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
+---+--------+----------+----------+------------+--------------+--------------
----------+--------+
|D=1| Length |Type=Ether| Dest MAC | Source MAC |EtherType=ROHC| ROHC
compressed packet | CRC-32 |
+---+--------+----------+----------+------------+--------------+--------------
----------+--------+
Figure 2: ROHC compressed packet encapsulated in SNDU bridged frame
This packet format should be used when there are multiple
transmitters and
receivers over a DVB link. The value of EtherType field is similar
to Type
Field in section 3.1.1.
3.2. ROHC over MPEG2-TS
This encapsulation format is the smallest packet format in terms
of packet
size. The format of SNDU is the following format:
+------+------------------------+--------+
|Length| ROHC compressed packet | CRC-32 |
+------+------------------------+--------+
Figure 3:
The meaning of each fields is specified below:
Length: This field indicates the ROHC compressed packet field
only. This
field can be either 1 or 2 octets depending on the the most
significant
bit.
If the most significant bit is cleared, the length of this field
is 1 octet
and may represents values from 0 until 127. Otherwise, the length
of this
field is 2 octets and may represents values from 128 until 61566.
ROHC Compressed Packet: ROHC compressed packet as defined in
section 5.2
of
[RFC 3095].
CRC-32: The 32-bit CRC is calculated over Length filed and ROHC
compressed
packet. The polynomial used to calculate the CRC is 0x104C11DB7.
Like ULE, ROHC over MPEG2-TS also supports packing and padding
mode. The
mechanism of encapsulating this SNDU is similar to encapsulation
of ULE
packet within MPEG2-TS. This approach requires that separate PID
dedicated
to a ROHC channel.
4. Establishing ROHC Channel
This standard presents two approaches to setup a ROHC channel over
a DVB
link. The first approach is to setup ROHC channel manually. This
requires
that the operators at the every transmitters and receivers to
manually
configure the ROHC channel parameters. When the size of network is
small,
this approach is favourable.
But the former approach becomes nonviable if the network is
dynamic and is
not scalable as the size of the network grows. Henceforth, we
presents a
negotiation protocol to create ROHC channel in the next section.
4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP)
The approach presented in this section can only work if compressor
site
and decompressor site are connected through two dedicated
unidirectional
DVB links, with a unidirectional link originating from each of the
sites, configured to form a bidirectional network link between the
two
sites. This protocol works through ULE packets only. It is
possible to
extend this protocol to work over Generic Stream Encapsulation
[GSE] in the
future. While it is possible to extend this protocol to work over
asymmetrical link, this draft doesn't try to address this issue.
Since new
EtherType is allocated, this protocol can be extended to
asymmetrical link
via Link-Layer Tunneling Mechanism [RFC 3077] with little
modifications.
The basic format of ULE SNDU packet is as such:
+---+--------+------------+----------+--------+
|D=1| Length |Type=ROHCNeg| Body | CRC-32 |
+---+--------+------------+----------+--------+
Figure 4: Minimal format of RCPNP message
+---+--------+----------+----------+------------+-----------------+------+----
----+
|D=1| Length |Type=Ether| Dest MAC | Source MAC
|EtherType=ROHCNeg| Body |
CRC-32 |
+---+--------+----------+----------+------------+-----------------+------+----
----+
Figure 5: RCPNP message encapsulated in bridged frame.
Type field requires a new separate IANA assigned EtherType number
for ROHC
Channel Negotiation Protocol. The types of message in this
protocol is
defined in the Body field. The following subsections will explain
the type
of messages for this protocol. Compressor Advertisement and
Compressor
Solicitation uses packet format depicted in Figure 4. While other
forms of
messages uses packet format depicted in Figure 5.
The basic format for these messages is depicted is as such:
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version | Operation | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 6: Basic format of RCPNP Body field.
Currently, version number is 0. Operation field defines the type
of message
contained in the Body field. The content of X-bit depends on
operation
type.
4.1.1. Compressor Advertisement
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=0 | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
~ Address (6 octets) ~
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 7: Format of Compressor Advertisement message.
Compressor site should send this message periodically to advertise
the
availability of compressor. Care should be taken as not to send
too many
advertisements. The decompressor site will use the value specified
in the
Address field when addressing compressor site. X-bit is unused and
should
be
ignored.
4.1.2. Compressor Solicitation
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=1 | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 8: Format of Compressor Solicitation message.
Instead of waiting for compressor site to advertise itself,
decompressor
site
may opt to solicit for compressor(s) by sending compressor site
solicitation
message. Upon receiving solicitation, compressor site should send an
advertisement. X-bit is unused and should be ignored. Decompressor
site
should rate-limit the frequency of solicitation if it is doesn't
receive
any advertisement to avoid flooding DVB link.
4.1.3. Request
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=2 | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Maximum CID +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
~ MRRU (4 octets) ~
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Num of profiles +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Profile ID 1 +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Profile ID 2 +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Profile ID N +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 9: Format of Request message.
This message is sent by decompressor site to compressor site. The
meaning
of each fields in the message are described below:
Maximum CID: Maximum Context Identifier tolerated by decompressor.
MRRU: Maximum Reconstructed Reception Unit tolerated by
decompressor. Value
of 0 indicates the negotiated channel doesn't allow for
segmentation of
ROHC
compressed packet.
Number of profiles: Number of profiles supported by decompressor.
Profile IDs: ROHC Profile IDs supported by decompressor. Each profile
ID occupy 2 octets.
X-bit is unused and should be ignored.
4.1.4. Reply
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=3 | X |
+===============================================+
| |
+ Maximum CID +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
~ MRRU (4 octets) ~
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Num of profiles |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Profile ID 1 +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Profile ID 2 +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ Profile ID N +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 10: Format of Reply message.
This message is sent by compressor site to decompressor site in
response to
request message sent by decompressor site. The meaning of each
fields in
the
message are described below:
Maximum CID: Maximum CID tolerated by compressor. This value of
this field
should be less than or equal to its counterpart in request message.
Decompressor site should send a NACK if it receives Maximum CID
that is
higher than the initial negotiated value.
MRRU: Maximum Reconstructed Reception Unit tolerated by compressor.
Likewise,
decompressor site should send a NACK if it is receives higher MRRU
than
what
it requested.
Number of profile IDs: Note that this field is 1 octet instead of
2 because
there can be only 256 active profiles at any given ROHC channel.
Decompressor
site should send a NACK if it receives more profile IDs than it can
support.
Profile IDs: Profile Identifiers of the ROHC profiles that will be
used for
the negotiated ROHC channel. Decompressor site should send a NACK
if it
receives any profile ID that it doesn't support.
X-bit is unused and should be ignored.
4.1.4.1. Medium Information
The following notation depicted in the previous figure 10
indicates the
presence of medium information.
+===============================================+
Medium information conveys how compressor is to send ROHC compressed
packets
to decompressor. Currently only 2 media are supported, namely
MPEG2-TS and
ULE. The details of packet format for ROHC over MPEG2-TS/ULE is
described
in section 3. Medium type is conveyed by Medium field. Other media
may be
supported in the future and the support for these media will
specified in
other documents. Decompressor receiving unsupported medium type
should send
a NACK.
4.1.4.1.1. MPEG2-TS Medium
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Medium=0 | |
+-----+-----+-----+ PID +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 11: Medium information for ROHC over MPEG2-TS.
PID: Packet Identifier of MPEG2-TS frames that will carry ROHC
compressed
packet.
4.1.4.1.2. ULE Medium
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Medium=1 | ULE Type | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 12: Medium information for ROHC over ULE.
ULE Type:
0: No MAC address will be sent in ULE packets. This option should
only be
used if the compressor site is certain that there is only one
receiver and
one transmitter over DVB link.
1: Only destination MAC address will be sent in ULE packets that
carry ROHC
compressed packet. This means that Destination Absent bit in ULE
header
will
be cleared. This option is used only if there is one transmitter
and many
receivers listening to that transmitter via DVB link.
2: ROHC packets will be encapsulated in Ethernet bridged frame.
This option
is used when there multiple transmitters and receivers over a DVB
link.
3: Not used. Receiver should treat it as corrupted packet, silently
discard the message and wait for a valid Reply message or until a
timeout
occur at which the decompressor site will start the negotiation
afresh by
sending a Request message.
Reserved field is not used and should be ignored.
4.1.5. Acknowledgement
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=4 | Ack |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 13: Format of Acknowledgement message.
Decompressor site should send either an acknowledgement or negative
acknowledgement if it receives a valid Reply message. If Ack bit
is set,
then the message is an acknowledgement. Otherwise, it is a negative
acknowledgement. If compressor site doesn't receive ACK nor NACK
within a
reasonable interval, it should discard any information of
negotiated ROHC
channel parameters. An acknowledgement must be sent to
decompressor site
when
compressor site receives Decompressor Shutdown message.
4.1.6 Compressor Shutdown
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=5 | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 14: Format of Compressor Shutdown message.
This message is sent by the compressor site to notify the
decompressor site
that it is about to stop compressing IP packets. Upon receiving this
message, decompressor should release all resources that are being
held.
Compressor must wait for an acknowledgement from decompressor site
before
freeing its resource. If it doesn't an acknowledgement within a
reasonable
interval, it should keep sending a shutdown message for a number
of times
before freeing its resource.
X-bit is unused and should be ignored.
4.1.7 Decompressor Shutdown
MSB LSB
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Version=0 | Operation=6 | X |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 15: Format of Decompressor Shutdown message.
This message is sent by the decompressor site to notify the
compressor
that it is about to stop decompressing IP packets. Upon receiving
this
message, compressor should release all resources that are being
held and
stop
sending compressed IP packets.
Decompressor must wait for an acknowledgement from compressor site
before
freeing its resource. If it doesn't an acknowledgement within a
reasonable
interval, it should keep sending a shutdown message for a number
of times
before freeing its resource.
X-bit is unused and should be ignored.
4.2. Interaction of RCPNP
The following diagram depicts a possible interaction between
compressor
site
and decompressor site in negotiating ROHC channel parameters.
Compressor Site Decompressor
Site
|<------------ Solicit (optional) ----------------|
| |
|------------------- Advertise ------------------>|
| |
|<------------------- Request --------------------|
| |
|--------------------- Reply -------------------->|
| | Create
instance
| | of
decompressor
Create |<-------------------- ACK -----------------------|
compressor | |
| |
| ==== (Compression can begin at this point) === |
| |
| |
Destroy |<------------ Decompressor Shutdown -------------|
compressor | |
|--------------------- ACK ---------------------->| Destroy
| |
decompressor
Figure 15: Packets flow of RCPNP
4.3 Bidirectional ROHC Channels
While establishing bidirectional ROHC channels allows for the use
of ROHC
bidirectional optimistic mode and bidirectional reliable mode, RCPNP
doesn't
concern itself with the establishment of bidirectional ROHC
channels.
Therefore, it is up to implementers of this protocol to support
bidirectional ROHC channels. The implementation should be as
straightforward
as mapping correct pair of ROHC channels.
5. IANA Consideration
Two EtherTypes should be assigned. One of it is for RCPNP and the
other is
to indicate the presence of ROHC compressed packet.
6. References
[RFC 3095] Bormann, C. et al, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, 2001
[RFC 4326] Fairhurst, G. and Collini-Nocker, B., "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams
over an MPEG-2 Transport Stream (TS)", RFC 4326, 2005
[GSE] Digital Video Broadcasting, "Generic Stream
Encapsulation
(GSE)
Protocol", DVB Document A116, 2007
[RFC 3077] Duros, E. et al, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, 2001
[ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding of
moving
pictures and associated audio information -- Part 1:
Systems",
International Standards Organisation (ISO), 2000.
Authors’ Addresses
Tat-Chee Wan
School of Computer Sciences,
Universiti Sains Malaysia,
11800 USM, Penang, Malaysia.
Email: tcwan@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