Internet-Draft user-plane-message-encoding September 2021
Murakami, et al. Expires 6 March 2022 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-murakami-dmm-user-plane-message-encoding-04
Published:
Intended Status:
Informational
Expires:
Authors:
T. Murakami, Ed.
Arrcus, Inc
S. Matsushima
SoftBank
K. Ebisawa
Toyota Motor Corporation
P. Camarillo
Cisco Systems, Inc.
R. Shekhar
Cisco Systems, Inc.

User Plane Message Encoding

Abstract

This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network.

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 5 March 2022.

1. Introduction

3GPP defines User Plane function (UPF) and the protocol messages that it supports. The User Plane messages support in-band signalling for path and tunnel management. Currently, User Plane messages are defined in TS 29.281 [TS29281].

When using SRv6 (Segment Routing IPv6) as a transport protocol for User Plane Function (UPF) of mobile networks, based on draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane]. User Plane messages must be carried over SRv6 network. This document defines which User Plane message must be encoded to SRv6 and also defines how to encode the User Plane messages into SRH.

In addition, SRH is mandatory at the ultimate segment upon carrying the User Plane messages because User Plane message is encoded into SRH. Hence, this document considers how to deal with the encoding of User Plane messages into SRH when PSP is applied that SRH is popped out at the penultimate segment.

2. 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 RFC 2119 [RFC2119].

3. Conventions and Terminology

SRv6:
Segment Routing IPv6.
GTP-U:
GPRS Tunneling Protocol User Plane.
UPF:
User Plane Function.
SRH:
IPv6 Segment Routing Header.
PSP:
Penultimate Segment POP of the SRH.
USP:
Ultimate Segment Pop of the SRH.

4. Motivation

3GPP User Plane needs to support the user plane messages associated with a GTP-U tunnel defined in [TS29281]. In the case of SRv6 User Plane [I-D.ietf-dmm-srv6-mobile-uplane], those messages are also required when the user plane interworks with GTP-U.

IPv6 Segment Routing Header (SRH) [RFC8754] is used for SRv6 User Plane. SRH is able to associate additional information to the segments. The Tag field of SRH is capable to indicate different properties within a SID. SRH TLV is capable to provide meta-data to the endpoint node.

The above capability of SRH motivates us to map the user plane messages into it because of the same encapsulation with the packets of carrying client packets. It introduces no additional headers or extension headers to be chained in the packet just for carrying the user plane messages.

5. User Plane Message encoding into SRH

This section defines how to encode the User Plane messages into SRH in order to carry the User Plane messages over SRv6 network.

5.1. GTP-U Header format

3GPP defines GTP-U Header format as shown below.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver |P|R|E|S|N| Message Type  |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Tunnel Endpoint Identifier                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Sequence Number          | N-PDU Number  |  Next-Ext-Hdr |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GTP-U Header format

User Plane message type is encoded in Message Type field of GTP-U Header. The following User Plane messages must be carried over SRv6 network at least. The value of each User Plane message type is defined as shown below.

Echo Request:
1
Echo Reply:
2
Error Indication:
26
End Marker:
254

5.2. Args.Mob.Upmsg

draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane] defines the format of Args.Mob.Session argument which is used in SRv6 SID Mobility Functions in order to carry the PDU Session identifier. The format of Args.Mobs.Session is defined as shown below.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   QFI     |R|U|                PDU Session ID                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |PDU Sess(cont')|
     +-+-+-+-+-+-+-+-+
Figure 2: Args.Mob.Session format

In case of Echo Request, Echo Reply and Error Indication, Sequence Number in GTP-U header needs to be carried. Similar to draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane], the new arguments to carry Sequqnce number for Echo Request, Echo Reply and Error Indication message needs to be defined. For this, the following Args.Mobs.Upmsg should be defined newly to carry Sequence number.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   QFI     |R|U|       Sequence Number         |      Pad      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Pad(cont')  |
     +-+-+-+-+-+-+-+-+
Figure 3: Args.Mob.Upmsg format for Echo Request, Echo Reply and Error Indication

QFI bit, R bit, U bit and 16-bit Sequence Number is encoded in Args.Mobs.Upmsg. The remaining bits followed by Sequence Number must be padded in 0.

In case of End Marker, TEID shall be used as PDU Session ID same as draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane]. Hence, for End Marker, Args.Mobs.Session should be used to carry TEID as PDU Session ID.

5.3. Encoding of Tags Field

The Segment Routing Header is defined in IPv6 Segment Routing Header (SRH) [RFC8754]. This draft defines 16 bits Tag field but does not define the format or use of this Tag field in the Segment Routing Header.

The User Plane message type encoding is defined in TS 29.281 [TS29281]. Based on this definition, the User Plane message type must be encoded into the Tag field in the Segment Routing Header in order to indicate the type of the user plane messages for at least Echo Request, Echo Reply, Error Indication or End Marker.

Only UPF must process the Tag field where the user plane message is encoded. In addition, when the user plane message is encoded in the Tag field, the UPF should not encode any segments in the Segment Routing Header whose function modifies the Tag field value. Any other transport router implementing SRv6 must ignore the Tag field upon processing the Segment Routing Header.

The user plane messages must be encoded into the Tag filed as shown below.

     0                             1
     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |         Reserved                  |B3|B2|B1|B0|
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: Tag Field Encoding
Bit 0 [B0]:
End Marker
Bit 1 [B1]:
Error Indication
Bit 2 [B2]:
Echo Request
Bit 3 [B3]:
Echo Reply

End Marker, Echo Request and Echo reply messages do not require any additional information elements. However, Error Indication message requires the additional information elements like Tunnel Endpoint Identifier Data IE, GSN Address, etc. These additional information elements can be encoded into the SRH TLV that is defined in the next section.

5.4. User Plane message Information Element Support

End Maker, Echo Request and Echo Reply messages do not require any additional information elements. However, Error Indication message requires additional 3GPP IEs (Information Element). These additional information elements must be carried over SRv6 network as well. However SRv6 SID has limited space only. Hence it cannot carry a lot of information elements.

In order to carry more information elements, SRH TLV shall be leveraged. SRH TLV is defined in IPv6 Segment Routing Header (SRH) [RFC8754] in order to carry the meta-data for the segment processing. In order to carry additional User Plane messages like 3GPP IEs, the new type named as "User Plane Container" must be defined as the new SRH TLV. The "User Plane Container" can carry additional User Plane messages which includes multiple 3GPP IEs with 1 sub-TLV.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |     Length      |  User Plane message sub-TLV |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               User Plane message sub-TLV                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: User Plane Container TLV
Type:
to be assigned by IANA
Length:
Length of User Plane message sub-TLV
User Plane message sub-TLV:
User Plane message sub-TLV defined below 

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |     Length      |            Value            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: User Plane message sub-TLV
Type:
Type of User Plane message sub-TLV
3GPP IE sub-TLV:
0x01
Length:
Length of Value
Value:
User Plane Message data
3GPP IE sub-TLV:
multiple 3GG IEs

5.5. SID flavor consideration

This section considers SID flavor of where the SRH is popped out at either the penultimate or the ultimate segment.

In order to carry User Plane message over SRv6 network, SRH must be sustained over entire SRv6 network because User Plane message type and required information elements are encoded into SRH. If the penultimate segment is popping out SRH, i.e., PSP, User Plane message can not be carried in entire SRv6 network.

In order to avoid this problem, USP is recommended in SRv6 Mobile network. In this case, SRH is never popped out and User Plane message can be sustained over entire SRv6 network.

However, if PSP needs to be enabled in SRv6 network, it is also a possible solution to encap another SRH which carries User Plane message along with the outer IPv6 or SRH.

6. Security Considerations

This document does not raise any additional security issues. This document just define the mechanisms for mapping between user plane message (GTP-U message) and SRH in SRv6. Basically, since this document is using SRH defined in [RFC8754] to carry user plane message, same security consideration stated in [RFC8754] shall be applied.

7. IANA Consideration

The type value of SRH TLV for User Plane Container must be assigned by IANA.

9. References

9.1. Normative References

[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>.
[RFC2460]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, , <https://www.rfc-editor.org/info/rfc2460>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.

9.2. Informative References

[I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for Mobile User Plane", Work in Progress, Internet-Draft, draft-ietf-dmm-srv6-mobile-uplane-16, , <https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-16.txt>.
[RFC1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, , <https://www.rfc-editor.org/info/rfc1918>.
[RFC3513]
Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/RFC3513, , <https://www.rfc-editor.org/info/rfc3513>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/info/rfc8754>.
[TS29281]
3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", , <http://www.3gpp.org/ftp//Specs/archive/29_series/29.281/29281-f60.zip>.

Authors' Addresses

Tetsuya Murakami (editor)
Arrcus, Inc
2077 Gateway Place, Suite 400
San Jose,
United States of America
Satoru Matsushima
SoftBank
1-9-1 Higashi-Shinbashi, Munato-ku,
Japan
Kentaro Ebisawa
Toyota Motor Corporation
Japan
Pablo Camarillo
Cisco Systems, Inc.
Spain
Ravi Shekhar
Cisco Systems, Inc.
United States of America