Subject: Re: RFC: Draft for ROHC over DVB

From: Ang Way Chuang <[email-masked]>
Date: Fri, 22 Feb 2008 17:51:11 +0800

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 ([email-masked]) 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 [email-masked], but I 
>>>>>> received no such email. I'm guessing the mailing list is not 
>>>>>> working properly.
>>>>>>
>>>>>>
>>>>>> Thank you very much.
>>>>>>
>>>>>> Regards,
>>>>>> Ang Way Chuang
>>>>
>>> Best wishes,
>>>
>>> Gorry
>>>
>>>
>>
>>
> 
> 

Network Working Group                                      Tat-Chee. Wan
Internet-Draft                                           Way-Chuang. Ang
Intended status: Standards Track                          Chee Hong. Teh
Expires: August 25, 2008                       Universiti Sains Malaysia
                                                       February 22, 2008

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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Wan, et al.              Expires August 25, 2008                [Page 1]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

Abstract

   This paper introduces approach to carry ROHC packets over ULE and
   MPEG2-TS frames.  For completeness, ROHC Channel Parameters
   Negotiation Protocol (RCPNP) is also presented.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminologies  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Packet Format of ROHC Packet . . . . . . . . . . . . . . . . .  7
     3.1.  ROHC over ULE  . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Dedicated EtherType Fields for ROHC Compressed
               Packet . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  ROHC Compressed Packet as Payload of Ethernet
               Packet . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  ROHC over MPEG2-TS . . . . . . . . . . . . . . . . . . . .  8
   4.  Establishing ROHC Channel  . . . . . . . . . . . . . . . . . . 10
     4.1.  ROHC Channel Parameters Negotiation Protocol (RCPNP) . . . 10
       4.1.1.  Compressor Advertisement . . . . . . . . . . . . . . . 12
       4.1.2.  Compressor Solicitation  . . . . . . . . . . . . . . . 12
       4.1.3.  Request  . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.4.  Reply  . . . . . . . . . . . . . . . . . . . . . . . . 15
         4.1.4.1.  Medium Information . . . . . . . . . . . . . . . . 16
           4.1.4.1.1.  MPEG-2 TS Medium . . . . . . . . . . . . . . . 16
           4.1.4.1.2.  ULE Medium . . . . . . . . . . . . . . . . . . 17
       4.1.5.  Acknowledgement/Negative Acknowledgement . . . . . . . 18
       4.1.6.  Compressor Shutdown  . . . . . . . . . . . . . . . . . 18
       4.1.7.  Decompressor Shutdown  . . . . . . . . . . . . . . . . 18
     4.2.  Interaction of RCPNP . . . . . . . . . . . . . . . . . . . 19
   5.  Bidirectional ROHC Channels  . . . . . . . . . . . . . . . . . 20
   6.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26

Wan, et al.              Expires August 25, 2008                [Page 2]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

1.  Introduction

   This paper introduces approach to carry ROHC packets over ULE and
   MPEG2-TS frames.  For completeness, ROHC Channel Parameters
   Negotiation Protocol (RCPNP) is also presented.

Wan, et al.              Expires August 25, 2008                [Page 3]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

2.  Terminologies

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   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.

Wan, et al.              Expires August 25, 2008                [Page 4]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

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

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

   MRRU

      Maximum Reconstructed Reception Unit as defined in [RFC3095].

   Context Identifier

      [RFC3095] provides a definition for context identifiers.

   MSB

Wan, et al.              Expires August 25, 2008                [Page 5]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

      Most significant bit.

   LSB

      Least significant bit.

   ACK

      Acknowledgement.

   NACk

      Negative acknowledgement.

   CID

      Contect Identifier.

Wan, et al.              Expires August 25, 2008                [Page 6]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

3.  Packet Format of ROHC Packet

   This section briefly describes the notation used in all diagrams. ":"
   in a diagram indicates that the part is optional.  Likewise, "~" in a
   diagram indicates the number of octets by the part is not presented
   in a precise manner.  This situation appears when a field or part
   spans multiple or variable number of bytes.

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

           MSB                                           LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  D  |                                         |
           +-----+              Length                     +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                   Type=ROHC                   +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           :                                               :
           ~              Dest Address* (6 octets)         ~
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~    ROHC compressed packet (variable length)   ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~               CRC-32 (4 octets)               ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+

       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

Wan, et al.              Expires August 25, 2008                [Page 7]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

   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

           MSB                                           LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | D=1 |                                         |
           +-----+              Length                     +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                   Type=Ether                  +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~                Dest MAC (6 octets)            ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~              Source MAC (6 octets)            ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +              EtherType=ROHC                   +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~    ROHC compressed packet (varible length)    ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~               CRC-32 (4 octets)               ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+

    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:

Wan, et al.              Expires August 25, 2008                [Page 8]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

           +------+------------------------+--------+
           |Length| ROHC compressed packet | CRC-32 |
           +------+------------------------+--------+

      Figure 3: ROHC compressed packet compressed encapsulated direct
                      within MPEG2-TS frames' payload

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

   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.

Wan, et al.              Expires August 25, 2008                [Page 9]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

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 [RFC3077] 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

Wan, et al.              Expires August 25, 2008               [Page 10]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

           MSB                                           LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | D=1 |                                         |
           +-----+              Length                     +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                   Type=Ether                  +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~                Dest MAC (6 octets)            ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~              Source MAC (6 octets)            ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +              EtherType=ROHCNeg                +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~              Body (varible length)            ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           ~               CRC-32 (4 octets)               ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+

           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:

Wan, et al.              Expires August 25, 2008               [Page 11]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

           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

   This message is used by the compressor site to advertise the
   availability of ROHC Compressor.  Out of concern for bandwidth and
   energy consumption, compressor site should limit the broadcast of
   this message for a few times when it first join the network.  This
   message should also be broadcasted when a Compressor Solicitation
   message is received.  The decompressor site will use the value
   specified in the 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

   This message is broadcasted by decompressor to solicit for
   compressor.  X-bit is unused and should be ignored.  Decompressor
   site should rate-limit the frequency of solicitation if it is doesn't

Wan, et al.              Expires August 25, 2008               [Page 12]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

   receive any Compressor 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)              ~
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | Number of Media |                             |
           ~-----+-----+-----+   Medium Types              ~
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +             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 when it
   wishes to establish a ROHC channel.  The meaning of each fields in
   the message are described below:

   Maximum CID

Wan, et al.              Expires August 25, 2008               [Page 13]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

      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 Media

      The number of medium types carried in Medium Types field.

   Medium Types

      This field consists of all supported medium types by the
      decompressor.  Each medium type consists of 3 bits and corresponds
      to Medium field described in Medium Information (Section 4.1.4.1)
      section.  The number of bits used by Medium Types and Number of
      Media fields must be expanded to multiple of 8 if actual number of
      required bits is not multiple of 8.  The unused bits for such case
      should be ignored by Compressor site.

   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.

Wan, et al.              Expires August 25, 2008               [Page 14]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

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

Wan, et al.              Expires August 25, 2008               [Page 15]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

      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.
   When an unrecognized medium type is received, decompressor site
   should send an NACK message to compressor.

4.1.4.1.1.  MPEG-2 TS Medium

           MSB                                          LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |    Medium=0     |                             |
           +-----+-----+-----+      PID                    +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+

           Figure 12: Medium information for ROHC over MPEG2-TS

Wan, et al.              Expires August 25, 2008               [Page 16]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

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

Wan, et al.              Expires August 25, 2008               [Page 17]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

4.1.5.  Acknowledgement/Negative Acknowledgement

           MSB                                          LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |        Version=0      |   Operation=4   | Ack |
           +-----+-----+-----+-----+-----+-----+-----+-----+

               Figure 14: 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 15: 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

Wan, et al.              Expires August 25, 2008               [Page 18]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

           MSB                                          LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |        Version=0      |   Operation=6   |  X  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

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

                     Figure 17: Packets flow of RCPNP

