Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 21 Mar 2008 12:44:50 +0000

Here is a copy of the I-D previously circulated on the list. This has 
been published in the IETF I-D database. A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt

Comments and discussion is invited on this list.

AUTHORS: Please note the name of the file. If you wish to submit an 
updated revision the new version should be: draft-wan-ipdvb-rohc-01.txt

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

---

To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt
From: Internet-Drafts at ietf.org
Date: Wed, 19 Mar 2008 11:00:01 -0700 (PDT)
Cc:
<mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:[email-masked]?subject=unsubscribe>
Reply-to: internet-drafts at ietf.org
Sender: i-d-announce-bounces at ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Robust Header Compression over Unidirectional Lightweight 
Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames
	Author(s)	: T. Wan, W. Ang, C. Teh
	Filename	: draft-wan-ipdvb-rohc-00.txt
	Pages		: 26
	Date		: 2008-3-19
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt>

---

From: Ang Way Chuang <[email-masked]>
Date: Mon, 24 Mar 2008 14:59:54 +0800

Dear Dr. Fairhurst,

Here is updated version according your previous feedback, but still 
incomplete. I removed the section that carries ROHC compressed packet 
directly over MPEG2-TS. So, what works for ULE should also work for GSE 
except for section 4.1.4.1.1 which relies on MPEG2-TS.

In addition to 2 new ULE type, we also need to have a new EtherType for 
section 3.1.2. If getting new EtherType is hard, we may need to redefine 
the packet format.

As for your previous comment:
 > 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.

I'm not sure what you meant exactly. I refer to figure 11 of RFC4326 and 
  the Receiver Destination NPA address field seems redundant since MAC 
destination address is there. Any practical scenario where Receiver 
Destination needs to be different from MAC destination address?

Diagrams has been changed to conform with the style used by RFC4326, but 
  style of diagram 4, 5, 6 and 7 is left untouched since it is difficult 
to represent variable format imposed by medium information using the 
former style.

Thank you.

Regards,
Ang Way Chuang

Gorry Fairhurst wrote:
> Delivered-to: ietfarch-i-d-announce-web-archive at core3.amsl.com
> Delivered-to: i-d-announce at core3.amsl.com
> List-archive: <http://www.ietf.org/pipermail/i-d-announce>
> List-help: <mailto:[email-masked]?subject=help>
> List-id: Internet Draft Announcements <i-d-announce.ietf.org>
> List-post: <mailto:[email-masked]>
> List-subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, 
>     Title        : Robust Header Compression over Unidirectional 
> Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames
>     Filename    : draft-wan-ipdvb-rohc-00.txtNPA
>     Pages        : 26
>     Date        : 2008-3-19
>     

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

Robust Header Compression over Unidirectional Lightweight Encapsulation
                             (ULE) packets
                      draft-wan-ipdvb-rohc-01.txt

Status of this Memo

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

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

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

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

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

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

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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

Abstract

   This document introduces approach to carry ROHC packets over ULE
   packets.  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 IANA ULE Type for ROHC Compressed Packet . .  7
       3.1.2.  ROHC Compressed Packet as Payload of Ethernet
               Packet . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Establishing ROHC Channel  . . . . . . . . . . . . . . . . . .  9
     4.1.  ROHC Channel Parameters Negotiation Protocol (RCPNP) . . .  9
       4.1.1.  Compressor Advertisement . . . . . . . . . . . . . . . 11
       4.1.2.  Compressor Solicitation  . . . . . . . . . . . . . . . 11
       4.1.3.  Request  . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.4.  Reply  . . . . . . . . . . . . . . . . . . . . . . . . 15
         4.1.4.1.  Medium Information . . . . . . . . . . . . . . . . 16
           4.1.4.1.1.  Dedicated PID space  . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . 19
     4.2.  Interaction of RCPNP . . . . . . . . . . . . . . . . . . . 19
   5.  Bidirectional ROHC Channels  . . . . . . . . . . . . . . . . . 21
   6.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

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

1.  Introduction

   This document introduces approach to carry ROHC packets over ULE
   packets.  For completeness, ROHC Channel Parameters Negotiation
   Protocol (RCPNP) is also presented.  FIXME: more details

Wan, et al.            Expires September 25, 2008               [Page 3]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 September 25, 2008               [Page 4]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 September 25, 2008               [Page 5]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 2008

      Most significant bit.

   LSB

      Least significant bit.

   ACK

      Acknowledgement.

   NACk

      Negative acknowledgement.

   CID

      Contect Identifier.

