MPLS Working Group L. Andersson Internet-Draft Bronze Dragon Consulting Intended status: Informational June 9, 2021 Expires: December 11, 2021 Indicators and anxillary data in the MPLS Label Stack draft-andersson-mpls-indicators-and-anxillary-data-00 Abstract This document is a living document, meaning that during the life timme of the MPLS Open Design Team we will to survey the relationship between indicators and anxillary dat. Ideally when the Design Team is closed this document will be empty, or maybe we just add a pointer to where the answer to quesstion is documented. Thus this document will never go on to become an RFCc. 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 December 11, 2021. Copyright Notice Copyright (c) 2021 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 Andersson Expires December 11, 2021 [Page 1] Internet-Draft Indicators and Data June 2021 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 1.2. Local terminology . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Indicator . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2. Anxillary Data . . . . . . . . . . . . . . . . . . . 3 1.2.3. Scan, Parse and Readable Depth . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Combiinations or Indicators anbd Anxillary Data . . . . . . . 4 3.1. No extra data . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Associated Channel Style . . . . . . . . . . . . . . . . 5 3.3. Extended Associated Channel Style . . . . . . . . . . . . 5 3.4. Modified Associated Channel Style . . . . . . . . . . . . 6 3.5. Modified Associated Channel Style . . . . . . . . . . . . 7 3.6. Enhanced Associated Channel Style . . . . . . . . . . . . 8 3.7. Enhanced Associated Channel Style . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Normative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document discusses in-label-stack indicators to locate anxillary data carried in the label stack or after the Bottom of Stack (BoS) bit. The document is intended to be a "living document", meaning that it will be updated as long as the Open DT finds it useful, but it is not intended to become an RFC. Information in this document might be captured in "real" output documents from the Open DT. "Living Documents" are not commonly used in the IETF, but we have considered it to be a good way of documenting the state of the issues worked on by the design team. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Andersson Expires December 11, 2021 [Page 2] Internet-Draft Indicators and Data June 2021 For a document that is not intended to become and RFC on the Standards Track it might seem moot to have the requirement language included, however it might be that a question or an answer to one of the questions might use the BCP 14 language, so to avoid ambiguity we left it in. 1.2. Local terminology Two terms are frequently used in this document. "indicator" and "anxillary data". This section gives a high level definition of the two terms. 1.2.1. Indicator An indicator is a Spoecial Purpose Label (bSPL or eSPL), or part of such a label, carried in MPLS Lael Stack. 1.2.2. Anxillary Data Anxillary data is data that is used to improve the precission of packet forwarding, it can be carried as part of a indicator label or after the the label with BoS bit set. 1.2.3. Scan, Parse and Readable Depth The three terms are used in the context of finding e.g. indicators or the BoS in a label stack. The terms "scan" and "parse" are virtually synonymous aand relates to an activity to consequtively read the labels in a label stack in order to find certain information. Readable depths tell you have deep into the label stack a scanning (a.k.a parsing) operation can go, expressed in the number of labels. 2. Background When MPLS was first designed the label stack was fairly simple, you had a label at the top of the stack on which a forwarding decision were taken. The only exception the few labels (values 0-15) that were set aside as Special Purpose Labels, such labels have a special action or interpretation assigned to them. When Pseudowires were designed it beccame clear that i would be beneficial to be possible to send anxillary data together with the MPLS packets that transported the Pseudowire payload data. Andersson Expires December 11, 2021 [Page 3] Internet-Draft Indicators and Data June 2021 The method develooped was to create an Associated Channel as a shim between the bottom of the label stack and the Pseudowire payload. When the MPLS Transport Profile (MPLS-TP) the assiciated channel were were generalized to applocable to all MPLS networks. From the start only one associated channel is allowed per packet. Lately there has been discussions on allowing multiple associated channels or other types of channelized ifo, like MPLS Extension headers. It should be noted that this "background" does not aspire to be 100% historically corect, but is the recollection of the author. 3. Combiinations or Indicators anbd Anxillary Data The aim of this docment is to list all the combinations of of indicators and anxillary data that we can think of. And also make note for each case if it is a "requirement" or not. The different types indicators and anxillary data are discussed as they they are listed. 3.1. No extra data For completness the Plain Old MPLS Service label stack is included here, it does not carry any indicator or anxillary data. +-------------+ | L1 (0) | +-------------+ | L2 (0) | +-------------+ | L3 (0) | +-------------+ | L4 (1) | +-------------+ | Pay Load | ~ ~ | | +-------------+ Figure 1: Plain Old MPLS Service Question: If we normally scan the label stack for indicators is it possible to stop the scanning for this type of packet? Andersson Expires December 11, 2021 [Page 4] Internet-Draft Indicators and Data June 2021 In scope: Yes 3.2. Associated Channel Style The combination of a GAL in the label stack and an Associated Channel after the BoS is the the original model for the "Associated Channel". Originally only one set of anxillary data and only one indicator was allowed. +-------------------+ | L1 (0) | +-------------------+ | indicator (0) | +-------------------+ | L3 (0) | +-------------------+ | L4 (1) | +-------------------+ | anxillary data | ~ ~ | | +-------------------+ | Pay Load | ~ ~ | | +-------------------+ Figure 2: Associated Channel Service Question: If we normally scan the label stack for indicators is it possible to stop the scanning once the single indicator for this type of packet is found? In scope: Yes 3.3. Extended Associated Channel Style Recently there has been a discussion about what happen if the label stack grow to such a depth that some LSRs can't scan the stack to such a depth that the indicator can't be read. The maximum readable depth has been exceeded. It has been proposed to allow inserting a copy of the indicator higher up in the stack. There is still only one set of anxillary data after the BoS. Andersson Expires December 11, 2021 [Page 5] Internet-Draft Indicators and Data June 2021 +-------------------+ | L1 (0) | +-------------------+ | indicator b (0) | +-------------------+ | L3 (0) | +-------------------+ | L4 [0) | +-------------------+ | indicator a (0) | +-------------------+ | L6 (1) | +-------------------+ | anxillary data | ~ ~ | | +-------------------+ | Pay Load | ~ ~ | | +-------------------+ Figure 3: Extended Associated Channel Service Question: If we normally scan the label stack for indicators is it possible to stop the scanning once the first copy indicator for this type of packet is found? In scope: Yes 3.4. Modified Associated Channel Style It has been discussed to allow more than one set of anxillary data, indicated byt different indicators in the label stack. Andersson Expires December 11, 2021 [Page 6] Internet-Draft Indicators and Data June 2021 +-------------------+ | L1 (0) | +-------------------+ | indicator 2 (0) | +-------------------+ | L3 (0) | +-------------------+ | L4 [0) | +-------------------+ | indicator 1 (0) | +-------------------+ | L6 (1) | +-------------------+ | anxillary data 1 | ~ ~ | | +-------------------+ | anxillary data 2 | ~ ~ | | +-------------------+ | Pay Load | ~ ~ | | +-------------------+ Figure 4: Modified Associated Channel Service Question: There might be a problem to decide which set of anxillary data is indicated by which indicator. Some method to disambiguiate this need to be designed. In scope: Yes 3.5. Modified Associated Channel Style It has been discussed to allow more than one set of anxillary data, indicated byt different indicators in the label stack. Andersson Expires December 11, 2021 [Page 7] Internet-Draft Indicators and Data June 2021 +-------------------+ | L1 (0) | +-------------------+ | indicator 2 (0) | +-------------------+ | L3 (0) | +-------------------+ | L4 [0) | +-------------------+ | indicator 1 (0) | +-------------------+ | L6 (1) | +-------------------+ | anxillary data 1 | ~ ~ | | +-------------------+ | anxillary data 2 | ~ ~ | | +-------------------+ | Pay Load | ~ ~ | | +-------------------+ Figure 5: Modified Associated Channel Service Question: There might be a problem to decide which set of anxillary data is indicated by which indicator. Some method to disambiguiate this need to be designed. In scope: Maybe, but we should really aim for Section 3.6 Enhanced Associated Channel Style if we want to do multiple sets of anxillary data. 3.6. Enhanced Associated Channel Style The discussion to allow more than one set of anxillary data, indicated by different indicators in the label stack, also has resulted in that a need to have the indicators to better indicate which set of anxillary data is the target. Andersson Expires December 11, 2021 [Page 8] Internet-Draft Indicators and Data June 2021 +-------------------+ | L1 (0) | +-------------------+ +---| indicator 2 (0) | | +-------------------+ | | L3 (0) | | +-------------------+ | | L4 [0) | | +-------------------+ | | indicator 1 (0) |---+ | +-------------------+ | | | L6 (1) | | | +-------------------+ | | | anxillary data 1 |<--+ | ~ ~ | | | | +-------------------+ +-->| anxillary data 2 | ~ ~ | | +-------------------+ | Pay Load | ~ ~ | | +-------------------+ Figure 6: Enhanceded Associated Channel Service Question: Nil In scope: Yes 3.7. Enhanced Associated Channel Style There is also a proposal to allocate a new bSPL called Farwarding Action Indicator (FAI). The FAI uses the "unused" bits in the label format, i.e. the TTL and the TC bits. These bits can bothe be "self contained", i.e. the bit give all the information needed for the required forwarding action, or they point to anxillary data after the BoS. Andersson Expires December 11, 2021 [Page 9] Internet-Draft Indicators and Data June 2021 +-------------------+ | L1 (0) | +-------------------+ (the FAI expanded below) | FAI (0) | +-------------------+ | L3 (0) | +-------------------+ | L4 [0) | +-------------------+ | indicator 1 (0) |---+ +-------------------+ | | L6 (1) | | +-------------------+ | | anxillary data 1 |<--+ ~ ~ | | +-------------------+ | anxillary data 2 | ~ ~ | | +-------------------+ | Pay Load | ~ ~ | | +-------------------+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ name | FAI | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bits | [to be alloacted) |x x x|-|x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Exmp | |0 0 0|-|0 0 0 1 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Legend: The "-" in the BoS (s) means that it is not availabel for FAI encoding Bits 20-22 and 24-31 are availabel for FAI encodings On the example line two bits are set, bit 27 and 30. Without claiming that this aligns with the existing proposal, we can imaging that bit 27 is self contained and directly gives forwarding actioins required, and that bit 30 indicates presence of anxillary data after the BoS. Figure 7: Enhanceded Associated Channel Service Andersson Expires December 11, 2021 [Page 10] Internet-Draft Indicators and Data June 2021 Question: Can we make the bits in an SPL exactly point out which set of anxillary data that should be used? In scope: Likely 4. IANA Considerations This document does not make any allocations of code points from IANA registries. 5. Acknowledgements - - 6. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Author's Address Loa Andersson Bronze Dragon Consulting Email: loa@pi.nu Andersson Expires December 11, 2021 [Page 11]