Stewart Bryant Internet Draft Lloyd Wood Document: draft-bryant-pwe3-protocol-layer-00.txt Cisco Systems Ltd Expires: May 2002 November 2001 Protocol Layering in PWE3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes a unified protocol layering approach for pseudo-wire emulation edge-to-edge (PWE3). It adopts the principles that PWE3 should operate over a common Packet-Switched Network (PSN) service model, and that new protocol definitions should be minimized. Bryant Informational - expires May 2002 1 draft-bryant-pwe3-protocol-layer-00.txt November 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................2 2. Architecture of Pseudo-wires....................................2 2.1 Logical Protocol Layering Model................................2 2.2 Instantiation of the Protocol Layers...........................3 2.3 Generic Payload Types..........................................5 3. Conclusions.....................................................7 4. IANA considerations.............................................7 5. Security considerations.........................................7 6. References......................................................7 Authors' addresses.................................................8 Full copyright statement...........................................8 1. Introduction This document proposes a unified protocol layering approach for pseudo-wire emulation edge-to-edge (PWE3). It adopts the principle that PWE3 should be a single transport type operating over a common Packet Switched Network service model. It is also assumed that, where possible, existing IETF protocols should be used with minimum modification. The document presents the protocol-layering framework for pseudo-wires that specifies the various protocol elements and their functions. It then describes some necessary extensions to other IETF protocols. Requirements for PWs are described in [XIAO]. It is proposed that the protocol layering approach described here can be combined with material in the existing Framework for Pseudo- Wire Emulation Edge-to-Edge draft [PATE]. 2. Architecture of Pseudo-wires This section describes the PWE3 architectural model, and then describes the mapping of that architecture onto already-existing protocols defined by the IETF. A number of extensions to protocols that fall outside the PWE3 scope are also identified. 2.1 Logical Protocol Layering Model The logical protocol-layering model needed to support a pseudo-wire is shown in Figure 1. This model was previously presented in PWE3 WG list discussion [BRYANT]. Bryant Informational - expires May 2002 2 draft-bryant-pwe3-protocol-layer-00.txt November 2001 +---------------------------+ | Payload | +---------------------------+ | Payload convergence layer | +---------------------------+ | Pseudo-wire common layer | +---------------------------+ | PSN convergence layer | +---------------------------+ | PSN header | +---------------------------+ | MAC/Data-link | +---------------------------+ | Physical | +---------------------------+ Figure 1: Logical protocol layering model This protocol-layering model has the goals of making the pseudo-wire definition independent of the underlying PSN, and maximizing the reuse of IETF protocol definitions. The payload to be carried over the pseudo-wire is transported over a payload convergence layer which carries any information, not available in the payload itself, needed by the PW outbound interface to send the payload out over the PW end service. The payload convergence layer is carried over the pseudo-wire common layer, which provides the transport elements common to all types of pseudo-wire. This layer includes common support for real-time processing, sequencing and pseudo-wire multiplexing. The PSN convergence layer provides any necessary enhancements to any PSN needed to conform to the assumed PSN service requirement. The function of this layer is therefore to provide a consistent interface for the pseudo-wire, so that the pseudo-wire definition is independent of its carrier and does not need to be adapted to each individual PSN type. If the PSN already meets the service requirement, this layer is effectively empty. The PSN header, MAC/data-link and physical layer definitions are outside the scope of this framework. 2.2 Instantiation of the Protocol Layers The instantiation of the logical protocol-layering model is shown in Figure 2. The assumed goal in selecting components was to use existing IETF standards and common work in progress where possible. Bryant Informational - expires May 2002 3 draft-bryant-pwe3-protocol-layer-00.txt November 2001 Where this was not possible, the goal was to call for the design of components that have the widest application within the IETF. +-----------------------------------------+ ---- | Payload (circuit/cell/packet) | payload +-------------+--------------+------------+ ---- | Bit | Cell | Packet | payload | type | type | type | convergence | specific | specific | specific | layer +-------------+--------------+------------+ ---- | Optional RTP / Sequencing | ^ +-----------------------------------------+ PW common | L2TPv3 | v +-------------+-------------+-------------+ ---- | | |Fragmentation| ^ | | +-------------+ PSN | IPv4 | IPv6 | Length | convergence and | | +-------------+ PSN header | | | MPLS | v +-------------+-------------+-------------+ ---- | MAC/Data-link | +-----------------------------------------+ | Physical | +-----------------------------------------+ Figure 2: Instantiated protocol layering The payload can be classified into three generic types: bit, cell and packet. Within these generic types, there will be specific service types. For example, within the generic packet type there are at least the following specific-service types: HDLC, Frame Relay, Ethernet, VLAN, ATM-AAL5, etc. The design of the type- specific convergence layer and the choice between transporting the payload in a native or intermediate format are left to the document specifying the method of encapsulation for that service type. Three elements are common to all service types: multiplexing, sequencing and real-time support. Sequencing and real-time support are optional. If sequencing and/or real-time support are not needed for the transport, the associated header should be omitted from the protocol stack. There will be instances where a specific service type will be required to transport with or without sequence and/or real-time support. For example, an invariant of frame-relay transport is the preservation of packet order. However, where the frame-relay service is only being used to carry IP, it may be desirable to relax that constraint in return for reduced per-packet processing cost. A suitable protocol for use as a multiplexing layer is L2TPv3 [LAU]. This updated definition of L2TP is specified to operate directly Bryant Informational - expires May 2002 4 draft-bryant-pwe3-protocol-layer-00.txt November 2001 over a PSN, and in the limiting case the L2TP data encapsulation reduces to a four-octet opaque data field. L2TPv3 is specified for operation in both manually-configured and negotiated mode. The associated control protocol is extensible and may be used to signal pseudo-wire-specific configuration or run-time information. One of the specified L2TPv3 control protocol transport modes carries control traffic in-band, over the tunnel itself. This has many desirable properties, for example the keep-alive mechanism verifies the tunnel path itself rather than just the availability of the end- point. A suitable real-time and sequencing protocol is RTP [RTP]. This protocol is designed to be extensible to carry new payload types over a transport layer running over an IP network. RTP includes a control protocol for managing the timing service. RTP is not currently defined for operation over L2TP. A short document describing the correct method of multiplexing the RTP control and data over LT2Pv3 would be needed. If there are limitations in RTP that make it unsuitable for a specific PWE3 application, then it is likely that those same limitations will be a problem in other IETF applications. As such, enhancements should be made to RTP, rather than designing a PWE3-specific real-time encapsulation protocol instead. Although RTP provides both real-time and sequencing support, its twelve-octet overhead and relatively small (16-bit) existing sequence number space may lead to the definition of a new IETF transport sequencing protocol with an extensible sequence number space. Such a protocol would have wider application beyond PWE3, and should be generally useful. As such, if a new sequencing protocol is needed, it would be a requirement for IETF PWE3 work, but its definition would be outside the scope of PWE3-specific documents. The three PSN types that are within the scope of the IETF are IPv4, IPv6 and MPLS. IPv4 and IPv6 both already provide the necessary switching, length and fragmentation services needed to support all IETF-specified transport protocols. L2TPv3 is specified to run directly over IPv4 and IPv6. No PSN convergence layer is needed when the PSN is IPv4 or IPv6. MPLS provides a switching service, but does not provide length or fragmentation information. When MPLS is used as the PSN, a suitable convergence layer providing length and fragmentation services is needed. The definition of this length and fragmentation service is outside the scope of PWE3. 2.3 Generic Payload Types Three generic payload types have been identified: bit, cell and packet. Bryant Informational - expires May 2002 5 draft-bryant-pwe3-protocol-layer-00.txt November 2001 A bit payload is created by capturing, transporting and replaying the bit pattern on the emulated wire, without taking advantage of any structure that, on inspection, may be visible within the relayed traffic. This service will need sequencing and real-time support. A cell payload is created by capturing, transporting and replaying groups of bits presented on the wire in a fixed-size format. The delineation of the group of bits that comprise the cell is specific to the encapsulation type. More than one cell may be transported in a payload for efficiency reasons. Two common examples of cell payloads are 53-octet cells carrying ATM AAL2, and the larger 188- octet DVB Transport Stream packets. The cells to be incorporated in the payload may be selected by filtering them from the stream of cells presented on the wire. For example, an ATM PWE3 service may select cells based on their VCI or VPI fields. In the case of a trunked interface, the payload may be considered complete on the expiry of a timer, or when a fixed number of cells have been received, or both. The cell generic payload service will normally need sequence number support, and may also need real-time support. The cell generic payload service would not normally require fragmentation. A packet payload is one that operates by capturing, transporting and replaying groups of bits of varying sizes that are presented on the wire. The delineation of the packet boundaries is encapsulation- specific. Common examples of packet payloads are HDLC and Ethernet protocol data units (PDUs). For reasons of scoping and efficiency, the packet payload should, where possible, be transported as received. However, some payloads may justify the adoption of an intermediate format. A packet payload would normally be relayed across the PW as a single unit. However, there will be cases where the combined size of the packet payload and its associated PWE3 and PSN headers exceeds the PSN path MTU. This is likely to be the case where a user is providing the service and attaching to the service provider via an Ethernet, or where nested pseudo-wires are involved. The pseudo- wire would in this case require the use of the fragmentation support in the underlying PSN. The packet payload may be selected from the packets presented on the emulated wire on the basis of some sub-multiplexing technique. For example, one or more frame-relay PDUs may be selected for transport over a particular pseudo-wire based on the frame-relay Data-Link Connection Identifier (DLCI), or in the case of Ethernet payloads, on the basis of the VLAN identifier. A packet payload may need sequencing and real-time support. Bryant Informational - expires May 2002 6 draft-bryant-pwe3-protocol-layer-00.txt November 2001 3. Conclusions This document has proposed that PWE3 adopt a PSN-independent layering model, building on existing IETF protocols. A PSN convergence layer is needed for operation over an MPLS PSN to provide the necessary length and fragmentation service. A small extension to the IETF RTP protocol may be required. We hope that this document provides useful material for the architecture section of the existing PWE3 framework specification [PATE]. 4. IANA considerations There are no IANA considerations for this document. 5. Security considerations There are no security implications for this document. 6. References Internet-drafts are works in progress available from http://www.ietf.org/internet-drafts/ [BRYANT] S. Bryant, 'Are the layers right?', mail to IETF PWE3 WG mailing list, 22 August 2001. [LAU] J. Lau et al., 'Layer Two Tunneling Protocol "L2TP"', work in progress as an internet-draft, [PATE] P. Pate et al., 'Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)', work in progress as an internet- draft, September 2001: [RTP] Schulzrinne, H, Casner, S., Frederick, R. and V. Jacobson, 'RTP: A Transport Protocol for Real-Time Applications', IETF RFC1889, January 1996. [XIAO] X. Xiao et al, 'Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)', work in progress as an internet- draft, July 2001: Bryant Informational - expires May 2002 7 draft-bryant-pwe3-protocol-layer-00.txt November 2001 Authors' addresses Stewart Bryant Cisco Systems Ltd 4, The Square Stockley Park Uxbridge UB11 1BL Email: stbryant@cisco.com United Kingdom Phone: +44-20-8756-8828 Lloyd Wood Cisco Systems Ltd 4, The Square Stockley Park Uxbridge UB11 1BL Email: lwood@cisco.com United Kingdom Phone: +44-20-8734-4236 Full copyright statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bryant Informational - expires May 2002 8