doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc4362.txt b/doc/rfc/rfc4362.txt
new file mode 100644
index 0000000..0b0cc70
--- /dev/null
+++ b/doc/rfc/rfc4362.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                       L-E. Jonsson
+Request for Comments: 4362                                  G. Pelletier
+Obsoletes: 3242                                              K. Sandlund
+Category: Standards Track                                       Ericsson
+                                                            January 2006
+
+                   RObust Header Compression (ROHC):
+              A Link-Layer Assisted Profile for IP/UDP/RTP
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a ROHC (Robust Header Compression) profile for
+   compression of IP/UDP/RTP (Internet Protocol/User Datagram
+   Protocol/Real-Time Transport Protocol) packets, utilizing
+   functionality provided by the lower layers to increase compression
+   efficiency by completely eliminating the header for most packets
+   during optimal operation.  The profile is built as an extension to
+   the ROHC RTP profile.  It defines additional mechanisms needed in
+   ROHC, states requirements on the assisting layer to guarantee
+   transparency, and specifies general logic for compression and
+   decompression related to the usage of the header-free packet format.
+   This document is a replacement for RFC 3242, which it obsoletes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 1]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Differences from RFC 3242 ..................................5
+   2. Terminology .....................................................5
+   3. Overview of the Link-Layer Assisted Profile .....................6
+      3.1. Providing Packet Type Identification .......................7
+      3.2. Replacing the Sequence Number ..............................7
+      3.3. CRC Replacement ............................................8
+      3.4. Applicability of This Profile ..............................8
+   4. Additions and Exceptions Compared to ROHC RTP ...................9
+      4.1. Additional Packet Types ....................................9
+           4.1.1. No-Header Packet (NHP) ..............................9
+           4.1.2. Context Synchronization Packet (CSP) ................9
+           4.1.3. Context Check Packet (CCP) .........................11
+      4.2. Interfaces Towards the Assisting Layer ....................12
+           4.2.1. Interface, Compressor to Assisting Layer ...........13
+           4.2.2. Interface, Assisting Layer to Decompressor .........13
+      4.3. Optimistic Approach Agreement .............................14
+      4.4. Fast Context Initialization, IR Redefinition ..............15
+      4.5. Feedback Option, CV-REQUEST ...............................16
+      4.6. Periodic Context Verification .............................16
+      4.7. Use of Context Identifier .................................16
+   5. Implementation Issues ..........................................17
+      5.1. Implementation Parameters and Signals .....................17
+           5.1.1. Implementation Parameters at the Compressor ........17
+           5.1.2. Implementation Parameters at the Decompressor ......19
+      5.2. Implementation over Various Link Technologies .............19
+   6. IANA Considerations ............................................20
+   7. Security Considerations ........................................20
+   8. Acknowledgements ...............................................20
+   9. References .....................................................20
+      9.1. Normative References ......................................20
+      9.2. Informative References ....................................21
+
+1.  Introduction
+
+   Header compression is a technique used to compress and transparently
+   decompress the header information of a packet on a per-hop basis,
+   utilizing redundancy within individual packets and between
+   consecutive packets within a packet stream.  Over the years, several
+   protocols [VJHC, IPHC] have been developed to compress the network
+   and transport protocol headers [IPv4, IPv6, UDP, TCP], and these
+   schemes have been successful in improving efficiency over many wired
+   bottleneck links, such as modem connections over telephone networks.
+   In addition to IP, UDP, and TCP compression, an additional
+   compression scheme called Compressed RTP [CRTP] has been developed to
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 2]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   improve compression efficiency further for real-time traffic using
+   the Real-Time Transport Protocol [RTP].
+
+   The schemes mentioned above have all been designed by taking into
+   account normal assumptions about link characteristics, which
+   traditionally have been based on wired links only.  However, with an
+   increasing number of wireless links in the Internet paths, these
+   assumptions are no longer generally valid.  In wireless environments,
+   especially wide-coverage cellular environments, relatively high error
+   rates are tolerated in order to allow efficient usage of the radio
+   resources.  For real-time traffic, which is more sensitive to delays
+   than to errors, such operating conditions will be norm over, for
+   example, 3rd generation cellular links, and header compression must
+   therefore tolerate packet loss.  However, with the previously
+   mentioned schemes, especially for real-time traffic compressed by
+   CRTP, high error rates have been shown to significantly degrade
+   header compression performance [CRTPC].  This problem was the driving
+   force behind the creation of the RObust Header Compression (ROHC) WG
+   in the IETF.
+
+   The ROHC WG has developed a header compression framework on top of
+   which profiles can be defined for different protocol sets, or for
+   different compression strategies.  Due to the limited packet-loss
+   robustness of CRTP and the demands of the cellular industry for an
+   efficient way of transporting voice over IP over wireless, the main
+   focus of ROHC has so far been on compression of IP/UDP/RTP headers,
+   which are generous in size, especially when compared to the payloads
+   often carried by packets with such headers.
+
+   ROHC RTP has become a very efficient, robust, and capable compression
+   scheme, able to compress the headers down to a total size of one
+   octet only.  Also, transparency is guaranteed to an extremely great
+   extent, even when residual bit errors are present in compressed
+   headers delivered to the decompressor.  The requirements for RTP
+   compression [RTP-REQ], defined by the WG before and during the
+   development process, have thus been fulfilled.
+
+   As mentioned above, the 3rd generation cellular systems, where IP
+   will be used end-to-end, have been one of the driving forces behind
+   ROHC RTP, and the scheme has also been designed to suit new cellular
+   air interfaces, such as WCDMA, making it possible to run even speech
+   services with spectrum efficiency insignificantly lower than for
+   existing one-service circuit switched solutions [VTC2000].  However,
+   other air interfaces (such as those based on GSM and IS-95) will also
+   be used in all-IP networks, with further implications for the header
+   compression issue.  These older air interfaces are less flexible,
+   with radio bearers optimized for specific payload sizes.  This means
+   that not even a single octet of header can be added without using the
+
+
+
+Jonsson, et al.             Standards Track                     [Page 3]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   next higher fixed packet size supported by the link, something that
+   is obviously very costly.  For the already deployed speech vocoders,
+   the spectrum efficiency over these links will thus be low compared to
+   existing circuit-switched solutions.  To achieve high spectrum
+   efficiency overall with any application, more flexible air interfaces
+   must be deployed, and then the ROHC RTP scheme will perform
+   excellently, as shown for WCDMA [MOMUC01].  However, for deployment
+   reasons, it is important to also provide a suitable header
+   compression strategy for already existing vocoders and air
+   interfaces, such as for GERAN and for CDMA2000, with minimal effects
+   on spectral efficiency.
+
+   This document describes a link-layer-assisted ROHC RTP profile,
+   originally defined by [LLA], extending ROHC RTP (profile 0x0001)
+   [ROHC], and compliant with the ROHC 0-byte requirements [0B-REQ].
+   The purpose of this profile is to provide a header-free packet format
+   that, for a certain application behavior, can replace a majority of
+   the 1-octet header ROHC RTP packets during normal U/O-mode operation,
+   while still being fully transparent and complying with all the
+   requirements of ROHC RTP [RTP-REQ].  For other applications,
+   compression will be carried out as with normal ROHC RTP.
+
+   To completely eliminate the compressed header, all functionality
+   normally provided by the 1-octet header has to be provided by other
+   means, typically by utilizing functionality provided by the lower
+   layers and sacrificing efficiency for less-frequently occurring
+   larger compressed headers.  The latter is not a contradiction, since
+   the argument for eliminating the last octet for most packets is not
+   overall efficiency in general.  It is important to remember that the
+   purpose of this profile is to provide efficient matching of existing
+   applications to existing link technologies, not efficiency in
+   general.  The additional complexity introduced by this profile,
+   although minimized by a tight integration with already-existing ROHC
+   functionality, implies that it should therefore only be used to
+   optimize performance of specific applications over specific links.
+
+   When implementing this profile over various link technologies, care
+   must be taken to guarantee that all the functionality needed is
+   provided by ROHC and the lower layers together.  Therefore,
+   additional documents should specify how to incorporate this profile
+   on top of various link technologies.
+
+   The profile defined by this document was originally specified by RFC
+   3242 [LLA], but to address one technical flaw and clarify one
+   implementation issue, this document has been issued to replace RFC
+   3242, which becomes obsolete.
+
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 4]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+1.1.  Differences from RFC 3242
+
+   This section briefly summarizes the differences of this document from
+   RFC 3242.  Acronyms and terminology can be found in Section 2.
+
+   The format of the CSP packet, as defined in [LLA], was identified as
+   non-interoperable when carrying a RHP header with a 3-bit or 7-bit
+   CRC.  This problem occurs because the payload has been dropped by the
+   compressor, and the decompressor is supposed to use the payload
+   length to infer certain fields in the uncompressed header.  These
+   fields are the IPv4 total length, the IPv6 payload length, the UDP
+   length, and the IPv4 header checksum field (all INFERRED fields in
+   [ROHC]).  To correct this flaw, the CSP packet must carry information
+   about the payload length of the RHP packet.  Therefore, the length of
+   the RTP payload has been included in the CSP packet.
+
+   This document also clarifies an unclear referencing in RFC 3242,
+   where Section 4.1.3 of [LLA] states that upon CRC failure, the
+   actions of [ROHC], Section 5.3.2.2.3 MUST be taken.  That section
+   specifies that detection of SN wraparound and local repair must be
+   performed, but neither of these steps apply when the failing packet
+   is a CCP.  Therefore, upon CRC failure, actions to be taken are the
+   ones specified in Section 5.3.2.2.3, but steps a-d only.
+
+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 RFC 2119 [RFC2119].
+
+   CCP    Context Check Packet
+   CRC    Cyclic Redundancy Check
+   CSP    Context Synchronization Packet
+   LLA    Link Layer Assisted ROHC RTP profile
+   NHP    No Header Packet
+   ROHC   RObust Header Compression
+   RHP    ROHC Header Packet (a non-NHP packet; i.e., RRP, CSP, or CCP)
+   RRP    ROHC RTP Packet as defined in [ROHC, profile 0x0001]
+
+   Assisting layer
+
+      "Assisting layer" refers to any entity implementing the interface
+      to ROHC (Section 4.2).  It may, for example, refer to a sub-layer
+      used to adapt the ROHC implementation and the physical link layer.
+      This layer is assumed to have knowledge of the physical layer
+      synchronization.
+
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 5]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   Compressing side
+
+      "Compressing side" refers to the combination of the header
+      compressor, operating with the LLA profile, and its associated
+      assisting layer.
+
+   Lower layers
+
+      "Lower layers", in this document, refers to entities located below
+      ROHC in the protocol stack, including the assisting layer.
+
+   ROHC RTP
+
+      "ROHC RTP" refers to the IP/UDP/RTP profile as defined in [ROHC].
+
+3.  Overview of the Link-Layer Assisted Profile
+
+   The ROHC IP/UDP/RTP profile defined in [LLA] and updated by this
+   document, profile 0x0005 (hex), is designed to be used over channels
+   that have been optimized for specific payload sizes and that
+   therefore cannot efficiently accommodate header information when
+   transmitted together with payloads corresponding to these optimal
+   sizes.
+
+   The LLA profile extends, and thus also inherits all functionality
+   from, the ROCH RTP profile by defining some additional functionality
+   and an interface from the ROHC component towards an assisting lower
+   layer.
+
+                   +---------------------------------------+
+                   |                                       |
+      The LLA      |    ROHC RTP,                          |
+      profile      |    Profile #1       +-----------------+
+                   |                     |  LLA Additions  |
+                   +---------------------+-----------------+
+
+   By imposing additional requirements on the lower layers compared to
+   [ROHC], it is possible to infer the information needed to maintain
+   robust and transparent header compression, even though the headers
+   are completely eliminated during most of the operation time.
+
+   Basically, this profile replaces the smallest and most frequent ROHC
+   U/O-mode headers with a no-header format, for which the header
+   functionality must be provided by other means.
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 6]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+     Smallest header in                 Smallest header in
+     ROHC RTP (profile #1)              LLA (profile #5)
+   +--+--+--+--+--+--+--+--+              ++
+   |        1 octet        |  ----->      ||  No Header
+   +--+--+--+--+--+--+--+--+              ++
+               |
+               |                        Header field functionality
+               +------------------->    provided by other means
+
+   The fields present in the ROHC RTP headers for U/O-mode PT0 are the
+   packet type identifier, the sequence number, and the CRC.  The
+   subsequent sections elaborate more on how the functionality of these
+   fields is replaced for NHP.
+
+3.1.  Providing Packet Type Identification
+
+   All ROHC headers carry a packet type identifier, indicating to the
+   decompressor how the header should be interpreted.  This is a
+   function that must be provided by some means in 0-byte header
+   compression.  It will be possible to distinguish ROHC RTP packets
+   with compressed headers thanks to the packet type identifier, but a
+   mechanism is needed to separate packets with a header from packets
+   without a header.  This function MUST therefore be provided by the
+   assisting layer in one way or another.
+
+3.2.  Replacing the Sequence Number
+
+   From the sending application, the RTP sequence number is increased by
+   one for each packet sent.  The purpose of the sequence number is to
+   cope with packet reordering and packet loss.  If reordering or loss
+   has occurred before the transmission point, the compressing side, if
+   needed, can easily avoid problems by not allowing the use of a
+   header-free packet.
+
+   However, at the transmission point, loss or reordering that may occur
+   over the link can not be anticipated and covered for.  Therefore, for
+   NHP, the assisting layer MUST guarantee in-order delivery over the
+   link (already assumed by [ROHC]), and at the receiving side, it MUST
+   provide an indication for each packet loss over the link.  This is
+   basically the same principle as that which the VJ header compression
+   [VJHC] relies on.
+
+   Note that guaranteeing in-order delivery and packet loss indication
+   over the link not only makes it possible to infer the sequence number
+   information, but also supersedes the main function of the CRC, which
+   normally takes care of errors due to link losses and bit errors in
+   the compressed sequence number.
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 7]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+3.3.  CRC Replacement
+
+   All context-updating RRP packets carry a CRC calculated over the
+   uncompressed header.  The CRC is used by the decompressor to verify
+   that the updated context is correct.  This verification serves three
+   purposes in U/O-mode:
+
+      1) Detection of longer losses than can be covered by the sequence
+         number LSBs.
+
+      2) Protection against failures caused by residual bit errors in
+         compressed headers.
+
+      3) Protection against faulty implementations and other causes of
+         error.
+
+   Since this profile defines an NHP packet without this CRC, care must
+   be taken to fulfill these purposes by other means when an NHP is used
+   as a replacement for a context-updating packet.  Detection of long
+   losses (1) is already covered, since the assisting layer MUST provide
+   an indication of all packet losses.  Furthermore, the NHP packet has
+   one important advantage over RHP packets in that residual bit errors
+   (2) cannot damage a header that is not even sent.
+
+   It is thus reasonable to assume that compression and decompression
+   transparency can be assured with high confidence, even without a CRC
+   in header-free packets.  However, to provide additional protection
+   against damage propagation due to undetected residual bit errors in
+   context-updating packets (2) or other unexpected errors (3), periodic
+   context verifications SHOULD be performed (see Section 4.6).
+
+3.4.  Applicability of This Profile
+
+   The LLA profile can be used with any link technology capable of
+   providing the required functionality described in previous sections.
+   Thus, whether LLA or ROHC RTP should be implemented depends on the
+   characteristics of the link itself.  For most RTP packet streams, LLA
+   will work exactly as ROHC RTP, and it will have a higher compression
+   efficiency for packet streams with certain characteristics.  LLA will
+   never have a lower compression efficiency than ROHC RTP.
+
+   Note as well that LLA, like all other ROHC profiles, is fully
+   transparent to any packet stream reaching the compressor.  LLA does
+   not make any assumptions about the packet stream but will perform
+   optimally for packet streams with certain characteristics, e.g.,
+   synchronized streams exactly timed with the assisting link over which
+   the LLA profile is implemented.
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 8]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   The LLA profile is obviously not applicable if the UDP checksum (2
+   bytes) is enabled, which is always the case for IPv6/UDP.  For
+   IPv4/UDP, the sender may choose to disable the UDP checksum.
+
+4.  Additions and Exceptions Compared to ROHC RTP
+
+4.1.  Additional Packet Types
+
+   The LLA profile defines three new packet types to be used in addition
+   to the RRP packet types defined by [ROHC].  The following sections
+   describe these packet types and their purpose in detail.
+
+4.1.1.  No-Header Packet (NHP)
+
+   A No-Header Packet (NHP) is a packet that consists only of the
+   payload of the original packet.  The NHP MAY be used when only the
+   sequence information needs to be conveyed to the decompressor.  In
+   other words, the NHP can be used when all header fields are either
+   unchanged or follow the currently established change pattern.  In
+   addition, there are some considerations for the use of the NHP (see
+   sections 4.3, 4.5, and 4.6).  An LLA compressor is not allowed to
+   deliver NHP packets when operating in R-mode.
+
+   The assisting layer MAY send the NHP for RTP SN = X only if an NHP
+   was delivered by the LLA compressor AND the assisting layer can
+   guarantee that the decompressor will infer the proper sequencing for
+   this NHP.  This guarantee is based on the confidence that the
+   decompressor
+
+      a) has the means to infer proper sequencing for the packet
+         corresponding to SN = X-1, AND
+
+      b) has either received a loss indication or the packet itself for
+         the packet corresponding to SN = X-1.
+
+   Updating properties: NHP packets update context (RTP Sequence
+   Number).
+
+4.1.2.  Context Synchronization Packet (CSP)
+
+   The case where the packet stream overruns the channel bandwidth may
+   lead to discarded data, which may result in decompressor context
+   invalidation.  It might therefore be beneficial to send a packet with
+   only the header information and to discard the payload.  This would
+   be helpful to maintain synchronization of the decompressor context
+   while efficiently using the available bandwidth.
+
+
+
+
+
+Jonsson, et al.             Standards Track                     [Page 9]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   This case can be handled with the Context Synchronization Packet
+   (CSP), which has the following format:
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 1   1   1   1   1   0   1   0 | Packet type identifier
+   +===+===+===+===+===+===+===+===+
+   /       RTP Payload Length      / 2 octets
+   +---+---+---+---+---+---+---+---+
+   :  ROHC header without padding  :
+   :    see [ROHC, Section 5.7]    :
+   +---+---+---+---+---+---+---+---+
+
+     RTP Payload Length: This field is the length of the payload carried
+                         inside the RTP header, stored in network byte
+                         order.  That is, this field will be set by the
+                         compressor to (UDP length - size of the UDP
+                         header - size of the RTP header including CSRC
+                         identifiers).
+
+   Updating properties: CSP maintains the updating properties of the
+   ROHC header it carries.
+
+   The CSP is defined by one of the unused packet type identifiers from
+   ROHC RTP, carried in the one-octet base header.  As for any ROHC
+   packet, except the NHP, the packet may begin with ROHC padding and/or
+   feedback.  It may also carry context identification after the packet
+   type identifier.  It is possible to have two CID fields present, one
+   after the packet type ID and one within the encapsulated ROHC header.
+   If a decompressor receives a CSP with two non-equal CID values
+   included, the packet MUST be discarded.  ROHC segmentation may also
+   be applied to the CSP.
+
+   In the CSP packet, the payload has been dropped by the compressor.
+   However, the decompressor is supposed to use the payload length to
+   infer certain fields in the uncompressed header (the IPv4 total
+   length, the IPv6 payload length, the UDP length, and the IPv4 header
+   checksum field).  When dropping the payload, the CSP packet needs to
+   contain information about the payload length carried in the RHP
+   packet.  Therefore, the length of the RTP payload is carried in the
+   CSP packet.  When the decompressor receives a CSP packet, it can use
+   the RTP payload length field to calculate the value of fields
+   classified as INFERRED in [ROHC] when attempting to verify a 3- or
+   7-bit CRC carried in the RHP header enclosed in the CSP.
+
+   Note that when the decompressor has received and processed a CSP, the
+   packet (including any possible data following the CSP encapsulated
+   compressed header) MUST be discarded.
+
+
+
+Jonsson, et al.             Standards Track                    [Page 10]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+4.1.3.  Context Check Packet (CCP)
+
+   A Context Check Packet (CCP), which does not carry any payload but
+   only an optional CRC value in addition to the packet type identifier,
+   is defined.
+
+   The purpose of the CCP is to provide a useful packet that MAY be sent
+   by a synchronized physical link layer in the case where data must be
+   sent at fixed intervals, even if no compressed packet is available.
+   Whether the CCP is sent over the link and delivered to the
+   decompressor is decided by the assisting layer.  The CCP has the
+   following format:
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 1   1   1   1   1   0   1   1 | Packet type identifier
+   +===+===+===+===+===+===+===+===+
+   | C |          CRC              |
+   +---+---+---+---+---+---+---+---+
+
+     C: C = 0 indicates that the CRC field is not used.
+        C = 1 indicates that a valid CRC is present.
+
+   Updating properties: CCP packets do not update context.
+
+   The CCP is defined by one of the unused packet type identifiers from
+   ROHC RTP, carried in the first octet of the base header.  The first
+   bit of the second octet, the C bit, indicates whether the CRC field
+   is used.  If C=1, the CRC field MUST be set to the 7-bit CRC
+   calculated over the original uncompressed header defined in [ROHC,
+   Section 5.9.2].  As for any ROHC packet, except NHP, the packet MAY
+   begin with ROHC padding and/or carry context identification.
+
+   The use of the CRC field to perform decompressor context verification
+   is optional and is therefore a compressor implementation issue.
+   However, a CCP MUST always be made available to the assisting layer.
+
+   If the assisting layer receives CCPs with the C bit set (C=1) from
+   the compressor, it MUST use the last CCP received if a CCP is to be
+   sent, i.e., the CCP corresponding to the last non-CCP packet sent
+   (NHP, RRP or CSP).  An assisting layer MAY use the CCP for other
+   purposes, such as signaling a packet loss before the link.
+
+   The decompressor is REQUIRED to handle a CCP received with the C bit
+   set (C=1), indicating a valid CRC field, and to perform context
+   verification.  The received CRC MUST then be applied to the last
+   decompressed packet, unless a packet loss indication was previously
+   received.  Upon CRC failure, actions MUST be taken as specified in
+
+
+
+Jonsson, et al.             Standards Track                    [Page 11]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   [ROHC, Section 5.3.2.2.3, steps a-d only].  A CCP received with C=0
+   MUST be ignored by the decompressor.  The decompressor is not allowed
+   to make any further interpretation of the CCP.
+
+   When using the 7-bit CRC in the CCP packet to verify the context, the
+   decompressor needs to have access to the entire uncompressed header
+   of the latest packet decompressed.  Some implementations of [ROHC]
+   might not save the values of INFERRED fields.  An implementation of
+   ROHC LLA MUST save these fields in the decompressor context to be
+   able to successfully verify CCP packets.
+
+   The use of CCP by an assisting layer is optional and depends on the
+   characteristics of the actual link.  Whether it is used MUST
+   therefore be specified in link-layer implementation specifications
+   for this profile.
+
+4.2.  Interfaces Towards the Assisting Layer
+
+   This profile relies on the lower layers to provide the necessary
+   functionality to allow NHP packets to be sent.  This interaction
+   between LLA and the assisting layer is defined as interfaces between
+   the LLA compressor/decompressor and the LLA applicable link
+   technology.
+
+                |                              |
+                +                              +
+   +-------------------------+    +-------------------------+
+   |       ROHC RTP HC       |    |       ROHC RTP HD       |
+   +-------------------------+    +-------------------------+
+   |       LLA profile       |    |       LLA profile       |
+   +=========================+    +=========================+
+   |       Interface         |    |        Interface        |
+   | ROHC to assisting layer |    | Assisting layer to ROHC |
+   +=========================+    +=========================+
+   |       Applicable        |    |       Applicable        |
+   |     link technology     |    |     link technology     |
+   +=========================+    +=========================+
+                |                              |
+                +------>---- CHANNEL ---->-----+
+
+   The figure above shows the various levels, as defined in [ROHC] and
+   this document, constituting a complete implementation of the LLA
+   profile.  The figure also underlines the need for additional
+   documents to specify how to implement these interfaces for a link
+   technology for which this profile is relevant.
+
+   This section defines the information to be exchanged between the LLA
+   compressor and the assisting layer for this profile to operate
+
+
+
+Jonsson, et al.             Standards Track                    [Page 12]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   properly.  While it does define semantics, it does not specify how
+   these interfaces are to be implemented.
+
+4.2.1.  Interface, Compressor to Assisting Layer
+
+   This section defines the interface semantics between the compressor
+   and the assisting layer, providing rules for packet delivery from the
+   compressor.
+
+   The interface defines the following parameters: RRP, RRP segmentation
+   flag, CSP, CSP segmentation flag, NHP, and RTP Sequence Number.  All
+   parameters, except the NHP, MUST always be delivered to the assisting
+   layer.  This leads to two possible delivery scenarios:
+
+      a. RRP, CSP, CCP, NHP, and RTP Sequence Number are delivered,
+         along with the corresponding segmentation flags, set
+         accordingly.
+
+         This corresponds to the case when the compressor allows sending
+         of an NHP packet, with or without segmentation applied to the
+         corresponding RRP/CSP packets.
+
+         Recall that delivery of an NHP packet occurs when the ROHC RTP
+         compressor would have used a ROHC UO-0.
+
+      b. RRP, CSP, CCP, and RTP Sequence Number are delivered, along
+         with the corresponding segmentation flags, set accordingly.
+
+         This corresponds to the case when the compressor does not allow
+         sending of an NHP packet.  Segmentation might be applied to the
+         corresponding RRP and CSP packets.
+
+   Segmentation may be applied independently to an RRP or a CSP packet
+   if its size exceeds the largest value provided in the PREFERRED
+   PACKET_SIZES list and if the LARGE_PACKET_ALLOWED parameter is set to
+   false.  The segmentation flags are explicitly stated in the interface
+   definition to emphasize that the RRP and the CSP may be delivered by
+   the compressor as segmented packets.
+
+   The RTP SN MUST be delivered for each packet by the compressor to
+   allow the assisting layer to maintain the necessary sequencing
+   information.
+
+4.2.2.  Interface, Assisting Layer to Decompressor
+
+   Here the interface semantics between the assisting layer and the
+   decompressor are defined, providing simple rules for the delivery of
+   received packets to the decompressor.  The decompressor needs a way
+
+
+
+Jonsson, et al.             Standards Track                    [Page 13]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   to distinguish NHP packets from RHP packets.  Also, when receiving
+   packets without a header, the decompressor needs a way to infer the
+   sequencing information to keep synchronization between the received
+   payload and the sequence information of the decompressed headers.  To
+   achieve this, the decompressor MUST receive the following from the
+   assisting layer:
+
+      -  an indication for each packet loss over the link between the
+         compressing and decompressing sides for CID=0.
+
+      -  the received packet together with an indication of whether the
+         packet received is an NHP.
+
+   Note that the context is updated from a packet loss indication.
+
+4.3.  Optimistic Approach Agreement
+
+   ROHC defines an optimistic approach for updates to reduce the header
+   overhead.  This approach is fully exploited in the Optimistic and
+   Unidirectional modes of operation.  Due to the presence of a CRC in
+   all compressed headers, the optimistic approach is defined as a
+   compressor issue only because the decompressor will always be able to
+   detect an invalid context through the CRC verification.
+
+   However, no CRC is present in the NHP packet defined by the LLA
+   profile.  Therefore, the loss of an RHP packet updating the context
+   may not always be detected.  To avoid this problem, the compressing
+   and decompressing sides must agree on the principles for the
+   optimistic approach, and the agreed principles MUST be enforced not
+   only by the compressor but also by the transmitting assisting layer.
+   If, for example, three consecutive updates are sent to convey a
+   header field change, the decompressor must know this and invalidate
+   the context if three or more consecutive physical packets are lost.
+   Note that the mechanism used to enforce the optimistic approach must
+   be reinitialized if a new field change needs to be conveyed while the
+   compressing side is already sending packets to convey non-linear
+   context updates.
+
+   An LLA decompressor MUST use the optimistic approach knowledge to
+   detect possible context loss events.  If context loss is suspected,
+   it MUST invalidate the context and not forward any packets before the
+   context has been synchronized.
+
+   It is REQUIRED that all documents describing how the LLA profile is
+   implemented over a certain link technology define how the optimistic
+   approach is agreed to between the compressing side and the
+   decompressing side.  It could be handled with a fixed principle, with
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 14]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   negotiation at startup, or by other means, but the method must be
+   unambiguously defined.
+
+4.4.  Fast Context Initialization, IR Redefinition
+
+   As initial IR packets might overrun the channel bandwidth and
+   significantly delay decompressor context establishment, it might be
+   beneficial to initially discard the payload.  This allows state
+   transitions and higher compression efficiency to be achieved with
+   minimal delay.
+
+   To serve this purpose, the D-bit from the basic structure of the ROHC
+   RTP IR packet [ROHC, Section 5.7.7.1] is redefined for the LLA
+   profile.  For D=0 (no dynamic chain), the meaning of the D-bit is
+   extended to indicate that the payload has been discarded when
+   assembling the IR packet.  All other fields keep their meanings as
+   defined for ROHC RTP.
+
+   The resulting structure, using small CIDs and CID=0, becomes:
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 1 | 1 | 1 | 1 | 1 | 1 | 0 | D |
+   +---+---+---+---+---+---+---+---+
+   |            Profile            | 1 octet
+   +---+---+---+---+---+---+---+---+
+   |              CRC              | 1 octet
+   +---+---+---+---+---+---+---+---+
+   |            Static             | variable length
+   |             chain             |
+    - - - - - - - - - - - - - - - -
+   |            Dynamic            | not present if D = 0
+   |             chain             | present if D = 1, variable length
+    - - - - - - - - - - - - - - - -
+   |            Payload            | not present if D = 0
+   |                               | present if D = 1, variable length
+    - - - - - - - - - - - - - - - -
+
+        D:   D = 0 indicates that the dynamic chain is not present
+             and that the payload has been discarded.
+
+   After an IR packet with D=0 has been processed by the decompressor,
+   the packet MUST be discarded.
+
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 15]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+4.5.  Feedback Option, CV-REQUEST
+
+   The CV-REQUEST option MAY be used by the decompressor to request an
+   RRP or CSP for context verification.  This option should be used if
+   only NHPs have been received for a long time and the context
+   therefore has not been verified recently.
+
+   +---+---+---+---+---+---+---+---+
+   |  Opt Type = 8 |  Opt Len = 0  |
+   +---+---+---+---+---+---+---+---+
+
+   If the compressor receives a feedback packet with this option, the
+   next packet compressed SHOULD NOT be delivered to the assisting layer
+   as an NHP.
+
+4.6.  Periodic Context Verification
+
+   As described in Section 3.3, transparency is expected to be
+   guaranteed by the functionality provided by the lower layers.  This
+   ROHC profile would therefore be at least as reliable as the older
+   header compression schemes [VJHC, IPHC, CRTP], which do not make use
+   of a header compression CRC.  However, since ROHC RTP normally is
+   extremely safe to use from a transparency point of view, it would be
+   desirable to be able to achieve this with LLA also.
+
+   To provide an additional guarantee for transparency and also catch
+   unexpected errors, such as errors due to faulty implementations, it
+   is RECOMMENDED that context updating packets be sent periodically,
+   even when the compressor logic allows NHP packets to be used.
+
+4.7.  Use of Context Identifier
+
+   Since an NHP cannot carry a context identifier (CID), there is a
+   restriction on how this profile may be used, related to context
+   identification.  Independent of which CID size has been negotiated,
+   NHP packets can only be used for CID=0.  If the decompressor receives
+   an NHP packet, it can only belong to CID=0.
+
+   Note that if multiple packet streams are handled by a compressor
+   operating using LLA, the assisting layer must, in case of physical
+   packet loss, be able to tell for which CID the loss occurred, or at
+   least it MUST be able to tell if packets with CID=0 (packet stream
+   with NHPs) have been lost.
+
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 16]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+5.  Implementation Issues
+
+   This document specifies mechanisms for the protocol and leaves
+   details on the use of these mechanisms to the implementers.  The
+   present section aims to provide guidelines, ideas, and suggestions
+   for implementation of LLA.
+
+5.1.  Implementation Parameters and Signals
+
+   As described in [ROHC, Section 6.3], implementations use parameters
+   to set up configuration information and to stipulate how a ROHC
+   implementation is to operate.  The following parameters are
+   additions, useful to LLA, to the parameter set defined for ROHC RTP
+   implementations.  Note that if the PREFERRED_PACKET_SIZES parameters
+   defined here are used, they obsolete all PACKET_SIZE and PAYLOAD_SIZE
+   parameters of ROHC RTP.
+
+5.1.1.  Implementation Parameters at the Compressor
+
+   ALWAYS_PAD -- value: boolean
+
+      This parameter may be set by an external entity to specify to the
+      compressor that every RHP packet MUST be padded with ROHC padding
+      of one octet, minimum.
+
+      The assisting layer MUST provide a packet type identification.  If
+      no field is available for this purpose from the protocol at the
+      link layer, then a leading sequence may be used to distinguish RHP
+      packets from NHP packets.  Although the use of a leading sequence
+      is obviously not efficient, since it sacrifices efficiency for RHP
+      packets, the efficiency loss should be insignificant because the
+      leading sequence applies only to packets with headers in order to
+      favor the use of packets without headers.  If a leading sequence
+      is desired for RHP identification, the lower layer MAY use ROHC
+      padding for the leading sequence by setting the ALWAYS_PAD
+      parameter.  Note that in such cases, possible collisions of the
+      padding with the NHP payload must be avoided.
+
+      By default, this parameter is set to FALSE.
+
+   PREFERRED_PACKET_SIZES -- list of:
+         SIZE -- value: integer (octets)
+         RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION]
+
+      This parameter set governs which packet sizes are preferred by the
+      assisting layer.  If this parameter set is used, all RHP packets
+      MUST be padded to fit the smallest possible preferred size.  If
+      the size of the unpadded packet (or, in the case of ALWAYS_PAD
+
+
+
+Jonsson, et al.             Standards Track                    [Page 17]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+      being set, the packet with minimal one-octet padding) is larger
+      than the maximal preferred packet size, the compressor has two
+      options.  Either it may deliver this larger packet with an
+      arbitrary size, or it may split the packet into several segments
+      using ROHC segmentation and pad each segment to one of the
+      preferred sizes.  Which method to use depends on the value of the
+      LARGE_PACKETS_ALLOWED parameter below.
+
+      NHP packets can be delivered to the lower layer only if the
+      payload size is part of the preferred packet size set.
+      Furthermore, if RESTRICTED_TYPE is set to one of NHP_ONLY or
+      RHP_ONLY for any of the preferred packet sizes, that size is
+      allowed only for packets of the specified type.
+
+      By default, no preferred packet sizes are specified.  When sizes
+      are specified, the default value for RESTRICTED_TYPE is
+      NO_RESTRICTION.
+
+   LARGE_PACKETS_ALLOWED -- value: boolean
+
+      This parameter may be set by an external entity to specify how to
+      handle packets that do not fit any of the preferred packet sizes
+      specified.  If it is set to TRUE, the compressor MUST deliver the
+      larger packet as-is and MUST NOT use segmentation.  If it is set
+      to FALSE, the ROHC segmentation scheme MUST be used to split the
+      packet into two or more segments, and each segment MUST further be
+      padded to fit one of the preferred packet sizes.
+
+      By default, this parameter is set to TRUE, which means that
+      segmentation is disabled.
+
+   VERIFICATION_PERIOD -- value: integer
+
+      This parameter may be set by an external entity to specify to the
+      compressor the minimum frequency with which a packet validating
+      the context must be sent.  This tells the compressor that a packet
+      containing a CRC field MUST be sent at least once every N packets,
+      where N=VERIFICATION_PERIOD (see Section 4.6).
+
+      By default, this parameter is set to 0, which indicates that
+      periodical verifications are disabled.
+
+
+
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 18]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+5.1.2.  Implementation Parameters at the Decompressor
+
+   NHP_PACKET -- value: boolean
+
+      This parameter informs the decompressor that the packet being
+      delivered is an NHP packet.  The decompressor MUST accept this
+      packet type indicator from the lower layer.  An assisting layer
+      MUST set this indicator to true for every NHP packet delivered,
+      and to false for any other packet.
+
+   PHYSICAL_PACKET_LOSS -- signal
+
+      This signal indicates to the decompressor that a packet has been
+      lost on the link between the compressing and the decompressing
+      sides, due to a physical link error.  The signal is given once for
+      each packet that was lost, and a decompressor must increase the
+      sequence number accordingly when this signal is received.
+
+   PRE_LINK_PACKET_LOSS -- signal
+
+      This signal tells the decompressor to increase the sequence number
+      due to a gap in the sequencing not related to a physical link
+      error.  A receiving assisting layer may, for example, use this
+      signal to indicate to the decompressor that a packet was lost
+      before the compressor, or that a packet was discarded by the
+      transmitting assisting layer.
+
+5.2.  Implementation over Various Link Technologies
+
+   This document provides the semantics and requirements of the
+   interface needed from the ROHC compressor and decompressor towards
+   the assisting layer to perform link-layer-assisted header
+   compression.
+
+   However, this document does not provide any link-layer-specific
+   operational information, except for some implementation suggestions.
+   Further details about how this profile is to be implemented over
+   various link technologies must be described in other documents, where
+   specific characteristics of each link layer can be taken into account
+   to provide optimal usage of this profile.
+
+   These specifications MAY use a packet-type bit pattern unused by this
+   profile to implement signaling on the lower layer.  The pattern
+   available to lower layer implementations is [11111001].
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 19]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+6.  IANA Considerations
+
+   ROHC profile identifier 0x0005 has been reserved by the IANA for the
+   IP/UDP/RTP profile defined in this document.
+
+7.  Security Considerations
+
+   The security considerations of ROHC RTP [ROHC, Section 7] apply also
+   to this document, with one addition: in the case of a denial-of-
+   service attack scenario where an intruder injects bogus CCP packets
+   using random CRC values onto the link, the CRC check will fail for
+   incorrect reasons at the decompressor side.  This would obviously
+   greatly reduce the advantages of ROHC and any extra efficiency
+   provided by this profile due to unnecessary context invalidation,
+   feedback messages, and refresh packets.  However, the same remarks
+   related to the presence of such an intruder apply.
+
+8.  Acknowledgements
+
+   The authors would like to thank Lila Madour, Ulises Olvera-Hernandez,
+   and Francis Lupien for input regarding the typical links in which LLA
+   can be applied.  Thanks also to Mikael Degermark for fruitful
+   discussions that led to improvements of this profile, and to Zhigang
+   Liu for many valuable comments.
+
+9.  References
+
+9.1.  Normative References
+
+   [ROHC]    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.
+
+   [IPv4]    Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+   [IPv6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [UDP]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+             August 1980.
+
+   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
+             Jacobson, "RTP: A Transport Protocol for Real-Time
+             Applications", STD 64, RFC 3550, July 2003.
+
+
+
+Jonsson, et al.             Standards Track                    [Page 20]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+9.2.  Informative References
+
+   [LLA]     Jonsson, L-E. and G. Pelletier, "RObust Header Compression
+             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC
+             3242, April 2002.
+
+   [TCP]     Postel, J., "Transmission Control Protocol", STD 7, RFC
+             793, September 1981.
+
+   [RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header
+             compression", RFC 3096, July 2001.
+
+   [0B-REQ]  Jonsson, L-E., "RObust Header Compression (ROHC):
+             Requirements and Assumptions for 0-byte IP/UDP/RTP
+             Compression", RFC 3243, April 2002.
+
+   [VJHC]    Jacobson, V., "Compressing TCP/IP headers for low-speed
+             serial links", RFC 1144, February 1990.
+
+   [IPHC]    Degermark, M., Nordgren, B., and S. Pink, "IP Header
+             Compression", RFC 2507, February 1999.
+
+   [CRTP]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
+             for Low-Speed Serial Links", RFC 2508, February 1999.
+
+   [CRTPC]   Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro,
+             "Evaluation of CRTP Performance over Cellular Radio
+             Networks", IEEE Personal Communications Magazine, Volume 7,
+             number 4, pp. 20-25, August 2000.
+
+   [VTC2000] Svanbro, K., Hannu, H., Jonsson, L-E. and M. Degermark,
+             "Wireless real time IP-services enabled by header
+             compression", proceedings of IEEE VTC2000, May 2000.
+
+   [MOMUC01] Liu, G., et al., "Experimental field trials results of
+             Voice-over IP over WCDMA links", MoMuC'01 - The
+             International Workshop on Mobile Multimedia Communications,
+             Conference proceedings, February 2001.
+
+
+
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 21]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+Authors' Addresses
+
+   Lars-Erik Jonsson
+   Ericsson AB
+   Box 920
+   SE-971 28 Lulea, Sweden
+
+   Phone: +46 8 404 29 61
+   Fax:   +46 920 996 21
+   EMail: lars-erik.jonsson@ericsson.com
+
+
+   Ghyslain Pelletier
+   Ericsson AB
+   Box 920
+   SE-971 28 Lulea, Sweden
+
+   Phone: +46 8 404 29 43
+   Fax:   +46 920 996 21
+   EMail: ghyslain.pelletier@ericsson.com
+
+
+   Kristofer Sandlund
+   Ericsson AB
+   Box 920
+   SE-971 28 Lulea, Sweden
+
+   Phone: +46 8 404 41 58
+   Fax:   +46 920 996 21
+   EMail: kristofer.sandlund@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 22]
+
+RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Jonsson, et al.             Standards Track                    [Page 23]
+