TOC 
Network Working GroupTat-Chee. Wan
Internet-DraftWay-Chuang. Ang
Intended status: Standards TrackChee-Hong. Teh
Expires: December 19, 2008Universiti Sains Malaysia
 June 17, 2008


Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames
draft-wan-ipdvb-rohc-01.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 19, 2008.

Abstract

This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC4326 to carry packets compressed with RObust Header Compression (ROHC), RFC 3095 over ULE Stream.


Table of Contents

1.  Introduction
2.  Terminologies
3.  Topology
4.  Encapsulation Format
    4.1.  Encapsulation Format of ULE SNDU within ROHC Channel
    4.2.  ROHC Feedback
5.  Topological Learning
    5.1.  Automatic Learning
6.  Establishing ROHC Channel
    6.1.  ROHC Channel Parameters Negotiation Protocol (RCPNP)
        6.1.1.  Compressor Advertisement
        6.1.2.  Compressor Solicitation
        6.1.3.  Request
        6.1.4.  Reply
        6.1.5.  Acknowledgement
        6.1.6.  Negative Acknowledgement
        6.1.7.  Compressor Shutdown
        6.1.8.  Decompressor Shutdown
    6.2.  Interaction of RCPNP
7.  Bidirectional ROHC Channels
8.  IANA Consideration
9.  Acknowledgements
10.  Security Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements



 TOC 

1.  Introduction

Header compression promotes efficient use of available bandwidth. This is more apparent in the case of DVB-S where satellite link is used. This document introduces a method to compress headers of IP packet encapsulated within ULE [RFC4326] (Fairhurst, G. and B. Collini-Nocker, “Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS),” 12 2005.) Stream using ROHC framework [RFC3095] (Borman, C., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” 2001.).

Important concepts of ROHC channel in MPEG2-TS system is introduced to differentiate between normal, uncompressed ULE Stream from ROHC compressed stream. Method to map outgoing packet to a ROHC channel is also presented. For completeness, a protocol to automate the negotiation and setup of parameters for ROHC channel is discussed.

This document doesn't try to address compression of broadcast or multicast traffic for there is no reliable way to handle ROHC feedback from multiple ROHC decompressor. Implementation that wants to enable ROHC compression for broadcast or multicast traffic must ensure that all recipient gateways are capable of decompressing ROHC packet and that all contexts for broadcast and multicast traffic must operate in unidirectional mode.


 TOC 

2.  Terminologies

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Compressor Gateway
Gateway that is capable of compressing header of IP packets using ROHC.
Decompressor Gateway
Machine that can perform ROHC decompression.
DVB
Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO‑MPEG2] (ISO 13818-1, “Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems,” 2000.).
Gateway
Machine that can either host ROHC compressors and ROHC decompressors.
MAC
Medium Access Control [IEEE‑802.3] (IEEE 802.3, “Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications,” 2000.). A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX] (Digital Equipment Corp, Intel Corp, Xerox Corp, “Ethernet Local Area Network Specification Version 2.0,” November 1982.)).
MPEG-2
A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO‑MPEG2] (ISO 13818-1, “Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems,” 2000.), and ITU-T (in H.222 [ITU‑H222] (H.222.0, “Information technology - Generic coding of moving pictures and associated audio information: Systems, International Telecommunication Union, (ITU-T),” 1995.)).
PDU
Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
ROHC
Robust Header Compression. A framework to compress header of IP packets as defined in [RFC3095] (Borman, C., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” 2001.).
ROHC channel
A logical unidirectional point-to-point channel carrying ROHC compressed packets from one compressor to one decompressor.
ROHC profile
Specification of how to compress the headers of a certain kind of packet stream as defined by [RFC3095] (Borman, C., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” 2001.)
SNDU
SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
TS
Transport stream (TS) is a format specified in MPEG-2 Part 1, Systems (ISO/IEC standard 13818-1). Its design goal is to allow multiplexing of digital video and audio and to synchronize the output. Transport stream offers features for error correction for transportation over unreliable media, and is used in broadcast applications such as DVB and ATSC.
ULE Stream
An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Stream may be identified by definition of a stream_type in SI/PSI [ISO‑MPEG2] (ISO 13818-1, “Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems,” 2000.).
MRRU
Maximum Reconstructed Reception Unit as defined in [RFC3095] (Borman, C., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” 2001.).
Context Identifier
[RFC3095] (Borman, C., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” 2001.) provides a definition for context identifiers.
ACK
Positive Acknowledgement.
NACK
Negative acknowledgement.
CID
Context Identifier.
B
Byte. Groups of bytes are represented in Internet byte order.
b
Bit.
Next-Header
A Type value indicating an Extension Header [RFC4326] (Fairhurst, G. and B. Collini-Nocker, “Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS),” 12 2005.).
NPA
Network Point of Attachment [RFC4326]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers.
ULE
Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation defines an extension format and an associated IANA Registry.

