Cisco Systems

davoyer@cisco.com

Cisco Systems

India sriragop@cisco.com

Swisscom

thomas.graf@swisscom.com

HPE

vyasraj.satyanarayana@hpe.com

Bell Canada

cristis0@gmail.com

Operations and Management Operations This document specifies IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol (GTP) User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header.

A dedicated header, called GPRS Tunneling Protocol (GTP) Header, is defined by 3GPP for the GTP User Plane (GTP-U) traffic of mobile subscribers. This document specifies eight IPFIX Information Elements (IEs) to export GTP-U information. Specifically, these IEs are used to export the GTP-U Tunnel Endpoint Identifier (TEID), QoS Flow Identifier (QFI), and PDU Type from the PDU Session Container extension header. Some examples are provided in Appendix A.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in IPFIX IPFIX Information Element Template Template Record Data Record Data Set This document uses the term "User Plane" as used by 3GPP GTP-U in and the term "Uplink Classifier" as used in . The document uses the following abbreviations: IE: Information Element GTP: GPRS Tunneling Protocol GTP-U: GTP User Plane PDU: Protocol Data Unit TEID: Tunnel Endpoint Identifier UPF: User Plane Function QFI: QoS Flow Identifier

This section defines IPFIX IEs corresponding to various fields in the GTP-U header. The GTP-U header includes a mandatory header and optional fields and extension headers. 8-bit flags field indicating the version of GTP-U header, protocol type, and presence of extension header, sequence number and N-PDU number defined in Section 5.1 of the 3GPP specification . The bits are exported as observed. 8-bit field which indicates the type of the GTP-U message as mentioned in Section 5.1 of the 3GPP specification . 32-bit tunnel endpoint identifier field defined in Section 5.1 of the 3GPP specification . This field unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint. 16-bit sequence number field defined in Section 5.1 of the 3GPP specification . This field is interpreted based on the sequence number flag value from gtpuFlags. The sequence number is meaningful only when the S (Sequence Number) flag in the observed GTP-U header is set to 1. When the S flag is set to 0, the Exporting Process MUST export a value of zero for this IE if it is included in the Template. The Collecting Process MUST interpret the sequence number only when the S flag is set to 1. 6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U . This may be used to determine the QoS flow and QoS profile which are associated with the received packet. The E (Extension Header) bit in the gtpuFlags IE indicates the presence of extension headers but does not necessarily indicate the presence of a PDU Session Container extension header. The Exporting Process MUST parse the GTP-U extension-header chain to locate a valid PDU Session Container extension header before exporting a meaningful value for this Information Element. When the Exporting Process cannot identify a valid PDU Session Container extension header in the observed GTP-U header, it MUST export a value of zero for this IE if it is included in the Template. The two most significant bits MUST be exported as zero and MUST be ignored on receipt. 4-bit PDU type field defined in PDU Session Container extension header of GTP-U . This field indicates the structure of the PDU session user plane frame. The E (Extension Header) bit in the gtpuFlags IE indicates the presence of extension headers but does not necessarily indicate the presence of a PDU Session Container extension header. The Exporting Process MUST parse the GTP-U extension-header chain to locate a valid PDU Session Container extension header before exporting a meaningful value for this Information Element. When the Exporting Process cannot identify a valid PDU Session Container extension header in the observed GTP-U header, it MUST export a value of zero for this IE if it is included in the Template. The four most significant bits MUST be exported as zero and MUST be ignored on receipt. 16-bit field indicating the total length in octets of the observed GTP-U header, including the mandatory 8-octet header and any optional fields and extension headers as defined in Sections 5.1 and 5.2 of the 3GPP specification . This IE is computed from the observed packet header and does not export the GTP-U Length field defined in Section 5.1 of . This Information Element carries the complete observed GTP-U header as a contiguous sequence of n octets, beginning at the first octet of the mandatory header and including all optional fields and extension headers, if present, as defined in Sections 5.1 and 5.2 of the 3GPP specification .

