Internet DRAFT - draft-collini-ipdvb-xule
draft-collini-ipdvb-xule
Internet Engineering Task Force Bernhard Collini-Nocker
Internet Draft Hilmar Linder
Document: draft-collini-ipdvb-xule-00.txt University of Salzburg
Gorry Fairhurst
University of Aberdeen
Category: Internet Draft May 2004
Ultra Lightweight Encapsulation (ULE) Extension Header
Status of this Draft
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document proposes an extension format for the Ultra-Lightweight
Encapsulation (ULE) protocol. The proposed method allows ULE to
carry both optional (with an explicit extension length) and
mandatory (with an implicit extension length) header information to
assist in network/Receiver processing of a SNDU.
These functions modify the behaviour of ULE, and introduce header
processing operations that will simplify the addition of new
headers.
This Internet Draft is presented as a separate document to allow
ipdvb working group discussion of the design trade-offs involved. If
accepted, the techniques will be incorporated within a future
revision of ULE.
Expires November 2004 [page 1]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
[RFC EDITOR NOTE
- This section must be deleted prior to publication]
DOCUMENT HISTORY
This draft is intended as a study item for the IETF ipdvb WG.
Comments relating to this document will be gratefully received by
the author(s) and the ipdvb mailing list at: ipdvb@erg.abdn.ac.uk
Draft -00
-0a based on discussions with B C-N, GF, HL and ipdvb WG list.
-0b corrections to text.
Change in allocation proposal.
-0c amendments to encryption header - addition of encryption block
-0d GF addition based on discussions with AR and WS
-0e GF length field correct - and text returned to B-CN
-0f/g proofreading and preparation of ID
-0h, 0i, 0j, 0k edit to ID -00.
[END of RFC EDITOR NOTE]
Expires November 2004 [page 2]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
Table of Contents
1. Introduction
2. Extension Headers
2.1 Mandatory Extension Headers
2.1 Optional Extension Headers
3. Summary
4. Acknowledgments
5. Security Considerations
6. References
6.1 Normative References
6.2 Informative References
7. Authors' Addresses
8. IANA Considerations
8.1 IANA Guidelines
Annexe A. Examples of use
Expires November 2004 [page 3]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
1. Introduction
This document describes an extension format for the ULE [ULE]
encapsulation for transport of IP datagrams or other network layer
packets over ISO MPEG-2 Transport Streams [ISO-MPEG]. The
terminology used is defined in [ULE].
2. Extension Headers
PDUs in ULE [ULE] are encapsulated to form a SNDU. Each SNDU is sent
as an MPEG-2 Payload Unit. The encapsulation format to be used for
PDUs (IP packets and bridged Ethernet frames) is illustrated below
(in these examples, for simplicity we assume D=1, if D=0, a NPA
destination address is inserted directly after the Type field of the
base header if D=1, or the NPA address if D=0:
<-------------------------- SNDU -------------------------->
+---+---------------------------------------------------+--------+
|D=0| Length | Type | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
<- ULE base header ->
Figure 1: SNDU Encapsulation, with no Extension Header
In ULE, the Type field is assigned an IANA assigned value. All
values above 1535 (decimal) follow the IEEE/DIX type assignments for
Ethernet.
Values less than 1536 (decimal) indicate a next-layer-header and are
assigned from a separate IANA registry for ULE.
The general format for these next-layer-header fields value is:
<-------------------------- SNDU -------------------------->
+---+--------------------------------------------------+--------+
|D=0| Length | H1 | T1 | ...| Hn | Tn | Type | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
<- ULE base header ->
Figure 2: SNDU Encapsulation, with n Extension Headers
Where:
D is the ULE D_bit.
T1 is the base header Type field. In this case, it specifies a next-
layer-header value.
H1 is a set of fields defined for header type T1. There may be 0 or
more bytes of header information in a specific ULE extension.
T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried.
Expires November 2004 [page 4]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
<-------------------------- SNDU ---------------------------->
+---+---------------------------------------------------+--------+
|D=0| Length | H1 | T1 | T2 | H2 | Type | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
<- ULE base header ->
Figure 3: SNDU Encapsulation, with two Extension Headers
The above figure shows a SNDU that includes two extension headers.
The Type values of T1 and T2 are both less than 1536 (decimal)
indicating the presence of a next-layer-header rather than a
directly following PDU. Using this method several headers may be
chained in series.
The 16-bit ULE next-layer-header field is used in place of the Type
value. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field
and an 8-bit H-Type field, as follows:
+----+-----+--------+
|0000|H-LEN| H-TYPE |
+----+-----+--------+
Figure 4: Structure of ULE Type field.
H-LEN Assignment
0 Indicates a Mandatory Extension Header
1 Indicates an Optional Extension Header of length 2B
2 Indicates an Optional Extension Header of length 4B
3 Indicates an Optional Extension Header of length 6B
4 Indicates an Optional Extension Header of length 8B
5 RESERVED for future use.
>=6 the combined H-LEN and H-TYPE values indicate the Ethertype
of a PDU that directly follows this Type field.
A H-LEN of zero indicates a Mandatory Extension Header. Each
specific Mandatory Extension header has a pre-defined length, that
is not communicated in the H-LEN field. No additional limit is
placed on the maximum length of a Mandatory Extension Header.
2.1 Mandatory Extension Headers
The term Mandatory refers to the processing action required to
forward a PDU and not to a requirement to implement an specific
option. That is, Receivers are NOT required to implement all types
of Mandatory Extension Headers, but MUST process these headers
according to the following rules: A Receiver that receives a ULE
SNDU with a next-layer-header value indicating a Mandatory Extension
Header (i.e. a value less than 255 decimal) has two processing
options:
Expires November 2004 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
(i) It MAY process the header, and continue processing the
remainder of the SNDU.
(ii) If it does not recognise the next-layer-header value, or
is configured to reject the next-layer-header it MUST discard
the remainder of the SNDU and commence processing with the next
SNDU.
Since the Receiver will suspend processing of a SNDU in case 2,
there is no need for an explicit header length field to indicate the
length of a mandatory extension.
The following mandatory next-layer-header types are defined in the
ULE specification:
0x0000: Test SNDU, discarded by the Receiver
0x0001: Bridged Ethernet Frame
0x0002: Mandatory Odd Encryption Header (see section A.1)
0x0003: Mandatory Even Encryption Header (see section A.1)
The format of additional Mandatory Extension Headers will be
specified in documents separate to the ULE base header, and these
must specify the format and length of the specific extension header.
2.2 Optional Extension Headers
A next-layer-header value greater than or equal to 512 decimal
(0x0100, hexadecimal) and less than 1536 decimal (0x600,
hexadecimal), indicates an Optional Extension Header. When a
Receiver encounters a next-layer-header indicating an Optional
Extension Headers, it MAY be configured to either:
(i) Process the Optional Extension Header. This requires the
Receiver to parse the bytes contained in this extension header.
After parsing the extension header, the Receiver MAY decide to
modify the processing of the remaining bytes within the SNDU.
(ii) Ignore the Optional Extension Header. The Receiver MUST
skip the number of bytes corresponding to the Extension header
length (H-LEN), before reading the Type value that follows the
extension header.
The chosen processing depends upon the set of implemented Optional
Extension Headers and the Receiver configuration. The length of each
Optional Extension Header (in 2-byte words, including the extension
payload type that follows each header) is implicit in the high-order
byte of the extension type. This header length, is known as the H-
LEN value. All Receivers MUST validate the H-LEN value, if this
value would cause the total header length to exceed the SNDU Length,
the Receiver MUST discard the SNDU. The Receiver SHOULD record an
illegal extension length error.
Expires November 2004 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
The following optional next-layer-header types are defined in the
ULE specification:
0x0100: Null Option, this header MUST be skipped by the
Receiver.
The format of other extension header fields will be specified in an
IETF document.
3. Summary
This document defines an extension header format for the Ultra
Lightweight Encapsulation (ULE) to perform efficient and flexible
support for including mandatory and optional SNDU headers.
This document takes several design decisions that need to be
considered by the ipdvb working group:
First, it assumes the need for both optional and Mandatory Extension
Headers. The authors suggest this is an important protocol
component, since once this function is added, it allows future
extension of the protocol, while providing backwards capability with
existing protocol releases. In particular, Optional Extension
Headers MAY be safely ignored by drivers that do not implement them,
or choose not to process them.
Second, it assumes that headers may be specified using the Type
registry, although in IPv6 a separate registry is used for this
purpose. The rationale for this decision is that it is not expected
that packets will carry a large number of consecutive extension
headers. The use of a single type space simplifies processing and
saves assignment and the need to maintain multiple IANA registries.
The cost is that a 2 byte value is used, with a small increase in
both overhead and processing cost.
Third, it assumes that the presence of extension headers can be
indicated using the Type field of the base header, rather than by
allocating bits within the header to indicate whether extensions are
present. This is justified, on the basis of simplified processing
and that it maintains a simple lightweight header for the common
case when no extensions are present.
Fourth, based on discussions within the ipdvb WG, the high-order
byte of the Type 1 header is used to indicate the Length (H-LEN) of
the extension header. This saves establishing a separate field for
this purpose. This reduces the available code-points for Types, but
still leaves adequate space for all envisaged extensions.
Expires November 2004 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
4. Acknowledgments
The authors wish to thank the members of the ipdvb mailing list for
the input provided. Particular thanks to Hilmar Linder, who helped
structure the arguments and basic syntax, to Alain Ritoux and
William Stanislaus for their suggestions and many improvements to
the design.
5. Security Considerations
The security issues for this document are the same as those for ULE
itself. Security issues are not addressed in this document.
6. References
6.1 Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic
coding of moving pictures and associated audio information:
Systems", International Standards Organisation (ISO).
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ULE] Fairhurst, G., Collini-Nocker, "Ultra Lightweight
Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB
networks", <draft-ietf-ule-00.txt>, IETF Work in Progress.
6.2 Informative References
7.Authors' Addresses
Bernhard Collini-Nocker
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
Email: bnocker@cosy.sbg.ac.at
Web: http://www.cosy.sbg.ac.at/sc/
Hilmar Linder
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
Expires November 2004 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
Email: hlinder@cosy.sbg.ac.at
Web: http://www.cosy.sbg.ac.at/sc/
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
8. IANA Considerations
As in ULE, this document will require IANA involvement:
The payload type field defined in this document must be aligned with
an existing IANA registry or the following values need to be
assigned by the IANA:
ULE Type Field
8.1 IANA Guidelines
The following contains the IANA guidelines for management of the ULE
Next-Protocol-Header registry.
This registry allocates values decimal 0-1535 (0x0000-0x05FF,
hexadecimal). It MUST NOT allocate values greater than 1535
Expires November 2004 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
(decimal), since such values overlap the assignments made in the
IANA Ethertypes registry.
It subdivides the Next-Layer-Header registry in the following way:
1) 0-255 (decimal) IANA assigned values indicating Mandatory
extension headers (or link-dependent type fields) for ULE,
requiring prior issue of an IETF standards-track RFC.
2) 256-511 (decimal) IANA assigned values indicating Optional
extension headers for ULE with no additional extension data,
requiring prior issue of an IETF standards-track RFC.
3) 512-767 (decimal) IANA assigned values indicating Optional
extension headers for ULE with 2 bytes of extension data,
requiring prior issue of an IETF standards-track RFC.
4) 768-1023 (decimal) IANA assigned values indicating Optional
extension headers for ULE with 4 bytes of extension data,
requiring prior issue of an IETF standards-track RFC.
5) 1024-1535 (decimal) IANA assigned values indicating Optional
Extension Headers for ULE with 6 bytes of extension data,
requiring prior issue of an IETF standards-track RFC.
Note in this format of assignment, the first byte also serves as a
count of the number of optional 2-byte words.
XXX Author Note: Should the category 5 indicate 6 bytes? -- Or
should we RESERVE this for future use???
XXX Author Note: Do we need an uncoordinated category? - In which
case should we, e.g., assign the highest value of each length for
private use? XXX
Expires November 2004 [page 10]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
Annexe A: Illustrative Examples
[RFC Ed note]
This annexe to be removed.
The following examples are hypothetical, and it is not the purpose
of this appendix to define these new extensions. Such extensions
may be defined by other documents or within a future revision of
this ID. The examples are included here only to illustrate how such
extensions may be defined, and are provided for discussion by the
IETF ipdvb working group.
A.1 Encryption Extension Header A and B
The Encryption Extension header format is an example of a Mandatory
Extension Header. This extension format defines two styles of
extension headers (functionally equivalent to the encryption control
behaviour of DSM-CC/MPE). PDUs that are not encrypted, do NOT
include this header.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 | Length (2B) | Type = 0x00YY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
= =
| (Link encryption control block) |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EtherType (2B) | |
+--+--+--+--+--+--+--+--+ |
= =
| (PDU or Extension Header) |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ ULE CRC-32 (4B) +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure A1: SNDU Format for the Encryption Header.
This encryption header has a type value with one of two IANA-
assigned 16-bit next-layer-header values.
[IANA ACTION]
IANA action is required to assign two successive code points from
ULE Next-Layer-Header in the range 0x0000 -0x00FF.
00YY General Encryption Extension A
Expires November 2004 [page 11]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
This indicates encryption using an even encryption key.
00YY General Encryption Extension B.
This indicates encryption using an odd encryption key
[END of IANA ACTION]
The usage of the encryption header resembles that specified for MPE
encryption. The specification of encryption algorithms and key
management protocols is beyond the scope of this Document.
Note that the encryption header is mandatory, that is a Receiver
MUST process this header, before it processes the next header, or
enclosed PDU.
Similar processing is also performed for SNDUs with D=0. (Note in
this case, the NPA value is not encrypted).
A.1.1 IPv4-specific Encryption Extension Header
The IPv4 Encryption Extension Header is an example of a Mandatory
Extension Header, it is a specific variant of the header described
in A.1. This header is only appropriate to PDUs that are IPv4, the
general Encryption Extension header MUST be used for all other types
of PDU, and MAY be used for IPv4:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 | Length (2B) | Type = 0x00WW |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
= =
| (Link encryption control block) |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
= =
| (PDU - IPv4) |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ ULE CRC-32 (4B) +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure A2: SNDU Format for the Encryption Header.
PDUs that are not encrypted, do NOT include this header. An
encryption header has a type value with one of two IANA-assigned 16-
bit next-layer-header values.
Expires November 2004 [page 12]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
[IANA ACTION]
IANA action is required to assign two successive code points from
ULE Next-Layer-Header in the range 0x0000 -0x00FF.
00WW IPv4-specific Encryption Extension A
This indicates encryption using an even encryption key.
00WW IPv4-specific Encryption Extension Header B.
This indicates encryption using an odd encryption key
[END of IANA ACTION]
The usage of the encryption header resembles that specified for MPE
encryption. The specification of encryption algorithms and key
management protocols is beyond the scope of this Document.
Note that the encryption header is mandatory, that is a Receiver
MUST process this header, before it processes the enclosed PDU.
Similar processing is also performed for SNDUs with D=0.
XXX Similar header could/should/must also be defined for IPv6 and
possibly for bridging - although all other protocols such as arp
MUST use the generic headers XXX
Expires November 2004 [page 13]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003
A.2 ULE Bridged Ethernet Frame
The following ULE Bridged Ethernet Frame is an example of a
Mandatory Extension Header:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 | Length (2B) | Type = 0x0001 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MAC Destination Address (6B) |
+ +--+--+--+--+--+--+--+--+
| | |
+--+--+--+--+--+--+--+--+ +
| MAC Source Address (6B) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EtherType (2B) | |
+--+--+--+--+--+--+--+--+ |
= =
| (Contents of bridged MAC frame) |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ ULE CRC-32 (4B) +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure A3: SNDU Format for a Bridged Payload
[IANA ACTION]
IANA action is required to assign two successive code points from
ULE Next-Layer-Header in the range 0x0000 -0x00FF.
0001 Bridged Ethernet Frame
[END of IANA ACTION]
Note that the final two bytes of the bridging header also have a
Type field. This is true of all ULE extension headers, but in this
special case the mandatory header format permits this to carry a LLC
Length field, specified by IEEE 802. Normally this will be an IANA
assigned value.
Similar processing is also performed for SNDUs with D=0.
[END of RFC Ed note to remove annexe ]
Expires November 2004 [page 14]
