< draft-song-mpls-extension-header-03.txt   draft-song-mpls-extension-header-04.txt >
MPLS H. Song, Ed. MPLS H. Song, Ed.
Internet-Draft Futurewei Technologies Internet-Draft Futurewei Technologies
Intended status: Standards Track Z. Li Intended status: Standards Track Z. Li
Expires: September 11, 2021 T. Zhou Expires: October 31, 2021 T. Zhou
Huawei Huawei
L. Andersson L. Andersson
Bronze Dragon Consulting Bronze Dragon Consulting
March 10, 2021 April 29, 2021
MPLS Extension Header MPLS Extension Header
draft-song-mpls-extension-header-03 draft-song-mpls-extension-header-04
Abstract Abstract
Motivated by the need to support multiple in-network services and Motivated by the need to support multiple in-network services and
functions in an MPLS network, this document describes a generic and functions in an MPLS network, this document describes a generic and
extensible method to encapsulate extension headers into MPLS packets. extensible method to encapsulate extension headers into MPLS packets.
The encapsulation method allows stacking multiple extension headers The encapsulation method allows stacking multiple extension headers
and quickly accessing any of them as well as the original upper layer and quickly accessing any of them as well as the original upper layer
protocol header and payload. We show how the extension header can be protocol header and payload. We show how the extension header can be
used to support several new network applications and optimize some used to support several new network applications and optimize some
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2021. This Internet-Draft will expire on October 31, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
The encapsulation of the new header(s) poses some challenges to MPLS The encapsulation of the new header(s) poses some challenges to MPLS
networks, because the MPLS protocol header contains no explicit networks, because the MPLS protocol header contains no explicit
indicator for the upper layer protocols by design. We leave the indicator for the upper layer protocols by design. We leave the
discussion on the indicator of new header(s) in an MPLS packet to discussion on the indicator of new header(s) in an MPLS packet to
another companion document [I-D.song-mpls-eh-indicator]. In this another companion document [I-D.song-mpls-eh-indicator]. In this
document, we focus on the encode and encapsulation of new headers in document, we focus on the encode and encapsulation of new headers in
an MPLS packet. an MPLS packet.
The similar problem has been tackled for some particular application The similar problem has been tackled for some particular application
before. However, the solutions have some drawbacks: before. However, these solutions have some drawbacks:
o These solutions rely on either the built-in next-protocol o The solutions rely on either the built-in next-protocol indicator
indicator in the header or the knowledge of the format and size of in the header or the knowledge of the format and size of the
the header to access the following packet data. The node is header to access the following packet data. The node is required
required to be able to parse the new header, which is unrealistic to be able to parse the new header, which is unrealistic in an
in an incremental deployment environment. incremental deployment environment.
o A piecemeal solution often assumes the new header is the only o These works only provide piecemeal solution which assumes the new
extra header and its location in the packet is fixed by default. header is the only extra header and its location in the packet is
It is impossible or difficult to support multiple new headers in fixed by default. It is impossible or difficult to support
one packet due to the conflicted assumption. multiple new headers in one packet due to the conflicted
assumption.
To solve these issues, we propose to introduce extension header as a o Some previous work such as G-ACH [RFC5586] was explicitly defined
general and extensible means to support new in-network functions and for control channel only but what we need is the user packet
service.
To solve these problems, we introduce extension header as a general
and extensible means to support new in-network functions and
applications in MPLS networks. The idea is similar to IPv6 extension applications in MPLS networks. The idea is similar to IPv6 extension
headers which offer a huge innovation potential (e.g, network headers which offer a huge innovation potential (e.g, network
security, SRv6 [RFC8754], network programming security, SRv6 [RFC8754], network programming
[I-D.ietf-spring-srv6-network-programming], SFC [I-D.ietf-spring-srv6-network-programming], SFC
[I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the [I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the
existing of extension headers, it is straightforward to introduce new existence of extension headers, it is straightforward to introduce
in-network services into IPv6 networks. For example, it has been new in-network services into IPv6 networks. For example, it has been
proposed to carry IOAM header [I-D.brockners-inband-oam-transport] as proposed to carry IOAM header [I-D.brockners-inband-oam-transport] as
a new extension header in IPv6 networks. a new extension header option in IPv6 networks.
Nevertheless, IPv6 is not perfect either. It has two main issues. Nevertheless, IPv6 EH is not perfect either. It has three issues:
First, IPv6's header is large compared to MPLS, claiming extra
bandwidth overhead and complicating the packet processing. We prefer o IPv6's header is large compared to MPLS, claiming extra bandwidth
to retain the header compactness in MPLS networks. Second, IPv6's overhead and complicating the packet processing. We prefer to
extension headers are chained with the original upper layer protocol retain the header compactness in MPLS networks.
headers in a flat stack. One must scan all the extension headers to
access the upper layer protocol headers and the payload. This is o IPv6's extension headers are chained with the original upper layer
inconvenient and raises some performance concerns for some protocol headers in a flat stack. One must scan all the extension
applications (e.g., DPI and ECMP). The new scheme for MPLS header headers to access the upper layer protocol headers and the
extension needs to address these issues too. payload. This is inconvenient and raises some performance
concerns for some applications(e.g., DPI and ECMP). The new
scheme for MPLS header extension needs to address these issues
too.
o [RFC8200] enforces many constraints to IPv6 extension headers
(e.g., EH can only be added or deleted by the end nodes specified
by the IP addresses in the IPv6 header, and there is only one Hop-
by-Hop EH that can be processed on the path nodes), which are not
suitable for MPLS networks. For example, MPLS label stacks are
added and changed in network, and there could be tunnel within
tunnel, so the extension headers need more flexibility.
2. MPLS Extension Header 2. MPLS Extension Header
From the previous discussion, we have laid out the design From the previous discussion, we have laid out the design
requirements to support extension headers in MPLS networks: requirements to support extension headers in MPLS networks:
Performance: If possible, unnecessary label stack scanning for a Performance: Unnecessary label stack scanning for a label and the
label and extension header stack scanning for the upper layer full extension header stack scanning for the upper layer protocol
protocol should be avoided. should be avoided. The extension headers a node needs to process
should be located as close to the MPLS label stack as possible.
Each extension header is better to serve only one application to
avoid the need of packing multiple TLV options in one extension
header.
Scalability: New applications can be easily supported by introducing Scalability: New applications can be supported by introducing new
new extension headers. Multiple extension headers can be easily extension headers. Multiple extension headers can be easily
stacked together to support multiple services simultaneously. stacked together to support multiple services simultaneously.
Backward Compatibility: Legacy devices which do not recognize the Backward Compatibility: Legacy devices which do not recognize the
extension header option should still be able to forward the extension header option should still be able to forward the
packets as usual. If a device recognize some of the extension packets as usual. If a device recognize some of the extension
headers but not the others in an extension header stack, it can headers but not the others in an extension header stack, it can
process the known headers only while ignoring the others. process the known headers only while ignoring the others.
Flexibility: A node can be configured to process or not process any
EH. Any tunnel end nodes in the MPLS domain can add new EH to the
packets which shall be removed on the other end of the tunnel.
We assume the MPLS label stack has included some indicator of the We assume the MPLS label stack has included some indicator of the
extension header(s). The actual extension headers are inserted extension header(s). The actual extension headers are inserted
between the MPLS label stack and the original upper layer packet between the MPLS label stack and the original upper layer packet
header. The format of the MPLS packets with extension headers is header. The format of the MPLS packets with extension headers is
shown in Figure 1. shown in Figure 1.
0 31 0 31
+--------+--------+--------+--------+ \ +--------+--------+--------+--------+ \
| | | | | |
~ MPLS Label Stack ~ | ~ MPLS Label Stack ~ |
skipping to change at page 6, line 19 skipping to change at page 6, line 19
this packet. It does not count the original upper layer protocol this packet. It does not count the original upper layer protocol
headers. headers.
EHTLEN: 12-bit unsigned integer for the Extension Header Total EHTLEN: 12-bit unsigned integer for the Extension Header Total
Length in 4-octet units. This field keeps the total length of the Length in 4-octet units. This field keeps the total length of the
extension headers in this packet, not including the HEH itself. extension headers in this packet, not including the HEH itself.
NH: 8-bit selector for the Next Header. This field identifies the NH: 8-bit selector for the Next Header. This field identifies the
type of the header immediately following the HEH. type of the header immediately following the HEH.
The EHCNT field can be used to keep track of the number of extension The value of the reserved nibble needs further consideration. The
EHCNT field can be used to keep track of the number of extension
headers when some headers are inserted or removed at some network headers when some headers are inserted or removed at some network
nodes. The EHLEN field can help to skip all the extension headers in nodes. The EHLEN field can help to skip all the extension headers in
one step if the original upper layer protocol headers or payload need one step if the original upper layer protocol headers or payload need
to be accessed. to be accessed.
The format of an Extension Header (EH) is shown in Figure 3. The format of an Extension Header (EH) is shown in Figure 3.
0 1 2 3 0 1 2 3
01234567 89012345 6789012345678901 01234567 89012345 6789012345678901
+--------+--------+----------------+ +--------+--------+----------------+
skipping to change at page 6, line 41 skipping to change at page 6, line 42
+--------+--------+ + +--------+--------+ +
| | | |
~ Header Specific Data ~ ~ Header Specific Data ~
| | | |
+--------+--------+----------------+ +--------+--------+----------------+
Figure 3: EH Format Figure 3: EH Format
The meaning of the fields in an EH is as follows: The meaning of the fields in an EH is as follows:
NH: 8-bit selector for the Next Header. This field identifies the NH: 8-bit indicator for the Next Header. This field identifies the
type of the EH immediately following this EH. type of the EH immediately following this EH.
HLEN: 8-bit unsigned integer for the Extension Header Length in HLEN: 8-bit unsigned integer for the Extension Header Length in
4-octet units, not including the first 4 octets. 4-octet units, not including the first 4 octets.
Header Specific Data: Variable length field for the specification of Header Specific Data: Variable length field for the specification of
the EH. This field is 4-octet aligned. the EH. This field is 4-octet aligned.
The extension headers as well as the first original upper layer The extension headers as well as the first original upper layer
protocol header are chained together through the NH field in HEH and protocol header are chained together through the NH field in HEH and
EHs. The encoding of NH uses the same values as the IPv4 protocol EHs. The encoding of NH can share the same value registry for IPv4/
field. Values for new EH types shall be assigned by IANA. IPv6 protocol numbers. Values for new EH types shall be assigned by
IANA.
Specifically, the NH field of the last EH in a chain can have two Specifically, the NH field of the last EH in a chain can have two
special values, which shall be assigned by IANA: special values, which shall be assigned by IANA as well:
NONE (No Next Header): Indicates that there is no other header and NONE (No Next Header): Indicates that there is no other header and
payload after this header. This can be used to transport packets payload after this header. This can be used to transport packets
with only extension header(s). with only extension header(s), for example, the control packets
for control or the probe packets for measurements. Note that
value 59 was reserved for "IPv6 No Next Header" indicator. It may
be possible for MPLS EH to share this value.
UNKNOWN (Unknown Next Header): Indicates that the type of the header UNKNOWN (Unknown Next Header): Indicates that the type of the header
after this header is unknown. This is intended to be compatible after this header is unknown. This is intended to be compatible
with the original MPLS design in which the upper layer protocol with the original MPLS design in which the upper layer protocol
type is unknown from the MPLS header alone. type is unknown from the MPLS header alone.
3. Type of MPLS Extension Headers 3. Type of MPLS Extension Headers
Basically, there are two types of MPLS EHs: HBH and E2E. E2E means Basically, there are two types of MPLS EHs: HBH and E2E. E2E means
that the EH is only supposed to be inserted/removed and processed at that the EH is only supposed to be inserted/removed and processed at
the MPLS tunnel end points where the MPLS header is inserted or the MPLS tunnel end points where the MPLS header is inserted or
removed. The EHs that are inserted or removed within the MPLS tunnel removed. The EHs that need to be processed on path nodes within the
are of the HBH type. However, any node in the tunnel can be MPLS tunnel are of the HBH type. However, any node in the tunnel can
configured to ignore an HBH EH, even if it is capable of processing be configured to ignore an HBH EH, even if it is capable of
the EH. processing it.
If there are two types of EHs in a packet, the HBH EHs must take If there are two types of EHs in a packet, the HBH EHs must take
precedence over the E2E EHs. precedence over the E2E EHs.
Making a distinction of the EH types and ordering the EHs in a packet Making a distinction of the EH types and ordering the EHs in a packet
help improve the forwardidng performance. For example, if a node help improve the forwardidng performance. For example, if a node
within an MPLS tunnel finds only E2E EHs in a packet, it can avoid within an MPLS tunnel finds only E2E EHs in a packet, it can avoid
scanning the EH list. scanning the EH list.
4. Operation on MPLS Extension Headers 4. Operation on MPLS Extension Headers
skipping to change at page 8, line 20 skipping to change at page 8, line 23
location. The NH field of Y is copied from the previous EH's NH location. The NH field of Y is copied from the previous EH's NH
field (or from the HEH's NH field, if Y is the first EH in the field (or from the HEH's NH field, if Y is the first EH in the
chain). The previous EH's NH value, or, if Y is the first EH in the chain). The previous EH's NH value, or, if Y is the first EH in the
chain, the HEH's NH, is set to the header value of Y. chain, the HEH's NH, is set to the header value of Y.
Deleting an EH simply reverses the above operation. If the deleted Deleting an EH simply reverses the above operation. If the deleted
EH is the last one, the EH indicator and HEH can also be removed. EH is the last one, the EH indicator and HEH can also be removed.
When processing an MPLS packet with extension headers, the node needs When processing an MPLS packet with extension headers, the node needs
to scan through the entire EH chain and process the EH one by one. to scan through the entire EH chain and process the EH one by one.
The node should ignore any unrecognized EH. The node should ignore any unrecognized EH or the EH that is
configured as "No Processing".
The EH can be categorized into HBH or E2E. If the EH indicator can The EH can be categorized into HBH or E2E. Since EHs are ordered
indicate the EH types and the EHs are ordered (i.e., HBH EHs are based on their type(i.e., HBH EHs are located before E2E EHs), a node
located before E2E EHs), a node can avoid some unnecessary EH scan. can avoid some unnecessary EH scan.
5. Use Cases 5. Use Cases
In this section, we show how MPLS extension header can be used to In this section, we show how MPLS extension header can be used to
support several new network applications. support several new network applications.
In-situ OAM: In-situ OAM (IOAM) records flow OAM information within In-situ OAM: In-situ OAM (IOAM) records flow OAM information within
user packets while the packets traverse a network. The user packets while the packets traverse a network. The
instruction and collected data are kept in an IOAM header instruction and collected data are kept in an IOAM header
[I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network, [I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network,
skipping to change at page 9, line 21 skipping to change at page 9, line 26
only, it will stop searching the EH stack when the IOAM EH is found. only, it will stop searching the EH stack when the IOAM EH is found.
6. Security Considerations 6. Security Considerations
TBD TBD
7. IANA Considerations 7. IANA Considerations
This document requests IANA to assign two new Internet Protocol This document requests IANA to assign two new Internet Protocol
Numbers from the "Protocol Numbers" Registry to indicate "No Next Numbers from the "Protocol Numbers" Registry to indicate "No Next
Header" or "Unknown Next Header". Header" and "Unknown Next Header".
This document does not create any new registries. This document does not create any other new registries.
8. Contributors 8. Contributors
The other contributors of this document are listed as follows. The other contributors of this document are listed as follows.
o James Guichard o James Guichard
o Stewart Bryant o Stewart Bryant
o Andrew Malis o Andrew Malis
skipping to change at page 10, line 31 skipping to change at page 10, line 36
[I-D.brockners-inband-oam-transport] [I-D.brockners-inband-oam-transport]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
D., Lapukhov, P., and R. Chang, "Encapsulations for In- D., Lapukhov, P., and R. Chang, "Encapsulations for In-
situ OAM Data", draft-brockners-inband-oam-transport-05 situ OAM Data", draft-brockners-inband-oam-transport-05
(work in progress), July 2017. (work in progress), July 2017.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in
progress), November 2020. progress), February 2021.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-28 (work in draft-ietf-spring-srv6-network-programming-28 (work in
progress), December 2020. progress), December 2020.
[I-D.song-mpls-eh-indicator] [I-D.song-mpls-eh-indicator]
Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for
MPLS Extension Header Indicator", draft-song-mpls-eh- MPLS Extension Header Indicator", draft-song-mpls-eh-
indicator-00 (work in progress), February 2019. indicator-01 (work in progress), March 2021.
[I-D.xu-clad-spring-sr-service-chaining] [I-D.xu-clad-spring-sr-service-chaining]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,
S., and S. Ma, "Segment Routing for Service Chaining", S., and S. Ma, "Segment Routing for Service Chaining",
draft-xu-clad-spring-sr-service-chaining-00 (work in draft-xu-clad-spring-sr-service-chaining-00 (work in
progress), December 2017. progress), December 2017.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Authors' Addresses Authors' Addresses
Haoyu Song (editor) Haoyu Song (editor)
Futurewei Technologies Futurewei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara Santa Clara
USA USA
Email: haoyu.song@futurewei.com Email: haoyu.song@futurewei.com
 End of changes. 27 change blocks. 
53 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/