User Plane Message Encoding

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

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.

Segment Routing IPv6. GPRS Tunneling Protocol User Plane. User Plane Function. IPv6 Segment Routing Header. Penultimate Segment POP of the SRH. Ultimate Segment Pop of the SRH.

3GPP User Plane needs to support the user plane messages associated with a GTP-U tunnel defined in . In the case of SRv6 User Plane , those messages are also required when the user plane interworks with GTP-U. IPv6 Segment Routing Header (SRH) 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.

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

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

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. 1 2 26 254

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.

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.

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.

The Segment Routing Header is defined in IPv6 Segment Routing Header (SRH). 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.

End Marker Error Indication Echo Request 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.

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

to be assigned by IANA Length of User Plane message sub-TLV User Plane message sub-TLV defined below

Type of User Plane message sub-TLV 0x01 Length of Value User Plane Message data multiple 3GG IEs

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.

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 to carry user plane message, same security consideration stated in shall be applied.

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