< draft-jonsson-rohc-lla-rtp-00.txt   draft-jonsson-rohc-lla-rtp-01.txt >
Network Working Group Lars-Erik Jonsson, Ericsson Network Working Group Lars-Erik Jonsson, Ericsson
INTERNET-DRAFT Ghyslain Pelletier, Ericsson INTERNET-DRAFT Ghyslain Pelletier, Ericsson
Expires: August 23, 2001 Sweden Expires: January 2002 Sweden
February 23, 2001 July 20, 2001
A Link-Layer Assisted ROHC Profile for IP/UDP/RTP A Link-Layer Assisted ROHC Profile for IP/UDP/RTP
<draft-jonsson-rohc-lla-rtp-00.txt> <draft-jonsson-rohc-lla-rtp-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments This document is an individual submission to the IETF. Comments
should be directed to the authors. should be directed to the authors.
Abstract Abstract
This document defines a ROHC profile for compression of IP/UDP/RTP This document defines a ROHC profile for compression of IP/UDP/RTP
packets, utilizing functionality provided by the lower layer to packets, utilizing functionality provided by the lower layers to
increase compression efficiency by completely eliminating the header increase compression efficiency by completely eliminating the header
for most packets during normal operation. The profile is built as an for most packets during normal operation. The profile is built as an
extension to the ROHC RTP profile [ROHC]. It defines additional extension to the ROHC RTP profile [ROHC]. It defines additional
mechanisms needed in ROHC, states requirements on the lower layer to mechanisms needed in ROHC, states requirements on the lower layer to
guarantee transparency, and specifies general logic for compression guarantee transparency, and specifies general logic for compression
and decompression making use of this header-free packet. and decompression making use of this header-free packet.
Table of contents Table of contents
1. Introduction....................................................3 1. Introduction....................................................3
2. Terminology.....................................................5 2. Terminology.....................................................5
3. Overview of the link-layer assisted profile.....................6 3. Overview of the link-layer assisted profile.....................6
3.1. Providing packet type identification.....................6 3.1. Providing packet type identification.....................6
3.2. Replacing the sequence number............................6 3.2. Replacing the sequence number............................7
3.3. CRC replacement..........................................7 3.3. CRC replacement..........................................7
3.4. Applicability of this profile............................8
4. Additions and exceptions compared to ROHC RTP...................7 4. Additions and exceptions compared to ROHC RTP...................8
4.1. A no-header packet (NHP).................................7 4.1. Additional packet types..................................8
4.2. A context check packet (CCP).............................8 4.1.1. A no-header packet (NHP)........................8
4.3. Interface between compressor and lower layer.............9 4.1.2. A context check packet (CCP)....................8
4.4. Interface between lower layer and decompressor...........9 4.1.3. A context synchronization packet (CSP)..........9
4.5. Periodic context verification...........................10 4.2. Interfaces towards the assisting lower layers...........10
4.6. Feedback option RHP-REQUEST.............................10 4.2.1. Interface between compressor and lower layer...11
4.7. Use of context identifiers..............................10 4.2.2. Interface between lower layer and decompressor.12
4.3. Agreement on optimistic approach........................12
4.4. Feedback option RHP-REQUEST.............................13
4.5. Periodic context verification...........................13
4.6. Use of context identifiers..............................13
5. Implementation issues..........................................10 5. Implementation issues..........................................14
5.1. Implementation parameters and signals...................11 5.1. Implementation parameters and signals...................14
5.1.1. Implementation parameters at compressor........11 5.1.1. Implementation parameters at compressor........14
5.1.2. Implementation parameters at decompressor......12 5.1.2. Implementation parameters at decompressor......15
5.2. Implementation structures...............................13 5.2. Implementation structures...............................16
5.2.1. Compressor context.............................13 5.2.1. Compressor context.............................16
5.2.2. Decompressor context...........................13 5.2.2. Decompressor context...........................16
5.3. Implementation over various link technologies...........13 5.3. Implementation over various link technologies...........16
6. IANA considerations............................................13 6. IANA considerations............................................17
7. Security considerations........................................14 7. Security considerations........................................17
8. Acknowledgements...............................................14 8. Acknowledgements...............................................17
9. References.....................................................14 9. References.....................................................17
10. Authors addresses..............................................15 10. Authors addresses..............................................18
1. Introduction 1. Introduction
Header compression is a technique used to compress and transparently Header compression is a technique used to compress and transparently
decompress the header information of a packet on a per-hop basis, decompress the header information of a packet on a per-hop basis,
utilizing redundancy within individual packets and between utilizing redundancy within individual packets and between
consecutive packets within a packet stream. Over the years, several consecutive packets within a packet stream. Over the years, several
protocols [VJHC, IPHC] have been developed to compress the network protocols [VJHC, IPHC] have been developed to compress the network
and transport protocol headers [IP, IPv6, UDP, TCP] and these schemes and transport protocol headers [IP, IPv6, UDP, TCP] and these schemes
have been successful at improving efficiency over many wired have been successful at improving efficiency over many wired
skipping to change at page 3, line 39 skipping to change at page 3, line 39
links such as the 3rd generation cellular links and header links such as the 3rd generation cellular links and header
compression must therefore tolerate packet loss. However, with the compression must therefore tolerate packet loss. However, with the
previously mentioned schemes, especially for real-time traffic previously mentioned schemes, especially for real-time traffic
compressed by CRTP, high error rates have been shown to significantly compressed by CRTP, high error rates have been shown to significantly
reduce header compression performance [CRTPC]. This problem was the reduce header compression performance [CRTPC]. This problem was the
driving force for the creation of the RObust Header Compression driving force for the creation of the RObust Header Compression
(ROHC) WG in the IETF. (ROHC) WG in the IETF.
The ROHC WG has developed a header compression framework on top of The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets, or which various profiles can be defined for different protocol sets, or
for different compression strategies. Because of the packet loss for different compression strategies. Due to the packet loss
robustness problems of CRTP and the demands of the cellular industry robustness problems of CRTP and the demands of the cellular industry
for an efficient way of transporting voice over IP over wireless, the 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 main focus of ROHC has so far been on compression of IP/UDP/RTP
headers, which are generous in size, especially compared to the headers, which are generous in size, especially compared to the
payloads often carried by the packets with these headers. payloads often carried by the packets with these headers.
ROHC RTP has become a very efficient, robust and capable compression ROHC RTP has become a very efficient, robust and capable compression
scheme, able to compress the headers down to a total size of one scheme, able to compress the headers down to a total size of one
octet only. Also, transparency is guaranteed to an extremely high octet only. Also, transparency is guaranteed to an extremely high
extent even when residual bit errors are present in compressed extent even when residual bit errors are present in compressed
headers delivered to the decompressor. The requirements for RTP headers delivered to the decompressor. The requirements for RTP
compression [RTP-REQ], defined by the WG before and during the compression [RTP-REQ], defined by the WG before and during the
development process, has thus been fulfilled. development process, has thus been fulfilled.
As mentioned above, the 3rd generation cellular systems, where IP As mentioned above, the 3rd generation cellular systems, where IP
will be used end-to-end, has been one of the driving forces for ROHC will be used end-to-end, has been one of the driving forces for ROHC
RTP and the scheme has been designed to also suit new cellular air RTP and the scheme has been designed to also suit new cellular air
interfaces, such as WCDMA, making even speech services possible with interfaces, such as WCDMA, making even speech services possible with
an insignificantly lower spectrum efficiency than with existing one- an insignificantly lower spectrum efficiency than with existing one-
service circuit switched solutions. However, other existing air service circuit switched solutions [VTC2000]. However, other existing
interfaces such as GSM and IS-95 will be used in all-IP networks, air interfaces such as GSM and IS-95 will be used in all-IP networks,
adding new implications to the header compression issue. These air adding new implications to the header compression issue. These air
interfaces are less flexible with radio bearers optimized for interfaces are less flexible with radio bearers optimized for
specific payload sizes. This means that not even a single octet of specific payload sizes. This means that not even a single octet of
header can be added without using the next higher fixed packet size header can be added without using the next higher fixed packet size
of the link and this is obviously very costly. For the already of the link and that is obviously very costly. For the already
deployed speech vocoders, the spectrum efficiency over these links deployed speech vocoders, the spectrum efficiency over these links
will thus be low compared to the existing circuit switched solutions. will thus be low compared to the existing circuit switched solutions.
To achieve high spectrum efficiency overall with any application, To achieve high spectrum efficiency overall with any application,
more flexible air interfaces must be deployed and then the ROHC RTP more flexible air interfaces must be deployed and then the ROHC RTP
scheme will be excellent, as shown for WCDMA. For deployment reasons, scheme will be excellent, as shown for WCDMA [MOMUC01]. For
it is however important to also achieve efficiency with already deployment reasons, it is however important to also achieve
existing vocoders and air interfaces, such as GSM and IS-95, with efficiency with already existing vocoders and air interfaces, such as
minimal effects on spectral efficiency. GSM and IS-95, with minimal effects on spectral efficiency.
This document defines a new link-layer assisted ROHC RTP profile This document defines a new link-layer assisted ROHC RTP profile
extending the ROHC RTP profile in [ROHC] (profile number 1). The extending the ROHC RTP profile in [ROHC] (profile number 1). The
purpose of this new profile is to provide a header free packet format purpose of this new profile is to provide a header free packet format
that, for a certain application behavior, can replace a majority of that, for a certain application behavior, can replace a majority of
the regular 1-octet header ROHC RTP packets during normal operation, the regular 1-octet header ROHC RTP packets during normal operation,
while still being fully transparent and comply with all the while still being fully transparent and comply with all the
requirements of ROHC RTP [RTP-REQ]. For other applications, requirements of ROHC RTP [RTP-REQ]. For other applications,
compression will be carried out as with normal ROHC RTP. To compression will be carried out as with normal ROHC RTP. To
completely eliminate the header, all functionality normally provided completely eliminate the header, all functionality normally provided
skipping to change at page 5, line 13 skipping to change at page 5, line 13
profile on top of various link technologies. profile on top of various link technologies.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
CCP Context Check Packet CCP Context Check Packet
CRC Cyclic Redundancy Check CRC Cyclic Redundancy Check
CSP Context Synchronization Packet
LL Link Layer LL Link Layer
LLA Link Layer Assisted ROHC RTP Profile
MSB Most Significant Bit MSB Most Significant Bit
NHP No Header Packet NHP No Header Packet
ROHC Robust Header Compression ROHC Robust Header Compression
RHP ROHC Header Packet (either a CCP or a RRP packet) RHP ROHC Header Packet (a non-NHP packet, i.e. RRP, CSP or CCP)
RRP ROHC RTP Packet as defined in [ROHC, profile 1] RRP ROHC RTP Packet as defined in [ROHC, profile 1]
Link layer Link layer
Link layer in this document refers to the physical link layer. Link layer in this document refers to the physical link layer.
Lower layer Lower layer
Lower layer in this document refers to any entity implementing the Lower layer in this document refers to any entity implementing the
interface to ROHC as defined in section 4.3 and 4.4. It may, as an interface to ROHC as defined in section 4.2. It may, as an
example, refer to a sub-layer between the ROHC implementation and example, refer to a sub-layer between the ROHC implementation and
the physical link layer used to adapt both implementations. the physical link layer used to adapt both implementations.
ROHC RTP ROHC RTP
ROHC RTP in this document refers to the IP/UDP/RTP profile as ROHC RTP in this document refers to the IP/UDP/RTP profile as
defined in [ROHC]. defined in [ROHC].
3. Overview of the link-layer assisted profile 3. Overview of the link-layer assisted profile
This ROHC IP/UDP/RTP profile is designed to be used over channels This ROHC IP/UDP/RTP profile is designed to be used over channels
that have been optimized for specific payload sizes and therefore that have been optimized for specific payload sizes and therefore
cannot efficiently accommodate header information to be transmitted cannot efficiently accommodate header information to be transmitted
together with payloads corresponding to these optimal sizes. together with payloads corresponding to these optimal sizes.
The profile extends, thus also inherits all functionality from, the The LLA profile extends, thus also inherits all functionality from,
ROCH RTP profile by defining some additional functionality and an the ROCH RTP profile by defining some additional functionality and an
interface between the ROHC component towards the lower layer. By interface between the ROHC component towards the lower layer.
putting additional requirements on the lower layer compared to [RTP-
LLG], it is possible for ROHC to infer the information needed to +---------------------------------------+
| |
| |
The LLA ROHC | ROHC RTP, +-----------------+
profile | Profile #1 | |
| | LLA Additions |
| | |
+---------------------+-----------------+
By putting additional requirements on the lower layer compared to
[RTP-LLG], it is possible for ROHC to infer the information needed to
maintain robust and transparent header compression even though the maintain robust and transparent header compression even though the
headers are completely eliminated during most of the operation time. headers are completely eliminated during most of the operation time.
Basically, what this profile does is to replace the smallest ROHC Basically, what this profile does is to replace the smallest ROHC
header of one octet with a no-header format by providing the header header of one octet with a no-header format by providing the header
functionality by other means. The fields present in the one octet functionality by other means.
ROHC RTP header for PT0 are the packet type identifier, the sequence
number and the CRC (optional in PT0 for Reliable mode). The Smallest header in Smallest header in
subsequent sections elaborate more on the replacement of the ROHC RTP (profile #1) LLA ROHC RTP profile
functionality of these fields. +--+--+--+--+--+--+--+--+ ++
| 1 octet | -----> || No Header
+--+--+--+--+--+--+--+--+ ++
|
| Header field functionality
+-------------------> provided by other means
The fields present in the one octet ROHC RTP header for PT0 are the
packet type identifier, the sequence number and the CRC (optional in
PT0 for Reliable mode). The subsequent sections elaborate more on the
replacement of the functionality of these fields.
3.1. Providing packet type identification 3.1. Providing packet type identification
All ROHC headers carry a packet type identifier, indicating to the All ROHC headers carry a packet type identifier, indicating to the
decompressor which context the compressed packet belongs to and how decompressor which context the compressed packet belongs to and how
it should be interpreted. This is a functionality that must be it should be interpreted. This is a functionality that must be
provided by some means. ROHC RTP packets with header will still be provided by some means. ROHC RTP packets with header will still be
possible to distinguish between since they have this identifier, but possible to distinguish between since they have this identifier, but
what must be provided is a mechanism to separate those packets with what must be provided is a mechanism to separate those packets with
header from the packets without header. This functionality MUST header from the packets without header. This functionality MUST
skipping to change at page 7, line 19 skipping to change at page 7, line 38
All RRP packets carry a CRC calculated over the uncompressed header All RRP packets carry a CRC calculated over the uncompressed header
(optional in PT0 for Reliable mode). This CRC is used by the (optional in PT0 for Reliable mode). This CRC is used by the
decompressor to verify that the decompressed header is correct. This decompressor to verify that the decompressed header is correct. This
verification serves three purposes: verification serves three purposes:
- Detection of longer losses than can be covered by the sequence - Detection of longer losses than can be covered by the sequence
number LSBs (this applies to Unidirectional and Optimistic mode) number LSBs (this applies to Unidirectional and Optimistic mode)
- Protection against failures caused by residual bit errors in the - Protection against failures caused by residual bit errors in the
compressed header compressed header
- Protection against faulty implementations or other causes of error - Protection against faulty implementations or other causes of error
Since this profile defines a NHP packet without this CRC, care must Since this profile defines a NHP packet without this CRC, care must
be taken to fulfill these purposes by other means. Detection of long be taken to fulfill these purposes by other means. Detection of long
losses is already covered since the lower layer MUST provide losses is already covered since the lower layer MUST provide
indication of all packet losses. Furthermore, the NHP packet has one indication of all packet losses. Furthermore, the NHP packet has one
important advantage compared to RHP packets because residual bit important advantage compared to RHP packets because residual bit
errors can not damage a header that is not even sent. It is thus errors can not damage a header that is not even sent. It is thus
reasonable to assume that compression and decompression transparency reasonable to assume that compression and decompression transparency
can be guaranteed even without a CRC in header-free packets. However, can be guaranteed even without a CRC in header-free packets. However,
to detect also unexpected errors and thereby provide transparency in to detect also unexpected errors and thereby provide transparency in
the ROHC class, periodical context checks SHOULD be performed. the ROHC class, periodical context checks SHOULD be performed.
3.4. Applicability of this profile
The LLA profile can be used on any link technology capable of
providing the necessary required functionality described in previous
sections. Whether LLA ROHC RTP or ROHC RTP profile #1 should be
implemented thus depends on the characteristics of the link itself.
For most RTP packet streams, LLA will work exactly as profile #1,
while it will be more efficient for packet streams with certain
characteristics. LLA will never be less efficient than ROHC RTP
profile #1.
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 produce
optimal performance for packet streams with certain characteristics,
e.g. synchronized streams exactly matching the timing of the
assisting link over which the LLA profile is implemented.
4. Additions and exceptions compared to ROHC RTP 4. Additions and exceptions compared to ROHC RTP
4.1. A no-header packet (NHP) 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. A no-header packet (NHP)
A no-header packet (NHP), thus a packet consisting only of a payload, A no-header packet (NHP), thus a packet consisting only of a payload,
is defined and MAY be used instead of ROHC RTP packet type 0 (PT0) is defined and MAY be used instead of ROHC RTP packet type 0 (PT0)
when the sequence number has incremented with one from the previous when the sequence number has incremented with one from the previous
packet. Note that the requirement for using PT0 in the first place is packet. Note that the requirement for using PT0 in the first place is
basically that all header fields must be unchanged or follow the basically that all header fields must be unchanged or follow the
currently established change pattern. In addition, there are some currently established change pattern. In addition, there are some
cases when NHP should not be used (see section 4.5). restrictions on when NHP should be used (see section 4.4 and 4.5).
Note that since the lower layer is responsible of separating NHP Note that since the lower layer is responsible of separating NHP
packets from RHP packets, an indicated from the compressor to the packets from RHP packets, an indication from the compressor to the
lower layer MUST be provided upon delivery of an NHP packet. lower layer MUST be provided upon delivery of an NHP packet.
4.2. A context check packet (CCP) 4.1.2. A context check packet (CCP)
A Context Check Packet (CCP) is defined, which does not carry any A Context Check Packet (CCP), which does not carry any payload but
payload but, in addition to the packet type identifier, only a CRC only a CRC value in addition to the packet type identifier, is
value. A CCP packet MAY be created by the compressor in addition to defined. The CCP packet MAY be created by the compressor in addition
the compressed packet and provided to the lower layer. Whether the to the compressed packet and provided to the lower layer. Whether the
packet is sent over the link and delivered to the decompressor is not packet is sent over the link and delivered to the decompressor is not
decided by the compressor, but by the lower layer. The purpose of decided by the compressor, but by the lower layer.
this packet is to provide a useful packet that MAY be sent by a
synchronized physical link layer in the case when it must send The purpose of the CCP is to provide a useful packet that MAY be sent
something on a regular basis, even if no compressed packet is by a synchronized physical link layer in the case where data must be
available. This is the format of the CCP packet: sent at fixed intervals, even if no compressed packet is available.
The CCP has the following format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 1 | Packet type identifier | 1 1 1 1 1 0 0 1 | Packet type identifier
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| R | CRC | | 0 | CRC |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
This packet is defined by one of the unused packet type identifiers This packet is defined by one of the unused packet type identifiers
from ROHC RTP, carried in the first octet of the packet. As for any from ROHC RTP, carried in the first octet of the packet, and the
ROHC packet, except NHP, the packet MAY begin with ROHC padding first bit of the following octet being set to 0. As for any ROHC
and/or carry context identification. The (R)eserved bit MUST be set packet, except NHP, the packet MAY begin with ROHC padding and/or
to 0 in all CCP packets. The CRC is the 7-bits CRC over the original carry context identification. The CRC is the 7-bits CRC over the
uncompressed header as described in [ROHC section 5.9.2]. original uncompressed header as described in [ROHC section 5.9.2].
If the lower layer implementation makes use of the CCP feature, the If the lower layer implementation makes use of the CCP feature, the
last CCP packet received from the compressor MUST always be used, last CCP packet received from the compressor MUST always be used,
i.e. the CCP corresponding to the last data packet sent (NHP or RRP). i.e. the CCP corresponding to the last data packet sent (NHP or RRP).
Accordingly, if a CCP packet is received by the decompressor, it MUST Accordingly, if a CCP packet is received by the decompressor, it MUST
be used as a context verification for the last packet decompressed be used as a context verification for the last packet decompressed
unless a packet loss indication was previously received. To unless a packet loss indication was previously received. The 7-bit
facilitate this verification, the 7-bit CRC MUST always be calculated CRC MUST always be calculated for all decompressed packets and saved
for all decompressed packets and saved in the decompressor context in in the decompressor context in order to use the CCP. Upon CRC
order to use the CCP. Upon CRC failure, actions MUST be taken as failure, actions MUST be taken as specified in [ROHC, section
specified in [ROHC, section 5.3.2.2.3]. 5.3.2.2.3].
Note that the usage of CCP is optional, depending on the link layer Note that the usage of CCP is optional and depends on the
this profile is implemented over. Whether it is used or not MUST characteristics of the actual link. Whether it is used or not MUST
therefore be specified in the link layer implementation therefore be specified in the link layer implementation
specifications for this profile. specifications for this profile.
4.3. Interface between compressor and the lower layer 4.1.3. A context synchronization packet (CSP)
The CCP packet can be used to ensure correctness of the decompressor
context, but when this verification fails a request must be sent to
get an update. All packets must then be discarded until the proper
context is re-established.
However, it would in many cases be beneficial to send not only the
header verifying CRC of the previous packet but also the header
itself without its associated payload. This would allow not only to
perform a context verification but also to provide a context repair
mechanism.
Another situation when it could be useful to send a packet with only
the header information is when the packet stream overruns the channel
bandwidth and data must be discarded. Instead of discarding the whole
packet at the compressor side, which would mean that the decompressor
context might be invalidated, only the payload could be discarded and
the header sent to keep the decompressor context synchronized while
still saving bandwidth.
Both cases above 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 0 1 | Packet type identifier
+---+---+---+---+---+---+---+---+
| 1 | CRC |
+---+---+---+---+---+---+---+---+
: ROHC header without padding :
: or context identification :
+---+---+---+---+---+---+---+---+
The CSP packet is identified using the same packet type identifier as
the CCP packet with the first bit of the second octet being set to 1,
and it uses the same CRC. The first two octets of the CSP packet are
thus identical to the CCP packet, except for the first bit of the
second octet being set to 1 instead of 0. As for any ROHC packet,
except NHP, the packet MAY begin with ROHC padding and/or carry
context identification.
The difference of the CSP from the CCP packet is the presence of a
compressed ROHC header that can be used to synchronize the
decompressor context. Note that when the decompressor has received a
CSP packet and updated the context accordingly, the packet including
any possible data following the CSP encapsulated compressed header
MUST be discarded.
4.2. Interfaces towards the assisting lower layers
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 lower layers is defined as interfaces between the
ROHC LLA compressor/decompressor elements and the LLA applicable link
technology. The figure below shows the various levels, as defined in
[ROHC] and this document, making up for a complete implementation of
the LLA profile.
| |
+ +
+---------------------+ +---------------------+
| ROHC RTP HC | | ROHC RTP HD |
+---------------------+ +---------------------+
| LLA profile | | LLA profile |
+=====================+ +=====================+
| ROHC to lower layer | | Lower layer to ROHC |
| interface | | interface |
+=====================+ +=====================+
| Applicable | | Applicable |
| link technology | | link technology |
+=====================+ +=====================+
| |
+------>---- CHANNEL ---->-----+
The figure also underline the need for additional standards-track
documents to specify how to fulfill these interfaces for a link
technology for which this profile is relevant.
4.2.1. Interface between compressor and lower layer
This section defines the interface semantics between the compressor This section defines the interface semantics between the compressor
and the lower layer, providing rules for packet delivery from the and the lower layer, providing rules for packet delivery from the
compressor. compressor.
+-----------+-----+-----+-----+-----+-----+-----+-----+ +------------------+-----+-----+-----+-----+-----+-----+-----+
| Interface | RRP | Seg | NHP | CCP | Seq | Seg | NHP | | \ Interface | RRP | Seg | NHP | CCP | Seq | Seg | NHP |
| Parameter | | RRP | | | Num | Flg | Flg | | Case \ Parameter | | RRP | | | Num | Flg | Flg |
+-----------+-----+-----+-----+-----+-----+-----+-----+ +------------------+-----+-----+-----+-----+-----+-----+-----+
| Case 1 | x | | x | x | x | | x | | 1 - NHP, No Seg. | x | | x | x | x | | x |
+-----------+-----+-----+-----+-----+-----+-----+-----+ +------------------+-----+-----+-----+-----+-----+-----+-----+
| Case 2 | | x | x | x | x | x | x | | 2 - NHP, Seg. | | x | x | x | x | x | x |
+-----------+-----+-----+-----+-----+-----+-----+-----+ +------------------+-----+-----+-----+-----+-----+-----+-----+
| Case 3 | x | | | x | | | | | 3 - No Seg. | x | | | x | x | | |
+-----------+-----+-----+-----+-----+-----+-----+-----+ +------------------+-----+-----+-----+-----+-----+-----+-----+
| Case 4 | | x | | x | | x | | | 4 - Seg. | | x | | x | x | x | |
+-----------+-----+-----+-----+-----+-----+-----+-----+ +------------------+-----+-----+-----+-----+-----+-----+-----+
Table 1: Data delivery from the compressor Table 1: Data delivery from the compressor
As seen in table 1, four different delivery scenarios are possible. As seen in table 1, four different delivery scenarios are possible.
Case 1 represent what needs to be delivered when the compressor Case 1 represent what needs to be delivered from compressor to lower
allows sending of an NHP packet, without any segmentation applied to layers when the compressor allows sending of an NHP packet, without
the corresponding RRP packet. Case 2 differs from case 1 in that a any segmentation applied to the corresponding RRP packet. Case 2
segmented RRP is being delivered. Case 3 and case 4 shows the case differs from case 1 in that a segmented RRP is being delivered. Case
where a packet without header cannot be delivered. 3 and case 4 are the cases where a packet without header cannot be
delivered.
If the compressor delivers a NHP packet to the lower layer, it MUST If the compressor delivers a NHP packet to the lower layer, it MUST
also provide the RRP packet, a CCP packet, the Sequence Number and also provide the RRP packet, a CCP packet, the Sequence Number and
the indication that a NHP packet MAY be used. Otherwise the RRP the indication that a NHP packet MAY be used. Otherwise the RRP
packet MUST be delivered together with a CCP packet. packet MUST be delivered together with a CCP packet.
Furthermore, for the case where the RRP packet is delivered to the Furthermore, for the case where the RRP packet is delivered to the
lower layer as a segmented ROHC packet according to the rules in lower layer as a segmented ROHC packet according to the rules in
chapter 5.5.1, an indication MUST be provided by the compressor. chapter 5.5.1, an indication MUST be provided by the compressor.
4.4. Interface between lower layer and decompressor 4.2.2. Interface between lower layer and decompressor
The interface semantics between the lower layer and the decompressor The interface semantics between the lower layer and the decompressor
are defined here, and provide simple rules for the delivery of are defined here, and provide simple rules for the delivery of
received packets to the decompressor. The decompressor needs a way to received packets to the decompressor. The decompressor needs a way to
identify NHP packets from RHP packets. Also, when receiving packets identify NHP packets from RHP packets. Also, when receiving packets
without headers, the decompressor needs a way to infer the sequencing without headers, the decompressor needs a way to infer the sequencing
information to keep synchronization between received payload and the information to keep synchronization between received payload and the
sequence information of the decompressed headers. To achieve this, sequence information of the decompressed headers. To achieve this,
the lower layer MUST provide the following to the decompressor: the lower layer MUST provide the following to the decompressor:
- an indication of packet loss - an indication of packet loss
- the received packets together with a indication whether the packet - the received packets together with a indication whether the packet
received is an NHP or not received is an NHP or not
4.3. Agreement on optimistic approach
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, but it may also be partially used
in the Reliable mode. 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 check.
However, with the LLA profile the CRC is not present in the NHP
packet and therefore the loss of an RHP packet updating the context
may not always be detected. To avoid this problem, the compressor and
decompressor must agree on the principles for the optimistic
approach. If, for example, the compressor sends three consecutive
updates to convey a header field change, the decompressor must know
this and invalidate the context in case of three or more consecutive
packet losses.
It is REQUIRED that all documents describing how the LLA profile is
implemented over a certain link technology MUST define how the
optimistic approach is agreed between compressor and decompressor. It
could be with a fixed principle, negotiation at startup or by other
means but it must be unambiguously defined.
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 a
context synchronization event has happened.
4.4. Feedback option, RHP-REQUEST
The RHP-REQUEST option could be used by the decompressor to request
an RHP for context verification. This option should be used if only
NHP have been received for a long time and the context therefore has
not been verified recently. If the compressor receives a feedback
packet with this option, at least one RRP with CRC SHOULD be sent
immediately.
+---+---+---+---+---+---+---+---+
| Opt Type = 8 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
4.5. Periodic context verification 4.5. Periodic context verification
As described in chapter 3.3, transparency is expected to be As described in chapter 3.3, transparency is expected to be
guaranteed by the functionality provided by the lower layer. This guaranteed by the functionality provided by the lower layer. This
ROHC profile would therefore be at least as reliable as the older ROHC profile would therefore be at least as reliable as the older
header compression schemes [VJHC, IPHC, CRTP], which do not make use header compression schemes [VJHC, IPHC, CRTP], which do not make use
of a header compression CRC. However, since ROHC RTP normally is of a header compression CRC. However, since ROHC RTP normally is
extremely safe to use from a transparency point of view, it would be extremely safe to use from a transparency point of view, it would be
desirable if that also could be achieved with this profile. To desirable if that also could be achieved with this profile. To
provide an additional guarantee for transparency and also catch non provide an additional guarantee for transparency and also catch non
expected errors, such as errors due to faulty implementations, it is expected errors, such as errors due to faulty implementations, it is
RECOMMENDED that RRP packets (with the CRC present also for Reliable RECOMMENDED that RRP packets (with the CRC present also for Reliable
mode PT0 packets) be sent periodically, even when the normal logic mode PT0 packets) be sent periodically (possibly with an increasing
allows for NHP packets to be used. period), even when the normal logic allows for NHP packets to be
used.
Since a CCP packet serves the same purpose as a regular periodic Since a CCP packet serves the same purpose as a regular periodic
verification with RRP, indication of CCP transmission is beneficial verification with RRP, indication of CCP transmission is beneficial
for the compressor, which can ignore some periodic RRP verifications. to the compressor, which can ignore some periodic RRP verifications.
4.6. Feedback option, RHP-REQUEST
The RHP-REQUEST option could be used by the decompressor to request
an RHP for context verification. This option should be used if only
NHP have been received for a long time and the context therefore has
not been verified recently. If the compressor receives a feedback
packet with this option, at least one RRP with CRC SHOULD be sent
immediately.
+---+---+---+---+---+---+---+---+
| Opt Type = 8 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
4.7. Use of context identifier 4.6. Use of context identifier
Since a NHP can not carry a context identifier (CID), there is a Since a NHP can not carry a context identifier (CID), there is a
restriction on how this profile may be used, related to context restriction on how this profile may be used, related to context
identification. Independent of which CID size has been negotiated, identification. Independent of which CID size has been negotiated,
NHP packets can only be used for CID=0. If the decompressor receives NHP packets can only be used for CID=0. If the decompressor receives
a NHP packet, it can only belong to CID=0. a NHP packet, it can only belong to CID=0. Note that if multiple
packet streams are handled by a compressor running LLA, the lower
layers MUST in case of packet loss be able to tell for which CID the
loss occurred, at least it must be able to tell if packets with CID 0
(NHP packet stream) have been lost.
5. Implementation issues 5. Implementation issues
This document specifies mechanisms for the protocol and leaves This document specifies mechanisms for the protocol and leaves
details on the use of these mechanisms to the implementers. This details on the use of these mechanisms to the implementers. This
chapter aims to provide guidelines, ideas and suggestions for chapter aims to provide guidelines, ideas and suggestions for
implementation of this profile. implementation of this profile.
5.1. Implementation parameters and signals 5.1. Implementation parameters and signals
skipping to change at page 14, line 20 skipping to change at page 17, line 28
onto the link using random CRC values, the CRC check will fail for onto the link using random CRC values, the CRC check will fail for
incorrect reasons at the decompressor side. This would obviously incorrect reasons at the decompressor side. This would obviously
greatly reduce the advantages of ROHC and any extra efficiency greatly reduce the advantages of ROHC and any extra efficiency
provided by this profile due to unnecessary context invalidation, provided by this profile due to unnecessary context invalidation,
feedback messages and refresh packets. However, the same remarks feedback messages and refresh packets. However, the same remarks
related to the presence of such an intruder applies. related to the presence of such an intruder applies.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Ulises Olvera-Hernandez and Francis The authors would like to thank Ulises Olvera-Hernandez and Francis
Lupien for valuable inputs. Lupien for valuable inputs about the typical links that LLA can be
applied to. Thanks also to Mikael Degermark and Zhigang Liu for
fruitful discussions that led to improvements of this profile.
9. References 9. References
[ROHC] C. Bormann, "Robust Header Compression (ROHC)", Internet [ROHC] C. Bormann, "Robust Header Compression (ROHC)",
draft (work in progress), February 2001. RFC 3095, July 2001.
<draft-ietf-rohc-rtp-08.txt>
[VJHC] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed [VJHC] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990. Serial Links", RFC 1144, February 1990.
[IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header [IPHC] M. Degermark, B. Nordgren, S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999. for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro, [CRTPC] M. Degermark, H. Hannu, L.-E. Jonsson, K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio "Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communications Magazine, Volume Networks", IEEE Personal Communications Magazine, Volume
7, number 4, pp. 20-25, August 2000. 7, number 4, pp. 20-25, August 2000.
[RTP-REQ] M. Degermark, "Requirements for IP/UDP/RTP Header [RTP-REQ] M. Degermark, "Requirements for IP/UDP/RTP Header
Compression", Internet draft (work in progress), Compression", RFC 3096, July 2001.
February 2001.
<draft-ietf-rohc-rtp-requirements-05.txt>
[RTP-LLG] K. Svanbro, "Lower Layer Guidelines for Robust [RTP-LLG] K. Svanbro, "Lower Layer Guidelines for Robust
RTP/UDP/IP Header Compression", Internet draft (work in RTP/UDP/IP Header Compression", Internet draft (work in
progress), February 2001. progress), February 2001.
<draft-ietf-rohc-rtp-lower-layer-guidelines-01.txt> <draft-ietf-rohc-rtp-lower-layer-guidelines-01.txt>
[IP] J. Postel, "Internet Protocol", RFC 791, September 1981. [IP] J. Postel, "Internet Protocol", RFC 791, September 1981.
[IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
skipping to change at page 15, line 18 skipping to change at page 18, line 28
[UDP] J. Postel, "User Datagram Protocol", RFC 768, August [UDP] J. Postel, "User Datagram Protocol", RFC 768, August
1980. 1980.
[TCP] J. Postel, "Transmission Control Protocol", RFC 793, [TCP] J. Postel, "Transmission Control Protocol", RFC 793,
September 1981. September 1981.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996. RFC 1889, January 1996.
[VTC2000] K. Svanbro, H. Hannu, L.-E. Jonsson, M. Degermark,
"Wireless real time IP-services enabled by header
compression", proceedings of IEEE VTC2000, May 2000.
[MOMUC01] G. Liu, 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.
10. Authors addresses 10. Authors addresses
Lars-Erik Jonsson Tel: +46 920 20 21 07 Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson Erisoft AB Fax: +46 920 20 20 99 Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Box 920
SE-971 28 Lulea SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com Sweden EMail: lars-erik.jonsson@ericsson.com
Ghyslain Pelletier Tel: +46 920 20 24 32 Ghyslain Pelletier Tel: +46 920 20 24 32
Ericsson Erisoft AB Fax: +46 920 20 20 99 Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Box 920
SE-971 28 Lulea SE-971 28 Lulea
Sweden EMail: ghyslain.pelletier@epl.ericsson.se Sweden EMail: ghyslain.pelletier@epl.ericsson.se
This Internet-Draft expires August 23, 2001. This Internet-Draft expires January 20, 2002.
 End of changes. 48 change blocks. 
116 lines changed or deleted 292 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/