MPLS Working Group L. Andersson
Internet-Draft Bronze Dragon Consulting
Intended status: Informational J. Guichard
Expires: October 7, 2022 H. Song
Futurewei Technologies
S. Bryant
University of Surrey
April 5, 2022
MPLS Extension Header Architecture
draft-andersson-mpls-eh-architecture-03
Abstract
Extension Headers (EH) carry information on in-network services and
functions in an MPLS network. This document describes an
architecture for EHs and what actions an EH capable Label Switching
Router (LSR) takes when finding or not finding an EH in the packet.
Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
technology. It uses label stack entries that are pre-pended to
either the EH or the ACH which in turn is pre-pended to the payload.
The label stack entries are used to identify the forwarding actions
by each LSR. Actions may include pushing, swapping or popping the
labels, and using the labels to determine the next hop for forwarding
the packet. Labels may also be used to establish the context under
which the packet is forwarded.
The extension headers are carried after the MPLS Label Stack, and the
presence of EHs are indicated in the label stack by an Extension
Header Indicator (EHI).
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."
Andersson, et al. Expires October 7, 2022 [Page 1]
Internet-Draft EH Architecture April 2022
This Internet-Draft will expire on October 7, 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 . . . . . . . . . . . . . . . . . . 4
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Extension Header Overview . . . . . . . . . . . . . . . . 4
2.2. Extension Header Terminology . . . . . . . . . . . . . . 4
3. Extension Header Basics . . . . . . . . . . . . . . . . . . . 5
3.1. General Principles . . . . . . . . . . . . . . . . . . . 5
3.2. LSPs in a EH capable Network . . . . . . . . . . . . . . 5
3.3. EH capable nodes . . . . . . . . . . . . . . . . . . . . 6
3.4. EH path and LSP . . . . . . . . . . . . . . . . . . . . . 6
3.5. Announcement of EH Capability . . . . . . . . . . . . . . 7
3.6. LSP establishment with LDP Downstream on Demand (DoD) in
an EH capable network . . . . . . . . . . . . . . . . . . 7
3.7. LSP establishment with LDP Downstream Unsolicited (DU) in
an EH capable network . . . . . . . . . . . . . . . . . . 9
3.8. Forwarding Behavior of EH Capable Nodes . . . . . . . . . 10
3.9. EH for RSVP-TE tunnels . . . . . . . . . . . . . . . . . 11
3.10. Ways to indicate an EH after the Label Stack . . . . . . 11
4. EH in VPNs . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. EH and MPLS-SR . . . . . . . . . . . . . . . . . . . . . . . 11
6. Extension Header Applications . . . . . . . . . . . . . . . . 11
7. EH distribution and EH capability announcement . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Andersson, et al. Expires October 7, 2022 [Page 2]
Internet-Draft EH Architecture April 2022
1. Introduction
This document specifies the architecture for the extension of MPLS to
include Extension Headers (EH). EHs carry information on in-network
services and functions in an MPLS network. This document describes
an architecture for EHs and what actions an EH capable Label
Switching Router (LSR) takes when finding or not finding an EH in the
packet,
The extension headers are carried after the MPLS Label Stack, and the
presence of EHs are indicated in the label stack by an Extension
Header Indicator (EHI).
Below some exmple use cases are listed. More details will be found
in [I-D.song-mpls-extension-header]
o In-situ OAM: In-situ OAM (IOAM) records flow OAM information
within user packets while the packets traverse a network.
o Network Telemetry and Measurement: A network telemetry and
instruction header can be carried as an extension header to
instruct a node what type of network measurements should be
performed on the packets.
o Network Security: Security related functions may require user
packets to carry some metadata.
o Segment Routing and Network Programming: MPLS extension header
could support MPLS-based segment routing. The details will be
described in a separate draft.
It is possible to distinguish between two types of MPLS EHs, "hop-by
hop" (HBH) and "End to end" (E2E).
An HBH EH is processed by every node along an LSP, HBH EHs MAY be
inserted by an ingress LSR or a transit LSR. A HBH EH MUST be
removed by an LSR along the LSP or by the egress LSR. An LSR along
the LSP may be configured to ignore HBH EHs.
An E2E EH will be inserted by the ingress LSR and, processed and MUST
be removed by the egress LSR, no other LSR along the LSP will process
the E2E EH.
Only EH capable LSRs will process EHs, LSR that are EH non-capable
will ignore the EH and forward the packet as if the information was
not there.
Andersson, et al. Expires October 7, 2022 [Page 3]
Internet-Draft EH Architecture April 2022
This document describes the interaction between EH capable neighbour
LSRs, and between EH capable LSRs and a neighbour that is EH non-
capable.
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.
2. Specification
This document specifies the use of Extension Headers (EH) with MPLS.
Further information on EH processing and formats will be found in
[I-D.song-mpls-extension-header].
2.1. Extension Header Overview
Applications carried over an MPLS network may require that specific
instructions and/or metadata are added to user packets. One such
example could be In-situ OAM (IOAM) [I-D.brockners-inband-oam-
requirements]. It is likely that new such applications will emerge
over time.
One or more EHs may be added by an ingress node to an Extension
Header Path (EHP) and be removed by one or more EH capable nodes
along the EHP. Such ingress and egress nodes may be nodes at the
head end and tail end of a Label Switched Path (LSP), or any other
intermediate node of the LSP that is EH capable. For more details on
EHPs see Figure 1.
2.2. Extension Header Terminology
This section lists the abbreviations and concepts that are used
throughout this document in the context of Extension Headers.
o EH - Extension Header
o EHI - Extension Header Indicator
o LDP DoD - LDP Downstream on Demand
o LDP DU - LDP Downstream Unsolicited
o LSP - Label Switched Path
Andersson, et al. Expires October 7, 2022 [Page 4]
Internet-Draft EH Architecture April 2022
o LSR - Label Switching Router
The following concepts new for MPLS are defined:
o EH capable node - an LSR that can process Extension Headers and
announce its EH capability
o EH capable LSR - this may be used interchangeably with EH capable
node.
o EH non-capable node - an LSR that is unaware of and unable to
process Extension Headers.
o EH path - an EH path starts at the node adding an EH and ends at
the node that removes it.
3. Extension Header Basics
3.1. General Principles
Any EH capable node along an LSP may add an EH as long as it can be
verified that there is another EH capable LSR downstream that can
remove it. Any EH capable node downstream may remove an EH. An EH
path starts when one or more EHs are added and ends where the last EH
is removed. If there is no node downstream capable to remove the EH,
it MUST NOT be added. It is assumed that a control plane will make
this determination, the specification of which is outside the scope
of this document.
In the context of the MPLS EH architecture an EH capable node assumes
that all user packets on the default LSP carry EHs. As an
optimization a second parallel LSP may be instantiated using a
Forwarding Equivalence Class (FEC) that does not permit EHs, thus
indicating to the LSR that there are no EHs in the packet.
3.2. LSPs in a EH capable Network
For an EH capable LSP between two EH capable LSRs there are two label
mappings:
o first, a label mapping for the FEC that indicates that the packet
carries IP
o second, a label mapping for a new FEC indicating that there are no
EHs in the packet
Andersson, et al. Expires October 7, 2022 [Page 5]
Internet-Draft EH Architecture April 2022
3.3. EH capable nodes
EH capable nodes may process Extension Headers, i.e. add, augment,
remove or do required processing at a transit node.
An EH capable node may not add an extension header to a packet if
unless it is sure that there is a downstream node that can remove it.
If an LSP forks due to ECMP, the node that does the forking MUST be
sure that all LSP branches (which may be re-merged) eventually
terminate at an EH capable node which will remove the EH.
3.4. EH path and LSP
EH capable nodes may process Extension Headers, i.e. add, remove or
do required processing at a transit node.
Figure 1 will be used for illustration.
<------------------LSP-------------------->
A------b------c------D------E------F------G
<------------------EHP1------------------->
<------------EHP2----------->
<--------EHP3-------->
<-----EHP4---->
<-EHP5->
A, D, E, F and G are EH capable nodes
b and c are non-EH capable nodes.
Figure 1: EH path vs. LSP
LSP - the LSP originates at ingress LSR A and terminates at egress
LSR G, packets flow from A to G.
EHP1 - EHP1 originates with the EH capable node A adding an
extension header to the packet and terminates when the EH capable
node G removes the EH
Andersson, et al. Expires October 7, 2022 [Page 6]
Internet-Draft EH Architecture April 2022
EHP2 - EHP2 originates with the EH capable node A adding an
extension header to the packet and terminates when the EH capable
node E removes the EH. i.e. the EH path is shorter than the LSP
EHP3 - EHP3 originates with the EH capable node D adding an
extension header to the packet and terminates when the EH capable
node G removes the EH.
EHP4 - EHP4 originates with the EH capable node D adding an
extension header to the packet and terminates when the EH capable
node F removes the EH, i.e. it is not necessary that an EH path
originates or terminate on an MPLS LER.
EHP5 - EHP5 originates with the EH capable node F adding an
extension header to the packet and terminates when the EH capable
node G removes the EH
Further discussion on the information needed in the packet to
identify and process EHs are found in
[I-D.song-mpls-extension-header].
3.5. Announcement of EH Capability
A node that is EH capable MUST have a way to announce this capability
to other nodes in the same domain. Additions to the IGPs should be a
baseline for such capabilities.
3.6. LSP establishment with LDP Downstream on Demand (DoD) in an EH
capable network
LSPs for EH handling and processing in an MPLS network may be set up
by LDP [RFC5036], a centralized controller and/or MPLS-SR. To enable
this small extensions to the protocols are required.
In the examples in Section 3.6 and Section 3.7 we for simplicity
assume that the payload of the packet is IP. It is of course
possible that the payload will be a Pseudowire (PW) or a Virtual
Private Network (VPN). This will be described in a later version of
the document.
It is anticipated that the difference in establishment procedures for
IP, PW and VPN will be minor.
It is possible to use the simplified physical topology show in
Figure 2 which uses LDP Downstream on Demand (DoD) to illustrate how
LSP setup work in a network with a mix of EH capable and EH non-
capable nodes. In LDP DoD the action to set up an LSP is taken by
the node at the head-end of the potential LSP.
Andersson, et al. Expires October 7, 2022 [Page 7]
Internet-Draft EH Architecture April 2022
+---+ +---+ +---+ +---+ +---+
| | | | | | | | | |
| A +------+ b +------+ D +------+ E +------+ G +
| | | | | | | | | |
+---+ +---+ +---+ +---+ +---+
A, D, E, and G are EH capable nodes
b is a non-EH capable node.
Figure 2: EH topology
The following steps would be taken assuming that node A wants to set
up connectivity with node G to support EH handling and processing:
o A sends an LDP Label Request message to b, indicating that an EH
capable LSP should be set up to G. A keeps track of the
outstanding request.
o b is not EH capable and treat the Label Request as a normal
request, however, the information indicating that an EH capable
LSP is requested is transitive and sent to D.
o D receives the Label Request, forwards it to E, and keeps track of
the outstanding request.
o E treats the label request the same way as D, and forward it to G.
o G receives the label request, finds out that it is the egress node
for this LSP. G allocates two labels one for the IP FEC and one
for the new "no EH present" FEC. G sends a label mapping to E
with both labels, and asks E to PHP both LSPs.
o E receives the label mapping and installs PHP for both the IP FEC
and for the new "no EH present"-FEC. E allocates two labels one
for the IP FEC (label value 201) and one for the new FEC (label
value 301). E sends a label mapping message to D, with the two
labels.
o D receives the label mapping message and installs label 201 for
the IP FEC and label value 301 for the new FEC. Since D know that
b is not EH capable it will only allocate one label (202 for the
IP FEC) and send a label mapping message to with that label.
o b receives the label mapping messages and installs label 202 for
the IP FEC. Since b is not EH capable it will only allocate one
Andersson, et al. Expires October 7, 2022 [Page 8]
Internet-Draft EH Architecture April 2022
label (203 for the IP FEC). b sends a label mapping message to A
with that label.
o A receives the label mapping and installs label value 203 for the
IP FEC.
This will result in installed labels like this.
+---+ +---+ +---+ +---+ +---+
| |...203...| |...202...| |...201...| |...php...| |
| A +---------+ b +---------+ D +---------+ E +---------+ G +
| | | | | |...301...| |...php...| |
+---+ +---+ +---+ +---+ +---+
A, D, E and G are EH capable nodes.
b is a non-EH capable node.
Figure 3: EH topology
3.7. LSP establishment with LDP Downstream Unsolicited (DU) in an EH
capable network
In LDP Downstream Unsolicited (DU) the initiative to establish a LSP
is taken by the egress router. The egress will establish an LSP to
every prefix it learns of from the IGP. With the exception from how
the set up of the LSP(s) are triggered the label mappings are similar
to how it is done with LDP DoD.
The same topoplogy as in the LDP DoD example Figure 2 will be used
for LDP DU.
o G learns that an EH capable LSP to egress LSR A is needed. G
allocates two labels one for the IP FEC and one for the new "no EH
present" FEC. G sends a label mapping to E with both labels, and
asks E to PHP both LSPs.
o E receives the label mapping and installs PHP for both the IP FEC
and for the new "no EH present"-FEC. E allocates two labels one
for the IP FEC (label value 201) and one for the new FEC (label
value 301). E sends a label mapping message to D, with the two
labels.
o D receives the label mapping message and installs label 201 for
the IP FEC and label value 301 for the new FEC. Since D know that
Andersson, et al. Expires October 7, 2022 [Page 9]
Internet-Draft EH Architecture April 2022
b is not EH capable it will only allocate one label (202 for the
IP FEC) and send a label mapping message to with that label.
o b receives the label mapping messages and installs label 202 for
the IP FEC. Since b is not EH capable it will only allocate one
label (203 for the IP FEC). b sends a label mapping message to A
with that label.
o A receives the label mapping and installs label value 203 for the
IP FEC.
o This will result in the exact the same label mappings as in the
Dod Example, see Figure 3.
3.8. Forwarding Behavior of EH Capable Nodes
A EH capable node will always search the label stack for EHs, with
the exception of when a packet is received on the new FEC (no EH
present).
Non-EH capable nodes will never search the label stack for EHs.
Given the configuration in Figure 3 packets will be forwarded as
follows through the network.
If Node A sends a packet with an extension header folling the label
stack:
1. A sends a packet with label 203 with an EH after the label stack
to b
2. b receives the packet and swaps the label to 202 and forward it
to D.
3. D receives the packet, and since D is EH capable it will search
the stack to find an EH-indicator. Since there is EH present, D
will decide whether it should process the extension header or
not. When that decision is taken and potential processing is
done, D will swap the label to 201 and send it to E.
4. E receives the packet on LSP with a FEC that indicates that "EH
may present" and will search the packet for an EH. When the EH
is found by E it will, if required, process the EH, after that
the top label is popped and the packet is forwarded to G.
5. G receives the packet, it will search the label stack to find the
EHI. It will find the EH and since G is the egress node it will
Andersson, et al. Expires October 7, 2022 [Page 10]
Internet-Draft EH Architecture April 2022
do necessary processing and as a last step remove the EH. G will
forward the packet based on the IP address.
If Node A sends a packet without an extension header:
1. A sends a packet with label 203 without an EH to b
2. b receives the packet and swaps the label to 202 and forward it
to D.
3. D receives the packet, and since D is EH capable it will search
the stack to find an EH. Since there is no EH present, D will
swap the label to 301 and send it to E (FEC indicates no EH
present).
4. E receives the packet on FEC "no EH present" and understand that
it does not need to search the packet for an EH. E pops the
label and forward to G
5. G receives the packet on FEC "no EH present" and understand that
it does not need to search the packet for an EH. G will forward
it based on the IP address.
3.9. EH for RSVP-TE tunnels
Extension Headers for RSVP-TE tunnels is for further study.
Essentially it expected to be similzar to the LDP case.
3.10. Ways to indicate an EH after the Label Stack
There are several ways to indicate the presence of EHs after the
label stack. This will be discussed in a separate document.
4. EH in VPNs
TBA
5. EH and MPLS-SR
TBA
6. Extension Header Applications
TBA
Andersson, et al. Expires October 7, 2022 [Page 11]
Internet-Draft EH Architecture April 2022
7. EH distribution and EH capability announcement
TBA
8. Security Considerations
TBA
9. IANA Considerations
MPLS extension headers will require code point allocations from more
than one IANA registry. It is not yet decided which document that
will make which allocation.
However, tentatively the "No EH present" FEC will be assigned from
this document.
IANA is requested to allocate lowest free value from the "IETF
Review" range as new FEC from the "Forwarding Equivalence Class (FEC)
Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters", like this:
+-------+-----+----------+------------------+-----------+-----------+
| Value | Hex | Name | Label | Reference | Note/Reg. |
| | | | Distribution | | Date |
| | | | Discipline | | |
+-------+-----+----------+------------------+-----------+-----------+
| TBD | TBD | No EH | DoD or DU | This | TBA |
| | | present | | Document | |
+-------+-----+----------+------------------+-----------+-----------+
Table 1: No EH present
10. Acknowledgements
-
-
11. References
11.1. Normative References
[]
Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang,
"MPLS Extension Header", draft-song-mpls-extension-
header-06 (work in progress), January 2022.
Andersson, et al. Expires October 7, 2022 [Page 12]
Internet-Draft EH Architecture April 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>.
11.2. Informative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
Authors' Addresses
Loa Andersson
Bronze Dragon Consulting
Email: loa@pi.nu
James N Guichard
Futurewei Technologies
Email: james.n.guichard@futurewei.com
Haoyu Song
Futurewei Technologies
Email: haoyu.song@futurewei.com
Stewart Bryant
University of Surrey
Email: stewart.bryant@gmail.com
Andersson, et al. Expires October 7, 2022 [Page 13]