The GTP-U related IPFIX IEs are helpful in order to identify the transport performance of PDU Sessions, e.g., with specific QoS class within a network slice (refer to ) or within a group of network slices hosted on the same User Plane Function (UPF). For example, when a set of UPFs are deployed per 5G slice, the slice is identified first using a list of gNB (refer to section 4 of ) IP addresses composing the slice and a list of IP addresses of UPFs dedicated for the slice. The gNB and the UPF form the tunnel endpoints. The traffic for each individual PDU Session per direction is identified using the GTP-U TEID, GTP-U PDU Type together with the above mentioned GTP-U tunnel endpoints. Furthermore, the traffic for a specific QoS class within a PDU Session per traffic direction is identified using the combination of GTP-U TEID, GTP-U PDU Type, and GTP-U QFI attributes. It is possible that for a single PDU session there might be multiple IP flows with different GTP-U QFI but with same GTP-U TEID. In another scenario when multiple 5G slices share the same UPF, each slice is identified using a separated list of gNB IPv4 or IPv6 addresses per slice. If an Uplink Classifier (refer to section 5.6.4.2 of ) is deployed there is an addition of a GTP-U tunnel between the Intermediate/Uplink-Classifier UPF and the final UPF. This brings a challenge for identifying the end-to-end path for a certain PDU Session - the GTP-U PDU Type and GTP-U QFI attributes from the gNB and Intermediate/Uplink-Classifier UPF tunnel will be the same on the Intermediate/Uplink-Classifier and final UPF tunnels, however the GTP-U TEIDs will be different on each tunnel. The use of the IPFIX GTP-U IEs is to identify either a particular PDU Session on a particular slice (using GTP-U TEID in combination with the gNB and the UPF IP addresses) or all the IP traffic flows for a 3GPP QoS flow on a slice (using GTP-U QFI in combination with the gNB and the UPF IP addresses) or a 3GPP QoS flow for a particular PDU Session on a slice (using both GTP-U TEID and GTP-U QFI in combination with the gNB and UPF IP addresses). Additionally, exporting GTP-U IEs together with the transportChecksum IE 503 registered in the IANA IPFIX registry can help identify GTP-U endpoints that transmit UDP packets with a zero checksum over IPv6. As specified in , UDP zero-checksum operation is permitted only when the peer GTP-U endpoint and the path between the endpoints support it. Such packets may otherwise be discarded by the receiving endpoint or intermediate IPv6 devices. The exported information can help operators identify the affected GTP-U traffic and investigate potential interoperability issues.

IANA has registered the following IEs in the "IPFIX Information Elements" registry available at . Table 1 lists the GTP-U IEs:

Table 2 lists the GTP-U IEs to be registered:

IANA is requested to update the references for the existing GTP-U Information Elements listed in Table 1 to point to this RFC and update their descriptions. IANA is also requested to allocate two new Information Element IDs listed in Table 2 for gtpuTotalHdrLength and gtpuHeaderSection in the "IPFIX Information Elements" registry.

Name:

gtpuFlags

ElementID:

505

Description:

8-bit flags field indicating the version of GTP-U header, protocol type, and presence of extension header, sequence number and N-PDU number defined in Section 5.1 of the 3GPP specification . The bits are exported as observed. The basic encoding is 8 bits. The layout of the encoding is as follows:

Version is the 3-bit GTP-U protocol version field defined in Section 5.1 of the 3GPP specification PT means Protocol Type Flag E means Extension Header Flag S means Sequence Number Flag PN means N-PDU Number Flag (*) indicates the spare bit in the GTP-U header defined in Section 5.1 of the 3GPP specification . Examples: value : 0x34 binary: 00110100 decode: Version=1, PT=1, spare=0, E=1, S=0, PN=0 value : 0x36 binary: 00110110 decode: Version=1, PT=1, spare=0, E=1, S=1, PN=0

