GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5795

Internet Engineering Task Force (IETF) K. Sandlund Request for Comments: 5795 G. Pelletier Obsoletes: 4995 Ericsson Category: Standards Track L-E. Jonsson ISSN: 2070-1721 March 2010

           The RObust Header Compression (ROHC) Framework

Abstract

 The Robust Header Compression (ROHC) protocol provides an efficient,
 flexible, and future-proof header compression concept.  It is
 designed to operate efficiently and robustly over various link
 technologies with different characteristics.
 The ROHC framework, along with a set of compression profiles, was
 initially defined in RFC 3095.  To improve and simplify the ROHC
 specifications, this document explicitly defines the ROHC framework
 and the profile for uncompressed separately.  More specifically, the
 definition of the framework does not modify or update the definition
 of the framework specified by RFC 3095.
 This specification obsoletes RFC 4995.  It fixes one interoperability
 issue that was erroneously introduced in RFC 4995, and adds some
 minor clarifications.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5795.

Sandlund, et al. Standards Track [Page 1] RFC 5795 ROHC Framework March 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.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.2.  ROHC Terminology . . . . . . . . . . . . . . . . . . . . .  5
 3.  Background (Informative) . . . . . . . . . . . . . . . . . . .  8
   3.1.  Header Compression Fundamentals  . . . . . . . . . . . . .  8
   3.2.  A Short History of Header Compression  . . . . . . . . . .  9
 4.  Overview of ROHC (Informative) . . . . . . . . . . . . . . . . 10
   4.1.  General Principles . . . . . . . . . . . . . . . . . . . . 10
   4.2.  Compression Efficiency, Robustness, and Transparency . . . 11
   4.3.  Developing the ROHC Protocol . . . . . . . . . . . . . . . 12
   4.4.  Operational Characteristics of the ROHC Channel  . . . . . 13
   4.5.  Compression and Master Sequence Number (MSN) . . . . . . . 14
   4.6.  Static and Dynamic Parts of a Context  . . . . . . . . . . 15
 5.  The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 15
   5.1.  The ROHC Channel . . . . . . . . . . . . . . . . . . . . . 15
     5.1.1.  Contexts and Context Identifiers . . . . . . . . . . . 15
     5.1.2.  Per-Channel Parameters . . . . . . . . . . . . . . . . 16
     5.1.3.  Persistence of Decompressor Contexts . . . . . . . . . 17

Sandlund, et al. Standards Track [Page 2] RFC 5795 ROHC Framework March 2010

   5.2.  ROHC Packets and Packet Types  . . . . . . . . . . . . . . 17
     5.2.1.  General Format of ROHC Packets . . . . . . . . . . . . 18
       5.2.1.1.  Format of the Padding Octet  . . . . . . . . . . . 19
       5.2.1.2.  Format of the Add-CID Octet  . . . . . . . . . . . 19
       5.2.1.3.  General Format of Header . . . . . . . . . . . . . 19
     5.2.2.  Initialization and Refresh (IR) Packet Types . . . . . 20
       5.2.2.1.  ROHC IR Header Format  . . . . . . . . . . . . . . 20
       5.2.2.2.  ROHC IR-DYN Header Format  . . . . . . . . . . . . 21
     5.2.3.  ROHC Initial Decompressor Processing . . . . . . . . . 22
     5.2.4.  ROHC Feedback  . . . . . . . . . . . . . . . . . . . . 23
       5.2.4.1.  ROHC Feedback Format . . . . . . . . . . . . . . . 24
     5.2.5.  ROHC Segmentation  . . . . . . . . . . . . . . . . . . 26
       5.2.5.1.  Segmentation Usage Considerations  . . . . . . . . 26
       5.2.5.2.  Segmentation Protocol  . . . . . . . . . . . . . . 26
   5.3.  General Encoding Methods . . . . . . . . . . . . . . . . . 28
     5.3.1.  Header Compression CRCs, Coverage, and Polynomials . . 28
       5.3.1.1.  8-bit CRC in IR and IR-DYN Headers . . . . . . . . 28
       5.3.1.2.  3-bit CRC in Compressed Headers  . . . . . . . . . 28
       5.3.1.3.  7-bit CRC in Compressed Headers  . . . . . . . . . 29
       5.3.1.4.  32-bit Segmentation CRC  . . . . . . . . . . . . . 29
     5.3.2.  Self-Describing Variable-Length Values . . . . . . . . 30
   5.4.  ROHC UNCOMPRESSED -- No Compression  (Profile 0x0000)  . . 30
     5.4.1.  IR Packet  . . . . . . . . . . . . . . . . . . . . . . 31
     5.4.2.  Normal Packet  . . . . . . . . . . . . . . . . . . . . 32
     5.4.3.  Context Initialization . . . . . . . . . . . . . . . . 32
     5.4.4.  Decompressor Operation . . . . . . . . . . . . . . . . 33
     5.4.5.  Feedback . . . . . . . . . . . . . . . . . . . . . . . 33
 6.  Overview of a ROHC Profile (Informative) . . . . . . . . . . . 33
 7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 35
 8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
 9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
   10.2. Informative References . . . . . . . . . . . . . . . . . . 37
 Appendix A.  CRC Algorithm . . . . . . . . . . . . . . . . . . . . 39

Sandlund, et al. Standards Track [Page 3] RFC 5795 ROHC Framework March 2010

1. Introduction

 For many types of networks, reducing the deployment and operational
 costs by improving the usage of the bandwidth resources is of vital
 importance.  Header compression over a link is possible because some
 of the information carried within the header of a packet becomes
 compressible between packets belonging to the same flow.
 For links where the overhead of the IP header(s) is problematic, the
 total size of the header may be significant.  Applications
 transferring data carried within RTP [RFC3550] will then, in addition
 to link-layer framing, have an IPv4 [RFC0791] header (20 octets), a
 UDP [RFC0768] header (8 octets), and an RTP header (12 octets), for a
 total of 40 octets.  With IPv6 [RFC2460], the IPv6 header is 40
 octets for a total of 60 octets.  Applications transferring data
 using TCP [RFC0793] will have 20 octets for the transport header, for
 a total size of 40 octets for IPv4 and 60 octets for IPv6.
 The relative gain for specific flows (or applications) depends on the
 size of the payload used in each packet.  For applications such as
 Voice over IP, where the size of the payload containing coded speech
 can be as small as 15-20 octets, this gain will be quite significant.
 Similarly, relative gains for TCP flows carrying large payloads (such
 as file transfers) will be less than for flows carrying smaller
 payloads (such as application signaling, e.g., session initiation).
 As more and more wireless link technologies are being deployed to
 carry IP traffic, care must be taken to address the specific
 characteristics of these technologies within the header compression
 algorithms.  Legacy header compression schemes, such as those defined
 in [RFC2507] and [RFC2508], have been shown to perform inadequately
 over links where both the lossy behavior and the round-trip times are
 non-negligible, such as those observed, for example, in wireless
 links and IP tunnels.
 In addition, a header compression scheme should handle the often non-
 trivial residual errors, i.e., where the lower layer may pass a
 packet that contains undetected bit errors to the decompressor.  It
 should also handle loss and reordering before the compression point,
 as well as on the link between the compression and decompression
 points [RFC4224].
 The Robust Header Compression (ROHC) protocol provides an efficient,
 flexible, and future-proof header compression concept.  It is
 designed to operate efficiently and robustly over various link
 technologies with different characteristics.

Sandlund, et al. Standards Track [Page 4] RFC 5795 ROHC Framework March 2010

 RFC 3095 [RFC3095] defines the ROHC framework along with an initial
 set of compression profiles.  To improve and simplify the
 specification, the framework and the profiles' parts have been split
 into separate documents.  This document explicitly defines the ROHC
 framework, but it does not modify or update the definition of the
 framework specified by RFC 3095; both documents can be used
 independently of each other.  This also implies that implementations
 based on either definition will be compatible and interoperable with
 each other.  However, it is the intent to let this specification
 replace RFC 3095 as the base specification for all profiles defined
 in the future.
 This document fixes one interoperability issue that was erroneously
 introduced in RFC 4995.  The fix for this issue is located in
 Section 5.2.4.1 and clarifies the interpretation of the Size field in
 ROHC feedback.

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].

2.1. Acronyms

 This section lists most acronyms used for reference.
 ACK    Acknowledgment.
 CID    Context Identifier.
 CO     Compressed Packet Format.
 CRC    Cyclic Redundancy Check.
 IR     Initialization and Refresh.
 IR-DYN Initialization and Refresh, Dynamic part.
 LSB    Least Significant Bit.
 MRRU   Maximum Reconstructed Reception Unit.
 MSB    Most Significant Bit.
 MSN    Master Sequence Number.
 NACK   Negative Acknowledgment.
 ROHC   RObust Header Compression.

