Internet-Draft GIP6 for MPLS November 2022
Li, et al. Expires 10 May 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-rtgwg-gip6-for-mpls-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Li
Huawei
S. Chen
Huawei
Q. Gao
Huawei
S. Zhang
China Unicom

Genralized IPv6 Tunnel for MPLS

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 10 May 2023.

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

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.

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.

Before POP MPLS Label Encap:

     Prefix        Active-Label      Next-Label       Last-Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Prefix | Lable-1 Encap | Label-2 Encap| Label-3 Encap(EOL)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

After POP MPLS Label Encap:

     Prefix        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)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 3. IPv6 MPLS SID (TYPE 2)

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:

-- 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.

7. Contributors

Jie Dong

Huawei Technologies

jie.dong@huawei.com

8. IANA Considerations

TBD.

9. References

[I-D.li-rtgwg-generalized-ipv6-tunnel]
Li, Z., Chen, S., Gao, Q., Zhang, S., and Q. Xu, "Generalized IPv6 Tunnel (GIP6)", Work in Progress, Internet-Draft, draft-li-rtgwg-generalized-ipv6-tunnel-03, , <https://datatracker.ietf.org/api/v1/doc/document/draft-li-rtgwg-generalized-ipv6-tunnel/>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8957>.

Authors' Addresses

Zhenbin Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Shuanglong Chen
Huawei
156 Beiqing Road
Beijing,100095
P.R. China
Qiangzhou Gao
Huawei
156 Beiqing Road
Beijing,100095
P.R. China
Shuai Zhang
China Unicom
Beijing,100048
P.R. China