PWE3 Working Group John Rutemiller Internet Draft Daniel Proch Expiration Date: December 2002 Marconi Communications Neil Harrison British Telecom June 2002 PWE3: ATM Cell Encapsulation draft-rutemiller-pwe3-atm-encaps-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026 [1]. 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. Rutemiller, et al. Expires December 2002 [Page 1] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 Abstract This draft defines the encapsulation formats and procedures for transporting ATM connections over a packet switched network (PSN) or packet based interface. This specification supports four levels of transport: 1) Transparent cell, 2) Virtual Path, 3) Virtual Channel, and 4) AAL5 Payload. Header compressions algorithms are provided for the Virtual Path and Virtual Channel transport levels. Table of Contents 1 Conventions used in this document................................3 2 Relationship to other drafts.....................................3 3 Introduction.....................................................4 3.1 Reference Model...............................................4 4 Terminology......................................................6 5 Packet Encapsulation Format......................................7 5.1 Control Word..................................................7 5.1.1 Length Field Processing..................................8 5.1.2 Sequence Field Processing................................9 5.2 ATM Transport Payload Format.................................10 6 ATM Transport Service...........................................12 7 ATM Cell Relay Services.........................................13 7.1 VPC Cell Relay Service.......................................13 7.2 VCC Cell Relay Service.......................................13 7.3 ATM Header Compression Formats...............................14 7.3.1 VPC Header Compression û Mode 1.........................14 7.3.2 VCC Header Compression û Mode 1.........................15 7.3.3 VCC Header Compression û Mode 2.........................15 8 AAL5 Payload VCC Service (AAL5-SDU mode)........................19 8.1 Transparency.................................................19 8.2 Encapsulation................................................19 8.3 Segmentation and Reassembly..................................21 8.4 Administrative cells.........................................21 9 Defect Handling.................................................22 9.1 Overview.....................................................22 9.2 ATM Transport Service........................................22 9.2.1 ATM Physical Layer OAM messages.........................23 9.2.2 Loss of Cell Delineation (LCD)..........................24 9.3 Comparison...................................................25 9.4 ATM Cell Relay Service.......................................25 Rutemiller, et al. Expires December 2002 [Page 2] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 9.4.1 VPC Cell Relay Service..................................25 9.4.2 VCC Cell Relay Service..................................26 9.5 AAL5 payload service.........................................26 9.6 PSN Failure detection and recovery...........................27 10 QoS considerations.............................................29 10.1 Cell Transfer Delay.........................................29 11 Technology specific Procedures.................................30 11.1 MPLS........................................................30 11.1.1 ATM to MPLS Class of Service Mapping...................30 11.2 L2TP........................................................31 12 ILMI support...................................................32 13 Security Considerations........................................32 14 Intellectual Property Disclaimer...............................32 15 References.....................................................32 16 Authors' Addresses.............................................33 17 Appendix A: Applicability Statements...........................34 17.1.1 ATM Transport Service..................................34 17.1.2 ATM Cell Relay Service.................................34 17.1.3 VPC and VCC Cell Header Compression....................36 17.1.4 Packet Switching Service...............................36 1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 2 Relationship to other drafts This draft is based on the draft-martini-atm-encap-mpls-xx.txt. The same encapsulations are used for the transparent port mode, cell mode, and AAL5 SDU mode found in the draft-martini document. Many of the same procedures are also used. This draft adds ATM cell header compression for the VPC and VCC cell relay services as a mechanism to improve efficiency. Compression Mode 1 removes the VPI or VPI/VCI in the VPC and VCC cell relay services, respectively. Compression Mode 2 applies only to the VCC cell relay service. This mode removes the VPI/VCI from every cell and compresses the PTI/CLP bits down to one instance per frame transmitted over the PSN. This compression mode represents an alternative to the PDU mode found in other drafts. The advantages of this approach over PDU mode are it is not specific to AAL5 and the arrival of an administrative cell Rutemiller, et al. Expires December 2002 [Page 3] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 does not cause two frames to be sent (the frame being collected plus a separate frame carrying the administrative cell). Other differences to the draft-martini document is a restructuring to better group functionality (defect management is not all in one section of the document) and additional defect management details. 3 Introduction The use of high-speed Packet Switched networks (PSN), such as IP/MPLS, provides an alternative to TDM links (e.g., SONET/SDH E3/T3, etc) for connecting together islands of ATM networks, or for connecting a remote ATM subscriber to a core ATM network. Using the PSN for ATM transport allows for statistical multiplexing of traffic in cases where the volume of ATM traffic does not justify the use of dedicated TDM transport paths. This capability also provides one component in a migration path for moving existing ATM and Frame Relay services to a PSN based network. Three generalized methods can be defined for carrying the ATM traffic over the PSN network depending on the type of service provided. These are: 1) ATM Transport service û This service emulates a transmission layer (F3) type capability. ATM cells arriving from the ATM device are transported transparently across the PSN. There are no VPI/VCI translations. 2) ATM Cell Relay service û This service emulates an ATM switched network. ATM cells arriving from the ATM device are mapped to a PSN connection based on the VPI or VPI/VCI value in the ATM header. ATM connections (VPC or VCC) arriving from the ATM device may be switched to one or more destinations on the PSN. 3) Packet switching service û This service operates between the ATM and AAL5 layers. The AAL5 service is terminated and the AAL5 PDU reassembled to extract the AAL5 SDU. The SDU is forwarded across the PSN and re-encapsulated/segmented at the egress of the PSN. The service appears somewhat like the cell relay service, but supports only AAL5 and is not fully transparent. 3.1 Reference Model This document defines the encapsulation for an end-to-end service between two ATM-to-PSN interworking functions. The encapsulation is not specific to any particular PSN technology. Rutemiller, et al. Expires December 2002 [Page 4] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The interworking function resides at the edge of the PSN network and is responsible for creating and maintaining a pseudo wire over which the ATM traffic will be transported. The purpose of the interworking function is to map one or more ATM connections to the pseudo wire. The pseudo wire can also be used to replace the ATM layer multiplexing. In this case, the PSN tunnel is required to provide the end-to-end service. The type of multiplexing used is dependent on the PSN technology. Figure 1 shows the reference model. |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | V V V V ATM Service+----+ +----+ ATM Service +-----+ | |PSN1|==================|PSN2| | +-----+ | |----------|............PW1.............|----------| | | AE1 | | | | | | | | AE2 | | |----------|............PW2.............|----------| | +-----+ | | |==================| | | +-----+ ^ | +----+ +----+ | ^ | | PSN PSN | | | | Edge 1 Edge 2 | | | | |<-------------- Emulated Service ---------------->| ATM ATM Edge 1 Edge 2 Figure 1: ATM Service Reference Model Rutemiller, et al. Expires December 2002 [Page 5] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 4 Terminology Packet Switched Network - A Packet Switched Network (PSN) is a network using variable length packets (e.g., IP, MPLS or L2TP) as the unit of switching. Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to Edge (PWE3) is a mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN. ATM Edge - AN ATM Edge (CE) is a device where one end of an emulated service originates and terminates. The CE is not aware that it is using an emulated service rather than a "real" service. PSN Edge û A PSN Edge (PSNE) is a device that provides PWE3 to a CE. Pseudo Wire - A Pseudo Wire (PW) is a connection between two PSN Edge nodes carried over a PSN. The PSN edge provides the adaptation between the ATM Edge and the Pseudo Wire. Pseudo Wire PDU - A Pseudo Wire PDU is a PDU frame sent on the Pseudo Wire that contains the encapsulated data from the ATM edge device. PSN Tunnel - A PSN Tunnel, when used, is a tunnel inside which multiple PWs can be nested so that they are transparent to core network devices. Ingress û The point where the ATM service is encapsulated into a Pseudo Wire PDU (ATM to PSN direction.) Egress - The point where the ATM service is decapsulated from a Pseudo Wire PDU (PSN to ATM direction.) Rutemiller, et al. Expires December 2002 [Page 6] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 5 Packet Encapsulation Format The ATM encapsulation format is generic to the type of PSN used to provide packet transport, as shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Transport Header (As Required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pseudo Wire Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM Transport Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Packet format for ATM encapsulation over a PSN The Control Word is inserted before the ATM service payload and helps detect improper delivery of the ATM payload at the egress. This includes functions for detecting misordered delivery and compensation for lower-layer technologies that may pad the frame. The Pseudo Wire Header is technology specific. The ATM service (transport, switched or packet service) is mapped to a flow or circuit depending on the technology. The PSN Transport Header provides an optional additional layer of multiplexing. It may be required due to the multiplexing structure of the technology (e.g., MPLS with PHP behavior), or may be used to map the ATM multiplexing onto the PSN multiplexing (e.g., to allow signaling of Pseudo Wires between interworking devices). The ATM transport Payload carries the ATM cell traffic in a concatenated format. The number of cells carried can be from one up to the maximum allowed by the PSN MTU. 5.1 Control Word The control word is not required for all services. The control word is designed to satisfy three requirements. - Ability to detect out of order delivery of PSN PDUs. - Ability to detect padding added by certain lower-layer technologies (i.e., below the PSN). - Data-plane control information for some ATM services. Rutemiller, et al. Expires December 2002 [Page 7] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 In all cases the egress interworking function MUST be aware of whether the ingress interworking will send a control word over a specific Pseudo Wire. This may be achieved using static configuration or using Pseudo Wire specific signaling. The method is outside the scope of this document. The control word is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM Control bits | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ATM control word The first 10 bits provide space for carrying ATM service specific control information. These are defined in the ATM service descriptions below. If a particular service does not require the use of these flags, these bits MUST be set to 0 upon transmission and ignored upon receipt. For services where use of these fields is optional, they must either be statically configured or signaled. The next 6 bits provide a length field. This field provides protection against lower-layer technologies that add, but do not remove, padding to meet minimum MTU requirements (i.e., Ethernet technologies). The length field provides a mechanism to detect and remove such padding. The next 16 bits provide a sequence number that can be used to detect misordered packet delivery. 5.1.1 Length Field Processing The length field is used to provide protection against padding that is not removed by certain lower-layer technologies, specifically Ethernet. Not all services require the length field. If a particular service uses the control word, but does not use the length field, these bits MUST be set to 0 upon transmission and ignored upon receipt. For services that require length processing, the length field MUST be set by the ingress and processed by the egress whenever the control word is present. Rutemiller, et al. Expires December 2002 [Page 8] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 If the total length of the Pseudo Wire PDU - including the ATM Transport payload, control word, Pseudo Wire header and PSN Transport Header - is less than 64 octets, the length field MUST be set to the PDU length. Otherwise the length field MUST be set to zero. 5.1.2 Sequence Field Processing 5.1.2.1 Processing the sequence number at the Ingress The processing of the sequence number field is OPTIONAL. The sequence number space is a 16-bit, unsigned circular space. The sequence number value 0 is used to indicate an unsequenced packet. The following procedures MUST be used by the ingress if sequencing is desired for a given ATM service: - the initial PDU transmitted on the Pseudo Wire MUST use sequence number 1 - the ingress MUST increment the sequence number by one for each subsequent PDU - when the transmit sequence number reaches the maximum 16 bit value (65535) the sequence number MUST wrap to 1 If the ingress does not support sequence number processing, then the sequence number field in the control word MUST be set to 0. 5.1.2.2 Processing the sequence number at the Egress If the egress supports receive sequence number processing, then the following procedures MUST be used: When an ATM service is initially created, the "expected sequence number" associated with it MUST be initialized to 1. When a PDU is received on the Pseudo Wire associated with the ATM service, the sequence number MUST be processed as follows: - if the sequence number on the packet is 0, then the PDU passes the sequence number check - otherwise if the PDU sequence number >= the expected sequence number and the PDU sequence number - the expected sequence number < 32768, then the PDU is in order. Rutemiller, et al. Expires December 2002 [Page 9] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 - otherwise if the PDU sequence number < the expected sequence number and the expected sequence number - the PDU sequence number >= 32768, then the PDU is in order. - otherwise the PDU is out of order. If a PDU passes the sequence number check, or is in order then, it can be delivered immediately. If the PDU is in order, then the expected sequence number MUST be set using the algorithm: expected_sequence_number := PDU_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number := 1; Pseudo Wire PDUs that are received out of order MAY be dropped or reordered at the discretion of the egress PE. If the egress does not support receive sequence number processing, then the sequence number field MUST be ignored. If frames arrive with the sequence number set, an indication SHOULD be sent to the management agent indicating the mismatch. 5.2 ATM Transport Payload Format The ATM Transport Payload section of the frame contains one or more ATM cells to be transported over the PSN. ATM cells are concatenated into the payload area by appending the first four bytes of the ATM cell header (i.e., VPI, VCI, PTI, CLP) and the 48-byte cell payload to the frame. This is shown in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI | VCI | PTI |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM Payload (48 octets) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI | VCI | PTI |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM Payload (48 octets) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ATM Cell Format (Mode 0) Rutemiller, et al. Expires December 2002 [Page 10] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The default concatenation is one cell per frame and MUST be supported. The maximum number of cells per frame is limited by the MTU. A maximum number less than the MTU limit MAY be supported. The maximum number of cells per frame must be either statically configured or signaled. Rutemiller, et al. Expires December 2002 [Page 11] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 6 ATM Transport Service Support for the ATM transport service is OPTIONAL. The ATM Transport service provides a cell-based Transmission Convergence function between two ATM devices at the ingress and egress of the PSN. From the perspective of the ATM devices, this service resides logically on top of the existing transmission convergence function (e.g., above the TC for SONET/SDH) in order to provide a end-to-end transmission function capability. The additional transmission layer is required because the existing transmission entities (e.g., SONET/SDH trails) connected to the ATM device terminates at the interworking function and the PSN Pseudo Wire terminates lies between, and terminates at, the ingress and egress interworking devices. Use of the ATM Control word is OPTIONAL. The control word is necessary only if sequencing is desired. If the ATM control word is used, then the Flag and Length fields MUST be set to 0 upon transmission and ignored upon receipt. If sequencing is not used, the control word MUST NOT be present in the PSN frame. At the ingress side, all ATM cells are transmitted over the pseudo wire except for idle/unassigned cells. The interworking function MUST NOT change any value in the ATM cell header or payload other than removing the HEC byte. At the egress side, the interworking function transmits all cells to the egress ATM device. The interworking function MUST NOT change any value in the ATM cell header or payload other than adding the HEC byte and recalculating the HEC value. ATM cell scrambling and cell rate adaptation are not performed by the ATM transport service transmission convergence. The procedures are not needed over the pseudo wire and are already performed by the transmission convergence function between the ATM devices and the interworking functions. The ATM transmission service MUST support operation at the ATM cell line rate of the interface between the interworking function and the ATM device. The ATM transmission service MAY support rates less than line rate. If this capability is supported, the egress MUST support shaping to the subscribed rate. The ingress ATM switch must also perform shaping to the subscribed rate. The ingress PSN node SHOULD perform policing of the ATM cell stream. Rutemiller, et al. Expires December 2002 [Page 12] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 7 ATM Cell Relay Services ATM cell relay services provide an ATM switching capability at the Virtual Path and the Virtual Circuit level. The ATM side of the interworking function provides ATM switching services, including VPI/VCI lookup and translation. Use of the ATM Control word is OPTIONAL. The control word is necessary only if sequencing is desired. If the ATM control word is used, then the Flag and Length fields MUST be set to 0 upon transmission and ignored upon receipt. If sequencing is not used, the control word MUST NOT be present in the PSN frame. The VPC and VCC cell relay services MUST be supported. 7.1 VPC Cell Relay Service The VPC cell relay service provides a Virtual Path level switching function. A Virtual Path Connection (VPC) is mapped to a single Pseudo Wire. The Pseudo wire is identified by a unique value in the PW Header. The ingress side may use a one-to-one mapping or a many-to-one mapping of the VPC to a Pseudo Wire. The allowed mapping depends on the PSN technology. When using many-to-one mapping, a VPC is identified using the VPI field in the ATM cell header. The VPI MUST be set to a valid value and MUST remain constant for each VPC supported. When using a one-to-one mapping, the VPC is identified by the PW Header value. The ingress side SHOULD use the same VPI for all cells in the Pseudo Wire. The egress side SHOULD ignore the value of the VPI field. The VCI field MUST NOT be modified in all cases. 7.2 VCC Cell Relay Service The VCC cell relay service provides a Virtual Circuit level switching function. A Virtual Circuit Connection (VCC) is mapped to a single Pseudo Wire. The Pseudo wire is identified by a unique value in the PW Header. The ingress side may use a one-to-one mapping or a many-to-one mapping of the VCC to a Pseudo Wire. The allowed mapping depends on the PSN technology. Rutemiller, et al. Expires December 2002 [Page 13] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 When using many-to-one mapping, a VCC is identified using the VCI field in the ATM cell header. The VCI MUST be set to a valid value and MUST remain constant for each VCC supported. When using a one-to-one mapping, the VCC is identified by the PW Header value. The ingress side SHOULD use the same VCI for all cells in the Pseudo Wire. The egress side SHOULD ignore the value of the VCI field. The VPI field is not used and MUST be set to 0 in all cases. 7.3 ATM Header Compression Formats Support for ATM header compression is OPTIONAL. ATM header compression is only supported when using one-to-one mappings and MUST NOT be used for many-to-one mappings. Each header compression format may be implemented independently. For example, an implementation may choose to support only VCC Mode 1 and not VPC Mode 1 or VCC Mode 2. The default format for carrying ATM cells over the PSN carries unused information when a one-to-one VPC to Pseudo Wire mapping is used. The efficiency of transporting ATM cells over the Pseudo Wire can be improved by removing unused bytes from the ATM cell header. 7.3.1 VPC Header Compression û Mode 1 VPC header compression removes the first byte of the ATM cell header prior to appending the cell to the frame. The format of the ATM Transport Payload using VPC header compression is shown in Figure 5. Rutemiller, et al. Expires December 2002 [Page 14] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | VCI | PTI |C| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | " | | ATM Payload (48 octets) | | " +-+-+-+-+-+-+-+-+ | | Rsvd | VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCI | PTI |C| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | " | | ATM Payload (48 octets) | | " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: VPC cell relay encapsulation (Mode 1) 7.3.2 VCC Header Compression û Mode 1 VCC header compression removes the first three bytes of the ATM cell header prior to appending the cell to the frame. The format of the ATM Transport Payload using VCC header compression is shown in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | PTI |C| " | +-+-+-+-+-+-+-+-+ ATM Payload (48 octets) | | " | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Rsvd | PTI |C| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | " | | ATM Payload (48 octets) | | " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: VCC cell relay encapsulation (Mode 1) 7.3.3 VCC Header Compression û Mode 2 Some applications require transmission efficiencies beyond what is provided by VCC header compression Mode 1. VCC Mode 2 further improves efficiency by not transmitting the PTI/CLP field with each cell payload. The encapsulation contains a single byte at the start Rutemiller, et al. Expires December 2002 [Page 15] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 of each frame that represents the PTI/CLP for all cell payloads in the frame. The encapsulation has the following properties: 1) Compresses the EFCI bit in user cells into a single value for all user cell payloads within the frame. 2) Compresses the CLP bit in user cells in to a single value for all user cell payloads within the frame. 3) Preserves the value of the ATM User-to-User bit in the PTI field. 4) Preserves the full PTI/CLP for administrative cells. 5) Is transparent to the AAL type in the ATM cell payload. 7.3.3.1 Transparency This mode is transparent to the ATM cell stream, with the exception of the user cell EFCI and CLP bits. The processing of these bits will cause all cells transmitted in the same frame to take on the same EFCI and CLP values. 7.3.3.2 Encapsulation Format The encapsulation format for VCC header compression Mode 2 is shown in figure 7. This mode removes the VPI, VCI and HEC fields and compresses the PTI/CLP field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A-PTI|C|U-PTI|C| " | +-+-+-+-+-+-+-+-+ ATM Payload (48 octets) | | " | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | " | +-+-+-+-+-+-+-+-+ ATM Payload (48 octets) | | " | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Figure 7: VCC cell relay encapsulation (Mode 2) The first byte contains the PTI and CLP bits for all of the cells in the frame. The first four bits carry the PTI and CLP bits for administrative cells (cells with PTI=1xx). The second four bits carry the PTI and CLP bits for user cells (cells with PTI=0xx). Rutemiller, et al. Expires December 2002 [Page 16] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 7.3.3.3 Procedures at the Ingress Side The procedures for processing arriving cells preserves the value of the ATM user-to-user bit located in PTI bit position 3 and all PTI bits for administrative cells. Processing is based on the following rules: 1) All cells, except the last cell of a frame, MUST be a user cell with the PTI bit value PTI=0x0. 2) The last cell in a frame may be either a user cell with any PTI value (PTI=0xx), or an administrative cell (PTI=1xx). 3) Administrative cells MUST be transmitted only as the last cell in a frame. 4) User cells with PTI=0x1 MUST be transmitted only as the last cell in a frame. The pseudo code for processing an arriving cell is as follows: If starting a new frame Initialize the A-PTI/C and U-PTI/C fields to zero Append arriving cell payload to frame buffer # If cell is a user cell, put PTI/CLP in low order four bits # If cell is an admin cell, put PTI/CLP in high order four bits If PTI=0xx then U-PTI = arriving-PTI U-CLP = U-CLP | arriving-CLP Else PTI=1xx then A-PTI = arriving-PTI A-CLP = arriving-CLP Endif # If cell is an admin cell (PTI=1xx) or a user cell with the # user-to-user bit set, send the frame now. # Note: checking if the cell is a not a user cell with the # user-to-user bit set (PTI is not 0x0) does the same thing. # # Or, if the frame is now at the maximum frame size, send now. If PTI != 0x0 or (FrameSize => MaxFrameSsize) Send Frame Endif Rutemiller, et al. Expires December 2002 [Page 17] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The value of the user cell EFCI is always set to the value of the last arriving cell. The algorithm above sets the value of the UU bit in the U-PTI field to zero when the arriving PTI=0x0. If the arriving PTI=0x1, the UU bit is set to one and the frame will be sent immediately. The algorithm above preserves the value of the admin cell PTI bits by placing them separately in the header, and since the frame is always sent immediately after appending the admin cell payload, it also preserves the ordering of the administrative cells within the sequence of user cells. ATM cells with PTI=0x1 and PTI=1xx will never occur in the same frame. 7.3.3.4 Procedures at the Egress Side The procedures for processing arriving frames generates ATM cells from using the PTI/CLP values carried in the first byte of the frame. The VPI and VCI are added and the HEC is recalculated. The pseudo code for processing an arriving frame is as follows: # For every cell, except the last cell, recreate the ATM # cell using the U-PTI and CLP bits, set the u-u bit to 0 # and transmit the ATM cell. While (not last cell payload) PTI = U-PTI & 010 CLP = U-CLP Prepend VPI/VCI Send cell End # If the last cell is still a user cell (admin field will # be set to 0000, then recreate the last ATM cell using # the values of the U-PTI and CLP. Note that the u-u bit # will be set properly. Otherwise, the last cell is an # admin cell. Recreate using the A-PTI and CLP If A-PTI/CLP = 0000 then PTI = U-PTI CLP = U-CLP Prepend VPI/VCI Send cell Else PTI = A-PTI CLP = A-CLP Prepend VPI/VCI Send cell Endif Rutemiller, et al. Expires December 2002 [Page 18] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 8 AAL5 Payload VCC Service (AAL5-SDU mode) Support for the AAL5 payload VCC service is OPTIONAL. AAL5 contains an eight-byte trailer and padding that is not required for transmission over a packet network. By removing the AAL5 overhead, additional efficiency can be achieved. The AAL5 payload VCC service defines a one-to-one mapping between the payload of a VCC containing AAL5 PDUs and a single Pseudo Wire. The AAL5 payload VCC service requires ATM segmentation and reassembly support in the interworking function. 8.1 Transparency The AAL5 Payload VCC service does not provide a transparent service. It requires successful processing of the AAL5 PDU and does not maintain ordering of administrative cells (PTI=1xx) and preserves only the least significant bit in the AAL5 user-to-user byte. This service can only be used when it is known that the lack of ATM and AAL5 transparency will not affect the service being provided. ATM services requiring full transparency must use the ATM cell relay service. 8.2 Encapsulation The AAL5 payload service encapsulation is shown in Figure 8. The ATM Control Word MUST be present. The length field MUST be processed as described in section 4.1.1. Processing of the sequence field is OPTIONAL. If used, it MUST be processed as described in section 4.1.2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |T|E|C|U|Res| Length | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM cell or AAL5 CPCS-SDU | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: AAL5 payload service encapsulation The first ten bytes of the control word carry are used to carry ATM specific information. Only four bits are currently defined. Rutemiller, et al. Expires December 2002 [Page 19] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 * Res (Reserved) These bits are reserved and MUST be set to 0 upon transmission and ignored upon reception. * T (Transport type) bit Bit (T) of the control word indicates whether the packet contains an ATM admin cell or an AAL5 payload. If T = 1, the packet contains an ATM admin cell, encapsulated according to section 4.2 and following the procedures in section 6.2. If T=0, the PDU contains an AAL5 payload. The ability to transport an ATM cell in the AAL5 mode is intended to provide a means of enabling administrative functionality over the AAL5 VCC. * E (EFCI) Bit The ingress PE device SHOULD set this bit to 1 if the EFCI bit of the final cell of those that transported the AAL5 payload is set to 1, or if the EFCI bit of the single ATM cell to be transported in the packet is set to 1. Otherwise this bit SHOULD be set to 0. The egress PE device SHOULD set the EFCI bit of all cells that transport the AAL5 payload to the value contained in this field. * C (CLP) Bit The ingress PE device SHOULD set this bit to 1 if the CLP bit of any of the ATM cells that transported the AAL5 payload are set to 1, or if the CLP bit of the single ATM cell that is to be transported in the packet is set to 1. Otherwise this bit SHOULD be set to 0. The egress PE device SHOULD set the CLP bit of all cells that transport the AAL5 CPCS-PDU to the value contained in this field. * U (Command/Response) Bit When FRF.8.1 Frame Relay / ATM PVC Service Interworking (see [5]) traffic is being transported, the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. The ingress PE device SHOULD copy this bit to the U bit of the control word. The egress PE device SHOULD copy the U bit to the CPCS-UU Least Significant Bit (LSB) of the AAL5 payload. The Length and Sequence Number fields are described in section 5.1. Rutemiller, et al. Expires December 2002 [Page 20] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 In case of a reassembly timeout, the encapsulating PE should discard all component cells of the AAL5 frame. 8.3 Segmentation and Reassembly The ingress must perform ATM AAL5 reassembly procedures as defined in Section 10 of [10]. AAL5 PDUs with reassembly errors MUST be discarded. Delivery of corrupted data is not supported. Persistent discarding of PDUs SHOULD be flagged to the network management agent. Suggested thresholds for such reporting are in Section 9 of this document. The AAL5 reassembly process MAY use a reassembly timer. If a reassembly timer is used, it MUST follow the procedures defined in Section 10.2.4 of [10]. The egress must perform AAL5 segmentation procedures as defined Section 10 of [10]. 8.4 Administrative cells This service does guarantee the proper transport of certain administrative cells, such as OAM and RM cells. This is because it does not attempt to maintain the relative order of these cells with respect to the user cells that comprise the AAL5 CPCS-PDU. OAM cells that arrive during the reassembly of a single AAL5 CPCS-PDU are sent immediately on the Pseudo Wire. The encapsulation for VCC cell relay MUST be used for such OAM cells without any header compression. The Control Word must be present. The control bits MUST be set to the binary value 0000100000. The length MUST be set to a value of 0. If the sequence number is being used, it MUST be processed normally. Rutemiller, et al. Expires December 2002 [Page 21] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 9 Defect Handling 9.1 Overview Defect handling procedures ensure that the appropriate actions are taken when a fault occurs. One of these actions is to localize the alarms raised to the management plane. The alarms resulting from a fault in the network should be present only in the layer in which the fault occurred, and at the location of the fault. Improper defect procedures will result in alarms generation progressing beyond the point of failure possibly to higher layers. The resulting distribution of alarms can make it difficult to perform fault isolation and could impact rapid repair. 9.2 ATM Transport Service Transparent port mode provides a capability similar to a cell-based transmission repeater service. The ATM cell stream is transparently carried from the source to the destination on a per-port basis. The interworking function (PE device) acts as a repeater for this service. For purposes of defect handling, transparent port mode is modeled as an F3 layer capability. The interworking function acts as a cell repeater between the SONET/SDH link and the MPLS Pseudo-Wire. Procedures are based loosely on [11], section 7.2.2.4. Only maintenance signals are supported. Performance monitoring is not supported. It is assumed that the SONET/SDH link and the PSN Pseudo- wire provide this function. ATM switches may implement F3 level cell-based services to achieve end-to-end performance monitoring. The procedures for applying this capability to PSN cell-based transmission are outside the scope of this document. This service is completely transparent to the ATM F4 and F5 fault management layer. The PEÆs MUST not terminate ATM F4/F5 OAM or admin cells. Transparent port mode must provide indications to the egress ATM device regarding the presence of an upstream lower layer failure. There are two types of upstream failures. 1) Failure of the transmission path from the ingress ATM device, either within the ATM layer or the physical layer that connects between the PSN edge node and the ATM devices. 2) Failure of the Pseudo wire, either within the PSN or the physical layer that connects the PSN nodes. Rutemiller, et al. Expires December 2002 [Page 22] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 A failure of the transmission path between the egress PSN edge node and the egress ATM device will be detected and managed by the egress ATM device. At the ingress PSN node, upon detecting a failure of the ingress transmission path (F1, F2 or F3), the ingress PSN node MUST indicate the failure to the egress PSN edge node by sending an ATM physical layer OAM-AIS message over the Pseudo Wire. At the egress PSN node, upon detection of a failure in the Pseudo Wire or upon receiving an indication of an upstream failure, a fault indication MUST be sent to the egress ATM device. Fault indications of an upstream failure between the ingress ATM device and the Ingress PSN node, or in the PSN, are sent to the egress ATM device using an ATM physical layer OAM-AIS message. If the egress ATM device does not support this message, the fault is indicated by disrupting the cell stream between the egress PSN and the egress ATM device. This forces a downstream Loss of Cell Delineation (LCD). Both ATM physical layer OAM messages and forcing LCD MUST be supported. The mechanism used MUST be configurable. 9.2.1 ATM Physical Layer OAM messages. Physical Layer OAM cells are used by this document to provide an additional F3 transmission path layer above the F3 transmission path layer provided by SONET/SDH, or PDH interfaces. The use of this capability requires support from the ATM devices at both ends of the PSN transparent port service. The Physical Layer OAM cell is adapted from [11]. Only the IAS and RDI capabilities are supported. The format of the ATM cell is shown in Figure 9. Rutemiller, et al. Expires December 2002 [Page 23] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI=0 | VCI=0 |0|1|1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HEC | 6 A | AIS | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | RDI | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A | 6 A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 A | 6 A | 6 A |0 0 0 0 0 0|CEC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C E C _| +-+-+-+-+-+-+-+-+ Figure 9: Cell format for Transparent Port Mode Maintenance Upon detection of a failure in the PSN Pseudo-wire, the interworking function (egress PE device) must send a Transmission Path Alarm Indication Signal (TP-AIS) to the egress ATM device by placing the value 0x01 in the 2nd byte of the ATM cell payload. ATM devices implementing this capability must send a Transmission Path Remote Defect Indication (TP-RDI) back towards the PSN by placing the value 0x01 in the 30th byte of the ATM cell payload. 9.2.2 Loss of Cell Delineation (LCD) Defect indication using Loss of Cell Delineation (LCD) is accomplished by disrupting the cell stream without affecting the lower transmission layers. Rutemiller, et al. Expires December 2002 [Page 24] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The LCD condition will occur if the state of the cell scrambling is changed. With cell scrambling disabled, the egress ATM device will not be able to locate a valid HEC value. Disabling the cell scrambler at the egress PSN node has the potential of causing faults in the lower layer, or false cell delineation. This can happen if the cell payload contains certain patterns. This is not a problem during the failure because upstream ATM cells will not be arriving. The only cells sent to the egress ATM device will be Idle/Unassigned cells. The potential vulnerability is during the time when the upstream service is restored and the cell scrambler is re-enabled. To prevent this vulnerability, the transparent port service MUST disconnect the Pseudo Wire from the egress path prior to disabling cell scrambling. After the upstream failure is cleared, the transparent port service MUST re-enable the cell scrambler prior to re-connecting the Pseudo Wire to the egress path. 9.3 Comparison The advantage of using physical layer OAM messages is it provides proper defect notification, isolation and alarm management. The disadvantage of using physical layer OAM messages is that the ATM Physical Layer OAM cells is not currently supported for non-cell based interface types, and therefore is not supported by existing ATM equipment. The advantage of using Loss of Cell Delineation is it will work with existing ATM devices. The disadvantage of using Loss of Cell Delineation is that it will cause an improper alarm condition at the egress ATM edge device. The alarm will indicate a fault between the egress PSN node and the egress ATM switch when in fact the fault is in the PSN or in the transmission layer between the ingress ATM device and the ingress PSN node. 9.4 ATM Cell Relay Service 9.4.1 VPC Cell Relay Service When configured for ATM VPC cell relay service, the interworking function SHOULD act as a VP switch in accordance with the procedures defined in [4]. Rutemiller, et al. Expires December 2002 [Page 25] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 When the interworking function is providing VPC service, it MUST pass all F4 administrative cells (VCI=3 and VCI=4) transparently. The ingress PSN node SHOULD generate an end-to-end F4 AIS (VCI=4) on the Pseudo Wire upon detecting a fault in the F3 or lower transmission function between the ingress ATM device and the ingress PSN node. The egress PSN node SHOULD generate an end-to-end F4 AIS towards the egress ATM device upon detecting a fault in the Pseudo Wire. A fault may be detected either though the PSN being revoked, through signaling, or through continuity checks. 9.4.2 VCC Cell Relay Service When configured for ATM VCC cell relay service, the interworking function SHOULD act as a VC switch in accordance with the procedures defined in [4], this includes all VP termination functions. When the interworking function is providing VCC service, it MUST pass all F5 administrative cells (PTI=1xx) transparently. The ingress PSN node SHOULD generate an end-to-end F5 AIS (PTI=101) on the Pseudo Wire upon detecting a fault in the F4 or lower transmission function between the ingress ATM device and the ingress PSN node. The egress PSN ndoe SHOULD generate an end-to-end F4 AIS towards the ATM device upon detecting a fault in the Pseudo Wire. A fault may be detected either though the PSN being revoked, through signaling, or through continuity checks. 9.5 AAL5 payload service The AAL5 payload service uses the same defect procedures specified for VCC cell relay service in section 8.4.2, with the addition of the following procedures. The AAL5 payload service introduces an additional fault condition: AAL5 reassembly failure. This condition exists above the F4 layer, although F4 defect procedures will be used. The interworking function SHOULD implement detection of persistent AAL5 reassembly errors. A persistent reassembly failure exists when ATM cells are arriving for a VCC for a period of time, but no valid AAL5 reassemblies have occurred (I.363.5 section 10.2.4). Rutemiller, et al. Expires December 2002 [Page 26] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The algorithm used to detect a persistent AAL5 reassembly error is defined as three consecutive reassembly failures occurring within a sliding one-minute window. Upon declaring a persistent AAL5 reassembly failure, the interworking function SHOULD raise an appropriate alarm to the management. A continuous failure of the AAL5 reassembly process may appear to the final VCC termination point as a failure of the VCC within the network, if it is known that the VCC origination point is transmitting cells. To help determine that the VCC is still active, the ingress PSN node MAY send the last cell from any failed PDUs. Alternatively, the ingress PSN MAY send a cell with a payload of all zero and the ATM user-to-user PTI bit set. The ATM device at the VCC origination point may also verify the VCC using continuity check OAM messages since these messages will be passed transparently by the ingress PSN node. 9.6 PSN Failure detection and recovery The PSN should provide some means for discovering failures either within the PSN or in a lower layer. It should also provide a means for indicating this failure. Most PSN technologies, and even ATM, are not able to detect all types of failures, or are slow to indicate the failure. Providing positive and timely indication of a failure requires an active mechanism (periodic continuity test). Positive and timely indication of a failure is required to prevent alarms from occurring outside of the PSN (i.e., in higher client layer networks) due to a failure within the PSN. Some ATM services may be performing their own continuity tests. A delay in detecting a failure inside the PSN will cause these continuity tests to fail and will raise an alarm in the ATM network. Such alarms may be raised in different organizationally administered networks, and they may occur geographically far from the true failure location. Assuming defect detection is possible, the fault notification is also required for the reasons noted above. In the forward direction, notification of a failure of the transmission system between PSN nodes, or the PSN itself, needs to propagate in a timely manner. Signaling messages used to tear down a connection is one method, but the propagation time is indeterminate (may be delayed due to heavy signaling load). In the backward direction, notification messages inform the transmitter that there is a fault. This allows the transmitter to Rutemiller, et al. Expires December 2002 [Page 27] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 take immediate action to restore the communication path (e.g., using a secondary path or establishing a new connection). Further, such fault notifications can actually be used to invoke signaling tear-down of connections. ITU specification Y.1711 is one method for detection and notification of faults in a MPLS PSN. Implementation of Y.1711 is RECOMMENDED in such a case. Other mechanisms, such as forcing an IP PING message down the PSN Transport Tunnel may also be used, but the will be required to be periodic and continuous in order to perform the required fault detection. Rutemiller, et al. Expires December 2002 [Page 28] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 10 QoS considerations 10.1 Cell Transfer Delay The ATM-to-PSN interworking function MUST bound the delay component it adds to the end-to-end ATM cell transfer delay for all ATM cells. During cell concatenation, this is measured based on the arrival of the first cell in a PSN frame. The method for bounding the delay is implementation specific. The default maximum delay is 250 microseconds. If a VCC in VCC cell relay mode is known to carry AAL5 payloads, the encapsulation process MAY use a maximum delay that allows a high probability of filling a frame to the maximum configured frame size. Use of this option MUST NOT violate the traffic management parameters configured for the VCC. The maximum delay used to achieve this affect is implementation specific. Rutemiller, et al. Expires December 2002 [Page 29] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 11 Technology specific Procedures 11.1 MPLS MPLS Pseudo Wires MUST support both the Pseudo Wire Header and the PSN Transport Header. ATM cell relay service MUST support a one-to- one mapping of the ATM VCC or VPC to the PSN Pseudo Wire. The PSN Transport header provides end-to-end transport between the ingress and egress interworking functions. The PSN Transport header and Pseudo Wire header are standard MPLS labels. Implementations SHOULD NOT support many-to-one mapping of the ATM cell relay service to the Pseudo Wire or transmission of Pseudo Wire frames without the PSN Transport header. 11.1.1 ATM to MPLS Class of Service Mapping The ingress PE should have the ability to maintain separation of ATM traffic classes (i.e. CBR, rt-VBR, nrt-VBR, ABR, and UBR) for each of the services transported across the PSN. The mechanism used to maintain these traffic classes depends upon the PSN in use. For example, does the PSN support resource assignments per PSN tunnel? Can it support per PSN tunnel queuing? The actual mechanisms to support the ATM traffic classes should be left up to the operator. This section offers some suggestions. QoS assignment on the PSN requires close inspection of incoming cell headers. This includes mapping the VPI/VCI to a specific PSN traffic class and using the CLP bit to determine the PSN drop precedence. For example, when processing incoming cells for a CBR VCC service, the ingress PE may mark the outgoing Pseudo Wire PDUs with a particular DSCP or MPLS EXP. (Marking depends upon the PSN in use.) Downstream PSN devices should use this marking to map these PW PDU's to queuing and scheduling resources that emulate an ATM CBR service (i.e. low latency, guaranteed bandwidth). If the PSN is MPLS based, the ingress PE may associate ATM services with E-LSPs or L-LSPs as defined in [9]. The PSN should also have the ability to maintain the ATM cell loss priority (CLP) of incoming cells. For example, in case of an MPLS based PSN, the ingress PE may mark both the PSN transport and Pseudo Wire labels with EXP = 010 or EXP = 011 depending upon the incoming cell's CLP value. (If the PW PDU contains multiple ATM cells the ingress PE should not mark the PW PDU to convey a single drop precedence.) For AAL5 services, the ingress PE should mark the PW Rutemiller, et al. Expires December 2002 [Page 30] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 PDU using the same algorithm that determines the C (CLP) bit (i.e if any cell has CLP = 1 then the C bit should be set to 1.) The following is an example of mapping ATM service classes and CLP to a Diff-Serv capable PSN. ATM traffic class CLP PSN marking --------------------------------------------------- CBR 0 DSCP=000110 or EXP=110 CBR 1 DSCP=000111 or EXP=111 rt-VBR 0 DSCP=000100 or EXP=100 rt-VBR 1 DSCP=000101 or EXP=101 nrt-VBR 0 DSCP=000010 or EXP=010 nrt-VBR 1 DSCP=000011 or EXP=011 UBR 0 DSCP=000000 or EXP=000 UBR 1 DSCP=000001 or EXP=001 11.2 L2TP Rutemiller, et al. Expires December 2002 [Page 31] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 12 ILMI support Integrated Local Management Interface (ILMI) typically is used in ATM networks for neighbor resource availability detection, address registration, auto-configuration, and loss of connectivity detection. ILMI messages are sent as SNMP PDUÆs within ATM AAL5 cells. The PSN edge node MAY use ILMI to detect or indicate the change in status of the ATM service as defined by [12], or by any extensions. Upon detecting a change in status via ILMI, the defect handling procedures defined in Section 9 of this document SHOULD be used. 13 Security Considerations This draft does not introduce any new security considerations to IP, L2TP or MPLS. 14 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 15 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] "Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)", draft-ietf-pwe3-requirements-01.txt, Work in Progress [4] ITU-T Recommendation I.610 (February 1999): B-ISDN operation and maintenance principles and functions [5] "Frame Relay / ATM PVC Service Interworking Implementation Agreement (FRF.8.1)", Frame Relay Forum 2000. [6] "Frame Based ATM over SONET/SDH Transport (FAST)," ATM Forum 2000. [7] "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-03.txt, Work in Progress [8] "Requirements and framework for ATM network interworking over MPLS", draft-koleyni-pwe3-atm-over-mpls-02.txt, Work in Progress Rutemiller, et al. Expires December 2002 [Page 32] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 [9] "MPLS Support of Differentiated Services", draft-ietf-mpls-diff- ext-09.txt, Work in Progress [10] ITU-T Recommendation I.363.5 (August 1996): B-ISDN ATM Adaptation Layer specification: Type 5 AAL [11] ITU-T Recommendation I.432.2 (February 1999): B-ISDN user- network interface û Physical layer specification: 155 520 kbit/s and 622 080 kbit/s operation [12] "Integrated Local Management Interface (ILMI) Specification Version 4.0 (AF-ILMI-0065.000)", ATM Forum, September 1996. 16 Authors' Addresses John Rutemiller Marconi Networks 1000 Marconi Drive Warrendale, PA 15086 Email: john.rutemiller@marconi.com Daniel Proch Marconi Networks 1000 Marconi Drive Warrendale, PA 15086 Email: daniel.proch@marconi.com Neil Harrison British Telecom Email: neil.2.Harrison@bt.com Rutemiller, et al. Expires December 2002 [Page 33] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 17 Appendix A: Applicability Statements 17.1.1 ATM Transport Service ATM Transport Service appears as a physical interface to the ATM device. It may be operating at either the full line rate of the interface between the ATM device and the interworking function, or may be operating at a reduced rate (similar to a fractional service). Transparent Port Service does not perform any VPI/VCI lookups, so is transparent to ATM signaling and routing. Transport service is not fully transparent to the ATM device. If the service is operating at less than line rate, it requires a shaping function at the ATM device to perform rate matching. Transport service is also not transparent to fault management procedures. Achieving proper fault management behavior requires adding another F3 transport layer on the link between the ATM device and the interworking function. This requires changes to the ATM device. In networks where proper fault management is not an issue, other techniques can be used that do not require changes to the ATM device. 17.1.2 ATM Cell Relay Service The ATM cell relay service provides a per-connection (Virtual Path or Virtual Channel) service across the PSN. Virtual Paths and Virtual channels may be grouped together to provide the appearance of an ATM port to ATM signaling and routing. Operation in this mode requires coordination of valid VPI and VCI values between the ATM device and the interworking device at both sides of the PSN. Virtual paths may be switched to separate locations in the PSN. Operation in this mode would appear to the ATM device as a VP switched ATM network. ATM signaling and routing within the Virtual Path will be transparent. Virtual channels may also be individually switched to separate locations in the PSN. Operation in this mode would not be transparent to the ATM device and would only support a PVC service. Support for SVC service requires ATM signaling on the interworking function, in which case the interworking function appears as an adjacent ATM switch to the ATM device. Rutemiller, et al. Expires December 2002 [Page 34] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The VCC cell relay service has the following attributes: 1. Supports all ATM Adaptation Layers. 2. Non-terminating OAM/Admin cells are transported among the user cell in the same order as they are received. This requirement enables the use of various performance management and security applications. 3. In order to gain transport efficiency on the PSN, multiple cells may be encapsulated in a single PW PDU. This process is called ôcell concatenationö. How many cells to insert or how long to wait for cell arrival before sending a PW PDU is an implementation decision. Like any SAR scheme, cell concatenation introduces latency to a cell relay service. 4. The CLP bit from each cell may be mapped to a corresponding marking on the PW PDU. This allows the drop precedence to be preserved across the PSN. The VCC cell relay service encapsulation has the following drawbacks: 1. There is no currently defined method to translate the forward congestion indication (EFCI) to a corresponding function in the PSN. Nor is there a way to translate PSN congestion to the EFCI upon transmission by the egress PE. 2. The ATM cell header checksum can correct a single bit error in the cell header. Analogous functionality does not exist in most PSNs. A single bit error in a PW PDU will most likely cause the packet to be dropped due to a L2 FCS failure. 3. There is no currently defined method to support EPD/PPD on the PSN. The VPC cell relay service shares many of the same attributes of the VCC cell relay service as defined above: 1. Non-terminating OAM/Admin cells are transported among the user cell in the same order as they are received. 2. The encapsulation allows cell concatenation. 3. The CLP bit from each cell may be mapped to a corresponding marking on the PW PDU. This allows the drop precedence to be preserved across the PSN. Rutemiller, et al. Expires December 2002 [Page 35] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The VPC cell relay service encapsulation has the following drawbacks: 1. There is no currently defined method to translate the forward congestion indication (EFCI) to a corresponding function in the PSN. Nor is there a way to translate PSN congestion to the EFCI upon transmission by the egress PE. 2. The ATM cell header checksum can correct a single bit error in the cell header. Analogous functionality does not exist in most PSNs. A single bit error in a PW PDU will most likely cause the packet to be dropped due to a L2 FCS failure. 17.1.3 VPC and VCC Cell Header Compression The VPC and VCC cell header compression is an optional service that increases the transmission efficiency of ATM cells over the PSN. The value of header compression depends on application of ATM over PSN transport. When used for transporting private networks, the traffic volume is most likely small compared to the PSN network. However, when used to connect together different parts of a public ATM network, the traffic volume may warrant the need for increased transmission efficiency. The maximum bandwidth saved using cell header compression is 1.9%, 5.8% and 7.7% for VPC Mode 1, VCC Mode 1 and VCC Mode 2 respectively. The use of header compression has the same benefits and limitations of the normal VPC and VCC cell relay services. The additional drawback is increased complexity in vendor implementations. For this reason, this capability is optional. Vendors may also choose to implement a subset of the header compression formats allowing them to match the level of additional complexity to the network into which their equipment is generally used. The VCC Mode 2 header compression adds one more drawback in the lack of transparency for the EFCI and CLP bits. The additional efficiency provided by this mode will have to balanced against the minor loss of transparency before deploying this service. 17.1.4 Packet Switching Service The packet switching service is only concerned with the transport of the AAL5-SDU (AAL5 payload). This service is useful when it is known before hand that the traffic between the ATM devices contains only AAL5 packets (e.g., ATM attached routers, or Frame Relay over ATM service). Rutemiller, et al. Expires December 2002 [Page 36] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 The advantage of this service is the efficiency of transporting packet-based traffic over the PSN. Removing the AAL5 PAD and trailer recovers as much as 7.1% of additional bandwidth beyond what can be achieved using VCC header compression Mode 2. The packet switching service requires successful processing of the AAL5 trailer. This makes it unsuitable for networks that somehow prevent successful processing of the AAL5 PDU by an intermediary device (e.g., ATM encryptors). Rutemiller, et al. Expires December 2002 [Page 37] Internet Draft draft-rutemiller-pwe3-atm-encaps-01.txt June 2002 Rutemiller, et al. Expires December 2002 [Page 38]