2.2. ROHC Terminology

 Context
    The context of the compressor is the state it uses to compress a
    header.  The context of the decompressor is the state it uses to
    decompress a header.  Either of these or the two in combination
    are usually referred to as "context", when it is clear which is

Sandlund, et al. Standards Track [Page 5] RFC 5795 ROHC Framework March 2010

    intended.  The context contains relevant information from previous
    headers in the packet flow, such as static fields and possible
    reference values for compression and decompression.  Moreover,
    additional information describing the packet flow is also part of
    the context, for example, information about the change behavior of
    fields (e.g., the IP Identifier behavior, or the typical inter-
    packet increase in sequence numbers and timestamps).
 Context damage
    When the context of the decompressor is not consistent with the
    context of the compressor, decompression may fail to reproduce the
    original header.  This situation can occur when the context of the
    decompressor has not been initialized properly or when packets
    have been lost or damaged between the compressor and decompressor.
    Packets that cannot be decompressed due to inconsistent contexts
    are said to be lost due to context damage.  Packets that are
    decompressed but contain errors due to inconsistent contexts are
    said to be damaged due to context damage.
 Context repair mechanisms
    Mechanisms used to resynchronize the contexts -- an important task
    since context damage causes loss propagation.  Examples of such
    mechanisms are NACK-based mechanisms, and the periodic refreshes
    of important context information, usually done in unidirectional
    operation.  There are also mechanisms that can reduce the context
    inconsistency probability, for example, repetition of the same
    type of information in multiple packets and CRCs that protect
    context-updating information.
 CRC-8 validation
    The validation of the integrity against bit error(s) in a received
    IR and IR-DYN header using the 8-bit CRC included in the IR/IR-DYN
    header.
 CRC verification
    The verification of the result of a decompression attempt using
    the 3-bit CRC or 7-bit CRC included in the header of a compressed
    packet format.

Sandlund, et al. Standards Track [Page 6] RFC 5795 ROHC Framework March 2010

 Damage propagation
    Delivery of incorrect decompressed headers due to context damage,
    such as errors in (i.e., loss of or damage to) previous header(s)
    or feedback.
 Error detection
    Detection of errors by lower layers.  If error detection is not
    perfect, there will be residual errors.
 Error propagation
    Damage propagation or loss propagation.
 ROHC profile
    A compression protocol that specifies how to compress specific
    header combinations.  A ROHC profile may be tailored to handle a
    specific set of link characteristics, e.g., loss characteristics,
    reordering between compression points, etc.  ROHC profiles provide
    the details of the header compression framework defined in this
    document, and each compression profile is associated with a unique
    ROHC profile identifier [ROHC-ids].  When setting up a ROHC
    channel, the set of profiles supported by both endpoints of the
    channel is negotiated, and when initializing new contexts, a
    profile identifier from this negotiated set is used to associate
    each compression context with one specific profile.
 Link
    A physical transmission path that constitutes a single IP hop.
 Loss propagation
    Loss of headers, due to errors in (i.e., loss of or damage to)
    previous header(s) or feedback.
 Packet flow
    A sequence of packets where the field values and change patterns
    of field values are such that the headers can be compressed using
    the same context.
 Residual error
    Error introduced during transmission and not detected by lower-
    layer error detection schemes.

Sandlund, et al. Standards Track [Page 7] RFC 5795 ROHC Framework March 2010

 ROHC channel
    A logical unidirectional point-to-point channel carrying ROHC
    packets from one compressor to one decompressor, optionally
    carrying ROHC feedback information on the behalf of another
    compressor-decompressor pair operating on a separate ROHC channel
    in the opposite direction.  See also [RFC3759].
 This document also makes use of the conceptual terminology defined by
 "ROHC Terminology and Channel Mapping Examples", RFC 3759 [RFC3759].

3. Background (Informative)

 This section provides a background to the subject of header
 compression.  The fundamental ideas are described together with a
 discussion about the history of header compression schemes.  The
 motivations driving the development of the various schemes are
 discussed and their drawbacks identified, thereby providing the
 foundations for the design of the ROHC framework and profiles
 [RFC3095].

3.1. Header Compression Fundamentals

 Header compression is possible because there is significant
 redundancy between header field values within packets, but in
 particular between consecutive packets belonging to the same flow.
 On the path end-to-end, the entire header information is necessary
 for all packets in the flow, but over a single link, some of this
 information becomes redundant and can be reduced, as long as it is
 transparently recovered at the receiving end of the link.  The header
 size can be reduced by first sending field information that is
 expected to remain static for (at least most of) the lifetime of the
 packet flow.  Further compression is achieved for the fields carrying
 information that changes more dynamically by using compression
 methods tailored to their respective assumed change behavior.
 To achieve compression and decompression, some necessary information
 from past packets is maintained in a context.  The compressor and the
 decompressor update their respective contexts upon certain, not
 necessarily synchronized, events.  Impairment events may lead to
 inconsistencies in the decompressor context (i.e., context damage),
 which in turn may cause incorrect decompression.  A Robust Header
 Compression scheme needs mechanisms to minimize the possibility of
 context damage, in combination with mechanisms for context repair.

Sandlund, et al. Standards Track [Page 8] RFC 5795 ROHC Framework March 2010

3.2. A Short History of Header Compression

 The first header compression scheme, compressed TCP (CTCP) [RFC1144],
 was introduced by Van Jacobson.  CTCP, also often referred to as VJ
 compression, compresses the 40 octets of the TCP/IP header down to 4
 octets.  CTCP uses delta encoding for sequentially changing fields.
 The CTCP compressor detects transport-level retransmissions and sends
 a header that updates the entire context when they occur.  This
 repair mechanism does not require any explicit signaling between the
 compressor and decompressor.
 A general IP header compression scheme, IP header compression
 [RFC2507], improves somewhat on CTCP.  IP header compression (IPHC)
 can compress arbitrary IP, TCP, and UDP headers.  When compressing
 non-TCP headers, IPHC does not use delta encoding and is robust.  The
 repair mechanism of CTCP is augmented with negative acknowledgments,
 called CONTEXT_STATE messages, which speed up the repair.  This
 context repair mechanism is thus limited by the round-trip time of
 the link.  IPHC does not compress RTP headers.
 CRTP [RFC2508] is an RTP extension to IPHC.  CRTP compresses the 40
 octets of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP
 Checksum is not enabled.  If the UDP Checksum is enabled, the minimum
 CRTP header is 4 octets.
 On lossy links with long round-trip times, CRTP does not perform well
 [CRTP-eval].  Each packet lost over the link causes decompression of
 several subsequent packets to fail, because the context becomes
 invalidated during at least one link round-trip time from the lost
 packet.  Unfortunately, the large headers that CRTP sends when
 updating the context waste additional bandwidth.
 CRTP uses a local repair mechanism known as TWICE, which was
 introduced by IPHC.  TWICE derives its name from the observation that
 when the flow of compressed packets is regular, the correct guess
 when one packet is lost between the compression points is to apply
 the update in the current packet twice.  While TWICE improves CRTP
 performance significantly, [CRTP-eval] also found that even with
 TWICE, CRTP doubled the number of lost packets.
 An enhanced variant of CRTP, called eCRTP [RFC3545], means to improve
 the robustness of CRTP in the presence of reordering and packet
 losses, while keeping the protocol almost unchanged from CRTP.  As a
 result, eCRTP does provide better means to implement some degree of
 robustness, albeit at the expense of additional overhead, leading to
 a reduction in compression efficiency in comparison to CRTP.

Sandlund, et al. Standards Track [Page 9] RFC 5795 ROHC Framework March 2010

4. Overview of ROHC (Informative)

4.1. General Principles

 As mentioned earlier, header compression is possible per-link due to
 the fact that there is much redundancy between header field values
 within packets, and especially between consecutive packets belonging
 to the same flow.  To utilize these properties for header
 compression, there are a few essential steps to consider.
 The first step consists of identifying and grouping packets together
 into different "flows", so that packet-to-packet redundancy is
 maximized in order to improve the compression ratio.  Grouping
 packets into flows is usually based on source and destination host
 (IP) addresses, transport protocol type (e.g., UDP or TCP), process
 (port) numbers, and potentially additional unique application
 identifiers, such as the synchronization source (SSRC) in RTP
 [RFC3550].  The compressor and decompressor each establish a context
 for the packet flow and identify the context with a Context
 Identifier (CID) included in each compressed header.
 The second step is to understand the change patterns of the various
 header fields.  On a high level, header fields fall into one of the
 following classes:
 INFERRED      These fields contain values that can be inferred from
               other fields or external sources; for example, the size
               of the frame carrying the packet can often be derived
               from the link-layer protocol, and thus does not have to
               be transmitted by the compression scheme.
 STATIC        Fields classified as STATIC are assumed to be constant
               throughout the lifetime of the packet flow.  The value
               of each field is thus only communicated initially.
 STATIC-DEF    Fields classified as STATIC-DEF are used to define a
               packet flow as discussed above.  Packets for which
               respective values of these fields differ are treated as
               belonging to different flows.  These fields are in
               general compressed as STATIC fields.
 STATIC-KNOWN  Fields classified as STATIC-KNOWN are expected to have
               well-known values, and therefore their values do not
               need to be communicated.

