| Internet-Draft | user-plane-message-encoding | March 2022 |
| Murakami, et al. | Expires 6 September 2022 | [Page] |
This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network.¶
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 2 September 2022.¶
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. 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.¶
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 applying SRv6 (Segment Routing IPv6) to the user plane 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.¶
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].¶
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.¶
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.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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')|
+-+-+-+-+-+-+-+-+
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') |
+-+-+-+-+-+-+-+-+
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.¶
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|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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) [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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC8754] to carry user plane message, same security consideration stated in [RFC8754] shall be applied.¶
The type value of SRH TLV for User Plane Container must be assigned by IANA.¶