Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen
Document: draft-fairhurst-ipdvb-s2-gule-00.txt
Category: Draft September 2005
An Encapsulation for transmission of
IP datagrams over a DVB-S2 Generic Stream (GULE)
Status of this Draft
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 document describes an Generic Lightweight Encapsulation (ULE)
mechanism for the transport of IPv4 and IPv6 Datagrams and other
network protocol packets directly over the DVB S2 Generic Stream.
This specifies a base encapsulation format and supports an extension
format that allows it to carry additional header information to
assist in network/Receiver processing.
Expires March 2006 [page 1]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
Table of Contents
1. Introduction
2. Conventions used in this document
3. Description of method
4. SNDU Format
4.1 Destination Address Absent (D) Field
4.2 Length Field
4.3 End Indicator
4.4 Type Field
4.4.1 Type 1: Next-Header Type Fields
4.4.2 Type 2: EtherType Compatible Type Fields
4.5 SNDU Destination Address Field
4.6 SNDU Trailer CRC
4.7 Description of SNDU Formats
4.7.1 End Indicator
4.7.2 IPv4 SNDU Encapsulation
4.7.3 IPv6 SNDU Encapsulation
5. Extension Headers
5.1 Test SNDU
5.2 Bridged Frame SNDU Encapsulation
5.3 Extension-Padding Optional Extension Header
5.4 MPEG-2 TS Extension
5.5 SNDU-Resume Extension
5.5.1 SNDU-Resume Extension fragment processing
5.5.2 SNDU-Resume Extension reassembly
6.Processing at the Encapsulator
6.1 SNDU Encapsulation
6.2 Procedure for Padding and Packing
7. Receiver Processing
7.1 Idle State
7.1.1 Idle State Payload Pointer Checking
7.2 Processing of a Received SNDU
7.2.1 Reassembly Payload Pointer Checking
7.3 Other Error Conditions
8. Summary
9. Acknowledgments
10. Security Considerations
11. References
11.1 Normative References
11.2 Informative References
12. Authors' Addresses
13. IPR Notices
13.1 Intellectual Property Statement
13.2 Disclaimer of Validity
14. Copyright Statement
14.1 Intellectual Property Statement
14.2 Disclaimer of Validity
15. IANA Considerations
15.1 IANA Guidelines
Expires March 2006 [page 2]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
1. Introduction
This document describes an encapsulation for transport of IP
datagrams, or other network layer packets, over a link using the
physical layer specified by DVB-S2 [S2] in the Generic Mode [ID-S2].
Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other
network layer packets) for transmission are passed to an
Encapsulator. This formats each PDU into a SubNetwork Data Unit
(SNDU) by adding an encapsulation header and an integrity check
trailer. The SNDU may be fragmented into a series of one or more
BaseBand (BB) frames that are sent over the DVB S2 link.
The method also allows TS Packets to be sent within GULE SNDUs. This
may be used to provide control information and/or Program Specific
Information (PSI) for a Multiplex.
Expires March 2006 [page 3]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
2. Conventions used in this document
The capitalized 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].
More abbreviations should be defined here.
b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order.
BBframe payload [S2]: The data field part of a Baseband frame that
may be used for the communication of data. The BBFrames size varies
from 3072 to 58192 bits according to the FEC being used.
BBH, Baseband Header [S2]: A fixed format 10 byte header that starts
each BBframe.
Counter: A 8-bit value located at a fixed position in the
encapsulation header of all BB frames utilising the GULE
encapsulation. The value is used to monitor in-sequence reception of
BBframes within a Stream, and may be utilised for monitoring
functions as a part of link-layer Operations and Management (OAM).
DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and
data.
Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output in the Generic
Mode of DVB-S2.
End Indicator: A value that indicates to the Receiver that there are
no further SNDUs present within the current BBframe.
Encapsulation Header: The fixed format header that occupies the
first bytes of a BBframe payload.
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 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
Next-Header: A Type value indicating an Extension Header.
NPA: Network Point of Attachment. In this document, refers to a 6
byte destination address (resembling an IEEE MAC address) within the
Expires March 2006 [page 4]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
DVB-S2 transmission network that is used to identify individual
Receivers or groups of Receivers.
Packing Threshold: A period of time an Encapsulator is willing to
defer transmission of a partially filled BBframe to accumulate
more SNDUs, rather than use Padding. After the Packet Threshold
period, the Encapsulator uses Padding to send the partially filled
BBframe.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets.
PP, Payload Pointer: In GULE, the PP is a 16-bit pointer located at
a fixed position in the encapsulation header of all BB frames
utilising the GULE encapsulation. If the BBframe contains the start
of a GULE SNDU, the PP value SHALL be set to the position of the
first byte of the first SNDU within the BBframe. If the BBframe
contains neither the start of a SNDU (or an End Indicator), the
value SHALL be assigned 0xFFFF.
SI Table: Service Information Table [ISO-MPEG2]. In this document,
this term describes a table that is been defined by another
standards body to convey information about the services carried in a
SNDU: Subnetwork Data Unit. An encapsulated PDU sent using GULE.
Stream: A logical flow from an Encapsulator to a set of Receivers.
The addresses at the MAC/NPA level and IP level need to be unique
within a specific stream.
TS: Transport Stream [ISO-MPEG2], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model.
Expires March 2006 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
3. Description of the Method
PDUs (IP packets, Ethernet frames or packets from other network
protocols) are encapsulated to form a Subnetwork Data Unit (SNDU)
associated with a specific Stream at the link layer. The SNDU is
transmitted over an DVB-S2 link by placing it either in a single
BBframe, or if required, an SNDU may be fragmented into a series of
BBframes. A mode also permits an SNDU to be suspended and resumed in
a later BB frame, while preserving the original order of each SNDU
sent to a specific MAC/NPA address over a Stream. Where there is
sufficient space, the method permits a BBframe to carry more than
one SNDU (or part there of), sometimes known as Packing. All parts
comprising an SNDU MUST be assigned to the same Stream.
If a SNDU finishes before the end of a BBframe, but it is not
intended to start another SNDU, a stuffing procedure fills the
remainder of the TS Packet payload with bytes with a value 0xFF,
known as Padding.
A Receiver that receives a value of 0xFF in place of the start of a
SNDU, interprets this as Padding/Stuffing and silently discards the
remainder of the BBframe payload. The payload of the next BBframe
for the same stream will begin with a Payload Pointer of value
0x0000, indicating that the next SNDU immediately follows the
encapsulation header. The ULE protocol resembles this, but differs
in the procedure that binds it to the MPEG-2 TS physical layer.
3.1 BB Encapsulation Header
The payload of each BBframe starts with an encapsulation header
defined by GULE. The GULE encapsulation header is sent as the first
bytes of every BBframe sent by an encapsulation Gateway. The format
of the header is shown below:
< ------------------ BBframe ----------------------- >
+-----+---------------------------------+--------------------+
| BBH |Ver| Resv | Counter | PP | CRC-8 | BB frame payload |
+-----+---------------------------------+--------------------+
< ----Encaspsulation Header---- >
Figure 1: BBframe Encapsulation Header
The BBframe encapsulation header is of a fixed format, identified by
the 4-bit version field. This is followed by a 4-bit reserved field,
a 8-bit BBframe counter, a 16-bit Payload Pointe and an 8-bit CRC-8.
The CRC-8 provides an integrity check for the BB frame header, and
guards against framing mis-alignment that may otherwise result
following corruption of the PP value. The polynomial for computation
of the CRC-8 will be defined in this document.
Expires March 2006 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
4. SNDU Format
This section is Informative, the formats decribed in this section
are defined by ULE [ULERFC].
PDUs are encapsulated using ULE to form an SNDU. The encapsulation
format to be used for PDUs is illustrated below:
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+
Figure 2: SNDU Encapsulation (* optional Destination Address)
This format is identical that defined for ULE [ULE-RFC]. All multi-
byte values (including the Length/End Indicator (4.2,4.3), Type
(4.4), Destination Address (4.5), and Extension Headers (5)) are
transmitted in network byte order (most significant byte first). The
most significant bit of each byte is placed in the left-most
position of the 8-bit field.
4.1 Destination Address Absent (D) Field
The most significant bit of the Length Field carries the value of
the Destination Address Absent Field, the D-bit. A value of 0
indicates the presence of the Destination Address Field (see section
4.5). A value of 1 indicates that a Destination Address Field is not
present.
An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other
SNDUs SHOULD be sent with a D-bit value of 0 (see 4.5).
4.2 Length Field
A 15-bit value that indicates the length, in bytes, of the SNDU
counted from the byte following the Type field, up to and including
the CRC. Note the special case described in 4.3.
4.3 End Indicator
When the first two bytes of an SNDU have the value 0xFFFF, this
denotes an End Indicator (i.e., all ones length combined with a
D-bit value of 1). This indicates to the Receiver that there are no
further SNDUs present within the current BB Frame (see section 6),
and that no Destination Address Field is present.
Expires March 2006 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
4.4 Type Field
The 16-bit Type field indicates the type of payload carried in an
SNDU, or the presence of a Next-Header. The set of values that may
be assigned to this field is divided into two parts, similar to the
allocations for Ethernet.
The first set of ULE Type field values comprise the set of values
less than 1536 in decimal. These Type field values are IANA
assigned (see 4.4.1), and indicate the Next-Header.
The second set of ULE Type field values comprise the set of values
greater than or equal to 1536 in decimal. In ULE, this value is
identical to the corresponding type codes specified by the IEEE/DIX
type assignments for Ethernet and recorded in the IANA EtherType
registry.
4.4.1 Type 1: Next-Header Type Fields
The first part of the Type space corresponds to the values 0 to 1535
Decimal. These values may be used to identify link-specific
protocols and/or to indicate the presence of Extension Headers that
carry additional optional protocol fields. The format is defined by
ULE and the ULE registry maintained by the IANA.
4.4.2 Type 2: EtherType Compatible Type Fields
The second part of the Type space corresponds to the values between
0x600 (1536 decimal) and 0xFFFF. This set of type assignments
follow DIX/IEEE assignments (but exclude use of this field as a
frame length indicator). All assignments in this space MUST use the
values defined for IANA EtherType, the following two Type values are
used as examples (taken from the IANA EtherTypes registry):
0x0800: IPv4 Payload (see 4.7.2)
0x86DD: IPv6 Payload (see 4.7.3)
4.5 SNDU Destination Address Field
The SNDU Destination Address Field is optional (see 4.1). This field
MUST be carried (i.e. D=0) for IP unicast packets destined to
routers that are sent using shared links (i.e., where the same link
connects multiple Receivers). A sender MAY omit this field (D=1) for
an IP unicast packet and/or multicast packets delivered to Receivers
that are able to utilise a discriminator field (e.g. the IPv4/IPv6
destination address, or a bridged MAC destination address), which in
combination with the PID value, could be interpreted as a Link-Level
address.
Expires March 2006 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
When the SNDU header indicates the presence of an SNDU Destination
Address field (i.e. D=0), a Network Point of Attachment, NPA, field
directly follows the fourth byte of the SNDU header. NPA destination
addresses are 6 Byte numbers, normally expressed in hexadecimal,
used to identify the Receiver(s) in a MPEG-2 transmission network
that should process a received SNDU. The value 0x00:00:00:00:00:00,
MUST NOT be used as a destination address in an SNDU. The least
significant bit of the first byte of the address is set to 1 for
multicast frames, and the remaining bytes specify the link layer
multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the
link broadcast address, indicating this SNDU is to be delivered to
all Receivers.
IPv4 packets carrying an IPv4 subnetwork broadcast address need to
be delivered to all systems with the same network prefix. When a
SNDU Destination Address is present (D=0) the value MUST be set to
the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
When the PDU is an IP multicast packet and an SNDU Destination
Address is present (D=0), the IP group destination address of the
multicast packet MUST be mapped to the multicast SNDU Destination
Address (following the method used to generate a destination MAC
address in Ethernet). The method for mapping IPv4 multicast
addresses is specified in [RFC1112]. The method for mapping IPv6
multicast addresses is specified in [RFC2464].
4.6 SNDU Trailer CRC
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of
the SNDU. This position eases CRC computation by hardware. The CRC-
32 polynomial is to be used. Examples where this polynomial is also
employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and
AAL5 [ITU-3563]. This is a 32 bit value calculated according to the
generator polynomial represented 0x104C11DB7 in hexadecimal:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
The Encapsulator initialises the CRC-32 accumulator register to the
value 0xFFFF FFFF. It then accumulates a transmit value for the
CRC32 that includes all bytes from the start of the SNDU header to
the end of the SNDU (excluding the 32-bit trailer holding the CRC-
32), and places this in the CRC Field. In ULE, the bytes are
processed in order of increasing position within the SNDU, the order
of processing bits is NOT reversed. This use resembles, but is
different to that in SCTP [RFC3309].
The Receiver performs an integrity check by independently
calculating the same CRC value and comparing this with the
transmitted value in the SNDU trailer. SNDUs that do not have a
valid CRC, are discarded, causing the Receiver to enter the Idle
State.
Expires March 2006 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
This description may be suited for hardware implementation, but this
document does not imply any specific implementation. Software-based
table-lookup or hardware-assisted software-based implementations are
also possible. Annexe B provides an example of an Encapsulated PDU
that includes the computed CRC-32 value.
The primary purpose of this CRC is to protect the SNDU (header, and
payload) from undetected reassembly errors and errors introduced by
unexpected software / hardware operation while the SNDU is in
transit across the MPEG-2 subnetwork and during processing at the
encapsulation gateway and/or the Receiver. It may also detect the
presence of uncorrected errors from the physical link (however,
these may also be detected by other means, e.g. section 7.3).
4.7 Description of SNDU Formats
The format of an SNDU is determined by the combination of the
Destination Address Absent bit (D) and the SNDU Type Field. The
simplest encapsulation places a PDU directly into an SNDU payload.
Some Type 1 encapsulations may require additional header fields.
These are inserted in the SNDU following the NPA/MAC destination
address and directly preceding the PDU.
Formats may be defined through relevant assignments in the IEEE and
IANA registries.
4.7.1 End Indicator
The format of the End Indicator is defined by ULE [ULERFC]. It is
shown in figure 2. This format MUST carry a D-bit value of 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 0x7FFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= A sequence of zero or more bytes with a value 0xFF filling =
| the remainder of the TS Packet Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format for a ULE End Indicator.
Expires March 2006 [page 10]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
4.7.2 IPv4 SNDU
IPv4 datagrams are directly transported using one of the two
standard SNDU structures, in which the PDU is placed directly in the
SNDU payload. The formats are defined by ULE [ULERFC]. The two
encapsulations are shown in figures 4 and 5. (Note that in this, and
the following figures, the IP datagram payload is of variable size,
and is directly followed by the CRC-32).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for an IPv4 Datagram using L2 filtering (D=0).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SNDU Format for an IPv4 Datagram using L3 filtering (D=1).
4.7.3 IPv6 SNDU Encapsulation
IPv6 datagrams are directly transported using one of the two
standard SNDU structures, in which the PDU is placed directly in the
SNDU payload, as defined by ULE [ULERFC]. The two encapsulations
are shown in figures 6 and 7.
Expires March 2006 [page 11]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SNDU Format for an IPv6 Datagram using L2 filtering (D=0).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
Expires March 2006 [page 12]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
5. Extension Headers
This section describes an extension format for the ULE
encapsulation. In ULE, a Type field value less than 1536 Decimal
indicates an Extension Header. These values are assigned from a
separate IANA registry defined for ULE [ELE-RFC].
The use of a single Type/Next-Header field simplifies processing and
eliminates the need to maintain multiple IANA registries. The cost
is that each Extension Header requires at least 2 bytes. This is
justified, on the basis of simplified processing and maintaining a
simple lightweight header for the common case when no extensions are
present.
A ULE Extension Header is identified by a 16-bit value in the Type
field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN
field and an 8-bit H-Type field, as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN| H-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Structure of ULE Next-Header Field.
The H-LEN Assignment is described below:
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 Indicates an Optional Extension Header of length 10B
>=6 the combined H-LEN and H-TYPE values indicate the EtherType
of a PDU that directly follows this Type field.
The H-LEN value indicates the total number of bytes in an Optional
Extension Header (including the 2B Type field).
An H-LEN value of zero indicates a Mandatory Extension Header. Each
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. A Mandatory
Extension Header MAY modify the format or encoding of the enclosed
PDU (e.g. to perform encryption and/or compression).
The H-Type is a one byte field that is either one of 256 Mandatory
Header Extensions or one of 256 Optional Header Extensions. This is
defined by ULE [ULE-RFC.
The general format for an SNDU with Extension Headers is:
Expires March 2006 [page 13]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
< -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header > < ext 1 >
Figure 9: SNDU Encapsulation with one Extension Header (for D=0).
Where:
D is the ULE D_bit (in this example D=0, however NPA addresses may
also be omitted when using Extension Headers).
T1 is the base header Type field. In this case, specifying a
Next-Header value.
H1 is a set of fields defined for header type T1. There may be 0
or more bytes of information for a specific ULE Extension Header.
T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried.
< -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
Figure 9: SNDU Encapsulation with two Extension Headers (D=1).
Using this method, several Extension Headers MAY be chained in
series [ULE-RFC]. Although an SNDU may contain an arbitrary number
of consecutive Extension Headers, it is not expected that SNDUs will
generally carry a large number of extensions.
5.1 Test SNDU
A Test SNDU is a Mandatory Extension Header of Type 1, specified by
ULE [ULE-RFC].
5.2 Bridge Frame SNDU Encapsulation
A bridged SNDU is a Mandatory Extension Header of Type 1 specified
by ULE [ULE-RFC].
5.3 Extension-Padding Optional Extension Header
The Extension-Padding Optional Extension Header is s specified by
ULE [ULE-RFC].
5.4 MPEG-2 TS Extension
Expires March 2006 [page 14]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
The MPEG-2 TS Extension Header is specified by an IANA assigned H-
Type value of <tbd>. This is a Mandatory Extension. The extension
is used to communicate 1 or more MPEG-2 TS Packets over the DVB-S2
link when utilising the Generic Mode. The number of TS Packets
carried in a specific SNDU is determined from the size specified by
the remainder of the Payload following the MPEG-2 TS Extension. A
Receiver MUST silently discard any data, if present, after the last
complete encapsulated MPEG-2 TS Packet.
A value of D=1 indicates there is no NPA/MAC address in use. A value
D=0 is also permitted, as defined in ULE.
The extension may be used to communicate one or more MPEG-2 TS
Packets of arbitrary content, interpreted according to [ISO-MPEG2].
One expected use is for the transmission of MPEG-2 SI/PSI signalling
and clock references.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0xtbd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SNDU Format for a TS-Packet Payload (D=1)
5.5 SNDU-Resume Extension
The SNDU-Resume Extension is specified by an IANA assigned H-Type
value of <tbd>. This is a Mandatory Extension. The extension is
used to send the remainder of a suspended SNDU. It MAY be used at
any time by Gateway which has already sent the first part of a SNDU.
The payload of an SNDU-Resume Extension contains a Fragment of a
SNDU payload. The final fragment includes the SNDU CRC value
calculated over the entire SNDU. This CRC is used to verify the
integrity and reassembly of the complete PDU.
The Length field in an SNDU-Resume Extension fragment specifies the
size of the remaining SNDU payload. (This includes the 4 byte CRC
value for the complete SNDU payload, see below).
Expires March 2006 [page 15]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
If the number of bytes to be sent in an SNDU-Resume Extension
fragment exceeds the unfilled space in the BB frame payload, then
the Encapsulator SHOULD by default continue transmission in the next
BB frame for the same stream. However, it MAY instead choose (e.g.
utilising a local policy with ACM coding to optimise overall
efficiency) to suspend the partially sent frame.
An SNDU that carries an SNDU-Resume Extension fragment with the
final Fragment of a suspended SNDU carries the CRC of the complete
SNDU (that would have been sent at the end of the of the original
SNDU, had the SNDU not been suspended). This CRC is appended to the
SNDU payload (and is included in the calculated Length of the SNDU
that carries this final Fragment).
Each SNDU (including an SNDU-Resume Extension) also carry a CRC
value that is used to validate framing of the SNDU. This value is
omitted if the SNDU is itself suspended.
5.5.1 SNDU-Resume Extension fragment processing
The Receiver SHOULD provisionally accept all SNDUs with a Length is
greater than the number of bytes remaining in the BBframe, these are
called Fragments. A Receiver could decide to silently discard such
SNDUs to conserve reassembly buffer capacity, or to limit
processing, e.g. if it believes it is under a DoS attack, the
resources consumed exceed some threshold, or other information
indicates the frame has been corrupted by physical layer errors. A
receiver MUST also configure a Fragment-timeout. Fragments that have
been buffered for more than this predetermined period MUST be
discarded (this procedure is invoked, fro example, when an
encapsulation Gateway is restarted).
To reassemble Fragments, a Receiver needs to buffer of up to one
full-sized SNDU for each NPA/MAC filter for which it expects to
receive SNDUs. Reassembly is performed independently for each Stream
the Receiver is configured to receive. Note: A Receiver may be
configured to receive an arbitrary large number of multicast NPA/MAC
addresses over a single stream. This is in contrast to normal
reassembly, where a Receiver needs to buffer at most one SNDU per
stream.
The Receiver detects the presence of a Fragment, when the SNDU
Length is greater than the number of bytes remaining in a BBframe,
and the next BB frame for the same Stream had a PP value of zero.
The processing of fragments uses the following rules:
1) The Receiver receives a subsequent SNDU-Resume Extension fragment
with the same NPA/MAC address of a fragment that is pending
reassembly for the Stream, and which contains less than the expected
number of bytes required to complete the SNDU payload. The Fragments
are then added to the set of Fragments to be later reassembled.
Expires March 2006 [page 16]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
2) The Receiver receives a subsequent SNDU-Resume Extension fragment
with a NPA/MAC address that matches a Fragment pending reassembly
for the Stream, and which contains the expected number of bytes
required to complete the SNDU payload. The Fragments are then
reassembled.
3) The Receiver receives a subsequent SNDU-Resume Extension fragment
that matches the NPA/MAC address of a Fragment pending reassembly
for the Stream, and which contains more than the expected number of
bytes required to complete the SNDU payload. This is a framing
error. All Fragments for this combination of Stream and NPA/MAC
address are then discarded.
4) The Receiver receives a SNDU that is an SNDU-Resume Extension
fragment, but for which it has no Fragments pending reassembly with
the same NPA/MAC address for the Stream. This is not a framing
error. All Fragments for this combination of Stream and NPA/MAC
address are then discarded and the Receiver continues with
processing with of the next received SNDU.
5) The Receiver receives a SNDU that is not an SNDU-Resume Extension
fragment, but has the same NPA/MAC address of a Fragment that is
pending reassembly for the Stream. This is a framing error. All
Fragments for this combination of Stream and NPA/MAC address are
then discarded and the Receiver continues with processing with of
the received SNDU.
6) The Receiver receives a SNDU with an invalid Length of a Fragment
and/or an invalid SNDU CRC. This case is an error, the SNDU is
discarded, and the Receiver enters the idle state (see section 7).
7) Within the period specified by the specified Fragment-timeout,
the Receiver does not receive an SNDU with a subsequent SNDU-Resume
Extension for a NPA/MAC address for which it has Fragments
outstanding. This is a framing error. All Fragments for this
combination of Stream and NPA/MAC address are then discarded.
8) The Receiver decides by other means that it will abort the
reassembly processing. This is a not framing error. All Fragments
for this combination of Stream and NPA/MAC address are discarded.
5.5.1 SNDU-Resume Extension reassembly
When a Receiver has accumulated a set of Fragments with the Length
specified in the SNDU in the base header of the first suspended
Fragment, it proceeds with reassembly.
The total accumulated size of all SNDU fragments (excluding the
appended SNDU CRC) MUST exactly match this Length. SNDUs with an
inconsistent length MUST be discarded (a framing error may be
recorded).
Expires March 2006 [page 17]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
The Receiver MUST verify the SNDU CRC value carried in the final 4
bytes of the final fragment of the SNDU. This value is used only to
verify the integrity of the reassembled SNDU.
A successfully reassembled SNDU payload is processed according to
the Type field specified in the base header of the first suspended
Fragment.
Expires March 2006 [page 18]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
6. Processing at the Encapsulator
The Encapsulator forms the PDUs queued for transmission into SNDUs
by adding a header and trailer to each PDU (section 4). It then
segments the SNDU into a series of TS Packet payloads (figure 9).
These are transmitted using a single TS Logical Channel over a TS
Multiplex. The TS Multiplex may be processed by a number of MPEG-2
(re)multiplexors before it is finally delivered to a Receiver
[ULE-RFC].
+------+------------------------------+------+
|ULE | Protocol Data Unit |ULE |
|Header| |CRC-32|
+------+------------------------------+------+
/ /\ \
/ / \ \
/ / \ \
+-------+-----------------------+ +-------+-------------------+
|Encaps | | |Encaps | |
|Header | | |Header | |
+-------+-----------------------+ +-------+-------------------+
Figure 11: Encapsulation of an SNDU into a series of BB Frames
6.1 SNDU Encapsulation
When an Encapsulator has not previously sent a SNDU for a specific
Stream, or after an Idle period, it starts to send an SNDU in the
first available BB Frame. This BB Frame MUST carry a Payload
Pointer value of zero indicating the SNDU starts in the first
available byte of the BB Frame payload.
The Encapsulation MUST ensure that all BB Frames incremented by one
(modulo 256) the Continuity Counter carried in the Encapsulation
header.
An Encapsulator MAY decide not to immediately send another SNDU,
even if space is available in a partially filled TS Packet. This
procedure is known as Padding (figure 11). The End Indicator informs
the Receiver that there are no more SNDUs in this BB Frame payload.
The End Indicator is followed by zero or more unused bytes until the
end of the TS Packet payload. All unused bytes MUST be set to the
value of 0xFF. The Padding procedure trades decreased efficiency
against improved latency.
Expires March 2006 [page 19]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
+-/------------+
| SubNetwork |
| DU 3 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
| Encaps | End of | 0xFFFF | Unused |
| Header | SNDU 3 | | Bytes |
+--------+--------+--------+----------+
ULE
End
Indicator
Figure 12: A BB Frame carrying the end of SNDU 3, followed by an End
Indicator.
Alternatively, when more packets are waiting at an Encapsulator, and
the BB Frame has sufficient space remaining in the payload, the
Encapsulator can follow a previously encapsulated SNDU with another
SNDU using the next available byte of the BB Frame payload (see
6.2). This is called Packing (figure 13).
+-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork |
| DU 1 | | DU 2 |
+-/----------------+ +----------------/-+
\ \ / /\
\ \ / / \
\ \ / / \. . .
+--------+--------+--------+----------+
| Encaps | Payload| end of | start of |
| Header | Pointer| SNDU 1 | SNDU 2 |
+--------+--------+--------+----------+
| ^
| |
+--------------+
Figure 13: A BB Frame with the end of SNDU 1, followed by SNDU 2.
6.2 Procedure for Padding and Packing
Use of the Packing method by an Encapsulator is optional, and may be
determined on a per-session, per-packet, or per-SNDU basis.
6.3 Suspend/Resume processing
An encapsulation gateway MAY also decide to suspend a SNDU at the
end of BB Frame. In this case, it may continue transmission by
Expires March 2006 [page 20]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
sending SNDUs to other MAC addresses within the same Stream. It
MUST however preserve FIFO delivery of packets with the same MAC
address by either sending a subsequent SNDU-Resume fragment (see
section 5) or by aborting the suspended SNDU (by starting a new SNDU
with the same MAC address).
Expires March 2006 [page 21]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
7. Receiver Processing
A Receiver tunes to a specific S2 Multiplex and sets a receive
filter to accept all Packets from a specific Stream. A single
Receiver may be able to receive multiple Streams. In each case,
reassembly MUST be performed independently for each Stream. To
perform reassembly, the Receiver may use a buffer to hold the
partially assembled SNDU, referred to here as the Current SNDU
buffer. Other implementations may choose to use other data
structures, but MUST provide equivalent operations.
Receipt of a BB Frame with a PP value not equal to 0xFFFF indicates
that the BB Frame contains the start of a new SNDU. The value of
the Payload Pointer indicates the number of bytes to the start of
the first SNDU in the BBframe. It is illegal to receive a Payload
Pointer value greater than the size of the BBframe payload, and this
MUST cause the SNDU reassembly to be aborted and the Receiver to
enter the Idle State. This event SHOULD be recorded as a payload
pointer error.
A Receiver MUST support the use of both the Packing and Padding
method for any received SNDU, and MUST support reception of SNDUs
with or without a Destination Address Field (i.e. D=0 and D=1).
7.1 Idle State
After initialisation, errors, or on receipt of an End Indicator, the
Receiver enters the Idle State. In this state, the Receiver discards
all BBframes until it discovers the start of a new SNDU, when it
then enters the Reassembly State. Figure 14 outlines these state
transitions:
+-------+
| START |
+---+---+
|
\/
+----------+
\| Idle |/
+-------/| State |\-------+
Insufficient | +----+-----+ |
unused space | | PUSI set | Physical Error
or | \/ | or
End Indicator| +----------+ | SNDU Error
| |Reassembly| |
+--------| State |--------+
+----------+
Figure 14: Receiver state transitions
7.1.1 Idle State Payload Pointer Checking
Expires March 2006 [page 22]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
A Receiver in the Idle State MUST check the PP value in the BBframe
header of all received BB frames. Following a loss of
synchronisation, the Receiver MUST discard the number of bytes
indicated by the Payload Pointer (counted from the first byte of the
BB frame payload field), before leaving the Idle State. It then
enters the Reassembly State, and starts reassembly of a new SNDU at
this point.
7.2 Processing of a Received SNDU
When in the Reassembly State, the Receiver reads a 2 byte SNDU
Length Field from the BBframe payload. If the value is less than or
equal to 4, or equal to 0xFFFF, the Receiver discards the Current
SNDU and the remaining SNDU payload (and any Fragments pending
reassenly, see section 5) and returns to the Idle State. Receipt of
an invalid Length Field is an error event and SHOULD be recorded as
an SNDU length error.
If the Length of the Current SNDU is greater than 4, the Receiver
accepts bytes from the BBframe payload to the Current SNDU buffer
until either Length bytes in total are received, or the end of the
BBframe payload is reached (see also 7.2.1). When Current SNDU
length equals the value of the Length Field, the Receiver MUST
calculate and verify the CRC value (see 4.6). SNDUs that contain an
invalid CRC value MUST be discarded. Mismatch of the CRC is an error
event and SHOULD be recorded as a CRC error. The under-lying
physical-layer processing (e.g. forward error correction coding)
often results in patterns of errors, rather than single bit errors,
so the Receiver needs to be robust to arbitrary patterns of
corruption to the BBframe payload, including potential corruption of
the PP, and SNDU Length fields. Therefore, a Receiver SHOULD discard
the remaining BBframe payload (if any) following a CRC mismatch and
return to the Idle State.
When the Destination Address is present (D=0), the Receiver accepts
SNDUs that match one of a set of addresses specified by the Receiver
(this includes the NPA address of the Receiver, the NPA broadcast
address and any required multicast NPA addresses). The Receiver MUST
silently discard an SNDU with an unmatched address.
After receiving a valid SNDU, the Receiver MUST check the Type Field
(and process any Type 1 Extension Headers). The SNDU payload is then
passed to the next protocol layer specified. An SNDU with an unknown
Type value < 1536 MUST be discarded. This error event SHOULD be
recorded as an SNDU type error.
The Receiver then starts reassembly of the next SNDU. This MAY
directly follow the previously reassembled SNDU within the BBframe
payload.
Expires March 2006 [page 23]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
(i) If the Current SNDU finishes at the end of a BBframe, the
Receiver MUST enter the Idle State.
(ii) If only one byte remains unprocessed in the BBframe payload
after completion of the Current SNDU, the Receiver MUST discard this
final byte of BBframe payload. It then enters the Idle State. It
MUST NOT record an error when the value of the remaining byte is
identical to 0xFF.
(iii) If two or more bytes of BBframe payload data remain after
completion of the Current SNDU, the Receiver accepts the next 2
bytes and examines if this is an End Indicator. When an End
Indicator is received, a Receiver MUST silently discard the
remainder of the BBframe payload and transition to the Idle State.
Otherwise this is the start of the next Packed SNDU and the Receiver
continues by processing this SNDU (provided that the BBframe has a
PP value of less than 0xFFFF, see 7.2.1, otherwise the Receiver has
detected a delimiting error and MUST discard all remaining bytes in
the BBframe payload and transitions to the Idle State).
7.2.1 Reassembly Payload Pointer Checking
A Receiver that has partially received an SNDU (in the Current SNDU
buffer) MUST check the PP value in the header of all subsequent
BBframes for the same Stream. If the Payload Pointer does NOT equal
the number of bytes remaining to complete the Current SNDU, i.e.,
the difference between the SNDU Length field and the number of
reassembled bytes, the Receiver may have detected a delimiting
error, or a suspended frame. The receiver follows the procedure
described in section 5.
7.3 Other Error Conditions
The Receiver SHOULD check the BBframe header and physical layer for
information that indicates a BBframe has been corrupted. If
detected, a transmission error event SHOULD be recorded. Any
partially received SNDU MUST be discarded. The Receiver then enters
the Idle State.
The Receiver MUST check the BBframe Counter carried in the
Encapsulation header. If the received value does NOT increment by
one for successive BBframes within a stream (modulo 255), the
Receiver has detected a continuity error. Any partially received
SNDU MUST be discarded. A continuity counter error event SHOULD be
recorded. The Receiver then enters the Idle State.
Expires March 2006 [page 24]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
8. Summary
This document defines an Generic Lightweight Encapsulation (GULE) to
perform efficient and flexible support for IPv4 and IPv6 network
services over networks built upon the DVB S2 physical layer
specification operating in the Generic Mode. The encapsulation is
also suited to transport of other protocol packets and bridged
Ethernet frames.
GULE utilises Extension Header format defined by the Uni-directional
Lihtweight Encapsulation (ULE) defined by RFC-ULE and shares the
associated IANA registry for support of both mandatory and optional
SNDU headers.
9. Acknowledgments
This draft is based on the ULE protocol specification developed by
the IETF ipdvb WG. The author gratefully acknowledges the inputs,
comments and assistance offered by the members of the DVB-GBS ad hoc
group on S2 encapsulation, and the inputs provided by the DVB-RCS WG
in identifying appropriate protocol requirements. The author also
wishes to thank Bernhard Collini-Nocker for his constructive email
and to others who have patiently tried to explain DVB-S.2.
10. Security Considerations
The security considerations for GULE resemble those of ULE, and
security mechanisms developed as ULE extensions are expected to be
appropriate also to the use of GULE.
Expires March 2006 [page 25]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
11. References
11.1 Normative References
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[S2] "EN 302 307, Digital Video Broadcasting (DVB); Second
generation framing structure, channel coding and modulation systems
for Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications European Telecommunication
Standards Institute (ETSI)".
11.2 Informative References
XXX RFC Editor please replace this reference and all citations with
the appropriate RFC number. The I-D referenced is currently ahead in
the RFC-ED queue.
XXX
[RFCXXXX] "Requirements for transmission of IP datagrams over MPEG-2
networks", Internet Draft, Work in Progress.
[ID-S2] "Requirements for transmission of IP datagrams over DVB-
S.2", Internet Draft, Work in Progress.
12. Authors' Addresses
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
Expires March 2006 [page 26]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
13. IPR Notices
13.1 Intellectual Property Statement
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.
13.2 Disclaimer of Validity
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.
14. Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Expires March 2006 [page 27]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005
15. IANA Considerations
This document will require IANA involvement for the assignment of
two new ULE option headers. These options are defined for specific
use cases envisaged by GULE, but are compatible with ULE.
[RFC EDITOR NOTE:
This section must be deleted prior to publication]
DOCUMENT HISTORY
Draft 00
This draft is intended as a study item for proposed future work by
the DVB-GBS in this area. Comments relating to this document will
be gratefully received by the author(s) and may also be sent to ip-
dvb mailing list at: ip-dvb@erg.abdn.ac.uk
--------------------------------------------------------------------
[END of RFC EDITOR NOTE]
Expires March 2006 [page 28]