Internet Draft David Allan Document: draft-allan-mpls-pid-00.txt Nortel Networks Category: Standards Track April 2003 MPLS and IP PW Payload ID 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 (2003). All Rights Reserved. Abstract This memo defines an MPLS and PW payload ID. It describes how an MPLS payload ID may be used to address a number of issues associated with proprietary ECMP deployments. It describes how when used with PWs permits OAM and control protocols to be multiplexed with a PW. Sub-IP ID Summary [to be removed when published] WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Fits in the MPLS, and PWE3. WHY IS IT TARGETED AT THESE WGs This draft addresses a number of issues associated with instrumenting/controlling MPLS LSPs and PWs in general. Allan et.al Expires October 2003 Page 1 MPLS and IP PW Payload ID 1. Introduction A number of problems have arisen with MPLS due to the deployment of core LSRs that perform load sharing for TE link bundles or to implement ECMP in LDP networks. Load spreading preserves microflow ordering (in varying degrees of granularity) via hashing of some or all of the label stack, and if the first nibble of the payload suggests an IPv4 packet, may incorporate IP flow details as well. Load sharing means that OAM flows and diagnostic tools may not fate share with an LSP (including PWs). Use of reserved labels to distinguish flows may result in the flows having different forwarding behavior than the LSP of interest. Use of IP packets in non-IP LSPs may have different forwarding behavior than the LSP of interest. Load sharing implies that a defacto payload ID exists in the MPLS architecture that impacts the payload carrying ability of any given LSP. Under certain circumstances a payload may be misinterpreted as IPv4 packet and have forwarding adversely modified. This document describes an approach to providing an MPLS and IP PW payload ID such that: - multiprotocol over MPLS and/or PWs may be transported without being mis-interpreted by load sharing LSRs. This is primarily in the interest of explicitly associating OAM and control traffic with LSPs and/or PWs. - OAM flows may fate share with the LSP of interest in a load sharing environment. - An alternative approach to reserved labels is supported such that requisite functions may be provided without being impacted by load sharing. - Commonality of PW control words is exploited for both MPLS LSPs and non MPLS PWs. 2. MPLS and PW extended payload ID MPLS label stack encoding is defined in [RFC3032]. This draft defines the following extension to label stack encoding. When the 'S' bit indicating bottom of stack is set, the payload is examined and if the first nibble is 0x08, then the payload may be interpreted as an extended payload ID control word. (Note that this collides with the current version number assignment for the P Internet protocol (PIP) [RFC1621, RFC 1622], and may collide with other protocol formats, it remains to be seen if this is an issue). For non-MPLS PWs configured to use a control word that support the extended payload ID control word, the extended payload ID control word may be used interchangeably with the normal PW control word. The extended PW control word is distinguished via the first nibble 0x08 value. Allan Expires October 2003 Page 2 MPLS and IP PW Payload ID The format of the extended payload ID control word is common to both MPLS LSPs, and PWs (of any variety). The format is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0|A| rsvd. | PA | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: A = LSR or PE "Alert" Rsvd. = reserved for future use (== 0) PA = protocol authority for Protocol ID 0 = reserved 1 = IP protocol number 2 = IEEE Ethertype 3-15 = reserved Protocol ID = Protocol id of any payload following the extended payload ID control word. Implementations that support the extended payload ID control word MUST, at a minimum, be able to support ICMP echo request/reply [RFC 792] over IPv4 as payload. Originators of ICMP echo request messages use the any address in the non-routable 127./8 address range as a destination address. Originators of ICMP echo reply messages substitute their own PSN loopback address for the 127./8 when replying. 3. PW Applicability The extended payload ID control word allows protocols to be multiplexed with PWs and fate share with PW connectivity. This would include but not be limited to IP, GTTP [GTTP], Y.1711 [Y.1711] etc. When used with PWs, it would permit IP (or other protocol) packets to be carried over the PW in a manner opaque to deployed load spreading mechanisms. Therefore for ICMP PING, GTTP, Y.1711 or LSP- PING [LSP-PING] operations, PDUs will have common forwarding with the PW, and sufficient information is transported in the PW to permit a PSN return path to be employed. Normal procedure would be to insert an IP message into the PW (PID auth == IP PID, Protocol ID == 4 (IPinIP)[RFC1700]) which would be processed by the receiving PE. This also provides an alternate mechanism to use of the reserved label for Y.1711, PID to be assigned by IANA. Allan Expires October 2003 Page 3 MPLS and IP PW Payload ID Use of two-legged transactions without a network layer header is not explicitly precluded (PW return path). Support for the Extended payload ID control word may be signaled via use of the PWid FEC Element [PWESIG]. Bit 14 of the PW type field is used to indicate support for the Extended payload ID control word. 1 = supported 0 = NOT supported Alternately PW support for the Extended payload ID control word may be tested for in tunnels via use of ICMP ping in conjunction with the extended payload ID CW. 4. MPLS Applicability The extended payload ID control word allows protocols to be multiplexed with MPLS LSPs, and fate share with LSPs that do not have their payload considered as part of load spreading operations. This would include: - Load spreading based on the combination of incoming label and interface. - Load spreading based on hashing any portion of the label stack. If the depth of hashing is not configurable, the extended PID control word can only guarantee forwarding consistency when employed on non-MPLS payload bearing LSPs. But would NOT include: - LSPs where non-MPLS payload (such as IP packet headers) was considered when performing load spreading calculations. - Use of reserved labels (such as router alert) in conjunction with the Extended PID CW. The alert bit in the CW is provided as an alternative mechanism. When used with LSPs (subject to the caveats above), it would permit IP (or other protocol) packets to be carried over the LSP in a manner opaque to deployed load spreading mechanisms. Therefore for ICMP PING, Generic Tunnel Trace Protocol, Y.1711 or LSP-PING operations, PDUs will have common forwarding with the LSP. The specific scenarios addressed are when an RSVP-TE LSP has a non- IP L3PID, and use of Y.1711. Support for the Extended payload ID control word may be tested for in tunnels set up via BGP, RSVP-TE or LDP via use of ICMP ping. 5. MTU Issues The extended payload ID control word does not include a length field (nominally used to distinguish payload from padding when the PDU is below the minimum length for Ethernet). Allan Expires October 2003 Page 4 MPLS and IP PW Payload ID Protocols carried as payload with the extended PW control word must either always be padded to the Ethernet minimum frame size (e.g. Y.1711) or be self describing w.r.t. length (e.g. IPv4 [RFC791]). 6. Restrictions The extended PID SHOULD NOT be used with MPLS LSPs that are PHP'd. 7. References [GTTP] Bonica, R. et.al., "Generic Tunnel Tracing Protocol (GTTP) Specification", IETF Internet Draft, draft- bonica-tunproto-04.txt, February 2003 [LSP-PING] Kompella et.al., "Detecting Data Plane Liveness", IETF Internet Draft draft-ietf-mpls-lsp-ping-02.txt, September 2003 [PWESIG] Martini et.al., "Pseudowire Setup and Maintenance using LDP", Internet Draft draft-ietf-pwe3-control-protocol- 02.txt, February 2003 [RFC 791] Postel, J. (editor), "Internet Protocol", IETF RFC 791, September 1981 [RFC 792] Postel, J., "Internet Control Message Protocol", IETF RFC 792, September 1981 [RFC 1621] Francis, P., "Pip Near-term Architecture", IETF RFC 1621, May 1994 [RFC 1622] Francis, P., "Pip Header Processing", IETF RFC 1622, May 1994 [RFC 1700] Reynolds, J., Postel, J., "Assigned Numbers", IETF RFC 1700, October 1994 [RFC 3032] Andersson et.al., "LDP Specification", IETF RFC 3036, January 2001 [Y.1711] ITU-T Recommendation Y.1711 (2002), "OAM Mechanism for MPLS Networks" 8. Author's Address David Allan Nortel Networks Phone: 1-613-763-6362 3500 Carling Ave. Email: dallan@nortelnetworks.com Ottawa, Ontario, CANADA 9. Full Copyright Statement Allan Expires October 2003 Page 5 MPLS and IP PW Payload ID "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.