Sandlund, et al. Standards Track [Page 10] RFC 5795 ROHC Framework March 2010

 CHANGING      These fields are expected to vary randomly, either
               within a limited value set or range, or in some other
               manner.  CHANGING fields are usually handled in more
               sophisticated ways based on a more detailed
               classification of their expected change patterns.
 Finally, the last step is to choose the encoding method(s) that will
 be applied onto different fields based on classification.  The
 encoding methods, in combination with the identified field behavior,
 provide the input to the design of the compressed header formats.
 The analysis of the probability distribution of the identified change
 patterns then provides the means to optimize the packet formats,
 where the most frequently occurring change patterns for a field
 should be encoded within the most efficient format(s).
 However, compression efficiency has to be traded against two other
 properties: the robustness of the encoding to losses and errors
 between the compressor and the decompressor, and the ability to
 detect and cope with errors in the decompression process.

4.2. Compression Efficiency, Robustness, and Transparency

 The performance of a header compression protocol can be described
 with three parameters: its compression efficiency, its robustness,
 and its compression transparency.
 Compression efficiency
    The compression efficiency is determined by how much the average
    header size is reduced by applying the compression protocol.
 Robustness
    A robust protocol tolerates packet losses, residual bit errors,
    and out-of-order delivery on the link over which header
    compression takes place, without losing additional packets or
    introducing additional errors in decompressed headers.
 Compression transparency
    The compression transparency is a measure of the extent to which
    the scheme maintains the semantics of the original headers.  If
    all decompressed headers are bitwise identical to the
    corresponding original headers, the scheme is transparent.

Sandlund, et al. Standards Track [Page 11] RFC 5795 ROHC Framework March 2010

4.3. Developing the ROHC Protocol

 The challenge in developing a header compression protocol is to
 conciliate compression efficiency and robustness while maintaining
 transparency, as increasing robustness will always come at the
 expense of a lower compression efficiency, and vice versa.  The
 scheme should also be flexible enough in its design to minimize the
 impacts from the varying round-trip times and loss patterns of links
 where header compression will be used.
 To achieve this, the header compression scheme must provide
 facilities for the decompressor to verify decompression and detect
 potential context damage, as well as context recovery mechanisms such
 as feedback.  Header compression schemes prior to the ones developed
 by the Robust Header Compression (ROHC) Working Group (WG) were not
 designed with the above high-level objectives in mind.
 The ROHC WG has developed header compression solutions to meet the
 needs of present and future link technologies.  While special
 attention has been put towards meeting the more stringent
 requirements stemming from the characteristics of wireless links, the
 results are equally applicable to many other link technologies.
 "RObust Header Compression (ROHC): Framework and four profiles: RTP,
 UDP, ESP, and uncompressed" [RFC3095] was published in 2001, as the
 first output of the ROHC WG.  ROHC is a general and extendable
 framework for header compression, on top of which profiles can be
 defined for compression of different protocols headers.  RFC 3095
 introduced a number of new compression techniques, and was successful
 at living up to the requirements placed on it, as described in
 [RFC3096].
 Interoperability testing of RFC 3095 confirms the capabilities of
 ROHC to meet its purposes, but feedback from implementers has also
 indicated that the protocol specification is complex and sometimes
 obscure.  Most importantly, a clear distinction between framework and
 profiles is not obvious in [RFC3095], which also makes development of
 additional profiles troublesome.  This document therefore aims at
 explicitly specifying the ROHC framework, while a companion document
 [RFC5225] specifies revised versions of the compression profiles of
 RFC 3095.

Sandlund, et al. Standards Track [Page 12] RFC 5795 ROHC Framework March 2010

4.4. Operational Characteristics of the ROHC Channel

 Robust header compression can be used over many types of link
 technologies.  The ROHC framework provides flexibility for profiles
 to address a wide range of applications, and this section lists some
 of the operational characteristics of the ROHC channel (see also
 [RFC3759]).
 Multiplexing over a single logical channel
    The ROHC channel provides a mechanism to identify a context within
    the general ROHC packet format.  The CID makes it possible for a
    logical channel that supports ROHC to transport multiple header-
    compressed flows, while still making it possible for a channel to
    be dedicated to one single packet flow without any CID overhead.
    More specifically, ROHC uses a distinct CID space per logical
    channel, and the CID can be omitted for one of the flows over the
    ROHC channel when configured to use a small CID space.
 Establishment of channel parameters
    A link layer defining support for the ROHC channel must provide
    the means to establish header compression channel parameters (see
    Section 5.1).  This can be achieved through a negotiation
    mechanism, static provisioning, or some out-of-band signaling.
 Packet type identification
    The ROHC channel defines a packet type identifier space, and puts
    restrictions with respect to the use of a number of identifiers
    that are common for all ROHC profiles.  Identifiers that have no
    restrictions, i.e., identifiers that are not defined by this
    document, are available to each profile.  The identifier is part
    of each compressed header, and this makes it possible for the link
    that supports the ROHC channel to allocate one single link-layer
    payload type for ROHC.
 Out-of-order delivery between compression endpoints
    Each profile defines its own level of robustness, including
    tolerance to reordering of packets before but especially between
    compression endpoints, if any.
    For profiles specified in [RFC3095], the channel between the
    compressor and decompressor is required to maintain in-order
    delivery of the packets; i.e., the definition of these profiles
    assumes that the decompressor always receives packets in the same
    order as the compressor sent them.  The impacts of reordering on

Sandlund, et al. Standards Track [Page 13] RFC 5795 ROHC Framework March 2010

    the performance of these profiles are described in [RFC4224].
    However, reordering before the compression point is handled, i.e.,
    these profiles make no assumption that the compressor will receive
    packets in order.
    For the ROHCv2 profiles specified in [RFC5225], their definitions
    assume that the decompressor can receive packets out of order,
    i.e., not in the same order that the compressor sent them.
    Reordering before the compression point is also dealt with.
 Duplication of packets
    The link supporting the ROHC channel is required to not duplicate
    packets (however, duplication of packets can occur before they
    reach the compressor; i.e., there is no assumption that the
    compressor will receive only one copy of each packet).
 Framing
    The link layer must provide framing that makes it possible to
    distinguish frame boundaries and individual frames.
 Error detection/protection
    ROHC profiles should be designed to cope with residual errors in
    the headers delivered to the decompressor.  CRCs are used to
    detect decompression failures and to prevent or reduce damage
    propagation.  However, it is recommended that lower layers deploy
    error detection for ROHC headers and that ROHC headers with high
    residual error rates not be delivered.

4.5. Compression and Master Sequence Number (MSN)

 Compression of header fields is based on the establishment of a
 function to a sequence number, called the master sequence number
 (MSN).  This function describes the change pattern of the field with
 respect to a change in the MSN.
 Change patterns include, for example, fields that increase
 monotonically or by a small value, fields that seldom change, and
 fields that remain unchanging for the entire lifetime of the packet
 flow, in which case the function to the MSN is equivalent to a
 constant value.
 The compressor first establishes functions for each of the header
 fields, and then reliably communicates the MSN.  When the change
 pattern of the field does not match the established function, i.e.,

Sandlund, et al. Standards Track [Page 14] RFC 5795 ROHC Framework March 2010

 the existing function gives a result that is different from the field
 in the header being compressed, additional information can be sent to
 update the parameters of that function.
 The MSN is defined per profile.  It can be either derived directly
 from one of the fields of the protocol being compressed (e.g., the
 RTP SN [RFC5225]), or it can be created and maintained by the
 compressor (e.g., the MSN for compression of UDP in profile 0x0102
 [RFC5225] or the MSN in ROHC-TCP [RFC4996]).

4.6. Static and Dynamic Parts of a Context

 A compression context can be conceptually divided into two different
 parts, the static context and the dynamic context, each based on the
 properties of the fields that are being compressed.
 The static part includes the information necessary to compress and
 decompress the fields whose change behavior is classified as STATIC,
 STATIC-KNOWN, or STATIC-DEF (as described in Section 4.1 above).
 The dynamic part includes the state maintained for all the other
 fields, i.e., those that are classified as CHANGING.

