Internet DRAFT - draft-murakami-dmm-user-plane-message-encoding
draft-murakami-dmm-user-plane-message-encoding
Internet Engineering Task Force T. Murakami, Ed.
Internet-Draft Arrcus, Inc
Intended status: Informational S. Matsushima
Expires: September 6, 2022 SoftBank
K. Ebisawa
Toyota Motor Corporation
P. Camarillo
R. Shekhar
Cisco Systems, Inc.
March 5, 2022
User Plane Message Encoding
draft-murakami-dmm-user-plane-message-encoding-05
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 6, 2022.
Copyright Notice
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
Murakami, et al. Expires September 6, 2022 [Page 1]
Internet-Draft user-plane-message-encoding March 2022
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. User Plane Message encoding into SRH . . . . . . . . . . . . 3
5.1. GTP-U Header format . . . . . . . . . . . . . . . . . . . 4
5.2. Args.Mob.Upmsg . . . . . . . . . . . . . . . . . . . . . 4
5.3. Encoding of Tags Field . . . . . . . . . . . . . . . . . 5
5.4. User Plane message Information Element Support . . . . . 6
5.5. SID flavor consideration . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 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.
Murakami, et al. Expires September 6, 2022 [Page 2]
Internet-Draft user-plane-message-encoding March 2022
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.
Murakami, et al. Expires September 6, 2022 [Page 3]
Internet-Draft user-plane-message-encoding March 2022
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-
Murakami, et al. Expires September 6, 2022 [Page 4]
Internet-Draft user-plane-message-encoding March 2022
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.
Murakami, et al. Expires September 6, 2022 [Page 5]
Internet-Draft user-plane-message-encoding March 2022
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.
Murakami, et al. Expires September 6, 2022 [Page 6]
Internet-Draft user-plane-message-encoding March 2022
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
Murakami, et al. Expires September 6, 2022 [Page 7]
Internet-Draft user-plane-message-encoding March 2022
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.
8. Acknowledgements
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, March 1997,
<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,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
Murakami, et al. Expires September 6, 2022 [Page 8]
Internet-Draft user-plane-message-encoding March 2022
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", draft-ietf-dmm-srv6-mobile-uplane-18
(work in progress), February 2022.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<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, April 2003,
<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, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[TS29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 2019,
<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
USA
Email: tetsuya@arrcus.com
Satoru Matsushima
SoftBank
1-9-1 Higashi-Shinbashi, Munato-ku
Tokyo
Japan
Email: satoru.matsushima@g.softbank.co.jp
Murakami, et al. Expires September 6, 2022 [Page 9]
Internet-Draft user-plane-message-encoding March 2022
Kentaro Ebisawa
Toyota Motor Corporation
Tokyo
Japan
Email: ebisawa@toyota-tokyo.tech
Pablo Camarillo
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Ravi Shekhar
Cisco Systems, Inc.
USA
Email: ravishek@cisco.com
Murakami, et al. Expires September 6, 2022 [Page 10]
