Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)
Extracted elements (20)
The incoming call procedures (rather than outgoing call procedures) are used for L2VPN signaling because they have advantages in terms of semantic relevance for pseudowire setup. The reference PWE3L2TP document provides more details on why incoming call procedures are more appropriate.
When the AGI AVP is omitted or contains a zero-length value, forwarders are considered to use a single designated default AGI. This allows backward-compatible operation for deployments that do not need to group forwarders.
When the Local End ID (SAII) AVP is omitted in control messages, it is assumed to have the same value as the TAII. This simplifies signaling for symmetric pseudowire configurations.
The signaling procedures for L2VPNs are based on the Control Connection Management and Incoming Call procedures defined in Sections 3.3 and 3.4.1 of RFC 3931. The document references SCCRQ, SCCRP, ICRQ, ICRP, ICCN, and SLI control messages from RFC 3931.
Before a local PE initiates a session of a particular pseudowire type to a remote PE, it MUST examine whether the remote PE has advertised this pseudowire type in the Pseudowire Capabilities List AVP and SHOULD NOT attempt to initiate the session if the intended pseudowire type is not supported.
If a PE receives a Pseudowire Type in ICRQ that it does not support, it MUST respond with a Call-Disconnect-Notify (CDN) with an 'unsupported pseudowire type' result code.
If the receiving PE supports the L2-Specific Sublayer specified by the sender, it MUST include that sublayer in its data packets. Otherwise, it MUST reject the connection by sending a CDN.
The MTU values of a given pseudowire, if advertised in both directions via the Interface MTU AVP, MUST be identical. If they do not match, the pseudowire SHOULD NOT be established.
To ensure interoperability, the mandatory (M) bit settings of existing AVPs used in L2VPN applications should be the same as those specified in RFC 3931. Setting the M-bit of the new AVPs to 1 will impair interoperability.
When connecting two forwarders together, both MUST have the same AGI as part of their forwarder identifiers.
A forwarder identifier is defined as the concatenation of an Attachment Group Identifier (AGI) and an Attachment Individual Identifier (AII), denoted as <AGI, AII>. The AGI groups forwarders for signaling purposes; the AII distinguishes forwarders within a group. The source forwarder is <AGI, SAII> and the target forwarder is <AGI, TAII>.
Pseudowire tie detection is required when both PEs initiate a pseudowire to each other simultaneously. The receiving PE compares the TAII and SAII from the received ICRQ against the SAII and TAII it previously sent; matching values indicate a tie. Once detected, the standard L2TP tie-breaking procedure from RFC 3931 Section 5.4.4 is used.
The TAII value is encoded in the Remote End ID AVP and sent in ICRQ along with the optional AGI to instruct the receiving PE to bind the proposed pseudowire to the forwarder matching the specified forwarder identifier. The SAII is encoded in the Local End ID AVP.
Three L2VPN forwarder types are defined: (1) simple cross-connect — one-to-one mapping between attachment circuit and pseudowire; (2) VPLS with Virtual Switching Instance (VSI) connected to multiple circuits and pseudowires; (3) VPWS with attachment circuits grouped into colored pools connected via point-to-point cross-connects.
IANA assigned three new L2TP AVP attribute types: 89 (Attachment Group Identifier), 90 (Local End Identifier), and 91 (Interface Maximum Transmission Unit). Three new CDN result codes were also assigned: 23 (Mismatching interface MTU), 24 (Attempt to connect to non-existent forwarder), and 25 (Attempt to connect to unauthorized forwarder).
This specification does not introduce any additional security considerations beyond those discussed in RFC 3931 (L2TPv3) and the L2VPN Framework (RFC 4664). Implementers should refer to those documents for security guidance.
The generic L2VPN setup algorithm iterates over SOURCE_FORWARDERS and TARGET_FORWARDERS lists. States include: pick source forwarder, pick target forwarder, check router ID (same→local cross-connect or skip, different→pseudowire setup), check existing pseudowire, initiate ICRQ, wait for response (ICRP→bind and ICCN, CDN→skip), and handle simultaneous ICRQ via tie detection and tie breaking.
The AGI AVP (Attribute Type 89) has a variable-length AGI field encoding the Attachment Group Identifier. Total length is 6 octets plus the AGI field length. The M bit SHOULD be set to 0; the H bit MAY be 0 or 1. MAY be present in ICRQ.
The Interface MTU AVP (Attribute Type 91) contains a 2-octet integer indicating the MTU in octets of packets that can be sent from the CE-facing interface. Total AVP length is 8 octets. The M bit SHOULD be set to 0; the H bit MAY be 0 or 1. MAY be present in ICRQ and ICRP.
The Local End ID AVP (Attribute Type 90) encodes the SAII value in a variable-length field. Total length is 6 octets plus the SAII field length. The M bit SHOULD be set to 0; the H bit MAY be 0 or 1. MAY be present in ICRQ.