Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)
Extracted elements (20)
An implementation MAY use more than one AAL5 connection between LAC and LNS to provide differentiated QoS to different client connections. QoS mechanisms involving inverse multiplexing across multiple VCs (e.g., Differentiated UBR) are deferred for further study.
Two encapsulation mechanisms are defined—VC-based multiplexing and LLC encapsulation—following RFC 2684. LLC encapsulation is mandatory on PVCs because it allows other protocols to share the same virtual connection, while VC-multiplexing is optional and useful for simpler 'null encapsulation' deployments.
Implementations connecting through a Frame Relay/ATM FRF.8 service interworking unit MUST use LLC encapsulated L2TP; VC-multiplexed L2TP is not compatible with FRF.8 interworking.
An implementation MUST support a PPP MRU of at least 1500 bytes. It is RECOMMENDED that an implementation support an IP packet of at least 9180 bytes in the PPP PDU.
An L2TP implementation MUST support LLC encapsulated L2TP on PVCs. It MAY additionally support LLC encapsulated L2TP on SVCs and MAY support VC-multiplexed L2TP on PVCs or SVCs.
An SVC-capable implementation MUST be able to both originate and respond to SVC setup requests. It MUST accept incoming calls offering LLC encapsulated L2TP, and MUST reject calls offering only an unsupported encapsulation.
Each L2TP PDU MUST be transported within a single AAL5 PDU, meaning the AAL5 connection MTU constrains both the L2TP tunnel MTU and all PPP connection MRUs that use the tunnel.
If an implementation connects through a Frame Relay/ATM FRF.8 service interworking unit, it MUST use LLC encapsulated L2TP.
If an implementation supports SVCs, it MUST use the Q.2931 Annex C procedure to negotiate connection setup, encoding the B-LLI IE to signal either VC-multiplexed L2TP or LLC encapsulated L2TP.
If an SVC tunnel is reset per RFC 2661 section 4.1, both ends MUST clear the SVC; any user sessions on the tunnel will be terminated. Either end MAY attempt to re-establish the tunnel upon receipt of a new client request.
The AAL5 message mode service MUST be used in the non-assured mode of operation without the corrupted delivery option.
The ATM AAL5 virtual circuit used for L2TP MUST be full-duplex and point-to-point. It MAY be either dedicated (permanent) or switched (on demand).
Upon notification that an AAL5 SVC connection has been cleared, an implementation SHALL tear down the tunnel and return the control connection to the idle state.
VC-multiplexed L2TP places the L2TP PDU directly as the AAL5 CPCS-PDU payload with no LLC header (also called 'Null encapsulation'). The protocol type is implicitly agreed upon per virtual circuit by provisioning or control plane procedures.
When a caller offers both encapsulation methods (VC-multiplexed and LLC encapsulated) in the SVC SETUP message, two B-LLI IEs SHALL be encoded within a Broadband Repeat Indicator IE in order of the sender's preference. The called peer SHALL respond with exactly one B-LLI IE in the Connect message.
When originating an LLC encapsulated SVC call, the Q.2931 B-LLI IE user information layer 2 protocol field SHALL be encoded to select LAN Logical Link Control (ISO/IEC 8802-2) in octet 6.
L2TP over AAL5 tunnel security may be compromised by attacks on the ATM transport network itself. Applications requiring protection are encouraged to use authentication headers, encrypted payloads, and/or ATM-layer security services described in ATM Forum specifications [AFSEC2].
AAL5 CPCS-PDU format: payload field (up to 2^16-1 octets), PAD field (0-47 octets), CPCS-UU (1 octet), CPI (1 octet), Length (2 octets), and CRC (4 octets). The CRC is computed over the entire CPCS-PDU except the CRC field itself.
For VC-multiplexed L2TP on SVCs, the B-LLI IE User Information layer 3 protocol field SHALL be encoded as 0B 80 00 00 5E 00 07, using the SNAP IPI followed by IANA OUI (0x00-00-5E) and L2TP PID (0x0007) as specified in DSL Forum TR-037.
LLC Encapsulated L2TP PDU: a 3-byte IEEE 802.2 LLC header (Destination SAP 0xAA, Source SAP 0xAA, Frame Type UI 0x03), followed by a 5-byte IEEE 802.1a SNAP header (OUI 0x00-00-5E for IANA, PID 0x0007 for L2TP), followed by the L2TP PDU payload.