Skip to main content

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