In addition, this document also borrows some terminologies defined in section 2 of [RFC3759] (Jonsson, L-E., “RObust Header Compression (ROHC): Terminology and Channel Mapping Examples,” April 2004.). When there is any ambiguity between terminologies defined in other documents and this document, the terminolgies in this document should be consulted to intepret the content of this document.


 TOC 

3.  Topology

Compressor gateways and decompressor gateways are connected through unidirectional links. This document assumes that these unidirectional links carry IP packets within ULE over MPEG2-TS frames. A unidirectional link from a compressor gateway may have multiple decompressor gateways listening to it. The following figure depicts a generic topology of a compressor gateway, Comp1, with 2 decompressor gateways, Decomp 1 and Decomp 2. 



                    unidirectional link
          ^------------->---------->--------->
          |                 |                |
          |                 v                v
     +--------+       +----------+      +----------+
     | Comp 1 |       | Decomp 1 |      | Decomp 2 |
     +--------+       +----------+      +----------+
       ^   ^                |                |
       |   |                |                |
       |   <--------<-------v                |
       |                                     |
       <----------<------------<-------------v
                    unidirectional links
 Figure 1: Generic Topology 

Each decompressor gateway has a dedicated unidirectional link connected to compressor gateway. Each unidirectional link may contain multiple logical channels which is identified by the PID field of MPEG2-TS frame. Of these logical channels, some of these logical channels may be dedicated for traffic of ROHC compressed packets only. While the rest of the logical channels may be used to carry uncompressed packets.

For the purpose of this discussion, the group of logical channels used to carry streams of uncompressed packets are called uncompressed channels. Uncompressed channel is not reserved exclusively between a pair of gateways and may be shared by multiple receiver gateways.

ROHC channel is a logical channel that is used to carry ROHC compressed packet from compressor gateway to decompressor gateway. ROHC channel is exclusive to a pair of compressor gateway and decompressor gateway.

ROHC feedback channel is the logical channel that carries ROHC feedback packet from decompressor gateway to compressor gateway. This channel is optional. This channel may be shared by co-located compressor at the decompressor gateway to send ROHC compressed packet. When used in this manner, ROHC feedback channel of decompressor and ROHC channel of co-located compressor at the decompressor gateway share the same logical channel.

However, in the absence of co-located compressor at the decompressor gateway, ROHC feedback doesn't necessitate a dedicated logical channel as it can be sent via uncompressed channel in the encapsulation format depicted in Figure 6 (Format of ROHC feedback encapsulated within ULE SNDU). As such, ROHC feedback channel is not an exclusive channel and may be a part uncompressed channel or ROHC channel.

Figure 2 (Topology of Logical Channels) depicts a possible combination of logical channels for the topology shown in Figure 1 (Generic Topology). The following topology assumes that there is no co-located compressor at both decompressor gateways and ROHC feedbacks are sent back through uncompressed channel. 



                        uncompressed channel
          ^--------->---------->--------->---------->
          |                    |                    |
          |                    |  ROHC channel      |
       ^--+------>--------->---+---->-------->      |
       |  |                    |             |      |
       |  ^   ROHC channel     v             |      v
       |  |  ^----->------>    |             |      |
       |  |  |            |    |             |      |
       |  |  |            v    v             v      v
     +----------+       +------------+      +------------+
     |  Comp 1  |       |  Decomp 1  |      |  Decomp 2  |
     +----------+       +------------+      +------------+
        ^   ^                      |              |
        |   | uncompressed channel |              |
        |   <--------<------<------v              |
        |                                         |
        |                uncompressed channel     |
        <------<------<-----<-------<------<------v
 Figure 2: Topology of Logical Channels 

To get a better understanding of the terminologies used in subsequent sections, Figure 3 (Topology of Gateways with Pairs of ROHC peers) depicts a topology of 2 gateways with both compressor and decompressor. Comp 1 is the compressor for Gateway 1 whereas Decomp 1 is the decompressor for Gateway 1. So is Comp 2 and Decomp 2 for Gateway 2. Comp 1 and Decomp 1 are co-located and associated. The arrow sign from Decomp 1 to Comp 1 means that ROHC feedback is being forwarded from Decomp 1 to Comp 1. Decomp 2 is the corresponding decompressor of compressor Comp 1. ROHC feedback from Decomp 2 can be sent back to Comp 1 through ROHC channel established between Comp 2 and Decomp 1. 



                        uncompressed channel
        ^------->------->-------->--------->-------->
        |                         ROHC channel      |
        |               ^------->------>------>-----+-->------>
        |               |                           |         |
        |               |                           v         |
   +--------------------+--------+      +------------------------------+
   |                    |        |      |                     |        |
   |                    |        |      |                     v        |
   |             +------------+  |      |              +------------+  |
   |             |   Comp 1   |  |      |              |  Decomp 2  |  |
   |             +------------+  |      |              +------------+  |
   |  Gateway 1         ^        |      |  Gateway 2          |        |
   |                    |        |      |                     v        |
   |             +------------+  |      |              +------------+  |
   |             |  Decomp 1  |  |      |              |   Comp 2   |  |
   |             +------------+  |      |              +------------+  |
   |                    ^        |      |                     |        |
   |                    |        |      |                     |        |
   +-----------------------------+      +---------------------+--------+
         ^              |        ROHC channel       |         |
         |              <--------<--------<---------+--<------v
         |             uncompressed channel         |
         <--------<-------<--------<--------<-------v
 Figure 3: Topology of Gateways with Pairs of ROHC peers 

 TOC 

4.  Encapsulation Format

This section briefly describes the notation used in all diagrams. "=" in the following diagrams indicates the number of octets taken by the indicated field is not presented in a precise manner. This situation appears when a field spans variable number of bytes.


 TOC 

4.1.  Encapsulation Format of ULE SNDU within ROHC Channel

All ULE SNDUs sent within ROHC channel have their payload compressed using ROHC. ULE Type field of these packets are the same as their counterparts in uncompressed channel. For instance, IPv4 PDUs compressed with ROHC will still have ULE type of 0x800. Likewise, compressed IPv6 PDUs will have ULE type of 0x86dd. Figure 4 (Packet Format of Compressed IPv6 PDU) depicts the format of ULE SNDU with compressed IPv6 PDU. 



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|        Length  (15b)        |         Type = 0x86dd         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Receiver Destination NPA Address* (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                        Compressed IPv6 PDU                    |
      =                                                               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            CRC-32                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 4: Packet Format of Compressed IPv6 PDU 

The semantics of D-bit, Length, Type, Receiver Destination NPA Address and CRC-32 fields are defined in section 4 of [RFC4326] (Fairhurst, G. and B. Collini-Nocker, “Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS),” 12 2005.) except for the PDU. If the decompressed PDU doesn't yield the same PDU type as defined in Type field, the PDU should treated as corrupted and be discarded. Thus, in the case where Type field is 0x800, ROHC decompressor should discard the packet if it yields an IPv6 PDU after decompression.

The same concept applies for compressed bridge frame PDUs. However, the Ethernet header is left untouch. Only the headers after the Ethernet frame header are compressed. Decompressed payload should result in payload of the type indicated in the EtherType field. If not, the frame should be discarded. Figure 5 (ROHC Compressed Packet Encapsulated within SNDU Bridged Frame) depicts the format of compressed SNDU bridged frame. Any padding bytes carried within content of original bridged MAC frame to fulfill the minimum Ethernet frame size should be stripped off before compression and should not be present within ROHC compressed payload as the total length field of IP header is not present in compressed header and may confuse ROHC decompressor. Decompressor gateway should insert necessary padding bytes to decompressed Ethernet frame to fulfill the minimum Ethernet frame size. 



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|        Length  (15b)        |         Type = 0x0001         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Receiver Destination NPA Address * (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                         Destination MAC  (6B)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Source MAC (6B)                     |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |      EtherType/LLC Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =                   RoHC compressed payload                     =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            CRC-32                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 5: ROHC Compressed Packet Encapsulated within SNDU Bridged Frame 

The rationale of reusing existing ULE type to carry ROHC compressed packets is twofold:

  1. Decompressor gateway can recognize the content of SNDU easily and handle the SNDU in the same way as its uncompressed counterpart after the PDU is decompressed.
  2. The framework will be more extensible. If in the future, when new ULE types are introduced to carry SNDU that can be compressed by ROHC, these new ULE types can be used again to cover for its ROHC compressed counterparts.

There can be no ambiguity as to whether a SNDU is carrying ROHC compressed PDU or uncompressed SNDU because ROHC compressed PDU can only exist in ROHC channel.


 TOC 

4.2.  ROHC Feedback

ROHC feedback is not compressed per se and is only used by decompressor to send feedback to compressor when it is operating in bidirectional mode. Format of ROHC feedback is depicted in Figure 6 (Format of ROHC feedback encapsulated within ULE SNDU). 



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|        Length  (15b)        |    Type = ULE ROHC-Feedback   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Receiver Destination NPA Address* (6B)            |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                        RoHC feedback                          |
      =                                                               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            CRC-32                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 6: Format of ROHC feedback encapsulated within ULE SNDU 

It should be noted that ROHC feedback may be embedded within a ROHC compressed packet and doesn't necessarily have to be sent in the format presented in Figure 6 (Format of ROHC feedback encapsulated within ULE SNDU).

As discussed earlier, ROHC feedback may be sent through ULE channel from decompressor gateway. However, there may be multiple gateways receiving that particular uncompressed channel. To uniquely identify the receiving gateway, Receiver Destination NPA Address field must be used to store the Address of the compressor gateway when ROHC feedback sent through uncompressed channel.

If, however, there is a dedicated ROHC channel from decompressor gateway to compressor gateway, Receiver Destination NPA Address need not be used. This is situation may occur when there is a co-located compressor at the decompressor gateway with a corresponding decompressor at the compressor gateway like the example shown in Figure 3 (Topology of Gateways with Pairs of ROHC peers). Therefore, if a decompressor gateway need to send ROHC feedback, it should do so through ROHC channel if one is available.


 TOC 

5.  Topological Learning

Since there may be more than one gateway listening to a transmission, a gateway may need to setup multiple ROHC channels each for a listening gateways. Before a gateway can compress a packet, it needs to decide the right recipient gateway. If not, the gateway won't be able to determine which ROHC compressor to use, thereby the right ROHC channel to use. Thus, a gateway that wishes to send ROHC compressed packet need to learn the topology of its network.

The following subsection will present a simple technique for a gateway to learn about topology of its network. Implementation of this document may choose to use any other technique to inform the gateway about the topology of the network.


 TOC 

5.1.  Automatic Learning

Since a gateway needs to listen incoming traffic of other peer gateways through individual frontend of DVB receiver card for each peer gateway. Thus each frontend must be mapped to a corresponding ROHC channel exclusively.

When an incoming packet arrives at a frontend, the source address for the packet will need to be identified. The source address may be source IP address of IPv4 and IPv6 PDU or source MAC address of a bridged frame SNDU. Collectively, these source addresses are mapped to the ROHC channel that corresponds to this frontend.

When compressor gateway needs to send a packet, it needs to identify the destination address of the packet. The destination may be destination IP address of IPv4 and IPv6 PDU or destination MAC address of a bridged frame SNDU. The compressor gateway then need to look for a ROHC channel that has a matching address with this destination address. If a match is found, the ROHC channel and its corresponding ROHC compressor will be used to compress and send the packet. If no match is found, compressor gateway must send the packet uncompressed through uncompressed channel.


 TOC 

6.  Establishing ROHC Channel

This document presents an approach to setup ROHC channel over DVB links through a negotiation protocol. Implementation of the protocol mentioned in this document is not strictly required, implementors may choose to have static configuration for the operation of ROHC compression and decompression.


 TOC 

6.1.  ROHC Channel Parameters Negotiation Protocol (RCPNP)

This protocol works through ULE Streams only. It is possible to modify this protocol to work on Generic Stream Encapsulation [GSE] (European Telecommunication Standards Institute, “Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol,” 2007.) in the future. While it is possible to extend this protocol to work over asymmetrical link, this draft doesn't try to address this issue. Since new EtherType can be allocated, this protocol can be extended to asymmetrical link via Link-Layer Tunneling Mechanism [RFC3077] (Duros, E., “A Link-Layer Tunneling Mechanism for Unidirectional Links,” 2001.) with little modifications. The ULE SNDUs defined in this section should be sent within uncompressed channel.

The skeleton format of a ULE SNDU packet for RCPNP message is as such: 



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|        Length  (15b)        |       Type = ULE ROHC-Neg     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Receiver Destination NPA Address* (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |Version| OpCod |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
      |                     Source Address * (6B)                     |
      +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               |                                               |
      +-+-+-+-+-+-+-+-+                                               =
      |                            Body *                             |
      =                                                               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            CRC-32                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 7: Minimal format of RCPNP message 

Type
New ULE type need to be assigned for ROHC negotiation protocol.
Receiver Destination NPA Address
Destination address field should exist for all types of message except for Compressor Solicitation and Compressor Advertisement messages.
Version
Version of ROHC Channel Parameters Negotiation Protocol (RCPNP). Currently, only version 0 is supported.
OpCod
OpCod field is an abbreviation for Operation Code. The value of Operation Code field determines the message type.
Source Address
Source address field should exist for all messages except for Compressor Solicitation message and is used to indicate the address of the sender.
Body
Body of message. This content of this field is dependent on Operation Code. This field may not be present for certain type of messages.

All fields marked with '*' are optional and may not be present for certain type of messages. Unless specified otherwise, these fields will be present in RCPNP messages. The following subsections will explain the type of messages for this protocol. As mentioned, the type of message is determined by Operation Code field.


 TOC 

6.1.1.  Compressor Advertisement

Operation Code
The value is 0.
Receiver Destination NPA Address
This field is not present in this message.
Body
This field is not present in this message.

This message is used by the compressor site to advertise the availability of ROHC Compressor. Out of concern for bandwidth and energy consumption, compressor site should limit the broadcast of this message for a few times when it first joins the network. This message should also be broadcasted when a Compressor Solicitation message is received. The decompressor site will use the value specified in the Source Address field when addressing compressor site.


 TOC 

6.1.2.  Compressor Solicitation

Operation Code
The value is 1.
Receiver Destination NPA Address
This field is not present in this message.
Source Address
This field is not present in this message.
Body
This field is not present in this message.

This message is broadcasted by decompressor to solicit for compressor. Decompressor site should rate-limit the frequency of solicitation to avoid flooding DVB link.


 TOC 

6.1.3.  Request



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             MRRU                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum CID (2B)        |     Num of profiles (2B)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Profile ID 1            |        Profile ID 2 *         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =                      More Profile IDs *                       =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 8: Format of Request message 

The fields shown in the figure above collectively form the Body field of a Request message. This message is sent by decompressor site to compressor site when it wishes to establish a ROHC channel. The meaning of each fields in the message are described below:

Operation Code
Not shown in the diagram, but this field carries the value of 2.
MRRU
Maximum Reconstructed Reception Unit tolerated by decompressor. Value of 0 indicates the negotiated channel doesn't allow for segmentation of ROHC compressed packet.
Maximum CID
Maximum Context Identifier tolerated by decompressor.
Number of profiles
Number of profiles supported by decompressor. Must be at least one.
Profile IDs
ROHC Profile IDs supported by decompressor. Each profile ID occupies 2 octets.


 TOC 

6.1.4.  Reply



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             MRRU                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum CID (2B)        |        PID (13b)        | Res |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Num of Profiles|         Profile ID 1          |    Profile    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ID 2 * (cont) |                                               |
      =-+-+-+-+-+-+-+-+      More Profile IDs *                       =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 9: Format of Reply message 

The fields shown in the figure above collectively form the Body field of a Reply message. This message is sent by compressor site to decompressor site in response to a Request message sent by decompressor site.

If decompressor doesn't receive within any Reply message within a specific interval, it should resend the same Request message for a few more times. If these few attempts fail to result in any Reply message, decompressor should wait for a longer period before starting a new round of negotiation.

The meaning of each fields in the message are described below:

Operation Code
Not shown in the diagram, but this field carries the value of 3.
MRRU
Maximum Reconstructed Reception Unit tolerated by compressor. Decompressor site should send a NACK if it is receives higher MRRU than what it requested.
Maximum CID
Maximum CID tolerated by compressor. This value of this field should be less than or equal to its counterpart in Request message. Decompressor site should send a NACK if it receives Maximum CID that is higher than the initial negotiated value. If the maximum CID is less than 16, CIDs will be encoded using small CID presentation for the ROHC channel. Otherwise, large CID presentation will be used.
PID
Packet Identifier of MPEG2-TS frames that will carry ROHC compressed packet.
Res
Reserved field. Unused and should be ignored.
Number of profile IDs
ROHC framework reserves most significant octet of profile ID to denote the version number of a ROHC profile. Due to this constraint, there can only be 256 active profiles per channel. Therefore, this field occupies 1 octet instead of 2. Decompressor site should send a NACK if it receives more profile IDs than it can support.
The compressor will set this field to 0 if none of profile negotiated in Request message can be supported. Upon receiving this reply, decompressor should discard any stored information of negotiated ROHC channel parameters. Neither Acknowledgement nor Negative Acknowledgement should be sent since compressor site doesn't expect one. However, decompressor site may start a new round of negotiation with different profiles.
Profile IDs
Profile Identifiers of the ROHC profiles that will be used for the negotiated ROHC channel. Decompressor site should send a NACK if it receives any profile ID that it doesn't support.


 TOC 

6.1.5.  Acknowledgement

Operation Code
The value is 4.
Body
This field is not present in this message.

Decompressor site should send an acknowledgement if the parameters negotiated in Reply message is agreeable. If compressor site doesn't receive ACK nor NACK within a reasonable interval, it should discard any information of negotiated ROHC channel parameters. An acknowledgement must be sent to decompressor site when compressor site receives Decompressor Shutdown message.


 TOC 

6.1.6.  Negative Acknowledgement

Operation Code
The value is 5.
Body
This field is not present in this message.

Decompressor site should send a negative acknowledgement if it receives a valid Reply message but disagree with the parameters set in the Reply message. If compressor site doesn't receive ACK nor NACK within a reasonable interval, it should discard any information of negotiated ROHC channel parameters.


 TOC 

6.1.7.  Compressor Shutdown

Operation Code
The value is 5.
Body
This field is not present in this message.

This message is sent by the compressor site to notify the decompressor site that it is about to stop compressing IP packets. Upon receiving this message, decompressor should release all resources that are being held for decompression.

Compressor must wait for an acknowledgement from decompressor site before freeing its resource. If it doesn't receive an acknowledgement within a reasonable interval, it should keep sending a shutdown message for a number of times before freeing its resource.


 TOC 

6.1.8.  Decompressor Shutdown

Operation Code
The value is 6.
Body
This field is not present in this message.

This message is sent by the decompressor site to notify the compressor that it is about to stop decompressing IP packets. Upon receiving this message, compressor should release all resources that are being held and stop sending compressed IP packets.

Decompressor must wait for an acknowledgement from compressor site before freeing its resource. If it doesn't receive an acknowledgement within a reasonable interval, it should keep sending a shutdown message for a number of times before freeing its resource.


 TOC 

6.2.  Interaction of RCPNP

The following diagram depicts a possible interaction between compressor site and decompressor site in negotiating ROHC channel parameters. 



      Compressor Site                                 Decompressor Site
            |<---------------- Solicit ---------------|
            |                                         |
            |-------------- Advertise --------------->|
            |                                         |
            |<-------------- Request -----------------|
            |                                         |
            |---------------- Reply ----------------->|
            |                                         | Create instance
            |                                         | of decompressor
Create      |<---------------- ACK -------------------|
compressor  |                                         |
            |                                         |
            |= (Compression can begin at this point) =|
            |                                         |
            |                                         |
Destroy     |<------- Decompressor Shutdown ----------|
compressor  |                                         |
            |----------------- ACK --- -------------->| Destroy
            |                                         | decompressor
 Figure 10: Packets flow of RCPNP 

 TOC 

7.  Bidirectional ROHC Channels

While establishing bidirectional ROHC channels allows for the use of ROHC bidirectional optimistic mode and bidirectional reliable mode, RCPNP doesn't concern itself with the establishment of bidirectional ROHC channels. Therefore, it is up to implementers of this protocol to support bidirectional ROHC channels. The implementation should be as straightforward as mapping correct pair of ROHC channels.

Bidirectional ROHC channels must be formed whenever possible by associating co-located compressor and decompressor. If co-located compressor and decompressor are not associated, decompressor won't be able to parse any ROHC compressed packet that piggyback ROHC feedback properly since it doesn't know the size of CID within the piggybacked ROHC feedback.


 TOC 

8.  IANA Consideration

This document requires IANA involvement for the assignment of two new Next-Header Type values from the IANA ULE Next-Header Registry.

The following assignments have been made in this document, and registered by IANA:

XXX NOTE: IANA please replace TBD and TBD-1 when assigned XXX

TypeNameReference
TBD: ULE-ROHC-Feedback Figure 6 (Format of ROHC feedback encapsulated within ULE SNDU)
TBD-1: ULE-ROHC-Neg Section 6.1 (ROHC Channel Parameters Negotiation Protocol (RCPNP))

The ULE-ROHC-Feedback Extension is a Mandatory next-type Extension Header, specified in Figure 6 (Format of ROHC feedback encapsulated within ULE SNDU) of this document. The value of this next-header is defined by an IANA assigned H-Type value of TBD.

The ULE-ROHC-Neg Extension is a Mandatory next-type Extension Header specified in Section 6.1 (ROHC Channel Parameters Negotiation Protocol (RCPNP)) of this document. The value of this next-header is defined by an IANA assigned H-Type value of TBD-1.


 TOC 

9.  Acknowledgements

We would like to extend our gratitude to Dr. Gorry Fairhurst for his guidance.

We also want to thank Rod Walsh (Nokia) for his valuable input and feedback.


 TOC 

10.  Security Considerations

Technique presented in Section 5.1 (Automatic Learning) allows for DoS. A malicious site may send packet with a fake source address matching an address that belongs to a victim site. The compressor gateway upon receiving such malicious packet may be fooled about the recipient gateway and thus the intended packet may not be received by victim site once it goes through the wrong ROHC channel.

To mitigate this problem, compressor gateway that receives such suspicious packets with similar source address coming from different frontends of DVB receiver should disable compression and send all packets uncompressed via uncompressed channel when transmitting packets with the destination address.


 TOC 

11.  References


 TOC 

11.1. Normative References

[GSE] European Telecommunication Standards Institute, “Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol,” TS 102 606, 2007.
[IEEE-802.3] IEEE 802.3, “Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications,” IEEE Computer Society, (also ISO/IEC 8802-3), 2000.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3095] Borman, C., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” RFC 3095, 2001.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, “Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS),” 12 2005.

 TOC 

