MPLS H. Song, Ed.
Internet-Draft Z. Li
Intended status: Informational T. Zhou
Expires: August 19, 2019 Huawei
L. Andersson
Bronze Dragon Consulting
February 15, 2019
Options for MPLS Extension Header Indicator
draft-song-mpls-eh-indicator-00
Abstract
This document describes the schemes that indicates the presence of
the MPLS extension header(s) following the MPLS label stack. After a
thorough evaluation of these options by comparing their pros and
cons, one should be chosen as the final scheme for MPLS extension
header indicator.
Requirements 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.
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 August 19, 2019.
Song, et al. Expires August 19, 2019 [Page 1]
Internet-Draft MPLS Extension Header Indicator February 2019
Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Dedicated Extension Header Label . . . . . . . . . . . . . . 3
2.1. Special Purpose Label . . . . . . . . . . . . . . . . . . 3
2.2. Extension Label plus an Extended Special Purpose Label . 3
3. Generic Associated Channel Extension . . . . . . . . . . . . 4
3.1. GAL and Associated Channel Header . . . . . . . . . . . . 4
3.2. GAL and a Different Nibble Value . . . . . . . . . . . . 4
4. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 5
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The document [I-D.song-mpls-extension-header] presents the
motivation, specification, and use cases of MPLS Extension Header
(EH). However, multiple options are possible to indicate the
presence of the extension header(s).
We propound three categories of methods which can be further
partitioned into five unique schemes. Four of them use explicit data
plane encoding to indicate the EH and the last one implies the EH
through control plane configuration. This document details and
Song, et al. Expires August 19, 2019 [Page 2]
Internet-Draft MPLS Extension Header Indicator February 2019
compares these schemes, in order to foster further discussions until
a final decision is made.
2. Dedicated Extension Header Label
A straightforward method is to directly encode an Extension Header
Label (EHL) in the MPLS label stack. Two derived schemes are as
follows.
2.1. Special Purpose Label
A new special purpose label, EHL, can be used to indicate EHs. As
specified in [RFC7274], so far eight special purpose label values are
still left unsigned by IANA (which are 4 to 6 and 8 to 12). This
single label scheme is elegant but arguably demands a scarce
resource. We cannot rule out the possibility of requiring more than
one label value to differentiate EH classes (e.g., Hop-by-Hop, End-
to-End, or both). If this happens, it can only aggravate the
situation.
Another benefit of this scheme is that an EHL can potentially be
located anywhere in an MPLS label stack. It is easier and quicker
for a router to figure out the existence of extension header(s) if
the EHL is close to or at the top of the label stack. However, if
there are legacy devices which can reach the EHL but do not recognize
it in a network, then for backward compatibility, the EHL must be
located at the bottom of the stack (i.e., only the MPLS tunnel ends
and EHL-aware nodes will look up and process it).
The format of an EHL is the same as an MPLS label. The first 20-bit
label value will be assigned by IANA. The BoS bit is used to
indicate the location of the label. The other fields, CoS and TTL,
currently have no use in the context of EHL. However, these two
fields can potentially be used to encode other information, which is
beyond the scope of this document.
2.2. Extension Label plus an Extended Special Purpose Label
[RFC7274] specifies the Extension Label (XL) with the value of 15.
An extended special purpose label (ESPL) following XL can be used as
EHL. A large number of ESPL values are available for allocation.
The XL+EHL scheme eases the concern on the reserved label space at
the cost of one more label in the label stack.
Except for the fact that one more label is needed, The XL+EHL scheme
shares the same property as the single special purpose EHL scheme.
Song, et al. Expires August 19, 2019 [Page 3]
Internet-Draft MPLS Extension Header Indicator February 2019
3. Generic Associated Channel Extension
The similar "header extension" requirement for MPLS has led to some
proposals before. A special Generic Associated Channel Label (GAL)
[RFC5586] with the value of 13 has been assigned to support the
identification of an Associated Channel Header (ACH). We can extend
this existing mechanism to encode the MPLS EH indicator.
3.1. GAL and Associated Channel Header
The ACH is located below the bottom label. It has a 16-bit Channel
Type field which provides abundant space to encode the MPLS EH
indicator. This scheme has the same header overhead as the XL+EHL
scheme. The format is depicted in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (13) | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Extension Header Indicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HEH and EH(s) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Associated Channel Header as Extension Header Indicator
GAL has several applications already yet its heritage also has
several limitations. The GAL must be located at the bottom of a
label stack for its chief use cases such as MPLS-TP. So a router
needs to search the entire label stack for the BoS bit and check if
the corresponding label is GAL. This can impact the performance when
the label stack is deep. A more serious concern is that [RFC5586]
states that GAL+ACH MUST NOT be used to transport user traffic and an
ACH is supposed to be followed by a non-service payload.
None of these is insurmountable but it does require an overhaul of
the existing RFC in order to extend the usage of GAL.
3.2. GAL and a Different Nibble Value
To avoid changing the established semantics of ACH, a variation can
be used. ACH starts with a nibble value "0001". A different nibble
value may be used to redefine the remaining part of the word. The
idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define
a Metadata Channel Header (MCH) with the leading nibble value "0000".
Song, et al. Expires August 19, 2019 [Page 4]
Internet-Draft MPLS Extension Header Indicator February 2019
Similarly, we can use another nibble value (e.g., "0010") to define a
new header, namely the MPLS Extension Header Indicator (EHI).
The format of the GAL and EHI is depicted in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (13) | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0|Version| Reserved | Extension Header Class |<-EHI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HEH and EH(s) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extension Header Indicator Format
The Extension Header Class field in EHI is used to differentiate the
extension headers. Potentially there are three classes: Hop-by-Hop
(HbH), End-to-End (E2E), or both. If finally we decide to not
differentiate the extension headers, we have the opportunity to merge
the HEH (see [I-D.song-mpls-extension-header] for details) into EHI,
so we can reduce the header overhead by four bytes. The header
format is depicted in Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (13) | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| EHCNT | EHTLEN | NH |<-HEH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| EH(s) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Merge HEH to EHI
4. Configured FEC Labels
It is also possible to use FEC labels to indicate the presence of
extension headers. An FEC label has the same forwarding semantics as
the original label, but it also means that one or more extension
headers exist below the label stack.
Song, et al. Expires August 19, 2019 [Page 5]
Internet-Draft MPLS Extension Header Indicator February 2019
Although this approach avoids the need of new header encoding
standards, it introduces a good deal of complexity into the control
plane. Since every label needs an FEC label to indicate EH, this
scheme also significantly reduces the available label space. Another
issue is that this solution may not work for incremental deployment
where some legacy routers cannot understand and apply the FEC labels
for EH. Moreover, this configuration-based solution certainly makes
the cross-domain interoperability more difficult. Hence, this is the
least preferred option. We only include it here for the completeness
of the discussion.
5. Summary
Evidenced by the existing and emerging use cases, MPLS networks need
a standard way to support extension headers. In Figure 4, we
summarize the potential schemes that allow MPLS packets to carry
extension headers and list the main pros and cons for each scheme.
Song, et al. Expires August 19, 2019 [Page 6]
Internet-Draft MPLS Extension Header Indicator February 2019
+---+---------------------------+---------------------------------+
|No.| Description | Pros and Cons |
+---+---------------------------+---------------------------------+
| 1 | Special purpose EHL |+ Single label |
| | |+ Location freedom |
| | |- Need standard extension |
| | |- Use scarce resource |
+---+---------------------------+---------------------------------+
| 2 | XL(15) + EHL |+ Location freedom |
| | |+ Established mechanism |
| | |+ Abundant resource |
| | |- One extra label than Optiona 1 |
| | |- Need standard extension |
+---+---------------------------+---------------------------------+
| 3 | GAL + ACH with channel |+ Reuse existing mechanism |
| | type extension |+ Abundant resource |
| | |- Label location limitation |
| | |- One more word than Option 1 |
| | |- Not for user traffic |
| | |- Need standard extension/update |
+---+---------------------------+---------------------------------+
| 4 | GAL + another nibble value|+ No change to ACH semantics |
| | to indicate EHs (e.g., |+ Potential overhead saving |
| | "0010") |- Label location limitation |
| | |- Hack scarce resource (nibble) |
| | |- Need standard extension |
+---+---------------------------+---------------------------------+
| 5 | FEC label as EH indicator |+ No need for header standard |
| | |- Complex control plane |
| | |- Cross-domain interoperability |
| | |- Label space issue |
| | |- Not for incremental deployment |
+---+---------------------------+---------------------------------+
Figure 4: Potential Schemes for MPLS Extension Headers
Through comprehensive considerations on the pros and cons of each
scheme, we expect a working group consensus can be reached to pick
the final winner.
6. Considerations of EHI
The existence of Extension Headers will make the ECMP based on inner
IP packet header impossible or harder. If legacy routers need to
conduct this kind of ECMP, the process either fails or generates
unexpected results. EH-aware routers can do this kind of ECMP but
they need to skip all the EHs in order to access the inner packet
Song, et al. Expires August 19, 2019 [Page 7]
Internet-Draft MPLS Extension Header Indicator February 2019
header which may not be efficient. In this case, the Entropy Label
(EL) is preferred for ECMP. The Entropy Label Indicator (ELI) and EL
should be put in front of the EHI to avoid confusing the legacy
routers.
7. Security Considerations
TBD
8. IANA Considerations
If the EHL approach is adopted to indicate the presence of MPLS
extension header(s), this document requests IANA to assign one or
more new Special-Purpose MPLS Label Values from the Special-Purpose
Multiprotocol Label Switching (MPLS) Label Values Registry of
"Extension Header Label (EHL)".
9. Contributors
The other contributors of this document are listed as follows.
o James Guichard
o Stewart Bryant
10. Acknowledgments
TBD.
11. References
11.1. 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>.
[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>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014,
<https://www.rfc-editor.org/info/rfc7274>.
Song, et al. Expires August 19, 2019 [Page 8]
Internet-Draft MPLS Extension Header Indicator February 2019
[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
[I-D.guichard-sfc-mpls-metadata]
Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant,
"Carrying Metadata in MPLS Networks", draft-guichard-sfc-
mpls-metadata-00 (work in progress), September 2013.
[]
Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS
Extension Header", draft-song-mpls-extension-header-02
(work in progress), February 2019.
Authors' Addresses
Haoyu Song (editor)
Huawei
2330 Central Expressway
Santa Clara
USA
Email: haoyu.song@huawei.com
Zhenbin Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: lizhenbin@huawei.com
Tianran Zhou
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: zhoutianran@huawei.com
Song, et al. Expires August 19, 2019 [Page 9]
Internet-Draft MPLS Extension Header Indicator February 2019
Loa Andersson
Bronze Dragon Consulting
Stockholm
Sweden
Email: loa@pi.nu
Song, et al. Expires August 19, 2019 [Page 10]