Internet Draft PWE3 Working Group Document: draft-balus-pwe3-ip-pseudowire-00.txt Category: Informational Expires: January 2005 ` Himanshu Shah Florin Balus Ciena Networks Mike Loomis Jeff Sugimoto Mircea Pisica Nortel Networks Infonet July 2004 IP Pseudowire Encapsulation draft-balus-pwe3-ip-pseudowire-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright(C) The Internet Society (2001). All Rights Reserved. Abstract This document specifies a PW encapsulation specific to IP packets, the IP Pseudowire, following the architectural principles defined in [PWE3 Architecture]. The IP Pseudowire is applicable mainly to the Ethernet to FR/ATM Interworking over MPLS (Routed mode) solution, described in [ARP Mediation], double-sided IWF. It enables the usage of PW OAM tools while offering support for preserving the Florin et.al Expires Jan 2005 Page 1 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 characteristics of the end-to-end L2 service. The proposed solution addresses the case of an MPLS backbone running ECMP so that the IP and PW OAM packets follow the same path throughout the backbone. Table of Contents 1. Conventions used in this document.............................2 2. Introduction and Requirements.................................2 3. Reference Model...............................................3 4. Support for PW OAM............................................4 5. IP PW Encapsulation...........................................4 6. Support for non-IP payload....................................6 7. Signaling of the IP PW........................................6 8. Security Considerations.......................................7 9. Acknowledgements..............................................7 10. Intellectual Property Rights Notices..........................7 11. References....................................................7 12. Editor's Address..............................................8 1. Conventions used in this document The keywords "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. Introduction and Requirements Legacy ATM/FR VPNs are sold currently backed by strong SLAs. When introducing PWs as part of the service, it is important for the Service Providers to maintain the overall service characteristics. [ARP Mediation] discusses different options for Ethernet to FR/ATM Service Interworking over MPLS (Routed mode). One of the solutions suggested for MPLS transport is to use the IP/MPLS encapsulation as defined in [RFC 3032]: i.e. the Attachment Circuits (ACs) are terminated at each PE and just the customer IP payload is carried transparently throughout the backbone using a two label stack. In this context it is important to note that the service provided end-to-end is required to preserve the operational characteristics of a layer 2 service: e.g. PE devices are not participating in customer's IP addressing or routing, the VC label is mapped against a Layer 2 FEC, OAM and QoS are driven by the characteristics of the Attachment Circuits... Balus & Loomis Page 2 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 One consequence is that the Service Provider cannot employ any IP OAM mechanisms related to customer IP Payload as in the IP VPN solution described in [RFC2547]. An ideal OAM solution will preserve fate sharing between data and OAM probes without requiring knowledge of specific customer flows to properly align with the desired operational characteristics of the service. This document specifies a PW encapsulation specific to IP packets, the IP Pseudowire (IP PW), following the architectural principles defined in [PWE3 Architecture]. The new encapsulation enables the use of PW OAM tools already defined in [VCCV] while offering the mechanisms for preserving the characteristics of the end-to-end L2 service. This provides an efficient transport of IP PDUs between unlike ACs in environment where ECMP is deployed but the lack of determinism of ECMP, and diagnostic complexity is not desired for this specific service. The document describes also how the proposed solution addresses the case of an MPLS backbone running ECMP so that the data and OAM packets follow the same path throughout the backbone. For the initial version of the draft the focus is on defining the IP PW encapsulation and signaling concepts as they apply to Layer 2 Service Interworking over MPLS, routed mode. 3. Reference Model The following diagram represents the reference model used to describe the services emulated by the IP PW, based on the concepts outlined in [PWE3 Architecture]. |<------------- Emulated L2 Service -------------->| | | | |<----- IP Pseudo Wire ----->| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V(IP/)X AC +----+ +----+(IP/)Y AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|..........IP PW1............|----------| | | CE1 | | | | | | | | CE2 | | |----------|..........IP PW2............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | native X service native Y service Figure 1: PWE3 IP PW Network Reference Model Balus & Loomis Page 3 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 In figure 1, X and Y represent two different types of Attachment Circuits, both supporting an IP payload. An IP PW is used to provide PSN transport between the two unlike ACs. It is important to note as a general rules that for the direction CE1 to CE2 just the incoming PE1 should map all the IP/X frames to IP/PW encapsulation described in section 5. The rest of the frame types MUST be discarded with the exceptions noted in section 7. Same is valid in the reverse direction (CE2->CE1) on PE2. In this version of the document we will focus our discussion on the following three cases of (X,Y) combinations: (Ethernet,ATM), (Ethernet,FR) and (FR,ATM). Other combinations are to be included at a later phase. Note that IP over ATM, FR encapsulations are defined in the following standard documents: [RFC2684] for ATM, [RFC2427] for FR. 4. Support for PW OAM [VCCV] defines a set of OAM tools (i.e. Ping, BFD) to be used for any type of PW encapsulation. One of the methods proposed to identify the associated OAM flows (see Section 4.1 of [VCCV]) suggests the use of the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA=0 |PPP DLL Proto Number=0021/0057 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: VCCV OAM Encapsulation The first nibble (0001) together with Protocol ID field is used to identify the OAM flows. This will enable, for the IP PW, the unrestricted use of OAM mechanisms common to other PW types. 5. IP PW Encapsulation This document introduces an OPTIONAL Control Word (CW) in front of the customer IP payload. This will address the requirements described in section 2, ensuring that the IP PW data packets follow the same path with the PW OAM ones. Also the presence of this CW allows for additional flexibility in maintaining the Layer 2 service characteristics. The IP PW Control Word follows the guidelines and the bit format described in [Martini L2CIRC] section 3.1 - see figure 3 below: 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 |B|F|D|0|RSV| RSVD | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Customer IP PDU | | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IP PW Control Word Balus & Loomis Page 4 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 The first 4 bits are reserved for further use. They MUST be set to (0000) upon transmitting and MUST be ignored upon reception. They ensure the IP PW data packets are differentiated from normal IP packets in the MPLS ECMP case. Or in other words they will follow the same path with the PW OAM ones. The next 4 bits (4 to 7) provide space for carrying protocol specific flags. In the IP PW case they are providing support for flexible protocol translation between the two unlike ACs: . Bit 4 (B) is used to signal Backward Congestion Indication (BCI): The ingress router, PE1 (see Figure 1), SHOULD copy the BECN field from the incoming Frame Relay header on an AC X = FR into this field. Also if the ingress PE1 experiences congestion in the PE1- >CE1 direction then it SHOULD set this bit to 1. If AC X is of Ethernet or ATM type and there is no local congestion in the backwards direction on PE1 the B bit MUST be set to 0. The receiving router, PE2, MAY choose to consider the indication and take action accordingly: e.g. perform rate adaptation. For PE 2 AC Y = FR, PE2 MUST generate a new BECN field based on the value of the B bit. In the latter scenario (AC Y = FR) the only case when the B = 1 will be when PE1 itself experiences congestion and marks the B bit: i.e. as ATM/Ethernet do not have an equivalent to BCI. . Bit 5 is used to signal Forward Congestion Indication (FCI): the ingress router PE1 SHOULD copy the equivalent congestion indication from the header portion specific to the L2 protocol running on local AC X: i.e. FECN for FR, EFCI for ATM. Also PE 1 SHOULD set it to 1 if it experiences local congestion in the downstream direction. If AC X = Ethernet and there is no local congestion in the forward direction on PE1 the F bit MUST be set to 0. For the case of a local AC Y = FR or ATM the receiving router, PE2 MUST generate a new congestion forward indication field based on the value of the F bit: FECN for FR and EFCI for ATM. . Bit 6 (D) is used to indicate the Discard Priority (DP): the ingress router, PE1, SHOULD mark this bit using the DP marking of the incoming frame on AC X using the following rules: . For X = FR the DE bit should be copied . for X = ATM - if one of the ATM cells from the reassembled IP (AAL5) frame had their CLP = 1 then the D bit MUST be set to 1. Otherwise the D bit must be set to 0. . Ethernet does not have a dedicated DP field but there are discussions in IEEE and MEF about using either the 802.1p or Balus & Loomis Page 5 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 the CFI bits to indicate the DP. A specific implementation MAY accommodate a certain DP scheme to mark the D bit accordingly. If that is not supported the D bit should be set to 0. . The D bit MUST be also marked based on the output of the Policer(s) related to AC X on PE1. The egress router, PE2, MUST generate on the egress AC Y a new DP field based on the value of the D bit copying it to the DE bit for AC Y = FR or to the CLP bits of all the ATM cells related to that specific IP payload. If a certain Ethernet scheme(802.1p/CFI) is used in order to mark DP in the case of AC Y = Ethernet the value of D bit should be copied to the appropriate Ethernet field. . Bit 7 is reserved and must be set to 0. The next 2 fields are reserved and MUST be set to 0 when transmitting. These fields were used (see [Martini L2CIRC] section 3.1) in some of the other, like-to-like PW encapsulations, to provide support, at PW layer for: . Fragmentation (to address MTU mismatch - see [FRAG]) . Padding (to address mismatch of the minimum payload) In the case of an IP PW the IP header could be used to address these issues: . MTU mismatch - via fragmentation of the IP payload . Minimum Payload size - via padding inside the IP payload 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 and a value of 0 is used to indicate an unsequenced packet - see [Martini L2CIRC] section. This Sequence number SHOULD be compliant with the rules defined in [Martini L2CIRC] see section 3.1.1 and 3.1.2. 6. Support for non-IP payload As a general rule PE1 and PE2 will discard the incoming non-IP payloads on ACs X and Y. Still in the case CE1 and CE2 are running IS-IS (non-IP Payload) the IP PW needs to be able to transport the payload between PE1 and PE2. We are proposing the use of the following encapsulation to achieve that with minimal changes to the encapsulation format used for OAM: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA=0 | PPP DLL Proto Number = 0023 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IP PW Encapsulation used for IS-IS where 0023 is the assigned PPP DLL Protocol Number for OSI - see [IANA PPP]. The Network Layer Protocol Identifier (NLPID),the first octet in each payload will discriminate between OSI Network Layer protocols: i.e. for IS-IS NLPID = 83. This format provides the advantage of re-using existing, well defined PPP code points. Also the scheme is extensible to address further needs. 7. Signaling of the IP PW A 15 bit quantity containing a value is used as part of the PWiD and Generalized Id FECs to identify the type of PWs - see [PWE3-CTRL] sections 5.1 and 5.2. Balus & Loomis Page 6 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 To signal the IP PW we propose the usage of the value 0x000b already assigned in [IANA PWE3]section 2 for IP Layer2 Transport. The negotiation of the control word complies with the procedure described in [PWE3-CTRL] section 5.4.2. No new TLVs, Interface parameters are required for now. 8. Security Considerations To be completed later. 9. Acknowledgements The authors would like to thank David Allan, Hamid Ould-Brahim, for their helpful discussions and feedbacks. 10. Intellectual Property Rights Notices. This document is being submitted for use in IETF standards discussions. 11. References [PWE3 Architecture] "PWE3 Architecture", draft-ietf-pwe3-arch- 07.txt, IETF work in progress, March 2004 [ARP Mediation] Shah, Himanshu "ARP Mediation for IP Interworking of Layer 2 VPN", draft-shah-l2vpn-arp-mediation-03.txt, IETF work in progress, October 2003 [RFC3032] "MPLS Label Stack Encoding" IETF RFC 3032 [2547] Rosen, E. Rekhter, Y., "BGP/MPLS VPNs", IETF RFC 2547, March 1999 [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", draft-ietf-pwe3-vccv-02.txt, February 2004 [RFC2427] RFC 2427, "Multiprotocol Interconnect over Frame Relay" [RFC2684] RFC 2684, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [Martini L2CIRC] Martini et.al. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", draft-martini- l2circuit-encap-mpls-07.txt, IETF Work in Progress, June 2004 [Martini L2TRANS] Martini et.al. "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-14.txt, IETF Work in Progress, June 2004 Balus & Loomis Page 7 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 [FR PW] Kawa et.al. "Frame Relay over Pseudo-Wires", draft-ietf- pwe3-frame-relay-02.txt, IETF Work in Progress, February 2004 [ATM PW] Martini et.al. "Encapsulation Methods for Transport of ATM Over IP and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt, IETF Work in Progress, April 2004 [PWE3-CTRL] Martini et.al. "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-07.txt, IETF Work in Progress, June 2004 [IANA PWE3] Martini, Townsley "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-04.txt ( work in progress), April 2004 [IANA PPP] IANA Point-to-Point Protocol Field Assignments, June 28,2004 http://www.iana.org/assignments/ppp-numbers 12. Editor's Address Florin Balus Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA e-mail: balus@nortelnetworks.com Himanshu Shah 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Mike Loomis Nortel Networks Billerica, MA Mircea Pisica Infonet Full copyright statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Balus & Loomis Page 8 draft-balus-pwe3-ip-pseudowire-00.txt Expires January 2005 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.