5. The ROHC Framework (Normative)

 This section normatively defines the parts common to all ROHC
 profiles, i.e., the framework.  The framework specifies the
 requirements and functionality of the ROHC channel, including how to
 handle multiple compressed packet flows over the same channel.
 Finally, this section specifies encoding methods used in the packet
 formats that are common to all profiles.  These encoding methods may
 be reused within profile specifications for encoding fields in
 profile-specific parts of a packet format, without requiring their
 redefinition.

5.1. The ROHC Channel

5.1.1. Contexts and Context Identifiers

 Associated with each compressed flow is a context.  The context is
 the state that the compressor and the decompressor maintain in order
 to correctly compress or decompress the headers of the packet in the
 flow.  Each context is identified using a CID.

Sandlund, et al. Standards Track [Page 15] RFC 5795 ROHC Framework March 2010

 A context is considered to be a new context when the CID is
 associated with a profile for the first time since the creation of
 the ROHC channel, or when the CID gets associated from the reception
 of an IR (this does not apply to the IR-DYN) with a different profile
 than the profile in the context.
 Context information is conceptually kept in a table.  The context
 table is indexed using the CID, which is sent along with compressed
 headers and feedback information.
 The CID space can be either small, which means that CIDs can take the
 values 0 through 15, or large, which means that CIDs take values
 between 0 and 2^14 - 1 = 16383.  Whether the CID space is large or
 small MUST be established, possibly by negotiation, before any
 compressed packet may be sent over the ROHC channel.
 The CID space is distinct for each channel, i.e., CID 3 over channel
 A and CID 3 over channel B do not refer to the same context, even if
 the endpoints of A and B are the same nodes.  In particular, CIDs for
 any pair of ROHC channels are not related (two associated ROHC
 channels serving as feedback channels for one another do not even
 need to have CID spaces of the same size).

5.1.2. Per-Channel Parameters

 The ROHC channel is based on a number of parameters that form part of
 the established channel state and the per-context state.  The state
 of the ROHC channel MUST be established before the first ROHC packet
 may be sent, which may be achieved using negotiation protocols
 provided by the link layer (see also [RFC3241], which describes an
 option for negotiation of ROHC parameters for PPP).  This section
 describes some of this channel state information in an abstract way:
 LARGE_CIDS: Boolean; if false, the small CID representation (0 octets
 or 1 prefix octet, covering CID 0 to 15) is used; if true, the large
 CID representation (1 or 2 embedded CID octets covering CID 0 to
 16383) is used.  See also Section 5.1.1 and Section 5.2.1.3.
 MAX_CID: Non-negative integer; highest CID number to be used by the
 compressor (note that this parameter is not coupled to, but in effect
 further constrained by, LARGE_CIDS).  This value represents an
 agreement by the decompressor that it can provide sufficient memory
 resources to host at least MAX_CID+1 contexts; the decompressor MUST
 maintain established contexts within this space until either the CID
 gets re-used by the establishment of a new context, or until the
 channel is taken down.

Sandlund, et al. Standards Track [Page 16] RFC 5795 ROHC Framework March 2010

 PROFILES: Set of non-negative integers, where each integer indicates
 a profile supported by both the compressor and the decompressor.  A
 profile is identified by a 16-bit value, where the 8 LSB bits
 indicate the actual profile, and the 8 MSB bits indicate the variant
 of that profile.  The ROHC compressed header format identifies the
 profile used with only the 8 LSB bits; this means that if multiple
 variants of the same profile are available for a ROHC channel, the
 PROFILES set after negotiation MUST NOT include more than one variant
 of the same profile.  The compressor MUST NOT compress using a
 profile that is not in PROFILES.
 FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite
 direction between the same compression endpoints.  If provided, this
 parameter indicates to which other ROHC channel any feedback sent on
 this ROHC channel refers (see [RFC3759]).
 MRRU: Non-negative integer.  Maximum Reconstructed Reception Unit.
 This is the size of the largest reconstructed unit in octets that the
 decompressor is expected to reassemble from segments (see
 Section 5.2.5).  This size includes the segmentation CRC.  If MRRU is
 negotiated to be 0, segmentation MUST NOT be used on the channel, and
 received segments MUST be discarded by the decompressor.

5.1.3. Persistence of Decompressor Contexts

 As part of the negotiated channel parameters, the compressor and
 decompressor have through the MAX_CID parameter agreed on the highest
 context identification (CID) number to be used.  By agreeing on the
 MAX_CID, the decompressor also agrees to provide memory resources to
 host at least MAX_CID+1 contexts, and an established context with a
 CID within this negotiated space SHOULD be kept by the decompressor
 until either the CID gets re-used, or the channel is taken down or
 re-negotiated.

5.2. ROHC Packets and Packet Types

 This section uses the following convention in the diagrams when
 representing various ROHC packet types, formats, and fields:
  1. colons ":" indicate that the part is optional
  2. slashes "/" indicate variable length
 The ROHC packet type indication scheme has been designed to provide
 optional padding, a feedback packet type, an optional Add-CID octet
 (which includes 4 bits of CID), and a simple segmentation and
 reassembly mechanism.

Sandlund, et al. Standards Track [Page 17] RFC 5795 ROHC Framework March 2010

 The following packet types are reserved at the ROHC framework level:
       11100000 : Padding
       1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through 0xF)
       11110    : Feedback
       11111000 : IR-DYN packet
       1111110  : IR packet
       1111111  : Segment
 Other packet types can be defined and used by individual profiles:
       0        : available (not reserved by ROHC framework)
       10       : available (not reserved by ROHC framework)
       110      : available (not reserved by ROHC framework)
       1111101  : available (not reserved by ROHC framework)
       11111001 : available (not reserved by ROHC framework)

5.2.1. General Format of ROHC Packets

 A ROHC packet has the following general format:
  1. – — — — — — — —

: Padding :

  1. – — — — — — — —

: Feedback :

  1. – — — — — — — —

: Header :

  1. – — — — — — — —

: Payload :

  1. – — — — — — — —
 Padding: Any number (zero or more) of padding octets, where the
 format of a padding octet is as defined in Section 5.2.1.1.
 Feedback: Any number (zero or more) of feedback elements, where the
 format of a feedback element is as defined in Section 5.2.4.1.
 Header: Either a profile-specific CO header (see Section 5.2.1.3), an
 IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see
 Section 5.2.5).  There can be at most one Header in a ROHC packet,
 but it may also be omitted (if the packet contains Feedback only).
 Payload: Corresponds to zero or more octets of payload from the
 uncompressed packet, starting with the first octet in the
 uncompressed packet after the last header compressible by the current
 profile.
 At least one of Feedback or Header MUST be present.

Sandlund, et al. Standards Track [Page 18] RFC 5795 ROHC Framework March 2010

5.2.1.1. Format of the Padding Octet

 Padding octet:
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   1   1   0   0   0   0   0 |
    +---+---+---+---+---+---+---+---+
 Note: The Padding octet MUST NOT be interpreted as an Add-CID octet
 for CID 0.

5.2.1.2. Format of the Add-CID Octet

 Add-CID octet:
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   1   1   0 |      CID      |
    +---+---+---+---+---+---+---+---+
 CID: 0x1 through 0xF indicates CIDs 1 through 15.
 Note: The Padding octet looks like an Add-CID octet for CID 0.

5.2.1.3. General Format of Header

 All ROHC packet types have the following general Header format:
      0              x-1  x       7
     --- --- --- --- --- --- --- ---
    :         Add-CID octet         :  if CID 1-15 and small CIDs
    +--- --- --- --- ---+--- --- ---+
    | type indication   |   body    |  1 octet (8-x bits of body)
    +--- --- --- --- ---+--- --- ---+
    :                               :
    /    0, 1, or 2 octets of CID   /  1 or 2 octets if large CIDs
    :                               :
    +---+---+---+---+---+---+---+---+
    /             body              /  variable length
    +---+---+---+---+---+---+---+---+
 type indication: ROHC packet type.
 body: Interpreted according to the packet type indication and CID
 information, as defined by individual profiles.

Sandlund, et al. Standards Track [Page 19] RFC 5795 ROHC Framework March 2010

 Thus, the header either starts with a packet type indication or has a
 packet type indication immediately following an Add-CID octet.
 When the ROHC channel is configured with a small CID space:
 o   If an Add-CID immediately precedes the packet type indication,
     the packet has the CID of the Add-CID; otherwise, it has CID 0.
 o   A small CID with the value 0 is represented using zero bits;
     therefore, a flow associated with CID 0 has no CID overhead in
     the compressed header.  In such case, Header starts with a packet
     type indication.
 o   A small CID with a value from 1 to 15 is represented using the
     Add-CID octet as described above.  The Header starts with the
     Add-CID octet, followed by a packet type indication.
 o   There is no large CID in the Header.
 When the ROHC channel is configured with a large CID space:
 o   The large CID is always present and is represented using the
     encoding scheme of Section 5.3.2, limited to two octets.  In this
     case, the Header starts with a packet type indication.

