[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: RFC: Draft for ROHC over DVB]

To: ipdvb@erg.abdn.ac.uk
Subject: [Fwd: RFC: Draft for ROHC over DVB]
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Sun, 17 Feb 2008 20:26:28 +0000
Organization: School of Engineering, University of Aberdeen, Scotland
Reply-to: ipdvb@erg.abdn.ac.uk
Sender: owner-ipdvb@erg.abdn.ac.uk
User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031)


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

best wishes,

Gorry Fairhurst
(as ipdvb Chair)

-------- Original Message --------
Subject: RFC: Draft for ROHC over DVB
Date: Sun, 17 Feb 2008 20:39:12 +0800
From: Ang Way Chuang <wcang@nav6.org>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>

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

      I tried to sent an email to ipdvb@erg.abdn.ac.uk, but I received
no such email. I'm guessing the mailing list is not working properly.


Thank you very much.

Regards,
Ang Way Chuang

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

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

Status of This Memo

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

Intellectual Property Right

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

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

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

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

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

Abstract

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

Table of Contents

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

1. Introduction

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

DVB
Digital Video Broadcast. A framework and set of associated
standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data
using the ISO MPEG-2 Standard [ISO-MPEG2].

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

MPEG-2
A set of standards specified by the Motion Picture Experts
Group (MPEG) and standardized by the International Standards
Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222
[ITU-H222]).

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

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

Transmitter
Router or host that sends data.

SNDU
SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit.

TS
Transport stream (TS) is a format specified in MPEG-2 Part 1,
Systems (ISO/IEC standard 13818-1). Its design goal is to allow
multiplexing of digital video and audio and to synchronize the
output. Transport stream offers features for error correction for
transportation over unreliable media, and is used in broadcast
applications such as DVB and ATSC.

ULE Stream
An MPEG-2 TS Logical Channel that carries only ULE encapsulated
PDUs. ULE Streams may be identified by definition of a
stream_type in SI/PSI [ISO-MPEG2].

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

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

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

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

DVB
Digital Video Broadcast. A framework and set of associated standards
published by the European Telecommunications Standards Institute (ETSI)
for the transmission of video, audio, and data using the ISO MPEG-2
Standard [ISO-MPEG2].

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

MSB
Most significant bit.

LSB
Least significant bit.

ACK
Acknowledgement.

NACK
Negative acknowledgement.

CID
Context Identifier.

3. Packet Format of ROHC Packet

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

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

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

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

3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet

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

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

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

The meaning of each fields is specified below:

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

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

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

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

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

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

4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP)
The approach presented in this section can only work if compressor site
and decompressor site are connected through two dedicated unidirectional
DVB links, with a unidirectional link originating from each of the
sites, configured to form a bidirectional network link between the two
sites. This protocol works through ULE packets only. It is possible to
extend this protocol to work over Generic Stream Encapsulation [GSE] in the
future. While it is possible to extend this protocol to work over
asymmetrical link, this draft doesn't try to address this issue. Since new
EtherType is allocated, this protocol can be extended to asymmetrical link
via Link-Layer Tunneling Mechanism [RFC 3077] with little modifications.

The basic format of ULE SNDU packet is as such:

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

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

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

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

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

4.1.1. Compressor Advertisement

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

4.1.2. Compressor Solicitation

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

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

4.1.3. Request

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

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

Maximum CID: Maximum Context Identifier tolerated by decompressor.

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

Number of profiles: Number of profiles supported by decompressor.

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

X-bit is unused and should be ignored.

4.1.4. Reply

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

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

Maximum CID: Maximum CID tolerated by compressor. This value of this field
should be less than or equal to its counterpart in request message.
Decompressor site should send a NACK if it receives Maximum CID that is
higher than the initial negotiated value.

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

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

Profile IDs: Profile Identifiers of the ROHC profiles that will be used for
the negotiated ROHC channel. Decompressor site should send a NACK if it
receives any profile ID that it doesn't support.

X-bit is unused and should be ignored.

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

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

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

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

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

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

ULE Type:

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

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

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

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

Reserved field is not used and should be ignored.

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

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

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

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

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

X-bit is unused and should be ignored.

4.1.7 Decompressor Shutdown
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=6 | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 15: Format of Decompressor Shutdown message.

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

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

X-bit is unused and should be ignored.

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

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

Figure 15: Packets flow of RCPNP

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

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

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

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

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

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

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

Authorsâ?? Addresses
Tat-Chee Wan
School of Computer Sciences,
Universiti Sains Malaysia,
11800 USM, Penang, Malaysia.
Email: tcwan@cs.usm.my
Web: http://nrg.cs.usm.my/~tcwan

Chee-Hong Teh
School of Computer Sciences,
Universiti Sains Malaysia,
11800 USM, Penang, Malaysia.
Email: chteh@nav6.org

Way-Chuang Ang
School of Computer Sciences,
Universiti Sains Malaysia,
11800 USM, Penang, Malaysia.
Email: wcang@nav6.org

Follow-Ups:
- Re: [Fwd: RFC: Draft for ROHC over DVB]
  - From: "Walsh Rod (Nokia-NRC/Tampere)" <Rod.Walsh@nokia.com>

Next by Date: Re: [Fwd: RFC: Draft for ROHC over DVB]
Next by thread: Re: [Fwd: RFC: Draft for ROHC over DVB]
Index(es):
- Date
- Thread