tsvwg Lei. zhu Internet-Draft Huawei Technologies Intended status: Informational Anil Kumar. Maguluri Expires: March 5, 2011 September 2010 ROHC profile for GTP-U compression draft-lei-tsvwg-gtpu-compression-00 Abstract This document specifies the comoression profile for IP/UDP/GTP-U header chain. ROHCv1 profiles [RFC 5795, RFC 4815] efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. The second version of the above profiles [ROHCv2] introduces a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. The ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation [RFC 4997]. To compress the defined GTP-U header chain uses the ROHCv2 mechanism as mentioned above. 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 http://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 March 5, 2011. zhu & Maguluri Expires March 5, 2011 [Page 1] Internet-Draft GTP-U compression September 2010 Copyright Notice Copyright (c) 2010 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 (http://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 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. zhu & Maguluri Expires March 5, 2011 [Page 2] Internet-Draft GTP-U compression September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Background (Informative) . . . . . . . . . . . . . . . . . . . 5 4.1. Classification of Header Fields . . . . . . . . . . . . . 5 4.2. Control Field . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Master Sequence Number (MSN) . . . . . . . . . . . . . 6 4.3. Compressed Header Chain . . . . . . . . . . . . . . . . . 6 4.4. Header Formats and Encoding Methods [TBD] . . . . . . . . 7 4.5. Encoding Methods with External Parameters as Arguments [TBD] . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6. Header Formats . . . . . . . . . . . . . . . . . . . . . . 7 4.6.1. Packet types . . . . . . . . . . . . . . . . . . . . . 7 4.6.2. Initialization and Refresh (IR) Packets . . . . . . . 7 4.6.3. Compressed (CO) Packets . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Appendix 1. Detailed Classification of Header Fields . . . . . . 13 1.1. GTP-U Header Fields . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 zhu & Maguluri Expires March 5, 2011 [Page 3] Internet-Draft GTP-U compression September 2010 1. Introduction The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets or compression requirements. The ROHC framework was first documented in [RFC3095], together with profiles for compression of RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload) headers. Additional profiles for compression of IP headers [RFC3843] and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were later specified to complete the initial set of ROHC profiles. The updated version of the above profiles are developed and documented [RFC 5225], using the ROHC formal notation [RFC 4997]. This document defines a compressed profile for IP/UDP/GTP-U header chain, using the ROHCv2 [RFC 5225] mechanism, which inturn used the ROHC formal notation [RFC 4997]. 3GPP (3rd Generation Partnership Project) defined GPRS Tunnelling Protocol (GTP) which can be decomposed into separate protocols, GTP-C, GTP-U and GTP'. GTP-U is, in effect a relatively simple IP based tunneling protocol which permits many tunnels between each set of end points. The separate tunnels are identified by a TEID (Tunnel Endpoint Identifier) in the GTP-U messages, which should be a dynamically allocated random number. If this random number is of cryptographic quality, then it will provide a measure of security against certain attacks. Even so, the requirement of the 3GPP standard is that all GTP traffic, including user data should be sent within secure private networks, not directly connected to the Internet. This happens on UDP port 2152. The compression of the extension headers is same as the mechanism developed in ROHCv2 [RFC 5225]. The usage of this profile is defined in 3GPP specification for UMTS [3GPP TS29.281] and LTE [3GPP TR 36.806] As per the 3GPP specification, IP/UDP/GTP-U header chain encapsulates application layer headers over the protocol stack over Un interface. The typical applications running over Un interface are most considered as voice over IP applications which are carried and managed by RTP/RTCP protocol over outer IP/UDP headers. Therefore, at the Un interface, IP/UDP/RTP header chain which is also called as inner IP header chain which is the dominated application of zhu & Maguluri Expires March 5, 2011 [Page 4] Internet-Draft GTP-U compression September 2010 operators are responsible to carry voice over IP type application, and, private transport protocol (GTP-U) which is also called as IP/ UDP/GTP-U outer IP header chain encapsulates inner IP header chain. 2. Terminology 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 [RFC2119]. This document is consistent with the terminology found in the ROHC framework [RFC4995] and in the formal notation for ROHC [RFC4997]. 3. Acronyms This section lists most acronyms used for reference, in addition to those defined in [RFC4995 & RFC 3095]. GTP -- GPRS Tunnelling Protocol GTP-C -- GTP Control Plane GTP-U -- GTP User Plane 4. Background (Informative) This section provides background information on the compression profile defined in this document. The fundamentals of general header compression [RFC 5225] and of the ROHC framework may be found in sections 3 and 4 of [RFC4995], respectively. The fundamentals of the formal notation for ROHC are defined in [RFC4997]. 4.1. Classification of Header Fields Section?.1 of [RFC4995] explains that header compression is possible due to the fact that there is much redundancy between field values within the headers of a packet, especially between the headers of consecutive packets. Appendix A lists and classifies in detail all the header fields relevant to this document. The appendix concludes with recommendations on how the various fields should be handled by header compression algorithms. The main conclusion is that most of the header fields can easily be zhu & Maguluri Expires March 5, 2011 [Page 5] Internet-Draft GTP-U compression September 2010 compressed away since they never or seldom change. For GTP-U, the Sequence Number (SN) is optional. First we should check the inner header chain, whether the inner header has RTP header or not. If RTP header is present, the RTP-SN act as MSN otherwise the compressor generates a 16-bit sequence number SN which increases by one for each packet received in the packet stream. 4.2. Control Field 4.2.1. Master Sequence Number (MSN) The Master Sequence Number (MSN) field is either taken from a field that already exists in one of the headers of the protocol that the profile compresses (e.g., RTP SN from the inner header), or alternatively it is created at the compressor. There is one MSN space per context. The MSN field has the following two functions: o Differentiating between reference headers when receiving feedback data; o Inferring the value of incrementing fields (e.g., IPv4 Identifier). There is one MSN field in every ROHCv2 header, i.e., the MSN is always present in each header type sent by the compressor. The MSN is sent in full in IR headers, while it can be lsb encoded within CO header formats. The decompressor always includes LSBs of the MSN in the Acknowledgment Number field in feedback (see Section 6.9). The compressor can later use this field to infer what packet the decompressor is acknowledging. For profiles for which the MSN is created by the compressor (i.e., GTP-U if the inner header chain does not have RTP header), the following applies: o The compressor only initializes the MSN for a context when that context is first created or when the profile associated with a context changes; o When the MSN is initialized, it is initialized to a random value; o The value of the MSN SHOULD be incremented by one for each packet that the compressor sends for a specific CID. 4.3. Compressed Header Chain Some header types use one or more chains containing sub-header information. The function of a chain is to group fields based on similar characteristics, such as static, dynamic, or irregular fields. zhu & Maguluri Expires March 5, 2011 [Page 6] Internet-Draft GTP-U compression September 2010 Chaining is done by appending an item for each header to the chain in their order of appearance in the uncompressed packet, starting from the fields in the outermost header. In the text below, the term "protocol_name" is used to identify formal notation names corresponding to different protocol headers. The mapping between these is defined in the following table: +----------------------------------+---------------+ | Protocol | protocol_name | +----------------------------------+---------------+ | GTP-U | gtpu | +----------------------------------+---------------+ 4.4. Header Formats and Encoding Methods [TBD] 4.5. Encoding Methods with External Parameters as Arguments [TBD] 4.6. Header Formats 4.6.1. Packet types ROHC profile for IP/UDP/GTP-U uses several different packet types: the Initialization and Refresh (IR) packet type and the Compressed (CO) packet type. Each packet type defines a number of packet formats: two packet formats are defined for the IR type and two sets of eight base header formats are defined for the CO type with one additional format that is common to both sets. The profile identifier for ROHC-GTP is 0xXXXX. 4.6.2. Initialization and Refresh (IR) Packets ROHC profile for IP/UDP/GTP-U uses the basic structure of the ROHC IR and IR-DYN packets as defined in [RFC4995] (Sections 5.2.2.1 and 5.2.2.2, respectively). Packet type: IR This packet type communicates the static part and the dynamic part of the context. For the ROHC profile of IP/UDP/GTP-U IR packet, the value of the x bit MUST be set to '1'. It has the following format, which corresponds to the "Header" and "Payload" fields described in Section zhu & Maguluri Expires March 5, 2011 [Page 7] Internet-Draft GTP-U compression September 2010 5.2.1 of [RFC4995]: 0 1 2 3 4 5 6 7 +-------------------------------+ | Add-CID octet | if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile = 0xXXXX | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Static chain / variable length | | +-------------------------------+ | | + Dynamic chain + variable length | | +-------------------------------+ | | / Payload / variable length | | - - - - - - - - - - - - - - - - IR packet format CRC: 8-bit CRC, computed according to Section 5.3.1.1. of [RFC4995]. The CRC covers the entire IR header, thus excluding payload, padding, and feedback, if any. Static chain: See Section XXXX Dynamic chain: See Section XXXX Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the TCP header to end of the uncompressed packet. The presence of a payload is inferred from the packet length. Packet type: IR-DYN This packet type communicates the dynamic part of the context. zhu & Maguluri Expires March 5, 2011 [Page 8] Internet-Draft GTP-U compression September 2010 The ROHC-TCP IR-DYN packet has the following format, which corresponds to the "Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]: 0 1 2 3 4 5 6 7 +-------------------------------+ | Add-CID octet | if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 0 0 | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile = 0xXXXX | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Static chain / variable length | | +-------------------------------+ | | + Dynamic chain + variable length | | +-------------------------------+ | | / Payload / variable length | | - - - - - - - - - - - - - - - - IR-DYN packet format CRC: 8-bit CRC, computed according to Section 5.3.1.1 of [RFC4995]. The CRC covers the entire IR-DYN header, thus excluding payload, padding, and feedback, if any. Dynamic chain: See Section XXXX. Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the TCP header to end of the uncompressed packet. The presence of a payload is inferred from the packet length. zhu & Maguluri Expires March 5, 2011 [Page 9] Internet-Draft GTP-U compression September 2010 4.6.3. Compressed (CO) Packets The ROHC profile for IP/UDP/GTP-U communicate irregularities in the packet header. All CO packets carry a CRC and can update the context. The general format for a compressed TCP header is as follows, which corresponds to the "Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]: 0 1 2 3 4 5 6 7 +-------------------------------+ | Add-CID octet | if for small CIDs and CID 1-15 +---+---+---+---+---+---+---+---+ | First octet of base header | (with type indication) +---+---+---+---+---+---+---+---+ : : / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ / Remainder of base header / variable number of octets +---+---+---+---+---+---+---+---+ : Irregular chain : / (including irregular chain / variable : items for TCP options) : --- --- --- --- --- --- --- --- | | / Payload / variable length | | - - - - - - - - - - - - - - - - CO packet format Base header: The complete set of base headers is defined in Section xxxx. Irregular chain: See Section xxxx and Section xxxx. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length. 5. Security Considerations TBD. zhu & Maguluri Expires March 5, 2011 [Page 10] Internet-Draft GTP-U compression September 2010 6. IANA Considerations ROHC profile identifier for IP/UDP/GTP-U compression is to be reserved by IANA. Following ROHC profile identifiers are reserved by IANA: +------------------+-----------------------+--------------+ |Profile identifier| Usage | Reference | +------------------+-----------------------+--------------+ | 0x0000 | ROHC uncompressed | RFC5795 | +------------------+-----------------------+--------------+ | 0x0001-0x0003 |ROHC RTP, UDP, ESP | RFC3095 | +------------------+-----------------------+--------------+ | 0x0004 | ROHC IP | RFC3843 | +------------------+-----------------------+--------------+ | 0x0005 | ROHC LLA | RFC4362 | +------------------+-----------------------+--------------+ | 0x0006 | ROHC TCP | RFC4996 | +------------------+-----------------------+--------------+ | 0x0007-0x0008 | ROHC RTP/UDP-Lite | RFC4019 | +------------------+-----------------------+--------------+ | 0x0101-0x0104 | ROHCv2 RTP, UDP, ESP | RFC5225 | +------------------+-----------------------+--------------+ | 0x0107-0x0108 | ROHCv2 RTP/UDP-Lite | RFC5225 | +------------------+-----------------------+--------------+ ROHC profile identifers and references A new ROHC profile identifier for IP/UDP/GTP-U is to be reserved by IANA following those current ROHC profile identifiers. 7. Acknowledgments TBD 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007. zhu & Maguluri Expires March 5, 2011 [Page 11] Internet-Draft GTP-U compression September 2010 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010. Authors' Addresses Lei Zhu Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836301 Email: Lei.zhu@huawei.com Anil Kumar Maguluri Email: anilmaguluri@gmail.com zhu & Maguluri Expires March 5, 2011 [Page 12] Internet-Draft GTP-U compression September 2010 1. Detailed Classification of Header Fields Header compression is possible due to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. In this appendix, all fields in the headers compressible by these profiles are classified and analyzed. The analysis is based on behavior for the types of traffic that are expected to be the most frequently compressed (e.g., RTP field behavior is based on voice and/or video traffic behavior). Fields are classified as belonging to one of the following classes: o INFERRED - These fields contain values that can be inferred from other values, for example the size of the frame carrying the packet, and thus do not have to be included in compressed packets. o STATIC - These fields are expected to be constant throughout the lifetime of the flow; in general, it is sufficient to design a compressed format so that these fields are only updated by IR packets. o STATIC-DEF - These fields are expected to be constant throughout the lifetime of the flow and their values can be used to define a flow. They are only sent in IR packets. o STATIC-KNOWN - These fields are expected to have well-known values and therefore do not need to be communicated at all. o SEMISTATIC - These fields are unchanged most of the time. However, occasionally the value changes but will revert to its original value. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets. o RARELY CHANGING (RACH) - These are fields that change their values occasionally and then keep their new values. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets. o IRREGULAR - These are the fields for which no useful change pattern can be identified and should be transmitted uncompressed in all compressed packets. o PATTERN - These are fields that change between each packet, but change in a predictable pattern. zhu & Maguluri Expires March 5, 2011 [Page 13] Internet-Draft GTP-U compression September 2010 1.1. GTP-U Header Fields Existing message format of GTP-U version 2: +---+----+-+-+-+-+--+------------+-----------------+------------------+ | |0-2 |3|4|5|6|7 | 8-15 | 16-23 | 24-31 | +---+----+-+-+-+-+--+------------+-----------------+------------------+ |0 |Veri|P|*|E|S|PN| Message | | | |son | | | | | | Type | Total length | +---+----+-+-+-+-+--+------------+------------------------------------+ |32 | TEID (only present if T=1) | | | | +---+----------------------------+-----------------+------------------+ |64 | Sequence number |N-PDU number |Next extension | | | | |header type | +---+----------------------------+-----------------+------------------+ Current GTP-U packet format Version field: This field is used to determine the version of the GTP-U protocol. The version number shall be set to '1'. This field contains static parameter in a series of GTP-U messages. Protocol Type (PT): This bit is used as a protocol discriminator between GTP (when PT is '1') and GTP' (when PT is '0'). GTP-U header should always use '1' as the value of this parameter. This field contains static parameter in a series of GTP-U messages. Extension Header flag (E): This flag indicates the presence of a meaningful value of the Next Extension Header field. This field contains static parameter in a series of GTP-U messages. Sequence number flag (S): This flag indicates the presence of a meaningful value of the Sequence Number field. N-PDU Number flag (PN): This flag indicates the presence of a meaningful value of the N-PDU Number field. This field contains static parameter in a series of GTP-U messages. Message Type: This field indicates the type of GTP-U message. This field contains static parameter in a series of GTP-U messages. Length: This field indicates the length in octets of the payload, i.e. the rest of the packet following the mandatory part of the GTP header (that is the first 8 octets). The Sequence Number, the N-PDU Number or any Extension headers would be considered to be part of the payload, i.e. included in the length count. zhu & Maguluri Expires March 5, 2011 [Page 14] Internet-Draft GTP-U compression September 2010 Tunnel Endpoint Identifier (TEID): This field unambiguously identifies a tunnel endpoint in the receiving GTP U protocol entity. This field contains static parameter in a series of GTP-U messages.