Network Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: April 2004 David Watkinson Alcatel Andrew G. Malis Tellabs October 2003 Extended MPLS/PW PID draft-aissaoui-extended-pid-01.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. 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 draft proposes the extension of the proposed MPLS/PW PID to include the identification of user protocols and multiple control plane protocols carried in a PW or MPLS LSP. Table of Contents Status of this Memo.............................................1 Abstract........................................................1 Table of Contents...............................................1 1 Conventions used in this document.............................2 2 Introduction..................................................2 Aissaoui, et al. Expires April 2004 [Page 1] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 3 Extended MPLS/PW PID..........................................3 3.1 Structure of the Extended MPLS/PW PID......................4 3.2 User-Plane Protocol Identification Details.................4 4 Signaling of the extended MPLS/PW PID.........................5 5 Security Considerations.......................................5 6 Intellectual Property Disclaimer..............................6 7 Appendix A: Application of the Extended MPLS/PW PID to Layer 2 interworking....................................................6 7.1 Interworking Considerations................................8 7.2 Application of the Extended MPLS/PW PID to MPLS/PW OAM.....9 8 References....................................................9 9 Acknowledgments..............................................10 10 Authors' Addresses..........................................10 11 Full Copyright Statement....................................11 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 Introduction There has been much discussion in the PWE3 and MPLS working group mailing lists about the concept of MPLS or PW protocol identifier (PID). A number of applications for the MPLS/PW PID have been identified: a. The first one has to do with the IP aliasing issue [1]. In networks where load balancing schemes such as ECMP are used, the first nibble immediately following the bottom of the label stack may infer a IPv4 or IPv6 if its value is 4 or 6. Some ECMP implementations include this nibble in the hashing mechanism and may attempt to process further information beyond this nibble if the packet is mistaken for an IP packet. It is therefore required that non-IP payloads not to infer these two values. In the specific case of PWE3 applications, this issue is addressed by forcing the first nibble of the generic control word or of the preferred control word to a value of zero [1]. However, the SONET PW control word [2] does not comply with this requirement. The SONET encapsulation addresses this issue by preceding the SONET control word with a MPLS/PW PID to disambiguate its payload from an IP packet. b. The second one has to do with the ability to identify in PE, MPLS or PW OAM messages, such as Y.1711 [3], LSP-Ping [4], or VCCV [5]. Y.1711 messages are MPLS control packets, while LSP- Ping and VCCV are IP control packets. All can be inserted in a non-IP LSP in the case of PWE3 applications. A PE can make use Aissaoui, et al. Expires April 2004 [Page 2] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 of the MPLS/PW PID to indicate to the remote PE that the payload is an OAM packet without the need for a special label value. c. The third one is about making sure that a MPLS or a PW OAM packet follows exactly the same path as the user traffic if ECMP or similar load sharing mechanisms are used in the network. This is fairly important since the whole idea of OAM packet is to check the sanity and to troubleshoot the path user packets follow through the network. The currently proposed MPLS or PW OAM messages rely on a reserved label value to carry these messages. For example, LSP-Ping makes use of the router alert label value while Y.1711 OAM makes use of the OAM alert label value. In both cases, another label is pushed into the stack and thus the hashing algorithm of some ECMP implementations may cause the OAM packet to follow a different path from the user packet. If a MPLS/PW PID is used instead of a special label value, this problem can be resolved. A proposal for MPLS/PW PID to address this issue was made in draft-allan- mpls-pid-00.txt [6]. This draft proposes to extend the use of the MPLS/PW PID to identify user plane protocols carried in the LSP/PW payload. The main application is interworking of different link layers over a MPLS network, where each data link layer is terminated locally in a PE. The MPLS/PW PID allows the use of a single multiprotocol PW between any two user sites. The issues that are resolved by this method are explained in Appendix A. Appendix A also discusses the use the MPLS/PW PID to identify different types of OAM messages in a PW in such a way to address issues (b) and (c) above. 3 Extended MPLS/PW PID The proposed structure of the MPLS/PW PID is compatible with the MPLS payload type identifier in the PWE3 architecture document [1]. Furthermore, it is compatible with RFC 2684 (Multiprotocol over ATM), RFC 2427 (Multiprotocol over Frame Relay), and RFC 2878 (Bridging over PPP). Support for this format of the PID is only needed when there are multiple protocol types being transmitted over the same PW. It is unnecessary when there is a single protocol even if this single protocol multiplexes other protocols. When only partial support is provided for this PID, the handling of multiple alternatives referred to in section 3.2 should be examined. Aissaoui, et al. Expires April 2004 [Page 3] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 3.1 Structure of the Extended MPLS/PW PID The structure of the proposed MPLS/PW PID is shown in Figure 1: 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 | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd. = reserved for future use (== 0) PA = protocol authority for the user plane or the control plane protocol ID 0 = PPP DLL. Reserved for MPLS/PW control protocol identification. 1 = ISO NLPID (other than 0x80) 2 = IP protocol number 3 = Ethertype 4 = SNAP (ISO NLPID=0x80, e.g., IEEE 802.1 MAC type) 5-15 = reserved Protocol ID = Protocol ID following the format defined by the protocol authority identified in PA. Figure 1: Extended MPLS/PW PID Structure 3.2 User-Plane Protocol Identification Details The user plane encapsulation follows the procedures in the NLPID/SNAP encapsulation in RFC 2427 (Multiprotocol over Frame Relay). Where there are multiple alternatives to identify a specific protocol, the use of the representation with the lowest PA possible is required. For example, an IP datagram is represented using PA=1 and an ISO NLPID=0xCC. PA=1: ISO NLPID value other than 0x80 (32 bits) 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 |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following ISO NLPID values are supported using this configuration: 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xCC IP 0xCF PPP PA=2, IP protocol number (32 bits) Aissaoui, et al. Expires April 2004 [Page 4] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 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=2 | IP Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PA=3: Ethertypes (32 bits) 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=3 | Ethertype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PA=4: SNAP protocols such as 802.1 MAC types and private protocols (64 bits) 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=4 | NLPID=0x80 | OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI (cont'd) | PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IEEE 802.1 bridged protocols are carried in the MPLS or PW payload using PA=4 and the 802.1 organization code of 0x00-80-C2 in the OUI field in the SNAP header. The following are the PID field values used to identify the different bridged protocols: with preserved FCS w/o preserved FCS Media ------------------ ----------------- -------------- 0x00-01 0x00-07 802.3/Ethernet 0x00-02 0x00-08 802.4 0x00-03 0x00-09 802.5 0x00-04 0x00-0A FDDI 0x00-0B 802.6 0x00-0D Fragments 0x00-0E BPDUs as defined by 802.1(d) or 802.1(g) 0x00-0F Source Routing BPDUs 4 Signaling of the extended MPLS/PW PID This section is for further study. 5 Security Considerations This draft does not introduce any new security considerations to MPLS. Aissaoui, et al. Expires April 2004 [Page 5] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 6 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 7 Appendix A: Application of the Extended MPLS/PW PID to Layer 2 interworking Note: this appendix is not intended to be part of the specification of the MPLS/PW PID. It is only provided to highlight an application of the MPLS/PW PID. The content of this appendix will be moved to a separate draft in the next revision of this draft. Figure 2 shows an example of interworking of different link layers over MPLS. |CE1|--FR--|PE1|----MPLS----|PE2|--Ethernet--|CE2| \ / \ / \ / |PE3| | ATM | |CE3| Figure 2: Interworking of different link layers over MPLS Each AC can carry multiple higher layer protocols. This type of interworking can be achieved in three different ways. Each method is valid and has its own advantages and disadvantages. 1. Extend one link layer to the remote PE: for example, the ATM link layer between CE3 and PE3 in Figure 2 can be extended to PE2 using the PWE3 ATM-MPLS encapsulations [9]. In PE2, the ATM PW is terminated and the corresponding ATM AAL5 payload is reconstructed. Then ATM and Ethernet link layers are interworked and the corresponding PID fields are translated. The same thing can be done for the FR link between CE1 and PE1 using a FR PW towards PE2. Note that extending the Ethernet link layer makes only sense if it is done all the way to the ATM and FR CEs using a bridged encapsulation over the FR and ATM links, and Ethernet PWs between the PEs. Otherwise, PE1 and PE3 will need to insert a (fake) MAC address for the FR and ATM interfaces on CE1 and CE3 in order to communicate with CE2. Aissaoui, et al. Expires April 2004 [Page 6] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 This method has the advantage of reusing existing PW encapsulations specified in the PWE3 working group. It also simplifies the interworking with MPLS since it does not require the identification of the higher layer protocols carried in an AC. However, it makes the assumption that a PE will need to terminate multiple L2 over MPLS encapsulations even if it does not support those L2 interface types. For example, PE2 might only have Ethernet and MPLS interfaces and not ATM interfaces. In order to use this method, it will need to terminate and process ATM PWs as specified in [9]. 2. Set up multiple pseudo-wires for each AC: This method is described in [8]. In this case, each link layer is terminated locally in a PE which inspects each packetÆs PID to select the PW dedicated to each protocol type. Therefore, multiple PWs need to be set up for each AC. In the case where IP packets are routed over the AC while all other protocols are bridged over the AC, this method reduces to the set up of 2 parallel pseudo-wires for each AC: an IP PW and an Ethernet PW. This method has the advantage of using the current PW model of inferring the protocol carried in the PW from the label value. In other words, each PW carries only one protocol type. The disadvantage of this method is that it requires the association of multiple PWs to a single AC. This is a change to the current forwarding behavior of a PW. That is, the traffic received on a AC is forwarded over a PW based on the attachment circuit and the PID in the link layer encapsulation. There are also cases where one wants to avoid splitting the path of the carried protocols. For example, the CE in Figure 2 could be a device of another service provider who runs IS-IS as its IGP while the rest of the traffic is IP. In normal operation, a failure of the datapath is detected by the IS-IS routing plane since routing packets follow the same path as user packets. If the IP PW fails while the IS-IS PW is still up, there is no way to let the IS-IS routing know about the failure except by tearing down the IS-IS PW. The tearing down of a group of PWs when one of them fails is not desirable for other types of user protocols who do not have such kind of dependency. 3. Set up a multiprotocol PW and translate the PID: In this method, each link layer is terminated locally in a PE which inspects each received packet in an AC and translates the link layer PID into a PW PID. The PW PID has the format proposed in Section 3 of this document. Aissaoui, et al. Expires April 2004 [Page 7] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 This method allows the creation of a single multiprotocol PW to carry all protocols in an AC. Consider the example of the traffic between CE1 and CE2 in Figure 2. The CE device could belong to a service provider running IS-IS as its IGP. The interworking here is between an Ethernet interface and an rfc2427 routed FR DLCI with IP and ISIS routing traffic. The ISIS routing traffic can be carried over the same PW as the IP traffic by using an extended PID with PA=1 and NLPID=0x83. The NLPID is interworked to 802.3 LLC on the Ethernet side of the PW by adding the appropriate LLC of FEFE03 using the same mapping as defined in FRF 8.1 [10]. This method has the advantage of requiring a single PW to carry multiple user protocols over MPLS. It maintains the same path for both user and control plane protocols of the customer of the network. Finally, it provides a consistent operation with existing FR-ATM service interworking deployments. The disadvantage of this method is that the PE needs to inspect the received traffic on a PW packet by packet in order to translate the PID. Note however that the PW forwarding paradigm is not changed. Forwarding is still based on the label and the attachment circuit for each direction respectively. PID translation can be viewed as part of payload manipulation. 7.1 Interworking Considerations Regardless of which of the 3 above methods is used to perform interworking of different link layers over MPLS, there are two orthogonal issues to resolve: a. Identification of multiple higher-layer protocols: When a CE multiplexes multiple protocols in a single AC, it indicates the protocol type in a protocol identifier (PID) field in the link layer encapsulation. For example, RFC 2684 specifies the format for this field for an ATM/AAL5 link layer. A PE examines the PID of each packet received in a AC to either select the PW dedicated to this protocol (method 2) or to translate the link layer PID into a PW PID(method 3). In the case of method 1, the PE performs a translation of the PID between two link layers, for instance ATM/AAL5 and Ethernet in the example above. b. L3 protocol dependency on the type of link layer: Consider again the example of IS-IS traffic and IP traffic carried between CE1 and CE2 in Figure 2. The operation of ISIS Aissaoui, et al. Expires April 2004 [Page 8] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 over a PW can treat the link as a broadcast link or a point-to- point link. When it is point-to-point (i.e., only one CE device on the Ethernet end), the procedures in draft-ietf-isis- igp-p2p-over-lan [11] will apply. When it is broadcast, there can be multiple CE routers on the Ethernet AC. The preferred choice in this particular case is to change the FR AC to bridged encapsulation and use an Ethernet PW. This will allow the FR attached CE (CE2) to properly participate when presented with packets with the three multicast MAC addresses AllISs, AllL1ISs, and AllL2ISs. If the FR AC is not or cannot be changed to bridged encapsulation, the Ethernet attached PE will need to assume that all ISIS packets received across the PW should be prepended with the AllISs destination MAC or dig into the packet to determine the MAC to use based on the packet type. The procedures for ARP Mediation [12] need to be applied to determine a source MAC address. 7.2 Application of the Extended MPLS/PW PID to MPLS/PW OAM In order to address issues (b) and (c) in Section 2, the MPLS/PW PID can be used to identify an MPLS/PW OAM message carried in a PW. This is an alternative to the router alert label value in LSP Ping/VCCV and to the OAM alert label value in Y.1711 MPLS OAM. An IP control packet (LSP Ping/VCCV) inserted in a PW is identified by including the MPLS/PW PID just below the bottom of the MPLS label stack as explained in [5]. The PA field is set to 0 to indicate a MPLS/PW control plane protocol. The PID field is a PPP DLL and is set to the value indicating an IPv4 or IPv6 packet. Similarly, a Y.1711 OAM message is identified through a PA=0 and a specific value of the PPP DLL to be assigned by IANA. 8 References [1] Bryant, S., "The PWE3 Architecture", draft-ietf-pwe3-arch- 06.txt, October 2003. [2] Malis, A., et al.,öSONET/SDH Circuit Emulation over Packet (CEP)ö, draft-ietf-pwe3-sonet-01.txt, January 2003. [3] ôOAM Mechanisms for MPLS Networksö, ITU-T Recommendation Y.1711, November 2002. [4] Kompella, K., et al., ôDetecting MPLS Data Plane Livenessö, draft-ietf-mpls-lsp-ping-03.txt, June 2003. Aissaoui, et al. Expires April 2004 [Page 9] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 [5] Nadeau, T., et al., ôPseudo Wire (PW) Virtual Circuit Connection Verification (VCCV), draft-ietf-pwe3-vccv-00.txt, July 2003. [6] Allan, D., ôMPLS and IP PW Payload IDö, draft-allan-mpls-pid- 00.txt, April 2003. [7] Moreels, J., et al., ôMulti-protocol encapsulation over MPLSö, draft-moreels-multiproto-mpls-00.txt, October 2002. [8] Sajassi, A., et al., ôL2VPN Interworkingö, draft-sajassi- l2vpn-interworking-01.txt, March 2003. [9] Martini, L., et al.,ô Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networksö, draft-ietf-pwe3- atm-encap-03.txt, October 2003. [10] Frame Relay Forum, ôFRF 8.1 - Frame Relay / ATM PVC Service Interworking Implementation Agreementö, February 2000. [11] Shen, N., et al., ôPoint-to-point operation over LAN in link- state routing protocolsö, draft-ietf-isis-igp-p2p-over-lan- 03.txt, September 2003. [12] Shah, H., et al., ôARP Mediation for IP interworking of Layer 2 VPNö, draft-shah-ppvpn-arp-mediation-02.txt, July 2003. 9 Acknowledgments The authors like to acknowledge the contribution to this work by Jeremy de Clercq, John Fischer, Johan Moreels, Stefaan De Cnodder, Dimitri Papadimitriu, Dave Allan, and Stewart Bryant. Some of the drivers and applications for this draft were initially presented in draft-moreels-multiproto-mpls [7]. The idea of a Protocol Authority (PA) field was originally proposed in draft-allan-mpls- pid [6]. 10 Authors' Addresses Mustapha Aissaoui Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: mustapha.aissaoui@alcatel.com Matthew Bocci Alcatel Voyager Place, Shoppenhangers Rd Maidenhead, Berks, UK SL6 2PJ Email: matthew.bocci@alcatel.co.uk Aissaoui, et al. Expires April 2004 [Page 10] Internet Draft draft-aissaoui-extended-pid-01.txt October 2003 David Watkinson Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: david.watkinson@alcatel.com Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 phone:+1 408-383-7223 email:Andy.Malis@tellabs.com 11 Full Copyright Statement "Copyright (C) The Internet Society (2003). Except as set forth below, authors retain all their rights. 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 rights in submissions defined in the IETF Standards Process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS (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. Aissaoui, et al. Expires April 2004 [Page 11]