Subject: [Fwd: RFC: Draft for ROHC over DVB]

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 17 Feb 2008 20:26:28 +0000

I am forwarding this to the list, for comments and discussion.

best wishes,

Gorry Fairhurst
(as ipdvb Chair)

-------- Original Message --------
Subject: RFC: Draft for ROHC over DVB
Date: Sun, 17 Feb 2008 20:39:12 +0800
From: Ang Way Chuang <[email-masked]>
To: Gorry Fairhurst <[email-masked]>

Hi Dr. Fairhurst and members of IP over DVB charter,
       We are from Network Research Group of Universiti Sains Malaysia
(http://nrg.cs.usm.my/satellite.htm). We would like to seek for your
comments (and corrections) regarding our draft. Attached is the draft.
Do note that the most of content in Terminologies section was copied
from other Internet Drafts and RFCs. I think they are still incomplete.

       I tried to sent an email to [email-masked], but I received
no such email. I'm guessing the mailing list is not working properly.

Thank you very much.

Regards,
Ang Way Chuang

                                                                 Tat-Chee Wan
                                                                 Chee-Hong Teh
                                                                 Way-Chuang Ang

Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) 
and MPEG2-TS frames

Status of This Memo

    This memo defines an Experimental Protocol for the Internet
    community.  It does not specify an Internet standard of any kind.
    Discussion and suggestions for improvement are requested.
    Distribution of this memo is unlimited.

Intellectual Property Right

   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/1id-abstracts.html

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

Abstract

   This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS
   frames. For completeness, ROHC channel parameters negotiation protocol is also
   presented.

Table of Contents
    
   1. Introduction
   2. Terminology
   3. Packet Format of ROHC Packet
   3.1. ROHC over ULE
   3.1.1. Dedicated EtherType Fields for ROHC Compressed Packet
   3.1.1. Dedicated EtherType Fields for ROHC Compressed Packet
   3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet
   3.2. ROHC over MPEG2-TS
   4. Establishing ROHC Channel
   4.1. ROHC Channel Negotiation Protocol
   4.1.1. Compressor Advertisement
   4.1.2. Compressor Solicitation
   4.1.3. Request
   4.1.4. Reply
   4.1.4.1. Medium Information
   4.1.4.1.1. MPEG2-TS Medium
   4.1.4.1.2. ULE Medium
   4.1.5. Acknowledgement/Negative Acknowledgement
   4.1.6 Compressor Shutdown
   4.1.7 Decompressor Shutdown
   4.2. Interaction of ROHC Channel Parameters Negotiation Protocol
   4.3 Bidirectional ROHC Channels
   5. IANA Consideration
   6. References
   
1. Introduction

2. Terminology
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

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

   MAC
      Medium Access Control [IEEE-802.3].  A link-layer protocol defined
      by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).

   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], and ITU-T (in H.222
      [ITU-H222]).

   PDU
      Protocol Data Unit.  Examples of a PDU include Ethernet frames,
      IPv4 or IPv6 datagrams, and other network packets.

   Receiver
      Equipment that processes the signal from a TS Multiplex and
      performs filtering and forwarding of encapsulated PDUs to the
      network-layer service (or bridging module when operating at the
      link layer).

   Transmitter
      Router or host that sends data.

   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 Streams may be identified by definition of a
      stream_type in SI/PSI [ISO-MPEG2].

   ROHC
      Robust Header Compression. A framework of compression headers of IP
      packet as defined in [RFC 3095]

   ROHC channel
      A logical unidirectional point-to-point channel carrying ROHC packets
      from one compressor to one decompressor, optionally carrying ROHC
      feedback information on the behalf of another compressor-decompressor
      pair operating on a separate ROHC channel in the opposite direction.

   ROHC profile
      A ROHC profile is a compression protocol, which specifies how to compress
      specific header combinations. A ROHC profile may be tailored to handle a
      specific set of link characteristics, e.g., loss characteristics,
      reordering between compression points, etc. ROHC profiles provide the
      details of the header compression and each compression profile is
      associated with a unique ROHC profile identifier.

   MRRU 
      Maximum Reconstructed Reception Unit as defined in [RFC 3095].

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

   Context Identifier
      [RFC 3095] provides a definition for context identifiers. 

   MSB
      Most significant bit.

   LSB
      Least significant bit.

   ACK
      Acknowledgement.

   NACK
      Negative acknowledgement.

   CID
      Context Identifier.

3. Packet Format of ROHC Packet

3.1. ROHC over ULE
   The packet format for ROHC packet encapsulated can be in one the following
   two formats:

3.1.1. Dedicated EtherType Fields for ROHC Compressed Packet
   +-+--------+---------+---------------+------------------------+--------+
   |D| Length |Type=ROHC| Dest Address* | ROHC compressed packet | CRC-32 |
   +-+--------+---------+---------------+------------------------+--------+
	Figure 1: ROHC compressed packet encapsulated using dedicated EtherType

   The semantics of D-bit, Length, Type, Destination Address and CRC-32 fields
   are defined in section 4 of [RFC 4326]. However, the Type fields requires
   a new IANA assigned EtherType value to indicate the presence of ROHC
   compressed packet in PDU.

   In the absence of multiple receivers, a transmitter can send an SNDU without
   Destination Address Field (D bit marked). However, when multiple receivers 
   are listening to the same transmitter, destination address must be included
   in SNDU.

3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet

   +---+--------+----------+----------+------------+--------------+------------------------+--------+
   |D=1| Length |Type=Ether| Dest MAC | Source MAC |EtherType=ROHC| ROHC compressed packet | CRC-32 |
   +---+--------+----------+----------+------------+--------------+------------------------+--------+
	Figure 2: ROHC compressed packet encapsulated in SNDU bridged frame

   This packet format should be used when there are multiple transmitters and
   receivers over a DVB link. The value of EtherType field is similar to Type
   Field in section 3.1.1.

3.2. ROHC over MPEG2-TS
   This encapsulation format is the smallest packet format in terms of packet
   size. The format of SNDU is the following format:

   +------+------------------------+--------+
   |Length| ROHC compressed packet | CRC-32 |
   +------+------------------------+--------+
      Figure 3:

   The meaning of each fields is specified below:

   Length: This field indicates the ROHC compressed packet field only. This
   field can be either 1 or 2 octets depending on the the most significant bit.
   If the most significant bit is cleared, the length of this field is 1 octet
   and may represents values from 0 until 127. Otherwise, the length of this
   field is 2 octets and may represents values from 128 until 61566.

   ROHC Compressed Packet:  ROHC compressed packet as defined in section 5.2 of
   [RFC 3095].

   CRC-32: The 32-bit CRC is calculated over Length filed and ROHC compressed
   packet. The polynomial used to calculate the CRC is 0x104C11DB7. 

   Like ULE, ROHC over MPEG2-TS also supports packing and padding mode. The 
   mechanism of encapsulating this SNDU is similar to encapsulation of ULE
   packet within MPEG2-TS. This approach requires that separate PID dedicated
   to a ROHC channel.

4. Establishing ROHC Channel
   This standard presents two approaches to setup a ROHC channel over a DVB
   link. The first approach is to setup ROHC channel manually. This requires 
   that the operators at the every transmitters and receivers to manually
   configure the ROHC channel parameters. When the size of network is small,
   this approach is favourable.

   But the former approach becomes nonviable if the network is dynamic and is
   not scalable as the size of the network grows. Henceforth, we presents a
   negotiation protocol to create ROHC channel in the next section.

4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP)
   The approach presented in this section can only work if compressor site
   and decompressor site are connected through two dedicated unidirectional
   DVB links, with a unidirectional link originating from each of the
   sites, configured to form a bidirectional network link between the two
   sites. This protocol works through ULE packets only. It is possible to
   extend this protocol to work over Generic Stream Encapsulation [GSE] 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 is allocated, this protocol can be extended to asymmetrical link
   via Link-Layer Tunneling Mechanism [RFC 3077] with little modifications.

   The basic format of ULE SNDU packet is as such:

   +---+--------+------------+----------+--------+
   |D=1| Length |Type=ROHCNeg|   Body   | CRC-32 |
   +---+--------+------------+----------+--------+
      Figure 4: Minimal format of RCPNP message  

   +---+--------+----------+----------+------------+-----------------+------+--------+
   |D=1| Length |Type=Ether| Dest MAC | Source MAC |EtherType=ROHCNeg| Body | CRC-32 |
   +---+--------+----------+----------+------------+-----------------+------+--------+
      Figure 5: RCPNP message encapsulated in bridged frame.

   Type field requires a new separate IANA assigned EtherType number for ROHC
   Channel Negotiation Protocol. The types of message in this protocol is
   defined in the Body field. The following subsections will explain the type
   of messages for this protocol. Compressor Advertisement and Compressor 
   Solicitation uses packet format depicted in Figure 4. While other forms of
   messages uses packet format depicted in Figure 5.

   The basic format for these messages is depicted is as such:

   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version        |    Operation    |  X  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 6: Basic format of RCPNP Body field.

   Currently, version number is 0. Operation field defines the type of message
   contained in the Body field. The content of X-bit depends on operation type.