Abstract Data Type:

unsigned8

Data Type Semantics:

flags

Additional Information:

Refer to Section 5.1 of .

Reference:

[RFC-to-be]

Name:

gtpuMsgType

ElementID:

506

Description:

8-bit field which indicates the type of the GTP-U message as mentioned in Section 5.1 of the 3GPP specification .

Abstract Data Type:

unsigned8

Data Type Semantics:

identifier

Additional Information:

Refer to Section 5.1 of the 3GPP specification .

Reference:

[RFC-to-be]

Name:

gtpuTEid

ElementID:

507

Description:

32-bit tunnel endpoint identifier field defined in Section 5.1 of the 3GPP specification . This field unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint.

Abstract Data Type:

unsigned32

Data Type Semantics:

identifier

Additional Information:

Refer to Section 5.1 of the 3GPP specification .

Reference:

[RFC-to-be]

Name:

gtpuSequenceNum

ElementID:

508

Description:

16-bit sequence number field defined in Section 5.1 of the 3GPP specification . This field is interpreted based on the sequence number flag value from gtpuFlags. The sequence number is meaningful only when the S (Sequence Number) flag in the observed GTP-U header is set to 1. When the S flag is set to 0, the Exporting Process MUST export a value of zero for this IE if it is included in the Template. The Collecting Process MUST interpret the sequence number only when the S flag is set to 1.

Abstract Data Type:

unsigned16

Data Type Semantics:

identifier

Additional Information:

Refer to Section 5.1 of the 3GPP specification .

Reference:

[RFC-to-be]

Name:

gtpuQFI

ElementID:

509

Description:

6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U . This may be used to determine the QoS flow and QoS profile which are associated with the received packet. The E (Extension Header) bit in the gtpuFlags IE indicates the presence of extension headers but does not necessarily indicate the presence of a PDU Session Container extension header. The Exporting Process MUST parse the GTP-U extension-header chain to locate a valid PDU Session Container extension header before exporting a meaningful value for this Information Element. When the Exporting Process cannot identify a valid PDU Session Container extension header in the observed GTP-U header, it MUST export a value of zero for this IE if it is included in the Template. The two most significant bits MUST be exported as zero and MUST be ignored on receipt. The basic encoding is 8 bits. The layout of basic encoding is as follows:

Examples: value : 0x08 binary: 00001000 decode: 001000 - QFI value value : 0x3e binary: 00111110 decode: 111110 - QFI value

Abstract Data Type:

unsigned8

Data Type Semantics:

identifier

Additional Information:

Refer to Section 5.5.3.3 of the 3GPP specification and Section 5.7.1.1 of the 3GPP specification .

Reference:

[RFC-to-be]

Name:

gtpuPduType

ElementID:

510

Description:

4-bit PDU type field defined in PDU Session Container extension header of GTP-U . This field indicates the structure of the PDU session user plane frame. The E (Extension Header) bit in the gtpuFlags IE indicates the presence of extension headers but does not necessarily indicate the presence of a PDU Session Container extension header. The Exporting Process MUST parse the GTP-U extension-header chain to locate a valid PDU Session Container extension header before exporting a meaningful value for this Information Element. When the Exporting Process cannot identify a valid PDU Session Container extension header in the observed GTP-U header, it MUST export a value of zero for this IE if it is included in the Template. The four most significant bits MUST be exported as zero and MUST be ignored on receipt. The basic encoding is 8 bits. The layout of basic encoding is as follows:

Example: value : 0x01 binary: 00000001 decode: 0001 - PDU Type value

Abstract Data Type:

unsigned8

Data Type Semantics:

identifier

Additional Information:

Refer to Section 5.5.3 of the 3GPP specification .

Reference:

[RFC-to-be]

Name:

gtpuTotalHdrLength

ElementID:

TBD1

Description:

16-bit field indicating the total length in octets of the observed GTP-U header, including the mandatory 8-octet header and any optional fields and extension headers as defined in Sections 5.1 and 5.2 of the 3GPP specification . This IE is computed from the observed packet header and does not export the GTP-U Length field defined in Section 5.1 of .

Abstract Data Type:

unsigned16

Data Type Semantics:

quantity

Additional Information:

Refer to Sections 5.1 and 5.2 of .

Reference:

[RFC-to-be]

Name:

gtpuHeaderSection

ElementID:

TBD2

Description:

This Information Element carries the complete observed GTP-U header as a contiguous sequence of n octets, beginning at the first octet of the mandatory header and including all optional fields and extension headers, if present, as defined in Sections 5.1 and 5.2 of the 3GPP specification .

Abstract Data Type:

octetArray

Data Type Semantics:

default

Additional Information:

Refer to Section 5 of .

Reference:

[RFC-to-be]

The authors would like to thank Benoit Claise, Ketan Talaulikar, Dhananjay Patki, Paul Aitken, Shraddha Hegde, Chongfeng Liu, and Mahesh Jethanandani for their reviews and valuable comments.

Bell Canada

kandhla.chandi@bell.ca

Cisco

rjohny@cisco.com

Note to the RFC-Editor: Please remove this section before publishing.

Cisco implemented the following IEs as part of a test implementation in the IOS XR platform. This implementation currently covers six of the eight IEs defined in this document; it does not yet cover gtpuTotalHdrLength or gtpuHeaderSection: gtpuFlags gtpuMsgType gtpuTEid gtpuSequenceNum gtpuQFI gtpuPduType

The IEs described in this document export GTP user plane information about packet forwarding in a 3GPP network. In particular, TEIDs, QFIs, PDU types, and GTP-U header sections can enable correlation of traffic with individual PDU sessions and, depending on deployment, with subscriber activity. Implementations and operators therefore MUST treat this data as sensitive network telemetry data. Applications and operators using the IEs specified in this document MUST evaluate the sensitivity of this information in their deployment context, and apply the data-at-rest storage guidance in Section 11.8 of as appropriate. Operators MUST restrict access to these exported IEs, apply retention limits appropriate to sensitive operational telemetry, and MUST NOT export gtpuHeaderSection unless required by the operational use case. An Exporting Process MUST NOT include octets beyond the observed GTP-U header in gtpuHeaderSection. Exporting Processes and Collecting Processes that exchange the Information Elements defined in this document SHOULD use the secure transport mechanisms specified in Section 11 of to provide confidentiality, integrity, and peer authentication, particularly when exporting gtpuHeaderSection.

The IPFIX IEs defined in this document require extraction of fields from packets. There may exist older devices in the network that do not support extensions defined in this document. For those devices defines dataLinkFrameSection which is a useful mechanism to export the packet header as a fallback scenario. However, when dataLinkFrameSection is used, Flow aggregation as per can't be applied. This document will serve as a guideline to extract the necessary fields from the GTP-U header for the above scenarios. When 3GPP specifications indicate that a GTP-U field is not to be interpreted, an Exporting Process can use a Template that omits the corresponding IE. If the IE is included in the Template, the Exporting Process follows the rules specified in the corresponding IE definition for representing values that are not meaningful. When gtpuQFI or gtpuPduType is exported with a value of zero, the Collecting Process cannot determine solely from that value or the E flag whether the PDU Session Container extension header was present. Applications requiring this distinction need additional information, such as the observed GTP-U header exported using gtpuHeaderSection.

3GPP Version 17.4.0 3GPP Version 17.1.0 3GPP Version 17.11.0 3GPP Version 17.11.0 HPE Nokia HPE Orange Telefonica

In this section, an example is provided to show IPFIX encoding format for the GTP-U introduced IEs. Template definition and data set corresponding to an observed GTP-U header is illustrated below.

Sample template consisting of the GTP-U IEs:

In this example, the Template ID is 256, which will be used in the Data Record. The data set is represented as follows: