From gorry at erg.abdn.ac.uk  Sun Feb 17 20:26:28 2008
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Sun, 17 Feb 2008 20:26:28 +0000
Subject: [Fwd: RFC: Draft for ROHC over DVB]
Message-ID: <47B89874.80009@erg.abdn.ac.uk>


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 <wcang at nav6.org>
To: Gorry Fairhurst <gorry at erg.abdn.ac.uk>

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 ipdvb at erg.abdn.ac.uk, but I received
no such email. I'm guessing the mailing list is not working properly.


Thank you very much.

Regards,
Ang Way Chuang



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-rohc-dvb.txt
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20080217/3f89d256/attachment.txt>

From Rod.Walsh at nokia.com  Mon Feb 18 07:59:06 2008
From: Rod.Walsh at nokia.com (Walsh Rod (Nokia-NRC/Tampere))
Date: Mon, 18 Feb 2008 09:59:06 +0200
Subject: [Fwd: RFC: Draft for ROHC over DVB]
In-Reply-To: <47B89874.80009@erg.abdn.ac.uk>
Message-ID: <C3DF076A.902F%Rod.Walsh@nokia.com>

Hi All et al :)

Quick comments and questions...

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

* 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
...
>    Compressor site should send this message periodically to advertise the
>    availability of compressor. Care should be taken as not to send too many
>    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" <gorry at erg.abdn.ac.uk> wrote:

> 
> 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 <wcang at nav6.org>
> To: Gorry Fairhurst <gorry at erg.abdn.ac.uk>
> 
> 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 ipdvb at erg.abdn.ac.uk, 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: tcwan at cs.usm.my
>    Web: http://nrg.cs.usm.my/~tcwan
> 
>    Chee-Hong Teh
>    School of Computer Sciences,
>    Universiti Sains Malaysia,
>    11800 USM, Penang, Malaysia.
>    Email: chteh at nav6.org
> 
>    Way-Chuang Ang
>    School of Computer Sciences,
>    Universiti Sains Malaysia,
>    11800 USM, Penang, Malaysia.
>    Email: wcang at nav6.org
> 
> 
> 




From wcang at nav6.org  Mon Feb 18 09:31:44 2008
From: wcang at nav6.org (Ang Way Chuang)
Date: Mon, 18 Feb 2008 17:31:44 +0800
Subject: [Fwd: RFC: Draft for ROHC over DVB]
In-Reply-To: <C3DF076A.902F%Rod.Walsh@nokia.com>
References: <C3DF076A.902F%Rod.Walsh@nokia.com>
Message-ID: <47B95080.8040606@nav6.org>

Walsh Rod (Nokia-NRC/Tampere) wrote:
> Hi All et al :)
> 
> Quick comments and questions...
> 
>> 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.
> 
> * Why such a limitation? Is there already a preferred where the secondary
> 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.

> 
>> 4.1.1. Compressor Advertisement
> ...
>>    Compressor site should send this message periodically to advertise the
>>    availability of compressor. Care should be taken as not to send too many
>>    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.

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.

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

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?

> 
> * 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?

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.

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

No, it doesn't.

Thank you for your interest.

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

Regards,
Ang Way-Chuang
> 
> 
> On 2/17/08 10:26 PM, "ext Gorry Fairhurst" <gorry at erg.abdn.ac.uk> wrote:
> 
>> 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 <wcang at nav6.org>
>> To: Gorry Fairhurst <gorry at erg.abdn.ac.uk>
>>
>> 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 ipdvb at erg.abdn.ac.uk, 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: tcwan at cs.usm.my
>>    Web: http://nrg.cs.usm.my/~tcwan
>>
>>    Chee-Hong Teh
>>    School of Computer Sciences,
>>    Universiti Sains Malaysia,
>>    11800 USM, Penang, Malaysia.
>>    Email: chteh at nav6.org
>>
>>    Way-Chuang Ang
>>    School of Computer Sciences,
>>    Universiti Sains Malaysia,
>>    11800 USM, Penang, Malaysia.
>>    Email: wcang at nav6.org
>>
>>
>>
> 
> 
> 



From wcang at nav6.org  Mon Feb 18 15:49:07 2008
From: wcang at nav6.org (Ang Way Chuang)
Date: Mon, 18 Feb 2008 23:49:07 +0800
Subject: [Fwd: RFC: Draft for ROHC over DVB]
In-Reply-To: <47B95080.8040606@nav6.org>
References: <C3DF076A.902F%Rod.Walsh@nokia.com> <47B95080.8040606@nav6.org>
Message-ID: <47B9A8F3.4040309@nav6.org>

Ang Way Chuang wrote:
> Walsh Rod (Nokia-NRC/Tampere) wrote:
>> Hi All et al :)
>>
>> Quick comments and questions...
>>
>>> 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.
>>
>> * Why such a limitation? Is there already a preferred where the secondary
>> 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.
> 
>>
>>> 4.1.1. Compressor Advertisement
>> ...
>>>    Compressor site should send this message periodically to advertise 
>>> the
>>>    availability of compressor. Care should be taken as not to send 
>>> too many
>>>    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.
> 
> 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.
> 

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?

>>
>>
>> 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).
> 
> 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?
> 
>>
>> * 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?
> 
> 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.
> 
>>
>> * 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.
> 
> No, it doesn't.
> 
> Thank you for your interest.
> 
>>
>> Cheers, Rod.
>>
>> PS Good timing of the email Gorry - I was doing my 2-monthly stroll 
>> through
>> IETF mails :)
>>
> 
> Regards,
> Ang Way-Chuang
>>
>>
>> On 2/17/08 10:26 PM, "ext Gorry Fairhurst" <gorry at erg.abdn.ac.uk> wrote:
>>
>>> 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 <wcang at nav6.org>
>>> To: Gorry Fairhurst <gorry at erg.abdn.ac.uk>
>>>
>>> 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 ipdvb at erg.abdn.ac.uk, 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: tcwan at cs.usm.my
>>>    Web: http://nrg.cs.usm.my/~tcwan
>>>
>>>    Chee-Hong Teh
>>>    School of Computer Sciences,
>>>    Universiti Sains Malaysia,
>>>    11800 USM, Penang, Malaysia.
>>>    Email: chteh at nav6.org
>>>
>>>    Way-Chuang Ang
>>>    School of Computer Sciences,
>>>    Universiti Sains Malaysia,
>>>    11800 USM, Penang, Malaysia.
>>>    Email: wcang at nav6.org
>>>
>>>
>>>
>>
>>
>>
> 
> 



From wcang at nav6.org  Fri Feb 22 09:51:11 2008
From: wcang at nav6.org (Ang Way Chuang)
Date: Fri, 22 Feb 2008 17:51:11 +0800
Subject: RFC: Draft for ROHC over DVB
In-Reply-To: <47B95D6D.3020500@erg.abdn.ac.uk>
References: <47B82AF0.7080605@nav6.org> <47B8982A.2020007@erg.abdn.ac.uk> <47B8EE6F.4050005@nav6.org> <47B94AFB.5060909@erg.abdn.ac.uk> <47B95983.4070600@nav6.org> <47B95D6D.3020500@erg.abdn.ac.uk>
Message-ID: <47BE9B0F.3020100@nav6.org>

Hi Gorry,
	As suggested, the draft has been converted to xml format. Attached are 
the update xml and txt files. I've included the change suggested by Rod 
Walsh in the draft. Some entries in the Terminologies section are copied 
from other RFCs, I hope that is bad practice for a candidate I-D. 
Certainly, this draft needs more polishing. I take the liberty to send 
it now, so that someone in this mailing list can help iron out some 
issues. English is not my native tongue, please forgive me for my poor 
command of the language.

	Thank you in advance.

Regards,
Ang Way Chuang

Gorry Fairhurst wrote:
> 
> Thanks for your contribution - let's still diuscuss the technical 
> proposal and what should be done in this space using the ipdvb list - 
> It's great to have some input for discussion of this.
> 
> In parallel, I'd encourage you to look at the tools and let me know your 
> thoughts and progress!
> 
> Best wishes,
> 
> Gorry
> 
> Ang Way Chuang wrote:
>> Gorry Fairhurst wrote:
>>> Ang Way Chuang wrote:
>>>> Sorry for the brief inlined reply.
>>>>
>>>> Gorry Fairhurst wrote:
>>>>>
>>>>> You should be able to post it yourself, I'll happily post it to the 
>>>>> list for you to see if there is feedback. Can you tell us what you 
>>>>> plan to do next?
>>>>
>>>> I think I know why the previous post failed. I am subscribed to the 
>>>> mailing list via another email address (wcang at nrg.cs.usm.my) which 
>>>> is an alias to the one I'm using.
>>>>
>>> Sounds likely.
>>>
>>>>>
>>>>> If you were intending to submit a draft for consideration by the 
>>>>> IETF, then you need to format it according to the guidelines shown at:
>>>>> http://www.ietf.org/ietf/1id-guidelines.html
>>>>
>>>> Aye, we want to submit this draft for consideration by the IETF.
>>>>
>>> The first thing to decide is what editor you wish to use - some 
>>> people use a text editor and nroff (these are in the minority), many 
>>> still use a microsoft word template (the main way until a few years 
>>> ago) and the rest use a XML-editor (now probably the best way). You 
>>> could of course just try to write a text file, but as you receive 
>>> comments and find that you have co-editors helping with the draft, 
>>> this is likely to become too difficult to do.
>>>
>>> See:
>>> http://www.rfc-editor.org/formatting.html
>>> http://tools.ietf.org//inventory/author-tools
>>>
>>> A good start would be to get a XML or DOC file in the format you 
>>> intend to use and add your text to this.
>>>
>>> The final Internet-Draft must conform to the fixed style (i.e. all 
>>> sections well-formed:
>>>
>>> http://www.ietf.org/ID-Checklist.html
>>> http://www.ietf.org/ietf/1id-guidelines.txt
>>>
>>> This means in practice that you need to upload the document to the 
>>> checking tool at (this will tell you what is right and what is wrong)
>>> http://www.tools.ietf.org/tools/idnits/
>>
>> Aye, thanks for the pointer.
>>
>>>
>>> You may well be aware that there is a deadline prior to an IETF 
>>> meeting, this is enforce today (which means you can not submit a new 
>>> document after 5pm US time today).  You could try for this, but if 
>>> this is your first draft, then this may well be too little time (it's 
>>> easier if you've done this before).
>>
>> I see. I wasn't aware of that. This is our first draft, so I think it 
>> is wiser to discuss first.
>>
>>>
>>> In the mean-time it seems some people have started reading your 
>>> inputs, so you could discuss this on the list and see if people agree.
>>>
>>> Gorry
>>>
>>> P.S. There is no formal IPDVB meeting at this IETF, or ROHC WG meeting,
>>> but if you were attending then please do let me know and we can talk.
>>>
>>>>>
>>>>> You can then upload the draft to the I-D repository using:
>>>>> https://datatracker.ietf.org/idst/upload.cgi
>>>>>
>>>>> If you want help formatting and submitting this, please do let us 
>>>>> know.
>>>>
>>>> Yes, we appreciate any form of help. Please help us with formatting 
>>>> and submission. Thank you very much.
>>>>
>>>>>
>>>>> Best wishes,
>>>>>
>>>>> Gorry
>>>>>
>>>>>
>>>>> Ang Way Chuang wrote:
>>>>>> 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 ipdvb at erg.abdn.ac.uk, but I 
>>>>>> received no such email. I'm guessing the mailing list is not 
>>>>>> working properly.
>>>>>>
>>>>>>
>>>>>> Thank you very much.
>>>>>>
>>>>>> Regards,
>>>>>> Ang Way Chuang
>>>>
>>> Best wishes,
>>>
>>> Gorry
>>>
>>>
>>
>>
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-rohc-dvb.txt
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20080222/a58c6c92/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-rohc-dvb.xml
Type: text/xml
Size: 41035 bytes
Desc: not available
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20080222/a58c6c92/attachment.xml>

From gorry at erg.abdn.ac.uk  Sat Feb 23 17:49:21 2008
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Sat, 23 Feb 2008 17:49:21 +0000
Subject: RFC: Draft for ROHC over DVB
In-Reply-To: <47BE9B0F.3020100@nav6.org>
References: <47B82AF0.7080605@nav6.org> <47B8982A.2020007@erg.abdn.ac.uk> <47B8EE6F.4050005@nav6.org> <47B94AFB.5060909@erg.abdn.ac.uk> <47B95983.4070600@nav6.org> <47B95D6D.3020500@erg.abdn.ac.uk> <47BE9B0F.3020100@nav6.org>
Message-ID: <47C05CA1.8060907@erg.abdn.ac.uk>


According to naming conventions, the first version that is officially 
published by the IETF should be named something like:

draft-wan-ipdvb-rohc-00.txt

(i.e. draft- followed by first author, followed by WG followed by title)

The format of the draft would have passed the ID-Submission process and 
have been published except for the pre-IETF meeting cut-off.

I think this should therefore be uploaded as soon as the archives 
re-open - but it would be good to get feedback from people on the 
current text. I will also send some comments on the draft soon,

Best wishes,

Gorry


Ang Way Chuang wrote:
> Hi Gorry,
>     As suggested, the draft has been converted to xml format. Attached 
> are the update xml and txt files. I've included the change suggested by 
> Rod Walsh in the draft. Some entries in the Terminologies section are 
> copied from other RFCs, I hope that is bad practice for a candidate I-D. 
> Certainly, this draft needs more polishing. I take the liberty to send 
> it now, so that someone in this mailing list can help iron out some 
> issues. English is not my native tongue, please forgive me for my poor 
> command of the language.
> 
>     Thank you in advance.
> 
> Regards,
> Ang Way Chuang
> 
> Gorry Fairhurst wrote:
>>
>> Thanks for your contribution - let's still diuscuss the technical 
>> proposal and what should be done in this space using the ipdvb list - 
>> It's great to have some input for discussion of this.
>>
>> In parallel, I'd encourage you to look at the tools and let me know 
>> your thoughts and progress!
>>
>> Best wishes,
>>
>> Gorry
>>
>> Ang Way Chuang wrote:
>>> Gorry Fairhurst wrote:
>>>> Ang Way Chuang wrote:
>>>>> Sorry for the brief inlined reply.
>>>>>
>>>>> Gorry Fairhurst wrote:
>>>>>>
>>>>>> You should be able to post it yourself, I'll happily post it to 
>>>>>> the list for you to see if there is feedback. Can you tell us what 
>>>>>> you plan to do next?
>>>>>
>>>>> I think I know why the previous post failed. I am subscribed to the 
>>>>> mailing list via another email address (wcang at nrg.cs.usm.my) which 
>>>>> is an alias to the one I'm using.
>>>>>
>>>> Sounds likely.
>>>>
>>>>>>
>>>>>> If you were intending to submit a draft for consideration by the 
>>>>>> IETF, then you need to format it according to the guidelines shown 
>>>>>> at:
>>>>>> http://www.ietf.org/ietf/1id-guidelines.html
>>>>>
>>>>> Aye, we want to submit this draft for consideration by the IETF.
>>>>>
>>>> The first thing to decide is what editor you wish to use - some 
>>>> people use a text editor and nroff (these are in the minority), many 
>>>> still use a microsoft word template (the main way until a few years 
>>>> ago) and the rest use a XML-editor (now probably the best way). You 
>>>> could of course just try to write a text file, but as you receive 
>>>> comments and find that you have co-editors helping with the draft, 
>>>> this is likely to become too difficult to do.
>>>>
>>>> See:
>>>> http://www.rfc-editor.org/formatting.html
>>>> http://tools.ietf.org//inventory/author-tools
>>>>
>>>> A good start would be to get a XML or DOC file in the format you 
>>>> intend to use and add your text to this.
>>>>
>>>> The final Internet-Draft must conform to the fixed style (i.e. all 
>>>> sections well-formed:
>>>>
>>>> http://www.ietf.org/ID-Checklist.html
>>>> http://www.ietf.org/ietf/1id-guidelines.txt
>>>>
>>>> This means in practice that you need to upload the document to the 
>>>> checking tool at (this will tell you what is right and what is wrong)
>>>> http://www.tools.ietf.org/tools/idnits/
>>>
>>> Aye, thanks for the pointer.
>>>
>>>>
>>>> You may well be aware that there is a deadline prior to an IETF 
>>>> meeting, this is enforce today (which means you can not submit a new 
>>>> document after 5pm US time today).  You could try for this, but if 
>>>> this is your first draft, then this may well be too little time 
>>>> (it's easier if you've done this before).
>>>
>>> I see. I wasn't aware of that. This is our first draft, so I think it 
>>> is wiser to discuss first.
>>>
>>>>
>>>> In the mean-time it seems some people have started reading your 
>>>> inputs, so you could discuss this on the list and see if people agree.
>>>>
>>>> Gorry
>>>>
>>>> P.S. There is no formal IPDVB meeting at this IETF, or ROHC WG meeting,
>>>> but if you were attending then please do let me know and we can talk.
>>>>
>>>>>>
>>>>>> You can then upload the draft to the I-D repository using:
>>>>>> https://datatracker.ietf.org/idst/upload.cgi
>>>>>>
>>>>>> If you want help formatting and submitting this, please do let us 
>>>>>> know.
>>>>>
>>>>> Yes, we appreciate any form of help. Please help us with formatting 
>>>>> and submission. Thank you very much.
>>>>>
>>>>>>
>>>>>> Best wishes,
>>>>>>
>>>>>> Gorry
>>>>>>
>>>>>>
>>>>>> Ang Way Chuang wrote:
>>>>>>> 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 ipdvb at erg.abdn.ac.uk, but I 
>>>>>>> received no such email. I'm guessing the mailing list is not 
>>>>>>> working properly.
>>>>>>>
>>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Ang Way Chuang
>>>>>
>>>> Best wishes,
>>>>
>>>> Gorry
>>>>
>>>>
>>>
>>>
>>
>>
> 



From gorry at erg.abdn.ac.uk  Sat Feb 23 18:30:22 2008
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Sat, 23 Feb 2008 18:30:22 +0000
Subject: Draft for ROHC over DVB - comments on your text.
In-Reply-To: <47BE9B0F.3020100@nav6.org>
References: <47B82AF0.7080605@nav6.org> <47B8982A.2020007@erg.abdn.ac.uk> <47B8EE6F.4050005@nav6.org> <47B94AFB.5060909@erg.abdn.ac.uk> <47B95983.4070600@nav6.org> <47B95D6D.3020500@erg.abdn.ac.uk> <47BE9B0F.3020100@nav6.org>
Message-ID: <47C0663E.20100@erg.abdn.ac.uk>


I have a few questions about the draft from the ULE perspective, please 
see below.

Gorry


---------------------------------------------------------------------

1) ULE Type

There are two ways the Type field could be used, and I am not clear 
which you are proposing.

a) You could use a ULE Mandatory Extension Header. The value for this 
could be allocated by the IETF, if this were approved as an IETF RFC and 
that would certainly be one way to proceed that would allow you to embed 
ROHC functionality in the ULE/GSE Gateway and Receivers.

b) You could apply to the IEEE for an EtherType value from the IEEE 
Registry that would be applicable to all IEEE technologies (WiFi, 
wired-ethernet, etc) and which naturally could be used with ULE/GSE 
also, although you would still need to define how this was implemented, 
and how this interacted with ULE if you wanted to embed the compression 
and decompression in the ULE end-points rather than in the connected end 
host Ethernet drivers.

(it's a little wrong to speak of a "IANA assigned EtherType number" - 
since this mixes the two possibilities).

Comments and questions relating to this:

---
In section 3.1.2:

I don't understand the header format. The base-header has the type 
Ethernet - this means the encapsulated PDU must be an Ethernet Frame (as 
per RFC4326). A receiver should attempt to forward the PDU to the 
bridged LAN interface.

If you wanted a compressed ROHC payload in bridged mode, you'd probably 
need to define a new ULE-Type that denotes you are carrying a bridged 
ROHC PDU that needs to be decompressed prior to Receiver bridge 
processing - you probably also need to describe how this would work.

---

In Section 4.1:

"Since new EtherType is allocated, this
    protocol can be extended to asymmetrical link via Link-Layer
    Tunneling Mechanism [RFC3077]"

- UDLR uses IEEE EtherTypes, whereas ULE uses these, but includes its 
own extension formats. So this is only so, if you request an 
IEEE-allocated Ethertype, rather than a ULE-Type value from the IANA 
extensions registry.

---------------------------------------------------------------------
2) In Section 3.1.1:

"In the absence of multiple receivers, a transmitter can send an SNDU"...

I think this is only partially true, it may be safer to refer this to 
RFC4326, since this is also dependent on the way in which the ULE Stream 
is used.

---------------------------------------------------------------------
3) In section 3.2 (ROHC over MPEG2-TS):

- This format isn't clear to me, it seems you are trying to define a new 
types of Stream, which I guess is possible, but that would imply 
defining integrity checks, length, NPAs, etc - in much the same way as 
ULE was developed. This would perhaps at most save 2 bytes, but would be 
incompatible with the ULE framework. I'm not sure I understand the 
motivation here.

---------------------------------------------------------------------
4) In Section 4:

With the exclusion of section 3.2, this seems to apply to any ULE 
Stream (and probably a GSE stream) - independent of the physical layer 
(DVB, ATSC, or whatever).

In Section 4.1:

Again, with the exclusion of section 3.2, this could be applicable to GSE.
---------------------------------------------------------------------

Best wishes,

Gorry


I also have a few minor editorial comments (which may be helpful if you 
decide to prepare an updated draft):

---
Change
/ULE stream/
to
/ULE Stream
---

It would seem worthwhile drawing the diagrams in the same representation 
as other ULE Extensions, using the 32-bit wide format of:


        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 = 0x????         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

I'd suggest creating a two reference subsections, one
"Normative References"
and one
"Informative References"

I'd suggest replacing GSE with the ETSI Specification reference:

    [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream
    Encapsulation (GSE) Protocol, "European Telecommunication Standards,
    Institute (ETSI), 2007.

I'd suggesting a normative reference to:

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

I'd suggest placing the following as Informative references :

[DIX]
[ISO-MPEG2]
[ITU-H222]
[RFC3077]

You may like to provide an informational reference to the following for 
terminology and architecture:

    [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
    Nocker, B., and H. Linder, "A Framework for Transmission of IP
    Datagrams over MPEG-2 Networks", RFC 4259, November 2006.






From wcang at nav6.org  Sat Feb 23 18:42:39 2008
From: wcang at nav6.org (Ang Way Chuang)
Date: Sun, 24 Feb 2008 02:42:39 +0800
Subject: RFC: Draft for ROHC over DVB
In-Reply-To: <47C05CA1.8060907@erg.abdn.ac.uk>
References: <47B82AF0.7080605@nav6.org> <47B8982A.2020007@erg.abdn.ac.uk> <47B8EE6F.4050005@nav6.org> <47B94AFB.5060909@erg.abdn.ac.uk> <47B95983.4070600@nav6.org> <47B95D6D.3020500@erg.abdn.ac.uk> <47BE9B0F.3020100@nav6.org> <47C05CA1.8060907@erg.abdn.ac.uk>
Message-ID: <47C0691F.70307@nav6.org>

Gorry Fairhurst wrote:
> 
> According to naming conventions, the first version that is officially 
> published by the IETF should be named something like:
> 
> draft-wan-ipdvb-rohc-00.txt
> 
> (i.e. draft- followed by first author, followed by WG followed by title)
> 
> The format of the draft would have passed the ID-Submission process and 
> have been published except for the pre-IETF meeting cut-off.
> 
> I think this should therefore be uploaded as soon as the archives 
> re-open - but it would be good to get feedback from people on the 
> current text. I will also send some comments on the draft soon,

Thank you very much.

> 
> Best wishes,
> 
> Gorry
> 
> 
> Ang Way Chuang wrote:
>> Hi Gorry,
>>     As suggested, the draft has been converted to xml format. Attached 
>> are the update xml and txt files. I've included the change suggested 
>> by Rod Walsh in the draft. Some entries in the Terminologies section 
>> are copied from other RFCs, I hope that is bad practice for a 
>> candidate I-D. Certainly, this draft needs more polishing. I take the 
>> liberty to send it now, so that someone in this mailing list can help 
>> iron out some issues. English is not my native tongue, please forgive 
>> me for my poor command of the language.
>>
>>     Thank you in advance.
>>
>> Regards,
>> Ang Way Chuang
>>
>> Gorry Fairhurst wrote:
>>>
>>> Thanks for your contribution - let's still diuscuss the technical 
>>> proposal and what should be done in this space using the ipdvb list - 
>>> It's great to have some input for discussion of this.
>>>
>>> In parallel, I'd encourage you to look at the tools and let me know 
>>> your thoughts and progress!
>>>
>>> Best wishes,
>>>
>>> Gorry
>>>
>>> Ang Way Chuang wrote:
>>>> Gorry Fairhurst wrote:
>>>>> Ang Way Chuang wrote:
>>>>>> Sorry for the brief inlined reply.
>>>>>>
>>>>>> Gorry Fairhurst wrote:
>>>>>>>
>>>>>>> You should be able to post it yourself, I'll happily post it to 
>>>>>>> the list for you to see if there is feedback. Can you tell us 
>>>>>>> what you plan to do next?
>>>>>>
>>>>>> I think I know why the previous post failed. I am subscribed to 
>>>>>> the mailing list via another email address (wcang at nrg.cs.usm.my) 
>>>>>> which is an alias to the one I'm using.
>>>>>>
>>>>> Sounds likely.
>>>>>
>>>>>>>
>>>>>>> If you were intending to submit a draft for consideration by the 
>>>>>>> IETF, then you need to format it according to the guidelines 
>>>>>>> shown at:
>>>>>>> http://www.ietf.org/ietf/1id-guidelines.html
>>>>>>
>>>>>> Aye, we want to submit this draft for consideration by the IETF.
>>>>>>
>>>>> The first thing to decide is what editor you wish to use - some 
>>>>> people use a text editor and nroff (these are in the minority), 
>>>>> many still use a microsoft word template (the main way until a few 
>>>>> years ago) and the rest use a XML-editor (now probably the best 
>>>>> way). You could of course just try to write a text file, but as you 
>>>>> receive comments and find that you have co-editors helping with the 
>>>>> draft, this is likely to become too difficult to do.
>>>>>
>>>>> See:
>>>>> http://www.rfc-editor.org/formatting.html
>>>>> http://tools.ietf.org//inventory/author-tools
>>>>>
>>>>> A good start would be to get a XML or DOC file in the format you 
>>>>> intend to use and add your text to this.
>>>>>
>>>>> The final Internet-Draft must conform to the fixed style (i.e. all 
>>>>> sections well-formed:
>>>>>
>>>>> http://www.ietf.org/ID-Checklist.html
>>>>> http://www.ietf.org/ietf/1id-guidelines.txt
>>>>>
>>>>> This means in practice that you need to upload the document to the 
>>>>> checking tool at (this will tell you what is right and what is wrong)
>>>>> http://www.tools.ietf.org/tools/idnits/
>>>>
>>>> Aye, thanks for the pointer.
>>>>
>>>>>
>>>>> You may well be aware that there is a deadline prior to an IETF 
>>>>> meeting, this is enforce today (which means you can not submit a 
>>>>> new document after 5pm US time today).  You could try for this, but 
>>>>> if this is your first draft, then this may well be too little time 
>>>>> (it's easier if you've done this before).
>>>>
>>>> I see. I wasn't aware of that. This is our first draft, so I think 
>>>> it is wiser to discuss first.
>>>>
>>>>>
>>>>> In the mean-time it seems some people have started reading your 
>>>>> inputs, so you could discuss this on the list and see if people agree.
>>>>>
>>>>> Gorry
>>>>>
>>>>> P.S. There is no formal IPDVB meeting at this IETF, or ROHC WG 
>>>>> meeting,
>>>>> but if you were attending then please do let me know and we can talk.
>>>>>
>>>>>>>
>>>>>>> You can then upload the draft to the I-D repository using:
>>>>>>> https://datatracker.ietf.org/idst/upload.cgi
>>>>>>>
>>>>>>> If you want help formatting and submitting this, please do let us 
>>>>>>> know.
>>>>>>
>>>>>> Yes, we appreciate any form of help. Please help us with 
>>>>>> formatting and submission. Thank you very much.
>>>>>>
>>>>>>>
>>>>>>> Best wishes,
>>>>>>>
>>>>>>> Gorry
>>>>>>>
>>>>>>>
>>>>>>> Ang Way Chuang wrote:
>>>>>>>> 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 ipdvb at erg.abdn.ac.uk, but I 
>>>>>>>> received no such email. I'm guessing the mailing list is not 
>>>>>>>> working properly.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you very much.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Ang Way Chuang
>>>>>>
>>>>> Best wishes,
>>>>>
>>>>> Gorry
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 
>