4.1.1. Compressor Advertisement

   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=0   |  X  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   ~              Address (6 octets)               ~
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 7: Format of Compressor Advertisement message.

   Compressor site should send this message periodically to advertise the
   availability of compressor. Care should be taken as not to send too many
   advertisements. The decompressor site will use the value specified in the
   Address field when addressing compressor site. X-bit is unused and should be
   ignored.

4.1.2. Compressor Solicitation

   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=1   |  X  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 8: Format of Compressor Solicitation message.

   Instead of waiting for compressor site to advertise itself, decompressor site
   may opt to solicit for compressor(s) by sending compressor site solicitation
   message. Upon receiving solicitation, compressor site should send an
   advertisement. X-bit is unused and should be ignored. Decompressor site
   should rate-limit the frequency of solicitation if it is doesn't receive
   any advertisement to avoid flooding DVB link.

4.1.3. Request

   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=2   |  X  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                  Maximum CID                  +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   ~                  MRRU (4 octets)              ~
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +             Num of profiles                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                Profile ID 1                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                Profile ID 2                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                Profile ID N                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 9: Format of Request message.

   This message is sent by decompressor site to compressor site. The meaning
   of each fields in the message are described below:

   Maximum CID: Maximum Context Identifier tolerated by decompressor.

   MRRU: Maximum Reconstructed Reception Unit tolerated by decompressor. Value
   of 0 indicates the negotiated channel doesn't allow for segmentation of ROHC
   compressed packet.

   Number of profiles: Number of profiles supported by decompressor.

   Profile IDs: ROHC Profile IDs supported by decompressor. Each profile
   ID occupy 2 octets.

   X-bit is unused and should be ignored.

4.1.4. Reply

   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=3   |  X  |
   +===============================================+
   |                                               |
   +                  Maximum CID                  +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   ~                  MRRU (4 octets)              ~
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |             Num of profiles                   |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                Profile ID 1                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                Profile ID 2                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   +                Profile ID N                   +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 10: Format of Reply message.

   This message is sent by compressor site to decompressor site in response to
   request message sent by decompressor site. The meaning of each fields in the
   message are described below:

   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.

   MRRU: Maximum Reconstructed Reception Unit tolerated by compressor. Likewise,
   decompressor site should send a NACK if it is receives higher MRRU than what
   it requested.

   Number of profile IDs: Note that this field is 1 octet instead of 2 because
   there can be only 256 active profiles at any given ROHC channel. Decompressor
   site should send a NACK if it receives more profile IDs than it can support. 

   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.

   X-bit is unused and should be ignored.

4.1.4.1. Medium Information
   The following notation depicted in the previous figure 10 indicates the 
   presence of medium information.

   +===============================================+

   Medium information conveys how compressor is to send ROHC compressed packets
   to decompressor. Currently only 2 media are supported, namely MPEG2-TS and
   ULE. The details of packet format for ROHC over MPEG2-TS/ULE is described 
   in section 3. Medium type is conveyed by Medium field. Other media may be
   supported in the future and the support for these media will specified in 
   other documents. Decompressor receiving unsupported medium type should send 
   a NACK.

4.1.4.1.1. MPEG2-TS Medium
   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |    Medium=0     |                             |
   +-----+-----+-----+      PID                    +
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 11: Medium information for ROHC over MPEG2-TS.

   PID: Packet Identifier of MPEG2-TS frames that will carry ROHC compressed
   packet.

4.1.4.1.2. ULE Medium
   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |    Medium=1     |  ULE Type |    Reserved     |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 12: Medium information for ROHC over ULE.

   ULE Type:

   0: No MAC address will be sent in ULE packets. This option should only be
   used if the compressor site is certain that there is only one receiver and
   one transmitter over DVB link.

   1: Only destination MAC address will be sent in ULE packets that carry ROHC
   compressed packet. This means that Destination Absent bit in ULE header will
   be cleared. This option is used only if there is one transmitter and many 
   receivers listening to that transmitter via DVB link.

   2: ROHC packets will be encapsulated in Ethernet bridged frame. This option
   is used when there multiple transmitters and receivers over a DVB link.

   3: Not used. Receiver should treat it as corrupted packet, silently
   discard the message and wait for a valid Reply message or until a timeout 
   occur at which the decompressor site will start the negotiation afresh by
   sending a Request message.

   Reserved field is not used and should be ignored.

4.1.5. Acknowledgement
   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=4   | Ack |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 13: Format of Acknowledgement message.

   Decompressor site should send either an acknowledgement or negative
   acknowledgement if it receives a valid Reply message. If Ack bit is set,
   then the message is an acknowledgement. Otherwise, it is a negative
   acknowledgement. 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.

4.1.6 Compressor Shutdown
   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=5   |  X  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 14: Format of Compressor Shutdown 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.

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

   X-bit is unused and should be ignored.

4.1.7 Decompressor Shutdown
   MSB                                          LSB
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |        Version=0      |   Operation=6   |  X  |
   +-----+-----+-----+-----+-----+-----+-----+-----+
      Figure 15: Format of Decompressor Shutdown 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 an  acknowledgement within a reasonable
   interval, it should keep sending a shutdown message for a number of times
   before freeing its resource.

   X-bit is unused and should be ignored.

4.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 (optional) ----------------|
            |                                                 |
            |------------------- Advertise ------------------>|
            |                                                 |
            |<------------------- Request --------------------|
            |                                                 |
            |--------------------- Reply -------------------->|
            |                                                 | Create instance
            |                                                 | of decompressor
Create      |<-------------------- ACK -----------------------| 
compressor  |                                                 |
            |                                                 |
            | ==== (Compression can begin at this point) ===  |
            |                                                 |
            |                                                 |
Destroy     |<------------ Decompressor Shutdown -------------| 
compressor  |                                                 |
            |--------------------- ACK ---------------------->| Destroy
            |                                                 | decompressor 

                  Figure 15: Packets flow of RCPNP

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

5. IANA Consideration
   Two EtherTypes should be assigned. One of it is for RCPNP and the other is
   to indicate the presence of ROHC compressed packet.

6. References
[RFC 3095]	Bormann, C. et al, "RObust Header Compression (ROHC):
		Framework and four profiles: RTP, UDP, ESP, and uncompressed",
		RFC 3095, 2001

[RFC 4326]      Fairhurst, G. and Collini-Nocker, B., "Unidirectional
                Lightweight Encapsulation (ULE) for Transmission of IP Datagrams
                over an MPEG-2 Transport Stream (TS)", RFC 4326, 2005

[GSE]           Digital Video Broadcasting, "Generic Stream Encapsulation (GSE)
                Protocol", DVB Document A116, 2007

[RFC 3077]      Duros, E. et al, "A Link-Layer Tunneling Mechanism for
                Unidirectional Links", RFC 3077, 2001

[ISO-MPEG2]     IS 13818-1, "Information technology -- Generic coding of moving
                pictures and associated audio information -- Part 1: Systems",
                International Standards Organisation (ISO), 2000.

Authors’ Addresses
   Tat-Chee Wan
   School of Computer Sciences,
   Universiti Sains Malaysia,
   11800 USM, Penang, Malaysia.
   Email: [email-masked]
   Web: http://nrg.cs.usm.my/~tcwan

   Chee-Hong Teh
   School of Computer Sciences,
   Universiti Sains Malaysia,
   11800 USM, Penang, Malaysia.
   Email: [email-masked]

   Way-Chuang Ang
   School of Computer Sciences,
   Universiti Sains Malaysia,
   11800 USM, Penang, Malaysia.
   Email: [email-masked]

---

From: "Walsh Rod (Nokia-NRC/Tampere)" <[email-masked]>
Date: Mon, 18 Feb 2008 09:59:06 +0200

Hi All et al :)

Quick comments and questions...

>    sites.

* Why such a limitation? Is there already a preferred where the secondary
link is bidirectional or can not be relied upon at all?

> 4.1.1. Compressor Advertisement
...
>    advertisements.

* What about indicating from, compressor or decompressor, when such a
heartbeat should be expected (Sorry if it was there but I missed this). At
least the interval/period would limit the "promiscuous listing" to one
period only, afterwards the decompressor can "sleep more". Apart from
altruistic energy saving reasons, any mobile application is going to want as
many opportunities to preserve power as possible.

Some argumentation needs making at the very least oin this mail list, but
preferably also in the I-D (maybe as an annex for easy removal later if it
gets adopted).

* What are the alternatives to this scheme based on ROHC?

* How similar to other ROHC profiles is this? Does it break or invent some
new semantic or is it exactly parallel to some existing RFC?

* Is there any effect on header compression at higher layers? E.g. If the
spec interferes with using RTP/UDP/IP ROHC, then any efficiencies could be
lost in the inability for the compression of heaver headers. Likewise, it
makes sense to keep this ULE part isolated if possible so that authors of
any other or future ROHC compression schemes aren't required to know about
this spec while still allowing ULE implementers to benefit from ULE and
higher layer ROHC together.

Cheers, Rod.

PS Good timing of the email Gorry - I was doing my 2-monthly stroll through
IETF mails :)

On 2/17/08 10:26 PM, "ext Gorry Fairhurst" <[email-masked]> wrote:

>                                                                  Way-Chuang
> Ang
>             |                                                 | Create
> instance
>             |                                                 | of
> decompressor

---

From: Ang Way Chuang <[email-masked]>
Date: Mon, 18 Feb 2008 17:31:44 +0800

> link is bidirectional or can not be relied upon at all?

Our research focuses on UDL mesh network 
(http://nrg.cs.usm.my/~tcwan/Papers/APAN00-WAN-UDL.pdf). We do not 
consider other scenarios like asymmetrical links. But I suppose it can 
work on other scenarios. It will be great if someone can provide input 
for this.

> many opportunities to preserve power as possible.

I suppose we can include heartbeat interval inside Compressor 
Advertisement message.  As for decompressor site, I'm not sure how 
compressor can benefit from such information.

> preferably also in the I-D (maybe as an annex for easy removal later if it

I beg ignorance on the I-D  matter.

> * What are the alternatives to this scheme based on ROHC?

I'm not sure what you meant. You mean way to carry other type of header 
compression (e.g IP Header Compression) over DVB?

> new semantic or is it exactly parallel to some existing RFC?

This draft doesn't create new ROHC profiles. It only defines ways to 
carry ROHC compressed packet over DVB and negotiation protocol to setup 
ROHC channel.

> higher layer ROHC together.

No, it doesn't.

Thank you for your interest.

> PS Good timing of the email Gorry - I was doing my 2-monthly stroll through

Regards,
Ang Way-Chuang

---

From: Ang Way Chuang <[email-masked]>
Date: Mon, 18 Feb 2008 23:49:07 +0800

> compressor can benefit from such information.

Hmm, silly me. I think the best approach for these mobile applications 
is to ignore Compressor Advertisement message. If it needs to know the 
presence of compressor(s), it can send a solicitation message. There is 
not much point of waking up applications/devices every few seconds just 
to listen to the message with same content. Better still, if periodical 
transmission of Compressor Advertisement is undesirable due to 
consumption of electricity and bandwidth, then we can change the way the 
protocol works. In effect, the Compressor Advertisement will be a 
reactive message that is only sent if compressor site receives a 
Compressor Solicitation message from Decompressor. Any other suggestion?

>>>    frames. For completeness, ROHC channel parameters negotiation 
>>> protocol is
>>> also
>>>    presented.
>>>
>>> Table of Contents
>>>        1. Introduction
>>>    2. Terminology
>>>    MRRU       Maximum Reconstructed Reception Unit as defined in [RFC 
>>> 3095].
>>>
>>>    DVB
>>> standards
>>> +---+--------+----------+----------+------------+--------------+-------------- 
>>>
>>> ----------+--------+
>>> +---+--------+----------+----------+------------+--------------+-------------- 
>>>
>>> ----------+--------+
>>>    field can be either 1 or 2 octets depending on the the most 
>>> significant
>>> bit.
>>>    ROHC Compressed Packet:  ROHC compressed packet as defined in 
>>> section 5.2
>>> of
>>>    [RFC 3095].
>>>
>>> +---+--------+----------+----------+------------+-----------------+------+---- 
>>>
>>> ----+
>>>    |D=1| Length |Type=Ether| Dest MAC | Source MAC 
>>> |EtherType=ROHCNeg| Body |
>>> CRC-32 |
>>>    
>>> +---+--------+----------+----------+------------+-----------------+------+---- 
>>>
>>> ----+
>>>    contained in the Body field. The content of X-bit depends on 
>>> operation
>>> type.
>>>
>>>    Address field when addressing compressor site. X-bit is unused and 
>>> should
>>> be
>>>    ignored.
>>>
>>>    Instead of waiting for compressor site to advertise itself, 
>>> decompressor
>>> site
>>>    of 0 indicates the negotiated channel doesn't allow for 
>>> segmentation of
>>> ROHC
>>>    compressed packet.
>>>
>>>    request message sent by decompressor site. The meaning of each 
>>> fields in
>>> the
>>>    decompressor site should send a NACK if it is receives higher MRRU 
>>> than
>>> what
>>>    it requested.
>>>
>>>    compressed packet. This means that Destination Absent bit in ULE 
>>> header
>>> will
>>>    channel parameters. An acknowledgement must be sent to 
>>> decompressor site
>>> when
>>>    message, compressor should release all resources that are being 
>>> held and
>>> stop
>>>    The following diagram depicts a possible interaction between 
>>> compressor
>>> site
>>> [GSE]           Digital Video Broadcasting, "Generic Stream 
>>> Encapsulation
>>> (GSE)