< draft-song-mpls-extension-header-04.txt   draft-song-mpls-extension-header-05.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: October 31, 2021 T. Zhou Expires: January 11, 2022 T. Zhou
Huawei Huawei
L. Andersson L. Andersson
Bronze Dragon Consulting Bronze Dragon Consulting
April 29, 2021 Z. Zhang
Juniper Networks
July 10, 2021
MPLS Extension Header MPLS Extension Header
draft-song-mpls-extension-header-04 draft-song-mpls-extension-header-05
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 48 skipping to change at page 2, line 4
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 January 11, 2022.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4 2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4
3. Type of MPLS Extension Headers . . . . . . . . . . . . . . . 7 3. Type of MPLS Extension Headers . . . . . . . . . . . . . . . 8
4. Operation on MPLS Extension Headers . . . . . . . . . . . . . 7 4. Operation on MPLS Extension Headers . . . . . . . . . . . . . 8
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Motivation 1. Motivation
Some applications require adding instructions and/or metadata to user Some applications require adding instructions and/or metadata to user
packets within a network. Such examples include In-situ OAM (IOAM) packets within a network. Such examples include In-situ OAM (IOAM)
[I-D.ietf-ippm-ioam-data] and Service Function Chaining (SFC) [I-D.ietf-ippm-ioam-data] and Service Function Chaining (SFC)
[RFC7665]. New applications are emerging. It is possible that the [RFC7665]. New applications are emerging. It is possible that the
instructions and/or metadata for multiple applications are stacked instructions and/or metadata for multiple applications are stacked
together in one packet to support a compound service. together in one packet to support a compound service.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
+--------+--------+--------+--------+ < +--------+--------+--------+--------+ <
| | | | | |
~ Upper Layer Headers/Payload ~ > MPLS Payload ~ Upper Layer Headers/Payload ~ > MPLS Payload
| | | (as is) | | | (as is)
+--------+--------+--------+--------+ / +--------+--------+--------+--------+ /
Figure 1: MPLS with Extension Headers Figure 1: MPLS with Extension Headers
Following the MPLS label stack is the 4-octet Header of Extension Following the MPLS label stack is the 4-octet Header of Extension
Headers (HEH), which indicates the total number of extension headers Headers (HEH), which indicates the total number of extension headers
in this packet, the overall length of the extension headers, and the in this packet, the overall length of the extension headers, the type
type of the next header. The format of the HEH is shown in Figure 2. of the original upper layer header, and the type of the next header.
The format of the HEH is shown in Figure 2.
0 1 2 3 0 1 2 3
0123 45678901 234567890123 45678901 0123 4567 89012345 67890123 45678901
+----+--------+------------+--------+ +----+----+--------+--------+--------+
| R | EHCNT | EHTLEN | NH | | R |EHC | EHTL | OUL | NH |
+----+--------+------------+--------+ +----+----+--------+--------+--------+
Figure 2: HEH Format Figure 2: HEH Format
The meaning of the fields in an HEH is as follows: The meaning of the fields in an HEH is as follows:
R: 4-bit reserved. R: 4-bit reserved. The nibble value means to avoid conflicting with
IP version numbers.
EHCNT: 8-bit unsigned integer for the Extension Header Counter. EHC: 4-bit unsigned integer for the Extension Header Counter. This
This field keeps the total number of extension headers included in field keeps the total number of extension headers included in this
this packet. It does not count the original upper layer protocol packet. It does not count the original upper layer protocol
headers. headers. At most 15 EHs are allowed in one packet.
EHTLEN: 12-bit unsigned integer for the Extension Header Total EHTL: 8-bit unsigned integer for the Extension Header Total Length
Length in 4-octet units. This field keeps the total length of the 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.
OUL: 8-bit Original Upper Layer protocol number indicating the
original upper layer protocol type. It can be set to "UNKNOWN" if
unknown.
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 value of the reserved nibble needs further consideration. The The value of the reserved nibble needs further consideration. The
EHCNT field can be used to keep track of the number of extension EHC 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 EHTL 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 OUL field can help identify the type of the
original upper layer protocol.
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 67890123 45678901
+--------+--------+----------------+ +--------+--------+--------+-------+
| NH | HLEN | | | NH | HLEN |EXT | |
+--------+--------+ + +--------+--------+--------+ |
| | | |
~ 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 indicator 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.
EXT: 8-bit optional type extension. To save the Next Header numbers
and extend the number space, it is possible to use one "Next
Header" code to cover a set of sub-types. Each sub-type is
assigned a new code in a different name space. This field is
optional and it is only specified for some specific EH type.
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 can share the same value registry for IPv4/ EHs. The encoding of NH can share the same value registry for IPv4/
IPv6 protocol numbers. Values for new EH types shall be assigned by IPv6 protocol numbers. Values for new EH types shall be assigned by
IANA. 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 some
special values, which shall be assigned by IANA as well: 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), for example, the control packets with only extension header(s), for example, the control packets
for control or the probe packets for measurements. Note that for control or the probe packets for measurements. Note that
value 59 was reserved for "IPv6 No Next Header" indicator. It may value 59 was reserved for "IPv6 No Next Header" indicator. It may
be possible for MPLS EH to share this value. 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.
MPLS: Indicates that the original upper layer protocol is still MPLS
and another MPLS label stack follows.
Note that the original upper layer protocol can be of type "MPLS",
which implies that in a packet there might be multiple label stacks
separated by EHs. Having more than one independent label stack is
not new. For example, A Bier header could separate the transport/
bier labels and the payload labels; An MPLS PW network could be
implemented on the top of another infrastructure MPLS network. In
such cases, we have the flexibility to apply different services to
different label stacks.
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 need to be processed on path nodes within the removed. The EHs that need to be processed on path nodes within the
MPLS tunnel are of the HBH type. However, any node in the tunnel can MPLS tunnel are of the HBH type. However, any node in the tunnel can
be configured to ignore an HBH EH, even if it is capable of be configured to ignore an HBH EH, even if it is capable of
processing it. processing it.
skipping to change at page 10, line 28 skipping to change at page 11, line 13
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
10.2. Informative References 10.2. Informative References
[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. P., Pignataro,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T.,
D., Lapukhov, P., and R. Chang, "Encapsulations for In- Mozes, D., Lapukhov, P., and R. Chang, "Encapsulations for
situ OAM Data", draft-brockners-inband-oam-transport-05 In-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-12 (work in for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in
progress), February 2021. 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., Garvia, P. C., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "Segment Routing over IPv6
draft-ietf-spring-srv6-network-programming-28 (work in (SRv6) Network Programming", draft-ietf-spring-srv6-
progress), December 2020. network-programming-28 (work in 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-01 (work in progress), March 2021. indicator-03 (work in progress), July 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., Bernier, D., Decraene, B.,
d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, Yadlapalli, C., Henderickx, W., Salsano, S., and S. Ma,
S., and S. Ma, "Segment Routing for Service Chaining", "Segment Routing for Service Chaining", draft-xu-clad-
draft-xu-clad-spring-sr-service-chaining-00 (work in spring-sr-service-chaining-00 (work in progress), December
progress), December 2017. 2017.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009, DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>. <https://www.rfc-editor.org/info/rfc5586>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
Authors' Addresses Authors' Addresses
Haoyu Song (editor) Haoyu Song (editor)
Futurewei Technologies Futurewei Technologies
2330 Central Expressway
Santa Clara Santa Clara
USA USA
Email: haoyu.song@futurewei.com Email: haoyu.song@futurewei.com
Zhenbin Li Zhenbin Li
Huawei Huawei
156 Beiqing Road
Beijing, 100095 Beijing
P.R. China P.R. China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Tianran Zhou Tianran Zhou
Huawei Huawei
156 Beiqing Road
Beijing, 100095 Beijing
P.R. China P.R. China
Email: zhoutianran@huawei.com Email: zhoutianran@huawei.com
Loa Andersson Loa Andersson
Bronze Dragon Consulting Bronze Dragon Consulting
Stockholm Stockholm
Sweden Sweden
Email: loa@pi.nu Email: loa@pi.nu
Zhaohui Zhang
Juniper Networks
Boston
USA
Email: zzhang@juniper.net
 End of changes. 28 change blocks. 
56 lines changed or deleted 83 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/