Wan, et al.              Expires August 25, 2008               [Page 19]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

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

Wan, et al.              Expires August 25, 2008               [Page 20]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

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

Wan, et al.              Expires August 25, 2008               [Page 21]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

7.  Acknowledgements

   We would like to thank Rod Walsh (Nokia) for his valuable input and
   feedback.

   We also want to extend our gratitude to Dr. Gorry Fairhurst for his
   guidance.

Wan, et al.              Expires August 25, 2008               [Page 22]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

8.  Security Considerations

   - None -

Wan, et al.              Expires August 25, 2008               [Page 23]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

9.  Normative References

   [DIX]      Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet
              Local Area Network Specification Version 2.0",
              November 1982.

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

   [IEEE-802.3]
              IEEE 802.3, "Local and metropolitan area networks-Specific
              requirements Part 3: Carrier sense multiple access with
              collision detection (CSMA/CD) access method and physical
              layer specifications", IEEE Computer Society, (also ISO/
              IEC 8802-3), 2000.

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

   [ITU-H222]
              H.222.0, "Information technology - Generic coding of
              moving pictures and associated audio information: Systems,
              International Telecommunication Union, (ITU-T)", 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3095]  Borman, C., "RObust Header Compression (ROHC): Framework
              and four profiles: RTP, UDP, ESP, and uncompressed",
              RFC 3095, 2001.

Wan, et al.              Expires August 25, 2008               [Page 24]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

Authors' Addresses

   Tat-Chee Wan
   Universiti Sains Malaysia
   School of Computer Science
   Universiti Sains Malaysia
   Penang
   Malaysia

   Phone: +6 04 653 4633
   Email: [email-masked]
   URI:   http://nrg.cs.usm.my/~tcwan

   Way-Chuang Ang
   Universiti Sains Malaysia
   School of Computer Science
   Universiti Sains Malaysia
   Penang
   Malaysia

   Email: [email-masked]

   Chee-Hong Teh
   Universiti Sains Malaysia
   School of Computer Science
   Universiti Sains Malaysia
   Penang
   Malaysia

   Email: [email-masked]

Wan, et al.              Expires August 25, 2008               [Page 25]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames      February 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Wan, et al.              Expires August 25, 2008               [Page 26]

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="std" ipr="full3978" docName="draft-rohc-dvb-01.txt">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc tocindent='yes'?>
<?rfc tocdepth="5"?>

    <front>
        <title abbrev= 'ROHC over ULE and MPEG-2 TS frames'>
         Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames
        </title>
        <author initials='Tat-Chee' surname="Wan" fullname='Tat-Chee Wan'>
            <organization>Universiti Sains Malaysia</organization>
	    	<address>
	    	<postal>
			<street>School of Computer Science</street>
			<street>Universiti Sains Malaysia</street>
			<city>Penang</city>
			<country>Malaysia</country>
                </postal>
		<phone>+6 04 653 4633</phone>
		<email>[email-masked]</email>
		<uri>http://nrg.cs.usm.my/~tcwan</uri>
		</address>
        </author>
        <author initials='Way-Chuang' surname="Ang" fullname='Way-Chuang Ang'>
            <organization>Universiti Sains Malaysia</organization>
	    	<address>
	    	<postal>
			<street>School of Computer Science</street>
			<street>Universiti Sains Malaysia</street>
			<city>Penang</city>
			<country>Malaysia</country>
                </postal>
		<email>[email-masked]</email>
		</address>
        </author>
        <author initials='Chee Hong' surname="Teh" fullname='Chee-Hong Teh'>
            <organization>Universiti Sains Malaysia</organization>
	    	<address>
	    	<postal>
			<street>School of Computer Science</street>
			<street>Universiti Sains Malaysia</street>
			<city>Penang</city>
			<country>Malaysia</country>
                </postal>
		<email>[email-masked]</email>
		</address>
        </author>
        <date/>
        <abstract><t>This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS frames. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented.</t></abstract>
    </front>

    <middle>
        <section title="Introduction">
	    <t>This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS frames. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented.</t>
	</section>

	<section title="Terminologies">
            <t>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 <xref target="RFC2119"/>.

	    <list style="hanging">
		<t hangText="DVB"></t>
		   <t>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 <xref target="ISO-MPEG2" />.</t>

		<t hangText="MAC"></t>
		   <t>Medium Access Control <xref target="IEEE-802.3" />. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 <xref target="DIX" />).</t>
		
		<t hangText="MPEG-2"></t>
		   <t> A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) <xref target="ISO-MPEG2" />, and ITU-T (in H.222 <xref target="ITU-H222" />).</t>
		
		<t hangText="PDU"></t>
		   <t>Protocol Data Unit.  Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.</t>

		<t hangText="Receiver"></t>
		   <t>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).</t>

		<t hangText="Transmitter"></t>
		  <t>Router or host that sends data.</t>
		
		<t hangText="SNDU"></t>
		  <t>SubNetwork Data Unit.  An encapsulated PDU sent as an MPEG-2 Payload Unit.</t>
		
		<t hangText="TS"></t>
		  <t>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.</t>

		<t hangText="ULE stream"></t>
		  <t>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 <xref target="ISO-MPEG2" />.</t>

		<t hangText="ROHC"></t>
		  <t>Robust Header Compression. A framework of compression headers of IP packet as defined in <xref target="RFC3095" />.</t>
		
		<t hangText="ROHC channel"></t>
		  <t> 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.</t>

		<t hangText="ROHC profile"></t>
		  <t> 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.</t>

		<t hangText="MRRU"></t>
		  <t>Maximum Reconstructed Reception Unit as defined in <xref target="RFC3095" />.</t>
		
		<t hangText="Context Identifier"></t>
		  <t><xref target="RFC3095" />  provides a definition for context identifiers.</t>

		<t hangText="MSB"></t>
		  <t>Most significant bit.</t>
		
		<t hangText="LSB"></t>
		  <t>Least significant bit.</t>

		<t hangText="ACK"></t>
		  <t>Acknowledgement.</t>

		<t hangText="NACk"></t>
		  <t>Negative acknowledgement.</t>

		<t hangText="CID"></t>
		  <t>Contect Identifier.</t>
	    </list>
	    </t>
        </section>

        <section title="Packet Format of ROHC Packet">
         <t>This section briefly describes the notation used in all diagrams. ":" in a diagram indicates that the part is optional. Likewise, "~" in a diagram indicates the number of octets by the part is not presented in a precise manner. This situation appears when a field or part spans multiple or variable number of bytes.</t>
	  <section title="ROHC over ULE"> 
	    <t> The packet format for ROHC packet encapsulated can be in one the following two formats:</t>
	    <section title="Dedicated EtherType Fields for ROHC Compressed Packet">
	      <figure anchor="Figure 1:" title="ROHC compressed packet encapsulated using dedicated EtherType">
		<artwork><![CDATA[
        MSB                                           LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |  D  |                                         |
        +-----+              Length                     +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +                   Type=ROHC                   +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        :                                               :
        ~              Dest Address* (6 octets)         ~
        :                                               :
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~    ROHC compressed packet (variable length)   ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~               CRC-32 (4 octets)               ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
		]]></artwork>
	      </figure>	
		<t> 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.
		</t>

		 <t>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.
		</t>
            </section>
	    
            <section title="ROHC Compressed Packet as Payload of Ethernet Packet"> 
	      <figure anchor="Figure 2:" title="ROHC compressed packet encapsulated in SNDU bridged frame">
		 <artwork><![CDATA[
        MSB                                           LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | D=1 |                                         |
        +-----+              Length                     +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +                   Type=Ether                  +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~                Dest MAC (6 octets)            ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~              Source MAC (6 octets)            ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +              EtherType=ROHC                   +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~    ROHC compressed packet (varible length)    ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~               CRC-32 (4 octets)               ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
		]]></artwork>
	      </figure>	
		<t> 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.
		</t>
            </section>
          </section>

	  <section title=" ROHC over MPEG2-TS">
	    <t> This encapsulation format is the smallest packet format in terms of packet size. The format of SNDU is the following format:</t>
	       <figure anchor="Figure 3:" title="ROHC compressed packet compressed encapsulated direct within MPEG2-TS frames' payload">
                 <artwork><![CDATA[
        +------+------------------------+--------+
        |Length| ROHC compressed packet | CRC-32 |
        +------+------------------------+--------+
		 ]]></artwork>
              </figure>
 	   <t>The meaning of each fields is specified below: 
	   <list style="hanging">
		<t hangText="Length"></t> 
		   <t>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.</t>

		<t hangText="ROHC Compressed Packet"></t>
		   <t>ROHC compressed packet as defined in section 5.2 of <xref target="RFC3095" />.</t>
		<t hangText="CRC-32"></t>
		   <t>The 32-bit CRC is calculated over Length filed and ROHC compressed packet. The polynomial used to calculate the CRC is 0x104C11DB7.</t>
		    
                   <t>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.</t>
	      </list>
	     </t>
            </section>
           </section>

	 <section title="Establishing ROHC Channel">
	   <t>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.
           </t>
	   <t> 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.
           </t>
           <section title="ROHC Channel Parameters Negotiation Protocol (RCPNP)">
	     <t>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 <xref target="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 <xref target="RFC3077" /> with little modifications.
	     </t>
             <t>The basic format of ULE SNDU packet is as such: 	   
	     </t>
		 <figure anchor="Figure 4:" title="Minimal format of RCPNP message">
                   <artwork><![CDATA[
        +---+--------+------------+----------+--------+
        |D=1| Length |Type=ROHCNeg|   Body   | CRC-32 |
        +---+--------+------------+----------+--------+
                   ]]></artwork>
                 </figure>
		<figure anchor="Figure 5:" title="RCPNP message encapsulated in bridged frame">
                   <artwork><![CDATA[
        MSB                                           LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | D=1 |                                         |
        +-----+              Length                     +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +                   Type=Ether                  +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~                Dest MAC (6 octets)            ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~              Source MAC (6 octets)            ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +              EtherType=ROHCNeg                +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~              Body (varible length)            ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~               CRC-32 (4 octets)               ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
                   ]]></artwork>
                 </figure>
	      <t>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.
	      </t>
	      <t>The basic format for these messages is depicted is as such:
	      </t>
		 <figure anchor="Figure 6:" title="Basic format of RCPNP Body field">
                   <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |        Version        |    Operation    |  X  |
        +-----+-----+-----+-----+-----+-----+-----+-----+
                   ]]></artwork>
                 </figure>
	       <t>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.
	       </t>
		     <section title="Compressor Advertisement">
			<figure anchor="Figure 7:" title="Format of Compressor Advertisement message">
                   	  <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |        Version=0      |   Operation=0   |  X  |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~              Address (6 octets)               ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
                   	  ]]></artwork>
                 	</figure>
	       		<t>This message is used by the compressor site to advertise the availability of ROHC Compressor. Out of concern for bandwidth and energy consumption, compressor site should limit the broadcast of this message for a few times when it first join the network. This message should also be broadcasted when a Compressor Solicitation message is received. The decompressor site will use the value specified in the Address field when addressing compressor site. X-bit is unused and should be ignored.
	       		</t>
             	      </section>
	     	      <section title="Compressor Solicitation" >
		 	<figure anchor="Figure 8:" title="Format of Compressor Solicitation message">
                          <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |        Version=0      |   Operation=1   |  X  |
        +-----+-----+-----+-----+-----+-----+-----+-----+
			   ]]></artwork>
                 	</figure>
			<t> This message is broadcasted by decompressor to solicit for compressor. X-bit is unused and should be ignored. Decompressor site should rate-limit the frequency of solicitation if it is doesn't receive any Compressor Advertisement to avoid flooding DVB link.
			</t>
             	      </section>
	     	      <section title="Request" >
		 	<figure anchor="Figure 9:" title="Format of Request message">
                          <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |        Version=0      |   Operation=2   |  X  |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +                  Maximum CID                  +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        ~                  MRRU (4 octets)              ~
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | Number of Media |                             |
        ~-----+-----+-----+   Medium Types              ~
        :                                               :
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +             Num of profiles                   +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                                               |
        +                Profile ID 1                   +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        :                                               :
        +                Profile ID 2                   +
        :                                               :
        +-----+-----+-----+-----+-----+-----+-----+-----+
        :                                               :
        +                Profile ID N                   +
        :|                                              :
        +-----+-----+-----+-----+-----+-----+-----+-----+
			   ]]></artwork>
                 	</figure>
			<t>This message is sent by decompressor site to compressor site when it wishes to establish a ROHC channel. The meaning of each fields in the message are described below:
			   <list style="hanging">
		              <t hangText="Maximum CID"></t>
				<t>Maximum Context Identifier tolerated by decompressor.
				</t>

		              <t hangText="MRRU"></t>
				<t>Maximum Reconstructed Reception Unit tolerated by decompressor. Value of 0 indicates the negotiated channel doesn't allow for segmentation of ROHC compressed packet.
				</t>
		              <t hangText="Number of Media"></t>
                              <t>The number of medium types carried in Medium Types field.</t>
                              <t hangText="Medium Types"></t>
                              <t>This field consists of all supported medium types by the decompressor. Each medium type consists of 3 bits and corresponds to Medium field described in <xref target="medium"> Medium Information</xref> section. The number of bits used by Medium Types and Number of Media fields must be expanded to multiple of 8 if actual number of required bits is not multiple of 8. The unused bits for such case should be ignored by Compressor site.</t>
				<t hangText="Number of profiles"></t>
				<t>Number of profiles supported by decompressor.
				</t>
				<t hangText="Profile IDs"></t>
				<t>ROHC Profile IDs supported by decompressor. Each profile ID occupy 2 octets.
				</t>
				<t>X-bit is unused and should be ignored.
				</t>
			   </list>
			</t>
             	      </section>
	     	      
		      <section title="Reply" >
		 	<figure anchor="Figure 10:" title="Format of Reply message">
                          <artwork><![CDATA[
        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                   +
        :                                               :
        +-----+-----+-----+-----+-----+-----+-----+-----+
			   ]]></artwork>
                 	</figure>
			<t>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:
			 <list style="hanging">
                              <t hangText="Maximum CID"></t>
                                <t>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.
                                </t>

                                <t hangText="MRRU"></t>
				<t>Maximum Reconstructed Reception Unit tolerated by compressor. Likewise, decompressor site should send a NACK if it is receives higher MRRU than what it requested.
				</t>
					
                                <t hangText="Number of profile IDs"></t>
				<t>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.
				</t>

                                <t hangText="Profile IDs"></t>
				<t>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.
				</t>
				<t>X-bit is unused and should be ignored.</t>
				</list>
		        </t>
					
					<section title="Medium Information" anchor="medium">
					   <t> The following notation depicted in the previous figure 10 indicates the presence of medium information.
					   </t>
					 	<figure>
			                          <artwork><![CDATA[
        +===============================================+
			   			  ]]></artwork>
                 				  </figure>
					   <t> 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. When an unrecognized medium type is received, decompressor site should send an NACK message to compressor.
					   </t>
						
						<section title="MPEG-2 TS Medium" >
						   <figure anchor="Figure 11:" title="Medium information for ROHC over MPEG2-TS">
                                                     <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |    Medium=0     |                             |
        +-----+-----+-----+      PID                    +
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
						    ]]></artwork>
                                                  </figure>		
					          <t>
						  <list style="hanging">
						    <t hangText="PID" ></t>
						       <t>Packet Identifier of MPEG2-TS frames that will carry ROHC compressed packet.</t>
						  </list>
						  </t> 
						</section>
						
						<section title="ULE Medium" >
						   <figure anchor="Figure 12:" title="Medium information for ROHC over ULE">
                                                     <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |    Medium=1     |  ULE Type |    Reserved     |
        +-----+-----+-----+-----+-----+-----+-----+-----+
						    ]]></artwork>
                                                  </figure>
						  <t>ULE Type:
						  <list style="hanging">
						    <t hangText="0" ></t>
						  	<t>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.
							</t>
						
						    <t hangText="1" ></t>
							<t>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.
							</t>

						    <t hangText="2" ></t>
							<t>ROHC packets will be encapsulated in Ethernet bridged frame. This option is used when there multiple transmitters and receivers over a DVB link.
							</t>
			
						    <t hangText="3" ></t>
							<t>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.
							</t>
						  </list>
						  </t>
						  <t>Reserved field is not used and should be ignored.</t>
						</section>
             				</section>
		
             		</section>
	          <section title="Acknowledgement/Negative Acknowledgement" >
		    <figure anchor="Figure 13:" title="Format of Acknowledgement message">
                          <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |        Version=0      |   Operation=4   | Ack |
        +-----+-----+-----+-----+-----+-----+-----+-----+
			   ]]></artwork>
                     </figure>
		    <t>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.
		   </t>
		  </section>

		  <section title="Compressor Shutdown" >
		    <figure anchor="Figure 14:" title="Format of Compressor Shutdown message">
                       <artwork><![CDATA[
          MSB                                          LSB
            0     1     2     3     4     5     6     7
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |        Version=0      |   Operation=5   |  X  |
         +-----+-----+-----+-----+-----+-----+-----+-----+
			   ]]></artwork>
                     </figure>
		    <t>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.
                    </t>
		    <t>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.
		    </t>
		    <t>X-bit is unused and should be ignored.
		    </t>
		  </section>

		  <section title="Decompressor Shutdown" >
		    <figure anchor="Figure 15:" title="Format of Decompressor Shutdown message">
                       <artwork><![CDATA[
        MSB                                          LSB
           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |        Version=0      |   Operation=6   |  X  |
        +-----+-----+-----+-----+-----+-----+-----+-----+
			   ]]></artwork>
                     </figure>
		   <t>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.
		   </t>
		   <t>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.
		   </t>
		   <t>X-bit is unused and should be ignored.
		   </t>
		  </section>
             </section>
	    
             <section title="Interaction of RCPNP">
		<t>The following diagram depicts a possible interaction between compressor site and decompressor site in negotiating ROHC channel parameters.
		</t>

   	    <figure anchor="Figure 16:" title="Packets flow of RCPNP">
               <artwork><![CDATA[
      Compressor Site                                 Decompressor Site
            |<---------------- Solicit ---------------|
            |                                         |
            |-------------- Advertise --------------->|
            |                                         |
            |<-------------- Request -----------------|
            |                                         |
            |---------------- Reply ----------------->|
            |                                         | Create instance
            |                                         | of decompressor
Create      |<---------------- ACK -------------------|
compressor  |                                         |
            |                                         |
            |= (Compression can begin at this point) =|
            |                                         |
            |                                         |
Destroy     |<------- Decompressor Shutdown ----------|
compressor  |                                         |
            |----------------- ACK --- -------------->| Destroy
            |                                         | decompressor
	        ]]></artwork>
               </figure>
	     </section>
	
           </section>

            <section title="Bidirectional ROHC Channels">
	    <t>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.
	    </t>
           </section>

	<section title="IANA Consideration">
	  <t>Two EtherTypes should be assigned. One of it is for RCPNP and the other is to indicate the presence of ROHC compressed packet.
	  </t>
        </section>

	<section title="Acknowledgements">
	  <t>We would like to thank Rod Walsh (Nokia) for his valuable input and feedback.
	  </t>
	  <t>We also want to extend our gratitude to Dr. Gorry Fairhurst for his guidance.
	  </t>
        </section>

	<section title="Security Considerations">
	  <t>- None -
          </t>
        </section>
    </middle>

    <back>
	  <references title='Normative References'>&rfc2119;
	  <reference anchor="ISO-MPEG2">
	    <front>
	      <title>Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems</title>
	      <author>
	        <organization abbrev="ISO">ISO 13818-1</organization>
		<address>
		<postal>
		  <street></street>
		  <city></city>
		  <country></country>
		</postal>
		</address>
              </author>
	      <date year="2000" />
            </front>
	    <seriesInfo name="International Standards Organisation" value="(ISO)" />
	  </reference>
	
	 <reference anchor="IEEE-802.3">
            <front>
              <title>Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications  </title>
              <author>
                <organization>IEEE 802.3</organization>
                <address>
                <postal>
                  <street></street>
                  <city></city>
                  <country></country>
                </postal>
                </address>
              </author>
              <date year="2000" />
            </front>
	    <seriesInfo name="IEEE Computer Society," value="(also ISO/IEC 8802-3)"/>
          </reference>
	
	<reference anchor="DIX">
            <front>
              <title>Ethernet Local Area Network Specification Version 2.0</title>
              <author>
                <organization>Digital Equipment Corp, Intel Corp, Xerox Corp</organization>
                <address>
                <postal>
                  <street></street>
                  <city></city>
                  <country></country>
                </postal>
                </address>
              </author>
              <date month="November" year="1982" />
            </front>
          </reference>
	
	 <reference anchor="ITU-H222">
            <front>
              <title>Information technology - Generic coding of moving pictures and associated audio information: Systems, International Telecommunication Union, (ITU-T)</title>
              <author>
                <organization>H.222.0</organization>
                <address>
                <postal>
                  <street></street>
                  <city></city>
                  <country></country>
                </postal>
                </address>
              </author>
              <date year="1995" />
            </front>
          </reference>

	<reference anchor="RFC3095">
            <front>
              <title>RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed</title>
              <author initials="C. et al" surname="Borman" fullname="Borman,C. et al">
                <organization></organization>
                <address>
                <postal>
                  <street></street>
                  <city></city>
                  <country></country>
                </postal>
                </address>
              </author>
              <date year="2001" />
            </front>
	    <seriesInfo name="RFC" value="3095" />
          </reference>
	
	<reference anchor="GSE">
            <front>
              <title>"Generic Stream Encapsulation (GSE) Protocol</title>
              <author>
                <organization abbrev="DVB">Digital Video Broadcasting</organization>
                <address>
                <postal>
                  <street></street>
                  <city></city>
                  <country></country>
                </postal>
                </address>
              </author>
              <date year="2007" />
            </front>
            <seriesInfo name="DVB Document" value="A116" />
          </reference>

	 <reference anchor="RFC3077">
            <front>
              <title>A Link-Layer Tunneling Mechanism for Unidirectional Links</title>
              <author initials="E. et al" surname="Duros" fullname="Duros, E. et al">
                <organization></organization>
                <address>
                <postal>
                  <street></street>
                  <city></city>
                  <country></country>
                </postal>
                </address>
              </author>
              <date year="2001" />
            </front>
            <seriesInfo name="RFC" value="3077" />
          </reference>

	</references>
    </back>

</rfc>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 23 Feb 2008 17:49:21 +0000

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. 
>> 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:
>>>>>> 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?
>>>>>
>>>> this is your first draft, then this may well be too little time 
>>>> (it's easier if you've done this before).
>>>
>>>>>>> copied from other Internet Drafts and RFCs. I think they are 
>>>>>>> still incomplete.
>>>>>>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 23 Feb 2008 18:30:22 +0000

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: Ang Way Chuang <[email-masked]>
Date: Sun, 24 Feb 2008 02:42:39 +0800

Thank you very much.

>> 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:
>>>
>>>>>>> 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 ([email-masked]) 
>>>>>> which is an alias to the one I'm using.
>>>>>>
>>>>> Sounds likely.
>>>>>
>>>>>>>
>>>>> 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:
>>>>> 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 
>>>> I see. I wasn't aware of that. This is our first draft, so I think 
>>>> it is wiser to discuss first.
>>>>
>>>>>
>>>>>> 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: