draft-ietf-ipdvb-ule-05.txt   draft-ietf-ipdvb-ule-06.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen Internet Draft University of Aberdeen
Document: draft-ietf-ipdvb-ule-05.txt Bernhard Collini-Nocker Document: draft-ietf-ipdvb-ule-06.txt Bernhard Collini-Nocker
University of Salzburg University of Salzburg
ipdvb WG ipdvb WG
Category: Draft, Intended Standards Track February 2005 Category: Draft, Intended Standards Track June 2005
Ultra Lightweight Encapsulation (ULE) for transmission of Unidirectional Lightweight Encapsulation (ULE) for transmission of
IP datagrams over an MPEG-2 Transport Stream IP datagrams over an MPEG-2 Transport Stream
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress". reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The MPEG-2 Transport Stream (TS) has been widely accepted not only The MPEG-2 Transport Stream (TS) has been widely accepted not only
for providing digital TV services, but also as a subnetwork for providing digital TV services, but also as a subnetwork
technology for building IP networks. technology for building IP networks.
This document describes an Ultra Lightweight Encapsulation (ULE) This document describes a Unidirectional Lightweight Encapsulation
mechanism for the transport of IPv4 and IPv6 Datagrams and other (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and
network protocol packets directly over the ISO MPEG-2 Transport other network protocol packets directly over the ISO MPEG-2
Stream as TS Private Data. ULE specifies a base encapsulation format Transport Stream as TS Private Data. ULE specifies a base
and supports an extension format that allows it to carry additional encapsulation format and supports an extension format that allows it
header information to assist in network/Receiver processing. to carry additional header information to assist in network/Receiver
processing.
Expires July 2005 [page 1] Expires November 2005 [page 1]
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Conventions used in this document 2. Conventions used in this document
3. Description of method 3. Description of method
4. SNDU Format 4. SNDU Format
4.1 Destination Address Absent (D) Field 4.1 Destination Address Absent (D) Field
4.2 Length Field 4.2 Length Field
4.3 End Indicator 4.3 End Indicator
skipping to change at line 103 skipping to change at line 104
15. IANA Considerations 15. IANA Considerations
15.1 IANA Guidelines 15.1 IANA Guidelines
ANNEX A: Informative Appendix - SNDU Packing Examples ANNEX A: Informative Appendix - SNDU Packing Examples
ANNEX B: Informative Appendix - SNDU Encapsulation ANNEX B: Informative Appendix - SNDU Encapsulation
Expires July 2005 [page 2] Expires July 2005 [page 2]
1. Introduction 1. Introduction
This document describes an encapsulation for transport of IP This document describes an encapsulation for the transport of IP
datagrams, or other network layer packets, over ISO MPEG-2 Transport datagrams, or other network layer packets, over ISO MPEG-2 Transport
Streams [[ISO-MPEG2; ID-ipdvb-arch]. It is suited to services based Streams [ISO-MPEG2; RFCXARCHX]. The encapsulation satisfies the
on MPEG-2, for example the Digital Video Broadcast (DVB) requirement for a lightweight encapsulation defined in section 4 of
architecture, the Advanced Television Systems Committee (ATSC) [RFCXARCHX]. The basic header provides the required set of protocol
system [ATSC; ATSC-G], and other similar MPEG-2 based transmission fields. Extension headers may also be defined. This header structure
systems. Such systems provide unidirectional (simplex) physical and is significantly simpler to parse and process [SOOR05] than current
link layer standards. Support has been defined for a wide range of alternative methods (e.g. MPE [ETSI-DAT] that builds upon the DSM-CC
physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Table Section syntax [ISO-DSMCC]).
Satellite TV [ETSI-DVBS; ATSC-S], Cable Transmission [ETSI-DVBC;
ATSC-PSIP-TC]). Bi-directional (duplex) links may also be The encapsulation is suited to services based on MPEG-2, for example
established using these standards (e.g., DVB defines a range of the Digital Video Broadcast (DVB) architecture, the Advanced
return channel technologies, including the use of two-way satellite Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other
links [ETSI-RCS] and dial-up modem links [RFC3077]). similar MPEG-2 based transmission systems. Such systems provide
unidirectional (simplex) physical and link layer standards. Support
has been defined for a wide range of physical media (e.g.
Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS;
ATSC-S], Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]).
Bi-directional (duplex) links may also be established using these
standards (e.g., DVB defines a range of return channel technologies,
including the use of two-way satellite links [ETSI-RCS] and dial-up
modem links [RFC3077]).
Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other
network layer packets) for transmission over an MPEG-2 Transport network layer packets) for transmission over an MPEG-2 Transport
Multiplex are passed to an Encapsulator. This formats each PDU into Multiplex are passed to an Encapsulator. This formats each PDU into
a SubNetwork Data Unit (SNDU) by adding an encapsulation header and a SubNetwork Data Unit (SNDU) by adding an encapsulation header and
an integrity check trailer. The SNDU is fragmented into a series of an integrity check trailer. The SNDU is fragmented into a series of
TS Packets that are sent over a single TS Logical Channel. one or more MPEG-2 Transport Stream (TS) Packets that are sent over
a single TS Logical Channel.
The MPEG-2 specification [ISO-MPEG2] requires conformant TS The MPEG-2 specification [ISO-MPEG2] requires conformant TS
Multiplexes to provide Program Specific Information (PSI) for Multiplexes to provide Program Specific Information (PSI) for
each stream in the TS Multiplex. Other MPEG-2 based transmission each stream in the TS Multiplex. Other MPEG-2 based transmission
standards may also define Service Information (SI). This standards may also define Service Information (SI).
information may allow Receivers and Re-multiplexors
[draft-ipdvb-arch] to locate a specific ULE Stream (i.e., the PID This information may allow Receivers and Re-multiplexors
value of the TS Logical Channel that carries a ULE Stream). The [RFCXARCHX] to locate a specific ULE Stream (i.e., the PID value of
conditions under which this information is required, and the the TS Logical Channel that carries a ULE Stream). The conditions
format in which it is to be provided is beyond the scope of under which this information is required, and the format in which it
this document. Addressing and mapping issues for ULE over MPEG-2 is to be provided is beyond the scope of this document. Addressing
are also described in [draft-ipdvb-ar]. and mapping issues for ULE over MPEG-2 are also described in
[ID-ipdvb-ar].
Expires July 2005 [page 3] Expires July 2005 [page 3]
2. Conventions used in this document 2. Conventions used in this document
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Other terms used in this document are defined below: Other terms used in this document are defined below:
Adaptation Field: An optional variable-length extension field of the Adaptation Field: An optional variable-length extension field of the
fixed-length TS Packet header, intended to convey clock references fixed-length TS Packet header, intended to convey clock references
and timing and synchronization information as well as stuffing over and timing and synchronization information as well as stuffing over
an MPEG-2 Multiplex [ISO-MPEG2]. an MPEG-2 Multiplex [ISO-MPEG2].
AFC: Adaptation Field Control [ISO_MPEG]. A pair of bits carried in AFC: Adaptation Field Control [ISO-MPEG2]. A pair of bits carried in
the TS Packet header that signal the presence of the Adaptation the TS Packet header that signal the presence of the Adaptation
Field and/or TS Packet payload. Field and/or TS Packet payload.
ATSC: Advanced Television Systems Committee [ATSC]. A framework and ATSC: Advanced Television Systems Committee [ATSC]. A framework and
a set of associated standards for the transmission of video, audio, a set of associated standards for the transmission of video, audio,
and data using the ISO MPEG-2 standard. and data using the ISO MPEG-2 standard.
b: bit. For example, one byte consists of 8b. b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order. B: Byte. Groups of bytes are represented in Internet byte order.
skipping to change at line 181 skipping to change at line 192
Standards Institute (ETSI) for the transmission of video, audio, and Standards Institute (ETSI) for the transmission of video, audio, and
data, using the ISO MPEG-2 Standard. data, using the ISO MPEG-2 Standard.
Encapsulator: A network device that receives PDUs and formats these Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output as a stream of into Payload Units (known here as SNDUs) for output as a stream of
TS Packets. TS Packets.
End Indicator: A value that indicates to the Receiver that there are End Indicator: A value that indicates to the Receiver that there are
no further SNDUs present within the current TS Packet. no further SNDUs present within the current TS Packet.
LLC: Logical Link Control [ISO-8802-2]. A link layer protocol LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]]. A link layer
defined by the IEEE 802 standard, which follows the Ethernet MAC protocol defined by the IEEE 802 standard, which follows the
Header. Ethernet MAC Header.
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
MAC Header: The link layer header of the IEEE 802.3 standard [IEEE- MAC Header: The link layer header of the IEEE 802.3 standard
802.3] or Ethernet v2 [DIX]. It consists of a 6B destination [IEEE-802.3] or Ethernet v2 [DIX]. It consists of a 6B destination
address, 6B source address, and 2B type field (see also NPA, LLC). address, 6B source address, and 2B type field (see also NPA, LLC).
Expires July 2005 [page 4] Expires July 2005 [page 4]
MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A
scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 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 Section is sent in a series of TS Packets using a single TS Logical
Channel. Channel.
MPEG-2: A set of standards specified by the Motion Picture Experts MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards Group (MPEG), and standardized by the International Standards
Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222
[ITU-H222]).
Next-Header: A Type value indicating an Extension Header. Next-Header: A Type value indicating an Extension Header.
NPA: Network Point of Attachment. In this document, refers to a 6 NPA: Network Point of Attachment. In this document, refers to a 6
byte destination address (resembling an IEEE MAC address) within the byte destination address (resembling an IEEE MAC address) within the
MPEG-2 transmission network that is used to identify individual MPEG-2 transmission network that is used to identify individual
Receivers or groups of Receivers. Receivers or groups of Receivers.
Packing Threshold: A period of time an Encapsulator is willing to Packing Threshold: A period of time an Encapsulator is willing to
defer transmission of a partially filled TS-Packet to accumulate defer transmission of a partially filled TS-Packet to accumulate
more SNDUs, rather than use Padding. After the Packet Threshold more SNDUs, rather than use Padding. After the Packet Threshold
period, the Encapsulator uses Padding to send the partially filled period, the Encapsulator uses Padding to send the partially filled
TS-Packet. TS-Packet.
"Padding: A method that fills the remaining unused bytes in a TS
Packet payload using the specific pattern of 0xFF."
Payload Unit, PU. A sequence of bytes sent using a TS. Examples of
Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets. IPv4 or IPv6 datagrams, and other network packets.
PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS
packet payload usually used for video or audio information. packet payload usually used for video or audio information.
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the
header of TS Packets. This is used to identify the TS Logical header of TS Packets. This is used to identify the TS Logical
Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
forming the parts of a Table Section, PES, or other Payload Unit forming the parts of a Table Section, PES, or other Payload Unit
must all carry the same PID value. The all 1s PID value indicates a must all carry the same PID value. The all zeros PID 0x0000 as well
Null TS Packet introduced to maintain a constant bit rate of a TS as other PID values are reserved for specific PSI/SI Tables [ISO-
Multiplex. There is no required relationship between the PID values MPEG2]. The all ones PID value 0x1FFF indicates a Null TS Packet
used for TS Logical Channels transmitted using different TS introduced to maintain a constant bit rate of a TS Multiplex. There
Multiplexes. is no required relationship between the PID values used for TS
Logical Channels transmitted using different TS Multiplexes.
PP: Payload Pointer [ISO-MPEG2]. An optional one byte pointer that PP: Payload Pointer [ISO-MPEG2]. An optional one byte pointer that
directly follows the TS Packet header. It contains the number of directly follows the 4 byte TS Packet header. It contains the number
bytes between the end of the TS Packet header and the start of a of bytes that follow the Payload Pointer, up to the start of the
Payload Unit. The presence of the Payload Pointer is indicated by first Payload Unit (counted from the first byte of the TS Packet
the value of the PUSI bit in the TS Packet header. The Payload payload field, and excluding the PP field itself). The presence of
Pointer is present in DSM-CC, and Table Sections, it is not present the Payload Pointer is indicated by the value of the PUSI bit in the
in TS Logical Channels that use the PES-format. TS Packet header. The Payload Pointer is present in DSM-CC, Table
Expires July 2005 [page 5]
Sections, and ULE. It is not present in TS Logical Channels that use
the PES-format.
Private Section: A syntactic structure constructed in accordance Private Section: A syntactic structure constructed in accordance
with Table 2-30 of [ISO-MPEG2]. The structure may be used to with Table 2-30 of [ISO-MPEG2]. The structure may be used to
identify private information (i.e. not defined by [ISO-MPEG2]) identify private information (i.e. not defined by [ISO-MPEG2])
relating to one or more elementary streams, or a specific MPEG-2 relating to one or more elementary streams, or a specific MPEG-2
program, or the entire Transport Stream. Other Standards bodies, program, or the entire Transport Stream. Other Standards bodies,
e.g. ETSI, ATSC, have defined sets of table structures using the e.g. ETSI, ATSC, have defined sets of table structures using the
private_section structure. A Private Section is transmitted as a private_section structure. A Private Section is transmitted as a
Expires July 2005 [page 5]
sequence of TS Packets using a TS Logical Channel. A TS Logical sequence of TS Packets using a TS Logical Channel. A TS Logical
Channel may carry sections from more than one set of tables. Channel may carry sections from more than one set of tables.
PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey
information about services carried in a TS Multiplex. It is carried
in one of four specifically identified table section constructs
[ISO-MPEG2], see also SI Table.
PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey
information about the service carried in a TS Multiplex. The set of information about the service carried in a TS Multiplex. The
PSI tables is defined by MPEG-2 [ISO-MPEG2]. See also SI Table. information is carried in one of four specifically identified Table
Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
PU: Payload Unit. A sequence of bytes sent using a TS. Examples of PU: Payload Unit.
Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. A single bit flag PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. A single bit flag
carried in the TS Packet header. A PUSI value of zero indicates that carried in the TS Packet header. A PUSI value of zero indicates that
the TS Packet does not carry the start of a new Payload Unit. A PUSI the TS Packet does not carry the start of a new Payload Unit. A PUSI
value of one indicates that the TS Packet does carry the start of a value of one indicates that the TS Packet does carry the start of a
new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the
presence of a one byte Payload Pointer (PP). presence of a one byte Payload Pointer (PP).
Receiver: Equipment that processes the signal from a TS Multiplex Receiver: Equipment that processes the signal from a TS Multiplex
and performs filtering and forwarding of encapsulated PDUs to the and performs filtering and forwarding of encapsulated PDUs to the
network-layer service (or bridging module when operating at the link network-layer service (or bridging module when operating at the link
layer). layer).
SI Table: Service Information Table [ISO-MPEG2]. In this document, SI Table: Service Information Table [ISO-MPEG2]. In this document,
this term describes a table that is been defined by another this term describes a table that is defined by another standards
standards body to convey information about the services carried in a body to convey information about the services carried in a TS
TS Multiplex. A Table may consist of one or more Table Sections, Multiplex. A Table may consist of one or more Table Sections,
however all sections of a particular SI Table must be carried over a however all sections of a particular SI Table must be carried over a
single TS Logical Channel [ISO-MPEG2]. single TS Logical Channel [ISO-MPEG2].
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit. Payload Unit.
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table Section: A Payload Unit carrying all or a part of an SI or PSI
Table [ISO-MPEG2]. Table [ISO-MPEG2].
TS: Transport Stream [ISO-MPEG2], a method of transmission at the TS: Transport Stream [ISO-MPEG2], a method of transmission at the
skipping to change at line 311 skipping to change at line 327
*1b Transport Error Indicator *1b Transport Error Indicator
*1b Payload Unit Start Indicator (PUSI) *1b Payload Unit Start Indicator (PUSI)
1b Transport Priority 1b Transport Priority
*13b Packet IDentifier (PID) *13b Packet IDentifier (PID)
2b Transport scrambling control 2b Transport scrambling control
*2b Adaptation Field Control (AFC) *2b Adaptation Field Control (AFC)
*4b Continuity Counter (CC) *4b Continuity Counter (CC)
TS Logical Channel: Transport Stream Logical Channel. In this TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level document, this term identifies a channel at the MPEG-2 level
[ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model. [ISO-MPEG2]. It exists at level 2 of the ISO/OSI reference model.
All packets sent over a TS Logical Channel carry the same PID All packets sent over a TS Logical Channel carry the same PID value
value (this value is unique within a specific TS Multiplex). The (this value is unique within a specific TS Multiplex). The term
term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the
content carried by a specific TS Logical Channel (see, ULE Stream). content carried by a specific TS Logical Channel (see, ULE Stream).
Some PID values are reserved (by MPEG-2) for specific signalling. Some PID values are reserved (by MPEG-2) for specific signalling.
Other standards (e.g., ATSC, DVB) also reserve specific PID values. Other standards (e.g., ATSC, DVB) also reserve specific PID values.
TS Multiplex: In this document, this term defines a set of MPEG-2 TS TS Multiplex: In this document, this term defines a set of MPEG-2 TS
Logical Channels sent over a single lower layer connection. This may Logical Channels sent over a single lower layer connection. This may
be a common physical link (i.e. a transmission at a specified symbol be a common physical link (i.e. a transmission at a specified symbol
rate, FEC setting, and transmission frequency) or an encapsulation rate, FEC setting, and transmission frequency) or an encapsulation
provided by another protocol layer (e.g. Ethernet, or RTP over IP). provided by another protocol layer (e.g. Ethernet, or RTP over IP).
The same TS Logical Channel may be repeated over more than one TS The same TS Logical Channel may be repeated over more than one TS
Multiplex (possibly associated with a different PID value) [ID- Multiplex (possibly associated with a different PID value)
ipdvb-arch], for example to redistribute the same multicast content [RFCXARCHX], for example to redistribute the same multicast content
to two terrestrial TV transmission cells. to two terrestrial TV transmission cells.
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex
[ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional
overhead including an Adaptation Field, encryption details and time overhead including an Adaptation Field, encryption details and time
stamp information to synchronise a set of related TS Logical stamp information to synchronise a set of related TS Logical
Channels. Channels.
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
encapsulated PDUs. ULE Streams may be identified by definition of encapsulated PDUs. ULE Streams may be identified by definition of a
a stream_type in SI/PSI [ISO_MPEG2]. stream_type in SI/PSI [ISO-MPEG2].
Expires July 2005 [page 7] Expires July 2005 [page 7]
3. Description of the Method 3. Description of the Method
PDUs (IP packets, Ethernet frames or packets from other network PDUs (IP packets, Ethernet frames or packets from other network
protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). protocols) are encapsulated to form a Subnetwork Data Unit (SNDU).
The SNDU is transmitted over an MPEG-2 transmission network by The SNDU is transmitted over an MPEG-2 transmission network by
placing it either in the payload of a single TS Packet, or if placing it either in the payload of a single TS Packet, or if
required, an SNDU may be fragmented into a series of TS Packets. required, an SNDU may be fragmented into a series of TS Packets.
Where there is sufficient space, the method permits a single TS Where there is sufficient space, the method permits a single TS
Packet to carry more than one SNDU (or part there of), sometimes Packet to carry more than one SNDU (or part there of), sometimes
known as Packing. All TS Packets comprising an SNDU MUST be assigned known as Packing. All TS Packets comprising an SNDU MUST be assigned
the same PID, and therefore form a part of the same TS Logical the same PID, and therefore form a part of the same TS Logical
Channel. Channel.
The ULE encapsulation is limited to TS private streams only. The The ULE encapsulation is limited to TS private streams only. The
header of each TS Packet carries a one bit Payload Unit Start header of each TS Packet carries a one bit Payload Unit Start
Indicator (PUSI) field. A PUSI field with a value of 1 indicates the Indicator (PUSI) field. A PUSI field with a value of 1 indicates the
presence of at least one Payload Unit (SNDU) within the TS Packet start of at least one Payload Unit (SNDU) within the TS Packet
payload. The semantics of the PUSI bit are defined for PES and PSI payload. The semantics of the PUSI bit are defined for PES and PSI
packets [ISO-MPEG2]; for private data, its use is not defined in the packets [ISO-MPEG2]; for private data, its use is not defined in the
MPEG-2 Standard. In ULE, although being private data, the operation MPEG-2 Standard. In ULE, although being private data, the operation
follows that of PSI packets. Hence, the following PUSI values are follows that of PSI packets. Hence, the following PUSI values are
defined: defined:
0: The TS Packet does NOT contain the start of an SNDU, but 0: The TS Packet does NOT contain the start of an SNDU, but
contains the continuation, or end of an SNDU; contains the continuation, or end of an SNDU;
1: The TS Packet contains the start of an SNDU, and a one byte 1: The TS Packet contains the start of an SNDU, and a one byte
skipping to change at line 403 skipping to change at line 419
Expires July 2005 [page 8] Expires July 2005 [page 8]
4. SNDU Format 4. SNDU Format
PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an
MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs
is illustrated below: is illustrated below:
< ----------------------------- SNDU ----------------------------- > < ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
|D| Length | Type | PDU | CRC-32 | |D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation Figure 1: SNDU Encapsulation (* optional Destination Address)
All multi-byte values in ULE (including Length, Type, and All multi-byte values in ULE (including the Length/End Indicator
Destination fields) are transmitted in network byte order (most (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension
significant byte first). The most significant bit of each byte is Headers (5)) are transmitted in network byte order (most significant
placed in the left-most position of the 8-bit field. Appendix A byte first). The most significant bit of each byte is placed in the
provides informative examples of usage. left-most position of the 8-bit field. Appendix A provides
informative examples of usage.
4.1 Destination Address Absent (D) Field 4.1 Destination Address Absent (D) Field
The most significant bit of the Length Field carries the value of The most significant bit of the Length Field carries the value of
the Destination Address Absent Field, the D-bit. A value of 0 the Destination Address Absent Field, the D-bit. A value of 0
indicates the presence of the Destination Address Field (see section indicates the presence of the Destination Address Field (see section
4.5). A value of 1 indicates that a Destination Address Field is not 4.5). A value of 1 indicates that a Destination Address Field is not
present. present.
By default, the D-bit value SHOULD be set to a value of 0 (see 4.5), An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other
except for the transmission of an End Indicator (see 4.3), for which SNDUs SHOULD be sent with a D-bit value of 0 (see 4.5).
this bit MUST be set to the value of 1.
4.2 Length Field 4.2 Length Field
A 15-bit value that indicates the length, in bytes, of the SNDU 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 counted from the byte following the Type field, up to and including
the CRC. Note the special case described in 4.3. the CRC. Note the special case described in 4.3.
4.3 End Indicator 4.3 End Indicator
When the first two bytes of an SNDU have the value 0xFFFF, this When the first two bytes following an SNDU have the value 0xFFFF,
denotes an End Indicator (i.e., all 1s length combined with a D-bit this denotes an End Indicator (i.e., all ones length combined with a
value of 1). This indicates to the Receiver that there are no D-bit value of 1). This indicates to the Receiver that there are no
further SNDUs present within the current TS Packet (see section 6), further SNDUs present within the current TS Packet (see section 6),
and that no Destination Address Field is present. The value 0xFF has and that no Destination Address Field is present. The value 0xFF has
specific semantics in MPEG-2 framing, where it is used to indicate specific semantics in MPEG-2 framing, where it is used to indicate
the presence of Padding. This use resembles [ISO-DSMCC]. the presence of Padding. This use resembles [ISO-DSMCC].
Expires July 2005 [page 9] Expires July 2005 [page 9]
4.4 Type Field 4.4 Type Field
The 16-bit Type field indicates the type of payload carried in an 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 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 be assigned to this field is divided into two parts, similar to the
allocations for Ethernet. allocations for Ethernet.
EtherTypes were originally specified by Xerox under the Ethernet v2 EtherTypes were originally specified by Xerox under the Ethernet v2
Specification [DIX]. After specification of IEEE 802.3 [IEEE 802.3; Specification [DIX]. After specification of IEEE 802.3 [IEEE-802.3;
ISO-8802-2], the set of EtherTypes less than 1536 (0x0600), assumed ISO-8802-2], the set of EtherTypes less than 1536 (0x0600), assumed
the role of a length indicator. Ethernet receivers use this feature the role of a length indicator. Ethernet receivers use this feature
to discriminate LLC format frames. Hence any IEEE EtherType < 1536 to discriminate LLC format frames. Hence any IEEE EtherType < 1536
indicates an LLC frame, and the actual value indicates the length of indicates an LLC frame, and the actual value indicates the length of
the LLC frame. the LLC frame.
There is a potential ambiguous case when a Receiver receives a PDU There is a potential ambiguous case when a Receiver receives a PDU
with two length fields: The Receiver would need to validate the with two length fields: The Receiver would need to validate the
actual length and the Length field and ensure that inconsistent actual length and the Length field and ensure that inconsistent
values are not propagated by the network. Specification of two values are not propagated by the network. Specification of two
skipping to change at line 556 skipping to change at line 573
Expires July 2005 [page 11] Expires July 2005 [page 11]
addresses is specified in [RFC1112]. The method for mapping IPv6 addresses is specified in [RFC1112]. The method for mapping IPv6
multicast addresses is specified in [RFC2464]. multicast addresses is specified in [RFC2464].
4.6 SNDU Trailer CRC 4.6 SNDU Trailer CRC
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of 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- the SNDU. This position eases CRC computation by hardware. The CRC-
32 polynomial is to be used. Examples where this polynomial is also 32 polynomial is to be used. Examples where this polynomial is also
employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and
AAL5 [ITU3563]. This is a 32 bit value calculated according to the AAL5 [ITU-3563]. This is a 32 bit value calculated according to the
generator polynomial represented 0x104C11DB7 in hexadecimal: 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. 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 The Encapsulator initialises the CRC-32 accumulator register to the
value 0xFFFF FFFF. It then accumulates a transmit value for 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 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- 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 32), and places this in the CRC Field. In ULE, the bytes are
processed in order of increasing position within the SNDU, the order processed in order of increasing position within the SNDU, the order
skipping to change at line 619 skipping to change at line 637
IEEE and IANA registries. IEEE and IANA registries.
4.7.1 End Indicator 4.7.1 End Indicator
The format of the End Indicator is shown in figure 2. This format The format of the End Indicator is shown in figure 2. This format
MUST carry a D-bit value of 1. MUST carry a D-bit value of 1.
0 1 2 3 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 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 | |1| 0x7FFF | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= A sequence of zero or more bytes with a value 0xFF filling = = A sequence of zero or more bytes with a value 0xFF filling =
| the remainder of the TS Packet Payload | | the remainder of the TS Packet Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for a ULE End Indicator. Figure 2: Format for a ULE End Indicator.
Expires July 2005 [page 13] Expires July 2005 [page 13]
4.7.2 IPv4 SNDU 4.7.2 IPv4 SNDU
IPv4 datagrams are directly transported using one of the two IPv4 datagrams are directly transported using one of the two
standard SNDU structures, in which the PDU is placed directly in the standard SNDU structures, in which the PDU is placed directly in the
SNDU payload. The two encapsulations are shown in figures 3 and 4. SNDU payload. The two encapsulations are shown in figures 3 and 4.
(Note that in this, and the following figures, the IP datagram (Note that in this, and the following figures, the IP datagram
payload is of variable size, and is directly followed by the CRC- payload is of variable size, and is directly followed by the CRC-
32). 32).
0 1 2 3 0 1 2 3
skipping to change at line 750 skipping to change at line 770
2 Indicates an Optional Extension Header of length 4B 2 Indicates an Optional Extension Header of length 4B
3 Indicates an Optional Extension Header of length 6B 3 Indicates an Optional Extension Header of length 6B
4 Indicates an Optional Extension Header of length 8B 4 Indicates an Optional Extension Header of length 8B
5 Indicates an Optional Extension Header of length 10B 5 Indicates an Optional Extension Header of length 10B
>=6 the combined H-LEN and H-TYPE values indicate the EtherType >=6 the combined H-LEN and H-TYPE values indicate the EtherType
of a PDU that directly follows this Type field. of a PDU that directly follows this Type field.
The H-LEN value indicates the total number of bytes in an Optional The H-LEN value indicates the total number of bytes in an Optional
Extension Header (including the 2B Type field). Extension Header (including the 2B Type field).
A H-LEN of zero indicates a Mandatory Extension Header. Each An H-LEN value of zero indicates a Mandatory Extension Header. Each
Mandatory Extension Header has a pre-defined length that is not Mandatory Extension Header has a pre-defined length that is not
communicated in the H-LEN field. No additional limit is placed on communicated in the H-LEN field. No additional limit is placed on
the maximum length of a Mandatory Extension Header. A Mandatory the maximum length of a Mandatory Extension Header. A Mandatory
Extension Header MAY modify the format or encoding of the enclosed Extension Header MAY modify the format or encoding of the enclosed
PDU (e.g. to perform encryption and/or compression). PDU (e.g. to perform encryption and/or compression).
The H-Type is a one byte field that is either one of 256 Mandatory The H-Type is a one byte field that is either one of 256 Mandatory
Header Extensions or one of 256 Optional Header Extensions. The set Header Extensions or one of 256 Optional Header Extensions. The set
of currently permitted values for both types of Extension Headers of currently permitted values for both types of Extension Headers
are defined by an IANA Registry (section 15). Registry values for are defined by an IANA Registry (section 15). Registry values for
Optional Extensions are specified in the form H=1 (i.e. a decimal Optional Extensions are specified in the form H=1 (i.e. a decimal
Expires July 2005 [page 16] Expires July 2005 [page 16]
number in the range 256-511), but may be used with an H-Length value number in the range 256-511), but may be used with an H-Length value
in the range 1-5 (see example in 5.3). in the range 1-5 (see example in 5.3).
Two examples of Extension Headers are the Test_SNDU and the use of Two examples of Extension Headers are the Test SNDU and the use of
Extension-Padding. The Test-SNDU Mandatory Extension Header results Extension-Padding. The Test SNDU Mandatory Extension Header results
in the entire PDU being discarded. The Extension-Padding Optional in the entire PDU being discarded. The Extension-Padding Optional
Extension Header results in the following (if any) option header Extension Header results in the following (if any) option header
being ignored (i.e. a total of H-LEN 16-bit words). being ignored (i.e. a total of H-LEN 16-bit words).
The general format for an SNDU with Extension Headers is: The general format for an SNDU with Extension Headers is:
< -------------------------- SNDU ------------------------- > < -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+ +---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 | |D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+ +---+--------------------------------------------------+--------+
skipping to change at line 802 skipping to change at line 822
< -------------------------- SNDU ------------------------- > < -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+ +---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 | |D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+ +---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 > < ULE base header >< ext 1 >< ext 2 >
Figure 9: SNDU Encapsulation with two Extension Headers (D=1). Figure 9: SNDU Encapsulation with two Extension Headers (D=1).
Using this method, several Extension Headers MAY be chained in Using this method, several Extension Headers MAY be chained in
series. Figure 12 shows an SNDU including two Extension Headers. The series. Figure 12 shows an SNDU including two Extension Headers. In
values of T1 and T2 are both less than 1536 Decimal, each indicates the example, the values of T1 and T2 are both less than 1536
the presence of an Extension Header, rather than a directly Decimal. Each indicates the presence of an Extension Header, rather
following PDU. T3 has a value > 1535 indicating the EtherType of the than a directly following PDU. T3 has a value > 1535 indicating the
PDU being carried. Although an SNDU may contain an arbitrary number EtherType of the PDU being carried. Although an SNDU may contain an
of consecutive Extension Headers, it is not expected that SNDUs will arbitrary number of consecutive Extension Headers, it is not
generally carry a large number of extensions. expected that SNDUs will generally carry a large number of
extensions.
Expires July 2005 [page 17] Expires July 2005 [page 17]
5.1 Test SNDU 5.1 Test SNDU
A Test SNDU (figure 10) is of a Mandatory Extension Header of Type A Test SNDU (figure 10) is a Mandatory Extension Header of Type 1.
1. This header must be the final (or only) extension header This header must be the final (or only) extension header specified
specified in the header chain of a SNDU. The structure of the Data in the header chain of a SNDU. The structure of the Data portion of
portion of this SNDU is not defined by this document. All Receivers this SNDU is not defined by this document. All Receivers MAY record
MAY record reception in a log file, but MUST then discard any Test reception in a log file, but MUST then discard any Test SNDUs. The
SNDUs. The D-bit MAY be set in a TEST SNDU. D-bit MAY be set in a TEST SNDU.
0 1 2 3 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 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 = 0x0000 | |D| Length (15b) | Type = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= Data (not forwarded by a Receiver) = = Data (not forwarded by a Receiver) =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SNDU Format for a Test SNDU Figure 10: SNDU Format for a Test SNDU
5.2 Bridge Frame SNDU Encapsulation 5.2 Bridged Frame SNDU Encapsulation
A bridged SNDU is a Mandatory Extension Header of Type 1. It must be A bridged SNDU is a Mandatory Extension Header of Type 1. It MUST be
the final (or only) extension header specified in the header chain the final (or only) extension header specified in the header chain
of a SNDU. The payload includes MAC address and EtherType [DIX] or of a SNDU. The payload includes MAC address and EtherType [DIX] or
LLC Length [ISO-8802-2] fields together with the contents of a LLC Length [ISO-8802-2] fields together with the contents of a
bridged MAC frame. The SNDU has the format shown in figures 11 and bridged MAC frame. The SNDU has the format shown in figures 11 and
12. 12.
When an NPA address is specified (D=0), Receivers MUST discard all When an NPA address is specified (D=0), Receivers MUST discard all
SNDUs that carry an NPA destination address that does NOT match SNDUs that carry an NPA destination address that does NOT match
their own NPA address (or a broadcast/multicast address), the their own NPA address (or a broadcast/multicast address), the
payload of the remaining SNDUs are processed by the bridging rules payload of the remaining SNDUs are processed by the bridging rules
that follow. An SNDU without an NPA address (D=1) results in a that follow. An SNDU without an NPA address (D=1) results in a
Receiver performing bridging processing on the payload of all Receiver performing bridging processing on the payload of all
received SNDUs. received SNDUs.
A Gateway MAY also use this encapsulation format to directly A Gateway MAY also use this encapsulation format to directly
communicate network protocol packets that require the LLC communicate network protocol packets that require the LLC
encapsulation [ISO-8802-2]. To do this, it constructs an SNDU with a encapsulation [IEEE-802.2; ISO-8802-2]. To do this, it constructs an
Bridge Extension Header containing the intended destination MAC SNDU with a Bridge Extension Header containing the intended
address, the MAC source address of the Gateway, and the LLC-Length. destination MAC address, the MAC source address of the Gateway, and
The PDU comprises an LLC header followed by the required payload. the LLC-Length. The PDU comprises an LLC header followed by the
The Gateway MAY choose to suppress the NPA address (see 4.5). required payload. The Gateway MAY choose to suppress the NPA address
(see 4.5).
Expires July 2005 [page 18] Expires July 2005 [page 18]
0 1 2 3 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 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 = 0x0001 | |0| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
skipping to change at line 907 skipping to change at line 930
| | | |
= (Contents of bridged MAC frame) = = (Contents of bridged MAC frame) =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SNDU Format for a Bridged Payload (D=1) Figure 12: SNDU Format for a Bridged Payload (D=1)
The EtherType/LLC-Length field of a frame is defined according to The EtherType/LLC-Length field of a frame is defined according to
IEEE 802.3 [IEEE-802.3; ISO-8802-2] (see section 5). IEEE 802.3 [IEEE-802.2] (see section 5).
In this special case, the extension mandatory header format permits In this special case, the Mandatory Extension Header format may be
this field may be interpreted as either an EtherType [DIX] or an LLC interpreted as either an EtherType [DIX] or an LLC Length field,
Expires July 2005 [page 19] Expires July 2005 [page 19]
Length field, specified by IEEE 802 [IEEE-802.3] rather a value specified by IEEE 802 [IEEE-802.3] rather a value assigned in the
assigned in the ULE Next Header Registry maintained by the IANA. ULE Next-Header Registry maintained by the IANA.
The MAC addresses in the frame being bridged SHOULD be assigned The MAC addresses in the frame being bridged SHOULD be assigned
according to the rules specified by the IEEE and may denote unknown, according to the rules specified by the IEEE and denote unknown,
unicast, broadcast, and multicast link addresses. These MAC unicast, broadcast, and multicast link addresses. These MAC
addresses denote the intended recipient in the destination LAN, and addresses denote the intended recipient in the destination LAN, and
therefore have a different function to the NPA addresses carried in therefore have a different function to the NPA addresses carried in
the SNDU header. the SNDU header.
A frame Type < 1536 for a bridged frame, introduces a LLC Length A frame Type < 1536 for a bridged frame, introduces a LLC Length
field. The Receiver MUST check this length and discard any frame field. The Receiver MUST check this length and discard any frame
with a length greater than permitted by the SNDU payload size. with a length greater than permitted by the SNDU payload size.
In normal operation, it is expected that any padding appended to the In normal operation, it is expected that any padding appended to the
Ethernet frame SHOULD be removed prior to forwarding. This requires Ethernet frame SHOULD be removed prior to forwarding. This requires
the sender to be aware of such Ethernet padding (e.g. [DIX; IEEE- the sender to be aware of such Ethernet padding
802.3]). (e.g. [DIX; IEEE-802.3]).
Ethernet frames received at the Encapsulator for onward transmission Ethernet frames received at the Encapsulator for onward transmission
over ULE carry a Local Area Network Frame Check sequence, LAN FCS, over ULE carry a Local Area Network Frame Check sequence, LAN FCS,
field (e.g. CRC-32 for Ethernet [DIX; IEEE-802.3]). The Encapsulator field (e.g. CRC-32 for Ethernet [DIX; IEEE-802.3]). The Encapsulator
MUST check the LAN-FCS value of all frames received, prior to MUST check the LAN-FCS value of all frames received, prior to
further processing. Frames received with an invalid LAN FCS MUST be further processing. Frames received with an invalid LAN FCS MUST be
discarded. After checking, the LAN FCS is then removed (i.e., it is discarded. After checking, the LAN FCS is then removed (i.e., it is
NOT forwarded in the bridged SNDU). As in other ULE frames, the NOT forwarded in the bridged SNDU). As in other ULE frames, the
Encapsulator appends a CRC-32 to the transmitted SNDU. At the Encapsulator appends a CRC-32 to the transmitted SNDU. At the
Receiver, an appropriate LAN-FCS field will be appended to the Receiver, an appropriate LAN-FCS field will be appended to the
skipping to change at line 958 skipping to change at line 981
processing performed at an Encapsulator and/or Receiver may not be processing performed at an Encapsulator and/or Receiver may not be
detected by the final recipient(s) (i.e. such corruption would not detected by the final recipient(s) (i.e. such corruption would not
normally result in an invalid LAN FCS). normally result in an invalid LAN FCS).
5.3 Extension-Padding Optional Extension Header 5.3 Extension-Padding Optional Extension Header
The Extension-Padding Optional Extension Header is specified by an The Extension-Padding Optional Extension Header is specified by an
IANA assigned H-Type value of 0x100. As in other Optional IANA assigned H-Type value of 0x100. As in other Optional
Extensions, the total length of the extension is indicated by the H- Extensions, the total length of the extension is indicated by the H-
LEN field (specified in 16-bit words). The extension field is formed LEN field (specified in 16-bit words). The extension field is formed
of a group of 1 to 5 16-bit fields. of a group of one to five 16-bit fields.
For this specific option, only the last 16-bit word has an assigned For this specific option, only the last 16-bit word has an assigned
value, the sender SHOULD set the remaining values to 0x0000. The value, the sender SHOULD set the remaining values to 0x0000. The
last 16-bit field forms the Next-Header Type field. A Receiver MUST last 16-bit field forms the Next-Header Type field. A Receiver MUST
interpret the Type field, but MUST ignore any other fields of this interpret the Type field, but MUST ignore any other fields of this
Extension Header. Extension Header.
Expires July 2005 [page 20] Expires July 2005 [page 20]
6. Processing at the Encapsulator 6. Processing at the Encapsulator
The Encapsulator forms the PDUs queued for transmission into SNDUs The Encapsulator forms the PDUs queued for transmission into SNDUs
by adding a header and trailer to each PDU (section 4). It then 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). segments the SNDU into a series of TS Packet payloads (figure 9).
These are transmitted using a single TS Logical Channel over a TS 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 Multiplex. The TS Multiplex may be processed by a number of MPEG-2
(re)multiplexors before it is finally delivered to a Receiver [ID- (re)multiplexors before it is finally delivered to a Receiver
ipdvb-arch]. [RFCXARCHX].
+------+--------------------------------+------+ +------+--------------------------------+------+
| ULE | Protocol Data Unit | ULE | | ULE | Protocol Data Unit | ULE |
|Header| |CRC-32| |Header| |CRC-32|
+------+--------------------------------+------+ +------+--------------------------------+------+
/ / \ \ / / \ \
/ / \ \ / / \ \
/ / \ \ / / \ \
+--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+
|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 | |MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |
skipping to change at line 998 skipping to change at line 1021
+--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+
Figure 13: Encapsulation of an SNDU into a series of TS Packets Figure 13: Encapsulation of an SNDU into a series of TS Packets
6.1 SNDU Encapsulation 6.1 SNDU Encapsulation
When an Encapsulator has not previously sent a TS Packet for a When an Encapsulator has not previously sent a TS Packet for a
specific TS Logical Channel, or after an Idle period, it starts to specific TS Logical Channel, or after an Idle period, it starts to
send an SNDU in the first available TS Packet. This first TS Packet send an SNDU in the first available TS Packet. This first TS Packet
generated MUST carry a PUSI value of 1. It MUST also carry a Payload generated MUST carry a PUSI value of 1. It MUST also carry a Payload
Pointer value of zero indicating the SNDU starts in the first Pointer value of zero indicating that the SNDU starts immediately
available byte of the TS Packet payload. after the Payload Pointer in the TS Packet payload.
The Encapsulation MUST ensure that all TS Packets set the MPEG-2 The Encapsulation MUST ensure that all TS Packets set the MPEG-2
Continuity Counter carried in the TS Packet header, according to Continuity Counter carried in the TS Packet header, according to
[ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for [ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for
each successive fragment/complete SNDU sent using a TS Logical each successive fragment/complete SNDU sent using a TS Logical
Channel. Channel.
An Encapsulator MAY decide not to immediately send another SNDU, An Encapsulator MAY decide not to immediately send another SNDU,
even if space is available in a partially filled TS Packet. This even if space is available in a partially filled TS Packet. This
procedure is known as Padding (figure 11). The End Indicator informs procedure is known as Padding (figure 11). The End Indicator informs
the Receiver that there are no more SNDUs in this TS Packet payload. the Receiver that there are no more SNDUs in this TS Packet payload.
The End Indicator is followed by zero or more unused bytes until the 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 end of the TS Packet payload. All unused bytes MUST be set to the
value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The
Padding procedure trades decreased efficiency against improved Padding procedure trades decreased efficiency against improved
latency. latency.
Expires July 2005 [page 21] Expires July 2005 [page 21]
+-/------------+ +-/------------+
| SubNetwork | | SubNetwork |
| DU 3 | | DU 1 |
+-/------------+ +-/------------+
\ \ \ \
\ \ \ \
\ \ \ \
+--------+--------+--------+----------+ +--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused | |MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 3 | | Bytes | | Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+ +--------+--------+--------+----------+
PUSI=0 ULE PUSI=0 ULE
End End
Indicator Indicator
Figure 14: A TS Packet carrying the end of SNDU 3, followed by an Figure 14: A TS Packet carrying the end of SNDU 1, followed by an
End Indicator. End Indicator.
Alternatively, when more packets are waiting at an Encapsulator, and Alternatively, when more packets are waiting at an Encapsulator, and
a TS Packet has sufficient space remaining in the payload, the a TS Packet has sufficient space remaining in the payload, the
Encapsulator can follow a previously encapsulated SNDU with another Encapsulator can follow a previously encapsulated SNDU with another
SNDU using the next available byte of the TS Packet payload (see SNDU using the next available byte of the TS Packet payload (see
6.2). This is called Packing (figure 15). 6.2). This is called Packing (figure 15).
+-/----------------+ +----------------/-+ +-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork | | Subnetwork | | Subnetwork |
| DU 1 | | DU 2 | | DU 2 | | DU 3 |
+-/----------------+ +----------------/-+ +-/----------------+ +----------------/-+
\ \ / /\ \ \ / /\
\ \ / / \ \ \ / / \
\ \ / / \. . . \ \ / / \. . .
+--------+--------+--------+----------+ +--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of | |MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 1 | SNDU 2 | | Header | Pointer| SNDU 2 | SNDU 3 |
+--------+--------+--------+----------+ +--------+--------+--------+----------+
PUSI=1 | ^ PUSI=1 | ^
| | | |
+--------------+ +--------------+
Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2. Figure 15: A TS Packet with the end of SNDU 2, followed by SNDU 3.
6.2 Procedure for Padding and Packing 6.2 Procedure for Padding and Packing
Five possible actions may occur when an Encapsulator has completed Five possible actions may occur when an Encapsulator has completed
encapsulation of an SNDU: encapsulation of an SNDU:
(i) If the TS Packet has no remaining space, the Encapsulator (i) If the TS Packet has no remaining space, the Encapsulator
transmits this TS Packet. It starts transmission of the next SNDU in transmits this TS Packet. It starts transmission of the next SNDU in
a new TS Packet. (The standard rules [ISO-MPEG2] require the header a new TS Packet. (The standard rules [ISO-MPEG2] require the header
of this new TS Packet to carry a PUSI value of 1, and a Payload of this new TS Packet to carry a PUSI value of 1, and a Payload
skipping to change at line 1098 skipping to change at line 1121
Packet. This rule prevents fragmentation of the SNDU Length Field Packet. This rule prevents fragmentation of the SNDU Length Field
over two TS Packets. The Encapsulator MUST start transmission of the over two TS Packets. The Encapsulator MUST start transmission of the
next SNDU in a new TS Packet. (The standard rules require the header next SNDU in a new TS Packet. (The standard rules require the header
of this new TS Packet to carry a PUSI value of 1 and a Payload of this new TS Packet to carry a PUSI value of 1 and a Payload
Pointer value of 0x00.) Pointer value of 0x00.)
(iv) If the TS Packet has more than two bytes of unused payload, the (iv) If the TS Packet has more than two bytes of unused payload, the
Encapsulator MAY transmit this partially full TS Packet but MUST Encapsulator MAY transmit this partially full TS Packet but MUST
first place the value 0xFF in all remaining unused bytes (i.e. first place the value 0xFF in all remaining unused bytes (i.e.
setting an End Indicator followed by Padding). The Encapsulator MUST setting an End Indicator followed by Padding). The Encapsulator MUST
start transmission of the next SNDU in a new TS Packet. (The then start transmission of the next SNDU in a new TS Packet. (The
standard rules [ISO-MPEG2] require the header of this new TS Packet standard rules [ISO-MPEG2] require the header of this new TS Packet
to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) to carry a PUSI value of 1 and a Payload Pointer value of 0x00.)
(v) If at least two bytes are available for SNDU data in the TS (v) If at least two bytes are available for SNDU data in the TS
Packet payload (i.e. three bytes if the PUSI was NOT previously set, Packet payload (i.e. three bytes if the PUSI was NOT previously set,
and two bytes if it was previously set), the Encapsulator MAY and two bytes if it was previously set), the Encapsulator MAY
encapsulate further queued PDUs, by starting the next SNDU in the encapsulate further queued PDUs, by starting the next SNDU in the
next available byte of the current TS Packet payload. The PUSI MUST next available byte of the current TS Packet payload. When the
be set. When the Encapsulator packs further SNDUs into a TS Packet Encapsulator packs further SNDUs into a TS Packet where the PUSI has
where the PUSI has NOT already been set, this requires the PUSI to NOT already been set, the PUSI MUST be updated (set to 1) and an 8-
be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted bit Payload Pointer MUST be inserted in the first byte directly
in the first byte directly following the TS Packet header. The value following the TS Packet header. The value of the Payload Pointer
MUST be set to the position of the byte following the end of the MUST be set to the position of the byte following the end of the
first SNDU in the TS Packet payload. If no further PDUs are first SNDU in the TS Packet payload. If no further PDUs are
available, an Encapsulator MAY wait for additional PDUs to fill the available, an Encapsulator MAY wait for additional PDUs to fill the
incomplete TS Packet. The maximum period of time an Encapsulator can incomplete TS Packet. The maximum period of time an Encapsulator can
wait, known as the Packing Threshold, MUST be bounded and SHOULD be wait, known as the Packing Threshold, MUST be bounded and SHOULD be
configurable in the Encapsulator. If sufficient additional PDUs are configurable in the Encapsulator. If sufficient additional PDUs are
NOT received to complete the TS Packet within the Packing Threshold, NOT received to complete the TS Packet within the Packing Threshold,
the Encapsulator MUST insert an End Indicator (using rule iv). the Encapsulator MUST insert an End Indicator (using rule iv).
Use of the Packing method (v) by an Encapsulator is optional, and Use of the Packing method (v) by an Encapsulator is optional, and
skipping to change at line 1161 skipping to change at line 1184
be recorded as a payload pointer error. be recorded as a payload pointer error.
A Receiver MUST support the use of both the Packing and Padding A Receiver MUST support the use of both the Packing and Padding
method for any received SNDU, and MUST support reception of SNDUs 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). with or without a Destination Address Field (i.e. D=0 and D=1).
7.1 Idle State 7.1 Idle State
After initialisation, errors, or on receipt of an End Indicator, the After initialisation, errors, or on receipt of an End Indicator, the
Receiver enters the Idle State. In this state, the Receiver discards Receiver enters the Idle State. In this state, the Receiver discards
all TS Packets until it discovers the start of a new SNDU, when it all TS Packets until it discovers the start of a new SNDU, upon
then enters the Reassembly State. Figure 16 outlines these state which it then enters the Reassembly State. Figure 16 outlines these
transitions: state transitions:
+-------+ +-------+
| START | | START |
+---+---+ +---+---+
| |
\/ \/
+----------+ +----------+
\| Idle |/ \| Idle |/
+-------/| State |\-------+ +-------/| State |\-------+
Insufficient | +----+-----+ | Insufficient | +----+-----+ |
skipping to change at line 1308 skipping to change at line 1332
Packets to the reassembly procedure. In most cases, the SNDU CRC-32 Packets to the reassembly procedure. In most cases, the SNDU CRC-32
integrity check will result in discard of these SNDUs, leading to integrity check will result in discard of these SNDUs, leading to
unexpected PDU loss, however in some cases, duplicate PDUs (fitting unexpected PDU loss, however in some cases, duplicate PDUs (fitting
into one TS Packet) could pass undetected to the next layer into one TS Packet) could pass undetected to the next layer
protocol. protocol.
Expires July 2005 [page 28] Expires July 2005 [page 28]
8. Summary 8. Summary
This document defines an Ultra Lightweight Encapsulation (ULE) to This document defines a Unidirectional Lightweight Encapsulation
perform efficient and flexible support for IPv4 and IPv6 network (ULE) that performs efficient and flexible support for IPv4 and IPv6
services over networks built upon the MPEG-2 Transport Stream (TS). network services over networks built upon the MPEG-2 Transport
The encapsulation is also suited to transport of other protocol Stream (TS). The encapsulation is also suited to transport of other
packets and bridged Ethernet frames. protocol packets and bridged Ethernet frames.
ULE also provides an Extension Header format and defines an ULE also provides an Extension Header format and defines an
associated IANA registry for efficient and flexible support of both associated IANA registry for efficient and flexible support of both
mandatory and optional SNDU headers. This allows for future mandatory and optional SNDU headers. This allows for future
extension of the protocol, while providing backwards compatibility extension of the protocol, while providing backwards compatibility
with existing implementations. In particular, Optional Extension with existing implementations. In particular, Optional Extension
Headers may safely be ignored by Receiver drivers that do not Headers may safely be ignored by Receiver drivers that do not
implement them, or choose not to process them. implement them, or choose not to process them.
9. Acknowledgments 9. Acknowledgments
This draft is based on a previous draft authored by: Horst D. This draft is based on a previous draft authored by: Horst D.
Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry
Fairhurst. The authors wish to thank the members of the ip-dvb Fairhurst. The authors wish to thank the members of the ip-dvb
mailing list for their input provided. In particular, the many mailing list for their input provided. In particular, the many
comments received from Art Allison, Carstsen Borman, Patrick comments received from Art Allison, Carstsen Borman, Patrick
Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and William
William Stanislaus. Alain also provided the original examples of Stanislaus. Alain also provided the original examples of usage.
usage.
Expires July 2005 [page 29] Expires July 2005 [page 29]
10. Security Considerations 10. Security Considerations
The security considerations for ULE resemble those that arise when The security considerations for ULE resemble those that arise when
the existing Multi-Protocol Encapsulation (MPE) is used. ULE does the existing Multi-Protocol Encapsulation (MPE) is used. ULE does
not add specific new threats that will impact the security of the not add specific new threats that will impact the security of the
general Internet. general Internet.
skipping to change at line 1362 skipping to change at line 1385
actual length and the Length Field and ensure that inconsistent actual length and the Length Field and ensure that inconsistent
values are not propagated by the network. In direct encapsulation of values are not propagated by the network. In direct encapsulation of
IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length
Field. However, this issue still arises in bridged LLC frames, and Field. However, this issue still arises in bridged LLC frames, and
frames with a LLC Length greater than the SNDU payload size MUST be frames with a LLC Length greater than the SNDU payload size MUST be
discarded, and an SNDU payload length error SHOULD be recorded. discarded, and an SNDU payload length error SHOULD be recorded.
A ULE Mandatory Extension Header may in future be used to define a A ULE Mandatory Extension Header may in future be used to define a
method to perform link encryption of the SNDU payload. This is as an method to perform link encryption of the SNDU payload. This is as an
additional security mechanism to IP, transport or application layer additional security mechanism to IP, transport or application layer
security - not a replacement [ID-ipdvb-arch]. The approach is security - not a replacement [RFCXARCHX]. The approach is generic
generic and decouples the encapsulation from future security and decouples the encapsulation from future security extensions. The
extensions. The operation provides functions that resemble those operation provides functions that resemble those currently used with
currently used with the MPE encapsulation. the MPE encapsulation.
Additional security control fields may be provided as a part of this Additional security control fields may be provided as a part of this
link encryption Extension Header, e.g. to associate an SNDU with one link encryption Extension Header, e.g. to associate an SNDU with one
of a set of Security Association (SA) parameters. As a part of the of a set of Security Association (SA) parameters. As a part of the
encryption process, it may also be desirable to authenticate encryption process, it may also be desirable to authenticate
some/all of the SNDU headers. The method of encryption and the way some/all of the SNDU headers. The method of encryption and the way
in which keys are exchanged is beyond the scope of this in which keys are exchanged is beyond the scope of this
specification, as also are the definition of the SA format and that specification, as also are the definition of the SA format and that
of the related encryption keys. of the related encryption keys.
skipping to change at line 1389 skipping to change at line 1412
11.1 Normative References 11.1 Normative References
[ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic
coding of moving pictures and associated audio information -- Part coding of moving pictures and associated audio information -- Part
1: Systems", International Standards Organisation (ISO), 2000. 1: Systems", International Standards Organisation (ISO), 2000.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
11.2 Informative References 11.2 Informative References
[ID-ipdvb-arch] "Requirements for transmission of IP datagrams over [ID-ipdvb-ar] Fairhurst, G., M-J. Montpetit, "Address Resolution for
MPEG-2 networks", Internet Draft, Work in Progress. IP datagrams over MPEG-2 Networks", Internet Draft, Work in
Progress.
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53 Rev.C, 2004 Systems Committee (ATSC), Doc. A/53 Rev.C, 2004
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 2000. Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC), Doc. A/91, 2001. Committee (ATSC), Doc. A/91, 2001.
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
1995. 1995.
[ATSC-PSIP-TC] A/65B Program and System Information Protocol for [ATSC-PSIP-TC] A/65B Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems Terrestrial Broadcast and Cable", Advanced Television Systems
Committee The(ATSC), Doc. A/65B, 18 March 2003. Committee (ATSC), Doc. A/65B, 2003.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems (DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 1999. Committee (ATSC), Doc. A/80, 1999.
Expires July 2005 [page 31]
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet
Local Area Network Specification" Version 2.0, November 1982. Local Area Network Specification" Version 2.0, November 1982.
[ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI), 2004.
Expires July 2005 [page 31]
[ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV)", interaction channel for Cable TV distribution systems (CATV)",
European Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI), 1998.
[ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation [ETSI-DVBS] EN 300 421 "Digital Video Broadcasting (DVB); Modulation
and Coding for DBS satellite systems at 11/12 GHz", European and Coding for DBS satellite systems at 11/12 GHz", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI), 1997.
[ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital terrestrial structure, channel coding and modulation for digital terrestrial
television (DVB-T)", European Telecommunications Standards Institute television (DVB-T)", European Telecommunications Standards Institute
(ETSI). (ETSI), 2004.
[ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); [ETSI-RCS] ETSI 301 790 "Digital Video Broadcasting (DVB);
Interaction Channel for Satellite Distribution Systems", European Interaction Channel for Satellite Distribution Systems", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI), 2005.
[IEEE-802.3] IEEE 802.3 "Local and metropolitan area networks: [IEEE-802.2] IEEE 802.2, "Local and metropolitan area networks-
Specific requirements Part 2: Logical Link Control", IEEE Computer
Society, (also ISO/IEC 8802-2), 1998.
[IEEE-802.3] IEEE 802.3 "Local and metropolitan area networks-
Specific requirements Part 3: Carrier sense multiple access with Specific requirements Part 3: Carrier sense multiple access with
collision detection (CSMA/CD) access method and physical layer collission detection (CSMA/CD) access method and physical layer
specifications", IEEE Computer Society, (also ISO/IEC 8802-3). specifications", IEEE Computer Society, (also ISO/IEC 8802-3), 2002.
[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic
coding of moving pictures and associated audio information -- Part coding of moving pictures and associated audio information -- Part
6: Extensions for DSM-CC", International Standards Organisation 6: Extensions for DSM-CC", International Standards Organisation
(ISO). (ISO), 1998.
[ITU-H222] H.222.0 "Information technology - Generic coding of
moving pictures and associated audio information: Systems",
International Telecommunication Union, (ITU-T), 1995.
[ITU-3563] I.363.5 "B-ISDN ATM Adaptation Layer specification: Type
5 AAL", International Telecommunication Union, (ITU-T), 1996.
[ISO-8802-2] ISO/IEC 8802.2 "Logical Link Control", International [ISO-8802-2] ISO/IEC 8802.2 "Logical Link Control", International
Standards Organisation (ISO), 1998. Standards Organisation (ISO), 1998.
[RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
Layer Tunneling Mechanism for Unidirectional Links", RFC3077, Layer Tunneling Mechanism for Unidirectional Links", RFC3077,
Proposed Standard, 2001. Proposed Standard, 2001.
[RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control
Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed
Standard, 2001. Standard, 2001.
XXX RFC Editor - please replace the next reference and all citations
with the appropriate RFC number. The I-D referenced is currently
ahead in the RFC-ED queue.
XXX
Expires July 2005 [page 32] Expires July 2005 [page 32]
[RFCXARCHX] M.J. Montpetit, H. D. Clausen, B. Collini-Nocker, H.
Linder "A Framework for transmission of IP datagrams over MPEG-2
Networks", RFCXARCHX, 2005.
[SOOR05] M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-Nocker,
H. Linder, W. Stering "A Lightweight Encapsulation Protocol for IP
over MPEG-2 Networks: Design, Implementation and Analysis", Computer
Networks 48 p5-19, 2005.
Expires July 2005 [page 33]
12. Authors' Addresses 12. Authors' Addresses
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
University of Aberdeen University of Aberdeen
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry Web: http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker Bernhard Collini-Nocker
Department of Scientific Computing Department of Scientific Computing
University of Salzburg University of Salzburg
Jakob Haringer Str. 2 Jakob Haringer Str. 2
5020 Salzburg 5020 Salzburg
Austria Austria
Email: bnocker@cosy.sbg.ac.at Email: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/ Web: http://www.scicomp.sbg.ac.at/
Expires July 2005 [page 33] Expires July 2005 [page 34]
13. IPR Notices 13. IPR Notices
13.1 Intellectual Property Statement 13.1 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
skipping to change at line 1533 skipping to change at line 1578
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Copyright Statement 14. Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2005).
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Expires July 2005 [page 34] This document is subject to the rights, licenses and restrictions
15. IANA Considerations contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document will require IANA involvement. Expires July 2005 [page 35]
The ULE Next-Header type field defined in this document requires 15. IANA Considerations
creation of a registry:
This document will require IANA involvement. The ULE Next-Header
type field defined in this document requires creation of a registry:
ULE Next-Header registry ULE Next-Header registry
This registry allocates values 0-511 (decimal). This registry allocates Next-Header values within the range 0-511
(decimal). For each allocated value, it also specifies the set of
allowed H-LEN values (see section 5). In combination, these define a
set of allowed values in the range 0-1535 for the first part of the
ULE Type space (see section 4.1).
15.1 IANA Guidelines 15.1 IANA Guidelines
The following contains the IANA guidelines for management of the ULE The following contains the IANA guidelines for management of the ULE
Next-Header registry. This registry allocates values 0-511 decimal Next-Header registry. This registry allocates values 0-511 decimal
(0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater
than 0x01FF (decimal). than 0x01FF (decimal).
It subdivides the Next-Header registry in the following way: It subdivides the Next-Header registry in the following way:
1) 0-255 (decimal) IANA assigned values indicating Mandatory 1) 0-255 (decimal) IANA assigned values, indicating Mandatory
Extension Headers (or link-dependent type fields) for ULE, Extension Headers (or link-dependent type fields) for ULE,
requiring expert review leading to prior issue of an IETF RFC. requiring expert review leading to prior issue of an IETF RFC.
This specification MUST define the value, and the name associated This specification MUST define the value, and the name associated
with the Extension Header, together with the procedure for with the Extension Header, together with the procedure for
processing the Extension Header. It MUST also define the need for processing the Extension Header. It MUST also define the need for
the extension and the intended use. The total size of the the Mandatory Extension and the intended use. The size of the
Extension Header MUST be specified. Extension Header MUST be specified.
Assignments made in this document: Assignments made in this document:
Type Name Reference Type Name Reference
0: Test-SNDU Section 4.7.4. 0: Test-SNDU Section 4.7.4.
1: Bridged-SNDU Section 4.7.5. 1: Bridged-SNDU Section 4.7.5.
2) 256-511 (decimal) IANA assigned values indicating Optional 2) 256-511 (decimal) IANA assigned values, indicating Optional
Extension Headers for ULE, requiring expert review leading to Extension Headers for ULE, requiring expert review leading to
prior issue of an IETF RFC. This specification MUST define the prior issue of an IETF RFC. This specification MUST define the
value, and the name associated with the Extension Header, together value, and the name associated with the Extension Header, together
with the procedure for processing the Extension Header. The entry with the procedure for processing the Extension Header. The entry
MUST specify range of allowable H-LEN values that are permitted MUST specify the range of allowable H-LEN values that are
(in the range 1-5). It MUST also define the need for the extension permitted (in the range 1-5). It MUST also define the need for the
and the intended use. Optional Extension and the intended use.
Assignments made in this document: Assignments made in this document:
Type Name H-LEN Reference Type Name H-LEN Reference
256: Extension-Padding 1-5 Section 5. 256: Extension-Padding 1-5 Section 5.
Expires July 2005 [page 35] Expires July 2005 [page 36]
ANNEX A: Informative Appendix - SNDU Packing Examples ANNEX A: Informative Appendix - SNDU Packing Examples
This appendix provides some examples of use. The appendix is This appendix provides some examples of use. The appendix is
informative. It does not provide a description of the protocol. The informative. It does not provide a description of the protocol. The
examples provide the complete TS Packet sequence for some sample examples provide the complete TS Packet sequence for some sample
encapsulated IP packets. encapsulated IP packets.
The specification of the TS Packet header operation and field values The specification of the TS Packet header operation and field values
is provided in [ISO-MPEG2]. The specification of ULE is provided in is provided in [ISO-MPEG2]. The specification of ULE is provided in
skipping to change at line 1639 skipping to change at line 1688
PUSI=1 * * PUSI=1 * *
************************* *************************
End Stuffing End Stuffing
CRC for A Indicator Bytes CRC for A Indicator Bytes
+-----+------+- -+------+----+----+- -+----+ +-----+------+- -+------+----+----+- -+----+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF| | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
+-----+------+- -+------+----+----+- -+----+ +-----+------+- -+------+----+----+- -+----+
PUSI=0 PUSI=0
Expires July 2005 [page 36] Expires July 2005 [page 37]
Example A.2: Usage of last byte in a TS-Packet Example A.2: Usage of last byte in a TS-Packet
SNDU A is 183 bytes SNDU A is 183 bytes
SNDU B is 182 bytes SNDU B is 182 bytes
SNDU C is 181 bytes SNDU C is 181 bytes
SNDU D is 185 bytes SNDU D is 185 bytes
The sequence comprises 4 TS Packets: The sequence comprises 4 TS Packets:
SNDU SNDU
skipping to change at line 1676 skipping to change at line 1725
| HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 |
+-----+---*--+-*----+------+- -+------+------+------+ +-----+---*--+-*----+------+- -+------+------+------+
PUSI=1 * * PUSI=1 * *
****** Unused ****** Unused
byte byte
+-----+------+- -+------+------+ +-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF | | HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+ +-----+------+- -+------+------+
PUSI=0 PUSI=0
Expires July 2005 [page 37] Expires July 2005 [page 38]
Example A.3: Large SNDUs Example A.3: Large SNDUs
SNDU A is 732 bytes SNDU A is 732 bytes
SNDU B is 284 bytes SNDU B is 284 bytes
The sequence comprises 6 TS Packets: The sequence comprises 6 TS Packets:
SNDU SNDU
PP=0 Length PP=0 Length
+-----+------+------+------+- -+------+ +-----+------+------+------+- -+------+
skipping to change at line 1722 skipping to change at line 1771
+-----+------+- -+------+ +-----+------+- -+------+
PUSI=0 PUSI=0
End Stuffing End Stuffing
Indicator Bytes Indicator Bytes
+-----+------+- -+------+------+------+- -+------+ +-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF | | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+ +-----+------+- -+------+------+------+- -+------+
PUSI=0 PUSI=0
Expires July 2005 [page 38] Expires July 2005 [page 39]
Example A.4: Packing of SNDUs Example A.4: Packing of SNDUs
SNDU A is 200 bytes SNDU A is 200 bytes
SNDU B is 60 bytes SNDU B is 60 bytes
SNDU C is 60 bytes SNDU C is 60 bytes
The sequence comprises two TS Packets: The sequence comprises two TS Packets:
SNDU SNDU
PP=0 Length PP=0 Length
skipping to change at line 1763 skipping to change at line 1812
+ ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF | + ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF |
+ -+------+-+----+------+ -+------+-+----+------+- -+------+ + -+------+-+----+------+ -+------+-+----+------+- -+------+
+ + + + + + + + + +
+ + ++++++++ + + + ++++++++ +
+ + + + + + + +
++++++++++++++++ ++++++++++++++++++++++ ++++++++++++++++ ++++++++++++++++++++++
*** TS Packet Payload Pointer (PP) *** TS Packet Payload Pointer (PP)
+++ ULE Length Indicator +++ ULE Length Indicator
Expires July 2005 [page 39] Expires July 2005 [page 40]
Example A.5: Three 44B PDUs. Example A.5: Three 44B PDUs.
SNDU A is 52 bytes (no ULE destination NPA address) SNDU A is 52 bytes (no ULE destination NPA address)
SNDU B is 52 bytes (no ULE destination NPA address) SNDU B is 52 bytes (no ULE destination NPA address)
SNDU C is 52 bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE destination NPA address)
The sequence comprises 1 TS Packet: The sequence comprises 1 TS Packet:
SNDU SNDU
PP=0 Length PP=0 Length
skipping to change at line 1786 skipping to change at line 1835
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
PUSI=1 * * PUSI=1 * *
***** *****
End Stuffing End Stuffing
Indicator bytes Indicator bytes
-----+------+- -+-----+---------+- -+------+ -----+------+- -+-----+---------+- -+------+
... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF |
-*---+------+- -+-----+---------+- -+------+ -*---+------+- -+-----+---------+- -+------+
Expires July 2005 [page 40] Expires July 2005 [page 41]
ANNEX B: Informative Appendix - SNDU Encapsulation ANNEX B: Informative Appendix - SNDU Encapsulation
An example of ULE encapsulation carrying an ICMPv6 packet generated An example of ULE encapsulation carrying an ICMPv6 packet generated
by ping6. by ping6.
ULE SNDU Length : 63 decimal ULE SNDU Length : 63 decimal
D-bit value : 0 (NPA destination address present) D-bit value : 0 (NPA destination address present)
ULE Protocol Type : 0x86dd (IPv6) ULE Protocol Type : 0x86dd (IPv6)
Destination ULE NPA Address: 00:01:02:03:04:05 Destination ULE NPA Address: 00:01:02:03:04:05
ULE CRC32 : 0x4709a744 ULE CRC32 : 0x7c171763
Source IPv6: 2001:660:3008:1789::5 Source IPv6 : 2001:DB8:3008:1965::1
Destination IPv6: 2001:660:3008:1789::6 Destination IPv6 : 2001:DB8:2509:1962::2
SNDU contents (including CRC-32): SNDU contents (including CRC-32):
0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d 0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d
0016: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0016: 3a 40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00
0032: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0032: 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00
0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47 0048: 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c
0064: 09 a7 44 0064: 17 17 63
Expires July 2005 [page 41] Expires July 2005 [page 42]
[RFC EDITOR NOTE: [RFC EDITOR NOTE:
This section must be deleted prior to publication] This section must be deleted prior to publication]
DOCUMENT HISTORY DOCUMENT HISTORY
Draft 00 Draft 00
This draft is intended as a study item for proposed future work by This draft is intended as a study item for proposed future work by
the IETF in this area. Comments relating to this document will be the IETF in this area. Comments relating to this document will be
gratefully received by the author(s) and the ip-dvb mailing list at: gratefully received by the author(s) and the ip-dvb mailing list at:
skipping to change at line 1857 skipping to change at line 1906
* Type field split into two. * Type field split into two.
* References updated. * References updated.
* Security considerations added (first draft). * Security considerations added (first draft).
* Appendix added with examples. * Appendix added with examples.
-------------------------------------------------------------------- --------------------------------------------------------------------
Expires July 2005 [page 42] Expires July 2005 [page 43]
DRAFT - 02 (Improvement of clarity) DRAFT - 02 (Improvement of clarity)
* Corrected CRC-32 to follow standard practice in DSM-CC. * Corrected CRC-32 to follow standard practice in DSM-CC.
* Removed LLC frame type, now redundant by Bridge-Type (==1) * Removed LLC frame type, now redundant by Bridge-Type (==1)
* Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain,
Bernhard Bernhard
* Changes to description of minimum payload length. Gorry * Changes to description of minimum payload length. Gorry
skipping to change at line 1908 skipping to change at line 1957
sections, since this is not a concern for deployment: Length field sections, since this is not a concern for deployment: Length field
usage and padding initialisation. usage and padding initialisation.
* Changed wording: All multi-byte values in ULE (including Length, * Changed wording: All multi-byte values in ULE (including Length,
Type, and Destination fields) are transmitted in network byte order Type, and Destination fields) are transmitted in network byte order
(most significant byte first). old NiT from Alain, now fixed. (most significant byte first). old NiT from Alain, now fixed.
* Frame byte size in diagrams now updated to -standard- format, and * Frame byte size in diagrams now updated to -standard- format, and
D bit action corrected, as requested by Alain. D bit action corrected, as requested by Alain.
Expires July 2005 [page 43] Expires July 2005 [page 44]
* Frame format diagrams, redrawn to 32-bit format below: * Frame format diagrams, redrawn to 32-bit format below:
0 1 2 3 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 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
* Additional diagram requested by Alain for D=0 bridging (added, and * Additional diagram requested by Alain for D=0 bridging (added, and
subsequent figures renumbered). subsequent figures renumbered).
* Diagrams of encapsulation process, redrawn for clarity (no change * Diagrams of encapsulation process, redrawn for clarity (no change
to meaning). Gorry. to meaning). Gorry.
skipping to change at line 1958 skipping to change at line 2007
* Revised CC processing at Encapsulator (B C-N/GF/A.Allison) * Revised CC processing at Encapsulator (B C-N/GF/A.Allison)
* Revised CC processing at Receiver (from List: A.Allison; et al ) * Revised CC processing at Receiver (from List: A.Allison; et al )
* Corrections to length/PP field in Examples (M Sooriyabandara, * Corrections to length/PP field in Examples (M Sooriyabandara,
Alain) Alain)
* Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit) * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit)
* Section 4.5 only SHARED routed links require D=0 * Section 4.5 only SHARED routed links require D=0
* Packing Threshold defined * Packing Threshold defined
* Next-Layer-Header defined (Now called Next-Header) * Next-Layer-Header defined (Now called Next-Header)
* Addition of Appendix B (to aide verification of SNDFU format) * Addition of Appendix B (to aide verification of SNDFU format)
Expires July 2005 [page 44] Expires July 2005 [page 45]
Working Group ID rev 01 Working Group ID rev 01
Issues addressed: Issues addressed:
* Typographical * Typographical
* Types > 1500 should be passed to the next higher protocol (Hilmar) * Types > 1500 should be passed to the next higher protocol (Hilmar)
* The second part of the Type space corresponds to the values 1500 * The second part of the Type space corresponds to the values 1500
COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF. COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF.
* IANA has already defined IP and IPv6 types - corrected text! * IANA has already defined IP and IPv6 types - corrected text!
Added more security considerations (-01d). Added more security considerations (-01d).
* Should we allow an Adaptation Field within ULE (request for DVB- * Should we allow an Adaptation Field within ULE (request for DVB-
skipping to change at line 1992 skipping to change at line 2041
Revised IPR disclosure Revised IPR disclosure
Revised copyright notice Revised copyright notice
Section 5 added to ULE to define optional Extension Headers (see Section 5 added to ULE to define optional Extension Headers (see
xule) xule)
Correction of figure numbering. Correction of figure numbering.
Correction to capitalisation in Transport Stream definition of fields Correction to capitalisation in Transport Stream definition of fields
Inserted space character after 1536 in line 2 of 4.4.2 Inserted space character after 1536 in line 2 of 4.4.2
Replaced } with ] after ISO_DSMCC Replaced } with ] after ISO-DSMCC
Replace reference to section 6.3 with section 7.3 at end of section Replace reference to section 6.3 with section 7.3 at end of section
4.6. 4.6.
Reference in 4.7.4 was changed to refer to figure 7 (not 6). Reference in 4.7.4 was changed to refer to figure 7 (not 6).
Note added after figure 9. Note added after figure 9.
Expires July 2005 [page 45] Expires July 2005 [page 46]
Working Group ID rev 03 Working Group ID rev 03
Changes with this revision of the document: Changes with this revision of the document:
(i) The worked hexadecimal example in the annexe was reworked to (i) The worked hexadecimal example in the annexe was reworked to
include a valid MAC address for an IPv6 unicast packet. - include a valid MAC address for an IPv6 unicast packet. -
(BCN) (BCN)
(ii) The IANA procedures revised, based on inputs from IANA to (ii) The IANA procedures revised, based on inputs from IANA to
improve consistency of the term Next-Header and to add the improve consistency of the term Next-Header and to add the
skipping to change at line 2052 skipping to change at line 2101
(vii) Clarification of placement of NPA address with extension (vii) Clarification of placement of NPA address with extension
headers. headers.
Issues address in rev-05: Issues address in rev-05:
These revisions were made following a second WGLC and invited cross- These revisions were made following a second WGLC and invited cross-
area IETF review of the Spec. area IETF review of the Spec.
NiTS corrected: NiTS corrected:
Expires July 2005 [page 46] Expires July 2005 [page 47]
Abstract shortened. Abstract shortened.
Added separate references to Ethernet v2; LLC; and 802.3 Added separate references to Ethernet v2; LLC; and 802.3
Added RFC2119 Boilerplate for definitions of capitilised words. Added RFC2119 Boilerplate for definitions of capitilised words.
Corrected English and 63 typos Corrected English and 63 typos
Specified explicitly that Test & Bridge Extension Headers must be Specified explicitly that Test & Bridge Extension Headers must be
the last in the extension chain (no other headers may follow) the last in the extension chain (no other headers may follow)
7.1.1. para 1 - changed PP processing description to specify where 7.1.1. para 1 - changed PP processing description to specify where
to count the number of bytes that were pointed to to count the number of bytes that were pointed to
Corrected the range 0-512 in the IANA Guidelines (should be 0-511). Corrected the range 0-512 in the IANA Guidelines (should be 0-511).
Fixed NPA to consistently refer to the ULE destination address. Fixed NPA to consistently refer to the ULE destination address.
Specific Issues: Specific Issues:
1) The reviewer suggested the title was confusing. A proposed new 1) The reviewer suggested the title was confusing. A proposed new
Title is: Title is:
Ultra Lightweight Encapsulation (ULE) for transmission of Ultra Lightweight Encapsulation (ULE) for transmission of
IP datagrams over an MPEG-2 Transport Stream IP datagrams over an MPEG-2 Transport Stream
2) The reviewer suggested that the name of the D field was changed, 2) The reviewer suggested that the name of the D field was changed,
to make the meaning more obvious. The new name is Destination to make the meaning more obvious. The new name is Destination
Address Absent field, rather than the Destination Address Address Absent field, rather than the Destination Address Present
Present field. The semantics of the D-bit do not change. field. The semantics of the D-bit do not change.
3) The reviewer asked for a description of how to send an LLC frame 3) The reviewer asked for a description of how to send an LLC frame
- in Section 4. This was added to the section on bridging. - in Section 4. This was added to the section on bridging.
4) The reviewer mentioned that we had NOT defined the values needed 4) The reviewer mentioned that we had NOT defined the values needed
for mapping addresses... I'm not sure this was an over-sight, but for mapping addresses... I'm not sure this was an over-sight, but
This was an oversight, the new text was added to the end of the This was an oversight, the new text was added to the end of the
description in section 4.5. Also added references to [RFC1112] description in section 4.5. Also added references to [RFC1112]
[RFC2464]. [RFC2464].
skipping to change at line 2105 skipping to change at line 2154
completion of the Current SNDU, the Receiver accepts the next 2 completion of the Current SNDU, the Receiver accepts the next 2
bytes and examines if this is an End Indicator. When an End bytes and examines if this is an End Indicator. When an End
Indicator is received, a Receiver MUST silently discard the Indicator is received, a Receiver MUST silently discard the
remainder of the TS Packet payload and transition to the Idle State. remainder of the TS Packet payload and transition to the Idle State.
Otherwise this is the start of the next Packed SNDU and the Receiver Otherwise this is the start of the next Packed SNDU and the Receiver
continues by processing this SNDU (provided that the TS Packet has a continues by processing this SNDU (provided that the TS Packet has a
PUSI value of 1, see 7.2.1, otherwise the Receiver has detected a PUSI value of 1, see 7.2.1, otherwise the Receiver has detected a
delimiting error and MUST discard all remaining bytes in the TS delimiting error and MUST discard all remaining bytes in the TS
Packet payload and transitions to the Idle State). Packet payload and transitions to the Idle State).
Expires July 2005 [page 47] Expires July 2005 [page 48]
8) Revised IANA procedures to REQUIRE a definition of the PROCEDURE 8) Revised IANA procedures to REQUIRE a definition of the PROCEDURE
when defining an extension header. when defining an extension header.
IESG Review Rev -06.
This rev was generated in response to issues raised during AD and
IESG review. The changes provide clarifications and corrections, but
do not modify the protocol behaviour.
Comments from Brian Carpenter; Margaret Wasserman; GenART review.
Figure 2 was also updated to reflect 16 bit alignment of the first
word.
In this review a change to the title was proposed by the IESG and was
accepted by the authors:
Ultra Lightweight Encapsulation (ULE)
-> Unidirectional Lightweight Encapsulation (ULE)
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
Expires July 2005 [page 48] Expires July 2005 [page 49]
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/