Internet DRAFT - draft-li-mpls-gip6-mpls
draft-li-mpls-gip6-mpls
Network Working Group L. Li
Internet-Draft J. Dong
Intended status: Standards Track S. Chen
Expires: 12 January 2023 Huawei
11 July 2022
Genralized IPv6 Tunnel for MPLS
draft-li-mpls-gip6-mpls-00
Abstract
With the development of new services, MPLS faces many problems and
technical challenges. This document defines the method to implement
MPLS through the GIP6 tunnel.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 12 January 2023.
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.
Li, et al. Expires 12 January 2023 [Page 1]
Internet-Draft GIP6 for MPLS July 2022
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. GIP6 Tunnel for MPLS . . . . . . . . . . . . . . . . . . . . 3
5. Control Plane Considerations . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The GIP6 tunnel is defined in [draft-li-rtgwg-generic-ipv6-tunnel-00]
which is to solve the challenges of the existing IP tunnels to
support new features such as alternate marking, IOAM, network
resource partition and APN.
With the development of new services, MPLS also faces many problems
and technical challenges. For example, it is difficult to
encapsulate new forwarding attributes because of lack of the metadata
extensibility. This document defines how to implement MPLS through
the GIP6 tunnel which is to solve the possible problems effectively.
2. Terminology
APN: Application-Aware Networking
GIP6: Generic Ipv6 Tunnel
GRE: Generic Routing Encapsulation
IFIT: In-situ Flow Information Telemetry
MP2P: Multi Point To Point
MPLS: Multiprotocol Label Switching
PM: Performance Monitor
Li, et al. Expires 12 January 2023 [Page 2]
Internet-Draft GIP6 for MPLS July 2022
SFL: Synonymos Flow Labels
SR-MPLS: Segment Routing Multiprotocol Label Switching
VXLAN: Virtual eXtensible Local Area Network
3. Problem Statement
With the development of new services, MPLS faces the following the
technical problems and challenges of MPLS:
1. MPLS is lack of the source indication and MP2P connections may
occur. This causes the difficulty and complex process for OAM over
MPLS. Although SFL( [RFC8957]) is defined, there is few
implementation.
2. The payload type (for example, L2 or L3 packets) cannot be
directly determined because there is no payload indication.
3. There is no metadata extensibility and it is difficult to
encapsulate new forwarding attributes for the new features such as
IETF network slicing, IFIT, and APN.
4. The process of the ECMP function is complex and affects
forwarding performance. Entropy labels or flow labels are placed at
the bottom of the label stack for processing and the internal IP
header information may have to be parsed for the purpose of ECMP.
4. GIP6 Tunnel for MPLS
[I-D.li-rtgwg-generalized-ipv6-tunnel] defines the GIP6 tunnel to
support both new features and the existing functions for the IP
tunnels based on the extension of the IPv6 extension header. If the
GIP6 tunnel is used for MPLS, there can be the following advantages:
1. The IPv6 source address is used to form a source identifier.
2. The IPv6 NH can indicate the payload type.
3. IPv6 flow labels are used to implement ECMP.
4. The encapsulations for the new features have been defined well in
the IPv6 and can be reused easily.
It is simple and can benefit forwarding performance. Moreover, there
have been many implementations and deployments.
Li, et al. Expires 12 January 2023 [Page 3]
Internet-Draft GIP6 for MPLS July 2022
In order to support MPLS based on the GIP6 tunnel, the method to
carry MPLS label stack information is defined as follows:
1. A special IPv6 prefix MUST be used to indicate that it is
followed by MPLS label encapsulation. The special IPv6 prefix can be
specified or a well-known IPv6 prefix to be assigned.
2. The IPv6 special prefix can be followed by multiple MPLS label
encapsulations to form a 128-bit IPv6 MPLS SID (Type 1). The format
of the IPv6 MPLS SID (Type 1) is shown in the following figure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Prefix(4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv6 MPLS SID (TYPE 1)
Special prefix: TBD
MPLS Label Encap: For details, please refer to section 2.1 in
[RFC3032].
3. IPv6 MPLS SID (Type 1) can be placed in the IPv6 destination
address.
Processing of the first label following the special prefix is as
follows:
(1) If the local action of the MPLS label is POP, the followed label
encapsulations are shifted left by 32 bits after the label is popped.
The following figure shows the process.
Li, et al. Expires 12 January 2023 [Page 4]
Internet-Draft GIP6 for MPLS July 2022
Before POP MPLS Label Encap:
uSID-Block Active-Label Next-Label Last-Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Prefix | Lable-1 Encap | Label-2 Encap| Label-3 Encap(EOL)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After POP MPLS Label Encap:
uSID-Block Active-Label Next-Label Last-Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Prefix | Lable-2 Encap | Label-3 Encap(EOL) | 0000...0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Pop MPLS Label Encapsulation in IPv6 DA
(2) If the local action of the MPLS label is SWAP, the label
encapsulation is changed to the new label after swap.
4. If all the MPLS label stack cannot be placed in the IPv6
destination address, IPv6 RH can be used to house the remaining MPLS
label stack.
(1) IPv6 MPLS SID (Type 2) is defined to house multiple (<= 4) label
encapsulations. The format of the IPv6 MPLS SID (Type 2) is shown in
the following figure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Encap (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS Label Encap: For details, see section 2.1 in [RFC3032].
(2) IPv6 MPLS SID (Type 2) is used as the segment in the RH. After
all of the label encapsulations in the IPv6 destination address are
popped, the first label encapsulation in the segment indicated by the
SL of the RH will be processed as follows:
Li, et al. Expires 12 January 2023 [Page 5]
Internet-Draft GIP6 for MPLS July 2022
-- If the local action of the MPLS label is POP, the followed label
encapsulations are shifted left by 32 bits after the label is popped.
-- If the local action of the MPLS label is SWAP, the label
encapsulation is changed to the new label after swap.
After all the label encapsulations in the segment are popped, SL
minus 1. Then the first label encapsulation in the segment indicted
by the new SL will go on to be processed as the above procedures.
A new type of RH can be defined to contain IPv6 MPLS SID (Type 2) or
SRv6 SRH can be reused for the purpose.
5. When find the S flag of the label encapsulation in the IPv6
destination address or the RH to be processed is set, this means the
bottom of the label stack is reached and the process of the label
stack in the GIP6 will end after the label is popped.
If an intermediate node requires to push a label or a label stack,
there can be two modes: Encap mode and Inserting mode.
1) Encap mode: with this mode, a new IPv6 MPLS packet header is
encapsulated outside the original MPLS packet, and the MPLS label
(stack) is encapsulated in the new IPv6 MPLS packet header as the
above procedures.
2) Inserting mode: All the label encapsulations in the IPv6
destination address and the IPv6 RH (if exist) need to be shifted
right and the new label (stack) can be placed immediately following
the special prefix in the IPv6 destination address. The process is
complex and not recommended.
5. Control Plane Considerations
GIP6 only provides a way to carry MPLS label encapsulations in the
data plane. The existing MPLS control plane does not need to be
changed. That is, MPLS labels on the control plane can still be
distributed for IPv4, IPv6, L2, etc.
6. Security Considerations
TBD.
Li, et al. Expires 12 January 2023 [Page 6]
Internet-Draft GIP6 for MPLS July 2022
7. IANA Considerations
TBD.
8. References
[I-D.li-rtgwg-generalized-ipv6-tunnel]
Zhenbin, Shuanglong, and Haibo, "Generalized IPv6 Tunnel
(GIP6)", Work in Progress, Internet-Draft, draft-li-rtgwg-
generalized-ipv6-tunnel-00, 10 July 2022,
<https://www.ietf.org/archive/id/draft-li-rtgwg-
generalized-ipv6-tunnel-00.txt>.
[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>.
[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>.
[RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G.
Mirsky, "Synonymous Flow Label Framework", RFC 8957,
DOI 10.17487/RFC8957, January 2021,
<https://www.rfc-editor.org/info/rfc8957>.
Authors' Addresses
Zhenbin Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: lizhenbin@huawei.com
Jie Dong
Huawei
156 Beiqing Road
Beijing,100095
P.R. China
Email: jie.dong@huawei.com
Li, et al. Expires 12 January 2023 [Page 7]
Internet-Draft GIP6 for MPLS July 2022
Shuanglong Chen
Huawei
156 Beiqing Road
Beijing,100095
P.R. China
Email: chenshuanglong@huawei.com
Li, et al. Expires 12 January 2023 [Page 8]
