Internet-Draft IPFIX support for GTP-U November 2024
Voyer, et al. Expires 8 May 2025 [Page]
Workgroup:
Operations
Internet-Draft:
draft-ietf-opsawg-ipfix-gtpu-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Voyer
Bell Canada
S. Gopalakrishnan
Cisco Systems
T. Graf
Swisscom
B. Claise
Huawei
V. Satyanarayana
Juniper Networks

Export of GTP-U Information in IP Flow Information Export (IPFIX)

Abstract

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

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 8 May 2025.

Table of Contents

1. Introduction

A dedicated header, called GPRS Tunneling Protocol Header (GTP), is defined by the 3GPP for use of user Plane (GTP User (GTP-U)) [TS.29281] traffic of mobile subscribers.

This document specifies six IPFIX Information Elements (IEs) [RFC7012] 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.

2. Terminology

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document makes use of the terms defined in [RFC7011]

This document makes use of following terms from [RFC6459]:

The document uses the following abbreviations:

3. IPFIX GTP-U Information Elements

This section defines IPFIX IEs corresponding to various fields in the GTP-U header.

gtpuFlags
8-bit flags field defined in the GTP-U.
gtpuMsgType
8-bit message type field defined in the GTP-U.
gtpuTEid
32-bit tunnel endpoint identifier field defined in GTP-U which unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint.
gtpuSequenceNum
16-bit sequence number field defined in the GTP-U. This field is interpreted based on the corresponding flag value from gtpuFlags.
gtpuQFI
6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U.
gtpuPduType
4-bit PDU Type field defined in PDU Session Container extension header of GTP-U.

4. Sample Use Cases

In order to identify the transport performance of PDU Sessions, e.g., with specific QoS class within a network slice or within a group of network slices hosted on the same User Plane Function (UPF), the GTP-U related IPFIX IEs would be helpful.

For example, when a set of UPFs are deployed per 5G slice, the slice is identified first using list of gNodeB IPs composing the slice and list of IPs of UPF dedicated for the slice. The gNodeB and the UPF form the tunnel endpoints. Also, the traffic for individual PDU Session per traffic direction is identified using the GTP-U TEID, GTP-U PDU Type together with above mentioned tunnel endpoints. Furthermore, the traffic for 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 there might be multiple IP flows having the same attributes.

In another scenario when multiple 5G slices share the same UPF, the slice is identified using a separated list of gNodeB IPv4 or IPv6 addresses per slice. If intermediate UPF or Uplink Classifier is deployed there is an addition of a GTP-U tunnel between the Intermediate/Uplink-Classifier UPF and the final UPF. These brings a challenge for identifying the end-to-end path for a certain PDU Session - where 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 tunnel, however the GTP-U TEIDs will be different since this is a different tunnel.

5. IANA Considerations

IANA has registered the following IEs in the "IPFIX Information Elements" registry group available at [IANA-IPFIX].

Table 1 lists the GTP-U IEs:


     +-------+-----------------+
     |Element| Name            |
     |       |                 |
     |   ID  |                 |
     |       |                 |
     +-------+-----------------+
     | 505   | gtpuFlags       |
     |       |                 |
     +-------+-----------------+
     | 506   | gtpuMsgType     |
     |       |                 |
     +-------+-----------------+
     | 507   | gtpuTEid        |
     |       |                 |
     |       |                 |
     +-------+-----------------+
     | 508   | gtpuSequenceNum |
     |       |                 |
     +-------+-----------------+
     | 509   | gtpuQFI         |
     |       |                 |
     |       |                 |
     |       |                 |
     |       |                 |
     +-------+-----------------+
     | 510   | gtpuPduType     |
     |       |                 |
     |       |                 |
     |       |                 |
     +-------+-----------------+

  Table 1: GTP-U IEs in the "IPFIX Information Elements" Registry

IANA is requested to update these entries as indicated in the following subsections.

5.1. gtpuFlags

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 [TS.29281].
Abstract Data Type:
unsigned8
Data Type Semantics:
flags
Additional Information:
Refer to Section 5.1 of [TS.29281].
Reference:
[RFC-to-be]

5.2. gtpuMsgType

Name:
gtpuMsgType
ElementID:
506
Description:
Indicates the type of the GTP-U message.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Refer to Section 5.1 of the 3GPP specification [TS.29281].
Reference:
[RFC-to-be]

5.3. gtpuTEid

Name:
gtpuTEid
ElementID:
507
Description:
This field unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint. The receiving side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between tunnel endpoints using control plane messages.
Abstract Data Type:
unsigned32
Data Type Semantics:
identifier
Additional Information:
Refer to Section 5.1 of the 3GPP specification [TS.29281].
Reference:
[RFC-to-be]

5.4. gtpuSequenceNum