5.2.2. Initialization and Refresh (IR) Packet Types

 IR packet types contain a profile identifier, which determines how
 the rest of the header is to be interpreted.  They also associate a
 profile with a context.  The stored profile parameter further
 determines the syntax and semantics of the packet type identifiers
 and packet types used with a specific context.
 The IR and IR-DYN packets always update the context for all context-
 updating fields carried in the header.  They never clear the context,
 except when initializing a new context (see Section 5.1.1), or unless
 the profile indicated in the Profile field specifies otherwise.

5.2.2.1. ROHC IR Header Format

 The IR header associates a CID with a profile, and typically also
 initializes the context.  It can typically also refresh all (or parts
 of) the context.  For IR, Header has the following general format:

Sandlund, et al. Standards Track [Page 20] RFC 5795 ROHC Framework March 2010

      0   1   2   3   4   5   6   7
     --- --- --- --- --- --- --- ---
    :         Add-CID octet         :  if CID 1-15 and small CID
    +---+---+---+---+---+---+---+---+
    | 1   1   1   1   1   1   0 | x |  IR type octet
    +---+---+---+---+---+---+---+---+
    :                               :
    /      0-2 octets of CID        /  1 or 2 octets if large CIDs
    :                               :
    +---+---+---+---+---+---+---+---+
    |            Profile            |  1 octet
    +---+---+---+---+---+---+---+---+
    |              CRC              |  1 octet
    +---+---+---+---+---+---+---+---+
    |                               |
    / profile-specific information  /  variable length
    |                               |
    +---+---+---+---+---+---+---+---+
 x: Profile-specific information.  Interpreted according to the
 profile indicated in the Profile field of the IR header.
 Profile: The profile associated with the CID.  In the IR header, the
 profile identifier is abbreviated to the 8 least significant bits
 (see Section 5.1.2).
 CRC: 8-bit CRC (see Section 5.3.1.1).
 Profile-specific information: The content of this part of the IR
 header is defined by the individual profiles.  It is interpreted
 according to the profile indicated in the Profile field.

5.2.2.2. ROHC IR-DYN Header Format

 In contrast to the IR header, the IR-DYN header can never initialize
 a non-initialized context.  However, it can redefine what profile is
 associated with a context, if the profile indicated in the IR-DYN
 header allows this.  Thus, this packet type is also reserved at the
 framework level.  The IR-DYN header typically also initializes or
 refreshes parts of a context.  For IR-DYN, Header has the following
 general format:

Sandlund, et al. Standards Track [Page 21] RFC 5795 ROHC Framework March 2010

      0   1   2   3   4   5   6   7
     --- --- --- --- --- --- --- ---
    :         Add-CID octet         :  if CID 1-15 and small CID
    +---+---+---+---+---+---+---+---+
    | 1   1   1   1   1   0   0   0 |  IR-DYN type octet
    +---+---+---+---+---+---+---+---+
    :                               :
    /      0-2 octets of CID        /  1 or 2 octets if large CIDs
    :                               :
    +---+---+---+---+---+---+---+---+
    |            Profile            |  1 octet
    +---+---+---+---+---+---+---+---+
    |              CRC              |  1 octet
    +---+---+---+---+---+---+---+---+
    |                               |
    / profile-specific information  /  variable length
    |                               |
    +---+---+---+---+---+---+---+---+
 Profile: The profile associated with the CID.  This is abbreviated in
 the same way as in IR packets.
 CRC: 8-bit CRC (see Section 5.3.1.1).
 Profile-specific information: The content of this part of the IR-DYN
 header is defined by the individual profiles.  It is interpreted
 according to the profile indicated in the Profile field.

5.2.3. ROHC Initial Decompressor Processing

 Initially, all contexts are in no context state.  Thus, all packets
 referencing a non-initialized context, except packets that have
 enough information on the static fields, cannot be decompressed by
 the decompressor.
 When the decompressor receives a packet of type IR, the profile
 indicated in the IR packet determines how it is to be processed.
 o  If the 8-bit CRC fails to verify the integrity of the header, the
    packet MUST NOT be decompressed and delivered to upper layers.  If
    a profile is indicated in the context, the logic of that profile
    determines what, if any, feedback is to be sent.  If no profile is
    noted in the context, the logic used to determine what, if any,
    feedback to send is up to the implementation.  However, it may be
    suitable to take no further actions, as any part of the IR header
    covered by the CRC may have caused the failure.

Sandlund, et al. Standards Track [Page 22] RFC 5795 ROHC Framework March 2010

 When the decompressor receives a packet of type IR-DYN, the profile
 indicated in the IR-DYN packet determines how it is to be processed.
 o  If the 8-bit CRC fails to verify the integrity of the header, the
    packet MUST NOT be decompressed and delivered to upper layers.  If
    a profile is indicated in the context, the logic of that profile
    determines what, if any, feedback is to be sent.  If no profile is
    noted in the context, the logic used to determine what, if any,
    feedback to send is up to the implementation.  However, it may be
    suitable to take no further actions, as any part of the IR-DYN
    header covered by the CRC may have caused the failure.
 o  If the context has not already been initialized, the packet MUST
    NOT be decompressed and delivered to upper layers.  The logic of
    the profile indicated in the IR-DYN header (if verified by the
    8-bit CRC), determines what, if any, feedback is to be sent.
 If a parsing error occurs for any packet type, the decompressor MUST
 discard the packet without further processing.  For example, a CID
 field is present in the compressed header when the large CID space is
 used for the ROHC channel, and the field is coded using the self-
 describing variable-length encoding of Section 5.3.2; if the field
 starts with 110 or 111, this would generate a parsing error for the
 decompressor because this field must not be encoded with a size
 larger than 2 octets.
 It is RECOMMENDED that profiles disallow the decompressor to make a
 decompression attempt for packets carrying only a 3-bit CRC after it
 has invalidated some or all of the entire dynamic context, until a
 packet that contains sufficient information on the dynamic fields is
 received, decompressed, and successfully verified by a 7- or 8-bit
 CRC.

5.2.4. ROHC Feedback

 Feedback carries information from the decompressor to the compressor.
 Feedback can be sent over a ROHC channel that operates in the same
 direction as the feedback.
 The general ROHC packet format allows transport of feedback using
 interspersion or piggybacking (see [RFC3759]), or a combination of
 both, over a ROHC channel.  This is facilitated by the following
 properties:
 Reserved packet type:
    A feedback packet type is reserved at the framework level.  The
    packet type can carry variable-length feedback information.

Sandlund, et al. Standards Track [Page 23] RFC 5795 ROHC Framework March 2010

 CID information:
    The feedback information sent on a particular channel is passed
    to, and interpreted by, the compressor associated with feedback on
    that channel.  Thus, each feedback element contains CID
    information from the channel for which the feedback is sent.  The
    ROHC feedback scheme thus requires that a channel carries feedback
    to at most one compressor.  How a compressor is associated with
    the feedback for a particular channel is outside the scope of this
    specification.  See also [RFC3759].
 Length information:
    The length of a feedback element can be determined by examining
    the first few octets of the feedback.  This enables piggybacking
    of feedback, and also the concatenation of more than one feedback
    element in a packet.  The length information thus decouples the
    decompressor from the associated same-side compressor, as the
    decompressor can extract the feedback information from the
    compressed header without parsing its content and hand over the
    extracted information.
 The association between compressor-decompressor pairs operating in
 opposite directions, for the purpose of exchanging piggyback and/or
 interspersed feedback, SHOULD be maintained for the lifetime of the
 ROHC channel.  Otherwise, it is RECOMMENDED that the compressor be
 notified if the feedback channel is no longer available: the
 compressor SHOULD then restart compression by creating a new context
 for each packet flow, and SHOULD use a CID value that was not
 previously associated with the profile used to compress the flow.

5.2.4.1. ROHC Feedback Format

 ROHC defines three different categories of feedback messages:
 acknowledgment (ACK), negative ACK (NACK), and NACK for the entire
 context (STATIC-NACK).  Other types of information may be defined in
 profile-specific feedback information.
    ACK: Acknowledges successful decompression of a packet.  Indicates
    that the decompressor considers its context to be valid.
    NACK: Indicates that the decompressor considers some or all of the
    dynamic part of its context invalid.
    STATIC-NACK : Indicates that the decompressor considers its entire
    static context invalid, or that it has not been established.

Sandlund, et al. Standards Track [Page 24] RFC 5795 ROHC Framework March 2010

 Feedback sent on a ROHC channel consists of one or more concatenated
 feedback elements, where each feedback element has the following
 format:
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 |   Code    |  feedback type
   +---+---+---+---+---+---+---+---+
   :             Size              :  if Code = 0
   +---+---+---+---+---+---+---+---+
   :         Add-CID octet         :  if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   :                               :
   /           large CID           /  1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   /         FEEDBACK data         /  variable length
   +---+---+---+---+---+---+---+---+
 Code:
    0 indicates that a Size octet is present.
    1-7 indicates the total size of the FEEDBACK data field and the
    CID field (if any), in octets.
 Size: Indicates the total size of the FEEDBACK data field and the CID
 field (if any), in octets.
 FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).
 CID information in a feedback element indicates the context for which
 feedback is sent.  The LARGE_CIDS parameter that controls whether a
 large CID is present is taken from the channel state of the receiving
 compressor's channel, not from the state of the channel carrying the
 feedback.
 The large CID field, if present, is encoded according to
 Section 5.3.2, and it MUST NOT be encoded using more than 2 octets.
 The FEEDBACK data field can have either of the following two formats:
 FEEDBACK-1:
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | profile-specific information  |  1 octet
    +---+---+---+---+---+---+---+---+

Sandlund, et al. Standards Track [Page 25] RFC 5795 ROHC Framework March 2010

 FEEDBACK-2:
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    |Acktype|                       |
    +---+---+   profile-specific    /  at least 2 octets
    /             information       |
    +---+---+---+---+---+---+---+---+
    Acktype:  0 = ACK
              1 = NACK
              2 = STATIC-NACK
              3 is reserved (MUST NOT be used.  Otherwise unparsable.)

5.2.5. ROHC Segmentation

 ROHC defines a simple segmentation protocol.  The compressor may
 perform segmentation, e.g., to accommodate packets that are larger
 than a specific size configured for the channel.

5.2.5.1. Segmentation Usage Considerations

 The ROHC segmentation protocol is not particularly efficient.  It is
 not intended to replace link-layer segmentation functions; these
 SHOULD be used whenever available and efficient for the task at hand.
 The ROHC segmentation protocol has been designed with an assumption
 of in-order delivery of packets between the compressor and the
 decompressor, using only a CRC for error detection, and no sequence
 numbers.  If in-order delivery cannot be guaranteed, ROHC
 segmentation MUST NOT be used.
 The segmentation protocol also assumes that all segments of a ROHC
 packet corresponding to one context are received without interference
 from other ROHC packets over the channel, including any ROHC packet
 corresponding to a different context.  Based on this assumption,
 segments do not carry CID information, and therefore cannot be
 associated with a specific context until all segments have been
 received and the whole unit has been reconstructed.

5.2.5.2. Segmentation Protocol

 ROHC segmentation is applied to the combination of the Header and the
 Payload fields of the ROHC packet, as defined in Section 5.2.1.

Sandlund, et al. Standards Track [Page 26] RFC 5795 ROHC Framework March 2010

 Segment format:
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   1   1   1   1   1   1 | F |  segment type
    +---+---+---+---+---+---+---+---+
    /           Segment             /  variable length
    +---+---+---+---+---+---+---+---+
 F: Final bit.  If set, it indicates that this is the last segment of
 a reconstructed unit.
 Padding and/or Feedback may precede the segment type octet.  There is
 no per-segment CID, but CID information is of course part of the
 reconstructed unit.  The reconstructed unit MUST NOT contain padding,
 segments, or feedback.
 When a final segment is received, the decompressor reassembles the
 segment carried in this packet and any non-final segments that
 immediately preceded it into a single reconstructed unit, in the
 order they were received.  All segments for one reconstructed unit
 have to be received consecutively and in the correct order by the
 decompressor.  If a non-segment ROHC packet directly follows a non-
 final segment, the reassembly of the current reconstructed unit is
 aborted and the decompressor MUST discard the non-final segments so
 far received on this channel.
 Reconstructed unit:
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    /            Header             /
    +---+---+---+---+---+---+---+---+
    :            Payload            :
    +---+---+---+---+---+---+---+---+
    /              CRC              /  4 octets
    +---+---+---+---+---+---+---+---+
 Header: See Section 5.2.1
 Payload: See Section 5.2.1
 CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4

Sandlund, et al. Standards Track [Page 27] RFC 5795 ROHC Framework March 2010

 If the reconstructed unit is 4 octets or less, or if the CRC fails,
 or if it is larger than the channel parameter MRRU (see
 Section 5.1.2), the reconstructed unit MUST be discarded by the
 decompressor.  If the CRC succeeds, the reconstructed unit can be
 further processed.

5.3. General Encoding Methods

5.3.1. Header Compression CRCs, Coverage, and Polynomials

 This section describes how to calculate the CRCs used by ROHC.  For
 all CRCs, the algorithm used to calculate the CRC is the same as the
 one used in [RFC1662], defined in Appendix A of this document, with
 the polynomials specified in subsequent sections.

5.3.1.1. 8-bit CRC in IR and IR-DYN Headers

 The coverage for the 8-bit CRC in the IR and IR-DYN headers is
 profile-dependent, but it MUST cover at least the initial part of the
 header ending with the Profile field, including the CID or an Add-CID
 octet.  Feedback and padding are not part of Header (Section 5.2.1)
 and are thus not included in the CRC calculation.  As a rule of thumb
 for profile specifications, any other information that initializes
 the decompressor context SHOULD also be covered by a CRC.
 More specifically, the 8-bit CRC does not cover only and entirely the
 original uncompressed header; therefore, it does not provide the
 means for the decompressor to verify a decompression attempt, or the
 means to verify the correctness of the entire decompressor context.
 However, when successful, it does provide enough robustness for the
 decompressor to update its context with the information carried
 within the IR or the IR-DYN header.
 The CRC polynomial for the 8-bit CRC is:
       C(x) = 1 + x + x^2 + x^8
 When computing the CRC, the CRC field in the header is set to zero,
 and the initial content of the CRC register is set to all 1's.

5.3.1.2. 3-bit CRC in Compressed Headers

 The 3-bit CRC in compressed headers is calculated over all octets of
 the entire original header, before compression, in the following
 manner.
 The initial content of the CRC register is set to all 1's.

Sandlund, et al. Standards Track [Page 28] RFC 5795 ROHC Framework March 2010

 The polynomial for the 3-bit CRC is:
       C(x) = 1 + x + x^3
 The purpose of the 3-bit CRC is to provide the means for the
 decompressor to verify the outcome of a decompression attempt for
 small compressed headers, and to detect context damage based on
 aggregated probability over a number of decompression attempts.
 However, it is too weak to provide enough success guarantees from the
 decompression of one single header.  Therefore, compressed headers
 carrying a 3-bit CRC are normally not suitable to perform context
 repairs at the decompressor; hence, profiles should refrain from
 allowing decompression of such a header when some or the entire
 decompressor context is assumed invalid.

5.3.1.3. 7-bit CRC in Compressed Headers

 The 7-bit CRC in compressed headers is calculated over all octets of
 the entire original header, before compression, in the following
 manner.
 The initial content of the CRC register is set to all 1's.
 The polynomial for the 7-bit CRC is:
       C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
 The purpose of the 7-bit CRC is to provide the means for the
 decompressor to verify the outcome of a decompression attempt for a
 larger compressed header, and to provide enough protection to
 validate a context repair at the decompressor.  The 7-bit CRC is
 strong enough to assume a repair to be successful from the
 decompression of one single header; hence, profiles may allow
 decompression of a header carrying a 7-bit CRC when some of the
 decompressor context is assumed invalid.

5.3.1.4. 32-bit Segmentation CRC

 The 32-bit CRC is used by the segmentation scheme to verify the
 reconstructed unit, and it is thus calculated over the segmented
 unit, i.e., over the Header and the Payload fields of the ROHC
 packet.
 The initial content of the CRC register is set to all 1's.

Sandlund, et al. Standards Track [Page 29] RFC 5795 ROHC Framework March 2010

 The polynomial for the 32-bit CRC is:
       C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
              x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
 The purpose of the 32-bit CRC is to verify the reconstructed unit.

5.3.2. Self-Describing Variable-Length Values

 The values of many fields and compression parameters can vary widely.
 To optimize the transfer of such values, a variable number of octets
 are used to encode them.  The first few bits of the first octet
 determine the number of octets used:
    First bit is 0: 1 octet.
             7 bits transferred.
             Up to 127 decimal.
             Encoded octets in hexadecimal: 00 to 7F
    First bits are 10: 2 octets.
             14 bits transferred.
             Up to 16 383 decimal.
             Encoded octets in hexadecimal: 80 00 to BF FF
    First bits are 110: 3 octets.
             21 bits transferred.
             Up to 2 097 151 decimal.
             Encoded octets in hexadecimal: C0 00 00 to DF FF FF
    First bits are 111: 4 octets.
             29 bits transferred.
             Up to 536 870 911 decimal.
             Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF

5.4. ROHC UNCOMPRESSED – No Compression (Profile 0x0000)

 This section describes the uncompressed ROHC profile.  The profile
 identifier for this profile is 0x0000.
 Profile 0x0000 provides a way to send IP packets without compressing
 them.  This can be used for any packet for which a compression
 profile is not available in the set of profiles supported by the ROHC
 channel, or for which compression is not desirable for some reason.

Sandlund, et al. Standards Track [Page 30] RFC 5795 ROHC Framework March 2010

 After initialization, the only overhead for sending packets using
 Profile 0x0000 is the size of the CID.  When uncompressed packets are
 frequent, Profile 0x0000 should be associated with a CID the size of
 zero or one octet.  Profile 0x0000 SHOULD be associated with at most
 one CID.

5.4.1. IR Packet

 The initialization and refresh packet (IR packet) for Profile 0x0000
 has the following Header format:
      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 |res|
    +---+---+---+---+---+---+---+---+
    :                               :
    /    0-2 octets of CID info     / 1-2 octets if for large CIDs
    :                               :
    +---+---+---+---+---+---+---+---+
    |         Profile = 0x00        | 1 octet
    +---+---+---+---+---+---+---+---+
    |              CRC              | 1 octet
    +---+---+---+---+---+---+---+---+
 res: MUST be set to zero; otherwise, the decompressor MUST discard
 the packet.
 Profile: 0x00
 CRC: 8-bit CRC, computed using the polynomial of Section 5.3.1.1.
 The CRC covers the first octet of the IR Header through the Profile
 octet of the IR Header, i.e., it does not cover the CRC itself.
 Neither does it cover any preceding Padding or Feedback, nor the
 Payload.
 For the IR packet, Payload has the following format:
  1. – — — — — — — —

: : (optional)

    /           IP packet           / variable length
    :                               :
     --- --- --- --- --- --- --- ---
 IP packet: An uncompressed IP packet may be included in the IR
 packet.  The decompressor determines if the IP packet is present by
 considering the length of the IR packet.

Sandlund, et al. Standards Track [Page 31] RFC 5795 ROHC Framework March 2010

5.4.2. Normal Packet

 A Normal packet is a normal IP packet plus CID information.  For the
 Normal Packet, the following format corresponds to the Header and
 Payload (as defined in Section 5.2.1):
      0   1   2   3   4   5   6   7
     --- --- --- --- --- --- --- ---
    :         Add-CID octet         : if for small CIDs and (CID != 0)
    +---+---+---+---+---+---+---+---+
    |   first octet of IP packet    |
    +---+---+---+---+---+---+---+---+
    :                               :
    /    0-2 octets of CID info     / 1-2 octets if for large CIDs
    :                               :
    +---+---+---+---+---+---+---+---+
    |                               |
    /       rest of IP packet       / variable length
    |                               |
    +---+---+---+---+---+---+---+---+
 Note that the first octet of the IP packet starts with the bit
 pattern 0100 (IPv4) or 0110 (IPv6).  This does not conflict with any
 reserved packet types.
 When the channel uses small CIDs, and profile 0x0000 is associated
 with a CID > 0, an Add-CID octet precedes the IP packet.  When the
 channel uses large CIDs, the CID is placed so that it starts at the
 second octet of the combined Header/Payload format above.
 A Normal Packet may carry Padding and/or Feedback as any other ROHC
 packet, preceding the combined Header/Payload.

5.4.3. Context Initialization

 The compressor initializes the static context associated with the
 UNCOMPRESSED profile by sending IR packets (see Section 5.4.1).
 During context initialization, it is RECOMMENDED that the compressor
 sends IR packets until it is reasonably confident that the
 decompressor has successfully received at least one IR packet.  For
 example, this confidence can be based on feedback from the
 decompressor, or on knowledge of the characteristics of the link.
 The compressor SHOULD periodically transmit IR packets for a context
 associated with the UNCOMPRESSED profile, at least until it receives
 feedback from the decompressor for that context.  The compressor MAY
 stop the periodic sending of IR packets once it has received
 feedback.

Sandlund, et al. Standards Track [Page 32] RFC 5795 ROHC Framework March 2010

5.4.4. Decompressor Operation

 When an IR packet is received, the decompressor first validates its
 header using the 8-bit CRC.
 o   If the header fails validation, the decompressor MUST NOT deliver
     the IP packet to upper layers.
 o   If the header is successfully validated, the decompressor
     1.  initializes the context if it has no valid context for the
         given CID already associated to the specified profile,
     2.  delivers the IP packet to upper layers if present,
     3.  MAY send an ACK.
 When any other packet is received while the decompressor has no
 context, it is discarded without further action.
 When a Normal packet is received and the decompressor has a valid
 context, the IP packet is extracted and delivered to upper layers.

5.4.5. Feedback

 The only kind of feedback defined by Profile 0x0000 is ACK, using the
 FEEDBACK-1 format of Section 5.2.4.1, where the value of the profile-
 specific octet in the FEEDBACK-1 is 0 (zero).  The FEEDBACK-2 format
 is thus not defined for Profile 0x0000.

6. Overview of a ROHC Profile (Informative)

 The ROHC protocol consists of a framework part and a profile part.
 The framework defines the mechanisms common to all profiles, while
 the profile defines the compression algorithm and profile-specific
 packet formats.
 Section 5 specifies the details of the ROHC framework.  This section
 provides an informative overview of the elements that make a profile
 specification.  The normative specification of individual profiles is
 outside the scope of this document.
 A ROHC profile defines the elements that build up the compression
 protocol.  A ROHC profile consists of:

Sandlund, et al. Standards Track [Page 33] RFC 5795 ROHC Framework March 2010

 Packet formats:
 o  Bits-on-the-wire
       The profile defines the layout of the bits for profile-specific
       packet types that it defines, and for the profile-specific
       parts of packet types common to all profiles (e.g., IR and IR-
       DYN).
 o  Field encodings
       Bits and groups of bits from the packet format layout, referred
       to as Compressed fields, represent the result of an encoding
       method specific for that compressed field within a specific
       packet format.  The profile defines these encoding methods.
 o  Updating properties
       The profile-specific packet formats may update the state of the
       decompressor, and may do so in different ways.  The profile
       defines how individual profile-specific fields, or entire
       profile-specific packet types, update the decompressor context.
 o  Verification
       Packets that update the state of the decompressor are verified
       to prevent incorrect updates to the decompressor context.  The
       profile defines the mechanisms used to verify the decompression
       of a packet.
 Context management:
 o  Robustness logic
       Packets may be lost or reordered between the compressor and the
       decompressor.  The profile defines mechanisms to minimize the
       impacts of such events and prevent damage propagation.
 o  Repair mechanism
       Despite the robustness logic, impairment events may still lead
       to decompression failure(s), and even to context damage at the
       decompressor.  The profile defines context repair mechanisms,
       including feedback logic if used.

Sandlund, et al. Standards Track [Page 34] RFC 5795 ROHC Framework March 2010

7. Acknowledgments

 The authors would like to acknowledge all who have contributed to
 previous ROHC work, and especially to the authors of RFC 3095
 [RFC3095], which is the technical basis for this document.  Thanks
 also to the various individuals who contributed to the RFC 3095
 corrections and clarifications document [RFC4815], from which
 technical contents, when applicable, have been incorporated into this
 document.  Thanks to Jani Juvan for discovering an inconsistency
 between the feedback structure described in [RFC4995] and the one
 described in [RFC3095], which made this update to [RFC4995]
 necessary.
 Committed WG document reviewers were Carl Knutsson, Biplab Sarkar,
 and Robert Stangarone, who reviewed the document during working group
 last calls.  Additional thanks to Bert Wijnen and Brian Carpenter for
 comments during IETF Last Call.

8. IANA Considerations

 An IANA registry for "RObust Header Compression (ROHC) Profile
 Identifiers" [ROHC-ids] was created by RFC 3095 [RFC3095].  The
 assignment policy, as outlined by RFC 3095, is the following:
 The ROHC profile identifier is a non-negative integer.  In many
 negotiation protocols, it will be represented as a 16-bit value.  Due
 to the way the profile identifier is abbreviated in ROHC packets, the
 8 LSBs of the profile identifier have a special significance: Two
 profile identifiers with identical 8 LSBs should be assigned only if
 the higher-numbered one is intended to supersede the lower-numbered
 one.  To highlight this relationship, profile identifiers should be
 given in hexadecimal (for example, as in 0x1234, which would
 supersede 0x0A34).
 Following the policies outlined in [RFC5226], the IANA policy for
 assigning new values for the profile identifier is Specification
 Required: values and their meanings must be documented in an RFC or
 in some other permanent and readily available reference, in
 sufficient detail that interoperability between independent
 implementations is possible.  In the 8 LSBs, the range 0 to 127 is
 reserved for IETF standard-track specifications; the range 128 to 254
 is available for other specifications that meet this requirement
 (such as Informational RFCs).  The LSB value 255 is reserved for
 future extensibility of the present specification.

Sandlund, et al. Standards Track [Page 35] RFC 5795 ROHC Framework March 2010

 The following profile identifiers have so far been allocated:
    Profile Identifier    Usage                      Reference
    ------------------    ----------------------     ---------
    0x0000                ROHC uncompressed          RFC 5795
    0x0001                ROHC RTP                   RFC 3095
    0x0002                ROHC UDP                   RFC 3095
    0x0003                ROHC ESP                   RFC 3095
    0x0004                ROHC IP                    RFC 3843
    0x0005                ROHC LLA                   RFC 3242
    0x0105                ROHC LLA with R-mode       RFC 3408
    0x0006                ROHC TCP                   RFC 4996
    0x0007                ROHC RTP/UDP-Lite          RFC 4019
    0x0008                ROHC UDP-Lite              RFC 4019
    0x0101                ROHCv2 RTP                 RFC 5225
    0x0102                ROHCv2 UDP                 RFC 5225
    0x0103                ROHCv2 ESP                 RFC 5225
    0x0104                ROHCv2 IP                  RFC 5225
    0x0107                ROHCv2 RTP/UDP-Lite        RFC 5225
    0x0108                ROHCv2 UDP-Lite            RFC 5225
 New profiles will need new identifiers to be assigned by the IANA,
 but this document does not require any additional IANA action.

9. Security Considerations

 Because encryption eliminates the redundancy that header compression
 schemes try to exploit, there is some inducement to forego encryption
 of headers in order to enable operation over low-bandwidth links.
 A malfunctioning or malicious header compressor could cause the
 header decompressor to reconstitute packets that do not match the
 original packets but still have valid headers and possibly also valid
 transport checksums.  Such corruption may be detected with end-to-end
 authentication and integrity mechanisms, which will not be affected
 by the compression.  Moreover, the ROHC header compression scheme
 uses an internal checksum for verification of reconstructed headers,
 which reduces the probability of producing decompressed headers not
 matching the original ones without this being noticed.
 Denial-of-service attacks are possible if an intruder can introduce,
 for example, bogus IR, IR-DYN, or feedback packets onto the link and
 thereby cause compression efficiency to be reduced.  However, an
 intruder having the ability to inject arbitrary packets at the link
 layer in this manner raises additional security issues that dwarf
 those related to the use of header compression.

Sandlund, et al. Standards Track [Page 36] RFC 5795 ROHC Framework March 2010

10. References

10.1. Normative References

 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

 [CRTP-eval]  Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
              ""Evaluation of CRTP Performance over Cellular Radio
              Networks", IEEE Personal Communication Magazine, Volume
              7, number 4, pp. 20-25, August 2000.", 2000.
 [RFC0768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.
 [RFC0791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.
 [RFC0793]    Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.
 [RFC1144]    Jacobson, V., "Compressing TCP/IP headers for low-speed
              serial links", RFC 1144, February 1990.
 [RFC1662]    Simpson, W., "PPP in HDLC-like Framing", STD 51,
              RFC 1662, July 1994.
 [RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.
 [RFC2507]    Degermark, M., Nordgren, B., and S. Pink, "IP Header
              Compression", RFC 2507, February 1999.
 [RFC2508]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              February 1999.
 [RFC3095]    Bormann, C., Burmeister, C., Degermark, M., Fukushima,
              H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
              Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
              K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
              Header Compression (ROHC): Framework and four profiles:
              RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
 [RFC3096]    Degermark, M., "Requirements for robust IP/UDP/RTP
              header compression", RFC 3096, July 2001.

Sandlund, et al. Standards Track [Page 37] RFC 5795 ROHC Framework March 2010

 [RFC3241]    Bormann, C., "Robust Header Compression (ROHC) over
              PPP", RFC 3241, April 2002.
 [RFC3545]    Koren, T., Casner, S., Geevarghese, J., Thompson, B.,
              and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links
              with High Delay, Packet Loss and Reordering", RFC 3545,
              July 2003.
 [RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.
 [RFC3759]    Jonsson, L-E., "RObust Header Compression (ROHC):
              Terminology and Channel Mapping Examples", RFC 3759,
              April 2004.
 [RFC4224]    Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
              Header Compression (ROHC): ROHC over Channels That Can
              Reorder Packets", RFC 4224, January 2006.
 [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.
 [RFC4995]    Jonsson, L-E., Pelletier, G., and K. Sandlund, "The
              RObust Header Compression (ROHC) Framework", RFC 4995,
              July 2007.
 [RFC4996]    Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
              "RObust Header Compression (ROHC): A Profile for TCP/IP
              (ROHC-TCP)", RFC 4996, July 2007.
 [RFC5225]    Pelletier, G. and K. Sandlund, "RObust Header
              Compression Version 2 (ROHCv2): Profiles for RTP, UDP,
              IP, ESP and UDP-Lite", RFC 5225, April 2008.
 [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.
 [ROHC-ids]   IANA, "RObust Header Compression (ROHC) Profile
              Identifiers", <http://www.iana.org>.

Sandlund, et al. Standards Track [Page 38] RFC 5795 ROHC Framework March 2010

Appendix A. CRC Algorithm

   #!/usr/bin/perl -w
 use strict;
 #=================================
 #
 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
 #
 # This little demo shows the four types of CRC in use in RFC 3095,
 # the specification for robust header compression.  Type your data in
 # hexadecimal form and then press Control+D.
 #
 #---------------------------------
 #
 # utility
 #
 sub dump_bytes($) {
     my $x = shift;
     my $i;
     for ($i = 0; $i < length($x); ) {
   printf("%02x ", ord(substr($x, $i, 1)));
   printf("\n") if (++$i % 16 == 0);
     }
     printf("\n") if ($i % 16 != 0);
 }
 #---------------------------------
 #
 # The CRC calculation algorithm.
 #
 sub do_crc($$$) {
     my $nbits = shift;
     my $poly = shift;
     my $string = shift;
     my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
     for (my $i = 0; $i < length($string); ++$i) {
       my $byte = ord(substr($string, $i, 1));
       for( my $b = 0; $b < 8; $b++ ) {
         if (($crc & 1) ^ ($byte & 1)) {
           $crc >>= 1;
           $crc ^= $poly;
         } else {
         $crc >>= 1;
         }
         $byte >>= 1;
       }
     }

Sandlund, et al. Standards Track [Page 39] RFC 5795 ROHC Framework March 2010

     printf "%2d bits, ", $nbits;
     printf "CRC: %02x\n", $crc;
 }
 #---------------------------------
 #
 # Test harness
 #
 $/ = undef;
 $_ = <>;         # read until EOF
 my $string = ""; # extract all that looks hex:
 s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
 dump_bytes($string);
 #---------------------------------
 #
 # 32-bit segmentation CRC
 # Note that the text implies this is complemented like for PPP
 # (this differs from 8, 7, and 3-bit CRC)
 #
 #      C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
 #             x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
 #
 do_crc(32, 0xedb88320, $string);
 #---------------------------------
 #
 # 8-bit IR/IR-DYN CRC
 #
 #      C(x) = x^0 + x^1 + x^2 + x^8
 #
 do_crc(8, 0xe0, $string);
 #---------------------------------
 #
 # 7-bit FO/SO CRC
 #
 #      C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
 #
 do_crc(7, 0x79, $string);
 #---------------------------------
 #
 # 3-bit FO/SO CRC
 #
 #      C(x) = x^0 + x^1 + x^3
 #
 do_crc(3, 0x6, $string);

Sandlund, et al. Standards Track [Page 40] RFC 5795 ROHC Framework March 2010

Authors' Addresses

 Kristofer Sandlund
 Ericsson
 Box 920
 Lulea  SE-971 28
 Sweden
 Phone: +46 (0) 8 404 41 58
 EMail: kristofer.sandlund@ericsson.com
 Ghyslain Pelletier
 Ericsson
 Box 920
 Lulea  SE-971 28
 Sweden
 Phone: +46 (0) 8 404 29 43
 EMail: ghyslain.pelletier@ericsson.com
 Lars-Erik Jonsson
 Optand 737
 Ostersund  SE-831 92
 Sweden
 Phone: +46 76 830 03 12
 EMail: lars-erik@lejonsson.com

Sandlund, et al. Standards Track [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5795.txt · Last modified: 2010/03/19 00:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki