draft-ietf-ipdvb-ule-04.txt   draft-ietf-ipdvb-ule-03.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen, U.K. Internet Draft University of Aberdeen, U.K.
Document: draft-ietf-ipdvb-ule-04.txt Bernhard Collini-Nocker Document: draft-ietf-ipdvb-ule-03.txt Bernhard Collini-Nocker
University of Salzburg, A University of Salzburg, A
ipdvb WG ipdvb WG
Category: Draft, Intended Standards Track January 2005 Category: Draft, Intended Standards Track November 2004
Ultra Lightweight Encapsulation (ULE) for transmission of Ultra Lightweight Encapsulation (ULE) for transmission of
IP datagrams over MPEG-2/DVB networks IP datagrams over MPEG-2/DVB networks
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of RFC 3668.
skipping to change at line 46 skipping to change at line 46
digital TV services, but also as a subnetwork technology for digital TV services, but also as a subnetwork technology for
building IP networks. This document describes an Ultra Lightweight building IP networks. This document describes an Ultra Lightweight
Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6
Datagrams and other network protocol packets directly over ISO MPEG- Datagrams and other network protocol packets directly over ISO MPEG-
2 Transport Streams (TS) as TS Private Data. ULE supports an 2 Transport Streams (TS) as TS Private Data. ULE supports an
extension format that allows it to carry both optional (with an extension format that allows it to carry both optional (with an
explicit extension length) and mandatory (with an implicit extension explicit extension length) and mandatory (with an implicit extension
length) header information to assist in network/Receiver processing length) header information to assist in network/Receiver processing
of a SNDU. of a SNDU.
Expires July 2005 [page 1] Expires April 2005 [page 1]
[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).
* Procedure for TS Packet carrying the final part of a 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 a 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 April 2005 [page 2]
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 April 2005 [page 3]
* 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 April 2005 [page 4]
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 April 2005 [page 5]
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
[END of RFC EDITOR NOTE]
Expires April 2005 [page 6]
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Conventions used in this document 2. Conventions used in this document
3. Description of method 3. Description of method
4. SNDU Format 4. SNDU Format
4.1 Destination Address Present (D) Field 4.1 Destination Address Present Field
4.2 Length Field 4.2 Length Field
4.3 End Indicator 4.3 End Indicator
4.4 Type Field 4.4 Type Field
4.4.1 Type 1: Next-Header Type Fields 4.4.1 Type 1: Next-Header Type Fields
4.4.2 Type 2: EtherType Compatible Type Fields 4.4.2 Type 2: EtherType Compatible Type Fields
4.5 SNDU Destination Address Field 4.5 SNDU Destination Address Field
4.6 SNDU Trailer CRC 4.6 SNDU Trailer CRC
4.7 Description of SNDU Formats 4.7 Description of SNDU Formats
4.7.1 End Indicator 4.7.1 End Indicator
4.7.2 IPv4 SNDU Encapsulation 4.7.2 IPv4 SNDU Encapsulation
4.7.3 IPv6 SNDU Encapsulation 4.7.3 IPv6 SNDU Encapsulation
4.7.4 Test SNDU
5. Extension Headers 5. Extension Headers
5.1 Test SNDU 5.1 Mandatory Extension Header
5.2 Bridged Frame SNDU Encapsulation 5.2 Optional Extension Header
5.3 Extension-Padding Optional Extension Header
6.Processing at the Encapsulator 6.Processing at the Encapsulator
6.1 SNDU Encapsulation 6.1 SNDU Encapsulation
6.2 Procedure for Padding and Packing 6.2 Procedure for Padding and Packing
7. Receiver Processing 7. Receiver Processing
7.1 Idle State 7.1 Idle State
7.1.1 Idle State Payload Pointer Checking 7.1.1 Reassembly Payload Pointer Checking
7.2 Processing of a Received SNDU 7.2 Processing of a Received SNDU
7.2.1 Reassembly Payload Pointer Checking 7.2.1 Reassembly Payload Pointer Checking
7.3 Other Error Conditions 7.3 Other Error Conditions
8. Summary 8. Summary
9. Acknowledgments 9. Acknowledgments
10. Security Considerations 10. Security Considerations
11. References 11. References
11.1 Normative References 11.1 Normative References
11.2 Informative References 11.2 Informative References
12. Authors' Addresses 12. Authors' Addresses
13. IPR Notices 13. IPR Notices
13.1 Intellectual Property Statement
13.2 Disclaimer of Validity
14. Copyright Statement 14. Copyright Statement
14.1 Intellectual Property Statement 14.1 Intellectual Property Statement
14.2 Disclaimer of Validity 14.2 Disclaimer of Validity
15. IANA Considerations 15. IANA Considerations
15.1 IANA Guidelines
ANNEXE A: Informative Appendix - SNDU Packing Examples ANNEXE A: Informative Appendix - SNDU Packing Examples
ANNEXE B: Informative Appendix - SNDU Encapsulation ANNEXE B: Informative Appendix - SNDU Encapsulation
Expires July 2005 [page 2] Expires April 2005 [page 7]
1. Introduction 1. Introduction
This document describes an encapsulation for transport of IP This document describes an encapsulation for 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-MPEG; ID-ipdvb-arch]. It is suited to services based Streams [ISO-MPEG; ID-ipdvb-arch]. It is suited to services based
on MPEG-2, for example the Digital Video Broadcast (DVB) on MPEG-2, for example the Digital Video Broadcast (DVB)
architecture, the Advanced Television Systems Committee (ATSC) architecture, the Advanced Television Systems Committee (ATSC)
system [ATSC; ATSC-G], and other similar MPEG-2 based transmission system [ATSC; ATSC-G], and other similar MPEG-2 based transmission
systems. Such systems provide unidirectional (simplex) physical and systems. Such systems provide unidirectional (simplex) physical and
skipping to change at line 120 skipping to change at line 341
physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC],
Satellite TV [ETSI-DVBS; ATSC-S], Cable Transmission [ETSI-DVBC; Satellite TV [ETSI-DVBS; ATSC-S], Cable Transmission [ETSI-DVBC;
ATSC-PSIP-TC]). Bi-directional (duplex) links may also be ATSC-PSIP-TC]). Bi-directional (duplex) links may also be
established using these standards (e.g., DVB defines a range of established using these standards (e.g., DVB defines a range of
return channel technologies, including the use of two-way satellite return channel technologies, including the use of two-way satellite
links [ETSI-RCS] and dial-up modem links [RFC3077]). links [ETSI-RCS] and dial-up modem links [RFC3077]).
Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other
network layer packets) for transmission over an MPEG-2 Transport network layer packets) for transmission over an MPEG-2 Transport
Multiplex are passed to an Encapsulator. This formats each PDU into Multiplex are passed to an Encapsulator. This formats each PDU into
a SubNetwork Data Unit (SNDU) [RFC3819] by adding an encapsulation a Subnetwork Data Unit (SNDU) by adding an encapsulation header and
header and an integrity check trailer. The SNDU is fragmented into a an integrity check trailer. The SNDU is fragmented into a series of
series of TS Packets) that are sent over a single TS Logical TS Packets) that are sent over a single TS Logical Channel.
Channel.
Expires July 2005 [page 3] Expires April 2005 [page 8]
2. Conventions used in this document 2. Conventions used in this document
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-MPEG]. an MPEG-2 Multiplex [ISO-MPEG].
AFC: Adaptation Field Control [ISO_MPEG]. A pair of bits carried in AFC: Adaptation Field Control, a pair of bits carried in the TS
the TS Packet header that signal the presence of the Adaptation 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.
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 defined by format for transmission of data and control information defined by
the ISO MPEG-2 standard that is carried in an MPEG-2 Private the ISO MPEG-2 standard that is carried in an MPEG-2 Private
Section. Section.
DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
associated standards published by the European Telecommunications associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and Standards Institute (ETSI) for the transmission of video, audio, and
data, using the ISO MPEG-2 Standard. data, using the ISO MPEG-2 Standard.
Encapsulator: A network device that receives PDUs and formats these ENCAPSULATOR: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output as a stream of into Payload Units (known here as SNDUs) for output as a stream of
TS Packets. TS Packets.
End Indicator: A value that indicates to the Receiver that there are END INDICATOR: A value that indicates to the Receiver that there are
no further SNDUs present within the current TS Packet. no further SNDUs present within the current TS Packet.
MAC: Medium Access and Control. The link layer header of the MAC: Medium Access and Control. The link layer header of the
Ethernet IEEE 802 standard of protocols, consisting of a 6B Ethernet IEEE 802 standard of protocols, consisting of a 6B
destination address, 6B source address, and 2B type field (see also destination address, 6B source address, and 2B type field.
NPA).
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) [ISO-MPEG]. Organisation (ISO) [ISO-MPEG].
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 B NPA: Network Point of Attachment. In this document, refers to a 6 B
destination address (resembling an IEEE MAC address) within the destination address (similar to an Ethernet MAC address) within the
MPEG-2 transmission network that is used to identify individual MPEG-2 transmission network used to identify individual Receivers or
Receivers or groups of Receivers. groups of Receivers.
Expires July 2005 [page 4] Expires April 2005 [page 9]
Packing Threshold: A period of time an Encapsulator is willing to PACKING THRESHOLD: A period of time an Encapsulator is willing to
defer transmission of a partially filled TS-Packet to accumulate defer transmission of a partially filled TS-Packet to accumulate
more SNDUs, rather than use Padding. After the Packet Threshold more SNDUs, rather than use Padding. After the Packet Threshold
period, the Encapsulator uses Padding to send the partially filled period, the Encapsulator uses Padding to send the partially filled
TS-Packet. TS-Packet.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, PDU: Protocol Data Unit. Examples of 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-MPEG]. A format of MPEG-2 TS
packet payload usually used for video or audio information.
PID: Packet Identifier [ISO_MPEG]. A 13 bit field carried in the
header of TS Packets. This is used to identify the TS Logical
Channel to which a TS Packet belongs [ISO-MPEG]. The TS Packets
forming the parts of a Table Section, PES, or other Payload Unit
must all carry the same PID value. The all 1s PID value indicates a
Null TS Packet introduced to maintain a constant bit rate of a TS
Multiplex. There is no required relationship between the PID values
used for TS Logical Channels transmitted using different TS
Multiplexes.
PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that
directly follows the TS Packet header. It contains the number of
bytes between the end of the TS Packet header and the start of a
Payload Unit. The presence of 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, and Table Sections, it is not present
in TS Logical Channels that use the PES-format.
Private Section: A syntactic structure constructed in accordance PES: Packetized Elementary Stream of MPEG-2 [ISO-MPEG].
with Table 2-30 of [ISO-MPEG]. The structure may be used to identify
private information (i.e. not defined by [ISO-MPEG]) relating to one
or more elementary streams, or a specific MPEG-2 program, or the
entire Transport Stream. Other Standards bodies, e.g. ETSI, ATSC,
have defined sets of table structures using the private_section
structure. A Private Section is transmitted as a sequence of TS
Packets using a TS Logical Channel. A TS Logical Channel may carry
sections from more than one set of tables.
PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey PID: Packet Identifier. A 13 bit field carried in the header of TS
information about services carried in a TS Multiplex. It is carried Packets. This is used to identify the TS Logical Channel to which a
in one of four specifically identified table section constructs TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a
[ISO-MPEG], see also SI Table. Table Section, PES, or other payload unit must all carry the same
PID value. The all 1s PID value indicates a Null TS Packet
introduced to maintain a constant bit rate of a TS Multiplex.
PSI: Program Specific Information [ISO-MPEG]. Tables used to convey PP: Payload Pointer. An optional one byte pointer that directly
information about the service carried in a TS Multiplex. The set of follows the TS Packet header. It contains the number of bytes
PSI tables is defined by MPEG-2 [ISO-MPEG]. See also SI Table. between the end of the TS Packet header and the start of a Payload
Unit. The presence of 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, and Table Sections, it is not present in TS
Logical Channels that use the PES-format.
PU: Payload Unit. A sequence of bytes sent using a TS. Examples of PU: Payload Unit. 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.
Expires July 2005 [page 5] PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. A single bit flag bit flag carried in the TS Packet header. A PUSI value of zero
carried in the TS Packet header. A PUSI value of zero indicates that indicates that the TS Packet does not carry the start of a new
the TS Packet does not carry the start of a new Payload Unit. A PUSI Payload Unit. A PUSI value of one indicates that the TS Packet does
value of one indicates that the TS Packet does carry the start of a carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1
new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the also indicates the presence of a one byte Payload Pointer (PP).
presence of a one byte Payload Pointer (PP).
Receiver: An equipment that processes the signal from a TS Multiplex PRIVATE SECTION: a syntactic structure used for mapping all service
and performs filtering and forwarding of encapsulated PDUs to the information (e.g. an SI table) into TS Packets. A Table may be
network-layer service (or bridging module when operating at the link divided into a number of Table Sections, however all Table Sections
layer). must be carried over a single TS Logical Channel.
SI Table: Service Information Table [ISO-MPEG]. In this document, PSI: Program Specific Information. Tables used to convey information
this term describes a table that is used to convey information about about the service carried in a TS Multiplex. The set of PSI tables
the services carried in a TS Multiplex, that has been defined by is defined by [ISO-MPEG], see also SI Table.
another standards body. A Table may consist of one or more Table
Sections, however all sections of a particular SI Table must be
carried over a single TS Logical Channel [ISO-MPEG].
SNDU: Subnetwork Data Unit [RFC3819]. An encapsulated PDU sent as an SI TABLE: Service Information Table. In this document, this term
MPEG-2 Payload Unit. describes any table used to convey information about the service
carried in a TS Multiplex. SI tables are carried in MPEG-2 private
sections.
Table Section: A Payload Unit carrying all or a part of an SI or PSI SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Table [ISO-MPEG]. Payload Unit.
Expires April 2005 [page 10]
TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table.
TS: Transport Stream [ISO-MPEG], a method of transmission at the TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI MPEG-2 level using TS Packets; it represents level 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.
TS Header: The 4 byte header of a TS Packet [ISO-MPEG]. TS HEADER: The 4 byte header of a TS Packet as illustrated in the
introduction.
TS Logical Channel: Transport Stream Logical Channel. In this TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel
document, this term identifies a channel at the MPEG-2 level [ISO- identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of
MPEG]. It exists at level 2 of the ISO/OSI reference model. All the ISO/OSI reference model. All packets sent over a TS Logical
packets sent over a TS Logical Channel carry the same PID value Channel carry the same PID value. According to MPEG-2, some TS
(this value is unique within a specific TS Multiplex). According to Logical Channels are reserved for specific signalling purposes.
MPEG-2, some TS Logical Channels are reserved for specific Other standards (e.g., ATSC, DVB) also reserve specific TS Logical
signalling purposes. Other standards (e.g., ATSC, DVB) also reserve Channels.
specific TS Logical Channels.
TS Multiplex: In this document, this term defines a set of MPEG-2 TS TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single
Logical Channels sent over a single lower layer connection. This may 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). The same TS Logical
rate, FEC setting, and transmission frequency) or an encapsulation Channel may be repeated over more than one TS Multiplex, for example
provided by another protocol layer (e.g. Ethernet, or RTP over IP). to redistribute the same multicast content to two terrestrial TV
The same TS Logical Channel may be repeated over more than one TS transmission cells.
Multiplex (possibly associated with a different PID value) [ID-
ipdvb-arch], for example to redistribute the same multicast content
to two terrestrial TV transmission cells.
Expires July 2005 [page 6] 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-MPEG]. Each TS Packet carries a 4B header, plus optional [ISO-MPEG]. 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 Transport Streams.
Channels. The 188B TS Packet incorporates a 4B header with the The 188B TS Packets incorporate a 4B header with the following
following fields (those referenced within this document are marked fields (those referenced within this document are marked with *):
with *):
Field Length Name/Purpose Field Length Name/Purpose
(in bits) (in bits)
8b Synchronisation pattern equal 0x47 8b Synchronisation pattern equal 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)
Expires July 2005 [page 7] Expires April 2005 [page 11]
3. Description of the Method 3. Description of the Method
PDUs (IP packets, Ethernet frames or packets from other network PDUs (IP packets, Ethernet frames or packets from other network
protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). protocols) are encapsulated to form a Subnetwork Data Unit (SNDU).
The SNDU is transmitted over an MPEG-2 transmission network by The SNDU is transmitted over an MPEG-2 transmission network by
placing it either in the payload of a single TS Packet, or if placing it either in the payload of a single TS Packet, or if
required, an SNDU may be fragmented into a series of TS Packets. required, an SNDU may be fragmented into a series of TS Packets.
Where there is sufficient space, the method permits a single TS Where there is sufficient space, the method permits a single TS
Packet to carry more than one SNDU (or part there of), sometimes Packet to carry more than one SNDU (or part there of), sometimes
skipping to change at line 340 skipping to change at line 532
contains the continuation, or end of a SNDU; contains the continuation, or end of a SNDU;
1: The TS Packet contains the start of a SNDU, and a one byte 1: The TS Packet contains the start of a 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 fills the remainder of the TS Packet payload with
bytes with a value 0xFF [ISO-MPEG2], known as Padding. bytes with a value 0xFF [ISO-MPEG2], known as Padding.
A Receiver processing MPEG-2 Table Sections that receives a value of A Receiver processing MPEG-2 Table Sections is aware that when it
0xFF in place of the table_id field, interprets this as receives a table_id value of 0xFF, this indicates Padding/Stuffing
Padding/Stuffing and silently discards the remainder of the TS occurred and silently discards the remainder of the TS Packet
Packet payload. The payload of the next TS Packet for the same TS payload. The payload of the next TS Packet for the same TS Logical
Logical Channel will begin with a Payload Pointer of value 0x00, Channel will begin with a Payload Pointer of value 0x00, indicating
indicating that the next Payload Unit immediately follows the TS that the next Payload Unit immediately follows the TS Packet header.
Packet header. The ULE protocol resembles this, but differs in the The ULE protocol resembles this, but differs in the exact procedure
exact procedure (see the following sections). (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. The purpose of the adaptation field is primarily to
to carry timing and synchronisation information and may also be used extend the TS header for timing and synchronisation information and
to include stuffing bytes before a TS Packet payload. Adaptation may be used to also include stuffing bytes before a TS Packet
Field stuffing is NOT used in this encapsulation method, and TS payload. Standard Receivers discard TS Packets with an
Packets from a ULE Encapsulator MUST be sent with an AFC value of adaptation_field_control field value of '00'. Adaptation Field
'01'. For TS Logical Channels supporting ULE, Receivers MUST discard stuffing is NOT used in this encapsulation method, and TS Packets
TS Packets that carry other AFC values. from a ULE Encapsulator MUST be sent with an AFC value of '01'.
Receivers MUST discard TS Packets that carry other AFC values.
Expires July 2005 [page 8] Expires April 2005 [page 12]
4. SNDU Format 4. SNDU Format
PDUs (IP packets and bridged Ethernet frames) are encapsulated using PDUs (IP packets and bridged Ethernet frames) are encapsulated using
ULE to form a SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The
encapsulation format to be used for PDUs is illustrated below: encapsulation format to be used for PDUs is illustrated below:
< ----------------------------- SNDU ----------------------------- > < ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
|D| Length | Type | PDU | CRC-32 | |D| Length | Type | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation Figure 1: SNDU Encapsulation
All multi-byte values in ULE (including Length, Type, and All multi-byte values in ULE (including Length, Type, and
Destination fields) are transmitted in network byte order (most Destination fields) are transmitted in network byte order (most
significant byte first). The most significant bit of each byte is significant byte first). Appendix A provides informative examples of
placed in the left-most position of the 8-bit field. Appendix A usage.
provides informative examples of usage.
4.1 Destination Address Present (D) Field 4.1 The Destination Address Present Field
The most significant bit of the Length Field carries the value of The most significant bit of the Length Field carries the value of
the Destination Address Present Field, the D-bit. A value of 0 the Destination Address Present Field, the D-bit. A value of 0
indicates the presence of the Destination Address Field (see section indicates the presence of the Destination Address Field (see section
4.5). A value of 1 indicates that a Destination Address Field is not 4.5). A value of 1 indicates that a Destination Address Field is not
present (i.e. it is omitted). present (i.e. it is omitted).
By default, the D-bit value SHOULD be set to a value of 0 (see 4.5), By default, the D-bit value MUST be set to a value of 0, except for
except for the transmission of an End Indicator (see 4.3), for which the transmission of an End Indicator (see 4.3), in which this bit
this bit MUST be set to the value of 1. MUST be set to the value of 1.
4.2 Length Field 4.2 Length Field
A 15-bit value that indicates the length, in bytes, of the SNDU A 15-bit value that indicates the length, in bytes, of the SNDU
(encapsulated Ethernet frame, IP datagram or other packet) counted (encapsulated Ethernet frame, IP datagram or other packet) counted
from the byte following the Type field, up to and including the CRC. from the byte following the Type field, up to and including the CRC.
Note the special case described in 4.3. Note the special case described in 4.3.
4.3 End Indicator 4.3 End Indicator
When the first two bytes of a SNDU have the value 0xFFFF, this When the first two bytes of a SNDU have the value 0xFFFF, this
denotes an End Indicator (i.e., all 1s length combined with a D-bit denotes an End Indicator (i.e., all 1s length combined with a D-bit
value of 1). This indicates to the Receiver that there are no value of 1). It indicates to the Receiver that there are no further
further SNDUs present within the current TS Packet (see section 6), SNDUs present within the current TS Packet (see section 6), and that
and that no Destination Address Field is present. The value 0xFF has no Destination Address Field is present. The value 0xFF has specific
specific semantics in MPEG-2 framing, where it is used to indicate semantics in MPEG-2 framing, where it is used to indicate the
the presence of Padding. This use resembles [ISO-DSMCC]. presence of Padding. This use resembles [ISO-DSMCC].
Expires July 2005 [page 9] Expires April 2005 [page 13]
4.4 Type Field 4.4 Type Field
The 16-bit Type field indicates the type of payload carried in a The 16-bit Type field indicates the type of payload carried in a
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 DIX EtherTypes were originally specified by Xerox under the DIX
framework for Ethernet. After specification of IEEE 802.3 [LLC], the framework for Ethernet. After specification of IEEE 802.3 [LLC], the
set of EtherTypes less than 1536 (0x0600), assumed the role of a set of EtherTypes less than 1536 (0x0600), assumed the role of a
skipping to change at line 431 skipping to change at line 623
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 4.7.5).
The Ethernet LLC mode of identification is not required in ULE, The Ethernet LLC mode of identification is not required in ULE,
since the SNDU format always carries an explicit Length Field, and since 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 1536. These Type field values are IANA assigned (see 4.4.1), and
assigned (see 4.4.1), and indicate the Next-Header. 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 >= 1536. In ULE, this indicates that the value is identical to the
identical to the corresponding type codes specified by the IEEE/DIX corresponding type codes specified by the IEEE/DIX type assignments
type assignments for Ethernet and recorded in the IANA EtherType 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. registry.
Expires July 2005 [page 10] Expires April 2005 [page 14]
The following types are defined in this document: The following types are defined in this document:
[XXX IANA ACTION REQUIRED XXX] [XXX IANA ACTION REQUIRED XXX]
0x0000: Test SNDU, discarded by the Receiver. 0x0000: Test SNDU, discarded by the Receiver.
0x0001: Bridged Ethernet Frame (i.e. MAC source address follows) 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)
0x0100: Padding, ignored by the Receiver. 0x0100: Padding, ignored by the Receiver.
[XXX END OF IANA ACTION REQUIRED XXX] [XXX END OF IANA ACTION REQUIRED XXX]
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 1536
0x600 (1536 decimal) and 0xFFFF. This set of type assignments Decimal (0x600) and 0xFFFF. This set of type assignments follow
follow DIX/IEEE assignments (but exclude use of this field as a DIX/IEEE assignments (but exclude use of this field as a frame
frame length indicator) [LLC]. All assignments in this space MUST length indicator) [LLC]. All assignments in this space MUST use the
use the values defined for IANA EtherType, the following two Type values defined for IANA EtherType, the following two Type values are
values are used as examples (taken from the IANA EtherTypes used as examples (taken from the IANA EtherTypes registry):
registry):
0x0800 : IPv4 Payload 0x0800 : IPv4 Payload
0x86DD : IPv6 Payload 0x86DD : IPv6 Payload
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
connects multiple Receivers). A sender MAY omit this field (D=1) for the same link connects multiple Receivers). A sender MAY omit this
an IP unicast packet and/or multicast packets delivered to Receivers field (D=1) for an IP unicast packet and/or multicast packets
that are able to utilise a discriminator field (e.g. the IPv4/IPv6 delivered to Receivers that are able to utilise a discriminator
destination address), which in combination with the PID value, could field (e.g. the IPv4/IPv6 destination address), which in combination
be interpreted as a Link-Level address. with the PID value, could be interpreted as a Link-Level address.
When the SNDU header indicates the presence of a SNDU Destination When the SNDU header indicates the presence of a 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 directly follows the SNDU Type Field. NPA destination addresses are
destination addresses are 6 Byte numbers, normally expressed in 6 Byte numbers, normally expressed in hexadecimal, used to identify
hexadecimal, used to identify the Receiver(s) in a MPEG-2 the Receiver(s) in a MPEG-2 transmission network that should process
transmission network that should process a received SNDU. The value a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as
0x00:00:00:00:00:00, MUST NOT be used as a destination address in a a destination address in a SNDU. The least significant bit of the
SNDU. The least significant bit of the first byte of the address is first byte of the address is set to 1 for multicast frames, and the
set to 1 for multicast frames, and the remaining bytes specify the remaining bytes specify the link layer multicast address. The
link layer multicast address. The specific value 0xFF:FF:FF:FF:FF:FF specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address,
is the link broadcast address, indicating this SNDU is to be indicating this SNDU is to be delivered to all Receivers.
delivered to all Receivers.
Expires July 2005 [page 11]
Expires April 2005 [page 15]
4.6 SNDU Trailer CRC 4.6 SNDU Trailer CRC
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of Each SNDU MUST carry a 32-bit CRC field in the last four bytes of
the SNDU. This position eases CRC computation by hardware. The CRC- the SNDU. This position eases CRC computation by hardware. The CRC-
32 polynomial is to be used. Examples where this polynomial is also 32 polynomial is to be used. Examples where this polynomial is also
employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and
AAL5 [ITU3563]. This is a 32 bit value calculated according to the AAL5 [ITU3563]. 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.
skipping to change at line 555 skipping to change at line 743
encapsulation gateway and/or the Receiver. It may also detect the encapsulation gateway and/or the Receiver. It may also detect the
presence of uncorrected errors from the physical link (however, presence of uncorrected errors from the physical link (however,
these may also be detected by other means, e.g. section 7.3). these may also be detected by other means, e.g. section 7.3).
4.7 Description of SNDU Formats 4.7 Description of SNDU Formats
The format of a SNDU is determined by the combination of the The format of a SNDU is determined by the combination of the
Destination Address Present bit (D) and the SNDU Type Field. The Destination Address Present bit (D) and the SNDU Type Field. The
simplest encapsulation places a PDU directly into a SNDU payload. simplest encapsulation places a PDU directly into a 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 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.
IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2) IPv4 SNDU: The payload is a complete IPv4 datagram
Expires July 2005 [page 12] Expires April 2005 [page 16]
IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3). IPv6 SNDU: The payload is a complete IPv6 datagram.
Test SNDU: The payload will be discarded by the Receiver (5.1). Test SNDU: The payload will be discarded by the Receiver.
Bridged SNDU: The payload carries a bridged MAC or LLC frame (5.2). Bridged SNDU: The payload carries a bridged MAC or LLC frame.
Other formats may be defined through relevant assignments in the All other formats are currently reserved.
IEEE and IANA registries.
Expires April 2005 [page 17]
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= Arbitrary number (>= 0) bytes with value 0xFF = = Arbitrary number (>= 0) bytes with value 0xFF =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 590 skipping to change at line 776
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= Arbitrary number (>= 0) bytes with value 0xFF = = Arbitrary number (>= 0) bytes with value 0xFF =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SNDU Format for an End Indicator. Figure 2: SNDU Format for an End Indicator.
4.7.2 IPv4 SNDU 4.7.2 IPv4 SNDU
IPv4 datagrams are directly transported using one of the two IPv4 datagrams are transported using one of the two standard SNDU
standard SNDU structures, in which the PDU is placed directly in the structures, in which the PDU is placed directly in the SNDU payload.
SNDU payload. The two encapsulations are shown in figures 3 and 4. The two encapsulations are shown in figures 3 and 4. (Note that in
(Note that in this, and the following figures, the IP datagram this, and the following figures, the IP datagram payload is of
payload is of variable size, and is directly followed by the CRC- 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 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).
Expires July 2005 [page 13] Expires April 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 transported using one of the two standard SNDU
standard SNDU structures, in which the PDU is placed directly in the structures, in which the PDU is placed directly in the SNDU payload.
SNDU payload. The two encapsulations are shown in figures 5 and 6. The two encapsulations are shown in figures 5 and 6.
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 = 0x086DD | |0| Length (15b) | Type = 0x086DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= IPv6 datagram = = IPv6 datagram =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 666 skipping to change at line 851
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x086DD | |1| Length (15b) | Type = 0x086DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= 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 14]
5. Extension Headers
This section describes an extension format for the ULE
encapsulation. In ULE, a Type field value less than 1536 Decimal
indicates an Extension Header. These values are assigned from a
separate IANA registry defined for ULE.
The use of a single Type/Next-Header field simplifies processing and
eliminates the need to maintain multiple IANA registries. The cost
is that each Extension Header requires at least 2 bytes. This is
justified, on the basis of simplified processing and maintaining a
simple lightweight header for the common case when no extensions are
present.
A ULE Extension Header is identified by a 16-bit value in the Type
field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN
field and an 8-bit H-Type field, as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN| H-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of ULE Next-Header Field.
The H-LEN Assignment is described below:
0 Indicates a Mandatory Extension Header
1 Indicates an Optional Extension Header of length 2B
2 Indicates an Optional Extension Header of length 4B
3 Indicates an Optional Extension Header of length 6B
4 Indicates an Optional Extension Header of length 8B
5 Indicates an Optional Extension Header of length 10B
>=6 the combined H-LEN and H-TYPE values indicate the EtherType
of a PDU that directly follows this Type field.
A H-LEN of zero indicates a Mandatory Extension Header. Each
Mandatory Extension Header has a pre-defined length that is not
communicated in the H-LEN field. No additional limit is placed on
the maximum length of a Mandatory Extension Header. A Mandatory
Extension Header MAY modify the format or encoding of the enclosed
PDU (e.g. to perform encryption and/or compression).
The H-Type is a one byte field that is either one of 256 Mandatory
Header Extensions or one of 256 Optional Header Extensions. The set
of currently permitted values for both types of Extension Headers
are defined by an IANA Registry (section 15). Registry values for
Optional Extensions are specified in the form H=1 (i.e. a decimal
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).
Expires July 2005 [page 15]
Two examples of Extension Headers are the Test_SNDU and the use of
Extension-Padding. The Test-SNDU Mandatory Extension Header results
in the entire PDU being discarded. The Extension-Padding Optional
Extension Header results in the following (if any) option header
being ignored (i.e. a total of H-LEN 16-bit words).
The general format for an SNDU with Extension Headers is:
< -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header > < ext 1 >
Figure 8: SNDU Encapsulation with one Extension Header (for D=0).
Where:
D is the ULE D_bit (in this example D=0, however NPA addresses may
also be omitted when using Extension Headers).
T1 is the base header Type field. In this case, specifying a
Next-Header value.
H1 is a set of fields defined for header type T1. There may be 0
or more bytes of information for a specific ULE Extension Header.
T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried.
< -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
Figure 9: SNDU Encapsulation with two Extension Headers (D=1).
Using this method, several Extension Headers MAY be chained in
series. Figure 12 shows an SNDU including two Extension Headers. The
values of T1 and T2 are both less than 1536 Decimal, each indicates
the presence of an Extension Header, rather than a directly
following PDU. T3 has a value > 1535 indicating the EtherType of the
PDU being carried. Although an SNDU may contain an arbitrary number
of consecutive Extension Headers, it is not expected that SNDUs will
generally carry a large number of extensions.
Expires July 2005 [page 16] Expires April 2005 [page 19]
5.1 Test SNDU 4.7.4 Test SNDU
A Test SNDU (figure 10) is of Type 1. The structure of the Data A Test SNDU is of Type 1 (figure 7). The structure of the Data
portion of this SNDU is not defined by this document. All Receivers portion of this SNDU is not defined by this document. All Receivers
MAY record reception in a log file, but MUST then discard any Test MAY record reception in a log file, but MUST then discard any Test
SNDUs. The D-bit MAY be set in a TEST SNDU. SNDUs. The 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 7: SNDU Format for a Test SNDU
5.2 Bridge Frame SNDU Encapsulation 4.7.5 Bridge Frame SNDU Encapsulation
A bridged SNDU is of Type 1. The payload includes MAC address and A bridged SNDU is of Type 1. The payload includes a MAC source and
Ether-Type fields together with the contents of a bridged MAC frame. Ether-Type field together with the contents of a bridged MAC frame.
The SNDU has the format shown in figures 11 and 12. The SNDU has the format shown in figures 8 and 9.
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 Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Destination Address (6B) | | MAC Destination Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Source Address (6B) | | MAC Source Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EtherType (2B) | | | EtherType (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= (Contents of bridged MAC frame) = = (Contents of bridged MAC frame) =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SNDU Format for a Bridged Payload (D=0) Figure 8: SNDU Format for a Bridged Payload (D=0)
Expires July 2005 [page 17] Expires April 2005 [page 20]
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 = 0x0001 | |1| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Destination Address (6B) | | MAC Destination Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Source Address (6B) | | MAC Source Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EtherType (2B) | | | EtherType (2B) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= (Contents of bridged MAC frame) = = (Contents of bridged MAC frame) =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SNDU Format for a Bridged Payload (D=1) Figure 9: SNDU Format for a Bridged Payload (D=1)
Note: The final two bytes of the bridging header also carry a Type Note: The final two bytes of the bridging header also carry a Type
field (see section 5). In this special case, the extension mandatory field (see section 5). In this special case, the extension mandatory
header format permits this to carry a LLC Length field, specified by header format permits this to carry a LLC Length field, specified by
IEEE 802 [LLC] rather than an IANA assigned value. IEEE 802 [LLC] rather than an IANA assigned value.
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 address that does NOT match their own NPA
their own NPA address (or a broadcast/multicast address), the address (or a broadcast/multicast address), the payload of the
payload of the remaining SNDUs are processed by the bridging rules remaining SNDUs are processed by the bridging rules that follow. An
that follow. An SNDU without an NPA address (D=1) results in a 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.
The MAC addresses in the frame being bridged SHOULD be assigned The MAC addresses in the frame being bridged SHOULD be assigned
according to the rules specified by the IEEE and may denote unknown, according to the rules specified by the IEEE and may denote unknown,
unicast, broadcast, and multicast link addresses. These MAC unicast, broadcast, and multicast link addresses. These MAC
addresses denote the intended recipient in the destination LAN, and addresses denote the intended recipient in the destination LAN, and
therefore have a different function to the NPA addresses carried in therefore have a different function to the NPA addresses carried in
the SNDU header. The EtherType field of a frame is defined according the SNDU header. The EtherType field of a frame is defined according
to Ethernet/LLC [LLC]. to Ethernet/LLC [LLC].
A frame Type < 1536 for a bridged frame, introduces a LLC Length A frame Type < 1536 for a bridged frame, introduces a LLC Length
field. The Receiver MUST check this length and discard any frame field. The Receiver MUST check this length and discard any frame
with a length greater than permitted by the SNDU payload size. with a length greater than permitted by the SNDU payload size.
In normal operation, it is expected that any padding appended to the In normal operation, it is expected that any padding appended to the
Ethernet frame SHOULD be removed prior to forwarding. This requires Ethernet frame SHOULD be removed prior to forwarding. This requires
the sender to be aware of such Ethernet padding (e.g. LLC). the sender to be aware of such Ethernet padding (e.g. LLC).
Expires July 2005 [page 18]
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,
Expires April 2005 [page 21]
field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the
LAN-FCS value of all frames received, prior to further processing. LAN-FCS value of all frames received, prior to further processing.
Frames received with an invalid LAN FCS MUST be discarded. After Frames received with an invalid LAN FCS MUST be discarded. After
checking, the LAN FCS is then removed (i.e., it is NOT forwarded in checking, the LAN FCS is then removed (i.e., it is NOT forwarded in
the bridged SNDU). As in other ULE frames, the Encapsulator appends the bridged SNDU). As in other ULE frames, the Encapsulator appends
a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate
LAN-FCS field will be appended to the bridged frame prior to onward LAN-FCS field will be appended to the bridged frame prior to onward
transmission on the Ethernet interface. transmission on the Ethernet 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 transmitting two
integrity check fields for bridged frames. However, it also integrity check fields for bridged frames. However, it also
introduces the possibility that a frame corrupted within the introduces the possibility that a frame corrupted within the
processing performed at an Encapsulator and/or Receiver may not be processing performed at an Encapsulator and/or Receiver may not be
detected by the final recipient(s) (i.e. such corruption would not detected by the final recipient(s) (i.e. such corruption would not
normally result in an invalid LAN FCS). normally result in an invalid LAN FCS).
5.3 Extension-Padding Optional Extension Header Expires April 2005 [page 22]
The Extension-Padding Optional Extension Header is specified by an 5. Extension Headers
IANA assigned H-Type value of 0x100. As in other Optional
Extensions, the total length of the extension is indicated by the H-
LEN field (specified in 16-bit words). The extension field is formed
of a group of 1-5 16-bit fields.
For this specific option, only the last 16-bit word has an assigned This section describes an extension format for the ULE
value, the sender SHOULD set the remaining values to 0x0000. The encapsulation. In ULE, a Type field value less than 1536 Decimal
last 16-bit field forms the Next-Header Type field. A Receiver MUST indicates an Extension Header. These values are assigned from a
interpret the Type field, but MUST ignore any other fields of this separate IANA registry defined for ULE.
Extension Header.
Expires July 2005 [page 19] The use of a single Type/Next-Header field simplifies processing and
eliminates the need to maintain multiple IANA registries. The cost
is that each Extension Header requires at least 2 bytes. This is
justified, on the basis of simplified processing and maintaining a
simple lightweight header for the common case when no extensions are
present.
A ULE Extension Header is identified by a 16-bit value in the Type
field. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field
and an 8-bit H-Type field, as follows:
+----+-----+--------+
|0000|H-LEN| H-TYPE |
+----+-----+--------+
Figure 10: Structure of ULE Next-Header Field.
The H-LEN Assignment is described below:
0 Indicates a Mandatory Extension Header
1 Indicates an Optional Extension Header of length 2B
2 Indicates an Optional Extension Header of length 4B
3 Indicates an Optional Extension Header of length 6B
4 Indicates an Optional Extension Header of length 8B
5 Indicates an Optional Extension Header of length 10B
>=6 the combined H-LEN and H-TYPE values indicate the EtherType
of a PDU that directly follows this Type field.
A H-LEN of zero indicates a Mandatory Extension Header. Each
Mandatory Extension Header has a pre-defined length that is not
communicated in the H-LEN field. No additional limit is placed on
the maximum length of a Mandatory Extension Header. A Mandatory
Extension Header MAY modify the format or encoding of the enclosed
PDU (e.g. to perform encryption and/or compression).
The H-Type is a one byte field that may be either one of 256
Mandatory Header Extensions or one of 256 Optional Header
Extensions. The set of currently permitted values for both types of
Extension Headers are defined by an IANA Registry (section 15).
Registry values for Optional Extensions are specified in the form
H=1 (i.e. a decimal number in the range 256-511), but may be used
with an H-Length value in the range 1-5.
Two examples of Extension Headers are the Test_SNDU and the use of
Extension-Padding. The Test-SNDU Mandatory Extension Header results
in the entire PDU being discarded. The Extension-Padding Optional
Expires April 2005 [page 23]
Extension Header results in the following (if any) option header
being ignored (i.e. a total of H-LEN 16-bit words).
The general format for an SNDU with Extension Headers is:
< -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header >< ext 1 >
Figure 11: SNDU Encapsulation with one Extension Header
Where:
D is the ULE D_bit (in this example D=1, however NPA addresses may
also be used in combination with Extension Headers).
T1 is the base header Type field. In this case, specifying a
Next-Header value.
H1 is a set of fields defined for header type T1. There may be 0
or more bytes of information for a specific ULE Extension Header.
T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried.
< -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
Figure 12: SNDU Encapsulation with two Extension Headers
Using this method, several Extension Headers MAY be chained in
series. Figure 12 shows an SNDU including two Extension Headers. The
values of T1 and T2 are both less than 1536 Decimal, each indicates
the presence of an Extension Header rather than a directly following
PDU. T3 has a value > 1535 indicating the EtherType of the PDU being
carried. Although an SNDU may contain an arbitrary number of
consecutive Extension Headers, it is not expected that SNDUs will
generally carry a large number of extensions.
Expires April 2005 [page 24]
6. Processing at the Encapsulator 6. Processing at the Encapsulator
The Encapsulator forms the PDUs queued for transmission into SNDUs The Encapsulator forms the PDUs queued for transmission into SNDUs
by adding a header and trailer to each PDU (section 4). It then by adding a header and trailer to each PDU (section 4). It then
segments the SNDU into a series of TS Packet payloads (figure 9). segments the SNDU into a series of TS Packet payloads (figure 9).
These are transmitted using a single TS Logical Channel over a TS These are transmitted using a single TS Logical Channel over a TS
Multiplex. The TS Multiplex may be processed by a number of MPEG-2 Multiplex. The TS Multiplex may be processed by a number of MPEG-2
(re)multiplexors before it is finally delivered to a Receiver [ID- (re)multiplexors before it is finally delivered to a Receiver.
ipdvb-arch].
+------+--------------------------------+------+ +------+--------------------------------+------+
| 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 a SNDU into a series of TS Packets Figure 13: Encapsulation of a 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 a SNDU in the first available TS Packet. This first TS Packet send a SNDU in the first available TS Packet. This first TS Packet
generated MUST carry a PUSI value of 1. It MUST also carry a Payload generated MUST carry a PUSI value of 1. It MUST also carry a Payload
Pointer value of zero indicating the SNDU starts in the first Pointer value of zero indicating the SNDU starts in the first
available byte of the TS Packet payload. available byte of 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-MPEG]. This value MUST be incremented by one (modulo 16) for [ISO-MPEG]. This value MUST be incremented by one (modulo 16) for
each successive fragment/complete SNDU sent using a TS Logical each successive fragment/complete SNDU sent using a TS Logical
Channel. Channel.
An Encapsulator MAY decide not to immediately send another SNDU, An Encapsulator MAY decide not to immediately send another SNDU,
even if space is available in a partially filled TS Packet. This even if space is available in a partially filled TS Packet. This
procedure is known as Padding (figure 11). It informs the Receiver procedure is known as Padding (figure 11). It informs the Receiver
that there are no more SNDUs in this TS Packet payload. The End that there are no more SNDUs in this TS Packet payload. The End
Indicator is followed by zero or more unused bytes until the end of Indicator is followed by zero or more unused bytes until the end of
the TS Packet payload. All unused bytes MUST be set to the value of the TS Packet payload. All unused bytes MUST be set to the value of
0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The Padding 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The padding
procedure trades decreased efficiency against improved latency. procedure trades decreased efficiency against improved latency.
Expires July 2005 [page 20] Expires April 2005 [page 25]
+-/------------+ +-/------------+
| SubNetwork | | SubNetwork |
| DU 3 | | DU 3 |
+-/------------+ +-/------------+
\ \ \ \
\ \ \ \
\ \ \ \
+--------+--------+--------+----------+ +--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused | |MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 3 | | Bytes | | Header | SNDU 3 | | Bytes |
skipping to change at line 1006 skipping to change at line 1176
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-MPEG] require the header a new TS Packet. (The standard rules [ISO-MPEG] require the header
of this new TS Packet to carry a PUSI value of 1, and a Payload of this new TS Packet to carry a PUSI value of 1, and a Payload
Pointer value of 0x00.) Pointer value of 0x00.)
Expires July 2005 [page 21] Expires April 2005 [page 26]
(ii) If the TS Packet carrying the final part of a SNDU has one byte (ii) If the TS Packet carrying the final part of a SNDU has one byte
of unused payload, the Encapsulator MUST place the value 0xFF in of unused payload, the Encapsulator MUST place the value 0xFF in
this final byte, and transmit the TS Packet. This rule provides a this final byte, and transmit the TS Packet. This rule provides a
simple mechanism to resolve the complex behaviour that may arise simple mechanism to resolve the complex behaviour that may arise
when the TS Packet has no PUSI set. To send another SNDU in the 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 current TS Packet, would otherwise require the addition of a Payload
Pointer that would consume the last remaining byte of TS Packet Pointer that would consume the last remaining byte of TS Packet
payload. The behaviour follows similar practice for other MPEG-2 payload. The behaviour follows similar practice for other MPEG-2
payload types [ISO-DSMCC]. The Encapsulator MUST start transmission payload types [ISO-DSMCC]. The Encapsulator MUST start transmission
of the next SNDU in a new TS Packet. (The standard rules require the of the next SNDU in a new TS Packet. (The standard rules require the
skipping to change at line 1059 skipping to change at line 1229
available, an Encapsulator MAY wait for additional PDUs to fill the available, an Encapsulator MAY wait for additional PDUs to fill the
incomplete TS Packet. The maximum period of time an Encapsulator can incomplete TS Packet. The maximum period of time an Encapsulator can
wait, known as the Packing Threshold, MUST be bounded and SHOULD be wait, known as the Packing Threshold, MUST be bounded and SHOULD be
configurable in the Encapsulator. If sufficient additional PDUs are configurable in the Encapsulator. If sufficient additional PDUs are
NOT received to complete the TS Packet within the Packing Threshold, NOT received to complete the TS Packet within the Packing Threshold,
the Encapsulator MUST insert an End Indicator (using rule iv). the Encapsulator MUST insert an End Indicator (using rule iv).
Use of the Packing method (v) by an Encapsulator is optional, and Use of the Packing method (v) by an Encapsulator is optional, and
may be determined on a per-session, per-packet, or per-SNDU basis. may be determined on a per-session, per-packet, or per-SNDU basis.
Expires July 2005 [page 22] Expires April 2005 [page 27]
When a SNDU is less than the size of a TS Packet payload, a TS When a 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 Indicator (using rule iv). End Indicator (using rule iv).
Expires July 2005 [page 23] Expires April 2005 [page 28]
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 and sets a receive
filter to accept all TS Packets with a specific PID. These TS filter to accept all TS Packets with a specific PID. These TS
Packets are associated with a specific TS Logical Channel and are Packets are associated with a specific TS Logical Channel and are
reassembled to form a stream of SNDUs. A single Receiver may be reassembled to form a stream of SNDUs. A single Receiver may be
able to receive multiple TS Logical Channels, possibly using a range able to receive multiple TS Logical Channels, possibly using a range
of TS Multiplexes. In each case, reassembly MUST be performed 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
skipping to change at line 1119 skipping to change at line 1289
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 24] Expires April 2005 [page 29]
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 from discard the number of bytes indicated by the Payload Pointer from
the start of the TS Packet payload, before leaving the Idle State. the start of the TS Packet payload, before leaving the Idle State.
It then enters the Reassembly State, and starts reassembly of a new It then enters the Reassembly State, and starts reassembly of a new
SNDU at this point. SNDU at this point.
skipping to change at line 1145 skipping to change at line 1315
or equal to 4, or equal to 0xFFFF, the Receiver discards the Current or equal to 4, or equal to 0xFFFF, the Receiver discards the Current
SNDU and the remaining TS Packet payload and returns to the Idle SNDU and the remaining TS Packet payload and returns to the Idle
State. Receipt of an invalid Length Field is an error event and State. Receipt of an invalid Length Field is an error event and
SHOULD be recorded as an SNDU length error. SHOULD be 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 Packet is reached (see also 7.2.1). When Current SNDU length TS Packet is reached (see also 7.2.1). When 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 verify the CRC value (see 4.6). SNDUs that contain an invalid and verify the CRC value (section 4.6). SNDUs that contain an
CRC value MUST be discarded. Mismatch of the CRC is an error event invalid CRC value MUST be discarded. Mismatch of the CRC is an error
and SHOULD be recorded as a CRC error. The under-lying physical-* event and SHOULD be recorded as a CRC error. The under-lying
layer processing (e.g. forward error correction coding) often physical-layer processing (e.g. forward error correction coding)
results in patterns of errors, rather than since bit errors, so the often results in patterns of errors, rather than since bit errors,
Receiver needs to be robust to arbitrary patterns of corruption to so the Receiver needs to be robust to arbitrary patterns of
the TS Packet and payload, including potential corruption of the corruption to the TS Packet and payload, including potential
PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD corruption of the PUSI, PP, and SNDU Length fields. Therefore, a
discard the remaining TS Packet payload (if any) following a CRC Receiver SHOULD discard the remaining TS Packet payload (if any)
mismatch and return to the Idle State. following a CRC musmatch and 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 MUST
silently discard an SNDU with an unmatched address. 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 a SNDU type error. recorded as a SNDU type error.
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.
Expires July 2005 [page 25] Expires April 2005 [page 30]
(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
skipping to change at line 1224 skipping to change at line 1394
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-MPEG]. If two (or more) successive TS Packets TS Packet header [ISO-MPEG]. 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
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.
Expires July 2005 [page 26] Expires April 2005 [page 31]
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-MPEG], which are normally detected by the duplicate TS Packets [ISO-MPEG], 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 27] Expires April 2005 [page 32]
8. Summary 8. Summary
This document defines an Ultra Lightweight Encapsulation (ULE) to This document defines an Ultra Lightweight Encapsulation (ULE) to
perform efficient and flexible support for IPv4 and IPv6 network perform efficient and flexible support for IPv4 and IPv6 network
services over networks built upon the MPEG-2 Transport Stream (TS). services over networks built upon the MPEG-2 Transport Stream (TS).
The encapsulation is also suited to transport of other protocol The encapsulation is also suited to transport of other protocol
packets and bridged Ethernet frames. 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 capability with extension of the protocol, while providing backwards capability with
existing implementations. In particular, Optional Extension Headers existing implementations. In particular, Optional Extension Headers
may safely be ignored by Receiver drivers that do not implement may safely be ignored by drivers that do not implement them, or
them, or choose not to process them. choose not to process them.
9. Acknowledgments 9. Acknowledgments
This draft is based on a previous draft authored by: Horst D. This draft is based on a previous draft authored by: Horst D.
Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry
Fairhurst. The authors wish to thank the members of the ip-dvb Fairhurst. The authors wish to thank the members of the ip-dvb
mailing list for their input provided. In particular, the many mailing list for their input provided. In particular, the many
comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar
Linder, Alain Ritoux, and William Stanislaus. Alain also provided Linder, Alain Ritoux, and William Stanislaus. Alain also provided
the original examples of usage. the original examples of usage.
Expires July 2005 [page 28] Expires April 2005 [page 33]
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 exiting 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 bridged networking environment. The removal for bridged frames a 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 ULE, this is avoided by
IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length including only one SNDU Length Field. However, this issue still
Field. However, this issue still arises in bridged LLC frames, and arises in bridged LLC frames, and frames with a LLC Length greater
frames with a LLC Length greater than the SNDU payload size MUST be than the SNDU payload size MUST be discarded, and a SNDU payload
discarded, and a SNDU payload length error SHOULD be recorded. length error SHOULD be recorded.
A ULE Mandatory Extension Header may in future be used to define a ULE supports optional link level encryption of the SNDU payload.
method to perform link encryption of the SNDU payload. This is as an This is as an additional security mechanism to IP, transport or
additional security mechanism to IP, transport or application layer application layer security - not a replacement [ID-ipdvb-arch]. The
security - not a replacement [ID-ipdvb-arch]. The approach is approach is generic and decouples the encapsulation from future
generic and decouples the encapsulation from future security security extensions. The operation provides functions that resemble
extensions. The operation provides functions that resemble those those currently used with the MPE encapsulation.
currently used with the MPE encapsulation.
Additional security control fields may be provided as a part of this A ULE Mandatory Extension Header may in future be used to define a
link encryption Extension Header, e.g. to associate an SNDU with one method to perform link encryption. Additional security control
of a set of Security Association (SA) parameters. As a part of the fields may be provided as a part of the Extension Header, e.g. to
encryption process, it may also be desirable to authenticate associate an SNDU with one of a set of Security Association (SA)
some/all of the SNDU headers. The method of encryption and the way parameters. As a part of the encryption process, it may also be
in which keys are exchanged is beyond the scope of this desirable to authenticate some/all of the SNDU headers. The method
specification, as also are the definition of the SA format and that of encryption and the way in which keys are exchanged is beyond the
of the related encryption keys. scope of this specification, as also are the definition of the SA
format and that of the related encryption keys.
Expires July 2005 [page 29] Expires April 2005 [page 34]
11. References 11. References
11.1 Normative References 11.1 Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic
coding of moving pictures and associated audio information: coding of moving pictures and associated audio information:
Systems", International Standards Organisation (ISO). Systems", International Standards Organisation (ISO).
[RFC2026] Bradner, S., "The Internet Standards Process - Revision [RFC2026] Bradner, S., "The Internet Standards Process - Revision
skipping to change at line 1334 skipping to change at line 1504
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
11.2 Informative References 11.2 Informative References
[ID-ipdvb-arch] "Requirements for transmission of IP datagrams over [ID-ipdvb-arch] "Requirements for transmission of IP datagrams over
MPEG-2 networks", Internet Draft, Work in Progress. MPEG-2 networks", Internet Draft, Work in Progress.
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53 Rev.C, 2004 Systems Committee (ATSC), Doc. A/53, 1995.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/090, 2000. Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC), Doc. A/91, 2001. Committee (ATSC), Doc. A/91, 2001.
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
skipping to change at line 1358 skipping to change at line 1528
Terrestrial Broadcast and Cable", Advanced Television Systems Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A, 2000. Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A, 2000.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems (DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 1999. Committee (ATSC), Doc. A/80, 1999.
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
Expires July 2005 [page 30] Expires April 2005 [page 35]
[ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV)", interaction channel for Cable TV distribution systems (CATV)",
European Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation
and Coding for DBS satellite systems at 11/12 GHz", European and Coding for DBS satellite systems at 11/12 GHz", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI).
skipping to change at line 1398 skipping to change at line 1568
1985. 1985.
[RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
Layer Tunneling Mechanism for Unidirectional Links", RFC3077, Layer Tunneling Mechanism for Unidirectional Links", RFC3077,
Proposed Standard, 2001. Proposed Standard, 2001.
[RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control
Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed
Standard, 2001. Standard, 2001.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Expires April 2005 [page 36]
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
"Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July
2004.
Expires July 2005 [page 31]
12. Authors' Addresses 12. Authors' Addresses
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
University of Aberdeen University of Aberdeen
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry Web: http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker Bernhard Collini-Nocker
Department of Scientific Computing Department of Scientific Computing
University of Salzburg University of Salzburg
Jakob Haringer Str. 2 Jakob Haringer Str. 2
5020 Salzburg 5020 Salzburg
Austria Austria
Email: bnocker@cosy.sbg.ac.at Email: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/ Web: http://www.scicomp.sbg.ac.at/
Expires July 2005 [page 32] Expires April 2005 [page 37]
13. IPR Notices 13. IPR Notices
13.1 Intellectual Property Statement 13.1 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
skipping to change at line 1468 skipping to change at line 1633
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Copyright Statement 14. Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all BCP 78, and except as set forth therein, the authors retain all
their rights. their rights.
Expires July 2005 [page 33] Expires April 2005 [page 38]
15. IANA Considerations 15. IANA Considerations
This document will require IANA involvement. This document will require IANA involvement.
The ULE Next-Header type field defined in this document requires The ULE Next-Header type field defined in this document requires a
creation of a registry: registry:
ULE Next-Header registry ULE Next-Header registry
This registry allocates values 0-512 (decimal). This registry allocates values 0-512 (decimal).
15.1 IANA Guidelines 15.1 IANA Guidelines
The following contains the IANA guidelines for management of the ULE The following contains the IANA guidelines for management of the ULE
Next-Header registry. This registry allocates values 0-512 decimal Next-Header registry. This registry allocates values decimal 0-512
(0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater
than 0x01FF (decimal). than 0x01FF (decimal).
It subdivides the Next-Header registry in the following way: It subdivides the Next-Header registry in the following way:
1) 0-255 (decimal) IANA assigned values indicating Mandatory 1) 0-255 (decimal) IANA assigned values indicating Mandatory
Extension Headers (or link-dependent type fields) for ULE, Extension Headers (or link-dependent type fields) for ULE,
requiring expert review leading to prior issue of an IETF RFC. requiring expert review leading to prior issue of an IETF RFC.
This specification must define the value, and the name associated This specification must define the value, and the name associated
with the Extension Header. It must also define the need for the with the Extension Header. It must also define the need for the
skipping to change at line 1518 skipping to change at line 1683
entry must specify range of allowable H-LEN values that are entry must specify range of allowable H-LEN values that are
permitted (in the range 1-5). It must also define the need for the permitted (in the range 1-5). It must also define the need for the
extension and the intended use. extension and the intended use.
Assignments made in this document: Assignments made in this document:
Type Name H-LEN Reference Type Name H-LEN Reference
256: Extension-Padding 1-5 Section 5. 256: Extension-Padding 1-5 Section 5.
Expires July 2005 [page 34] Expires April 2005 [page 39]
ANNEXE A: Informative Appendix - SNDU Packing Examples ANNEXE A: Informative Appendix
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-MPEG]. The specification of ULE is provided in is provided in [ISO-MPEG]. The specification of ULE is provided in
the body of this document. the body of this document.
skipping to change at line 1566 skipping to change at line 1731
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 35] Expires April 2005 [page 40]
Example A.2: Usage of last byte in a TS-Packet Example A.2: Usage of last byte in a TS-Packet
SNDU A is 183 bytes SNDU A is 183 bytes
SNDU B is 182 bytes SNDU B is 182 bytes
SNDU C is 181 bytes SNDU C is 181 bytes
SNDU D is 185 bytes SNDU D is 185 bytes
The sequence comprises 4 TS Packets: The sequence comprises 4 TS Packets:
SNDU SNDU
skipping to change at line 1603 skipping to change at line 1768
| HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 |
+-----+---*--+-*----+------+- -+------+------+------+ +-----+---*--+-*----+------+- -+------+------+------+
PUSI=1 * * PUSI=1 * *
****** Unused ****** Unused
byte byte
+-----+------+- -+------+------+ +-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF | | HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+ +-----+------+- -+------+------+
PUSI=0 PUSI=0
Expires July 2005 [page 36] Expires April 2005 [page 41]
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 1649 skipping to change at line 1814
+-----+------+- -+------+ +-----+------+- -+------+
PUSI=0 PUSI=0
End Stuffing End Stuffing
Indicator Bytes Indicator Bytes
+-----+------+- -+------+------+------+- -+------+ +-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF | | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+ +-----+------+- -+------+------+------+- -+------+
PUSI=0 PUSI=0
Expires July 2005 [page 37] Expires April 2005 [page 42]
Example A.4: Packing of SNDUs Example A.4: Packing of SNDUs
SNDU A is 200 bytes SNDU A is 200 bytes
SNDU B is 60 bytes SNDU B is 60 bytes
SNDU C is 60 bytes SNDU C is 60 bytes
The sequence comprises two TS Packets: The sequence comprises two TS Packets:
SNDU SNDU
PP=0 Length PP=0 Length
skipping to change at line 1690 skipping to change at line 1855
+ ... | 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 38] Expires April 2005 [page 43]
Example A.5: Three 44B PDUs. Example A.5: Three 44B PDUs.
SNDU A is 52 bytes (no destination MAC address) SNDU A is 52 bytes (no destination MAC address)
SNDU B is 52 bytes (no destination MAC address) SNDU B is 52 bytes (no destination MAC address)
SNDU C is 52 bytes (no destination MAC address) SNDU C is 52 bytes (no destination MAC address)
The sequence comprises 1 TS Packet: The sequence comprises 1 TS Packet:
SNDU SNDU
PP=0 Length PP=0 Length
skipping to change at line 1713 skipping to change at line 1878
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
PUSI=1 * * PUSI=1 * *
***** *****
End Stuffing End Stuffing
Indicator bytes Indicator bytes
-----+------+- -+-----+---------+- -+------+ -----+------+- -+-----+---------+- -+------+
... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF |
-*---+------+- -+-----+---------+- -+------+ -*---+------+- -+-----+---------+- -+------+
Expires July 2005 [page 39] Expires April 2005 [page 44]
ANNEXE B: Informative Appendix - SNDU Encapsulation ANNEXE 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 Present) D-bit value : 0 (NPA Present)
ULE Protocol Type : 0x86dd (IPv6) ULE Protocol Type : 0x86dd (IPv6)
Destination ULE NPA Address: 00:01:02:03:04:05 Destination ULE NPA Address: 00:01:02:03:04:05
ULE CRC32 : 0x4709a744 ULE CRC32 : 0x4709a744
skipping to change at line 1736 skipping to change at line 1901
Destination IPv6: 2001:660:3008:1789::6 Destination IPv6: 2001:660:3008:1789::6
SNDU contents (including CRC-32): SNDU contents (including CRC-32):
0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d 0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d
0016: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0016: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00
0032: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0032: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00
0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47 0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47
0064: 09 a7 44 0064: 09 a7 44
Expires July 2005 [page 40] Expires April 2005 [page 45]
[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).
* Procedure for TS Packet carrying the final part of a 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 a 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 41]
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 42]
* 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 43]
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 44]
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
Expires July 2005 [page 45]
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 18181-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.
[END of RFC EDITOR NOTE]
Expires July 2005 [page 46]
 End of changes. 

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