Internet DRAFT - draft-andersson-mpls-indicators-and-anxillary-data
draft-andersson-mpls-indicators-and-anxillary-data
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,
<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>.
Author's Address
Loa Andersson
Bronze Dragon Consulting
Email: loa@pi.nu
Andersson Expires December 11, 2021 [Page 11]
