Cisco Systems

davoyer@cisco.com

Cisco Systems

India sriragop@cisco.com

Swisscom

thomas.graf@swisscom.com

HPE

vyasraj.satyanarayana@hpe.com

Bell Canada

cristian.staicu@bell.ca

Operations and Management Operations This document introduces 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.

This document makes use of the terms defined in IPFIX IPFIX Information Element Template Template Record Options Template Options Template Record Data Record Data Set This document uses the term "User Plane" as used by 3GPP GTP-U in . The document uses the following abbreviations: IE: Information Element GTP: GPRS Tunneling Protocol GTP-U: GTP User Plane GTP-C: GTP Control 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. When the corresponding field is not present in the observed packet, or when 3GPP specifications state that the field shall not be interpreted, an Exporting Process SHOULD use a Template that omits the corresponding IE. If operational constraints require use of a fixed Template, the Exporting Process MUST export a value of zero for that IE, and the Collecting Process MUST treat that value in this context as "field not available". Reserved bits in exported gtpuQFI and gtpuPduType values MUST be set to zero by the Exporting Process and MUST be ignored by the Collecting Process. 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 6.1 of 3GPP specification . 32-bit tunnel endpoint identifier 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 the GTP-U. This field is interpreted based on the sequence number flag value from gtpuFlags. 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 presence of this extension header is interpreted based on the extension header flag value from gtpuFlags. 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 presence of this extension header is interpreted based on the extension header flag value from gtpuFlags. 8-bit field indicating the total length of the GTP-U header which includes mandatory fields and all the optional headers as defined in Sections 5.1 and 5.2 of the 3GPP specification . This IE is derived from the observed packet header and does not export the GTP-U Length field defined in Section 5.1 of . This Information Element carries a series of n octets from the GTP-U header mandatory fields and all the following optional headers if any, defined in Section 5 of the 3GPP specification as a series of octets in IPFIX.

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 gNodeB IP addresses composing the slice and a list of IP addresses of UPFs dedicated for the slice. The gNodeB 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 IP 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 gNodeB IPv4 or IPv6 addresses per slice. If an Uplink Classifier (refer to section 3.1 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 gNodeB 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 since 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 gNodeB 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 gNodeB 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 gNodeB and UPF IP addresses). Additionally, exporting GTP-U IEs together with the transportChecksum IE 503 registered in the IANA IPFIX registry can help detect misbehaving nodes, particularly when using GTP-U over IPv6.

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

IANA is requested to update the references for the existing GTP-U Information Elements listed in Table 1 to point to this RFC. IANA is also requested to allocate two new Information Element IDs 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:

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 6.1 of the 3GPP specification .

Abstract Data Type:

unsigned8

Data Type Semantics:

identifier

Additional Information:

Refer to Section 6.1 of the 3GPP specification .

Reference:

[RFC-to-be]

Name:

gtpuTEid

ElementID:

507

Description:

32-bit tunnel endpoint identifier 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 the GTP-U. This field is interpreted based on the sequence number flag value from gtpuFlags. When the S flag is not set, this IE is not meaningful and is exported as specified in .

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 presence of this extension header is interpreted based on the extension header flag value from gtpuFlags. When the PDU Session Container extension header is not present, this IE is not meaningful and is exported as specified in . The two most significant bits are reserved, 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 . The reserved bits in the exported octet are set to zero.

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 presence of this extension header is interpreted based on the extension header flag value from gtpuFlags. When the PDU Session Container extension header is not present, this IE is not meaningful and is exported as specified in . The four most significant bits are reserved, 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 : 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 . The reserved bits in the exported octet are set to zero.

Reference:

[RFC-to-be]

Name:

gtpuTotalHdrLength

ElementID:

TBD1

Description:

8-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 defined in Sections 5.1 and 5.2 of the 3GPP specification . This IE is derived from the observed packet header and does not export the GTP-U Length field defined in Section 5.1 of .

Abstract Data Type:

unsigned8

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 a series of n octets from the observed GTP-U header, including the mandatory header and any optional fields and extension headers defined in Sections 5.1 and 5.2 of the 3GPP specification , as a series of octets in IPFIX.

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 on how packets are being forwarded in a 3GPP network. In particular, TEIDs, QFIs, PDU types, and raw header sections can enable correlation of traffic with individual PDU sessions and, depending on deployment, with subscriber activity. Implementations and operators therefore SHOULD treat this data as sensitive network telemetry. Applications and operators using the IEs described in this document must evaluate the sensitivity of this information in their implementation context, and apply the data-at-rest storage guidance in Section 11.8 of as appropriate. Operators SHOULD restrict access to these exported IEs, apply retention limits appropriate to sensitive operational telemetry, and avoid exporting gtpuHeaderSection unless required by the operational use case.

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.

3GPP Version 17.4.0 3GPP Version 17.1.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: