[rohc] RE: Updating draft-ietf-rohc-rfc3095bis-framework-01.txt: Summary of proposed changes

The draft has now been submitted with these changes. Please
make sure to review them and let the list know if you have
any comments. If we do not hear any objections before the
ROHC session at IETF 66 (July 11th), we will consider this
current WG consensus.

BR
/L-E

----Original Message----
From: Ghyslain Pelletier (LU/EAB)
Sent: den 26 juni 2006 01:09
To: rohc@ietf.org
Cc: Lars-Erik Jonsson (LU/EAB); Kristofer Sandlund (LU/EAB)
Subject: Updating
draft-ietf-rohc-rfc3095bis-framework-01.txt: Summary of
proposed changes

> RoHCers,
> 
> I'm in the process of updating the draft that separately
> defines the ROHC framework,
> draft-ietf-rohc-rfc3095bis-framework-01.txt. We're targeting
> a submission on time for the Montreal meeting deadline, i.e.
> ... tomorrow Monday morning in a few hours from now!
> 
> Although it is short notice, I thought I would send a summary
> of the proposed updates to the list. Would someone comment
> against these changes even after the draft is submitted, we
> can always undo the changes in a later version would we reach
> a better agreement. These proposed changes will thus likely
> make it in the submission -01, but there are still very open
> to comments.
> 
> Most of the changes are related to aligning the framework
> draft with the ROHCv2 profiles
> (draft-draft-pelletier-rohc-rohcv2-profiles-00.txt).
> 
> /Ghyslain, on behalf of Kristofer and Lars-Erik
> 
> Summary of the proposed changes:
> --------------------------------
> 
> Most of the changes are meant to harmonize the framework
> draft with the recently submitted ROHCv2 profiles.
> 
> 1) Editorial: deletion of RTT definition (not used)
> 2) Definition of robustness should include robustness
>    to out-of-order (ooo) delivery
> 3) we suggest to add a whole section on "Operational
>    Characteristics of the RoHC Channel", based on 3095's
>    section 4.2 "Dynamicity" and complementing section
>    "4.2. Operational Characteristics of RoHCv2 Profiles"
>    in draft-pelletier-rohc-rohcv2-profiles-00.txt.
> 4) we suggest to add a section defining the Master Sequence
>    Number (MSN), since all RoHC profiles use a SN as part
>    of their profile-specific definition (in the most simple
>    case to allow the use of feedback, and in the most frequent
>    case to compress some fields that behave sequentially).
> 5) We suggest to include a section that define the concept of
>    "static" and "dynamic" parts of a context.
> 6) We suggest to add to section 5.1.1. a definition of a new context.
> 7) We suggest the addition of an optional parameter to the
>    ROHC channel, for the purpose of quantifying ooo depth.
> 8) We suggest to add to section 5.2 the two type identifiers
>    that are unused by the RoHC framework.
> 9) Add a description of "Payload" field in the general packet   
> format definition. 10) Split section 5.2.1 in smaller sub-sections
> 11) Replaced "MUST be discarded" by "MUST NOT be delieved to
>     upper layers" just about everywhere appropriate.
> 12) Clarify the semantics of ACK, NACK and STATIC-NACK wrt static
>     and dynamic parts of the decompressor context and assumptions    
> of validity. 13) Delete first note in 5.2.3.1
> 14) Added a clear explanation of the purpose/usage of CRC-8, CRC-3
>     and CRC-7 as guideline to profile definitions.
> 15) Include the UNCOMPRESSED profile definition in the framework
>     document. This is motivated by the fact that this profile is a
>     "channel" profile and because its definition does not need to
>     be updated. In other words, this is not a compression profile,
>     it is a channel path for all traffic that is not to be compressed.
> 
> Detailed text proposal for each point above:
> ---------------------------------------------
> 
> 3)
> 
> Operational Characteristics of the RoHC Channel
> 
> Robust header compression can be used over many type 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.
> 
> Multiplexing over a single logical channel
> 
>    The RoHC channel provides a mechanism to identify a context within
>    the general RoHC header format.  The Context Identifier (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 flow without
>    any CID overhead.  More specifically, ROHC uses a distinct context
>    identifier space per logical channel, and the context identifier
>    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 either through a negotiation
>    mechanism, static provisioning or some out-of-band signaling.
> 
> Packet type indication
> 
>    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. This identifier is part
>    of each compressed header.  This makes it possible for the link
>    that supports the RoHC channel to allocate one single packet type 
> for RoHC. 
> 
> Out-of-order delivery between compression endpoints
> 
>    Each profile define its own level of robustness, including against
>    reordering of packets between compression endpoints, if any.
> 
>    The definition of the RoHC channel includes state that is
>    established prior to the first header compressed packet being
>    sent.  It does not in itself make any assumption with respect to
>    the order of the packets that are delivered by the link to the
>    decompressor. However, the channel state can include parameters
>    that characterizes the maximum reordering depth that profiles
>    supporting out-of-order delivery over the RoHC channel may use.
> 
>    For profiles specified in ý[3], the channel between compressor and
>    decompressor is required to maintain in-order delivery of the
>    packets, i.e. the definition of these profiles assume that the
>    decompressor always receives packets in the same order as the
>    compressor sent them.  The impacts of reordering on the
>    performance of these profiles is described in ý[7]. Reordering
>    before the compression point, however, is dealt with, i.e. these
>    profiles make no assumption that the compressor will only receive 
> packets in sequence. 
> 
>    For the RoHv2 profiles specified in ý[8], their definition assume
>    that the decompressor can receive packets out-of-order, i.e. not
>    in the same order as 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.  (Duplication before the compression point, however, is
>    dealt with, 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 are 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 do not deliver ROHC headers
>    with high residual error rates.
> 
> 4)
> 
> 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 an increase of the MSN.
> 
> Change patterns include e.g. fields that increase monotonically or by
> a small value, but also fields that seldom change as well as fields
> that remain unchanging for the entire lifetime of the 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 it then reliably communicates the MSN.  When the change
> pattern of the field does not match the established function, i.e.,
> the existing function gives a result that is different from the field
> in the header to be compressed, additional information is 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 ý[8]), or it can be created and maintained by the compressor (e.g.
> the MSN for compression of UDP in profile 0x0102 ý[8] or the MSN in
> ROHC-TCP ý[9]). 
> 
> 5)
> 
> Static and Dynamic parts of a Context
> 
> A compression context can be conceptually divided in 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.
> 
> 6)
> 
> 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.
> 
> 7)
> 
> MAX_R_DEPTH: Nonnegative integer. Maximum reordering depth expected
>    between the compressor and the decompressor, when the link ´
>    supporting the RoHC channel cannot guarantee in-order delivery. If
>    MAX_R_DEPTH is negotiated to be 0, the channel is assumed not to
>    deliver packets to the decompressor in an order that differs for
>    the order the compressor sent them, per compressed flow (CID).
>    This parameter is optional.
> 
> 8)
> Other packet types can be defined and used by individual profiles:
> 
> 1111101  : available (not reserved by ROHC framework)
> 11111001 : available (not reserved by ROHC framework)
> 
> 9)
> 
> 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. 
> 
> 12)
> 
> ACK         : Acknowledges successful decompression of a packet.
>               Indicates that the decompressor considers its context
>               to be valid up to this packet.
> 
> NACK        : Indicates that the decompressor considers that some or
>               all of the dynamic part of its context is invalid.
> 
> STATIC-NACK : Indicates that the decompressor considers that its
>               entire static context is not valid, or that is  has not
>               been established.
> 
> 14)
> 
> 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 either 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 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. It is
> however 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 header when some or the entire
> decompressor context is assumed invalid.
> --
> 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.

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc