Internet DRAFT - draft-wan-ipdvb-rohc
draft-wan-ipdvb-rohc
Network Working Group Tat-Chee. Wan
Internet-Draft Way-Chuang. Ang
Intended status: Standards Track Chee-Hong. Teh
Expires: April 20, 2009 Universiti Sains Malaysia
October 17, 2008
Robust Header Compression over Unidirectional Lightweight Encapsulation
(ULE) and MPEG2 Transport Stream (TS) frames
draft-wan-ipdvb-rohc-02.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 April 20, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Wan, et al. Expires April 20, 2009 [Page 1]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Abstract
This document describes a set of Extension Headers for the
Unidirectional Lightweight Encapsulation (ULE), RFC4326 to carry
packets compressed with RObust Header Compression (ROHC), RFC 3095
over ULE Stream.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Encapsulation Format . . . . . . . . . . . . . . . . . . . . . 10
4.1. Encapsulation Format of ULE SNDU within ROHC Channel . . . 10
4.2. ROHC Feedback . . . . . . . . . . . . . . . . . . . . . . 12
5. Topological Learning . . . . . . . . . . . . . . . . . . . . . 13
5.1. Automatic Learning . . . . . . . . . . . . . . . . . . . . 13
6. Establishing ROHC Channel . . . . . . . . . . . . . . . . . . 14
6.1. ROHC Channel Parameters Negotiation Protocol (RCPNP) . . . 14
6.1.1. Compressor Advertisement . . . . . . . . . . . . . . . 16
6.1.2. Compressor Solicitation . . . . . . . . . . . . . . . 16
6.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.4. Reply . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.5. Acknowledgement . . . . . . . . . . . . . . . . . . . 19
6.1.6. Negative Acknowledgement . . . . . . . . . . . . . . . 20
6.1.7. Compressor Shutdown . . . . . . . . . . . . . . . . . 21
6.1.8. Decompressor Shutdown . . . . . . . . . . . . . . . . 21
6.1.9. Heartbeat . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Interaction of RCPNP . . . . . . . . . . . . . . . . . . . 22
7. Bidirectional ROHC Channels . . . . . . . . . . . . . . . . . 25
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Wan, et al. Expires April 20, 2009 [Page 2]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
1. Introduction
Header compression promotes efficient use of available bandwidth.
This is more apparent in the case of DVB-S where satellite link is
used. This document introduces a method to compress headers of IP
packet encapsulated within ULE [RFC4326] Stream using ROHC framework
[RFC3095].
Important concepts of ROHC channel in MPEG2-TS system is introduced
to differentiate between normal, uncompressed ULE Stream from ROHC
compressed stream. Method to map outgoing packet to a ROHC channel
is also presented. For completeness, a protocol to automate the
negotiation and setup of parameters for ROHC channel is discussed.
This document doesn't try to address compression of broadcast or
multicast traffic for there is no reliable way to handle ROHC
feedback from multiple ROHC decompressor. Implementation that wants
to enable ROHC compression for broadcast or multicast traffic must
ensure that all recipient gateways are capable of decompressing ROHC
packet and that all contexts for broadcast and multicast traffic must
operate in unidirectional mode.
Wan, et al. Expires April 20, 2009 [Page 3]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 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].
Compressor Gateway
Gateway that is capable of compressing header of IP packets using
ROHC.
Decompressor Gateway
Machine that can perform ROHC decompression.
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].
Gateway
Machine that can either host ROHC compressors and ROHC
decompressors.
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.
ROHC
Wan, et al. Expires April 20, 2009 [Page 4]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
RObust Header Compression. A framework to compress header of IP
packets as defined in [RFC3095].
ROHC channel
A logical unidirectional point-to-point channel carrying ROHC
compressed packets for a pair compressor and decompressor.
ROHC profile
Specification of how to compress the headers of a certain kind of
packet stream as defined by [RFC3095]
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 Stream may be identified by definition of a stream_type
in SI/PSI [ISO-MPEG2].
MRRU
Maximum Reconstructed Reception Unit as defined in [RFC3095].
Context Identifier
[RFC3095] provides a definition for context identifiers.
ACK
Positive Acknowledgement.
Wan, et al. Expires April 20, 2009 [Page 5]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
NACK
Negative acknowledgement.
CID
Context Identifier.
B
Byte. Groups of bytes are represented in Internet byte order.
b
Bit.
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.
In addition, this document also borrows some terminologies defined in
section 2 of [RFC3759]. When there is any ambiguity between
terminologies defined in other documents and this document, the
terminolgies in this document should be consulted to intepret the
content of this document.
Wan, et al. Expires April 20, 2009 [Page 6]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
3. Topology
Compressor gateways and decompressor gateways are connected through
unidirectional links. This document assumes that these
unidirectional links carry IP packets within ULE over MPEG2-TS
frames. A unidirectional link from a compressor gateway may have
multiple decompressor gateways listening to it. The following figure
depicts a generic topology of a compressor gateway, Comp1, with 2
decompressor gateways, Decomp 1 and Decomp 2.
unidirectional link
^------------->---------->--------->
| | |
| v v
+--------+ +----------+ +----------+
| Comp 1 | | Decomp 1 | | Decomp 2 |
+--------+ +----------+ +----------+
^ ^ | |
| | | |
| <--------<-------v |
| |
<----------<------------<-------------v
unidirectional links
Figure 1: Generic Topology
Each decompressor gateway has a dedicated unidirectional link
connected to compressor gateway. Each unidirectional link may
contain multiple logical channels identified by the PID field of
MPEG2-TS frame. Of these logical channels, some may be dedicated for
traffic of ROHC compressed packets only. While the rest of the
logical channels may be used to carry uncompressed packets.
For the purpose of this discussion, the group of logical channels
used to carry streams of uncompressed packets are called uncompressed
channels. An uncompressed channel is not reserved exclusively
between a pair of gateways and may be shared by multiple receiver
gateways.
A ROHC channel is a logical channel that is used to carry ROHC
compressed packets from a compressor gateway to a decompressor
gateway. ROHC channel is exclusive to a pair of compressor gateway
and decompressor gateway.
A ROHC feedback channel is a logical channel that carries ROHC
feedback packet from decompressor gateway to compressor gateway.
Wan, et al. Expires April 20, 2009 [Page 7]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
When co-located compressor and decompressor are associated, ROHC
feedback can be piggybacked within ROHC compressed stream. When used
in this manner, ROHC feedback channel of decompressor and ROHC
channel of co-located compressor at the decompressor gateway share
the same logical channel.
However, in the absence of co-located compressor at the decompressor
gateway, ROHC feedback doesn't necessitate a dedicated logical
channel as it can be sent via uncompressed channel in the
encapsulation format depicted in Figure 6. As such, ROHC feedback
channel is not an exclusive channel and may be a part uncompressed
channel or ROHC channel.
Figure 2 depicts a possible combination of logical channels for the
topology shown in Figure 1. The following topology assumes that
there is no co-located compressor at both decompressor gateways and
ROHC feedbacks are sent back through uncompressed channel.
uncompressed channel
^--------->---------->--------->---------->
| | |
| | ROHC channel |
^--+------>--------->---+---->--------> |
| | | | |
| ^ ROHC channel v | v
| | ^----->------> | | |
| | | | | | |
| | | v v v v
+----------+ +------------+ +------------+
| Comp 1 | | Decomp 1 | | Decomp 2 |
+----------+ +------------+ +------------+
^ ^ | |
| | uncompressed channel | |
| <--------<------<------v |
| |
| uncompressed channel |
<------<------<-----<-------<------<------v
Figure 2: Topology of Logical Channels
To get a better understanding of the terminologies used in subsequent
sections, Figure 3 depicts a topology of 2 gateways with both
compressor and decompressor. Comp 1 is the compressor for Gateway 1
whereas Decomp 1 is the decompressor for Gateway 1. So is Comp 2 and
Decomp 2 for Gateway 2. Comp 1 and Decomp 1 are co-located and
associated. The arrow sign from Decomp 1 to Comp 1 means that ROHC
Wan, et al. Expires April 20, 2009 [Page 8]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
feedback is being forwarded from Decomp 1 to Comp 1. Decomp 2 is the
corresponding decompressor of compressor Comp 1. ROHC feedback from
Decomp 2 can be sent back to Comp 1 through ROHC channel established
between Comp 2 and Decomp 1.
uncompressed channel
^------->------->-------->--------->-------->
| ROHC channel |
| ^------->------>------>-----+-->------>
| | | |
| | v |
+--------------------+--------+ +------------------------------+
| | | | | |
| | | | v |
| +------------+ | | +------------+ |
| | Comp 1 | | | | Decomp 2 | |
| +------------+ | | +------------+ |
| Gateway 1 ^ | | Gateway 2 | |
| | | | v |
| +------------+ | | +------------+ |
| | Decomp 1 | | | | Comp 2 | |
| +------------+ | | +------------+ |
| ^ | | | |
| | | | | |
+-----------------------------+ +---------------------+--------+
^ | ROHC channel | |
| <--------<--------<---------+--<------v
| uncompressed channel |
<--------<-------<--------<--------<-------v
Figure 3: Topology of Gateways with Pairs of ROHC peers
Wan, et al. Expires April 20, 2009 [Page 9]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
4. Encapsulation Format
This section briefly describes the notation used in all diagrams. "="
in the following diagrams indicates the number of octets occupied by
the indicated field is not presented in a precise manner. This
situation appears when a field spans variable number of bytes.
4.1. Encapsulation Format of ULE SNDU within ROHC Channel
All ULE SNDUs sent within ROHC channel have their payload compressed
using ROHC. ULE Type field of these packets are the same as their
counterparts in uncompressed channel. For instance, IPv4 PDUs
compressed with ROHC will still have ULE type of 0x800. Likewise,
compressed IPv6 PDUs will have ULE type of 0x86dd. Figure 4 depicts
the format of ULE SNDU with compressed IPv6 PDU.
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 = 0x86dd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address* (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
| Compressed IPv6 PDU |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Packet Format of Compressed IPv6 PDU
The semantics of D-bit, Length, Type, Receiver Destination NPA
Address and CRC-32 fields are defined in section 4 of [RFC4326]
except for the PDU. If the decompressed PDU doesn't yield the same
PDU type as defined in Type field, the PDU is corrupted and should be
discarded. For example, when the value of the Type field is 0x800,
ROHC decompressor should discard the packet if it yields an IPv6 PDU
after decompression.
The same concept applies for compressed bridge frame PDUs. However,
the Ethernet header is left untouched. Only the headers after the
Ethernet frame header are compressed. Decompressed payload should
result in payload of the type indicated in the EtherType field. If
Wan, et al. Expires April 20, 2009 [Page 10]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
not, the frame should be discarded. Figure 5 depicts the format of
compressed SNDU bridged frame. Any padding bytes carried within
content of original bridged MAC frame to fulfill the minimum Ethernet
frame size should be stripped off before compression and should not
be present within ROHC compressed payload as the total length field
of IP header is not present in compressed header and may confuse ROHC
decompressor. Decompressor gateway should insert necessary padding
bytes to decompressed Ethernet frame to fulfill the minimum Ethernet
frame size.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address * (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Destination MAC (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EtherType/LLC Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= ROHC compressed payload =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ROHC Compressed Packet Encapsulated within SNDU Bridged
Frame
The rationale of reusing existing ULE type to carry ROHC compressed
packets is twofold:
1. Decompressor gateway can recognize the content of SNDU easily and
handle the SNDU in the same way as its uncompressed counterpart
after the PDU is decompressed.
2. The framework will be more extensible. If in the future, when
new ULE types are introduced to carry SNDU that can be compressed
by ROHC, these new ULE types can be used again to cover for its
ROHC compressed counterparts.
Wan, et al. Expires April 20, 2009 [Page 11]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
There can be no ambiguity as to whether a SNDU is carrying ROHC
compressed PDU or uncompressed SNDU because ROHC compressed PDU can
only exist in ROHC channel.
4.2. ROHC Feedback
ROHC feedback is not compressed per se and is only used by
decompressor to send feedback to compressor when it is operating in
bidirectional mode. Format of ROHC feedback is depicted in Figure 6.
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 = ULE ROHC-Feedback |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address* (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
| ROHC feedback |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of ROHC feedback encapsulated within ULE SNDU
It should be noted that ROHC feedback may be embedded within a ROHC
compressed packet and doesn't necessarily have to be sent in the
format presented in Figure 6.
ROHC feedback may be sent through uncompressed channel from
decompressor gateway. However, there may be multiple gateways
listening to uncompressed channel. To uniquely identify the
recipient gateway, Receiver Destination NPA Address field must store
the Address of the compressor gateway when ROHC feedback is sent
through uncompressed channel.
If, however, there is a dedicated ROHC channel from decompressor
gateway to compressor gateway, Receiver Destination NPA Address need
not be used. This is situation may occur when there is a co-located
compressor at the decompressor gateway with a corresponding
decompressor at the compressor gateway like the example shown in
Figure 3. Therefore, if a decompressor gateway needs to send ROHC
feedback, it should do so through ROHC channel if one is available.
Wan, et al. Expires April 20, 2009 [Page 12]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
5. Topological Learning
Since there may be more than one gateway listening to a transmission,
a gateway may need to setup multiple ROHC channels each for a
listening gateways. Before a gateway can compress a packet, it needs
to decide the right recipient gateway. If not, the gateway won't be
able to determine which ROHC compressor to use, thereby the right
ROHC channel to use. Thus, a gateway that needs to send ROHC
compressed packet need to learn the topology of its network.
The following subsection will present a simple technique for a
gateway to learn about topology of its network. Implementation of
this document may choose to use any other technique to inform the
gateway about the topology of the network.
5.1. Automatic Learning
Since a gateway needs to listen incoming traffic of other peer
gateways through individual frontend of DVB receiver card for each
peer gateway. Thus each frontend must be mapped to a corresponding
ROHC channel exclusively.
When an incoming packet arrives at a frontend, the source address for
the packet will need to be identified. The source address may be
source IP address of IPv4 and IPv6 PDU or source MAC address of a
bridged frame SNDU. Collectively, these source addresses are mapped
to the ROHC channel that corresponds to this frontend.
When compressor gateway needs to send a packet, it needs to identify
the destination address of the packet. The destination may be
destination IP address of IPv4 and IPv6 PDU or destination MAC
address of a bridged frame SNDU. The compressor gateway then needs
to look for a ROHC channel that has a matching address with this
destination address. If a match is found, the ROHC channel and its
corresponding ROHC compressor will be used to compress and send the
packet. If no match is found, compressor gateway must send the
packet uncompressed through the uncompressed channel.
Wan, et al. Expires April 20, 2009 [Page 13]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
6. Establishing ROHC Channel
This document presents an approach to setup ROHC channel(s) over DVB
links through a negotiation protocol. Implementation of the protocol
mentioned in this document is not strictly required, implementers may
choose to have static configuration to setup the parameters of ROHC
compression and decompression.
6.1. ROHC Channel Parameters Negotiation Protocol (RCPNP)
This protocol works through ULE Streams only. It is possible to
modify this protocol to work on Generic Stream Encapsulation [GSE] in
the future. While it is possible to extend this protocol to work
over asymmetrical link as in the case of Link-Layer Tunneling
Mechanism [RFC3077], this draft doesn't try to address this issue.The
ULE SNDUs defined in this section should be sent via uncompressed
channel.
The structure of a ULE SNDU packet for RCPNP message is as such:
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 = ULE ROHC-Neg |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address* (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Version| OpCod | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Source Address * (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identifier * (2B) | Ref ID * (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ =
| Body * |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Minimal format of RCPNP message
Wan, et al. Expires April 20, 2009 [Page 14]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Type
New ULE type needs to be assigned for ROHC negotiation protocol.
Receiver Destination NPA 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.
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.
Identifier
An identifier that is used to identify related exchange of
messages. This field only exists for Compressor Shutdown,
Decompressor Shutdown, Heartbeat, Request and Reply messages.
Ref ID
Reference identifier. This field identifies the value of
Identifier of the message that the current message is replying to.
This field only exists for Reply, Acknowledgement and Negative
Acknowledgement message. The value contained in this field is the
value of Identifier it is referring to.
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. Unless specified otherwise, these fields
Wan, et al. Expires April 20, 2009 [Page 15]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
will be present in all RCPNP 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.
6.1.1. Compressor Advertisement
Operation Code
The value is 0.
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 to 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.
6.1.2. Compressor Solicitation
Operation Code
The value is 1.
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 April 20, 2009 [Page 16]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
6.1.3. Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum CID (2B) | Num of profiles (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID 1 | Profile ID 2 * |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= More Profile IDs * =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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 wants 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.
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. For
example, if the field carries the value of 0, the ROHC channel can
only support 1 context.
Number of profiles
Number of profiles supported by decompressor. Must be at least
one.
Wan, et al. Expires April 20, 2009 [Page 17]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Profile IDs
ROHC Profile IDs supported by decompressor. Each profile ID
occupies 2 octets.
6.1.4. Reply
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum CID (2B) | PID (13b) | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num of Profiles| Profile ID 1 | Profile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID 2 * (cont) | |
=-+-+-+-+-+-+-+-+ More Profile IDs * =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 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.
If decompressor doesn't receive within any Reply message within a
specific interval, it should resend the same Request message for a
few more times. If these few attempts fail to result in any Reply
message, decompressor should wait for a longer period before starting
a new round of negotiation.
If compressor site doesn't receive an ACK nor a NACK message within a
reasonable interval for the Reply message, it should resend the Reply
message for a few times before discarding any information of
negotiated ROHC channel parameters.
The meaning of each fields in the message are described below:
Operation Code
Wan, et al. Expires April 20, 2009 [Page 18]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
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.
Maximum CID
Maximum CID tolerated by compressor. This value of this field
should be less than or equal to the negotiated value in Request
message, otherwise decompressor site should send a NACK. If the
maximum CID is less than 16, CIDs will be encoded using small CID
format for the ROHC channel. Otherwise, large CID format is
implied.
PID
Packet Identifier of MPEG2-TS frames that will carry ROHC
compressed packet.
Res
Reserved field. Unused and should be ignored.
Number of profile IDs
ROHC framework reserves the most significant octet of profile ID
to denote the version number of a ROHC profile. Due to this
constraint, there can only be 256 active profiles per channel.
Therefore, this field occupies 1 octet instead of 2. Decompressor
site should send a NACK if it receives more profile IDs than it
can support. If the value of this field is 0, the message is
corrupted and should be discarded.
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.
6.1.5. Acknowledgement
Decompressor site should send an acknowledgement if the parameters
negotiated in Reply message is agreeable. An acknowledgement must
also be sent to decompressor site when compressor site receives
Decompressor Shutdown message. Likewise, this message will also be
Wan, et al. Expires April 20, 2009 [Page 19]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
sent to acknowledge a Compressor Shutdown message.
Operation Code
The value of this field is 4.
Body
This field is not present in this message.
6.1.6. Negative Acknowledgement
Operation Code
This field carries the value of 5.
Body
This field is not present in this message.
Negative Acknowledgement may be sent for various types of messages
depending on the Ref ID field. Negative Acknowledgment is sent for
the following messages for the following reasons:
Request
Compressor site receives a Request message with no parameter that
it can support or when it doesn't have the resource to establish a
new ROHC channel.
Reply
The decompressor site receives a valid Reply message with
unsupported ROHC channel parameters or it is unable to allocate
resource for the creation of ROHC decompressor. Compressor site
should discard any information regarding negotiated ROHC channel
parameters upon receiving this message.
Decompressor Shutdown
Compressor site doesn't have any compressor for the channel. This
can happen for a number of reasons. For example, decompressor
site may resend a Compressor Shutdown if the Acknowledgement
message was not lost. By the time the resent Compressor Shutdown
is received, the compressor on the compressor site may have been
destroyed. Decompressor site can free the resources allocated for
decompressor when it receives this message.
Wan, et al. Expires April 20, 2009 [Page 20]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Compressor Shutdown
Decompressor site doesn't have any decompressor for the channel.
This can happen for a number of reasons. Compressor site can free
the resources allocated for compressor when it receives this
message.
Heartbeat
Decompressor and compressor doesn't exists. This may be due to
abnormal shutdown of compressor and decompressor.If a Negative
Acknowledgement is received in return, the sender should treat it
as a sign for the absence of compressor/decompressor at its
counterpart site. Resources should be freed immediately upon
receiving a Negative Acknowledgement.
6.1.7. Compressor Shutdown
Operation Code
The value is 6.
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
resources that are being held for decompression.
Compressor must wait for an acknowledgement or a negative
acknowledgement from decompressor site before freeing its resource.
If it doesn't receive one of these messages within a reasonable
interval, it should keep sending a shutdown message for a number of
times before freeing its resource.
6.1.8. Decompressor Shutdown
Operation Code
The value is 7.
Body
Wan, et al. Expires April 20, 2009 [Page 21]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
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 or a negative
acknowledgement from compressor site before freeing its resource. If
it doesn't receive one of these messages within a reasonable
interval, it should keep sending a shutdown message for a number of
times before freeing its resource.
6.1.9. Heartbeat
Operation Code
The value is 8.
Body
This field is not present in this message.
This message can be sent by either decompressor site or compressor
site to probe for the presence of its counterpart. This message
should only be sent periodically when the ROHC channel is
experiencing inactivity. The recipient site should send an
Acknowledgement to notify its counterpart about the presence of its
compressor/decompressor.
If no Acknowledgement is received, the sender site should resend the
Heartbeat for a few more times before freeing resources allocated for
its compressor/decompressor.
6.2. Interaction of RCPNP
Diagrams within this section uses the the following notation:
Arrowed line with --- tail is used to indicate traffic within
uncompressed channel. Whereas, arrowed line with === tail is used to
indicate traffic within ROHC channel.
Figure 10 depicts a possible interaction between compressor site and
decompressor site in establishing a new ROHC channel.
Wan, et al. Expires April 20, 2009 [Page 22]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Compressor Site Decompressor Site
| Solicit |
|<----------------------------------------|
| |
| Advertise |
|---------------------------------------->|
| |
| Request (ID=A) |
|<----------------------------------------|
| |
| Reply (ID=B,RefID=A) |
|---------------------------------------->|
| | Create instance
| ACK (RefID=B) | of decompressor
Create |<----------------------------------------|
compressor | |
| Compressed Stream |
|========================================>|
| |
| Compressed Stream |
|========================================>|
| |
| Decompressor Shutdown (ID=A+1) |
Destroy |<----------------------------------------|
compressor | |
| ACK (RefID=A+1) |
|---------------------------------------->| Destroy
| | decompressor
Figure 10: Packets flow of RCPNP negotiating a new ROHC channel and
terminating a ROHC channel
RefID is the Ref ID field and ID is the Identifier in RCPNP messages.
The Reply message uses A in Ref ID field to indicate that it
corresponds to Request message with ID A. Likewise, Acknowledgement
uses Ref ID field to identify the message it acknowledges.
Termination of ROHC channel can be initiated either by compressor
site or decompressor site.
Wan, et al. Expires April 20, 2009 [Page 23]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Compressor Site Decompressor Site
| Compressed Stream |
|========================================>|
| |
| Compressed Stream | Decompressor
|=======================================>X| site abort
| |
| | Decompressor
| Solicit | site restart
|<----------------------------------------|
| |
| Advertise |
|---------------------------------------->|
| |
| Request (ID=A) |
|<----------------------------------------|
| |
| NACK (RefID=A) |
|---------------------------------------->|
| |
| Heartbeat (ID=B) |
|---------------------------------------->|
| |
| NACK (RefID=B) |
Destroy |<----------------------------------------|
compressor | |
| |
Figure 11: Packets flow of RCPNP handling abnormal termination of
decompressor
Figure 11 shows a case where the decompressor suddenly terminates
without sending Decompressor Shutdown message. The decompressor site
tries to re-establish ROHC channel after abrupt termination of
decompressor. Compressor site suspects that decompressor was
terminated abruptly when it receives a Solicitation message and
Request message when its compressor is still active. Upon receiving
these unexpected messages, the compressor site probes for
decompressor at decompressor site and receives a NACK from the
decompressor site. Compressor site can then terminate existing ROHC
channel and compressor. New round of negotiation to establish a new
ROHC channel can be conducted henceforth.
Wan, et al. Expires April 20, 2009 [Page 24]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
7. 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.
Bidirectional ROHC channels must be formed whenever possible by
associating co-located compressor and decompressor. If co-located
compressor and decompressor are not associated, decompressor won't be
able to parse any ROHC compressed packet that piggyback ROHC feedback
properly since it doesn't know the size of CID within the piggybacked
ROHC feedback.
Wan, et al. Expires April 20, 2009 [Page 25]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
8. IANA Consideration
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-Feedback | Figure 6 |
| | | |
| TBD-1: | ULE-ROHC-Neg | Section 6.1 |
+--------+-------------------+-------------+
The ULE-ROHC-Feedback Extension is a Mandatory next-type Extension
Header, specified in Figure 6 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 6.1 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of TBD-1.
Wan, et al. Expires April 20, 2009 [Page 26]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
9. Acknowledgements
We would like to extend our gratitude to Dr. Gorry Fairhurst for his
guidance.
We also want to thank Rod Walsh (Nokia) for his valuable input and
feedback.
Wan, et al. Expires April 20, 2009 [Page 27]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
10. Security Considerations
Technique presented in Section 5.1 allows for DoS. A malicious site
may send packet with a fake source address matching an address that
belongs to a victim site. The compressor gateway upon receiving such
malicious packet may be fooled about the recipient gateway and thus
the intended packet may not be received by victim site once it goes
through the wrong ROHC channel.
To mitigate this problem, compressor gateway that receives such
suspicious packets with similar source address coming from different
frontends of DVB receiver should disable compression and send all
packets uncompressed via uncompressed channel when transmitting
packets with the destination address.
Wan, et al. Expires April 20, 2009 [Page 28]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
11. References
11.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.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)", 12 2005.
11.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.
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759,
Wan, et al. Expires April 20, 2009 [Page 29]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
April 2004.
[RFC4259] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker,
B., and H. Linder, "A Framework for Transmission of IP
Datagrams over MPEG-2 Networks", RFC 4259, 2005.
Wan, et al. Expires April 20, 2009 [Page 30]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 2008
Authors' Addresses
Tat-Chee Wan
Universiti Sains Malaysia
School of Computer Science
Universiti Sains Malaysia
Penang
Malaysia
Phone: +6 04 653 4633
Email: tcwan@nav6.org
URI: http://nrg.cs.usm.my/~tcwan
Way-Chuang Ang
Universiti Sains Malaysia
School of Computer Science
Universiti Sains Malaysia
Penang
Malaysia
Email: wcang@nav6.org
Chee-Hong Teh
Universiti Sains Malaysia
School of Computer Science
Universiti Sains Malaysia
Penang
Malaysia
Email: chteh@nav6.org
Wan, et al. Expires April 20, 2009 [Page 31]
Internet-Draft ROHC over ULE and MPEG-2 TS frames October 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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wan, et al. Expires April 20, 2009 [Page 32]
