Summary
This chapter explored how L2TPv3 evolved into a pseudowire emulation protocol by examining its evolution from its prestandard implementation, its Data Plane encapsulation, and its Control Plane Signaling. Following are several key aspects to take away from this chapter: L2TPv3 borrowed heavily from UTI's encapsulation format and L2TPv2's control plane to provide pseudowire emulation. L2TPv3 supports IP encapsulation using an IP protocol value of 115, whereas UTI uses an IP protocol value of 120. Although the base L2TPv3 draft supports both IP and IP/UDP encapsulation, the Cisco initial implementation supports only IP encapsulation. The Cisco L2TPv3 data packet encapsulation essentially is composed of an IP header, Session ID, cookie, an optional Layer 2-Specific Sublayer, and the Layer 2 payload. The Cisco L2TPv3 control packet encapsulation is composed of an IP header, Session ID, Control Message Header, and AVPs if necessary. The Control Message header includes a 12-octet field containing T-, L-, and S-bits; Version field; Length field; Control Connection ID; and Sequence Number sent and received fields. L2TPv3's control channel is inband along the data path, as opposed to AToM. Control Connection IDs are locally significant values to identify a specific Control Channel. One Control Channel usually exists between a pair of PE routers. Session IDs are locally significant values that identify a specific pseudowire session. AVPs are an extensible method of defining individual parameters in each of the control messages. When you have Control Plane signaling enabled, you must first build the Control Channel between the PE devices using SCCRQ/SCCRP/SCCCN messages. You negotiate any subsequent pseudowire sessions that you need to build through a similar three-way handshake using ICRQ/ICRP/ICCN messages. Although L2TPv3 has a defined control plane, the signaling is entirely optional. You can reduce it to just Control Channel negotiation or Control and Session Negotiation.
|