PWE3 Working Group Jeremy Brayley Internet Draft Gerald de Grace Expiration Date: April 2001 John Shirron Laurel Networks, Inc. Rick Wilder Nasser El-Aawar Masergy Communications Level 3 Communications, LLC. Dimitri Stratton Vlachos Andrew G. Malis Mazu Networks, Inc. Vinai Sirkay Vivace Networks, Inc. Tom Johnson Litchfield Communications, Inc. Jayakumar Jayakumar Durai Chinnaiah Chris Liljenstolpe Dan Tappan Cable & Wireless Eric Rosen Cisco Systems, Inc. John Rutemiller Marconi Networks Laura Dominik Qwest Communications, Inc. Giles Heron PacketExchange Ltd. September 2001 PWE3: ATM service description draft-brayley-pwe3-atm-service-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. Abstract Brayley, et al. Expires April 2002 [Page 1] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [2]. This draft lists ATM specific requirements and provides encapsulation formats and semantics for connecting ATM edge networks through a core packet network using IP, L2TP or MPLS. This basic application of ATM interworking will allow ATM service providers to take advantage of new technologies in the core in order to provide ATM services. Table of Contents 1 Conventions used in this document..............................3 2 Introduction...................................................3 3 Terminology....................................................4 4 General Requirements...........................................5 5 ATM Service Encapsulation......................................5 5.1 ATM control Word............................................6 5.1.1 Setting the sequence number............................7 5.1.2 Processing the sequence number.........................7 6 ATM Cell Relay Services........................................8 6.1 VCC Cell Relay Service......................................8 6.1.1 OAM Cell Support.......................................8 6.2 VPC Cell Relay Service......................................9 6.2.1 OAM Cell Support.......................................9 6.3 Transparent Port Cell Relay Service........................10 6.3.1 OAM Cell Support......................................10 6.4 Cell Mode Encapsulation....................................11 7 Frame Based ATM Services......................................12 7.1 AAL5 Payload VCC Service...................................12 7.1.1 OAM Cell Support......................................14 7.2 AAL5 Transparent VCC Service...............................14 7.2.1 OAM Cell Support......................................16 7.2.2 Fragmentation.........................................16 8 ILMI support..................................................17 9 QoS considerations............................................18 10 Pseudo-Wire specific requirements............................18 10.1 MPLS requirements.........................................18 10.2 L2TP requirements.........................................18 10.3 IP requirements...........................................18 11 Security Considerations......................................18 12 Intellectual Property Disclaimer.............................18 13 References...................................................18 14 Acknowledgments..............................................19 15 Authors' Addresses...........................................19 Brayley, et al. Expires April 2002 [Page 2] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 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 [1]. 2 Introduction Many service providers have multiple service networks and the Operational Support System capabilities needed to support these existing service offerings. Packet Switched Networks (PSNs) have the potential to reduce the complexity of a service providerÆs infrastructure by allowing virtually any existing digital service to be supported over a single networking infrastructure. The benefit of this model to a service provider is threefold: 1. Leveraging of the existing systems and services to provide increased capacity from a packet switched core. 2. Preserving existing network operational processes and procedures used to maintain the legacy services. 3. Using the common packet switched network infrastructure to support both the core capacity requirements of existing services and the requirements of new services supported natively over the packet switched network. This draft describes a method to carry ATM services over IP, L2TP and MPLS. It lists ATM specific requirements and provides encapsulation formats and semantics for connecting ATM edge networks through a core packet network using IP, L2TP or MPLS. The techniques described in this draft will allow ATM service providers to take advantage of new technologies in the core in order to provide ATM multi-services. Figure 1, below displays the ATM services reference model. This model is adapted from [6]. Brayley, et al. Expires April 2002 [Page 3] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | V V V V ATM Service+----+ +----+ ATM Service +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ | | |==================| | | +-----+ ^ | +----+ +----+ | ^ | | Provider Provider | | | | Edge 1 Edge 2 | | | | |<-------------- Emulated Service ---------------->| Customer Customer Edge 1 Edge 2 Figure 1: ATM Service Reference Model 3 Terminology Packet Switched Network - A Packet Switched Network (PSN) is a network using 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. Customer Edge - A Customer 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. Provider Edge - A Provider Edge (PE) is a device that provides PWE3 to a CE. Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs carried over a PSN. The PE provides the adaptation between the CE and the PW. Pseudo Wire PDU - A Pseudo Wire PDU is a PDU sent on the PW that contains all of the data and control information necessary to provide the desired service. PSN Tunnel - A PSN Tunnel 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.) Brayley, et al. Expires April 2002 [Page 4] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 Egress - The point where the ATM service is decapsulated from a Pseudo Wire PDU (PSN to ATM direction.) 4 General Requirements For transport of an ATM service across a PSN, the PSN SHOULD be able to: 1. Carry all AAL types transparently. 2. Carry multiple ATM connections (VPCs and/or VCCs). 3. Support ATM OAM applications. 4. Transport Cell Loss Priority (CLP) and Payload Type Indicator (PTI) information from the ATM cell header. 5. Provide a mechanism to detect mis-ordering of ATM cells over the PSN. 6. Support traffic contracts and the QoS commitments made to the ATM connections (through the use of existing IETF defined Diff-Serv techniques). 5 ATM Service Encapsulation This section describes the general encapsulation format for ATM over PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics pertaining to each packet technology are covered in later sections. Figure 2 provides a general format for encapsulation of ATM cells (or frames) into packets. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM Control Word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM Service Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: General format for ATM encapsulation over PSNs The PSN Transport Header depends on the packet technology: IP, L2TP or MPLS. This header is used to transport the encapsulated ATM information through the packet switched core. This header is always present if the Pseudo Wire is MPLS. Brayley, et al. Expires April 2002 [Page 5] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 The Pseudo Wire Header depends on the packet technology: IP, L2TP or MPLS. It identifies a particular ATM service within the PSN tunnel. The ATM Control Word is inserted before the ATM service payload. It may contain a length and sequence number in addition to certain control bits needed to carry the service. The ATM Service Payload is specific to the service being offered via the Pseudo Wire. It is defined in the following sections. 5.1 ATM control Word The ATM control word is part of the ATM specific header. It is not required for all services. The control word is designed to satisfy three requirements. - Ability to detect out of order delivery of PDUs. - Ability to detect padding added by certain link technologies. - Control bits for ATM services. In all cases the egress PE MUST be aware of whether the ingress PE will send a control word over a specific Pseudo Wire. This may be achieved using static configuration or using Pseudo Wire specific signaling. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Flags | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ATM control word In the above diagram the first 4 bits are reserved for future use. They MUST be set to 0 upon transmission and MUST be ignored upon receipt. The next 4 bits provide space for carrying ATM service specific flags. 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. The next 8 bits provide a length field, which is used as follows: Brayley, et al. Expires April 2002 [Page 6] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 The Pseudo Wire may traverse a network link that requires a minimum frame size. (Ethernet is a practical example with a minimum frame size of 64 octets.) Such links will apply padding to the Pseudo Wire PDU to reach its minimum frame size. A mechanism is required for the egress PE to detect and remove such padding. If the total length of the Pseudo Wire PDU (including the control word if applicable) is less than 64 octets, the length field MUST be set to the PDU length. Otherwise the length field MUST be set to zero. The next 16 bits provide a sequence number that can be used to guarantee ordered packet delivery. 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. 5.1.1 Setting the sequence number The following procedures SHOULD be used by the ingress PE if sequencing is desired for a given ATM service: - the initial PDU transmitted on the Pseudo Wire MUST use sequence number 1 - the PE 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 PE does not support sequence number processing, then the sequence number field in the control word MUST be set to 0. 5.1.2 Processing the sequence number If the egress PE supports receive sequence number processing, then the following procedures SHOULD 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 SHOULD be processed as follows: - if the sequence number on the packet is 0, then the PDU passes the sequence number check Brayley, et al. Expires April 2002 [Page 7] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 - 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. - 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 SHOULD 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 PE does not support receive sequence number processing, then the sequence number field MAY be ignored. 6 ATM Cell Relay Services This section defines three types of ATM services that may be supported over the PSN: ATM VCC, ATM VPC, and ATM transparent port. 6.1 VCC Cell Relay Service The VCC cell relay service is characterized by the mapping of a single ATM VCC (VPI/VCI) to a Pseudo Wire. This service is fully transparent to the ATM Adaptation Layer. The egress PE may choose to apply a different VCI other than the one that arrived at the ingress PE. The egress PE MUST choose the outgoing VCI based solely upon the Pseudo Wire header. The VCC cell relay service is REQUIRED. This service MUST use the cell mode encapsulation defined in section 6.4. 6.1.1 OAM Cell Support Brayley, et al. Expires April 2002 [Page 8] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 When configured for a VCC cell relay service, both PEÆs SHOULD act as a VC switch in accordance with the OAM procedures defined in [5]. The PEs SHOULD be able to pass the following OAM cells transparently: - F5 AIS (segment and end-to-end) - F5 RDI (segment and end-to-end) - F5 loopback (segment and end-to-end) - Resource Management - Performance Management - Continuity Check - Security The ingress PE SHOULD be able to generate an F5 AIS upon reception of a corresponding F4 AIS or lower layer defect (such as LOS). The egress PE SHOULD be able to generate an F5 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port). If the ingress PE cannot support the generation of OAM cells, it MAY notify the egress PE using a Pseudo Wire specific maintenance mechanism to be defined. For example, the ingress PE MAY withdraw the Pseudo Wire (VC label) associated with the service. Upon receiving such a notification, the egress PE SHOULD generate the appropriate F5 AIS. 6.2 VPC Cell Relay Service The VPC service is defined by mapping a single VPC (VPI) to a Pseudo Wire. As such it emulates as Virtual Path cross-connect across the PSN. All VCCs belonging to the VPC are carried transparently by the VPC service. This service MUST use the cell mode encapsulation defined in section 6.4. The egress PE may choose to apply a different VPI other than the one that arrived at the ingress PE. The egress PE MUST choose the outgoing VPI based solely upon the Pseudo Wire header. As a VPC service, the egress PE MUST NOT change the VCI field. The VPC cell relay service is REQUIRED. 6.2.1 OAM Cell Support When configured for a VPC cell relay service, both PEÆs SHOULD act as a VP cross-connect in accordance with the OAM procedures defined in [5]. Brayley, et al. Expires April 2002 [Page 9] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 The PEs SHOULD be able to pass the following OAM cells transparently: - F4 AIS (segment and end-to-end) - F4 RDI (segment and end-to-end) - F4 loopback (segment and end-to-end) - F5 AIS (segment and end-to-end) - F5 RDI (segment and end-to-end) - F5 loopback (segment and end-to-end) - Resource Management - Performance Management - Continuity Check - Security The ingress PE MUST be able to generate an F4 AIS upon reception of a lower layer defect (such as LOS). The egress PE SHOULD be able to generate an F4 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port). If the ingress PE cannot support the generation of OAM cells, it MAY notify the egress PE using a Pseudo Wire specific maintenance mechanism to be defined. For example, the ingress PE MAY withdraw the Pseudo Wire (VC label) associated with the service. Upon receiving such a notification, the egress PE SHOULD generate the appropriate F4 AIS. 6.3 Transparent Port Cell Relay Service Transparent port encapsulation is used to emulate an ATM Port-to- Port connection over a PSN. This service is useful when one desires to connect two CEs without interfering at the VPC or VCC layer. The ingress PE SHOULD discard any idle/unassigned cells received from the ingress ATM port, and map all other received cells to a single Pseudo Wire. This service MUST use the cell mode encapsulation defined in section 6.4. The egress PE SHOULD not change the VPI, VCI, PTI, or CLP bits when it sends these cells on the egress ATM port. This service SHOULD appear as a Layer 1 service (such as SONET/SDH) to CE devices. However, the service provider may benefit from increased transport efficiency due to statistical multiplexing. The transparent port cell relay service is OPTIONAL. 6.3.1 OAM Cell Support Brayley, et al. Expires April 2002 [Page 10] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 This service is completely transparent to the F4 and F5 OAM layer. The PEs MUST pass all OAM and resource management cells. If the ingress PE detects a physical layer defect (such as LOS) it SHOULD be able to notify the egress PE via a mechanism specific to the Pseudo Wire in use. When it receives such a notification, the egress PE SHOULD propagate the failure (such as sending a SONET Line AIS). If the ingress PE cannot support the generation of OAM cells, it MAY notify the egress PE using a Pseudo Wire specific maintenance mechanism to be defined. For example, the ingress PE MAY withdraw the Pseudo Wire (VC label) associated with the service. Upon receiving such a notification, the egress PE SHOULD generate the appropriate physical layer AIS. 6.4 Cell Mode Encapsulation The encapsulation defined in this section is used for all cell relay services. The cell mode does not involve any higher layer AAL processing such as AAL5 segmentation and reassembly. The cell mode MUST support the encapsulation of a single ATM cell into a Pseudo Wire PDU. For increased transport efficiency, the ingress PE SHOULD be able to encapsulate multiple ATM cells into a Pseudo Wire PDU. The ingress and egress PE SHOULD agree to a maximum number of cells in a single Pseudo Wire PDU. This agreement may be accomplished via a Pseudo Wire specific signaling mechanism or via static configuration. 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 word (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI | VCI | PTI |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM Payload (48 octets) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPI | VCI | PTI |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM Payload (48 octets) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Brayley, et al. Expires April 2002 [Page 11] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 Figure 4: trunk mode encapsulation The ATM control word is defined in section 5.1. It use 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 should be set to 0 upon transmission and ignored upon receipt. 7 Frame Based ATM Services 7.1 AAL5 Payload VCC Service The AAL5 payload VCC service defines a mapping between the payload of an AAL5 VCC and a single Pseudo Wire. Therefore, it requires ATM segmentation and reassembly support on the PE. The AAL5 payload VCC service is designed to be more efficient than the VCC cell relay service. The AAL5 payload VCC service is OPTIONAL. Even the smallest TCP packet requires two ATM cells when sent over AAL5 on a native ATM device. It is desirable to avoid this padding on the Pseudo Wire. Therefore, once the ingress PE reassembles the AAL5 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer then inserts the resulting payload into a Pseudo Wire PDU. The egress PE MUST regenerate the PAD and trailer before transmitting the AAL5 frame on the egress ATM port. This service does allow the transport of OAM and RM cells, but does not attempt to maintain the relative order of these cells with respect to the 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, followed by the AAL5 payload. Therefore, the AAL5 payload VCC service may not be suitable for some ATM applications that require strict ordering of OAM cells (such as performance monitoring and security applications). The AAL5 payload service encapsulation is shown below. Brayley, et al. Expires April 2002 [Page 12] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Rsvd |E|C|U| Length | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM cell or AAL5 CPCS-SDU | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: AAL5 payload service encapsulation The AAL5 payload service encapsulation requires the ATM control word. The Flag bits are described below. * T (Transport type) bit Bit (T) of the control word indicates whether the packet contains an ATM cell or an AAL5 payload. If T = 1, the packet contains an ATM cell, encapsulated according to the VCC cell relay encapsulation of section 6.4. If not set, 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 OAM 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 traffic is being transported, the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. Brayley, et al. Expires April 2002 [Page 13] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 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. 7.1.1 OAM Cell Support Similar to the VCC cell relay service, both PEs SHOULD act as a VC switch in accordance with the OAM procedures defined in [5]. The PEs SHOULD be able to pass the following OAM cells transparently: - F5 AIS (segment and end-to-end) - F5 RDI (segment and end-to-end) - F5 loopback (segment and end-to-end) - Resource Management - Continuity Check Because this service does not guarantee the original OAM cell position within the AAL5 composite cells, the following cell types are discarded by the ingress PE: - Performance Management - Security The ingress PE SHOULD be able to generate an F5 AIS upon reception of a corresponding F4 AIS or lower layer defect (such as LOS). The egress PE SHOULD be able to generate an F5 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port). If the ingress PE cannot support the generation of OAM cells, it MAY notify the egress PE using a Pseudo Wire specific maintenance mechanism to be defined. For example, the ingress PE MAY withdraw the Pseudo Wire (VC label) associated with the service. Upon receiving such a notification, the egress PE SHOULD generate the appropriate F5 AIS. 7.2 AAL5 Transparent VCC Service Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC service is intended to be more efficient than the VCC cell relay service. However, the AAL5 transparent VCC service carries the entire AAL5 CPCS-PDU, including the PAD and trailer. This service supports all OAM cell flows by using a fragmentation procedure that ensures that OAM cells are not repositioned in respect to AAL5 composite cells. The AAL5 transparent VCC service is OPTIONAL. Brayley, et al. Expires April 2002 [Page 14] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Rsvd|FRG|E|C| Rsvd | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | ATM cell or AAL5 CPCS-PDU | | (n * 48 bytes) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: AAL5 transparent service encapsulation The first octet following the Pseudo Wire Header carries control information. * T (Transport type) bit Bit (T) of the control word indicates whether the packet contains an ATM cell. If T = 1, the packet contains an ATM cell, encapsulated according to the VCC cell relay encapsulation of section 6.4. If T = 0, the PDU contains an AAL5 CPCS-PDU or CPCS-PDU fragment. The ability to transport a single ATM cell is intended to enable OAM functionality for the VCC. * FRG (Fragmentation) Bits This field is used to support the fragmentation functionality described later in this section. - 00 Continuation of Message - 01 End of Message - 10 Beginning of Message - 11 Single Segment Message (Beginning and End of Message) * 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 CPCS-PDU or CPCS-PDU fragment is set to 1, or if the EFCI bit of the single ATM cell to be transported in the Pseudo Wire PDU 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 CPCS-PDU or CPCS-PDU fragment to the value contained in this field. Brayley, et al. Expires April 2002 [Page 15] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 * 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 CPCS-PDU or CPCS-PDU fragment are set to 1, or if the CLP bit of the single ATM cell that is to be transported in the Pseudo Wire PDU 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 or CPCS-PDU fragment to the value contained in this field. The payload consists of a complete AAL5 CPCS-PDU, including the AAL5 padding and trailer or CPCS-PDU fragment. 7.2.1 OAM Cell Support When configured for the AAL5 transparent VCC service, both PEÆs SHOULD act as a VC switch, in accordance with the OAM procedures defined in [5]. The PEs SHOULD be able to pass the following OAM cells transparently: - F5 AIS (segment and end-to-end) - F5 RDI (segment and end-to-end) - F5 loopback (segment and end-to-end) - Resource Management - Performance Management - Continuity Check - Security The ingress PE SHOULD be able to generate an F5 AIS upon reception of a corresponding F4 AIS or lower layer defect (such as LOS). The egress PE SHOULD be able to generate an F5 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port). If the ingress PE cannot support the generation of OAM cells, it MAY notify the egress PE using a Pseudo Wire specific maintenance mechanism to be defined. For example, the ingress PE MAY withdraw the Pseudo Wire (VC label) associated with the service. Upon receiving such a notification, the egress PE SHOULD generate the appropriate F5 AIS. 7.2.2 Fragmentation Brayley, et al. Expires April 2002 [Page 16] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 The ingress PE may not always be able to reassemble a full AAL5 frame. This may be due to the AAL5 PDU exceeding the Pseudo Wire MTU or when OAM cells arrive during reassembly of the AAL5 PDU. In these cases, the AAL5 PDU shall be fragmented. In addition, fragmentation may be desirable to bound ATM cell delay. If no fragmentation occurs, then the FRG bits are set to 11 (SSM, Single Segment Message). When fragmentation occurs, the procedures described in the following subsections shall be followed. 7.2.2.1 Procedures in the ATM-to-MPLS Direction The following procedures shall apply while fragmenting AAL5 PDUs: Fragmentation shall always occur at cell boundaries within the AAL5 PDU. For the first fragment, the FRG bits shall be set to 10 (BOM, Beginning Of Message). For the last fragment, the FRG bits shall be set to 01 (EOM, End Of Message). For all other fragments, the FRG bits shall be set to 00 (COM, Continuation Of Message). 7.2.2.2 Procedures in the MPLS-to-ATM Direction The 3-bit PTI field of each ATM cell header is constructed as follows: The most significant bit is set to 0, indicating a user data cell. The middle bit is set to the E bit value of the fragment. The least significant bit is set to 1 for the last ATM cell of a fragment where the FRG bits are 01 (EOM) or 11(SSM); otherwise this bit is set to 0. 8 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. Brayley, et al. Expires April 2002 [Page 17] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE receives an ILMI message indicating that the ATM service (VCC or VPC) is down, it MAY use a Pseudo Wire specific mechanism to notify the egress PE of the ATM service status. For example, a PE using an MPLS based Pseudo Wire may withdraw its advertised VC label. When receiving such a notification, the egress PE MAY use ILMI to signal the ATM service status to its attached CE. 9 QoS considerations TBD. 10 Pseudo-Wire specific requirements 10.1 MPLS requirements 10.2 L2TP requirements 10.3 IP requirements 11 Security Considerations This draft does not introduce any new security considerations to IP, L2TP or MPLS. 12 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 13 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] "Frame Relay / ATM PVC Service Interworking Implementation Agreement (FRF.8.1)", Frame Relay Forum 2000. [4] "Frame Based ATM over SONET/SDH Transport (FAST)," ATM Forum 2000. [5] ITU-T Recommendation I.610 (February 1999): B-ISDN operation and maintenance principles and functions [6] IETF draft-ietf-pwe3-requirements-00.txt, work in progress, (17 May 2001): Requirements for pseudo Wire Emulation Edge-to- Edge (PWE3) Brayley, et al. Expires April 2002 [Page 18] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 [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 14 Acknowledgments 15 Authors' Addresses Jeremy Brayley Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205 Email: jbrayley@laurelnetworks.com Gerald de Grace Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205 Email: gdegrace@laurelnetworks.com John Shirron Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205 Email: jshirron@laurelnetworks.com Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 Email: nna@level3.net Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Andy.Malis@vivacenetworks.com Vinai Sirkay Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Vinai.Sirkay@vivacenetworks.com Jayakumar Jayakumar Cisco Systems, Inc. 225, E.Tasman, MS-SJ3/3, Brayley, et al. Expires April 2002 [Page 19] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 San Jose, CA, 95134 Email: jjayakum@cisco.com Durai Chinnaiah Cisco Systems, Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA, 95134 Email: dchinnai@cisco.com Dan Tappan Cisco Systems, Inc. 50 Apollo Drive Chelmsford, MA, 01824 Email: tappan@cisco.com Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 Email: erosen@cisco.com Rick Wilder Masergy Communications 2901 Telestar Ct. Falls Church, VA 22042 Email: rwilder@masergy.com Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 Email: d@mazunetworks.com Thomas K. Johnson Litchfield Communications, Inc. 76 Westbury Park Rd. Watertown, CT 06795 Email: tom_johnson@litchfieldcomm.com Chris Liljenstolpe Cable & Wireless 11700 Plaza America Drive Reston, VA 20190 Email: chris@cw.net John Rutemiller Marconi Networks 1000 Marconi Drive Warrendale, PA 15086 Email: John.Rutemiller@marconi.com Giles Heron Brayley, et al. Expires April 2002 [Page 20] Internet Draft draft-brayley-pwe3-atm-service-00.txt September 2001 PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom Tel.: +44 7880 506185 Email: giles@packetexchange.net Laura Dominik Qwest Communications, Inc. 600 Stinson Blvd. Minneapolis, MN, 55413 Email: ldomini@qwest.com Brayley, et al. Expires April 2002 [Page 21]