Wan, et al.            Expires September 25, 2008               [Page 6]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 compressed packet encapsulated within ULE
   can be in one the following two formats:

3.1.1.  Dedicated IANA ULE Type for ROHC Compressed Packet

        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 = ROHC ULE       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Address* (6B)                 |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                    RoHC compressed packet                     |
       =                                                               =
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            CRC-32                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 1: ROHC compressed packet encapsulated using dedicated ULE
                                   type

   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 ULE type value to indicate the
   presence of ROHC compressed packet in PDU.

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

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

3.1.2.  ROHC Compressed Packet as Payload of Ethernet Packet

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |D|        Length  (15b)        |         Type = 0x0001         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Destination MAC  (6B)                 |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                           Source MAC (6B)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     EtherType = ROHC Ether    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                  RoHC compressed packet                       |
       =                                                               =
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            CRC-32                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: ROHC compressed packet encapsulated in SNDU bridged frame

   This packet format should be used when there are multiple
   transmitters and receivers over a DVB link.  A new EtherType value
   needs to be assigned for this.

Wan, et al.            Expires September 25, 2008               [Page 8]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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
   present 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 can be allocated, this
   protocol can be extended to asymmetrical link via Link-Layer
   Tunneling Mechanism [RFC3077] with little modifications.

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

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

        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 = RoHC Neg       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Address* (6B)                 |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |Version|OpCod|X|               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
       |                     Source Address * (6B)                     |
       +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               |                                               |
       +-+-+-+-+-+-+-+-+                                               =
       |                            Body *                             |
       =                                                               =
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            CRC-32                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: Minimal format of RCPNP message

   Type

      New ULE type need to be assigned for ROHC negotiation protocol.

   Destination Address

      Destination address field should exist for all types of message
      except for Compressor Solicitation and Compressor Advertisement
      messages.

   Version

      Version of ROHC Channel Parameters Negotiation Protocol (RCPNP).
      Currently, only version 0 is supported.

   OpCod

      OpCod field is an abbreviation for Operation Code.  The value of
      Operation Code field determines the message type.

   X

      This bit is not used in most messages and should be ignored unless
      specified otherwise.

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

   Source Address

      Source address field should exist for all messages except for
      Compressor Solicitation message and is used to indicate the
      address of the sender.

   Body

      Body of message.  This content of this field is dependent on
      Operation Code.  This field may not be present for certain type of
      messages.

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

4.1.1.  Compressor Advertisement

   Operation Code

      The value is 0.

   Destination Address

      This field is not present in this message.

   Body

      This field is not present in this message.

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

4.1.2.  Compressor Solicitation

   Operation Code

      The value is 1.

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

   Destination Address

      This field is not present in this message.

   Source Address

      This field is not present in this message.

   Body

      This field is not present in this message.

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

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

4.1.3.  Request

           MSB                                          LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           =                  MRRU (4 octets)              =
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                  Maximum CID                  +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | Number of Media |                             |
           =-----+-----+-----+   Medium Types              =
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +             Num of profiles                   +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                Profile ID 1                   +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           :                                               :
           +                Profile ID 2                   +
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+
           :                                               :
           +                Profile ID N                   +
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+

                    Figure 4: Format of Request message

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

   Operation Code

      Not shown in the diagram, but this field carries the value of 2.

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

   MRRU

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

   Maximum CID

      Maximum Context Identifier tolerated by decompressor.

   Number of 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
      occupies 2 octets.

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

4.1.4.  Reply

           MSB                                          LSB
              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           =                  MRRU (4 octets)              =
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                  Maximum CID                  +
           |                                               |
           +===============================================+
           |             Num of profiles                   |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                                               |
           +                Profile ID 1                   +
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           :                                               :
           +                Profile ID 2                   +
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+
           :                                               :
           +                Profile ID N                   +
           :                                               :
           +-----+-----+-----+-----+-----+-----+-----+-----+

                     Figure 5: Format of Reply message

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

   Operation Code

      Not shown in the diagram, but this field carries the value of 3.

   MRRU

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

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

   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.

   Number of profile IDs

      Note that this field occupies 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.  FIXME: Add more notes here.

   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.

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 over ULE packets.  The details of packet
   format for ROHC over ULE are 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 a NACK message to compressor.

4.1.4.1.1.  Dedicated PID space

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

     Figure 6: Medium information for ROHC over ULE over dedicated PID
                                   space

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

   PID

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

   This approach should only be used when the current negotiating PID
   channel of MPEG2-TS is shared by multiple senders and receivers and
   the need to shave off the destination and source addresses from each
   ULE packet at the cost of using additional PID is reasonable.  It is
   pointless to use this approach the PID channel of MPEG2-TS is only
   used for Point to Point communication between a sender and a receiver
   where there is no need to send source and destination addresses.  For
   such case, compressor site should opt the approach mentioned in the
   next section.

4.1.4.1.2.  ULE Medium

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

              Figure 7: Medium information for ROHC over 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.  This is similar
      to what is mentioned in section Section 4.1.4.1.1, but without the
      cost of additional PID channel.

   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

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

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

   3

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

   Reserved field is not used and should be ignored.

4.1.5.  Acknowledgement/Negative Acknowledgement

   Operation Code

      The value is 4.

   X

      If this bit is set, this message is an acknowledgement.
      Otherwise, it is a negative acknowledgement.

   Body

      This field is not present in this message.

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

4.1.6.  Compressor Shutdown

   Operation Code

      The value is 5.

   Body

      This field is not present in this message.

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

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

   resources that are being held for decompression.

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

4.1.7.  Decompressor Shutdown

   Operation Code

      The value is 6.

   Body

      This field is not present in this message.

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

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

4.2.  Interaction of RCPNP

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

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

       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 8: Packets flow of RCPNP

Wan, et al.            Expires September 25, 2008              [Page 20]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 September 25, 2008              [Page 21]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 2008

6.  IANA Consideration

   Two ULE types 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 September 25, 2008              [Page 22]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 September 25, 2008              [Page 23]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 2008

8.  Security Considerations

   - None -

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

9.  References

9.1.  Normative References

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

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

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

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

9.2.  Informative References

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

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

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

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

Wan, et al.            Expires September 25, 2008              [Page 25]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 September 25, 2008              [Page 26]

Internet-Draft     ROHC over ULE and MPEG-2 TS frames         March 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 September 25, 2008              [Page 27]

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 29 Mar 2008 18:12:59 +0000

Thanks,

See in-line for a clarification, and some suggestions on formatting.

Best wishes,

Gorry

> Destination needs to be different from MAC destination address?
There could be - when the receiver is an Ethernet Bridge and this is 
feeding a local area network. In the case in Figure 11, the NPA address 
is the address of the receiver itself. This topology resembles that of 
Metro-Ethernet - where Ethernet frames are bridged between two or more 
attached LANs using a L2 network. The NPA addresses are local only to 
the DVB/MPEG network and used to construct the "virtual" transmission 
network.

---

The abstract should state the name of the specification it is extendin 
in full, hence:

  " This document describes a set of Extension Headers for the
    Unidirectional Lightweight Encapsulation (ULE), RFC4326."

---

You may also wish to define:
    B: Byte. Groups of bytes are represented in Internet byte order.

    Next-Header: A Type value indicating an Extension Header [RFC4326].

    NPA: Network Point of Attachment [RFC4326]. In this document, refers
    to a destination address (resembling an IEEE MAC address) within the
    DVB-S/S2 transmission network that is used to identify individual
    Receivers or groups of Receivers.

    ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A
    method that encapsulates PDUs into SNDUs that are sent in a series
    of TS Packets using a single TS Logical Channel. The encapsulation
    defines an extension format and an associated IANA Registry.

---

I suggest rewriting the IANA section, so that reads something like the 
following. This is the form of words we used in previous IANA requests.

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

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

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

          Type      Name                             Reference

          TBD:      ULE-ROHC                        Section 3.1
          TBD-1:    ULE-ROHC-Neg                    Section 4.1

    The ULE-ROHC Extension is a Mandatory next-type Extension Header,
    specified in section 3.1 of this document. The value of this next-
    header is defined by an IANA assigned H-Type value of TBD.

    The ULE-ROHC-Neg Extension is a Mandatory next-type Extension Header
    specified in section 4.1 of this document. The value of this next-
    header is defined by an IANA assigned H-Type value of TBD-1.

---

The University of Aberdeen is a charity registered in Scotland, No SC013683.