MPLS Working Group R. Raszuk, Ed. Internet-Draft NTT NI Intended status: Informational 25 April 2022 Expires: 27 October 2022 Framework of MPLS Reference Augmented Forwarding draft-raszuk-mpls-raf-fwk-00 Abstract This document specifies an architectural framework for enabling MPLS based forwarding with optional reference based packet processing in transit network elements. Requirements Language 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 [RFC2119]. 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 27 October 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 to this document. Code Components Raszuk Expires 27 October 2022 [Page 1] Internet-Draft MPLS RAF April 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Reference to Special Instructions Mapping . . . . . . . . . . 5 6. Operational Considerations . . . . . . . . . . . . . . . . . 6 7. Capability Advertisement . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Growth of network services results in increased demand for custom transit packet processing. Traditional per destination based best effort or constrained based forwarding is no longer sufficient. Hop by hop switching in addition to label or destination based LSP switching can be augmented with additional packet processing at all or at selective transit network elements. Such additional processing can be triggered in a number of ways. Today some networks can apply local policies which enable selective processing on subset of packets based on the header's elements. Alternative to such filtering is to embed additional information in the packet header itself to indicate implicitly or explicitly what additional processing is required. Examples of explicit encoding of such network actions can be found in SRv6 Network Programming [RFC8986] document. For MPLS data plane an analogy to SRv6 has been recently proposed in draft-andersson-mpls-mna-fwk [I-D.andersson-mpls-mna-fwk]. Raszuk Expires 27 October 2022 [Page 2] Internet-Draft MPLS RAF April 2022 In this document authors propose an implicit model. Instead of explicitly encoding all required actions as a variable size ordered list in every packet this document proposes to insert fixed size 20 bit reference identifier. Such value will be used to mark groups of flows with identical custom forwarding behaviour. By forwarding behaviour (further abbreviated as FB) this document assumes additional network actions which may exclude packet from default processing, may include additional security screening, OAM triggering actions or any other special handling including, but not limited to rate limited, queue mapping, redirection etc ... 2. Terminology 2.1. Definitions * Network Action aka Forwarding Behaviour: An operation to be performed on a packet or be triggered based on given packet's arrival without affecting the packet switching decision. A network action may affect forwarding decisions, queuing classification, OAM measurement and reporting etc .... Network Actions are not carried in packets. They are distributed by configuration or control plane. * Reference Augmented Forwarding: Packet forwarding in addition to or instead of normal lookup (by address or label) based on a set of Network Actions or Forwarding Behaviours indicated by Reference Identifier. * Reference Forwarding Value: A 20 bit value carried in a packet used to identify a set of Network Actions defining given packet's special handling. * Reference Forwarding Indicator: A base Special Purpose Label carried in a packet used to indicate to the packet processor that the following LSE is containing Reference Forwarding Value. 2.2. Abbreviations * FB - Network Actions or Forwarding Behaviours * LSE - Label Stack Entry * RAF - Reference Augmented Forwarding * bSPL - Base Special Purpose Label * ECMP - Equal Cost Multipath Raszuk Expires 27 October 2022 [Page 3] Internet-Draft MPLS RAF April 2022 * RFI - Reference Forwarding Indicator * RFV - Reference Forwarding Value * TBA - To Be Allocated * SDN - Software Defined Network 3. Encoding A Reference Forwarding Value MUST be clearly distinguished from any forwarding label. LSE immediately preceding label stack entry containing RFV is called Reference Forwarding Indicator. RFI is REQUIRED to use Special Purpose Label value (TBA by IANA). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFI - bSPL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFV | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFI: Reference Forwarding Indicator, 20 bits RFV: Reference Forwarding Value, 20 bits TC: Traffic Class, 3 bits S: Bottom of Stack, 1 bit TTL: Time To Live Figure 1: RFI and RFV Tuple RFI and RFV tuple is always of fixed size of 8 octets. It also should occur only once in a given packet. It is optional. If a network uses the concept of LSPs it MUST be placed after the topmost label. If LSP is not setup and the network uses the concept of SDN based path computation it can be preset as topmost LSE. How to set values of the TTL, TC, and Bottom of Stack (S bit) fields [RFC3032] for the RFI and RFV entries should be the same as described in [RFC6790] Section 4.2. Ingress LSR SHOULD put the same TTL and TC fields for the RFI as it does for transport label. Such ingress LSR MAY choose different values for the TTL and TC fields if it is known that the RFI will not be exposed as the top label at any point along the LSP (as may happen in cases where PHP is used and the RFI and RFV are not stripped at the penultimate hop. The BoS bit for the RFI MUST be set to zero (i.e., BoS is not set). The TTL for the RFV MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the RFV may be any value. The BoS bit for the RFV depends on whether or not there are more labels in the label stack. Raszuk Expires 27 October 2022 [Page 4] Internet-Draft MPLS RAF April 2022 4. Processing Any network element can insert, delete or modify RFV or RFI-RFV tuple if instructed to do so by special action instructions. If a network element understands RFI and recognizes based on the top most lable value special handling requirement it MAY direct packet for special processing. MAY or MUST processing of all requested actions (or subset of those actions) really depend on the special action instructions. 5. Reference to Special Instructions Mapping As the proposed architecture is based on indirection, what is present in the packet is only a reference to special handling instructions. Such instructions are not to be explicitly carried in the packet. As each network operator has a different set of operational preferences, embedding insertion of actions into a data plane parsing of each packet is very operationally limiting and inefficient. Special Network Actions or Forwarding Behaviours are to be distributed by configuration or by control plane. Details of their distribution are outside of scope of this framework document. However, it is important to recognize that this model in its roots allows open innovation for vendors in developing accelerated data plane action dictionaries as mapping and execution has only a local scope. It needs to be further observed that format of such configuration or control plane (including PUB-SUB model) distributed Forwarding Behaviours MAY have a TLV/sub-TLV structure as illustrated on Figure 2 and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST NODE ID(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: FB TLV Raszuk Expires 27 October 2022 [Page 5] Internet-Draft MPLS RAF April 2022 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 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Actions and Optional Ancillary Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FB sub-TLV With such encoding option it needs to be observed that for a given RFV only nodes listed in the TLV will accept and install special handling instructions. 6. Operational Considerations The proposed model is designed to operate both in the networks using traditional MPLS LSP (with local labels) as well with SR-MPLS (domain wide labels). Nodes which utilize MPLS LSPs and did not receive any special handling instructions via control plane are NOT REQUIRED to inspect anything above the top label and will continue to perform basic label switching. If a node is enabled to perform additional actions on the packets it should leave the RFI/RFV tuple as received immediately after the top label swap on the stack. The PHP action may take place as usuall exposing RFI LSE. In such cases egress LSR MUST be able to understand bSPL and either discard RFI/RFV tuple or if configured so execute special actions on those packets before further forwarding it. [Discussion point for WG: Should nodes inserting additional labels on the stack for example during FRR should copy the RFI/RFV to enable it to be executed on the repair path or not ?]. Nodes which utilize the concept of SR-MPLS and use global labels as a replacement for use of LDP can apply the same set of procedures as nodes using MPLS-LSP. Nodes which utilize the concept of SR-MPLS and use global labels with segment endpoints encoded in the label stack MUST understand RFI bSPL in order to correctly copy the tuple to always place it immediately behind the top most segment endpoint during label stack modification. Raszuk Expires 27 October 2022 [Page 6] Internet-Draft MPLS RAF April 2022 To further simplify the concept of MPLS RAF deployment networks which utilize concept of domain wide labels can allocate two label values from each LSR. One would indicate non RAF forwarding and the other one RAF enhanced forwarding. With such allocation only nodes which recognize that arriving packets contain RAF aware label value and which received any special handling instructions may need to perform additional RFI/RFV lookup and processing. Such allocation may be unified to differentiate normal vs RAF enabled labels with common label block offset or selected label bit set. 7. Capability Advertisement This document does not require any new capability to be defined. 8. IANA Considerations This document defines a new bSPL label called Reference Forwarding Indicator and is requesting IANA to allocate one from Base Special- Purpose MPLS Label Values registry. 9. Security Considerations This document does not introduce any new security risks. 10. Acknowledgements Author would like to thank Tony Li and Jeff Tantsura for encouraging me to write this up. 11. References 11.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, . [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, . [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, . Raszuk Expires 27 October 2022 [Page 7] Internet-Draft MPLS RAF April 2022 11.2. Informative References [I-D.andersson-mpls-mna-fwk] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Network Actions Framework", Work in Progress, Internet- Draft, draft-andersson-mpls-mna-fwk-00, 4 April 2022, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Author's Address Robert Raszuk (editor) NTT NI Email: robert@raszuk.net Raszuk Expires 27 October 2022 [Page 8]