Internet DRAFT - draft-andersson-mpls-miad-fwk
draft-andersson-mpls-miad-fwk
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,
<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>.
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,
<https://www.rfc-editor.org/info/rfc3032>.
[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,
<https://www.rfc-editor.org/info/rfc4928>.
[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, <https://www.rfc-editor.org/info/rfc8296>.
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]