11.2. Informative References

[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, “Ethernet Local Area Network Specification Version 2.0,” November 1982.
[ISO-MPEG2] ISO 13818-1, “Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems,” International Standards Organisation (ISO), 2000.
[ITU-H222] H.222.0, “Information technology - Generic coding of moving pictures and associated audio information: Systems, International Telecommunication Union, (ITU-T),” 1995.
[RFC3077] Duros, E., “A Link-Layer Tunneling Mechanism for Unidirectional Links,” RFC 3077, 2001.
[RFC3759] Jonsson, L-E., “RObust Header Compression (ROHC): Terminology and Channel Mapping Examples,” RFC 3759, April 2004.
[RFC4259] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, “A Framework for Transmission of IP Datagrams over MPEG-2 Networks,” RFC 4259, 2005.

 TOC 

Authors' Addresses

  Tat-Chee Wan
  Universiti Sains Malaysia
  School of Computer Science
  Universiti Sains Malaysia
  Penang
  Malaysia
Phone:  +6 04 653 4633
Email:  tcwan@nav6.org
URI:  http://nrg.cs.usm.my/~tcwan
  
  Way-Chuang Ang
  Universiti Sains Malaysia
  School of Computer Science
  Universiti Sains Malaysia
  Penang
  Malaysia
Email:  wcang@nav6.org
  
  Chee-Hong Teh
  Universiti Sains Malaysia
  School of Computer Science
  Universiti Sains Malaysia
  Penang
  Malaysia
Email:  chteh@nav6.org

 TOC 

Full Copyright Statement

Copyright © The IETF Trust (2008).

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, THE IETF TRUST 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.