draft-ietf-ipdvb-ule-06.txt   rfc4326.txt 
Internet Engineering Task Force Gorry Fairhurst Network Working Group G. Fairhurst
Internet Draft University of Aberdeen Request for Comments: 4326 University of Aberdeen
Document: draft-ietf-ipdvb-ule-06.txt Bernhard Collini-Nocker Category: Standards Track B. Collini-Nocker
University of Salzburg University of Salzburg
December 2005
ipdvb WG Unidirectional Lightweight Encapsulation (ULE) for
Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
Category: Draft, Intended Standards Track June 2005
Unidirectional Lightweight Encapsulation (ULE) for transmission of
IP datagrams over an MPEG-2 Transport Stream
Status of this Draft Status of This Memo
By submitting this Internet-Draft, each author represents that any This document specifies an Internet standards track protocol for the
applicable patent or other IPR claims of which he or she is aware Internet community, and requests discussion and suggestions for
have been or will be disclosed, and any of which he or she becomes improvements. Please refer to the current edition of the "Internet
aware will be disclosed, in accordance with Section 6 of BCP 79. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (2005).
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract 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 a Unidirectional Lightweight Encapsulation This document describes a Unidirectional Lightweight Encapsulation
(ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and
other network protocol packets directly over the ISO MPEG-2 other network protocol packets directly over the ISO MPEG-2 Transport
Transport Stream as TS Private Data. ULE specifies a base Stream as TS Private Data. ULE specifies a base encapsulation format
encapsulation format and supports an extension format that allows it and supports an extension format that allows it to carry additional
to carry additional header information to assist in network/Receiver header information to assist in network/Receiver processing.
processing.
Expires November 2005 [page 1]
Table of Contents Table of Contents
1. Introduction 1. Introduction ....................................................3
2. Conventions used in this document 2. Conventions Used in This Document ...............................4
3. Description of method 3. Description of the Method .......................................8
4. SNDU Format 4. SNDU Format .....................................................9
4.1 Destination Address Absent (D) Field 4.1. Destination Address Absent (D) Field ......................10
4.2 Length Field 4.2. Length Field ..............................................10
4.3 End Indicator 4.3. End Indicator .............................................10
4.4 Type Field 4.4. Type Field ................................................10
4.4.1 Type 1: Next-Header Type Fields 4.4.1. Type 1: Next-Header Type Fields ....................11
4.4.2 Type 2: EtherType Compatible Type Fields 4.4.2. Type 2: EtherType Compatible Type Fields ...........11
4.5 SNDU Destination Address Field 4.5. SNDU Destination Address Field ............................12
4.6 SNDU Trailer CRC 4.6. SNDU Trailer CRC ..........................................12
4.7 Description of SNDU Formats 4.7. Description of SNDU Formats ...............................13
4.7.1 End Indicator 4.7.1. End Indicator ......................................14
4.7.2 IPv4 SNDU Encapsulation 4.7.2. IPv4 SNDU Encapsulation ............................14
4.7.3 IPv6 SNDU Encapsulation 4.7.3. IPv6 SNDU Encapsulation ............................15
5. Extension Headers 5. Extension Headers ..............................................16
5.1 Test SNDU 5.1. Test SNDU .................................................18
5.2 Bridged Frame SNDU Encapsulation 5.2. Bridged Frame SNDU Encapsulation ..........................18
5.3 Extension-Padding Optional Extension Header 5.3. Extension-Padding Optional Extension Header ...............21
6.Processing at the Encapsulator 6. Processing at the Encapsulator .................................22
6.1 SNDU Encapsulation 6.1. SNDU Encapsulation ........................................22
6.2 Procedure for Padding and Packing 6.2. Procedure for Padding and Packing .........................24
7. Receiver Processing 7. Receiver Processing ............................................25
7.1 Idle State 7.1. Idle State ................................................26
7.1.1 Idle State Payload Pointer Checking 7.1.1. Idle State Payload Pointer Checking ................26
7.2 Processing of a Received SNDU 7.2. Processing of a Received SNDU .............................26
7.2.1 Reassembly Payload Pointer Checking 7.2.1. Reassembly Payload Pointer Checking ................28
7.3 Other Error Conditions 7.3. Other Error Conditions ....................................28
8. Summary 8. Summary ........................................................29
9. Acknowledgments 9. Acknowledgements ...............................................29
10. Security Considerations 10. Security Considerations .......................................29
11. References 11. IANA Considerations ...........................................30
11.1 Normative References 11.1. IANA Guidelines ..........................................30
11.2 Informative References 12. References ....................................................31
12. Authors' Addresses 12.1. Normative References .....................................31
13. IPR Notices 12.2. Informative References ...................................32
13.1 Intellectual Property Statement Appendix A. SNDU Packing Examples .................................35
13.2 Disclaimer of Validity Appendix B. SNDU Encapsulation ....................................40
14. Copyright Statement
14.1 Intellectual Property Statement
14.2 Disclaimer of Validity
15. IANA Considerations
15.1 IANA Guidelines
ANNEX A: Informative Appendix - SNDU Packing Examples
ANNEX B: Informative Appendix - SNDU Encapsulation
Expires July 2005 [page 2]
1. Introduction 1. Introduction
This document describes an encapsulation for the 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; RFCXARCHX]. The encapsulation satisfies the Streams [ISO-MPEG2, RFC4259]. The encapsulation satisfies the
requirement for a lightweight encapsulation defined in section 4 of requirement for a lightweight encapsulation defined in section 4 of
[RFCXARCHX]. The basic header provides the required set of protocol [RFC4259]. The basic header provides the required set of protocol
fields. Extension headers may also be defined. This header structure fields. Extension headers may also be defined. This header
is significantly simpler to parse and process [SOOR05] than current structure is significantly simpler to parse and process [SOOR05] than
alternative methods (e.g. MPE [ETSI-DAT] that builds upon the DSM-CC current alternative methods (e.g., MPE [ETSI-DAT], which builds upon
Table Section syntax [ISO-DSMCC]). the DSM-CC Table Section syntax [ISO-DSMCC]).
The encapsulation is suited to services based on MPEG-2, for example The encapsulation is suited to services based on MPEG-2; for example,
the Digital Video Broadcast (DVB) architecture, the Advanced the Digital Video Broadcast (DVB) architecture, the Advanced
Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other Television Systems Committee (ATSC) system [ATSC, ATSC-G], and other
similar MPEG-2 based transmission systems. Such systems provide similar MPEG-2-based transmission systems. Such systems provide
unidirectional (simplex) physical and link layer standards. Support unidirectional (simplex) physical and link-layer standards. Support
has been defined for a wide range of physical media (e.g. has been defined for a wide range of physical media (e.g.,
Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS,
ATSC-S], Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). ATSC-S], and Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC]).
Bi-directional (duplex) links may also be established using these Bi-directional (duplex) links may also be established using these
standards (e.g., DVB defines a range of return channel technologies, standards (e.g., DVB defines a range of return channel technologies,
including the use of two-way satellite links [ETSI-RCS] and dial-up including the use of two-way satellite links [ETSI-RCS]) and dial-up
modem links [RFC3077]). modem links [RFC3077].
Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other Protocol Data Units (PDUs), such as Ethernet Frames, IP datagrams, or
network layer packets) for transmission over an MPEG-2 Transport other network-layer packets, used for transmission over an MPEG-2
Multiplex are passed to an Encapsulator. This formats each PDU into Transport Multiplex are passed to an Encapsulator. This formats each
a SubNetwork Data Unit (SNDU) by adding an encapsulation header and PDU into a SubNetwork Data Unit (SNDU) by adding an encapsulation
an integrity check trailer. The SNDU is fragmented into a series of header and an integrity check trailer. The SNDU is fragmented into a
one or more MPEG-2 Transport Stream (TS) Packets that are sent over series of one or more MPEG-2 Transport Stream (TS) Packets that are
a single TS Logical Channel. sent over a single TS Logical Channel.
The MPEG-2 specification [ISO-MPEG2] requires conformant TS The MPEG-2 specification [ISO-MPEG2] requires that conformant TS
Multiplexes to provide Program Specific Information (PSI) for Multiplexes provide Program Specific Information (PSI) for each
each stream in the TS Multiplex. Other MPEG-2 based transmission stream in the TS Multiplex. Other MPEG-2-based transmission
standards may also define Service Information (SI). standards may also define Service Information (SI).
This information may allow Receivers and Re-multiplexors A format_identifier value has been registered for ULE [ULE1]. This
[RFCXARCHX] to locate a specific ULE Stream (i.e., the PID value of 32 bit number has a hexadecimal value of 0x554C4531. Transport
the TS Logical Channel that carries a ULE Stream). The conditions Streams that utilise the Programme Map Table (PMT) defined in ISO
under which this information is required, and the format in which it 13818-1 [ISO-MPEG2] and that use the ULE format defined in this
is to be provided is beyond the scope of this document. Addressing document, SHOULD insert a descriptor with this value in the PMT
and mapping issues for ULE over MPEG-2 are also described in ES_info descriptor loop. ULE Streams may also be identified by the
[ID-ipdvb-ar]. stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2].
Expires July 2005 [page 3] This information may allow Receivers and Re-multiplexors [RFC4259] to
locate a specific ULE Stream (i.e., the PID value of the TS Logical
Channel that carries a ULE Stream). The conditions under which this
information is required and the format in which it is to be provided
are beyond the scope of this document. Addressing and mapping issues
for ULE over MPEG-2 are also described in [IPDVB-AR].
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-MPEG2]. 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
Field and/or TS Packet payload. 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.
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A
format for transmission of data and control information in an MPEG-2 format for transmission of data and control information in an MPEG-2
Private Section, defined by the ISO MPEG-2 standard. Private Section, defined by the ISO MPEG-2 standard.
DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of DVB: Digital Video Broadcast. A framework and set of associated
associated standards published by the European Telecommunications standards published by the European Telecommunications Standards
Standards Institute (ETSI) for the transmission of video, audio, and Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for the
data, using the ISO MPEG-2 Standard. transmission of video, audio, and data using the ISO MPEG-2 Standard
[ISO-MPEG2].
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
TS Packets. 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, IEEE-802.2]]. A link layer LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. A link-layer
protocol defined by the IEEE 802 standard, which follows the protocol defined by the IEEE 802 standard, which follows the Ethernet
Ethernet MAC Header. 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 MAC Header: The link-layer header of the IEEE 802.3 standard
[IEEE-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] 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 13818-1) [ISO-MPEG2], and ITU-T (in H.222 Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222
[ITU-H222]). [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
byte destination address (resembling an IEEE MAC address) within the 6-byte destination address (resembling an IEEE MAC address) within
MPEG-2 transmission network that is used to identify individual the 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
more SNDUs, rather than use Padding. After the Packet Threshold SNDUs, rather than use Padding. After the Packet Threshold period,
period, the Encapsulator uses Padding to send the partially filled 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 Padding: A method that fills the remaining unused bytes in a TS
Packet payload using the specific pattern of 0xFF." Packet payload using the specific pattern of 0xFF.
Payload Unit, PU. A sequence of bytes sent using a TS. Examples of 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. 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
must all carry the same PID value. The all zeros PID 0x0000 as well all carry the same PID value. The all-zeros PID 0x0000 as well as
as other PID values are reserved for specific PSI/SI Tables [ISO- other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2].
MPEG2]. The all ones PID value 0x1FFF indicates a Null TS Packet The all-ones PID value 0x1FFF indicates a Null TS Packet introduced
introduced to maintain a constant bit rate of a TS Multiplex. There to maintain a constant bit rate of a TS Multiplex. There is no
is no required relationship between the PID values used for TS required relationship between the PID values used for TS Logical
Logical Channels transmitted using different TS Multiplexes. 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 4 byte TS Packet header. It contains the number directly follows the 4-byte TS Packet header. It contains the number
of bytes that follow the Payload Pointer, up to the start of the of bytes that follow the Payload Pointer, up to the start of the
first Payload Unit (counted from the first byte of the TS Packet first Payload Unit (counted from the first byte of the TS Packet
payload field, and excluding the PP field itself). The presence of payload field, and excluding the PP field itself). The presence of
the Payload Pointer is indicated by the value of the PUSI bit in the the Payload Pointer is indicated by the value of the PUSI bit in the
TS Packet header. The Payload Pointer is present in DSM-CC, Table 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 Sections, and ULE. It is not present in TS Logical Channels that use
the PES-format. the PES-format.
Private Section: A syntactic structure constructed in accordance Private Section: A syntactic structure constructed in accordance with
with Table 2-30 of [ISO-MPEG2]. The structure may be used to Table 2-30 of [ISO-MPEG2]. The structure may be used to identify
identify private information (i.e. not defined by [ISO-MPEG2]) private information (i.e., not defined by [ISO-MPEG2]) relating to
relating to one or more elementary streams, or a specific MPEG-2 one or more elementary streams, or a specific MPEG-2 program, or the
program, or the entire Transport Stream. Other Standards bodies, entire Transport Stream. Other Standards bodies, e.g., ETSI, ATSC,
e.g. ETSI, ATSC, have defined sets of table structures using the have defined sets of table structures using the private_section
private_section structure. A Private Section is transmitted as a structure. A Private Section is transmitted as a sequence of TS
sequence of TS Packets using a TS Logical Channel. A TS Logical Packets using a TS Logical Channel. A TS Logical Channel may carry
Channel may carry sections from more than one set of tables. sections from more than one set of tables.
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 information about the service carried in a TS Multiplex. The
information is carried in one of four specifically identified Table information is carried in one of four specifically identified Table
Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table. Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
PU: Payload Unit. PU: Payload Unit.
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
and performs filtering and forwarding of encapsulated PDUs to the 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 defined by another standards this term describes a table that is defined by another standards body
body to convey information about the services carried in a TS to convey information about the services carried in a TS Multiplex.
Multiplex. A Table may consist of one or more Table Sections, A Table may consist of one or more Table Sections; however, all
however all sections of a particular SI Table must be carried over a sections of a particular SI Table must be carried over a single TS
single TS Logical Channel [ISO-MPEG2]. 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 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
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model. See also TS Logical Channel and TS Multiplex. reference model. See also TS Logical Channel and TS Multiplex.
Expires July 2005 [page 6] TS Header: The 4-byte header of a TS Packet [ISO-MPEG2]. Each 188B
TS Header: The 4 byte header of a TS Packet [ISO-MPEG2]. Each 188B
TS Packet incorporates a 4B header with the following fields (those TS Packet incorporates a 4B header with the following fields (those
referenced within this document are marked with *): referenced within this document are marked with *):
Field Length Name/Purpose Field Length Name/Purpose
(in bits) (in bits)
8b Synchronisation pattern equal 0x47 8b Synchronisation pattern equal to 0x47
*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)
If the PUSI bit is set to a value of 1, there is one
additional field following the TS packet header:
*8b Payload Pointer (PP)
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]. It 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 value All packets sent over a TS Logical Channel carry the same PID value
(this value is unique within a specific TS Multiplex). The term (this value is unique within a specific TS Multiplex). The term
"Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the "Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content
content carried by a specific TS Logical Channel (see, ULE Stream). carried by a specific TS Logical Channel (see ULE Stream). Some PID
Some PID values are reserved (by MPEG-2) for specific signalling. values are reserved (by MPEG-2) for specific signalling. Other
Other standards (e.g., ATSC, DVB) also reserve specific PID values. 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) Multiplex (possibly associated with a different PID value) [RFC4259];
[RFCXARCHX], for example to redistribute the same multicast content for example, to redistribute the same multicast content to two
to two terrestrial TV transmission cells. 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 a encapsulated PDUs. ULE Streams may be identified by definition of a
stream_type in SI/PSI [ISO-MPEG2]. stream_type in SI/PSI [ISO-MPEG2].
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 either by
placing it either in the payload of a single TS Packet, or if being placed in the payload of a single TS Packet, or, if required,
required, an SNDU may be fragmented into a series of TS Packets. by being fragmented into a series of TS Packets. Where there is
Where there is sufficient space, the method permits a single TS sufficient space, the method permits a single TS Packet to carry more
Packet to carry more than one SNDU (or part there of), sometimes than one SNDU (or part thereof), a practice sometimes known as
known as Packing. All TS Packets comprising an SNDU MUST be assigned Packing. All TS Packets comprising an SNDU MUST be assigned the same
the same PID, and therefore form a part of the same TS Logical 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
start 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. Although ULE uses 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
Payload Pointer follows the last byte of the TS Packet header. Payload Pointer follows the last byte of the TS Packet header.
If a Payload Unit (SNDU) finishes before the end of a TS Packet If a Payload Unit (SNDU) finishes before the end of a TS Packet
payload, but it is not intended to start another Payload Unit, a payload, but it is not intended to start another Payload Unit, a
stuffing procedure fills the remainder of the TS Packet payload with stuffing procedure (known as Padding) fills the remainder of the TS
bytes with a value 0xFF [ISO-MPEG2], known as Padding. Packet payload with bytes with a value 0xFF [ISO-MPEG2].
A Receiver processing MPEG-2 Table Sections that receives a value of A Receiver processing MPEG-2 Table Sections that receives a value of
0xFF in place of the table_id field, interprets this as 0xFF in the first byte of a Table Section (table_Id) interprets this
Padding/Stuffing and silently discards the remainder of the TS as Padding/Stuffing and silently discards the remainder of the TS
Packet payload. The payload of the next TS Packet for the same TS Packet payload. The payload of the next TS Packet for the same TS
Logical Channel will begin with a Payload Pointer of value 0x00, Logical Channel will begin with a Payload Pointer of value 0x00,
indicating that the next Payload Unit immediately follows the TS indicating that the next Payload Unit immediately follows the TS
Packet header. The ULE protocol resembles this, but differs in the Packet header. The ULE protocol resembles this, but differs in the
exact procedure (see the following sections). exact procedure (see the following sections).
The TS Packet Header also carries a two bit Adaptation Field Control The TS Packet Header also carries a two-bit Adaptation Field Control
(AFC) value. This adaptation field may extend the TS Packet Header (AFC) value. This adaptation field may extend the TS Packet Header
to carry timing and synchronisation information and may also be used to carry timing and synchronisation information and may also be used
to include stuffing bytes before a TS Packet payload. Adaptation to include stuffing bytes before a TS Packet payload. Adaptation
Field stuffing is NOT used in this encapsulation method, and TS Field stuffing is NOT used in this encapsulation method, and TS
Packets from a ULE Encapsulator MUST be sent with an AFC value of Packets from a ULE Encapsulator MUST be sent with an AFC value of
'01'. For TS Logical Channels supporting ULE, Receivers MUST discard '01'. For TS Logical Channels supporting ULE, Receivers MUST discard
TS Packets that carry other AFC values. TS Packets that carry other AFC values.
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
is illustrated below: illustrated below:
< ----------------------------- SNDU ----------------------------- > < ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 | |D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation (* optional Destination Address) Figure 1: SNDU Encapsulation (* optional Destination Address)
All multi-byte values in ULE (including the Length/End Indicator All multi-byte values in ULE (including the Length/End Indicator
(4.2,4.3), Type (4.4), Destination Address (4.5), and Extension (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension
Headers (5)) are transmitted in network byte order (most significant Headers (5)) are transmitted in network byte order (most significant
byte first). The most significant bit of each byte is placed in the byte first). The most significant bit of each byte is placed in the
left-most position of the 8-bit field. Appendix A provides left-most position of the 8-bit field. Appendix A provides
informative examples of usage. 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
the Destination Address Absent Field, the D-bit. A value of 0 Destination Address Absent Field, the D-bit. A value of 0 indicates
indicates the presence of the Destination Address Field (see section the presence of the Destination Address Field (see section 4.5). A
4.5). A value of 1 indicates that a Destination Address Field is not value of 1 indicates that a Destination Address Field is not present.
present.
An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other
SNDUs SHOULD be sent with a D-bit value of 0 (see 4.5). SNDUs MAY be sent with a D-bit value of 0 or 1. The default method
SHOULD use a D-bit value of 0 (see section 4.5).
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 of the SNDU base
the CRC. Note the special case described in 4.3. header (figure 9) up to and including the CRC. This Length includes
the size of any extension headers that may be present (section 5).
Note the special case described in section 4.3.
4.3 End Indicator 4.3. End Indicator
When the first two bytes following an SNDU have the value 0xFFFF, When the first two bytes following an SNDU have the value 0xFFFF,
this denotes an End Indicator (i.e., all ones length combined with a this denotes an End Indicator (i.e., all ones length combined with a
D-bit value of 1). This indicates to the Receiver that there are no 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] 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
independent length fields is therefore undesirable. In the ULE independent Length fields is therefore undesirable. In the ULE
header, this is avoided in the SNDU header by including only one header, this is avoided in the SNDU header by including only one
length value, but bridging of LLC frames re-introduces this length value, but bridging of LLC frames re-introduces this
consideration (section 5.2). consideration (section 5.2).
The Ethernet LLC mode of identification is not required in ULE, The Ethernet LLC mode of identification is not required in ULE, since
since the SNDU format always carries an explicit Length Field, and the SNDU format always carries an explicit Length field, and
therefore the procedure in ULE is modified, as below: therefore the procedure in ULE is modified, as below:
The first set of ULE Type field values comprise the set of values The first set of ULE Type field values comprise the set of values
less than 1536 in decimal. These Type field values are IANA less than 1536 in decimal. These Type field values are IANA assigned
assigned (see 4.4.1), and indicate the Next-Header. (see section 4.4.1) and indicate the Next-Header.
The second set of ULE Type field values comprise the set of values The second set of ULE Type field values comprise the set of values
greater than or equal to 1536 in decimal. In ULE, this value is greater than or equal to 1536 in decimal. In ULE, this value is
identical to the corresponding type codes specified by the IEEE/DIX identical to the corresponding type codes specified by the IEEE/DIX
type assignments for Ethernet and recorded in the IANA EtherType type assignments for Ethernet and recorded in the IANA EtherType
registry. registry.
4.4.1 Type 1: Next-Header Type Fields 4.4.1. Type 1: Next-Header Type Fields
The first part of the Type space corresponds to the values 0 to 1535 The first part of the Type space corresponds to the values 0 to 1535
Decimal. These values may be used to identify link-specific decimal. These values may be used to identify link-specific
protocols and/or to indicate the presence of Extension Headers that protocols and/or to indicate the presence of Extension Headers that
carry additional optional protocol fields (e.g. a bridging carry additional optional protocol fields (e.g., a bridging
encapsulation). Use of these values is co-ordinated by an IANA encapsulation). Use of these values is co-ordinated by an IANA
registry. The following types are defined in this document: registry. The following types are defined in this document:
0x0000: Test SNDU (see 5.1) 0x0000: Test SNDU (see section 5.1)
0x0001: Bridged Frame (see 5.2) 0x0001: Bridged Frame (see section 5.2)
0x0100: Extension-Padding (see 5.3) 0x0100: Extension-Padding (see section 5.3)
Expires July 2005 [page 10]
The remaining values within the first part of the Type space are The remaining values within the first part of the Type space are
reserved for Next-Header values allocated by the IANA. reserved for Next-Header values allocated by the IANA.
4.4.2 Type 2: EtherType Compatible Type Fields 4.4.2. Type 2: EtherType Compatible Type Fields
The second part of the Type space corresponds to the values between The second part of the Type space corresponds to the values between
0x600 (1536 decimal) and 0xFFFF. This set of type assignments 0x600 (1536 decimal) and 0xFFFF. This set of type assignments
follow DIX/IEEE assignments (but exclude use of this field as a follows DIX/IEEE assignments (but excludes use of this field as a
frame length indicator). All assignments in this space MUST use the frame length indicator). All assignments in this space MUST use the
values defined for IANA EtherType, the following two Type values are values defined for IANA EtherType. The following two Type values are
used as examples (taken from the IANA EtherTypes registry): used as examples (taken from the IANA EtherTypes registry):
0x0800: IPv4 Payload (see 4.7.2) 0x0800: IPv4 Payload (see section 4.7.2)
0x86DD: IPv6 Payload (see 4.7.3) 0x86DD: IPv6 Payload (see section 4.7.3)
4.5 SNDU Destination Address Field 4.5. SNDU Destination Address Field
The SNDU Destination Address Field is optional (see 4.1). This field The SNDU Destination Address Field is optional (see section 4.1).
MUST be carried (i.e. D=0) for IP unicast packets destined to This field MUST be carried (i.e., D=0) for IP unicast packets
routers that are sent using shared links (i.e., where the same link destined to routers that are sent using shared links (i.e., where the
connects multiple Receivers). A sender MAY omit this field (D=1) for same link connects multiple Receivers). A sender MAY omit this field
an IP unicast packet and/or multicast packets delivered to Receivers (D=1) for an IP unicast packet and/or multicast packets delivered to
that are able to utilise a discriminator field (e.g. the IPv4/IPv6 Receivers that are able to utilise a discriminator field (e.g., the
destination address, or a bridged MAC destination address), which in IPv4/IPv6 destination address, or a bridged MAC destination address),
combination with the PID value, could be interpreted as a Link-Level which, in combination with the PID value, could be interpreted as a
address. Link-Level address.
When the SNDU header indicates the presence of an SNDU Destination When the SNDU header indicates the presence of an SNDU Destination
Address field (i.e. D=0), a Network Point of Attachment, NPA, field Address field (i.e., D=0), a Network Point of Attachment (NPA) field
directly follows the fourth byte of the SNDU header. NPA destination directly follows the fourth byte of the SNDU header. NPA destination
addresses are 6 Byte numbers, normally expressed in hexadecimal, addresses are 6 Byte numbers, normally expressed in hexadecimal, used
used to identify the Receiver(s) in a MPEG-2 transmission network to identify the Receiver(s) in a MPEG-2 transmission network that
that should process a received SNDU. The value 0x00:00:00:00:00:00, should process a received SNDU. The value 0x00:00:00:00:00:00 MUST
MUST NOT be used as a destination address in an SNDU. The least NOT be used as a destination address in an SNDU. The least
significant bit of the first byte of the address is set to 1 for significant bit of the first byte of the address is set to 1 for
multicast frames, and the remaining bytes specify the link layer multicast frames, and the remaining bytes specify the link-layer
multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the
link broadcast address, indicating this SNDU is to be delivered to link broadcast address, indicating that this SNDU is to be delivered
all Receivers. to all Receivers.
IPv4 packets carrying an IPv4 subnetwork broadcast address need to IPv4 packets carrying an IPv4 subnetwork broadcast address need to be
be delivered to all systems with the same network prefix. When a delivered to all systems with the same network prefix. When a SNDU
SNDU Destination Address is present (D=0) the value MUST be set to Destination Address is present (D=0), the value MUST be set to the
the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF). NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
When the PDU is an IP multicast packet and an SNDU Destination When the PDU is an IP multicast packet and an SNDU Destination
Address is present (D=0), the IP group destination address of the Address is present (D=0), the IP group destination address of the
multicast packet MUST be mapped to the multicast SNDU Destination multicast packet MUST be mapped to the multicast SNDU Destination
Address (following the method used to generate a destination MAC Address (following the method used to generate a destination MAC
address in Ethernet). The method for mapping IPv4 multicast address in Ethernet). The method for mapping IPv4 multicast
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
the SNDU. This position eases CRC computation by hardware. The CRC- SNDU. This position eases CRC computation by hardware. The CRC-32
32 polynomial is to be used. Examples where this polynomial is also 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 [ITU-3563]. 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
32), and places this in the CRC Field. In ULE, the bytes are CRC-32), and places this in the CRC Field. In ULE, the bytes are
processed in order of increasing position within the SNDU, the order processed in order of increasing position within the SNDU; the order
of processing bits is NOT reversed. This use resembles, but is of processing bits is NOT reversed. This use resembles, but is
different to that in SCTP [RFC3309]. different from that in SCTP [RFC3309].
The Receiver performs an integrity check by independently The Receiver performs an integrity check by independently calculating
calculating the same CRC value and comparing this with the the same CRC value and comparing this with the transmitted value in
transmitted value in the SNDU trailer. SNDUs that do not have a the SNDU trailer. SNDUs that do not have a valid CRC are discarded,
valid CRC, are discarded, causing the Receiver to enter the Idle causing the Receiver to enter the Idle State.
State.
This description may be suited for hardware implementation, but this This description may be suited for hardware implementation, but this
document does not imply any specific implementation. Software-based document does not imply any specific implementation. Software-based
table-lookup or hardware-assisted software-based implementations are table-lookup or hardware-assisted software-based implementations are
also possible. Annexe B provides an example of an Encapsulated PDU also possible. Appendix B provides an example of an Encapsulated PDU
that includes the computed CRC-32 value. that includes the computed CRC-32 value.
The primary purpose of this CRC is to protect the SNDU (header, and The primary purpose of this CRC is to protect the SNDU (header and
payload) from undetected reassembly errors and errors introduced by payload) from undetected reassembly errors and errors introduced by
unexpected software / hardware operation while the SNDU is in unexpected software/hardware operation while the SNDU is in transit
transit across the MPEG-2 subnetwork and during processing at the across the MPEG-2 subnetwork and during processing at the
encapsulation gateway and/or the Receiver. It may also detect the Encapsulator and/or the Receiver. It may also detect the presence of
presence of uncorrected errors from the physical link (however, uncorrected errors from the physical link (however, these may also be
these may also be detected by other means, e.g. section 7.3). detected by other means, e.g., section 7.3).
Expires July 2005 [page 12]
4.7 Description of SNDU Formats 4.7. Description of SNDU Formats
The format of an SNDU is determined by the combination of the The format of an SNDU is determined by the combination of the
Destination Address Absent bit (D) and the SNDU Type Field. The Destination Address Absent bit (D) and the SNDU Type field. The
simplest encapsulation places a PDU directly into an SNDU payload. simplest encapsulation places a PDU directly into an SNDU payload.
Some Type 1 encapsulations may require additional header fields. Some Type 1 encapsulations may require additional header fields.
These are inserted in the SNDU following the NPA destination address These are inserted in the SNDU following the NPA destination address
and directly preceding the PDU. and directly preceding the PDU.
The following SNDU Formats are defined here: The following SNDU Formats are defined here:
End Indicator: The Receiver should enter the Idle State (4.7.1). End Indicator: The Receiver should enter the Idle State (4.7.1).
IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2) IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2).
IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3). IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3).
Test SNDU: The payload will be discarded by the Receiver (5.1). Test SNDU: The payload will be discarded by the Receiver (5.1).
Bridged SNDU: The payload carries a bridged MAC frame (5.2). Bridged SNDU: The payload carries a bridged MAC frame (5.2).
Other formats may be defined through relevant assignments in the Other formats may be defined through relevant assignments in the IEEE
IEEE and IANA registries. 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]
4.7.2 IPv4 SNDU 4.7.2. IPv4 SNDU Encapsulation
IPv4 datagrams are directly transported using one of the two IPv4 datagrams are directly transported using one of the two standard
standard SNDU structures, in which the PDU is placed directly in the SNDU structures, in which the PDU is placed directly in the SNDU
SNDU payload. The two encapsulations are shown in figures 3 and 4. payload. The two encapsulations are shown in Figures 3 and 4. (Note
(Note that in this, and the following figures, the IP datagram that in this, and the following figures, the IP datagram payload is
payload is of variable size, and is directly followed by the CRC- of variable size and is directly followed by the CRC-32).
32).
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 = 0x0800 | |0| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= IPv4 datagram = = IPv4 datagram =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0)
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| Length (15b) | Type = 0x0800 | |1| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= IPv4 datagram = = IPv4 datagram =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1). Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1)
4.7.3 IPv6 SNDU Encapsulation 4.7.3. IPv6 SNDU Encapsulation
IPv6 datagrams are directly transported using one of the two IPv6 datagrams are directly transported using one of the two standard
standard SNDU structures, in which the PDU is placed directly in the SNDU structures, in which the PDU is placed directly in the SNDU
SNDU payload. The two encapsulations are shown in figures 5 and 6. payload. The two encapsulations are shown in Figures 5 and 6.
Expires July 2005 [page 14]
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 = 0x86DD | |0| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= IPv6 datagram = = IPv6 datagram =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0). Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0)
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| Length (15b) | Type = 0x86DD | |1| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= IPv6 datagram = = IPv6 datagram =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1) Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
Expires July 2005 [page 15]
5. Extension Headers 5. Extension Headers
This section describes an extension format for the ULE This section describes an extension format for the ULE encapsulation.
encapsulation. In ULE, a Type field value less than 1536 Decimal In ULE, a Type field value less than 1536 decimal indicates an
indicates an Extension Header. These values are assigned from a Extension Header. These values are assigned from a separate IANA
separate IANA registry defined for ULE. registry defined for ULE.
The use of a single Type/Next-Header field simplifies processing and The use of a single Type/Next-Header field simplifies processing and
eliminates the need to maintain multiple IANA registries. The cost eliminates the need to maintain multiple IANA registries. The cost
is that each Extension Header requires at least 2 bytes. This is is that each Extension Header requires at least 2 bytes. This is
justified, on the basis of simplified processing and maintaining a justified, on the basis of simplified processing and maintaining a
simple lightweight header for the common case when no extensions are simple lightweight header for the common case when no extensions are
present. present.
A ULE Extension Header is identified by a 16-bit value in the Type A ULE Extension Header is identified by a 16-bit value in the Type
field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN
field and an 8-bit H-Type field, as follows: field, and an 8-bit H-Type field, as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN| H-Type | |0 0 0 0 0|H-LEN| H-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of ULE Next-Header Field. Figure 7: Structure of ULE Next-Header Field
The H-LEN Assignment is described below: The H-LEN Assignment is described below:
0 Indicates a Mandatory Extension Header 0 Indicates a Mandatory Extension Header
1 Indicates an Optional Extension Header of length 2B 1 Indicates an Optional Extension Header of length 2B (Type only)
2 Indicates an Optional Extension Header of length 4B 2 Indicates an Optional Extension Header of length 4B (Type + 2B)
3 Indicates an Optional Extension Header of length 6B 3 Indicates an Optional Extension Header of length 6B (Type + 4B)
4 Indicates an Optional Extension Header of length 8B 4 Indicates an Optional Extension Header of length 8B (Type + 6B)
5 Indicates an Optional Extension Header of length 10B 5 Indicates an Optional Extension Header of length 10B (Type + 8B)
>=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).
An H-LEN value 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
are defined by an IANA Registry (section 15). Registry values for 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]
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 section 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's 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 |
+---+--------------------------------------------------+--------+ +---+--------------------------------------------------+--------+
< ULE base header > < ext 1 > < ULE base header > < ext 1 >
Figure 8: SNDU Encapsulation with one Extension Header (for D=0). Figure 8: SNDU Encapsulation with one Extension Header (for D=0)
Where: Where:
D is the ULE D_bit (in this example D=0, however NPA addresses may D is the ULE D_bit (in this example D=0; however, NPA addresses may
also be omitted when using Extension Headers). also be omitted when using Extension Headers).
T1 is the base header Type field. In this case, specifying a T1 is the base header Type field. In this case, specifying a
Next-Header value. Next-Header value.
H1 is a set of fields defined for header type T1. There may be 0 H1 is a set of fields defined for header type T1. There may be 0
or more bytes of information for a specific ULE Extension Header. or more bytes of information for a specific ULE Extension Header.
T2 is the Type field of the next header, or an EtherType > 1535 B T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried. indicating the type of the PDU being carried.
< -------------------------- 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. In series. Figure 12 shows an SNDU including two Extension Headers. In
the example, the values of T1 and T2 are both less than 1536 the example, the values of T1 and T2 are both less than 1536 decimal.
Decimal. Each indicates the presence of an Extension Header, rather Each indicates the presence of an Extension Header, rather than a
than a directly following PDU. T3 has a value > 1535 indicating the directly following PDU. T3 has a value > 1535 indicating the
EtherType of the PDU being carried. Although an SNDU may contain an EtherType of the PDU being carried. Although an SNDU may contain an
arbitrary number of consecutive Extension Headers, it is not arbitrary number of consecutive Extension Headers, it is not expected
expected that SNDUs will generally carry a large number of that SNDUs will generally carry a large number of extensions.
extensions.
Expires July 2005 [page 17]
5.1 Test SNDU 5.1. Test SNDU
A Test SNDU (figure 10) is a Mandatory Extension Header of Type 1. A Test SNDU (Figure 10) is a Mandatory Extension Header of Type 1.
This header must be the final (or only) extension header specified This header must be the final (or only) extension header specified in
in the header chain of a SNDU. The structure of the Data portion of the header chain of an SNDU. The structure of the Data portion of
this SNDU is not defined by this document. All Receivers MAY record this SNDU is not defined by this document. Receivers MAY record
reception in a log file, but MUST then discard any Test SNDUs. The reception in a log file, but MUST then discard any Test 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 Bridged 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
of a SNDU. The payload includes MAC address and EtherType [DIX] or an SNDU. The payload includes MAC address and EtherType [DIX] or LLC
LLC Length [ISO-8802-2] fields together with the contents of a Length [ISO-8802-2] fields together with the contents of a bridged
bridged MAC frame. The SNDU has the format shown in figures 11 and 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
their own NPA address (or a broadcast/multicast address), the own NPA address (or a broadcast/multicast address); the payload of
payload of the remaining SNDUs are processed by the bridging rules the remaining SNDUs are processed by the bridging rules that follow.
that follow. An SNDU without an NPA address (D=1) results in a An SNDU without an NPA address (D=1) results in a Receiver performing
Receiver performing bridging processing on the payload of all bridging processing on the payload of all received SNDUs.
received SNDUs.
A Gateway MAY also use this encapsulation format to directly An Encapsulator 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 [IEEE-802.2; ISO-8802-2]. To do this, it constructs an encapsulation [IEEE-802.2, ISO-8802-2]. To do this, it constructs an
SNDU with a Bridge Extension Header containing the intended SNDU with a Bridge Extension Header containing the intended
destination MAC address, the MAC source address of the Gateway, and destination MAC address, the MAC source address of the Encapsulator,
the LLC-Length. The PDU comprises an LLC header followed by the and the LLC-Length. The PDU comprises an LLC header followed by the
required payload. The Gateway MAY choose to suppress the NPA address required payload. The Encapsulator MAY choose to suppress the NPA
(see 4.5). address (see 4.5).
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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Destination Address (6B) | | MAC Destination Address (6B) |
skipping to change at line 934 skipping to change at page 20, line 31
| (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.2] (see section 5). IEEE 802.3 [IEEE-802.2] (see section 5).
In this special case, the Mandatory Extension Header format may be In this special case, the Mandatory Extension Header format may be
interpreted as either an EtherType [DIX] or an LLC Length field, interpreted as either an EtherType [DIX] or an LLC Length field,
specified by IEEE 802 [IEEE-802.3] rather than as a value assigned in
Expires July 2005 [page 19] the ULE Next-Header Registry maintained by the IANA.
specified by IEEE 802 [IEEE-802.3] rather a value assigned in the
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 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 from 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 the sender to be aware of such Ethernet padding (e.g., [DIX,
(e.g. [DIX; IEEE-802.3]). 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
MUST check the LAN-FCS value of all frames received, prior to Encapsulator MUST check the LAN-FCS value of all frames received,
further processing. Frames received with an invalid LAN FCS MUST be prior to further processing. Frames received with an invalid LAN FCS
discarded. After checking, the LAN FCS is then removed (i.e., it is MUST be discarded. After checking, the LAN FCS is then removed
NOT forwarded in the bridged SNDU). As in other ULE frames, the (i.e., it is NOT forwarded in the bridged SNDU). As in other ULE
Encapsulator appends a CRC-32 to the transmitted SNDU. At the frames, the Encapsulator appends a CRC-32 to the transmitted SNDU.
Receiver, an appropriate LAN-FCS field will be appended to the At the Receiver, an appropriate LAN-FCS field will be appended to the
bridged frame prior to onward transmission on the Ethernet bridged frame prior to onward transmission on the Ethernet interface.
interface.
This design is readily implemented using existing network interface This design is readily implemented using existing network interface
cards, and does not introduce an efficiency cost by transmitting two cards and does not introduce an efficiency cost by
integrity check fields for bridged frames. However, it also calculating/verifying two integrity check fields for bridged frames.
introduces the possibility that a frame corrupted within the However, it also introduces the possibility that a frame corrupted
processing performed at an Encapsulator and/or Receiver may not be within the processing performed at an Encapsulator and/or Receiver
detected by the final recipient(s) (i.e. such corruption would not may not be detected by the final recipient(s) (i.e., such corruption
normally result in an invalid LAN FCS). would not 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
LEN field (specified in 16-bit words). The extension field is formed H-LEN field (specified in 16-bit words). The extension field is
of a group of one to five 16-bit fields. formed 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]
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
by adding a header and trailer to each PDU (section 4). It then 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 13).
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 (re)multiplexors before it is finally delivered to a Receiver
[RFCXARCHX]. [RFC4259].
+------+--------------------------------+------+ +------+--------------------------------+------+
| 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 |
| Header | Payload | | Header | Payload | | Header | Payload | | Header | Payload | | Header | Payload | | Header | Payload |
+--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+
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 that the SNDU starts immediately Pointer value of zero, indicating that the SNDU starts immediately
after the Payload Pointer in 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 TS Packet containing a fragment/complete SNDU sent
Channel. using the same TS Logical Channel.
An Encapsulator MAY decide not to immediately send another SNDU, An Encapsulator MAY decide not to send another SNDU immediately, even
even if space is available in a partially filled TS Packet. This 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 14). 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]
+-/------------+ +-/------------+
| SubNetwork | | SubNetwork |
| DU 1 | | DU 1 |
+-/------------+ +-/------------+
\ \ \ \
\ \ \ \
\ \ \ \
+--------+--------+--------+----------+ +--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused | |MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | 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 1, 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 2 | | DU 3 | | DU 2 | | DU 3 |
+-/----------------+ +----------------/-+ +-/----------------+ +----------------/-+
\ \ / /\ \ \ / /\
\ \ / / \ \ \ / / \
\ \ / / \. . . \ \ / / \. . .
+--------+--------+--------+----------+ +--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of | |MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 2 | SNDU 3 | | Header | Pointer| SNDU 2 | SNDU 3 |
+--------+--------+--------+----------+ +--------+--------+--------+----------+
PUSI=1 | ^ PUSI=1 | ^
| | | |
+--------------+ +--------------+
Figure 15: A TS Packet with the end of SNDU 2, followed by SNDU 3. 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 that the
of this new TS Packet to carry a PUSI value of 1, and a Payload header of this new TS Packet carry a PUSI value of 1 followed by a
Pointer value of 0x00.)
Expires July 2005 [page 22]
(ii) If the TS Packet carrying the final part of an SNDU has one
byte of unused payload, the Encapsulator MUST place the value 0xFF
in this final byte, and transmit the TS Packet. This rule provides a
simple mechanism to resolve the complex behaviour that may arise
when the TS Packet has no PUSI set. To send another SNDU in the
current TS Packet, would otherwise require the addition of a Payload
Pointer that would consume the last remaining byte of TS Packet
payload. The behaviour follows similar practice for other MPEG-2
payload types [ISO-DSMCC]. The Encapsulator MUST start transmission
of the 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 Pointer value of 0x00.) Payload Pointer value of 0x00.)
(iii) If the TS Packet carrying the final part of an SNDU has (ii) If the TS Packet carrying the final part of an SNDU has one byte
exactly two bytes of unused payload, and the PUSI was NOT already of unused payload, the Encapsulator MUST place the value 0xFF in this
set, the Encapsulator MUST place the value 0xFFFF in this final two final byte and transmit the TS Packet. This rule provides a simple
bytes, providing an End Indicator (section 4.3), and transmit the TS mechanism to resolve the complex behaviour that may arise when the TS
Packet. This rule prevents fragmentation of the SNDU Length Field Packet has no PUSI set. To send another SNDU in the current TS
over two TS Packets. The Encapsulator MUST start transmission of the Packet would otherwise require the addition of a Payload Pointer that
next SNDU in a new TS Packet. (The standard rules require the header would consume the last remaining byte of TS Packet payload. The
of this new TS Packet to carry a PUSI value of 1 and a Payload behaviour follows similar practice for other MPEG-2 payload types
[ISO-DSMCC]. The Encapsulator MUST start transmission of the 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 followed by a Payload
Pointer value of 0x00.)
(iii) If the TS Packet carrying the final part of an SNDU has exactly
two bytes of unused payload, and the PUSI was NOT already set, the
Encapsulator MUST place the value 0xFFFF in these final two bytes,
providing an End Indicator (section 4.3), and transmit the TS Packet.
This rule prevents fragmentation of the SNDU Length field over two TS
Packets. The Encapsulator MUST start transmission of the 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 followed by 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
then 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 that the header of this new TS
to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) Packet 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. When the next available byte of the current TS Packet payload. When the
Encapsulator packs further SNDUs into a TS Packet where the PUSI has Encapsulator packs further SNDUs into a TS Packet where the PUSI has
NOT already been set, the PUSI MUST be updated (set to 1) and an 8- NOT already been set, the PUSI MUST be updated (set to 1), and an
bit Payload Pointer MUST be inserted in the first byte directly 8-bit Payload Pointer MUST be inserted in the first byte directly
following the TS Packet header. The value of the Payload Pointer following the TS Packet header. (This reduces the size of the TS
MUST be set to the position of the byte following the end of the Packet payload field that is available for data by one byte.) The
first SNDU in the TS Packet payload. If no further PDUs are value of the Payload Pointer MUST be set to the position of the byte
available, an Encapsulator MAY wait for additional PDUs to fill the following the end of the first SNDU in the TS Packet payload. If no
incomplete TS Packet. The maximum period of time an Encapsulator can further PDUs are available, an Encapsulator MAY wait for additional
wait, known as the Packing Threshold, MUST be bounded and SHOULD be PDUs to fill the incomplete TS Packet. The maximum period of time an
configurable in the Encapsulator. If sufficient additional PDUs are Encapsulator can wait, known as the Packing Threshold, MUST be
NOT received to complete the TS Packet within the Packing Threshold, bounded and SHOULD be configurable in the Encapsulator. If
the Encapsulator MUST insert an End Indicator (using rule iv). sufficient additional PDUs are NOT received to complete the TS Packet
within the Packing Threshold, 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 may
may be determined on a per-session, per-packet, or per-SNDU basis. be determined on a per-session, per-packet, or per-SNDU basis.
Expires July 2005 [page 23]
When an SNDU is less than the size of a TS Packet payload, a TS When an SNDU is less than the size of a TS Packet payload, a TS
Packet may be formed that carries a PUSI value of one and also an Packet may be formed that carries a PUSI value of one and also an End
End Indicator (using rule iv). Indicator (using rule iv).
Expires July 2005 [page 24]
7. Receiver Processing 7. Receiver Processing
A Receiver tunes to a specific TS Multiplex and sets a receive A Receiver tunes to a specific TS Multiplex carrying a ULE Stream and
filter to accept all TS Packets with a specific PID. These TS sets a receive filter to accept all TS Packets with a specific PID.
Packets are associated with a specific TS Logical Channel and are These TS Packets are associated with a specific TS Logical Channel
reassembled to form a stream of SNDUs. A single Receiver may be and are reassembled to form a stream of SNDUs. A single Receiver may
able to receive multiple TS Logical Channels, possibly using a range be able to receive multiple TS Logical Channels, possibly using a
of TS Multiplexes. In each case, reassembly MUST be performed range of TS Multiplexes. In each case, reassembly MUST be performed
independently for each TS Logical Channel. To perform this independently for each TS Logical Channel. To perform this
reassembly, the Receiver may use a buffer to hold the partially reassembly, the Receiver may use a buffer to hold the partially
assembled SNDU, referred to here as the Current SNDU buffer. Other assembled SNDU, referred to here as the Current SNDU buffer. Other
implementations may choose to use other data structures, but MUST implementations may choose to use other data structures, but MUST
provide equivalent operations. provide equivalent operations.
Receipt of a TS Packet with a PUSI value of 1 indicates that the TS Receipt of a TS Packet with a PUSI value of 1 indicates that the TS
Packet contains the start of a new SNDU. It also indicates the Packet contains the start of a new SNDU. It also indicates the
presence of the Payload Pointer (indicating the number of bytes to presence of the Payload Pointer (indicating the number of bytes to
the start of the first SNDU in the TS-Packet currently being the start of the first SNDU in the TS-Packet currently being
reassembled). It is illegal to receive a Payload Pointer value reassembled). It is illegal to receive a Payload Pointer value
greater than 181, and this MUST cause the SNDU reassembly to be greater than 181, and this MUST cause the SNDU reassembly to be
aborted and the Receiver to enter the Idle State. This event SHOULD aborted and the Receiver to enter the Idle State. This event SHOULD
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
with or without a Destination Address Field (i.e. D=0 and D=1). 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 or errors, or on receipt of an End Indicator,
Receiver enters the Idle State. In this state, the Receiver discards the Receiver enters the Idle State. In this state, the Receiver
all TS Packets until it discovers the start of a new SNDU, upon discards all TS Packets until it discovers the start of a new SNDU,
which it then enters the Reassembly State. Figure 16 outlines these upon which it then enters the Reassembly State. Figure 16 outlines
state transitions: these state transitions:
+-------+ +-------+
| START | | START |
+---+---+ +---+---+
| |
\/ \/
+----------+ +----------+
\| Idle |/ \| Idle |/
+-------/| State |\-------+ +-------/| State |\-------+
Insufficient | +----+-----+ | Insufficient | +----+-----+ |
unused space | | PUSI set | MPEG-2 TS Error unused space | | PUSI set | MPEG-2 TS Error
or | \/ | or or | \/ | or
End Indicator| +----------+ | SNDU Error End Indicator| +----------+ | SNDU Error
| |Reassembly| | | |Reassembly| |
+--------| State |--------+ +--------| State |--------+
+----------+ +----------+
Figure 16: Receiver state transitions Figure 16: Receiver state transitions
Expires July 2005 [page 25] 7.1.1. Idle State Payload Pointer Checking
7.1.1 Idle State Payload Pointer Checking
A Receiver in the Idle State MUST check the PUSI value in the header A Receiver in the Idle State MUST check the PUSI value in the header
of all received TS Packets. A PUSI value of 1 indicates the presence of all received TS Packets. A PUSI value of 1 indicates the presence
of a Payload Pointer. Following a loss of synchronisation, values of a Payload Pointer. Following a loss of synchronisation, values
between 0 and 181 are permitted, in which case the Receiver MUST between 0 and 181 are permitted, in which case the Receiver MUST
discard the number of bytes indicated by the Payload Pointer discard the number of bytes indicated by the Payload Pointer (counted
(counted from the first byte of the TS Packet payload field, and from the first byte of the TS Packet payload field, and excluding the
excluding the PP field itself), before leaving the Idle State. It PP field itself), before leaving the Idle State. It then enters the
then enters the Reassembly State, and starts reassembly of a new Reassembly State, and starts reassembly of a new SNDU at this point.
SNDU at this point.
7.2 Processing of a Received SNDU 7.2. Processing of a Received SNDU
When in the Reassembly State, the Receiver reads a 2 byte SNDU When in the Reassembly State, the Receiver reads a 2-byte SNDU Length
Length Field from the TS Packet payload. If the value is less than field from the TS Packet payload. If the value is less than or equal
or equal to 4, or equal to 0xFFFF, the Receiver discards the Current to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and
SNDU and the remaining TS Packet payload and returns to the Idle the remaining TS Packet payload and returns to the Idle State.
State. Receipt of an invalid Length Field is an error event and Receipt of an invalid Length field is an error event and SHOULD be
SHOULD be recorded as an SNDU length error. recorded as an SNDU length error.
If the Length of the Current SNDU is greater than 4, the Receiver If the Length of the Current SNDU is greater than 4, the Receiver
accepts bytes from the TS Packet payload to the Current SNDU buffer accepts bytes from the TS Packet payload to the Current SNDU buffer
until either Length bytes in total are received, or the end of the until either Length bytes in total are received, or the end of the TS
TS Packet is reached (see also 7.2.1). When Current SNDU length Packet is reached (see also 7.2.1). When the Current SNDU length
equals the value of the Length Field, the Receiver MUST calculate equals the value of the Length field, the Receiver MUST calculate and
and verify the CRC value (see 4.6). SNDUs that contain an invalid verify the CRC value (see 4.6). SNDUs that contain an invalid CRC
CRC value MUST be discarded. Mismatch of the CRC is an error event value MUST be discarded. Mismatch of the CRC is an error event and
and SHOULD be recorded as a CRC error. The under-lying physical- SHOULD be recorded as a CRC error. The underlying physical-layer
layer processing (e.g. forward error correction coding) often processing (e.g., forward error correction coding) often results in
results in patterns of errors, rather than single bit errors, so the patterns of errors, rather than single bit errors, so the Receiver
Receiver needs to be robust to arbitrary patterns of corruption to needs to be robust to arbitrary patterns of corruption to the TS
the TS Packet and payload, including potential corruption of the Packet and payload, including potential corruption of the PUSI, PP,
PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD and SNDU Length fields. Therefore, a Receiver SHOULD discard the
discard the remaining TS Packet payload (if any) following a CRC remaining TS Packet payload (if any) following a CRC mismatch and
mismatch and return to the Idle State. return to the Idle State.
When the Destination Address is present (D=0), the Receiver accepts When the Destination Address is present (D=0), the Receiver accepts
SNDUs that match one of a set of addresses specified by the Receiver SNDUs that match one of a set of addresses specified by the Receiver
(this includes the NPA address of the Receiver, the NPA broadcast (this includes the NPA address of the Receiver, the NPA broadcast
address and any required multicast NPA addresses). The Receiver MUST address, and any required multicast NPA addresses). The Receiver
silently discard an SNDU with an unmatched address. MUST silently discard an SNDU with an unmatched address.
After receiving a valid SNDU, the Receiver MUST check the Type Field After receiving a valid SNDU, the Receiver MUST check the Type field
(and process any Type 1 Extension Headers). The SNDU payload is then (and process any Type 1 Extension Headers). The SNDU payload is then
passed to the next protocol layer specified. An SNDU with an unknown passed to the next protocol layer specified. An SNDU with an unknown
Type value < 1536 MUST be discarded. This error event SHOULD be Type value < 1536 MUST be discarded. This error event SHOULD be
recorded as an SNDU type error. recorded as an SNDU type error.
Expires July 2005 [page 26]
The Receiver then starts reassembly of the next SNDU. This MAY The Receiver then starts reassembly of the next SNDU. This MAY
directly follow the previously reassembled SNDU within the TS Packet directly follow the previously reassembled SNDU within the TS Packet
payload. payload.
(i) If the Current SNDU finishes at the end of a TS Packet payload, (i) If the Current SNDU finishes at the end of a TS Packet payload,
the Receiver MUST enter the Idle State. the Receiver MUST enter the Idle State.
(ii) If only one byte remains unprocessed in the TS Packet payload (ii) If only one byte remains unprocessed in the TS Packet payload
after completion of the Current SNDU, the Receiver MUST discard this after completion of the Current SNDU, the Receiver MUST discard this
final byte of TS Packet payload. It then enters the Idle State. It final byte of TS Packet payload. It then enters the Idle State. It
MUST NOT record an error when the value of the remaining byte is MUST NOT record an error when the value of the remaining byte is
identical to 0xFF. identical to 0xFF.
(iii) If two or more bytes of TS Packet payload data remain after (iii) If two or more bytes of TS Packet payload data remain after
completion of the Current SNDU, the Receiver accepts the next 2 completion of the Current SNDU, the Receiver accepts the next 2 bytes
bytes and examines if this is an End Indicator. When an End and examines whether this is an End Indicator. When an End Indicator
Indicator is received, a Receiver MUST silently discard the is received, a Receiver MUST silently discard the remainder of the TS
remainder of the TS Packet payload and transition to the Idle State. Packet payload and transition to the Idle State. Otherwise, this is
Otherwise this is the start of the next Packed SNDU and the Receiver the start of the next Packed SNDU, and the Receiver continues by
continues by processing this SNDU (provided that the TS Packet has a processing this SNDU. (This is 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.)
7.2.1 Reassembly Payload Pointer Checking 7.2.1. Reassembly Payload Pointer Checking
A Receiver that has partially received an SNDU (in the Current SNDU A Receiver that has partially received an SNDU (in the Current SNDU
buffer) MUST check the PUSI value in the header of all subsequent TS buffer) MUST check the PUSI value in the header of all subsequent TS
Packets with the same PID (i.e. same TS Logical Channel). If it Packets with the same PID (i.e., same TS Logical Channel). If it
receives a TS Packet with a PUSI value of 1, it MUST then verify the receives a TS Packet with a PUSI value of 1, it MUST then verify the
Payload Pointer. If the Payload Pointer does NOT equal the number of Payload Pointer. If the Payload Pointer does NOT equal the number of
bytes remaining to complete the Current SNDU, i.e., the difference bytes remaining to complete the Current SNDU (i.e., the difference
between the SNDU Length field and the number of reassembled bytes, between the SNDU Length field and the number of reassembled bytes),
the Receiver has detected a delimiting error. the Receiver has detected a delimiting error.
Following a delimiting error, the Receiver MUST discard the Following a delimiting error, the Receiver MUST discard the partially
partially assembled SNDU (in the Current SNDU buffer), and SHOULD assembled SNDU (in the Current SNDU buffer) and SHOULD record a
record a reassembly error. It MUST then re-enter the Idle State. reassembly error. It MUST then re-enter the Idle State.
7.3 Other Error Conditions 7.3. Other Error Conditions
The Receiver SHOULD check the MPEG-2 Transport Error Indicator The Receiver SHOULD check the MPEG-2 Transport Error Indicator
carried in the TS Packet header [ISO-MPEG2]. This flag indicates a carried in the TS Packet header [ISO-MPEG2]. This flag indicates a
transmission error for a TS Logical Channel. If the flag is set to a transmission error for a TS Logical Channel. If the flag is set to a
value of one, a transmission error event SHOULD be recorded. Any value of one, a transmission error event SHOULD be recorded. Any
partially received SNDU MUST be discarded. The Receiver then enters partially received SNDU MUST be discarded. The Receiver then enters
the Idle State. the Idle State.
The Receiver MUST check the MPEG-2 Continuity Counter carried in the The Receiver MUST check the MPEG-2 Continuity Counter carried in the
TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets
within the same TS Logical Channel carry the same Continuity Counter within the same TS Logical Channel carry the same Continuity Counter
Expires July 2005 [page 27]
value, the duplicate TS Packets MUST be silently discarded. If the value, the duplicate TS Packets MUST be silently discarded. If the
received value is NOT identical to that in the previous TS Packet, received value is NOT identical to that in the previous TS Packet,
and it does NOT increment by one for successive TS Packets (modulo and it does NOT increment by one for successive TS Packets (modulo
16), the Receiver has detected a continuity error. Any partially 16), the Receiver has detected a continuity error. Any partially
received SNDU MUST be discarded. A continuity counter error event received SNDU MUST be discarded. A continuity counter error event
SHOULD be recorded. The Receiver then enters the Idle State. SHOULD be recorded. The Receiver then enters the Idle State.
Note that an MPEG2-2 Transmission network is permitted to carry Note that an MPEG2-2 Transmission network is permitted to carry
duplicate TS Packets [ISO-MPEG2], which are normally detected by the duplicate TS Packets [ISO-MPEG2], which are normally detected by the
MPEG-2 Continuity Counter. A Receiver that does not perform the MPEG-2 Continuity Counter. A Receiver that does not perform the
above Continuity Counter check, would accept duplicate copies of TS above Continuity Counter check would accept duplicate copies of TS
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]
8. Summary 8. Summary
This document defines a Unidirectional Lightweight Encapsulation This document defines a Unidirectional Lightweight Encapsulation
(ULE) that performs efficient and flexible support for IPv4 and IPv6 (ULE) that performs efficient and flexible support for IPv4 and IPv6
network services over networks built upon the MPEG-2 Transport network services over networks built upon the MPEG-2 Transport Stream
Stream (TS). The encapsulation is also suited to transport of other (TS). The encapsulation is also suited to transport of other
protocol 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 Receivers that do not implement
implement them, or choose not to process them. them, or choose not to process them.
9. Acknowledgments
This draft is based on a previous draft authored by: Horst D. 9. Acknowledgements
Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry
Fairhurst. The authors wish to thank the members of the ip-dvb
mailing list for their input provided. In particular, the many
comments received from Art Allison, Carstsen Borman, Patrick
Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and William
Stanislaus. Alain also provided the original examples of usage.
Expires July 2005 [page 29] This document is based on a previous document authored by: Horst D.
Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Fairhurst.
The authors wish to thank the members of the ip-dvb mailing list for
their input; in particular, the many comments received from Art
Allison, Carstsen Borman, Patrick Cipiere, Wolgang Fritsche, Hilmar
Linder, Alain Ritoux, and William Stanislaus. Alain also provided
the original examples of usage.
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.
There is a known security issue with un-initialised stuffing bytes. There is a known security issue with un-initialised stuffing bytes.
In ULE, these bytes are set to 0xFF (normal practice in MPEG-2). In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
There are known integrity issues with the removal of the LAN FCS in There are known integrity issues with the removal of the LAN FCS in a
a bridged networking environment. The removal for bridged frames bridged networking environment. The removal for bridged frames
exposes the traffic to potentially undetected corruption while being exposes the traffic to potentially undetected corruption while being
processed by the Encapsulator and/or Receiver. processed by the Encapsulator and/or Receiver.
There is a potential security issue when a Receiver receives a PDU There is a potential security issue 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. 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 In the future, a ULE Mandatory Extension Header may be used to define
method to perform link encryption of the SNDU payload. This is as an a method to perform link encryption of the SNDU payload. This is as
additional security mechanism to IP, transport or application layer an additional security mechanism to IP-, transport-, or application-
security - not a replacement [RFCXARCHX]. The approach is generic layer security, not a replacement [RFC4259]. The approach is generic
and decouples the encapsulation from future security extensions. The and decouples the encapsulation from future security extensions. The
operation provides functions that resemble those currently used with operation provides functions that resemble those 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 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 or
some/all of the SNDU headers. The method of encryption and the way all of the SNDU headers. The method of encryption and the way in
in which keys are exchanged is beyond the scope of this which keys are exchanged is beyond the scope of this specification,
specification, as also are the definition of the SA format and that as are the definition of the SA format and that of the related
of the related encryption keys. encryption keys.
Expires July 2005 [page 30]
11. References
11.1 Normative References
[ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic
coding of moving pictures and associated audio information -- Part
1: Systems", International Standards Organisation (ISO), 2000.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
11.2 Informative References
[ID-ipdvb-ar] Fairhurst, G., M-J. Montpetit, "Address Resolution for
IP datagrams over MPEG-2 Networks", Internet Draft, Work in
Progress.
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53 Rev.C, 2004
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC), Doc. A/91, 2001.
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
1995.
[ATSC-PSIP-TC] A/65B Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65B, 2003.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 1999.
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet
Local Area Network Specification" Version 2.0, November 1982.
[ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI), 2004.
Expires July 2005 [page 31] 11. IANA Considerations
[ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV)",
European Telecommunications Standards Institute (ETSI), 1998.
[ETSI-DVBS] EN 300 421 "Digital Video Broadcasting (DVB); Modulation The IANA has created the ULE Next-Header Type field registry as
and Coding for DBS satellite systems at 11/12 GHz", European defined in this document.
Telecommunications Standards Institute (ETSI), 1997.
[ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing ULE Next-Header registry
structure, channel coding and modulation for digital terrestrial
television (DVB-T)", European Telecommunications Standards Institute
(ETSI), 2004.
[ETSI-RCS] ETSI 301 790 "Digital Video Broadcasting (DVB); This registry allocates Next-Header values within the range 0-511
Interaction Channel for Satellite Distribution Systems", European (decimal). For each allocated value, it also specifies the set of
Telecommunications Standards Institute (ETSI), 2005. 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.4.1).
[IEEE-802.2] IEEE 802.2, "Local and metropolitan area networks- 11.1. IANA Guidelines
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- The following contains the IANA guidelines for management of the ULE
Specific requirements Part 3: Carrier sense multiple access with Next-Header registry. This registry allocates values 0-511 decimal
collission detection (CSMA/CD) access method and physical layer (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater
specifications", IEEE Computer Society, (also ISO/IEC 8802-3), 2002. than 0x01FF (decimal).
[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic It subdivides the Next-Header registry in the following way:
coding of moving pictures and associated audio information -- Part
6: Extensions for DSM-CC", International Standards Organisation
(ISO), 1998.
[ITU-H222] H.222.0 "Information technology - Generic coding of 1) 0-255 (decimal) IANA-assigned values, indicating Mandatory
moving pictures and associated audio information: Systems", Extension Headers (or link-dependent Type fields) for ULE,
International Telecommunication Union, (ITU-T), 1995. requiring expert review leading to prior issue of an IETF RFC.
This specification MUST define the value and the name associated
with the Extension Header, together with the procedure for
processing the Extension Header. It MUST also define the need for
the Mandatory Extension and the intended use. The size of the
Extension Header MUST be specified.
[ITU-3563] I.363.5 "B-ISDN ATM Adaptation Layer specification: Type Assignments have been made in this document, and registered by
5 AAL", International Telecommunication Union, (ITU-T), 1996. IANA:
[ISO-8802-2] ISO/IEC 8802.2 "Logical Link Control", International Type Name Reference
Standards Organisation (ISO), 1998.
[RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 0: Test-SNDU Section 5.1
Layer Tunneling Mechanism for Unidirectional Links", RFC3077, 1: Bridged-SNDU Section 5.2
Proposed Standard, 2001.
[RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control 2) 256-511 (decimal) IANA-assigned values, indicating Optional
Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed Extension Headers for ULE, requiring expert review leading to
Standard, 2001. prior issue of an IETF RFC. This specification MUST define the
value and the name associated with the Extension Header, together
with the procedure for processing the Extension Header. The entry
MUST specify the range of allowable H-LEN values that are
permitted (in the range 1-5). It MUST also define the need for
the Optional Extension and the intended use.
XXX RFC Editor - please replace the next reference and all citations Assignments have been made in this document, and registered by
with the appropriate RFC number. The I-D referenced is currently IANA:
ahead in the RFC-ED queue.
XXX
Expires July 2005 [page 32] Type Name H-LEN Reference
[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, 256: Extension-Padding 1-5 Section 5.3
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. References
12. Authors' Addresses 12.1. Normative References
Godred Fairhurst [ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding
Department of Engineering of moving pictures and associated audio information --
University of Aberdeen Part 1: Systems", International Standards Organisation
Aberdeen, AB24 3UE (ISO), 2000.
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Department of Scientific Computing Requirement Levels", BCP 14, RFC 2119, 1997.
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
Email: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/
Expires July 2005 [page 34] [RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
13. IPR Notices [RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
13.1 Intellectual Property Statement [ULE1] Registration for format_identifier ULE1, SMPTE
Registration Authority, LLC,
http://www.smpte-ra.org/ule1.html.
The IETF takes no position regarding the validity or scope of any 12.2. Informative References
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any [IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
assurances of licenses to be made available, or the result of an for IP datagrams over MPEG-2 Networks", Work in
attempt made to obtain a general license or permission for the use Progress, September 2005.
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any [ATSC] A/53, "ATSC Digital Television Standard", Advanced
copyrights, patents or patent applications, or other proprietary Television Systems Committee (ATSC), Doc. A/53 Rev.C,
rights that may cover technology that may be required to implement 2004
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13.2 Disclaimer of Validity [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
This document and the information contained herein are provided on [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE for the ATSC Data Broadcast Standard", Advanced
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE Television Systems Committee (ATSC), Doc. A/91, 2001.
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Copyright Statement [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee
(ATSC), Doc. A/54, 1995.
Copyright (C) The Internet Society (2005). [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television
Systems Committee (ATSC), Doc. A/65B, 2003.
This document is subject to the rights, licenses and restrictions [ATSC-REG] ATSC "Code Point Registry"
contained in BCP 78, and except as set forth therein, the authors www.atsc.org/standards/Code_Point_Registry.pdf.
retain all their rights.
Expires July 2005 [page 35] [ATSC-S] A/80, "Modulation and Coding Requirements for Digital
TV (DTV) Applications over Satellite", Advanced
Television Systems Committee (ATSC), Doc. A/80, 1999.
15. IANA Considerations [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp,
"Ethernet Local Area Network Specification" Version
2.0, November 1982.
This document will require IANA involvement. The ULE Next-Header [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
type field defined in this document requires creation of a registry: European Telecommunications Standards Institute
(ETSI), 2004.
ULE Next-Header registry [ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI), 1998.
This registry allocates Next-Header values within the range 0-511 [ETSI-DVBS] EN 300 421, "Digital Video Broadcasting (DVB);
(decimal). For each allocated value, it also specifies the set of Modulation and Coding for DBS satellite systems at
allowed H-LEN values (see section 5). In combination, these define a 11/12 GHz", European Telecommunications Standards
set of allowed values in the range 0-1535 for the first part of the Institute (ETSI), 1997.
ULE Type space (see section 4.1).
15.1 IANA Guidelines [ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T)", European
Telecommunications Standards Institute (ETSI), 2004.
The following contains the IANA guidelines for management of the ULE [ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB);
Next-Header registry. This registry allocates values 0-511 decimal Interaction Channel for Satellite Distribution
(0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater Systems", European Telecommunications Standards
than 0x01FF (decimal). Institute (ETSI), 2005.
It subdivides the Next-Header registry in the following way: [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.
1) 0-255 (decimal) IANA assigned values, indicating Mandatory [IEEE-802.3] IEEE 802.3, "Local and metropolitan area networks-
Extension Headers (or link-dependent type fields) for ULE, Specific requirements Part 3: Carrier sense multiple
requiring expert review leading to prior issue of an IETF RFC. access with collision detection (CSMA/CD) access
This specification MUST define the value, and the name associated method and physical layer specifications", IEEE
with the Extension Header, together with the procedure for Computer Society, (also ISO/IEC 8802-3), 2002.
processing the Extension Header. It MUST also define the need for
the Mandatory Extension and the intended use. The size of the
Extension Header MUST be specified.
Assignments made in this document: [ISO-DSMCC] IS 13818-6, "Information technology -- Generic coding
of moving pictures and associated audio information --
Part 6: Extensions for DSM-CC", International
Standards Organisation (ISO), 1998.
Type Name Reference [ITU-H222] H.222.0, "Information technology - Generic coding of
moving pictures and associated audio information:
Systems", International Telecommunication Union,
(ITU-T), 1995.
0: Test-SNDU Section 4.7.4. [ITU-3563] I.363.5, "B-ISDN ATM Adaptation Layer specification:
1: Bridged-SNDU Section 4.7.5. Type 5 AAL", International Telecommunication Union,
(ITU-T), 1996.
2) 256-511 (decimal) IANA assigned values, indicating Optional [ISO-8802-2] ISO/IEC 8802.2, "Logical Link Control", International
Extension Headers for ULE, requiring expert review leading to Standards Organisation (ISO), 1998.
prior issue of an IETF RFC. This specification MUST define the
value, and the name associated with the Extension Header, together
with the procedure for processing the Extension Header. The entry
MUST specify the range of allowable H-LEN values that are
permitted (in the range 1-5). It MUST also define the need for the
Optional Extension and the intended use.
Assignments made in this document: [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
Type Name H-LEN Reference [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC
3309, September 2002.
256: Extension-Padding 1-5 Section 5. [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H.,
Collini-Nocker, B., and H. Linder, "A Framework for
Transmission of IP Datagrams over MPEG-2 Networks",
RFC 4259, November 2005.
Expires July 2005 [page 36] [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.
ANNEX A: Informative Appendix - SNDU Packing Examples Appendix A: 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
the body of this document. the body of this document.
skipping to change at line 1687 skipping to change at page 36, line 4
+-----+----*-+------+- -+------+-*----+------+- -+------+ +-----+----*-+------+- -+------+-*----+------+- -+------+
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 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
PP=0 Length CRC for A PP=0 Length CRC for A
+-----+------+------+------+- -+------+ +-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0x63 | ... | A182 | | HDR | 0x00 | 0x00 | 0xB3 | ... | A182 |
+-----+----*-+-*----+------+- -+------+ +-----+----*-+-*----+------+- -+------+
PUSI=1 * * PUSI=1 * *
***** *****
SNDU Unused SNDU Unused
PP=0 Length CRC for B byte PP=0 Length CRC for B byte
+-----+------+------+------+- -+------+------+ +-----+------+------+------+- -+------+------+
| HDR | 0x00 | 0x00 | 0x62 | ... | B181 | 0xFF | | HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
+-----+---*--+-*----+------+- -+------+------+ +-----+---*--+-*----+------+- -+------+------+
PUSI=1 * * PUSI=1 * *
****** ******
SNDU SNDU SNDU SNDU
PP=0 Length CRC for C Length PP=0 Length CRC for C Length
+-----+------+------+------+- -+------+------+------+ +-----+------+------+------+- -+------+------+------+
| HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | | HDR | 0x00 | 0x00 | 0xB1 | ... | 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 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 1770 skipping to change at page 38, line 4
| HDR | B002 | ... | B185 | | HDR | B002 | ... | B185 |
+-----+------+- -+------+ +-----+------+- -+------+
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
Example A.4: Illustration of SNDU Length field
Expires July 2005 [page 39]
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 1811 skipping to change at page 39, line 4
+ -+------+------+------+ -+------+------+------+- -+------+ + -+------+------+------+ -+------+------+------+- -+------+
+ ... | 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 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
SNDU B is 52 bytes (no ULE destination NPA address) bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE
SNDU C is 52 bytes (no ULE destination NPA address) destination NPA address)
The sequence comprises 1 TS Packet: The sequence comprises 1 TS Packet:
SNDU SNDU
PP=0 Length PP=0 Length
+-----+------+------+------+- -+-----+------+-----+- -+-----+- +-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | .. | HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- +-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * * PUSI=1 * *
***** *****
End Stuffing End Stuffing
Indicator bytes Indicator bytes
-----+------+- -+-----+---------+- -+------+ -----+------+- -+-----+---------+- -+------+
... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | ... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |
-*---+------+- -+-----+---------+- -+------+ -----+------+- -+-----+---------+- -+------+
Expires July 2005 [page 41] Appendix B: 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 : 0x7c171763 ULE CRC32 : 0x7c171763
skipping to change at line 1858 skipping to change at page 41, line 5
Destination IPv6 : 2001:DB8:2509:1962::2 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 0d b8 30 08 19 65 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 01 20 01 0d b8 25 09 19 62 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 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c 0048: 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c
0064: 17 17 63 0064: 17 17 63
Expires July 2005 [page 42] Authors' Addresses
[RFC EDITOR NOTE:
This section must be deleted prior to publication]
DOCUMENT HISTORY
Draft 00
This draft is intended as a study item for proposed future work by
the IETF in this area. Comments relating to this document will be
gratefully received by the author(s) and the ip-dvb mailing list at:
ip-dvb@erg.abdn.ac.uk
--------------------------------------------------------------------
DRAFT 01 (Protocol update)
* Padding sequence modified to 0xFFFF, this change aligns with other
usage by MPEG-2 streams. Treatment remains the same as specified for
ULE.
* SDNU Format updated to include R-bit (reserved).
* Updated procedure for TS Packet carrying the final part of an SNDU
with either less than two bytes of unused payload updated.
* A Receiver MUST silently discard the remainder of a TS Packet
payload when two or less bytes remain unprocessed following the end
of an SNDU, irrespective of the PUSI value in the received TS
Packet. It MUST NOT record an error when the value of the remaining
byte(s) is identical to 0xFF or 0xFFFF. The Receiver MUST then wait
for a TS Packet with a PUSI value set to 1.
* Payload Pointer description updated.
* CRC Calculation added.
* Decapsulator processing revised.
* Type field split into two.
* References updated.
* Security considerations added (first draft).
* Appendix added with examples.
--------------------------------------------------------------------
Expires July 2005 [page 43]
DRAFT - 02 (Improvement of clarity)
* Corrected CRC-32 to follow standard practice in DSM-CC.
* Removed LLC frame type, now redundant by Bridge-Type (==1)
* Defined D-bit to use the reserved bit field (R ) - Gorry, Alain,
Bernhard
* Changes to description of minimum payload length. Gorry
* MPEG-2 Error Indicator SHOULD be used.Hilmar & Gorry
* MPEG-2 CC MAY be used (since CRC-32 is strong anyway). Hilmar &
Gorry
* Corrected CRC-32 to now follow standard practice in DSM-CC. Gorry,
Hilmar, Alain.
* Changed description of Encapsulator action for Packing. Gorry &
Hilmar.
* Changed description of Receiver to clarify packing. Gorry & Alain.
* Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG.
Hilmar/Bernhard.
* Recommend removal of section on Flushing bit stream. Gorry
* Updated SNDU figures to reflect D-bit and correct a mistake in the
bridged type field. Alain
* Reorganised section 5 to form sections 5 and 6, separating
encapsulation and receiver processing. Gorry, Hilmar, Alain.
* Added concept of Idle State and Reassembly State to the Receiver.
Renumbered sections 5,6 and following. Gorry.
* Nits from Alain, Hilmar and Gorry.
Moved security issue on the design of the protocol to appropriate
sections, since this is not a concern for deployment: Length field
usage and padding initialisation.
* Changed wording: All multi-byte values in ULE (including Length,
Type, and Destination fields) are transmitted in network byte order
(most significant byte first). old NiT from Alain, now fixed.
* Frame byte size in diagrams now updated to -standard- format, and
D bit action corrected, as requested by Alain.
Expires July 2005 [page 44]
* Frame format diagrams, redrawn to 32-bit format below:
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
* Additional diagram requested by Alain for D=0 bridging (added, and
subsequent figures renumbered).
* Diagrams of encapsulation process, redrawn for clarity (no change
to meaning). Gorry.
* Reworded last para of CRC description.
* Clarification to the statements in the CRC coverage - to make it
clear that it is the entire SNDU (header AND payload) that is
checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at).
* References added for RCS (spotted by Alain) and AAL5 (provided by
Anthony Ang).
* Removed informative reference to MPEG part 1.Alain.
Spelling correction -> Allain to Alain.
* Added description of Receiver processing of the address
field.Gorry
* Added caution on LLC Length in bridged Packets thanks.
Gorry/wolfgang
* Removed Authors notes from text after their discussion on the list
Gorry
* Corrected text to now say maximum value of PP = 182 in ULE. Gorry
* Tidied diagrams at end (again) - Gorry,
Revision with following changes:
* Re issue as working group draft (filename change)
* Refinement of the text on CRC generation to be unambiguous.
* Revised CC processing at Encapsulator (B C-N/GF/A.Allison)
* Revised CC processing at Receiver (from List: A.Allison; et al )
* Corrections to length/PP field in Examples (M Sooriyabandara,
Alain)
* Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit)
* Section 4.5 only SHARED routed links require D=0
* Packing Threshold defined
* Next-Layer-Header defined (Now called Next-Header)
* Addition of Appendix B (to aide verification of SNDFU format)
Expires July 2005 [page 45]
Working Group ID rev 01
Issues addressed:
* Typographical
* Types > 1500 should be passed to the next higher protocol (Hilmar)
* The second part of the Type space corresponds to the values 1500
COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF.
* IANA has already defined IP and IPv6 types - corrected text!
Added more security considerations (-01d).
* Should we allow an Adaptation Field within ULE (request for DVB-
RCS compatibility)? Requirement to be clarified! Implementation
impact to be evaluated!
Current Recommendation: The current spec does not preclude use of
AF, it simply says that this is not the standard for ULE. The use
case and requirement for this mode are not currently clear, based on
this there is no current intention to add this to ULE - text for
requirements would be welcome.
* Verify the minimum value allocated to DIX Ethernet Header Types.
Draft updated to align with IEEE Registry assignments.
--------------------------------------------------------------------
Working Group ID rev 02
Revised IPR disclosure
Revised copyright notice
Section 5 added to ULE to define optional Extension Headers (see
xule)
Correction of figure numbering.
Correction to capitalisation in Transport Stream definition of fields
Inserted space character after 1536 in line 2 of 4.4.2
Replaced } with ] after ISO-DSMCC
Replace reference to section 6.3 with section 7.3 at end of section
4.6.
Reference in 4.7.4 was changed to refer to figure 7 (not 6).
Note added after figure 9.
Expires July 2005 [page 46]
Working Group ID rev 03
Changes with this revision of the document:
(i) The worked hexadecimal example in the annexe was reworked to
include a valid MAC address for an IPv6 unicast packet. -
(BCN)
(ii) The IANA procedures revised, based on inputs from IANA to
improve consistency of the term Next-Header and to add the
HLEN field to the IANA registry record for OPTIONAL headers.
(GF)
(iii) 7.2 Change to revert wording in the second para to MUST enter
IDLE after CRC failure of SNDU check.
(iv) In normal operation, it is expected that any padding appended
to a bridged Ethernet frame SHOULD be removed prior to
forwarding. This requires the sender to be aware of such
Ethernet padding (e.g. LLC). (Made this a SHOULD). (GF)
NiTS:
(v) Format of page Breaks was updated. (GF)
(vi) Check for <- -> sequences of characters. (GF)
(vii) Update refs to add RFC3667 / 3668. (GF)
(viii) Changed text defining M in DSMCC definition to the word Media
(ix) 7.1.1 Range of PP values corrected to 0-181.
(x) Definition of END INDICATOR corrected in section 2 - this is
not a TYPE value, but a LENGTH value.
(xi) Next-Header used throughout the document to replace
next-layer-header, and various other forms of wording.
(xii) In section 7.2, added a ref the section on PP checking
Working Group ID rev 04
This rev followed WGLC comments, which are defined in the ipdvb
mailing list. Important changes included:
(i) This text was moved to an appendix
(ii) ToC was updated and section headers made consistent
(iii) Revised definition text
(iv) Improved clarity with respect to terms defined in ISO 13818-1
(v) Bridging and Extension-Padding formats move to section 5
(vi) Clarification of the NPA in packet headers
(vii) Clarification of placement of NPA address with extension
headers.
Issues address in rev-05:
These revisions were made following a second WGLC and invited cross-
area IETF review of the Spec.
NiTS corrected:
Expires July 2005 [page 47]
Abstract shortened.
Added separate references to Ethernet v2; LLC; and 802.3
Added RFC2119 Boilerplate for definitions of capitilised words.
Corrected English and 63 typos
Specified explicitly that Test & Bridge Extension Headers must be
the last in the extension chain (no other headers may follow)
7.1.1. para 1 - changed PP processing description to specify where
to count the number of bytes that were pointed to
Corrected the range 0-512 in the IANA Guidelines (should be 0-511).
Fixed NPA to consistently refer to the ULE destination address.
Specific Issues:
1) The reviewer suggested the title was confusing. A proposed new
Title is:
Ultra Lightweight Encapsulation (ULE) for transmission of
IP datagrams over an MPEG-2 Transport Stream
2) The reviewer suggested that the name of the D field was changed,
to make the meaning more obvious. The new name is Destination
Address Absent field, rather than the Destination Address Present
field. The semantics of the D-bit do not change.
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.
4) The reviewer mentioned that we had NOT defined the values needed Godred Fairhurst
for mapping addresses... I'm not sure this was an over-sight, but Department of Engineering
This was an oversight, the new text was added to the end of the University of Aberdeen
description in section 4.5. Also added references to [RFC1112] Aberdeen, AB24 3UE
[RFC2464]. UK
5) Added text on the need for data descriptors. EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry
6) Removed reference to RFC3819 which was either ambiguous in the Bernhard Collini-Nocker
definition of SNDU. Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
7) In final clause of 7.2 (Receiver processing) the last sentence EMail: bnocker@cosy.sbg.ac.at
was extended by a bracketed clause to deal with the case when there Web: http://www.scicomp.sbg.ac.at/
was excess data and no PUSI set).
(iii) If two or more bytes of TS Packet payload data remain after Full Copyright Statement
completion of the Current SNDU, the Receiver accepts the next 2
bytes and examines if this is an End Indicator. When an End
Indicator is received, a Receiver MUST silently discard the
remainder of the TS Packet payload and transition to the Idle State.
Otherwise this is the start of the next Packed SNDU and the Receiver
continues by processing this SNDU (provided that the TS Packet has 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
Packet payload and transitions to the Idle State).
Expires July 2005 [page 48] Copyright (C) The Internet Society (2005).
8) Revised IANA procedures to REQUIRE a definition of the PROCEDURE
when defining an extension header.
IESG Review Rev -06. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This rev was generated in response to issues raised during AD and This document and the information contained herein are provided on an
IESG review. The changes provide clarifications and corrections, but "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
do not modify the protocol behaviour. OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Comments from Brian Carpenter; Margaret Wasserman; GenART review. Intellectual Property
Figure 2 was also updated to reflect 16 bit alignment of the first The IETF takes no position regarding the validity or scope of any
word. Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
In this review a change to the title was proposed by the IESG and was Copies of IPR disclosures made to the IETF Secretariat and any
accepted by the authors: assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Ultra Lightweight Encapsulation (ULE) The IETF invites any interested party to bring to its attention any
-> Unidirectional Lightweight Encapsulation (ULE) copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
[END of RFC EDITOR NOTE] Acknowledgement
Expires July 2005 [page 49] Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 273 change blocks. 
1094 lines changed or deleted 707 lines changed or added

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