Network Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: December 2003 David Watkinson Alcatel Andrew G. Malis Tellabs June 2003 Extended MPLS/PW PID draft-aissaoui-extended-pid-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. 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 1 Conventions used in this document 2 2 Introduction 2 3 Relationship of PW Control Word to MPLS/PW PID 3 4 Extended MPLS/PW PID 5 4.1 Structure of the Extended MPLS/PW PID 5 4.2 User-Plane Protocol Identification Details 6 5 Signaling of the extended MPLS/PW PID 7 Aissaoui, et al. Expires December 2003 [Page 1] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 6 Security Considerations 7 7 Intellectual Property Disclaimer 7 8 References 7 9 Acknowledgments 8 10 Authors' Addresses 8 11 Full Copyright Statement 8 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 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 and it was suggested to precede the SONET control word with a MPLS/PW PID to disambiguate its payload from an IP packet [1]. 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 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 Aissaoui, et al. Expires December 2003 [Page 2] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 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. There are currently two proposals for the structure of the MPLS/PW PID to address the above applications. One is described in the PWE3 architecture document [1] and reuses the PPP DLL PID. It is referred to in [1] as MPLS payload identifier. The other one is described in draft-allan-mpls-pid [6] and adds the option to identify protocols of different standards organizations. This draft discusses the following aspects of the MPLS/PW PID: a. The relationship of the control word to the MPLS payload identifier defined in the PWE3 architecture document [1]. Specifically, it proposes an alternative structure in which the MPLS/PW PID follows the PW control word instead of preceding it. This is because the control word is essentially providing an adaptation layer to the PSN and may be required if PW fragmentation, length field, or sequencing are required for the user and/or OAM payloads carried in the MPLS packet. b. The extension of the use of the MPLS/PW PID to identify user plane protocols in addition to control plane protocols carried in the LSP/PW payload. The need for user plane protocol is identified in [7] and [8]. Two main applications are described. The first one is service interworking of different link layers over a MPLS network, where each data link layer is terminated locally in a PE. The second one has to do with aggregating existing ATM/DSL subscribers over an MPLS-enabled packet aggregation network [7]. c. The ability to identify multiple control plane protocols such as LSP-Ping/VCCV and Y.1711. 3 Relationship of PW Control Word to MPLS/PW PID Figure 1 illustrates the structure and position of the MPLS payload identifier, as proposed in the PWE3 architecture document [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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | Aissaoui, et al. Expires December 2003 [Page 3] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Control Word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PW CW and MPLS Payload Identifier In Figure 1, the MPLS payload identifier precedes the PW control word. This is because the intent is to allow PW encapsulations which do not comply with the generic or preferred control word to resolve the IP aliasing issue. Figure 2 illustrates an alternative proposal for the position of the optional extended MPLS/PW PID in a PW encapsulation. The generic or preferred control word must be used as explained in [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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Specified by PW Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload or Control Channel PID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Alternative Position of the MPLS Payload Identifier In this case, the PW control word precedes the MPLS/PW PID. This is the reverse order of what is currently proposed in the PWE3 architecture document [1]. This is because the control word is essentially providing an adaptation layer to the PSN and may be required if PW fragmentation, length field, or sequencing are required for the user and/or control channel (e.g., OAM) payloads carried in the MPLS packet. In PW encapsulations where the PW control word is optional, a control channel message (e.g., OAM message) can be sent with the MPLS/PW PID immediately following the bottom of the label stack. This is the case where both the user payload and the control channel payload meet the minimum length requirement of Ethernet and where sequencing is not an issue. This alternative structure satisfies all the applications described in Section 2. A consequence of this structure is that all PW encapsulations will require adhering to the generic or preferred PW control word in order to resolve the IP aliasing issue. All currently defined PW encapsulations conform to this, except for the SONET one Aissaoui, et al. Expires December 2003 [Page 4] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 [2]. The SONET draft team has chosen to use the structure in Figure 1 and not to alter the CW. Each of the above 2 alternatives has its advantages and disadvantages. This issue requires further investigation and discussion in the PWE3 working group. 4 Extended MPLS/PW PID The proposed structure of the MPLS/PW PID is compatible with the proposed MPLS payload type identifier in the PWE3 architecture document [1], and is a subset of the proposed MPLS PID in draft-allan- mpls-pid [6]. Furthermore, it is compatible with RFC 2684 (Multiprotocol over ATM), RFC 2427 (Multiprotocol over Frame Relay), and RFC 2878 (Bridging over PPP). The differences between this structure and the proposals in [1] and [6] are: a. Reserved the use of the PPP DLL PID in [1] for the identification of control plane protocols. This is an initial proposal as this issue requires further discussion. b. used a value of ô0001ö for the first nibble in the MPLS/PW PID as proposed in [1]. A value of ô1000ö was proposed in [6]. c. Removed the ôAlertö bit in the proposal in [6]. d. Added user plane protocol identification following the same procedures as in the NLPID/SNAP encapsulation in RFC 2427 (Multiprotocol over Frame Relay). 4.1 Structure of the Extended MPLS/PW PID The structure of the proposed MPLS/PW PID is shown in Figure 3: 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 control protocol identification. 1 = ISO NLPID (other than 0x80) 2 = IP protocol number 3 = Ethertype 4 = SNAP (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. Aissaoui, et al. Expires December 2003 [Page 5] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 Figure 3: Extended MPLS/PW PID Structure 4.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) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aissaoui, et al. Expires December 2003 [Page 6] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 | 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 5 Signaling of the extended MPLS/PW PID This section is for further study. 6 Security Considerations This draft does not introduce any new security considerations to MPLS. 7 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 8 References [1] Bryant, S., "The PWE3 Architecture", draft-ietf-pwe3-arch- 03.txt, June 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-02.txt, March 2003. Aissaoui, et al. Expires December 2003 [Page 7] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 [5] Nadeau, T., et al., ôPseudo Wire (PW) Virtual Circuit Connection Verification (VCCV), draft-nadeau-pwe3-vccv-00.txt, April 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 Acknowledgments The authors like to acknowledge the contribution to this work by Jeremy de Clercq, John Fischer, Johan Moreels, Stefaan De Cnodder, Dave Allan, and Stewart Bryant. 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 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. Aissaoui, et al. Expires December 2003 [Page 8] Internet Draft draft-aissaoui-extended-pid-00.txt June 2003 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 December 2003 [Page 9]