Name:
gtpuSequenceNum
ElementID:
508
Description:
Export the content of the Sequence Number Field.
Abstract Data Type:
unsigned16
Data Type Semantics:
identifier
Additional Information:
Refer to Section 5.1 of the 3GPP specification [TS.29281].
Reference:
[RFC-to-be]

5.5. gtpuQFI

Name:
gtpuQFI
ElementID:
509
Description:

6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U. This is used to determine the QoS flow and QoS profile which are associated with the received packet.

The basic encoding is 8 bits. The layout of basic encoding is as follows:


          MSB -   0     1    2    3    4    5    6    7   - LSB
                +----+----+----+----+----+----+----+----+
                |Reserved |       6 bit QFI value       |
                +----+----+----+----+----+----+----+----+

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 [TS.38415] and Section 5.7.1.1 of the 3GPP specification [TS.23501] for additional details.
Reference:
[RFC-to-be]

5.6. gtpuPduType

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 basic encoding is 8 bits. The layout of basic encoding is as follows:


          MSB -   0     1    2    3    4    5    6    7   - LSB
                +----+----+----+----+----+----+----+----+
                |     Reserved      |  4 bit PDU Type   |
                +----+----+----+----+----+----+----+----+

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 [TS.38415].
Reference:
[RFC-to-be]

6. Acknowledgements

The authors would like to thank Ketan Talaulikar, Dhananjay Patki, Paul Aitken and Shraddha Hegde for their reviews and valuable comments.

7. Contributors

Cristian Staicu
Bell Canada
Kandhla Chandi
Bell Canada
Ralu Johny
Cisco

8. Implementation Status

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

8.1. Cisco IOS XR

Cisco implemented the following IEs as part of a test implementation in the IOS XR platform:

  • gtpuFlags

  • gtpuMsgType

  • gtpuTEid

  • gtpuSequenceNum

  • gtpuQFI

  • gtpuPduType

9. Security Considerations

There exist no extra security considerations regarding allocation of these IPFIX IEs compared to [RFC7012].

The IEs described in this document export GTP user plane data information on how packets are being forwarded in a 3GPP network. 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 [RFC7011] as appropriate.

10. Operational Considerations

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 [RFC7133] 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 [RFC7015] 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.

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6459]
Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, , <https://www.rfc-editor.org/info/rfc6459>.
[RFC7011]
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, , <https://www.rfc-editor.org/info/rfc7011>.
[RFC7012]
Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, , <https://www.rfc-editor.org/info/rfc7012>.
[RFC7015]
Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, , <https://www.rfc-editor.org/info/rfc7015>.
[RFC7133]
Kashima, S., Kobayashi, A., Ed., and P. Aitken, "Information Elements for Data Link Layer Traffic Measurement", RFC 7133, DOI 10.17487/RFC7133, , <https://www.rfc-editor.org/info/rfc7133>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[TS.23501]
3GPP, "5G; System architecture for the 5G System (5GS)", Version 17.11.0, 3GPP TS 23.501, .
[TS.29281]
3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", Version 17.4.0, 3GPP TS 29.281, .
[TS.38415]
3GPP, "NG-RAN; PDU Session User Plane Protocol)", Version 17.1.0, 3GPP TS 38.415, .

11.2. Informative References

[IANA-IPFIX]
"IANA, "IP Flow Information Export (IPFIX) Entities"", <https://www.iana.org/assignments/ipfix/ipfix.xhtml>.

Appendix A. IPFIX Encoding Examples

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.


          Observed GTP-U Header:
          Flags = 0x36, Message Type = 0xff, TEID = 0x1,
          Sequence number = 0x0000,
          Next extension header type = 0x85 (PDU Session container),
          PDU Type = 0, QFI = 8

A.1. Template Record

A.1.1. Template Record and Data Set

Sample template consisting of the GTP-U IEs:


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SET ID = 2           |       Length = 32             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 256        |      Field Count = 6          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuFlags = 505            |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuMsgType = 506          |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuTEid = 507             |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuSequenceNum = 508      |      Field Length = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuQFI = 509              |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  gtpuPduType = 510          |      Field Length = 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1: Sample Template Record

In this example, the Template ID is 256, which will be used in the Data Record.

The data set is represented as follows:


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SET ID = 256          |           Length = 14         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | gtpuFlags     |  gtpuMsgType  |      gtpuTEid = 0x1           |
   | = 0x36        |  = 0xff       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |   gtpuSequenceNum = 0x0000    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | gtpuQFI = 8   | gtpuPduType   |
   |               | = 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



           Figure 2: Data Set Encoding Format

Authors' Addresses

Daniel Voyer
Bell Canada
Sriram Gopalakrishnan
Cisco Systems
India
Thomas Graf
Swisscom
Benoit Claise
Huawei
Vyasraj Satyanarayana
Juniper Networks