[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New I-D: draft-byun-ipdvb-ule-header-comp-00.txt - Anyone interested in header compression?
The enclosed draft was submitted by Do Byun at al, for consideration
by this WG.
Header Compression over Unidirectional Lightweight Encryption (ULE)
draft-byun-ipdvb-ule-header-comp-00.txt
The submission was close to the deadline for -00 I-D's and to
prevent further delay, I'm sending this to the list as an attachment.
The document may appear in the I-D archives soon, but if it does
not it will be resubmitted as soon as they re-open after the
IETF metting.
Discussion on whether this is a suitable topic for study and
protocol development in the IETF is welcome, please do send
emails to this list if you would like to see this topic discussed,
or if you have any other comments on the topic.
Best wishes,
Gorry Fairhurst
(ipdvb Wg Chair)
INTERNET-DRAFT Do J. Byun
October 16, 2006 John Border
Category: Experimental Roderick Ragland
Expiration: March 19, 2007
Header Compression over Unidirectional Lightweight Encryption (ULE)
draft-byun-ipdvb-ule-header-comp-00.txt
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Multi-Protocol Encapsulation (MPE) is widely deployed in DVB-S and
DVB-S2 networks [DVB-S2]. Replacing MPE with Unidirectional
Lightweight Encryption (ULE) has been proposed to gain flexibility
and reduce overhead. This paper introduces a signaling method for
sending header-compressed unicast packets over satellite networks
using ULE, taking advantage of ULE's increased flexibility.
Ed. Note: This is a quick first draft to get the discussion going.
Byun, Border and Ragland Experimental [Page 1]
Header Compression over ULE October 2006
Table of Contents
1. Introduction ...................................................1
2. Terminology ....................................................1
3. Signaling Method ...............................................3
3.1. SNDU Format ...............................................3
3.2. Header Compression Algorithm ..............................4
3.3. Multicast and Broadcast Traffic ...........................5
4. Summary ........................................................5
5. Acknowledgements ...............................................6
6. Security Considerations ........................................6
7. IANA Considerations ............................................6
8. References .....................................................6
1. Introduction
Header compression is a mechanism that compresses the header fields
that do not change or change in predictable ways. RFC 3095
defines "Robust Header Compression (ROHC)" as a standard for
compressing RTP/UDP/IP, UDP/IP and ESP/IP headers. [RFC3095]. There
could be other proprietary compression schemes besides ROHC.
To support header compression, the link-layer has to be flexible
enough to indicate whether the payload is header-compressed or not.
Such indication has been difficult with MPE due to its limited
flexibility in its header format.
Unidirectional Lightweight Encryption has been proposed to overcome
this shortcoming of MPE and there had been numerous proposals to
standardize one as the link-layer protocol of DVB-S2 [GSE]. This
document describes how ULE is used to support header compression
over ISO MPEG-2 transport streams [ISO-MPEG2, RFC4259] for
peer-to-peer traffic.
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]).
Byun, Border and Ragland Experimental [Page 2]
Header Compression over ULE October 2006
MPE
Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A
scheme that encapsulates PDUs, forming a DSM-CC Table Section.
Each Section is sent in a series of TS Packets using a single TS
Logical Channel.
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]).
PSI
Program Specific Information [ISO-MPEG2]. Tables used to convey
information about the service carried in a TS Multiplex. The
information is carried in one of four specifically identified
Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
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).
SI Table
Service Information Table [ISO-MPEG2]. In this document, this
term describes a table that is defined by another standards body
to convey information about the services carried in a TS
Multiplex. A Table may consist of one or more Table Sections;
however, all sections of a particular SI Table must be carried
over a single TS Logical Channel [ISO-MPEG2].
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].
Byun, Border and Ragland Experimental [Page 3]
Header Compression over ULE October 2006
3. Signaling Method
Header compression shall be indicated by the EtherType field of the
ULE header. i.e.) When this this field is set to header compression
type, the payload is header-compressed. The actual type of header
compression is determined during the context establishment between
two peers (one compressor and one decompressor). Therefore, the
method by which the payload is compressed and decompressed is part of
the compression context. Moreover, compression context control
messages can also be header-compressed but their context will be
different from the one for the actual user data.
Decompressor Compressor
| |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| ------ (EtherType=IPv4) Compression Request -----> |
| <----- (EtherType=IPv4) Compression Ack ------ |
| <----- (EtherType=Comp) Compressed payload ------ |
| <----- (EtherType=Comp) Compressed payload ------ |
| <----- (EtherType=Comp) Compressed payload ------ |
| ------ (EtherType=IPv4) Compression Error -----> |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
Figure 1: Header compression example
Figure 1 illustrates an example where control messages (that signal
and synchronize peers to compress/decompress) are not
header-compressed but the user data messages are. When EtherType is
set to 'Comp' whose hex value is TBD, the MPEG-2 payload contains
header-compressed user data messages.
The EtherType of TBD will be a newly registered IANA EtherType number
that indicates a compression algorithm that is agreed by both the
sender and receiver. In other words, it could any proprietary
header compression algorithm as long as the receiver knows how to
decompress it. EtherType of 0x876B (TCP/IP Compression [RFC1144])
was intentionally not used because it is currently defined to imply
a specific header-compression algorithm.
3.1. SNDU Format
This section describes the SNDU format of MPEG-2 PDU with ULE where
headers for PDU are compressed.
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+
Figure 2: SNDU Encapsulation (* optional Destination Address)
Byun, Border and Ragland Experimental [Page 4]
Header Compression over ULE October 2006
Definition of all the fields in Figure 2 stays the same as the
definition in [RFC4326]. The 16-bit type field will have a new
EtherType to indicate the PDU is header-compressed with an algorithm
that both sender and received agreed on. The hex value for this type
is TBD. Note that the new header-compressed PDU EtherType does not
indicate a specific header-compression algorithm. It is the sender
and receiver's responsibility to make sure the algorithm is
synchronized.
Ed. Note: This is one of the main points we want to discuss on the
mailing list.
3.2. Header Compression Algorithm
In order to use the proposed EtherType to indicate the PDU is
header-compressed, both the send and receiver have to agree with
the compression algorithm. This is not an issue because such
synchronization is always required in peer-to-peer header compression
anyway.
Incapable Incompatible
Decompressor Compressor
| |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| Waiting for
| Comp Request
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| Waiting for
| Comp Request
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| Waiting for
| Comp Request
| |
Figure 3: Incapable decompressor
Figure 3 illustrates a scenario where the decompressor (receiver) is
not capable of decompressing the packets that the compressor (sender)
sent. The decompressor does not send any compression request to the
compressor and the compressor continues to send uncompressed headers
to the decompressor with non-header-compression EtherType.
Byun, Border and Ragland Experimental [Page 5]
Header Compression over ULE October 2006
Incompatible Incompatible
Decompressor Compressor
| |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| ------ (EtherType=IPv4) Compression Request -----> |
| detects
| incompatible
| decompressor
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| <----- (EtherType=IPv4) Uncompressed payload ------ |
| |
Figure 4: Incompatible compressor and decompressor
Figure 4 illustrates a scenario where the compressor is not
compatible with the decompressor and therefore it continues to send
uncompressed headers to the decompressor with non-header-compression
EtherType.
Specifics of a header compression algorithm may differ widely. They
include the way header-compression is initiated and synchronized.
For example, compression request messages can be initiated by the
compressor instead of decompressor. Regardless of the algorithm,
the header-compression indication method proposed here signals the
decompressor that the payload is header-compressed with the algorithm
that it agreed to use.
3.3. Multicast and Broadcast Traffic
The proposed header-compressed PDU signaling scheme will not support
multicast or broadcast traffic.
4. Summary
This document defines a mechanism to signal the receiver that the
payload is header-compressed using ULE as the link layer. The
mechansim is compatible with any peer-to-peer header compression
algorithms. It uses a newly proposed EtherType to indicate the
payload is header-compressed. The EtherType has the value of TBD
which is not tied to a specific header compression algorithm.
The proposed method to indicate header-compressed payload is not for
multicast and broadcast as there is no gaurantee that the receivers
are compatible decompressors.
Byun, Border and Ragland Experimental [Page 6]
Header Compression over ULE October 2006
5. Acknowledgements
TBD
6. Security Considerations
The proposed header compression signaling method does not introduce
any additional security concerns.
7. IANA Considerations
A new EtherType number will be proposed to the IANA EtherType
registry. This number will be used to indicate ULE PDU is
header-compressed as described in this document.
8. References:
8.1. Normative References
[ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding
of moving pictures and associated audio information --
Part 1: Systems", International Standards Organization
(ISO), 2000.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for
Low-Speed Serial Links", 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, 1997.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., et al,
"Robust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
2001.
[RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)",
RFC 4326, 2005.
[DVB-S2] Digital Video Broadcasting (DVB); Second generation
framing structure, channel coding and modulation
systems for Broadcasting, Interactive Services, News
Gathering and other broadband satellite applications,
ETSI EN 302 307 V1.1.1, 2005.
8.2. Informative References
[GSE] Fairhurst, G., "A Network-Layer Interface To The
Second Generation Standard For DVB Over Satellite",
Work in Progress, September 2006.
Byun, Border and Ragland Experimental [Page 7]
Header Compression over ULE October 2006
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp,
"Ethernet Local Area Network Specification" Version
2.0, November 1982.
[ITU-H222] H.222.0, "Information technology - Generic coding of
moving pictures and associated audio information:
Systems", International Telecommunication Union,
(ITU-T), 1995.
Authors' Addresses
Do J. Byun
Hughes Network Systems
11717 Exploration Lane
Germantown, MD, 20876
USA
EMail: dbyun@hns.com
John Border
Hughes Network Systems
11717 Exploration Lane
Germantown, MD, 20876
USA
EMail: border@hns.com
Roderick Ragland
Hughes Network Systems
11717 Exploration Lane
Germantown, MD, 20876
USA
EMail: rragland@hns.com
Comments are solicited and should be addressed to the authors.
Byun, Border and Ragland Experimental [Page 8]
Header Compression over ULE October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.