PWE3 Working Group Internet Draft Expires: April 2005 Himanshu Shah Florin Balus Ciena Networks Mike Loomis Jeff Sugimoto Nortel Networks Mustapha Aissaoui Alcatel Mircea Pisica Infonet October 2004 IP Pseudowire Encapsulation draft-balus-pwe3-ip-pseudowire-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes a PW encapsulation specific to IP packets, the IP Pseudowire, following the architectural principles defined in [PWE3 Architecture]. This proposal introduces an optional CW for IP encapsulation. Note that when the inclusion of a control word is not negotiated, the IP PW uses the encapsulation described in [RFC3032]. Balus et.al Expires Jan 2005 Page 1 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 Table of Contents 1. Conventions used in this document.............................2 2. Introduction and Requirements.................................2 3. Reference Model...............................................3 4. IP PW Encapsulation...........................................4 5. Support for PW OAM............................................5 6. Support for non-IP payload....................................6 7. Signaling of the IP PW........................................7 8. Security Considerations.......................................7 9. Changes from the previous version.............................7 10. Acknowledgements..............................................7 11. Intellectual Property Rights Notices..........................7 12. References....................................................7 13. Authors' Addresses............................................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 This document defines the encapsulation and the motivators for using an optional CW for IP pseudowire. In this model, the AC circuits are terminated at each PE, and only the IP payload is transported across the PSN using a PW header. Two solutions using the IP PW encapsulation are described in [ARP Mediation] and [IPLS]. Multi-hop pseudowire could be also another application for the concepts described in this draft. The requirements for an IP PW vary depending on the behavior expected from end user application, and sometimes by how much the layer 2 media characteristics were used to achieve said behaviour. For instance, deterministic path forwarding, connection tracing, discard priorities and congestion notifications are typical L2 attributes, which often benefit a native, end-to-end service encapsulated within it. In the context of an IP PW, these characteristics may need to be reflected to preserve current SLAs. Specifically concerning deterministic path forwarding in IP/MPLS networks, when no CW is used, the IP PW uses the encapsulation described in [RFC3032], virtually indistiguishable from the IP over MPLS encapsulation, mapped based on the IP FEC. Current ECMP algorithms used by the MPLS LSRs may perform deep packet inspection and loadshare the IP over MPLS packets based on the IP addresses from the customer IP header. As a result, when the CW is not present, the packets on an IP PW may be loadspread across multiple backbone paths compromising the deterministic path forwarding. In this scenario potential OAM packets (see [VCCV]) may be forwarded consistently on a different path than most of the IP PW packets. This could cause challenges for troubleshooting and operational changes to the network administrator looking to migrate their L2VPN networks to an IP PW Balus et.al Page 2 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 transport. Network operators that relied on L2 mechanisms to provide this functionality may expect to preserve this behavior in IP PWs. Similarly, some end user applications rely on native L2 congestion notifications or discard priority markings for QoS treatment or even SLA reporting. Clearly, not all end user applications using an IP PW will have an identical set of requirements. Typically an internet access service has less requirements from its layer 2 transport media, when compared to a SLA-based, L2VPN service. An IP PW must be flexible enough to satisfy the loose requirements of the basic application, but offer the optional tools to address the strict requirements of the more demanding one.These requirements typically include: ¸ Enable the use of PW in-band OAM with or without ECMP ¸ Distinguish an IP PW frame from a regular IP/MPLS frame for consistent forwarding of user frames in a PSN using ECMP ¸ The option to reflect important layer 2 service characteristics This document proposes an IP PW encapsulation that includes an optional IP control word. 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 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. 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 et.al Page 3 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 In figure 1, X and Y represent two Attachment Circuits, both upporting an IP payload. An IP PW is used to provide PSN transport between the two ACs. It is important to note as a general rules that for the direction CE1 to CE2 the ingress PE, PE1, should map all the IP/X frames to IP/PW encapsulation described in section 4. 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. 4. 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|FRG| Length | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Customer IP PDU | | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IP PW Control Word - The first 4 bits are reserved for further use. They MUST be set to (0000) upon transmitting. 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) MAY be used to provide flexible support for transport-specific treatments for any given AC type: . Bit 4 (B) used to signal Backward Congestion Indication (BCI) This bit could be used to alleviate possible congestion situation related to differences in speed between ACs located at the two sides of an IP PW: e.g. Ethernet/ATM AC X --> FR AC Y. . Bit 5 (F) used to signal Forward Congestion Indication (FCI) . Bit 6 (D) used to indicate the Discard Priority (DP) If the transmitting PE does not support the processing of the above flags, it MUST set them to 0. If the receiving PE does not support the Balus et.al Page 4 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 processing of the flags it MAY ignore them upon reception. . Bit 7 is reserved and must be set to 0. - FRG field (bits 8,9) MAY be used to provide support for PW Fragmentation to address MTU mismatch. The usage of these bits is compliant with the procedure described in [FRAG]. Note that the usage of PW fragmentation could be negotiated using the parameter id described in section 4 of [FRAG]. Alternatively, fragmentation at IP Layer could be used - see section 3 of [FRAG]. In the latter case the packet is fragmented at the ingress PE and reassembled just at the IP Destination device - i.e. the egress PE does not get involved. As such this option could be enabled by provisioning just at the ingress PE. - Length field (bits 10 to 15) MAY be used (see [Martini L2CIRC] section 3.1) in conjunction with the padding of short IP PW payloads (i.e. 40 Bytes) when the link layer protocol on the related PSN links requires a minimum frame length: i.e. minimum payload for Ethernet is 64 bytes. If the total length of the IP payload plus the CW (4 bytes) plus the 2 labels (8 bytes) is less than 64 bytes then the Length field indicates the total length of the L2 payload (i.e. IP payload+12 bytes). Otherwise the length field must be set to zero. The egress PE will remove the padding and it will restore the frame to its original size. Alternatively, the Length field from the IP header could be used to address this issue. In this case the padding will be removed just at the IP destination. - 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. This Sequence number SHOULD be compliant with the rules defined in [Martini L2CIRC] see section 3.1.1 and 3.1.2. 5. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: VCCV OAM Encapsulation The first nibble (0001) together with PPP DLL Protocol Number 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. Balus et.al Page 5 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 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 there could be exceptions from the above rule: e.g. if CE1 and CE2 are using IS-IS for routing protocol, the IP PW might be required to transport this non-IP payload between PE1 and PE2. To achieve the above goal, it is proposed to extend the PWE3 Payload Type Identifier defined in [PWE3-CW] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA=X | Payload Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IP PW Encapsulation used non-IP payload exceptions The value PA=0 is reserved for PW OAM messages (VCCV PING, BFD). Values other than zero are used to identify user packets which are not IP packet. For example, PA=1 (ISO protocol) and the corresponding ISO NLPID code points could be used to provide support for transporting IS-IS frames over an IP PW: 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| rsvd. | PA=1 |ISO NLPID=0x83 |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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. Changes from the previous version - Improved the Abstract and Introduction to clarify the goal of the draft - Switched section "Support for PW OAM" (now 5, previously 4) with "IP PW Encapsulation" (now 4, previously 5). - Comments in section 4: on the usage of BE(fragmentation) and Lenght bits - Changed the format in section 6 to allign to the newly proposed PTI Balus et.al Page 6 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 10. Acknowledgements The authors would like to thank David Allan, Hamid Ould-Brahim, for their helpful discussions and feedbacks. 11. Intellectual Property Rights Notices. This document is being submitted for use in IETF standards discussions. 12. 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 [IPLS] Shah,Himanshu "IP-Only LAN Service", draft-ietf-l2vpn-ipls-01.txt, IETF work in progress, May 2004 [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 [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 Balus et.al Page 7 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 [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 [RCF3032] RFC 3032 Rosen, et al., "MPLS Label Stack Encoding", January 2001 [PWE3-CW] Bryant-McPherson, "PWE3 Control Word" draft-bryant-mcpherson-pwe3-cw-00.txt, July 2004 12. Authors' Addresses Florin Balus Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA e-mail: balus@nortelnetworks.com Jeff Sugimoto Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA e-mail: sugimoto@nortelnetworks.com Mike Loomis Nortel Networks Billerica, MA Himanshu Shah 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Mircea Pisica Infonet Services Corporation Brussells, Belgium Mustapha Aissaoui Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: mustapha.aissaoui@alcatel.com Full copyright statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Balus et.al Page 8 draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Balus et.al Page 9