Liaison statement
In Response to 3GPP RAN2’s LS on RoHC utilization for Ethernet header compression
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2019-04-03 |
From Group | IETF |
From Contact | Magnus Westerlund |
To Group | 3GPP-TSGRAN-RAN2 |
To Contacts | georg.mayer.huawei@gmx.com 3GPPLiaison@etsi.org |
Cc | The IESG <iesg@ietf.org> The IETF Chair <chair@ietf.org> IEEE 802 <p.nikolich@ieee.org> |
Response Contact | The IETF Chair <chair@ietf.org> |
Purpose | In response |
Attachments | (None) |
Liaisons referred by this one |
Liaison Response: ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON Lexicography"
|
Body |
Greetings, The IETF appreciate 3GPP RAN2 reaching out to IETF on the topic of robust header compression (ROHC). We are happy to answer your questions. See below for our response to your questions. But let us first provide some background information. It has been 9 years since the ROHC WG was closed, IETF currently has no established community working on ROHC. However, for minor work adding a work item to the TSVWG would be a possibility. The IETF could also consider forming a new WG if there would be good reasons for more substantial work on header compression. However, for a single ROHC profile there are no necessity for such work in IETF. In case 3GPP would see a need for combining compression of Ethernet with several sets of high layer protocols, for example Ethernet/IPv6/UDP and Ethernet/IPv6/TCP etc. there might be wider interest which may motivate doing such work in IETF. The ROHC framework is defined to allow for additional profiles and allows registration of ROHC profiles from both IETF and external bodies, such as 3GPP. The IANA registry for ROHC Profile Identifiers (https://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml#rohc-pro-ids-1) is operating under the Specification Required policy defined in RFC 8126. Q1: Does IETF or IEEE have any concerns with 3GPP defining new RoHC profile for Ethernet header compression? Answer: IETF has no issues with 3GPP defining a ROHC profile as long it is registered with IANA. Q3: In case 3GPP is allowed to develop RoHC profile for Ethernet header compression, does it have to be registered with IANA. If yes, how long can such process take? Answer: For 3GPP to be assigned a ROHC profile identifier the new profile needs to be registered with IANA. This registry operates under a Specification Required policy. A 3GPP technical specification meet the formal requirements of this policy and enable registration. There is also an IANA expert review, this review is to verify that the registration is for a ROHC profile with an interoperable description. The IANA registration process should be accomplished from submitted request to completion in a couple of weeks (2-4) given no issues are identified. When the expert has approved the registration the IANA will assign the profile an identifier. Q4: According to IETF, what are the actions needed of 3GPP to specify and maintain a ROHC profile? 3GPP defines and documents the ROHC profile in a technical specification. When the content of the specification is mature and describes a solution that fits the ROHC framework RFC 5795 and enables interoperable implementation, then 3GPP can submit a registration request to IANA (https://www.iana.org/protocols/apply) for a ROHC Profile Identifier. If there are any issues the expert will communicate such issues to the 3GPP contact person requesting the registration, so they can communicate these to the 3GPP RAN2 WG so that they can be resolved. When registration has been approved, IANA will assign a profile identifier that can be added to the 3GPP specification. Continued maintenance of the ROHC profile is solely under 3GPP responsibility. Please note that the registration request can be sent prior to the 3GPP specification is 100% complete, but the ROHC profile description needs to be mature enough for the expert to determine that the profile will result in interoperable implementations. -- Magnus Westerlund |