User Plane Message Encoding
draft-murakami-dmm-user-plane-message-encoding-01

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 September 7, 2020.

Copyright Notice

Copyright (c) 2020 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. Requirements Language
• 3. Conventions and Terminology
• 4. Motivation
• 5. User Plane Message encoding into SRH
• 5.1. GTP-U Header format
• 5.2. Args.Mob.Upmsg
• 5.3. Encoding of Tags Field
• 5.4. User Plane message Information Element Support
• 5.5. SID flavor consideration
• 6. Security Considerations
• 7. IANA Consideration
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

3GPP defines User Plane messages. The User Plane messages support in-band signaling for path and tunnel management. Currently, User Plane messages are defined in TS 29.281.

When applying SRv6 (Segment Routing IPv6) to the user plane of mobile networks based on draft-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.

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.

Segment Routing Header (SRH) [I-D.ietf-6man-segment-routing-header] 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 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, 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. 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 draft-ietf-6man-segment-routing-header. 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. 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 draft-ietf-6man-segment-routing-header 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                    //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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

TBD

7. IANA Consideration

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

8. Acknowledgements

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses