Internet-Draft | IPFIX support for GTP-U | October 2024 |
Voyer, et al. | Expires 21 April 2025 | [Page] |
This document introduces IP Flow Information Export Information Elements to identify 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.¶
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 21 April 2025.¶
Copyright (c) 2024 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.¶
A dedicated header, called GPRS Tunneling Protocol Header (GTP), is defined by 3GPP for use of GTP-C Control plane and GTP-U User Plane [TS.29281] traffic of mobile subscribers.¶
This document specifies six IPFIX Information Elements (IEs) [RFC7012] for fields within a GTP-U header.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section defines IPFIX IEs corresponding to various fields in the GTP-U.¶
In order to identify the transport performance of PDU Sessions with specific QoS within a slice or within a group of slices hosted on the same UPF the GTP User Plane related IEs would be much helpful.¶
For example when in case of one or a couple of dedicated UPFs are deployed per 5G slice, the slice is identified first using list of gNodeB IPs composing the slice and list of IPs of User Plane Function dedicated for the slice. The gNodeB and the User Plane Function form the tunnel endpoints. Also the traffic for individual PDU session per direction is identified using the GTP-U TEID, GTP-U PDU Type together with above mentioned tunnel endpoints. Further the traffic for specific QoS within a PDU session per direction is identified using the combination of GTP-U TEID, GTP-U PDU Type and GTP-U QFI attributes. It is possible that there may be multiple IP flows having the same attributes.¶
In another scenario when multiple 5G slices are served by the same User Plane Function, the slice is identified using a separated list of gNodeB IPv6 addresses per slice. If Intermediate User Plane Function 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.¶
IANA has added the following new IEs to the "IPFIX Information Elements" registry [RFC7012] 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¶
6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U. This is defined in section 5.5.3.3 of the 3GPP specification [TS.38415]. 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¶
4-bit PDU type field defined in PDU Session Container extension header of GTP-U. This is defined in section 5.5.3 of the 3GPP specification [TS.38415]. 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¶
The authors would like to thank Ketan Talaulikar and Dhananjay Patki for their reviews and valuable comments.¶
Note to the RFC-Editor: Please remove this section before publishing.¶
There exists no extra security considerations regarding allocation of these IPFIX IEs compared to [RFC7012].¶
The IEs described in this document export GTP user plane data metrics on how packets are being forwarded in 5G 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.¶
The IPFIX extensions defined in this draft requires deep parsing and extraction of fields from the packet. 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.¶
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¶
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¶