MPLS Working Group L. Andersson Internet-Draft Bronze Dragon Consulting Intended status: Informational S. Bryant Expires: September 4, 2022 University of Surrey 5GIC M. Bocci Nokia March 03, 2022 MPLS MIAD Framework draft-andersson-mpls-miad-fwk-01 Abstract This document specifies an architectural framework for the application of the MPLS Indicator and Ancillary Data (MIAD) technologies. MIAD techmologies are used to indicate actions (I) for LSPs and/or packets and to transfer data needed for these actions (AD). The document describes a common set of protocol functions and information elements - the MPLS Indicartor and Ancillary Data - supporting additional operational models and capabilities of MPLS netwroks that support these functions. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements in the MIAD requirement specification. This document is the result of work started in MPLS Open Desgign Team, with participation by the MPLS, PALS and DETNET working groups. 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 September 4, 2022. Andersson, et al. Expires September 4, 2022 [Page 1] Internet-Draft MIAD Framework March 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2. Normative Definitions . . . . . . . . . . . . . . . . . . . . 3 2.1. Ancillary Data (AD) . . . . . . . . . . . . . . . . . . . 3 2.2. Ancillary Data Indicator (ADI) . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Process Note on E2E . . . . . . . . . . . . . . . . . 6 3.2. Concepts used in this Framework . . . . . . . . . . . . . 6 4. Methods to carry Ancillary Data Indicators . . . . . . . . . 6 4.1. existing base SPL . . . . . . . . . . . . . . . . . . . . 6 4.2. new base SPL . . . . . . . . . . . . . . . . . . . . . . 6 4.3. new extend SPL . . . . . . . . . . . . . . . . . . . . . 7 5. Method chosen by the working group . . . . . . . . . . . . . 7 6. Types of AD . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. In Stack Data (ISD) . . . . . . . . . . . . . . . . . . . 7 6.2. Post Stack Data (PSD) . . . . . . . . . . . . . . . . . . 7 6.3. Implicit Data . . . . . . . . . . . . . . . . . . . . . . 7 7. ADI details . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Hop by Hop (HBH) . . . . . . . . . . . . . . . . . . . . 7 7.2. End to End (E2E) . . . . . . . . . . . . . . . . . . . . 7 7.3. Initiate action at a specific single node . . . . . . . . 7 8. Flag Field . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Unused SPL bits . . . . . . . . . . . . . . . . . . . . . 7 8.1.1. RFC 3032 LSE definition . . . . . . . . . . . . . . . 8 8.1.2. Carrying the flag field starting in the first LSE . . 8 8.1.3. Carrying the flag field starting in the second LSE . 8 8.1.4. Using two bSPLs . . . . . . . . . . . . . . . . . . . 9 8.2. Process Note flags and flag field . . . . . . . . . . . . 9 9. ADI specification rules . . . . . . . . . . . . . . . . . . . 9 10. Ancillary Data . . . . . . . . . . . . . . . . . . . . . . . 9 Andersson, et al. Expires September 4, 2022 [Page 2] Internet-Draft MIAD Framework March 2022 11. Packet Structure . . . . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 13. Management Considerations . . . . . . . . . . . . . . . . . . 10 14. MPLS Forwarding model . . . . . . . . . . . . . . . . . . . . 10 14.1. Orginal Model . . . . . . . . . . . . . . . . . . . . . 10 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 16. The First Nibble considerations . . . . . . . . . . . . . . . 11 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 18.1. Normative References . . . . . . . . . . . . . . . . . . 11 18.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document discusses how flag fields ancillary data and IANA registries for the data coul be desinged. Maybe expand the abstract a bit and give some of the developement we seen in the MPLS forwarding model, e.g. original model, first nible, Pseudowire ACH, GACH and MIAD. 1.1. Requirement 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document is intended to become an Informational RFC, it is not clear that we will need Section 1.1. We will leave it in for the time being and take the decision to remove or not closer to the Publication Request. test 2. Normative Definitions text to be added, prime candidates to be discussed are AD and ADI, not least explaining the differences. 2.1. Ancillary Data (AD) 2.2. Ancillary Data Indicator (ADI) Andersson, et al. Expires September 4, 2022 [Page 3] Internet-Draft MIAD Framework March 2022 3. Terminology 3.1. Abbreviations Andersson, et al. Expires September 4, 2022 [Page 4] Internet-Draft MIAD Framework March 2022 +--------------+------------+---------------------------+-----------+ | Abbreviation | Meaning | Reference | Note | +--------------+------------+---------------------------+-----------+ | AD | Ancillary | draft-bocci-mpls-miad- | place | | | Data | adi-requirements | holder | | | | | | | ADI | Ancillary | draft-bocci-mpls-miad- | | | | Data | adi-requirements | | | | Indicator | | | | | | | | | ECMP | Equal Cost | | | | | Multipath | | | | | | | | | E2E | End to end | In the MIAD context this | | | | | document. | | | | | | | | HBH | Hop by hop | In the MIAD context this | | | | | document. | | | | | | | | ISD | In stack | draft-bocci-mpls-miad- | | | | data | adi-requirements | | | | | | | | LSE | Label | RFC 3032 [RFC3032] | | | | Stack | | | | | Entry | | | | | | | | | MIAD | MPLS | MPLS Open DT wiki and | MIAD is | | | Indicators | this documnent | the name | | | and | | of both | | | Ancillary | | this tech | | | Data | | nology | | | | | technlogy | | | | | and the | | | | | project d | | | | | eveloping | | | | | this part | | | | | of the | | | | | MPLS arch | | | | | itecture | | | | | | | PSD | Post stack | draft-bocci-mpls-miad- | | | | data | adi-requirements | | +--------------+------------+---------------------------+-----------+ Table 1: Abbreviations Andersson, et al. Expires September 4, 2022 [Page 5] Internet-Draft MIAD Framework March 2022 3.1.1. Process Note on E2E There has been some discussion on the of the E"E abbreviation. 1. In a mail to the MPLS Working group mailing list Joel Halpern pinted out that the abbreviation E2E has been used in several different meanings. Joel suggested to use another abbreaviation. 1. Some variants has been proposed, for example. * Ingress to Egress (I2E); alernative abbreviatioon (i2e) * Egress * LSP Ingress to LSP Egress (LI2LE) In a few days (counting from the publication date of this document) the working group chairs will take an initiative to poll the working groups for consensus on this. 3.2. Concepts used in this Framework +------------+--------------------------------+--------------+------+ | Concept | Meaning | Reference | Note | +------------+--------------------------------+--------------+------+ | E2E | E2E in MIAD context is defined | this | - | | concept | in... | document | | | | | | | | concept | free text | this | - | | | | document | | +------------+--------------------------------+--------------+------+ Table 2: Concepts Not complete, help appreciated. 4. Methods to carry Ancillary Data Indicators Several possibilities to carry ADI's has been discussed in MIAD drafts and in the MPLS Open DT. 4.1. existing base SPL 4.2. new base SPL Andersson, et al. Expires September 4, 2022 [Page 6] Internet-Draft MIAD Framework March 2022 4.3. new extend SPL 5. Method chosen by the working group o confused, but we need to write something 6. Types of AD 6.1. In Stack Data (ISD) a bit of explanatory text 6.2. Post Stack Data (PSD) a bit of explanatory text 6.3. Implicit Data Note: We are changing the earlier "No Data" (NoD) to implicit without creating an abbreviation [I-D.bocci-mpls-miad-adi-requirements]. ID would be to close o ISD. 7. ADI details 7.1. Hop by Hop (HBH) 7.2. End to End (E2E) 7.3. Initiate action at a specific single node We are looking to see if this is needed. 8. Flag Field The MIAD flag field is carried in a Base Special Purpose Lavel (bSPL). Different style of bSPLs can as discussed in {#carry} issues around which bSPL to use for the flag field are discussed in this section. This section discussed how the flag field itself is set up. 8.1. Unused SPL bits In a SPL only the 20 bits of Label Value and the Bottom of Stack bit are significant, the TC field (3 bits) and the TTL (8 bits) are not used. This leaves 11 bits that could be used for the MIAD flag fields (carrying ADIs) in the first LSE.. The flag field may also be carried in an LSE (second LSE) immediately following the LSE that carries the Label Value Andersson, et al. Expires September 4, 2022 [Page 7] Internet-Draft MIAD Framework March 2022 8.1.1. RFC 3032 LSE definition 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: Label Value, 20 bits TC: Traffic Class, 3 bits S: Bottom of Stack, 1 bit TTL: Time to Live, 8 bits 8.1.2. Carrying the flag field starting in the first LSE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label |f f f|s|f f f f f f f x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f f f f f f f f f f f f f f f f f f f f f f f|s|f f f f f f f x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: Label Value, 20 bits f: MIAD flag (ADI) S: Bottom of Stack, 1 bit x: Extension bit 8.1.3. Carrying the flag field starting in the second LSE An alternative would be to not carrying flags in the "spare" 11 bits of the first LSE, but to start the flag field in the second LSE. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | TC |s| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f f f f f f f f f f f f f f f f f f f f f f f|s|f f f f f f f x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: Label Value, 20 bits TC: Traffic Class, 3 bits S: Bottom of Stack, 1 bit TTL: Time To Live f: MIAD flag (ADI) x: Extension bit Andersson, et al. Expires September 4, 2022 [Page 8] Internet-Draft MIAD Framework March 2022 8.1.4. Using two bSPLs The possibility to use two bSPLs to carry flag fields has been suggested. For example action indicators (ADIs) using Implicit and ISD could use one bSPL and the action indicators using PSD could use the other. The mapping of the flag field into the bSPLs would be the same as above. 8.1.4.1. Interpreting flags and bits Label - As in RFC 3032. TC - Traffic Class, as in the updated RFC 3032. S - Bottom of Stack bit, as in RFC 3032. TTL . Time To Live, as in RFC 3032. f-bits (f) - Flags (ADIs) see Section 7. It is possible to have flags of more than one bit. x-bit (x) - Extension bit, if the x bit is 0 (zero) the next field is an LSE carrying MIAD flags, if it is 1 (one) there are no more flag field LSEs for that bSPL. 8.2. Process Note flags and flag field 1. It seem obvious that the working group would want to produce one single consolidated solution for how to carry the flags and flag field. 2. The decision on which method to use for carrying flags and flag fields will be taken by a consensus call in the MPLS, PALS and DETNET working groups, and be documented here. 9. ADI specification rules Guidance what to include in an IANA section 10. Ancillary Data Structure, encoding, allocation of identifiers. Matters of sequence / priority. Instances of a single type of AD. Andersson, et al. Expires September 4, 2022 [Page 9] Internet-Draft MIAD Framework March 2022 11. Packet Structure 12. Security Considerations 13. Management Considerations 14. MPLS Forwarding model This is section here to basically to have a place holder where to discuss the development of the MPLS forwrding model. It might be removed. 14.1. Orginal Model +-----------------------------------------------------------------+ | | | +---------------------+ | | | +------------+ | | | | | MPLS Label | LSE | | | | +---|--------+ | | | +-----|---------------+ | | | | | | +----------------------+ | | | | FIB | | | | | | | | | | +------------+ | +----------------------+ | | +------->|FIB Entry |-----+-->|Forwarding Code | | | | +------------+ | | +----------------------+ | | +----------------------| | | | | | +----------------------+ | | +-->|Forwarding Parameters | | | +----------------------+ | | | | | | LSE = Label Stack Entry (what many people call a label) | | FIB = Forwarding Information (date)Base | +-----------------------------------------------------------------+ Figure 1: MPLS Original Forwarding Model 15. IANA Considerations This document does not make any allocations of code points from IANA registries. As long as the "does not make any allocations ..." from IANA is true, this pragraph shoukd be removed by the RFC-Editor. If it turns out Andersson, et al. Expires September 4, 2022 [Page 10] Internet-Draft MIAD Framework March 2022 that we will need to do IANA allocation, a proper IANA section will be added. 16. The First Nibble considerations The first nibble after the label stack has been used to convey information in certain cases. For example, in [RFC4928] this nibble is investigated to find out if it has the value "4" or "6", if it is not, it is assumed that the packet payload is not IPv4 or IPv6 and Equal Cost Multipath (ECMP) is not performed. It should be noted that this is an inexact method, for example an Ethernet Pseudowire without a control word might have "4" or "6" in the first nibble and thus will be ECMP'ed. Nevertheless, the method is implemented and deployed, it is used to day and will be for the foreseeable future. The use of the first nibble for BIER is specified in [RFC8296]. Bier sets the first nibble to 5. The same is true for BIER payload, as for any use of the first nibble, it is not possible from the first nibble itself being set to 5, conclude that the payload is BIER. However, it achieves the design goal of {{RFC8296, to exclude that the payload is IPv4, IPv6 or a pseudowire. There is possible more examples, they will be added if we find that they further highlights the issue with using the first nibble. 17. Acknowledgements 18. References 18.1. Normative References [I-D.bocci-mpls-miad-adi-requirements] Bocci, M. and S. Bryant, "Requirements for MPLS Label Stack Indicators and Ancillary Data", draft-bocci-mpls- miad-adi-requirements-02 (work in progress), March 2022. [I-D.decraene-mpls-slid-encoded-entropy-label-id] Decraene, B., Filsfils, C., Henderickx, W., Saad, T., Beeram, V. P., and L. Jalil, "Using Entropy Label for Network Slice Identification in MPLS networks.", draft- decraene-mpls-slid-encoded-entropy-label-id-03 (work in progress), February 2022. Andersson, et al. Expires September 4, 2022 [Page 11] Internet-Draft MIAD Framework March 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 18.2. Informative References [I-D.kbbma-mpls-1stnibble] Kompella, K., Bryant, S., Bocci, M., Mirsky, G., and L. O. (. Andersson, "IANA Registry for the First Nibble Following a Label Stack", draft-kbbma-mpls-1stnibble-00 (work in progress), October 2021. [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, . [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, . [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, . Authors' Addresses Loa Andersson Bronze Dragon Consulting Email: loa@pi.nu Stewart Bryant University of Surrey 5GIC Email: sb@stewartbryant.com Andersson, et al. Expires September 4, 2022 [Page 12] Internet-Draft MIAD Framework March 2022 Matthew Bocci Nokia Email: matthew.bocci@nokia.com Andersson, et al. Expires September 4, 2022 [Page 13]