Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
updated by
- rfc-5641 — Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values
Extracted elements (31)
The three-octet FR header is explicitly excluded from scope; only 2-byte (required) and 4-byte (optional) variants are defined, simplifying interoperability negotiation to a single AVP exchange.
Waiting until the PVC transitions to ACTIVE before establishing the L2TP session is preferred because it delays allocation of L2TP resources until absolutely necessary.
Clients obtain session parameters through the standard L2TPv3 three-way handshake (ICRQ/ICRP/ICCN). An LCCE MAY send ICRQ or ICRP before a PVC is ACTIVE as long as the Circuit Status AVP reflects INACTIVE and an SLI is sent when the PVC becomes ACTIVE.
Frame Relay port-to-port (interface-to-interface) transport is outside this document's scope and is instead handled by HDLC Pseudowires as defined in RFC 4349. SVCs and SPVCs are also out of scope.
An L2TPv3 Control Connection MUST first be established before tunneling a Frame Relay circuit over IP, and the SCCRQ and SCCRP messages MUST include the Frame Relay DLCI PW Type of 0x0001 in the Pseudowire Capabilities List.
An LCCE MUST be able to identify itself uniquely in SCCRQ and SCCRP messages via a globally unique value, by default using the structured Router ID AVP, though the unstructured Hostname AVP MAY also be used.
An LCCE participating in Q.933 Annex A PVC status management MUST transmit an SLI message including the Circuit Status AVP when it detects a change in the status of a local FR PVC.
FECN and BECN bits must never be cleared by the LCCE; they MAY be set to indicate congestion but if unsupported MUST be passed unchanged.
FRPW over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer when sequencing is enabled.
If LCCE A uses a periodic retry mechanism after receiving a CDN, the retry period and maximum number of retries MUST be configurable.
If sequencing or other features require an L2-Specific Sublayer, the Default format defined in Section 4.6 of RFC 3931 MUST be used.
If the Frame Relay Header Length AVP is not signalled, it MUST be assumed that the peer uses a 2-byte Frame Relay header.
If the FRPW is known to be carrying data that does not require strict packet ordering (such as IP), packet sequencing SHOULD NOT be enabled.
In the event a PVC is deleted at either LCCE, the associated L2TP session MUST be torn down via the CDN message.
Reserved bits in the Circuit Status AVP MUST be set to 0 by the sender and ignored by the receiver.
The C/R bit MUST NOT be changed by the LCCE; it is conveyed transparently.
The Circuit Status AVP MUST be present in ICRQ and ICRP messages and MAY be present in Set Link Info (SLI) messages for FRPWs.
The Pseudowire Type AVP (Attribute Type 68) MUST be present in ICRQ messages and MUST include the Frame Relay DLCI PW Type of 0x0001 for FRPWs.
The Remote End ID AVP MUST be present in the ICRQ to identify the PVC; at a minimum, implementations MUST support an unstructured four-octet value known to both LCCEs.
The SLI message MUST be sent any time there is a circuit status change reportable by the Circuit Status AVP, except for the initial ICRQ, ICRP, and CDN messages.
The two peer LCCEs MUST agree on the length of the Frame Relay header; if a different length is supported, the L2TP session MUST be torn down via CDN with result code 19.
Frame Relay result codes for the CDN message: 17 (FR PVC deleted permanently), 18 (FR PVC INACTIVE for extended period), 19 (Mismatched FR Header Length).
The Frame Relay Header Length AVP (Attribute Type 85) is exchanged during session negotiation in ICRQ and ICRP messages to negotiate whether 2-byte or 4-byte FR headers are used. The M bit MAY be 0 or vary; the H bit MAY be 0 or 1.
A new Control Message AVP Attribute Type 85 (Frame Relay Header Length) was allocated in the L2TP AVP registry managed per RFC 3438.
IANA allocated L2TPv3 Pseudowire Type 0x0001 for Frame Relay DLCI Pseudowire Type in the L2TPv3 Pseudowire Types registry (number space created with RFC 3931).
Three new Result Code AVP values for CDN messages were allocated: 17 (PVC deleted permanently), 18 (PVC INACTIVE for extended period), 19 (Mismatched FR Header Length), managed per RFC 3438.
Frame Relay over L2TPv3 is subject to the security considerations defined in RFC 3931. There are no additional security considerations specific to carrying Frame Relay beyond those present for other data link types.
PVC states are ACTIVE and INACTIVE. An LCCE MAY initiate an L2TP session immediately upon PVC creation or wait until the PVC becomes ACTIVE. State changes are signalled via SLI with the Circuit Status AVP; PVC deletion triggers CDN and tears down the L2TP session.
The Circuit Status AVP (Attribute Type 71) is a 16-bit mask; bit 0 (A) indicates ACTIVE (1) or INACTIVE (0), bit 1 (N) indicates new (1) or existing (0) FR PVC; remaining bits are reserved.
The FR PDU is transported in its entirety excluding opening/closing HDLC flags and FCS, with bit stuffing undone. The two-octet FR header (REQUIRED) contains hi-dlci, C/R, lo-dlci, FECN, BECN, DE bits; a four-octet variant (OPTIONAL) extends the DLCI field across 4 bytes.
The Frame Relay Header Length AVP (Attribute Type 85) is a 2-octet unsigned integer with values 2 (two-octet header) or 4 (four-octet header); total AVP length before hiding is 8 octets.