Requirements for MPLS Label Stack Indicators and Ancillary Data
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|Authors||Matthew Bocci , Stewart Bryant|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
MPLS Working Group M. Bocci Internet-Draft Nokia Intended status: Informational S. Bryant Expires: July 28, 2022 University of Surrey 5GIC January 24, 2022 Requirements for MPLS Label Stack Indicators and Ancillary Data draft-bocci-mpls-miad-adi-requirements-01 Abstract This draft specifies requirements for indicators in the MPLS label stack to support ancillary data that exists below the label stack. This work is the product of the IETF MPLS Open Design Team. Requirements are derived from a number of new proposals for additions to the MPLS label stack to allow forwarding or other processing decisions to be made, either by a transit or terminating LSR, based on application data that may be in or below the bottom of the label stack. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 28, 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Bocci & Bryant Expires July 28, 2022 [Page 1] Internet-Draft MIAD ADI Requirements January 2022 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. MPLS Ancillary Data Indicator Requirements . . . . . . . . . 4 3.1. General Requirements . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction There is significant interest in developing the MPLS data plane to address the requirements of new applications. These applications typically require the inclusion of ancillary data in the MPLS packet. This data may be encoded either in the label stack or below the bottom of the label stack. This data is then either intercepted and processed, or some other forwarding decision is taken by routers processing the packet. The ancillary data is added by the ingress LSR, and then makes use of mechanisms implemented by an intermediate or egress LSR that complies with the MPLS base architecture and potentially its extensions, including (but not limited to) [RFC3031], [RFC3032], [RFC6790]. This draft specifies requirements for indicators in the MPLS label stack to support these applications. 1.1. Terminology o Ancillary Data: Data relating to the MPLS packet that may be used to affect the forwarding or other processing of that packet, either at the LER or LSR. This data may be implicit (i.e. context-specific), encoded within the label stack (in-stack data), and/or after the bottom of the label stack (post-stack data). Bocci & Bryant Expires July 28, 2022 [Page 2] Internet-Draft MIAD ADI Requirements January 2022 o In-Stack Data: Any data within the MPLS label stack including the outer label and the bottom of stack (the label with the S-bit set). o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but before the first octet of the user payload. This document does not prescribe whether post-stack data precedes or follows any other protocol structure such as a control word or associated channel header (ACH). o Ancillary Data Indicator (ADI): A indicator in the MPLS label stack that ancillary data exists in this packet. It MAY also indicate the specific type of the ancillary data. 1.2. Background The MPLS architecture is specified in [RFC3031] and provides a mechanism for forwarding packets through a network without requiring any analysis of the packet payload's network layer header by intermediate nodes (Label Switching Routers - LSRs). Formally, inspection may only occur at network ingress (the Label edge router - LER) where the packet is assigned to a forwarding equivalence class (FEC). MPLS uses switching based on a label pushed on the packet to achieve efficient forwarding and traffic engineering of flows associated with the FEC. While originally used for IP traffic, MPLS has been extended to support point-to-point, point-to-multipoint and multipoint-to-multipoint layer 2 and layer 3 services. An overview of the development of MPLS is provided in [I-D.bryant-mpls-dev-primer]. A number of applications have emerged which require LSRs to make forwarding or other processing decisions based on inspection of the network layer header, or some other ancillary information in the protocol stack encapsulated deeper in the packet. An early example of this was generation of a hash of the payload header to be used for load balancing over Equal Cost Multipath (ECMP) or Link Aggregation Group (LAG) next hops. This is based on an assumption that the network layer protocol is IP. MPLS was extended to avoid the need for LSRs to perform this operation if load balancing was needed based on the payload and instead use only the MPLS label stack, using the Entropy Label / Entropy Label Indicator [RFC6790] which are inserted at the LER. Other applications where the intermediate LSRs may need to inspect and process a packet on an LSP include OAM, which can make use of mechanisms such the Router Alert Label [RFC3032] or the Generic Associated Channel Label (GAL) [RFC5586] to indicate that an Bocci & Bryant Expires July 28, 2022 [Page 3] Internet-Draft MIAD ADI Requirements January 2022 intercepted packet should be processed locally. See [I-D.bryant-mpls-dev-primer] for detailed list of such applications. There have been a number of new proposals for how ancillary data is carried in MPLS and how its presence is indicated to the LSR or egress LER, for example In-situ OAM and Service Function Chaining (SFC). A summary of these proposals is contained in [I-D.bryant-mpls-dev-primer], an overview of use cases is provided in [Reference to MIAD use cases]. [I-D.song-mpls-extension-header] summarises some of the issues with existing solutions to address these new applications (note that this document draws on the requirements and issues without endorsing a specific solution from [I-D.song-mpls-extension-header]): These solutions rely on either the built-in next-protocol indicator in the header or the knowledge of the format and size of the header to access the following packet data. The node is required to be able to parse the new header, which is unrealistic in an incremental deployment environment. A piecemeal solution often assumes the new header is the only extra header and its location in the packet is fixed by default. It is impossible or difficult to support multiple new headers in one packet due to the conflicted assumption. An example of this is that the GAL/G-ACH mechanism assumes that if the GAL is present, only a single G-ACH header follows. New applications therefore require the definition of extensions to the MPLS architecture and label stack operations that can be used across these applications in order to minimise implementation complexity and promote interoperability. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. MPLS Ancillary Data Indicator Requirements This document specifies requirements of MPLS Indicators for Ancillary Data (MIAD) and the Ancillary Data itself. The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which indicators for ancillary data are constructed. It does not specify the detailed processing that may be required by an application of that ancillary data by an LSR or Bocci & Bryant Expires July 28, 2022 [Page 4] Internet-Draft MIAD ADI Requirements January 2022 LER. The requirements in this document do not describe what functions an implementation must support. The purpose of this document is to identify the toolkit and any new protocol work that is required. This new protocol work MUST be based on the existing MPLS architecture. 3.1. General Requirements 1. MPLS combines extensibility, flexibility and efficiency by using control plane context combined with a simple data plane mechanism to allow the network to make forwarding decisions about a packet. Any solution MUST maintain these properties of MPLS. 2. Any solutions to these requirements MUST NOT restrict the generality of MPLS architecture [RFC3031], [RFC3032]. 3. Any solution MUST respect the principle that Special Purpose Labels are the mechanism of last resort and therefore must minimise the number of new SPLs that are allocated. 4. Solutions MUST be able to coexist with and MUST NOT obsolete existing MPLS mechanisms. 5. An ADI or ancillary data MUST NOT be delivered to a node that is not capable of processing it. That is: * An ADI MUST NOT become top of stack at a node that does not understand the ADI and is thus is not able to perform a disposition operation on it. Disposition includes both processing and ignoring. * When the label stack is popped there MUST NOT exist ancillary data that the node is not capable of performing a disposition operation on. Disposition includes both processing and ignoring. 6. Care MUST be taken in the coexistence of ancillary data and existing post-stack data mechanisms. 7. Mechanisms are needed to determine that all nodes that need to process the ancillary data can read the required distance into the packet at that node. 8. When ancillary data is present in the MPLS label stack, a mechanism is REQUIRED to indicate its presence. Bocci & Bryant Expires July 28, 2022 [Page 5] Internet-Draft MIAD ADI Requirements January 2022 9. When ancillary data is present below the MPLS label stack, a mechanism is REQUIRED to indicate its presence. 10. Ancillary data MAY be associated with control or maintenance information for traffic carried by an LSP, and/or it MAY be associated with the user traffic itself. 11. Ancillary Data Indicators (ADIs) SHOULD make use of existing MPLS data plane operations. If extensions to the MPLS data plane are required, they MUST NOT be inconsistent with the MPLS architecture [RFC3031], [RFC3032]. 12. The ADI design MUST support end-to-end (E2E) processing of ancillary data. 13. The ADI design MUST support hop-by-hop (HBH) processing of ancillary data. 14. For HBH ancillary data, a mechanism is REQUIRED to enable an LER inserting ADIs to determine if the ADI will be processed by LSRs along the path. 15. For HBH ancillary data, a mechanism is REQUIRED to enable an LER inserting ADIs to determine whether LSRs along the path can parse the label stack and process the ADI at the depth in the label stack where it is inserted. 16. If both HBH and E2E ancillary data indicators are present together, the precedence must be specified in the design. 17. A mechanism is REQUIRED to enable an LER inserting ADIs to determine if the far-end LER can accept and process a packet containing a given ADI. 18. ADIs SHOULD be supported for both P2P and P2MP paths, but any specific ADI may only be supported for one or the other. 19. Data plane mechanisms for ADIs MUST be independent of the control plane type (LDP, RSVP, BGP, static, IGP, etc). 20. A mechanism MUST be defined for control planes in use (e.g. LDP, RSVP, BGP, static, IGP, etc) to determine the ability of downstream LSRs/LERs to accept/process a given ADI. 21. A mechanism is REQUIRED to enable an LSR to determine if an ADI is present in a packet. Bocci & Bryant Expires July 28, 2022 [Page 6] Internet-Draft MIAD ADI Requirements January 2022 22. The design of this mechanism SHOULD be such that an LSR is able to efficiently parse the label stack and MUST NOT add more labels to the stack than is absolutely necessary. 23. ADIs can only be inserted at LERs, but MAY be processed at LSRs and LERs. If it is required to insert an ADI at a transit router on an LSP, then a new label stack MUST be pushed. 24. It SHOULD be possible to include indicators for ancillary data for multiple applications in the same packet, but each ADI MAY only support one application. 25. It MUST be possible to insert new ADIs for new applications on an established LSP that may have existing ADIs present. 26. The solution MUST allow ADI and non-ADI packets to coexist on the same LSP. 27. The solution MUST support the processing of a subset of the ADIs on a packet. 28. The solution MUST support slow path processing of ancillary data. 29. The solution MUST support fast path processing of ancillary data. 30. Application specifications MUST specify if the ancillary data needs to be processed in the fast path or if it can be processed in the slow path. (Ed. note: The fast path and slow path terminology may need to be reconsidered, and we should perhaps think in terms of synchronous and asynchronous operations ) 31. In order to prevent unnecessary scanning of the packet, care needs to be taken in the location of the ancillary data, for example it SHOULD be located as close to the label stack as possible. 32. A solution MUST be provided to verify the authenticity of ancillary data processed to LSRs [RFC3552]. 33. The design of the ADIs and ancillary data MUST NOT expose confidential information [RFC6973] [RFC3552] to the LSRs. 34. Any solution that modifies the ADI SHOULD NOT affect ECMP behavior. Bocci & Bryant Expires July 28, 2022 [Page 7] Internet-Draft MIAD ADI Requirements January 2022 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations The mechanisms required by this document introduce new security considerations to MPLS. Individual solution specifications meeting these requirements MUST address any security considerations. 6. Acknowledgements The authors gratefully acknowledge the contributions from Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, and Bruno Decraene. The authors also gratefully acknowledge the input of the members of the MPLS Open Design Team. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 7.2. Informative References [I-D.bryant-mpls-dev-primer] Bryant, S., "A Primer on the Development of MPLS", draft- bryant-mpls-dev-primer-01 (work in progress), December 2021. [I-D.song-mpls-extension-header] Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, "MPLS Extension Header", draft-song-mpls-extension- header-06 (work in progress), January 2022. Bocci & Bryant Expires July 28, 2022 [Page 8] Internet-Draft MIAD ADI Requirements January 2022 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>. [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>. Authors' Addresses Matthew Bocci Nokia Email: email@example.com Stewart Bryant University of Surrey 5GIC Email: firstname.lastname@example.org Bocci & Bryant Expires July 28, 2022 [Page 9]