draft-ietf-ipdvb-ule-01.txt   draft-ietf-ipdvb-ule-02.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-01.txt Bernhard Collini-Nocker Document: draft-ietf-ipdvb-ule-02.txt Bernhard Collini-Nocker
University of Salzburg, A University of Salzburg, A
ipdvb WG ipdvb WG
Category: Draft Intended Standards Track May 2004 Category: Draft, Intended Standards Track October 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
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet-Drafts as
as reference material or to cite them other than as "work in reference material or to cite them other than as "work in progress".
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The MPEG-2 TS has been widely accepted not only for providing The MPEG-2 TS has been widely accepted not only for providing
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. 2 Transport Streams (TS) as TS Private Data. ULE supports an
extension format that allows it to carry both optional (with an
explicit extension length) and mandatory (with an implicit extension
length) header information to assist in network/Receiver processing
of a SNDU.
Expires November 2004 [page 1] Expires April 2005 [page 1]
[RFC EDITOR NOTE: [RFC EDITOR NOTE:
This section must be deleted prior to publication] This section must be deleted prior to publication]
DOCUMENT HISTORY DOCUMENT HISTORY
Draft -00 Draft 00
This draft is intended as a study item for proposed future work by This draft is intended as a study item for proposed future work by
the IETF in this area. Comments relating to this document will be the IETF in this area. Comments relating to this document will be
gratefully received by the author(s) and the ip-dvb mailing list at: gratefully received by the author(s) and the ip-dvb mailing list at:
ip-dvb@erg.abdn.ac.uk ip-dvb@erg.abdn.ac.uk
-------------------------------------------------------------------- --------------------------------------------------------------------
DRAFT 01 (Protocol update) DRAFT 01 (Protocol update)
* Padding sequence modified to 0xFFFF, this change aligns with other * Padding sequence modified to 0xFFFF, this change aligns with other
usage by MPEG-2 streams. Treatment remains the same as specified for usage by MPEG-2 streams. Treatment remains the same as specified for
skipping to change at line 89 skipping to change at line 94
* Type field split into two. * Type field split into two.
* References updated. * References updated.
* Security considerations added (first draft). * Security considerations added (first draft).
* Appendix added with examples. * Appendix added with examples.
-------------------------------------------------------------------- --------------------------------------------------------------------
Expires November 2004 [page 2] Expires December 2004 [page 2]
DRAFT - 02 (Improvement of clarity) DRAFT - 02 (Improvement of clarity)
* Corrected CRC-32 to follow standard practice in DSM-CC. * Corrected CRC-32 to follow standard practice in DSM-CC.
* Removed LLC frame type, now redundant by Bridge-Type (==1) * Removed LLC frame type, now redundant by Bridge-Type (==1)
* Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain,
Bernhard Bernhard
* Changes to description of minimum payload length. - Gorry * Changes to description of minimum payload length. Gorry
* MPEG-2 Error Indicator SHOULD be used - Hilmar & Gorry * MPEG-2 Error Indicator SHOULD be used.Hilmar & Gorry
* MPEG-2 CC MAY be used (since CRC-32 is strong anyway) - Hilmar & * MPEG-2 CC MAY be used (since CRC-32 is strong anyway). Hilmar &
Gorry Gorry
* Corrected CRC-32 to now follow standard practice in DSM-CC - * Corrected CRC-32 to now follow standard practice in DSM-CC. Gorry,
Gorry, Hilmar, Alain. Hilmar, Alain.
* Changed description of Encapsulator action for Packing, Gorry & * Changed description of Encapsulator action for Packing. Gorry &
Hilmar. Hilmar.
* Changed description of Receiver to clarify packing, Gorry & Alain. * Changed description of Receiver to clarify packing. Gorry & Alain.
* Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG - * Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG.
Hilmar/Bernhard. Hilmar/Bernhard.
* Recommend removal of section on Flushing bit stream - Gorry * Recommend removal of section on Flushing bit stream. Gorry
* Updated SNDU figures to reflect D-bit and correct a mistake in the * Updated SNDU figures to reflect D-bit and correct a mistake in the
bridged type field - Alain bridged type field. Alain
* Reorganised section 5 to form sections 5 and 6, separating * Reorganised section 5 to form sections 5 and 6, separating
encapsulation and receiver processing - Gorry, Hilmar, Alain. encapsulation and receiver processing. Gorry, Hilmar, Alain.
* Added concept of Idle State and Reassembly State to the Receiver. * Added concept of Idle State and Reassembly State to the Receiver.
Renumbered sections 5,6 and following, - Gorry. Renumbered sections 5,6 and following. Gorry.
* Nits from Alain, Hilmar and Gorry. * Nits from Alain, Hilmar and Gorry.
Moved security issue on the design of the protocol to appropriate Moved security issue on the design of the protocol to appropriate
sections, since this is not a concern for deployment: Length field sections, since this is not a concern for deployment: Length field
usage and padding initialisation. usage and padding initialisation.
* Changed wording: All multi-byte values in ULE (including Length, * Changed wording: All multi-byte values in ULE (including Length,
Type, and Destination fields) are transmitted in network byte order Type, and Destination fields) are transmitted in network byte order
(most significant byte first) - old NiT from Alain, now fixed. (most significant byte first). old NiT from Alain, now fixed.
* Frame byte size in diagrams now updated to -standard- format, and * Frame byte size in diagrams now updated to -standard- format, and
D bit action corrected, as requested by Alain. D bit action corrected, as requested by Alain.
Expires November 2004 [page 3] Expires December 2004 [page 3]
* Frame format diagrams, redrawn to 32-bit format below: * Frame format diagrams, redrawn to 32-bit format below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* Additional diagram requested by Alain for D=0 bridging (added, and * Additional diagram requested by Alain for D=0 bridging (added, and
subsequent figures renumbered). subsequent figures renumbered).
* Diagrams of encapsulation process, redrawn for clarity (no change * Diagrams of encapsulation process, redrawn for clarity (no change
to meaning) - Gorry. to meaning). Gorry.
* Reworded last para of CRC description. * Reworded last para of CRC description.
* Clarification to the statements in the CRC coverage - to make it * Clarification to the statements in the CRC coverage - to make it
clear that it is the entire SNDU (header AND payload) that is clear that it is the entire SNDU (header AND payload) that is
checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at). checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at).
* References added for RCS (spotted by Alain) and AAL5 (provided by * References added for RCS (spotted by Alain) and AAL5 (provided by
Anthony Ang). Anthony Ang).
* Removed informative reference to MPEG part 1 - Alain. * Removed informative reference to MPEG part 1.Alain.
Spelling correction -> Allain to Alain. Spelling correction -> Allain to Alain.
* Added description of Receiver processing of the address field.- * Added description of Receiver processing of the address
Gorry field.Gorry
* Added caution on LLC Length in bridged Packets thanks - * Added caution on LLC Length in bridged Packets thanks.
Gorry/wolfgang Gorry/wolfgang
* Removed Authors notes from text after their discussion on the list * Removed Authors notes from text after their discussion on the list
- Gorry, Gorry
* Corrected text to now say maximum value of PP = 182 in ULE - * Corrected text to now say maximum value of PP = 182 in ULE. Gorry
Gorry,
* Tidied diagrams at end (again) - Gorry, * Tidied diagrams at end (again) - Gorry,
Revision with following changes: Revision with following changes:
* Re issue as working group draft (filename change) * Re issue as working group draft (filename change)
* Refinement of the text on CRC generation to be unambiguous. * 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 Encapsulator (B C-N/GF/A.Allison)
* Revised CC processing at Receiver (from List: A.Allison; et al ) * Revised CC processing at Receiver (from List: A.Allison; et al )
* Corrections to length/PP field in Examples (M Sooriyabandara, * Corrections to length/PP field in Examples (M Sooriyabandara,
Alain) Alain)
* Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit) * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit)
* Section 4.5 only SHARED routed links require D=0 * Section 4.5 only SHARED routed links require D=0
* Packing Threshold defined * Packing Threshold defined
* Next-Layer-Header defined * Next-Layer-Header defined
* Addition of Appendix B (to aide verification of SNDFU format) * Addition of Appendix B (to aide verification of SNDFU format)
Expires November 2004 [page 4]
Working Group ID rev 01 Working Group ID rev 01
Issues addressed: Issues addressed:
* Typographical * Typographical
Expires December 2004 [page 4]
* Types > 1500 should be passed to the next higher protocol (Hilmar) * Types > 1500 should be passed to the next higher protocol (Hilmar)
* The second part of the Type space corresponds to the values 1500 * The second part of the Type space corresponds to the values 1500
COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF. COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF.
* IANA has already defined IP and IPv6 types - corrected text! * IANA has already defined IP and IPv6 types - corrected text!
Added more security considerations (-01d). Added more security considerations (-01d).
* Should we allow an Adaptation Field within ULE (request for DVB- * Should we allow an Adaptation Field within ULE (request for DVB-
RCS compatibility)? Requirement to be clarified! Implementation RCS compatibility)? Requirement to be clarified! Implementation
impact to be evaluated! impact to be evaluated!
Current Recommendation: The current spec does not preclude use of Current Recommendation: The current spec does not preclude use of
AF, it simply says that this is not the standard for ULE. The use- 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 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 this there is no current intention to add this to ULE - text for
requirements would be welcome. requirements would be welcome.
* Verify the minimum value allocated to DIX Ethernet Header Types. * Verify the minimum value allocated to DIX Ethernet Header Types.
Draft updated to align with IEEE Registry assignments. Draft updated to align with IEEE Registry assignments.
Expires November 2004 [page 5] --------------------------------------------------------------------
Issues pending working group consensus:
1) Query about the code point value for an Ethernet Bridging SNDU - Working Group ID rev 02
should the ULE type-field be 0x0001; 0x0007; or should the IEEE
Ethertype for bridging be used instead?
Author Note: This may depend on other assignments, to be
determined.
2) Should we allow configuration of an optional non-default CC Revised IPR disclosure
processing??? Revised copyright notice
3) Consider amendment to ULE to define optional extension headers Section 5 added to ULE to define optional extension headers (see
(various proposals) xule)
Author Note: Design trade-offs need to be considered.
Current Recommendation: Document to be produced with concrete
proposal.
4) Should ULE support FEC? Correction of figure numbering.
Author Note 1: No concrete proposal yet, although this seems within Correction to capitalisation in Transport Stream definition of fields
the scope of the use of extension headers. Inserted space character after 1536 in line 2 of 4.4.2
Author Note 2: Text is required for the requirements ID so this may Replaced } with ] after ISO_DSMCC
first be updated to reflect the need for this option. Replace reference to section 6.3 with section 7.3 at end of section
Current Recommendation: No change to ULE Spec, but extensions may 4.6.
subsequently be defined to support this - text would be welcome to Reference in 4.7.4 was changed to refer to figure 7 (not 6).
requirements documents on why and what should be added. Note added after figure 9.
5) Should ULE support Encryption? 7.2 Changed, New text: <<SNDUs that contain an invalid CRC value MUST
Author Note: In principle, this is just a code-point issue, since we be discarded, causing the Receiver to processes the next in-sequence
only defining an encapsulation here. This seems within the scope of SNDU (if any).>> The rationale is that the this a SNDU-integrity
the use of type fields. check - rather than a framing issue. The mantra of being liberal in
Author Note 2: Text is required for the requirements ID so this may what is accepted suggests we discard, but not that we also discard
first be updated to reflect the need for this option (some inputs succeeding SNDUs.
from L. Claverotte/H. Cruickshank/et al).
6) Do we need to define OPTIONAL extension header fields to allow Known issues with this revision of the document:
Receivers backwards compatibility with unknown options?
(i) The worked hexadecimal example in the annexe needs to be
reworked.
(ii) The IANA procedures need to be checked with IANA.
(iii) Format page breaks in next rev!
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
Expires November 2004 [page 6] Expires December 2004 [page 5]
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 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: IANA Assigned Type Fields 4.4.1 Type 1: IANA Assigned 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 4.7.4 Test SNDU
5. Processing at the Encapsulator 5. Extension Headers
5.1 SNDU Encapsulation 5.1 Mandatory Extension Header
5.2 Procedure for Padding and Packing 5.2 Optional Extension Header
6. Receiver Processing 6.Processing at the Encapsulator
6.1 Idle State 6.1 SNDU Encapsulation
6.1.1 Reassembly Payload Pointer Checking 6.2 Procedure for Padding and Packing
6.2 Processing of a Received SNDU 7. Receiver Processing
6.2.1 Reassembly Payload Pointer Checking 7.1 Idle State
6.3 Other Error Conditions 7.1.1 Reassembly Payload Pointer Checking
7. Summary 7.2 Processing of a Received SNDU
8. Acknowledgments 7.2.1 Reassembly Payload Pointer Checking
9. Security Considerations 7.3 Other Error Conditions
10. References 8. Summary
10.1 Normative References 9. Acknowledgments
10.2 Informative References 10. Security Considerations
11. Authors' Addresses 11. References
12. IANA Considerations 11.1 Normative References
11.2 Informative References
12. Authors' Addresses
13. IPR Notices
14. Copyright Statement
14.1 Intellectual Property Statement
14.2 Disclaimer of Validity
15. IANA Considerations
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 November 2004 [page 7] Expires December 2004 [page 6]
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
link layer standards. Support has been defined for a wide range of link layer standards. Support has been defined for a wide range of
skipping to change at line 318 skipping to change at line 327
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) by adding an encapsulation header and a Subnetwork Data Unit (SNDU) by adding an encapsulation header and
an integrity check trailer. The SNDU is fragmented into a series of an integrity check trailer. The SNDU is fragmented into a series of
TS Packets) that are sent over a single TS Logical Channel. TS Packets) that are sent over a single TS Logical Channel.
Expires November 2004 [page 8] Expires December 2004 [page 7]
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, a pair of bits carried in the TS AFC: Adaptation Field Control, a pair of bits carried in the TS
Packet header that signal the presence of the Adaptation Field Packet header that signal the presence of the Adaptation Field
and/or TS Packet payload. and/or TS Packet payload.
skipping to change at line 371 skipping to change at line 381
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 (similar to an Ethernet MAC address) within the destination address (similar to an Ethernet MAC address) within the
MPEG-2 transmission network used to identify individual Receivers or MPEG-2 transmission network used to identify individual Receivers or
groups of Receivers. groups of Receivers.
Expires November 2004 [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 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
Expires December 2004 [page 8]
PES: Packetized Elementary Stream of MPEG-2 [ISO-MPEG]. PES: Packetized Elementary Stream of MPEG-2 [ISO-MPEG].
PID: Packet Identifier. A 13 bit field carried in the header of TS PID: Packet Identifier. A 13 bit field carried in the header of TS
Packets. This is used to identify the TS Logical Channel to which a 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 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 Table Section, PES, or other payload unit must all carry the same
PID value. The all 1s PID value indicates a Null TS Packet PID value. The all 1s PID value indicates a Null TS Packet
introduced to maintain a constant bit rate of a TS Multiplex. introduced to maintain a constant bit rate of a TS Multiplex.
PP: Payload Pointer. An optional one byte pointer that directly PP: Payload Pointer. An optional one byte pointer that directly
skipping to change at line 422 skipping to change at line 432
PSI: Program Specific Information. Tables used to convey information PSI: Program Specific Information. Tables used to convey information
about the service carried in a TS Multiplex. The set of PSI tables about the service carried in a TS Multiplex. The set of PSI tables
is defined by [ISO-MPEG], see also SI Table. is defined by [ISO-MPEG], see also SI Table.
SI TABLE: Service Information Table. In this document, this term SI TABLE: Service Information Table. In this document, this term
describes any table used to convey information about the service describes any table used to convey information about the service
carried in a TS Multiplex. SI tables are carried in MPEG-2 private carried in a TS Multiplex. SI tables are carried in MPEG-2 private
sections. sections.
Expires November 2004 [page 10]
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit. Payload Unit.
TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table. 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 as illustrated in the TS HEADER: The 4 byte header of a TS Packet as illustrated in the
introduction. introduction.
TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel
identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of
the ISO/OSI reference model. All packets sent over a TS Logical the ISO/OSI reference model. All packets sent over a TS Logical
Channel carry the same PID value. According to MPEG-2, some TS Channel carry the same PID value. According to MPEG-2, some TS
Logical Channels are reserved for specific signalling purposes. Logical Channels are reserved for specific signalling purposes.
Expires December 2004 [page 9]
Other standards (e.g., ATSC, DVB) also reserve specific TS Logical Other standards (e.g., ATSC, DVB) also reserve specific TS Logical
Channels. Channels.
TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single
common physical link (i.e. a transmission at a specified symbol 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). The same TS Logical
Channel may be repeated over more than one TS Multiplex, for example Channel may be repeated over more than one TS Multiplex, for example
to redistribute the same multicast content to two terrestrial TV to redistribute the same multicast content to two terrestrial TV
transmission cells. transmission cells.
TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex
[ISO-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 Transport Streams. stamp information to synchronise a set of related Transport Streams.
The 188B TS Packets incorporate a 4B header with the following The 188B TS Packets incorporate a 4B header with the following
fields, those referenced within this document marked with “*”: fields (those referenced within this document are marked with *):
Field Length Name/Purpose Field Length Name/Purpose
(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 *2b Adaptation Field Control (AFC)
*4b continuity counter (CC) *4b Continuity Counter (CC)
Expires December 2004 [page 10]
Expires November 2004 [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
known as Packing. All TS Packets comprising a SNDU MUST be assigned known as Packing. All TS Packets comprising a SNDU MUST be assigned
skipping to change at line 521 skipping to change at line 534
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. The purpose of the adaptation field is primarily to (AFC) value. The purpose of the adaptation field is primarily to
extend the TS header for timing and synchronisation information and extend the TS header for timing and synchronisation information and
may be used to also include stuffing bytes before a TS Packet may be used to also include stuffing bytes before a TS Packet
payload. Standard Receivers discard TS Packets with an payload. Standard Receivers discard TS Packets with an
adaptation_field_control field value of '00'. Adaptation Field adaptation_field_control field value of '00'. Adaptation Field
stuffing is NOT used in this encapsulation method, and TS Packets stuffing is NOT used in this encapsulation method, and TS Packets
from a ULE Encapsulator MUST be sent with an AFC value of '01'. from a ULE Encapsulator MUST be sent with an AFC value of '01'.
Receivers MUST discard TS Packets that carry other AFC values. Receivers MUST discard TS Packets that carry other AFC values.
Expires November 2004 [page 12] Expires December 2004 [page 11]
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 sent as 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 |
+-+-------------------------------------------------------+--------+ +-+-------------------------------------------------------+--------+
skipping to change at line 562 skipping to change at line 576
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 1’s length combined with a D-bit denotes an End Indicator (i.e., all 1s length combined with a D-bit
value of 1). It indicates to the Receiver that there are no further value of 1). It indicates to the Receiver that there are no further
SNDUs present within the current TS Packet (see section 6), and that SNDUs present within the current TS Packet (see section 6), and that
no Destination Address Field is present. The value 0xFF has specific no Destination Address Field is present. The value 0xFF has specific
semantics in MPEG-2 framing, where it is used to indicate the semantics in MPEG-2 framing, where it is used to indicate the
presence of Padding. This use resembles [ISO-DSMCC]. presence of Padding. This use resembles [ISO-DSMCC].
Expires November 2004 [page 13] Expires December 2004 [page 12]
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 621 skipping to change at line 635
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.
The following types are defined: The following types are defined:
[XXX IANA ACTION REQUIRED XXX] [XXX IANA ACTION REQUIRED XXX]
0x0000: Test SNDU, discarded by the Receiver. 0x0000: Test SNDU, discarded by the Receiver.
Expires November 2004 [page 14]
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.
[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 allocation by the IANA. reserved for allocation by the IANA.
[Author NOTE: Type allocation and appropriate IANA Procedure to be Expires December 2004 [page 13]
determined.]
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 The second part of the Type space corresponds to the values 1536
1536Decimal (0x600) and 0xFFFF. This set of type assignments follow Decimal (0x600) and 0xFFFF. This set of type assignments follow
DIX/IEEE assignments (but exclude use of this field as a frame DIX/IEEE assignments (but exclude use of this field as a frame
length indicator) [LLC]. All assignments in this space MUST use the length indicator) [LLC]. All assignments in this space MUST use the
values defined for IANA EtherType, the following two Type values are values defined for IANA EtherType, the following two Type values are
used as examples (taken from the IANA Ethertypes registry): used as examples (taken from the IANA Ethertypes registry):
0x0800 : IPv4 Payload 0x0800 : IPv4 Payload
0x86DD : IPv6 Payload 0x86DD : IPv6 Payload
4.5 SNDU Destination Address Field 4.5 SNDU Destination Address Field
skipping to change at line 668 skipping to change at line 679
directly follows the SNDU Type Field. NPA destination addresses are directly follows the SNDU Type Field. NPA destination addresses are
6 Byte numbers, normally expressed in hexadecimal, used to identify 6 Byte numbers, normally expressed in hexadecimal, used to identify
the Receiver(s) in a MPEG-2 transmission network that should process the Receiver(s) in a MPEG-2 transmission network that should process
a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as
a destination address in a SNDU. The least significant bit of the a destination address in a SNDU. The least significant bit of the
first byte of the address is set to 1 for multicast frames, and the first byte of the address is set to 1 for multicast frames, and the
remaining bytes specify the link layer multicast address. The remaining bytes specify the link layer multicast address. The
specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address,
indicating this SNDU is to be delivered to all Receivers. indicating this SNDU is to be delivered to all Receivers.
Expires November 2004 [page 15] Expires December 2004 [page 14]
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 0x04C11DB7 in hexadecimal: generator polynomial represented 0x04C11DB7 in hexadecimal:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0. x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
The Encapsulator initialises the CRC-32 accumulator register to the The Encapsulator initialises the CRC-32 accumulator register to the
value 0xFFFF FFFF. It then accumulates a transmit value for the value 0xFFFF FFFF. It then accumulates a transmit value for the
CRC32 that includes all bytes from the start of the SNDU header to CRC32 that includes all bytes from the start of the SNDU header to
the end of the SNDU (excluding the 32-bit trailer holding the CRC- the end of the SNDU (excluding the 32-bit trailer holding the CRC-
32), and places this in the CRC Field. In ULE, the bytes are 32), and places this in the CRC Field. In ULE, the bytes are
skipping to change at line 707 skipping to change at line 718
table-lookup or hardware-assisted software-based implementations are table-lookup or hardware-assisted software-based implementations are
also possible. Annexe B provides an example of an Encapsulated PDU also possible. Annexe B provides an example of an Encapsulated PDU
that includes the computed CRC-32 value. that includes the computed CRC-32 value.
The primary purpose of this CRC is to protect the SNDU (header, and The primary purpose of this CRC is to protect the SNDU (header, and
payload) from undetected reassembly errors and errors introduced by payload) from undetected reassembly errors and errors introduced by
unexpected software / hardware operation while the SNDU is in unexpected software / hardware operation while the SNDU is in
transit across the MPEG-2 subnetwork and during processing at the transit across the MPEG-2 subnetwork and during processing at the
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 6.3). these may also be detected by other means, e.g. section 7.3).
Expires December 2004 [page 15]
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 directly preceding the PDU. These are inserted in the SNDU directly preceding the PDU.
The following SNDU Formats are defined here: The following SNDU Formats are defined here:
Expires November 2004 [page 16]
End Indicator: The Receiver should enter the Idle State. End Indicator: The Receiver should enter the Idle State.
IPv4 SNDU: The payload is a complete IPv4 datagram IPv4 SNDU: The payload is a complete IPv4 datagram
IPv6 SNDU: The payload is a complete IPv6 datagram. IPv6 SNDU: The payload is a complete IPv6 datagram.
Test SNDU: The payload will be discarded by the Receiver. Test SNDU: The payload will be discarded by the Receiver.
Bridged SNDU: The payload carries a bridged MAC or LLC frame. Bridged SNDU: The payload carries a bridged MAC or LLC frame.
All other formats are currently reserved. All other formats are currently reserved.
Expires November 2004 [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 of 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.
Expires December 2004 [page 16]
4.7.2 IPv4 SNDU 4.7.2 IPv4 SNDU
IPv4 datagrams are transported using one of the two standard SNDU IPv4 datagrams are transported using one of the two standard SNDU
structures, in which the PDU is placed directly in the SNDU payload. structures, in which the PDU is placed directly in the SNDU payload.
The two encapsulations are shown in figures 3 and 4. (Note that in The two encapsulations are shown in figures 3 and 4. (Note that in
this, and the following figures, the IP datagram payload is of this, and the following figures, the IP datagram payload is of
variable size, and is directly followed by the CRC-32). variable size, and is directly followed by the CRC-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
skipping to change at line 771 skipping to change at line 782
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= 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 November 2004 [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).
Expires December 2004 [page 17]
4.7.3 IPv6 SNDU Encapsulation 4.7.3 IPv6 SNDU Encapsulation
IPv6 datagrams are transported using one of the two standard SNDU IPv6 datagrams are transported using one of the two standard SNDU
structures, in which the PDU is placed directly in the SNDU payload. structures, in which the PDU is placed directly in the 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 |
skipping to change at line 824 skipping to change at line 835
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= 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 November 2004 [page 19] Expires December 2004 [page 18]
4.7.4 Test SNDU 4.7.4 Test SNDU
A Test SNDU is of Type 1 (figure 6). 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at line 876 skipping to change at line 887
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
= (Contents of bridged MAC frame) = = (Contents of bridged MAC frame) =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SNDU Format for a Bridged Payload (D=0) Figure 8: SNDU Format for a Bridged Payload (D=0)
Expires November 2004 [page 20] Expires December 2004 [page 19]
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) |
skipping to change at line 898 skipping to change at line 909
| EtherType (2B) | | | EtherType (2B) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
= (Contents of bridged MAC frame) = = (Contents of bridged MAC frame) =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 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
field (see section 5). In this special case, the extension mandatory
header format permits this to carry a LLC Length field, specified by
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 address that does NOT match their own NPA SNDUs that carry an NPA address that does NOT match their own NPA
address (or a broadcast/mcast address), the payload of the remaining address (or a broadcast/mcast address), the payload of the remaining
SNDUs are processed by the bridging rules that follow. An SNDU SNDUs are processed by the bridging rules that follow. An SNDU
without an NPA address (D=1) results in a Receiver performing without an NPA address (D=1) results in a Receiver performing
bridging processing on the payload of all received SNDUs. bridging processing on the payload of all 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
skipping to change at line 929 skipping to change at line 946
the sender to be aware of such Ethernet padding. the sender to be aware of such Ethernet padding.
Ethernet frames received at the Encapsulator for onward transmission Ethernet frames received at the Encapsulator for onward transmission
over ULE carry a Local Area Network Frame Check sequence, LAN FCS, over ULE carry a Local Area Network Frame Check sequence, LAN FCS,
field (e.g. CRC-32 for Ethernet). 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
Expires November 2004 [page 21]
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.
Expires December 2004 [page 20]
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. Processing at the Encapsulator Expires December 2004 [page 21]
5. Extension Headers
This section describes an extension format for the ULE
encapsulation. In ULE, a Type field value less than 1536 Decimal
indicates a next-layer-header and is assigned from a separate IANA
registry defined for ULE.
The use of a single Type/next-layer-header registry 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.
The 16-bit ULE next-layer-header field is used in place of the Type
value. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field
and an 8-bit H-Type field, as follows:
+----+-----+--------+
|0000|H-LEN| H-TYPE |
+----+-----+--------+
Figure 10: Structure of ULE Next-Layer-Header Extension Type.
The H-LEN Assignment
0 Indicates a Mandatory Extension Header
1 Indicates an Optional Extension Header of length 2B
2 Indicates an Optional Extension Header of length 4B
3 Indicates an Optional Extension Header of length 6B
4 Indicates an Optional Extension Header of length 8B
5 Indicates an Optional Extension Header of length 10BX
>=6 the combined H-LEN and H-TYPE values indicate the Ethertype
of a PDU that directly follows this Type field.
A H-LEN of zero indicates a Mandatory Extension Header. Each
specific Mandatory Extension header has a pre-defined length, that
is not communicated in the H-LEN field. No additional limit is
placed on the maximum length of a Mandatory Extension Header. 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 sent in a one byte field which may be either be
one of 256 Mandatory Header Extensions or one of 256 Optional
Header Extensions. The set of currently permitted H-Type values
for both types of header extension are defined by an IANA Registry.
The simplest examples of Extension Headers are Test and Padding.
The Test Mandatory Extension Header results in the entire PDU
being discarded. The Padding Optional Extension Header results
in the following (if any) option header being ignored.
Expires December 2004 [page 22]
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-layer-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, i.e. a value > 1535 B
indicating the Ethertype 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
indicating the presence of a next-layer-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.
Expires December 2004 [page 23]
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. (re)multiplexors before it is finally delivered to a Receiver.
+------+--------------------------------+------+ +------+--------------------------------+------+
| 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 10: Encapsulation of a SNDU into a series of TS Packets Figure 13: Encapsulation of a SNDU into a series of TS Packets
5.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.
Expires November 2004 [page 22]
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 December 2004 [page 24]
+-/------------+ +-/------------+
| 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 |
+--------+--------+--------+----------+ +--------+--------+--------+----------+
PUSI=0 ULE PUSI=0 ULE
End End
Indicator Indicator
Figure 11: A TS Packet carrying the end of SNDU 3, followed by an Figure 14: A TS Packet carrying the end of SNDU 3, followed by an
End Indicator. End Indicator.
Alternatively, when more packets are waiting at an Encapsulator, and Alternatively, when more packets are waiting at an Encapsulator, and
a TS Packet has sufficient space remaining in the payload, the a TS Packet has sufficient space remaining in the payload, the
Encapsulator can follow a previously encapsulated SNDU with another Encapsulator can follow a previously encapsulated SNDU with another
SNDU using the next available byte of the TS Packet payload (see SNDU using the next available byte of the TS Packet payload (see
5.2). This is called Packing (figure 12). 6.2). This is called Packing (figure 15).
+-/----------------+ +----------------/-+ +-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork | | Subnetwork | | Subnetwork |
| DU 1 | | DU 2 | | DU 1 | | DU 2 |
+-/----------------+ +----------------/-+ +-/----------------+ +----------------/-+
\ \ / /\ \ \ / /\
\ \ / / \ \ \ / / \
\ \ / / \. . . \ \ / / \. . .
+--------+--------+--------+----------+ +--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of | |MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 1 | SNDU 2 | | Header | Pointer| SNDU 1 | SNDU 2 |
+--------+--------+--------+----------+ +--------+--------+--------+----------+
PUSI=1 | ^ PUSI=1 | ^
| | | |
+--------------+ +--------------+
Figure 12: A TS Packet with the end of SNDU 1, followed by SNDU 2. Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2.
Expires November 2004 [page 23] 6.2 Procedure for Padding and Packing
5.2 Procedure for Padding and Packing
Five possible actions may occur when an Encapsulator has completed Five possible actions may occur when an Encapsulator has completed
encapsulation of an SNDU: encapsulation of an SNDU:
(i) If the TS Packet has no remaining space, the Encapsulator (i) If the TS Packet has no remaining space, the Encapsulator
transmits this TS Packet. It starts transmission of the next SNDU in transmits this TS Packet. It starts transmission of the next SNDU in
a new TS Packet. (The standard rules require the header of this new a new TS Packet. (The standard rules require the header of this new
TS Packet to carry a PUSI value of 1, and a Payload Pointer value of TS Packet to carry a PUSI value of 1, and a Payload Pointer value of
0x00.) 0x00.)
(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
Expires December 2004 [page 25]
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
header of this new TS Packet to carry a PUSI value of 1 and a header of this new TS Packet to carry a PUSI value of 1 and a
Payload Pointer value of 0x00.) Payload Pointer value of 0x00.)
(iii) If the TS Packet carrying the final part of a SNDU has exactly (iii) If the TS Packet carrying the final part of a SNDU has exactly
two bytes of unused payload, and the PUSI was NOT already set, the two bytes of unused payload, and the PUSI was NOT already set, the
Encapsulator MUST place the value 0xFFFF in this final two bytes, Encapsulator MUST place the value 0xFFFF in this final two bytes,
providing an End Indicator (4.7.1), and transmit the TS Packet. This providing an End Indicator (section 4.3), and transmit the TS
rule prevents fragmentation of the SNDU Length Field over two TS Packet. This rule prevents fragmentation of the SNDU Length Field
Packets. The Encapsulator MUST start transmission of the next SNDU over two TS Packets. The Encapsulator MUST start transmission of the
in a new TS Packet. (The standard rules require the header of this next SNDU in a new TS Packet. (The standard rules require the header
new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of this new TS Packet to carry a PUSI value of 1 and a Payload
of 0x00.) Pointer value of 0x00.)
(iv) If the TS Packet has more than two bytes of unused payload, the (iv) If the TS Packet has more than two bytes of unused payload, the
Encapsulator MAY transmit this partially full TS Packet but MUST Encapsulator MAY transmit this partially full TS Packet but MUST
first place the value 0xFF in all remaining unused bytes (i.e. first place the value 0xFF in all remaining unused bytes (i.e.
setting an End Indicator followed by Padding). The Encapsulator MUST setting an End Indicator followed by Padding). The Encapsulator MUST
start transmission of the next SNDU in a new TS Packet. (The start transmission of the next SNDU in a new TS Packet. (The
standard rules require the header of this new TS Packet to carry a standard rules require the header of this new TS Packet to carry a
PUSI value of 1 and a Payload Pointer value of 0x00.) PUSI value of 1 and a Payload Pointer value of 0x00.)
(v) If at least two bytes are available for payload data in the TS (v) If at least two bytes are available for payload data in the TS
Packet payload (i.e. three bytes if the PUSI was NOT previously set, Packet payload (i.e. three bytes if the PUSI was NOT previously set,
and two bytes if it was previously set), the Encapsulator MAY and two bytes if it was previously set), the Encapsulator MAY
encapsulate further queued PDUs, by starting the next SNDU in the encapsulate further queued PDUs, by starting the next SNDU in the
next available byte of the current TS Packet payload. The PUSI MUST next available byte of the current TS Packet payload. The PUSI MUST
be set. When the Encapsulator packs further SNDUs into a TS Packet be set. When the Encapsulator packs further SNDUs into a TS Packet
where the PUSI has NOT already been set, this requires the PUSI to where the PUSI has NOT already been set, this requires the PUSI to
be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted
in the first byte directly following the TS Packet header. The value in the first byte directly following the TS Packet header. The value
MUST be set to the position of the byte following the end of the MUST be set to the position of the byte following the end of the
Expires November 2004 [page 24]
first SNDU in the TS Packet payload. If no further PDUs are first SNDU in the TS Packet payload. If no further PDUs are
available, an Encapsulator MAY wait for additional PDUs to fill the available, an Encapsulator MAY wait for additional PDUs to fill the
incomplete TS Packet. The maximum period of time an Encapsulator can incomplete TS Packet. The maximum period of time an Encapsulator can
wait, known as the Packing Threshold, MUST be bounded and SHOULD be wait, known as the Packing Threshold, MUST be bounded and SHOULD be
configurable in the Encapsulator. If sufficient additional PDUs are configurable in the Encapsulator. If sufficient additional PDUs are
NOT received to complete the TS Packet within the Packing Threshold, NOT received to complete the TS Packet within the Packing Threshold,
the Encapsulator MUST insert an End Indicator (using rule iv). the Encapsulator MUST insert an End Indicator (using rule iv).
Use of the Packing method (v) by an Encapsulator is optional, and Use of the Packing method (v) by an Encapsulator is optional, and
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.
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).
6. 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
Expires December 2004 [page 26]
reassembly, the Receiver may use a buffer to hold the partially reassembly, the Receiver may use a buffer to hold the partially
assembled SNDU, referred to here as the Current SNDU buffer. Other assembled SNDU, referred to here as the Current SNDU buffer. Other
implementations may choose to use other data structures, but MUST implementations may choose to use other data structures, but MUST
provide equivalent operations. provide equivalent operations.
Receipt of a TS Packet with a PUSI value of 1 indicates that the TS Receipt of a TS Packet with a PUSI value of 1 indicates that the TS
Packet contains the start of a new SNDU. It also indicates the Packet contains the start of a new SNDU. It also indicates the
presence of the Payload Pointer (indicating the number of bytes to presence of the Payload Pointer (indicating the number of bytes to
the start of the first SNDU in the TS-Packet currently being the start of the first SNDU in the TS-Packet currently being
reassembled). It is illegal to receive a Payload Pointer value reassembled). It is illegal to receive a Payload Pointer value
greater than 181, and this MUST cause the SNDU reassembly to be greater than 181, and this MUST cause the SNDU reassembly to be
aborted and the Receiver to enter the Idle State. This event SHOULD aborted and the Receiver to enter the Idle State. This event SHOULD
be recorded as a payload pointer error. be recorded as a payload pointer error.
A Receiver MUST support the use of both the Packing and Padding A Receiver MUST support the use of both the Packing and Padding
method for any received SNDU, and MUST support reception of SNDUs method for any received SNDU, and MUST support reception of SNDUs
with or without a Destination Address Field (i.e. D=0 and D=1). with or without a Destination Address Field (i.e. D=0 and D=1).
6.1 Idle State 7.1 Idle State
After initialisation, errors, or on receipt of an End Indicator, the After initialisation, errors, or on receipt of an End Indicator, the
Receiver enters the Idle State. In this state, the Receiver discards Receiver enters the Idle State. In this state, the Receiver discards
all TS Packets until it discovers the start of a new SNDU, when it all TS Packets until it discovers the start of a new SNDU, when it
then enters the Reassembly State. Figure 13 outlines these state then enters the Reassembly State. Figure 16 outlines these state
transitions: transitions:
Expires November 2004 [page 25] Expires December 2004 [page 27]
+-------+ +-------+
| START | | START |
+---+---+ +---+---+
| |
\/ \/
+----------+ +----------+
\| Idle |/ \| Idle |/
+-------/| State |\-------+ +-------/| State |\-------+
Insufficient | +----+-----+ | Insufficient | +----+-----+ |
unused space | | PUSI set | MPEG-2 TS Error unused space | | PUSI set | MPEG-2 TS Error
or | \/ | or or | \/ | or
End Indicator| +----------+ | SNDU Error End Indicator| +----------+ | SNDU Error
| |Reassembly| | | |Reassembly| |
+--------| State |--------+ +--------| State |--------+
+----------+ +----------+
Figure 13: Receiver state transitions Figure 16: Receiver state transitions
6.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 1 and 182 are permitted, in which case the Receiver MUST between 1 and 182 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.
6.2 Processing of a Received SNDU 7.2 Processing of a Received SNDU
When in the Reassembly State, the Receiver reads a 2 byte SNDU When in the Reassembly State, the Receiver reads a 2 byte SNDU
Length Field from the TS Packet payload. If the value is less than Length Field from the TS Packet payload. If the value is less than
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. When Current SNDU length equals the value of TS Packet is reached. When Current SNDU length equals the value of
the Length Field, the Receiver MUST calculate and verify the CRC the Length Field, the Receiver MUST calculate and verify the CRC
value (section 4.6). SNDUs that contain an invalid CRC value MUST be value (section 4.6). SNDUs that contain an invalid CRC value MUST be
discarded, causing the Receiver to re-enter the Idle State. discarded, causing the Receiver to processes the next in-sequence
SNDU (if any).
When the Destination Address is present, the Receiver accepts SNDUs
that match one of a set of addresses specified by the Receiver (this
includes the NPA address of the Receiver, the NPA broadcast address
Expires November 2004 [page 26] When the Destination Address is present (D=0), the Receiver accepts
and any required multicast NPA addresses). The Receiver MUST SNDUs that match one of a set of addresses specified by the Receiver
(this includes the NPA address of the Receiver, the NPA broadcast
address and any required multicast NPA addresses). The Receiver MUST
silently discard an SNDU with an unmatched address. 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 extensions specified). The SNDU payload is (and process any Type 1 extensions specified). The SNDU payload is
then passed to the next protocol layer specified. An SNDU with an then passed to the next protocol layer specified. An SNDU with an
unknown Type value < 1536 MUST be discarded. This error event SHOULD unknown Type value < 1536 MUST be discarded. This error event SHOULD
be recorded as a SNDU type error. be recorded as a SNDU type error.
Expires December 2004 [page 28]
The Receiver then starts reassembly of the next SNDU. This MAY The Receiver then starts reassembly of the next SNDU. This MAY
directly follow the previously reassembled SNDU within the TS Packet directly follow the previously reassembled SNDU within the TS Packet
payload. payload.
(i) If the Current SNDU finishes at the end of a TS Packet payload, (i) If the Current SNDU finishes at the end of a TS Packet payload,
the Receiver MUST enter the Idle State. the Receiver MUST enter the Idle State.
(ii) If only one byte remains unprocessed in the TS Packet payload (ii) If only one byte remains unprocessed in the TS Packet payload
after completion of the Current SNDU, the Receiver MUST discard this after completion of the Current SNDU, the Receiver MUST discard this
final byte of TS Packet payload. It then enters the Idle State. It final byte of TS Packet payload. It then enters the Idle State. It
skipping to change at line 1218 skipping to change at line 1329
identical to 0xFF. identical to 0xFF.
(iii) If two or more bytes of TS Packet payload data remain after (iii) If two or more bytes of TS Packet payload data remain after
completion of the Current SNDU, the Receiver accepts the next 2 completion of the Current SNDU, the Receiver accepts the next 2
bytes and examines if this is an End Indicator. When an End bytes and examines if this is an End Indicator. When an End
Indicator is received, a Receiver MUST silently discard the Indicator is received, a Receiver MUST silently discard the
remainder of the TS Packet payload and transition to the Idle State. remainder of the TS Packet payload and transition to the Idle State.
Otherwise this is the start of the next Packed SNDU, and the Otherwise this is the start of the next Packed SNDU, and the
Receiver continues by processing this SNDU. Receiver continues by processing this SNDU.
6.2.1 Reassembly Payload Pointer Checking 7.2.1 Reassembly Payload Pointer Checking
A Receiver that has partially received a SNDU (in the Current SNDU A Receiver that has partially received a SNDU (in the Current SNDU
buffer) MUST check the PUSI value in the header of all subsequent TS buffer) MUST check the PUSI value in the header of all subsequent TS
Packets with the same PID (i.e. same TS Logical Channel). If it Packets with the same PID (i.e. same TS Logical Channel). If it
receives a TS Packet with a PUSI value of 1, it MUST then verify the receives a TS Packet with a PUSI value of 1, it MUST then verify the
Payload Pointer. If the Payload Pointer does NOT equal the number of Payload Pointer. If the Payload Pointer does NOT equal the number of
bytes remaining to complete the Current SNDU, i.e., the difference bytes remaining to complete the Current SNDU, i.e., the difference
between the SNDU Length field and the number of reassembled bytes, between the SNDU Length field and the number of reassembled bytes,
the Receiver has detected a delimiting error. the Receiver has detected a delimiting error.
Following a delimiting error, the Receiver MUST discard the Following a delimiting error, the Receiver MUST discard the
partially assembled SNDU (in the Current SNDU buffer), and SHOULD partially assembled SNDU (in the Current SNDU buffer), and SHOULD
record a reassembly error. It MUST then re-enter the Idle State. record a reassembly error. It MUST then re-enter the Idle State.
6.3 Other Error Conditions Expires December 2004 [page 29]
7.3 Other Error Conditions
The Receiver SHOULD check the MPEG-2 Transport Error indicator The Receiver SHOULD check the MPEG-2 Transport Error Indicator
carried in the TS Packet header. This flag indicates a transmission carried in the TS Packet header. This flag indicates a transmission
error for a TS Logical Channel. If the flag is set to a value of error for a TS Logical Channel. If the flag is set to a value of
Expires November 2004 [page 27]
one, a transmission error event SHOULD be recorded. Any partially one, a transmission error event SHOULD be recorded. Any partially
received SNDU MUST be discarded. The Receiver then enters the Idle received SNDU MUST be discarded. The Receiver then enters the Idle
State. State.
The Receiver MUST check the MPEG-2 Continuity Counter carried in the The Receiver MUST check the MPEG-2 Continuity Counter carried in the
TS Packet header [ISO-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.
Note that the 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.
7. 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.
8. Acknowledgments ULE also provides an extension header format and defines an
associated IANA registry for efficient and flexible support of both
mandatory and optional SNDU headers. This allows for future
extension of the protocol, while providing backwards capability with
existing implementations. In particular, Optional Extension Headers
may safely be ignored by drivers that do not implement them, or
choose not to process them.
Expires December 2004 [page 30]
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, and Alain comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar
Ritoux. Alain also provided the original examples of usage. Linder, Alain Ritoux, and William Stanislaus. Alain also provided
the original examples of usage.
9. 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 exiting 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.
Expires November 2004 [page 28]
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 ULE, this is avoided by values are not propagated by the network. In ULE, this is avoided by
including only one SNDU Length Field. However, this issue still including only one SNDU Length Field. However, this issue still
arises in bridged LLC frames, and frames with a LLC Length greater arises in bridged LLC frames, and frames with a LLC Length greater
than the SNDU payload size MUST be discarded, and a SNDU payload than the SNDU payload size MUST be discarded, and a SNDU payload
length error SHOULD be recorded. length error SHOULD be recorded.
ULE supports optional link level encryption of the SNDU payload. ULE supports optional link level encryption of the SNDU payload.
This is as an additional security mechanism to IP, transport or This is as an additional security mechanism to IP, transport or
application layer security - not a replacement [ID-ipdvb-arch]. application layer security - not a replacement [ID-ipdvb-arch]. The
approach is generic and decouples the encapsulation from future
XXX Authors Note: Text below to be revised when this requirement is security extensions. The operation provides functions that resemble
included in the Spec - depending on style of extension mechanism those currently used with the MPE encapsulation.
that is used XXX
Options that may be used include a next header extension type field
in the ULE header (16 bits) that may indicate that some part of the
ULE PDU is encrypted. Two potential solutions for the use of the
type field are:
a. Define a range of types X-to-Y for security. These types A ULE Mandatory Extension Header may in future be used to define a
will act as security key ID to enable the decryption of the mechanism to perform link encryption . Additional security control
incoming ULE PDUs. fields may be provided as a part of the extension header, e.g. to
b. 2. A single type value may be defined for encryption (say X) associate an SNDU with one of a set of Security Association (SA)
followed by any required Security Association (SA) parameters. As a part of the encryption process, it may also be
parameters. The definition of this SA and the related desirable to authenticate some/all of the SNDU headers. The method
encryption keys are out of the scope for ULE draft. of encryption and the way in which keys are exchanged is beyond the
scope of this specification, as also are the definition of the SA
format and that of the related encryption keys.
The second solution is more generic and decouples the encapsulation Expires December 2004 [page 31]
from future security extensions. The former provides functions that
resemble those currently used for the MPE encapsulation.
Additional security control fields may be provided as a part of the 11. References
extension header. The method of encryption and the way in which keys
are exchanged is beyond the scope of this specification. However,
the specification provides appropriate code points to allow such
encryption to be implemented at the link layer. As a part of the
encryption process, it may be desirable to authenticate some/all of
the SNDU headers.
10. References
Expires November 2004 [page 29] 11.1 Normative References
10.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
3", BCP 9, RFC 2026, BCP 9, 1996. 3", BCP 9, RFC 2026, BCP 9, 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
10.2 Informative References 11.2 Informative References
[ID-ipdvb-arch] "Requirements for transmission of IP datagrams over
MPEG-2 networks", Internet Draft, Work in Progress.
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
Systems Committee (ATSC), Doc. A/53, 1995. 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.
skipping to change at line 1391 skipping to change at line 1499
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).
Expires November 2004 [page 30]
[ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital terrestrial structure, channel coding and modulation for digital terrestrial
Expires December 2004 [page 32]
television (DVB-T)", European Telecommunications Standards Institute television (DVB-T)", European Telecommunications Standards Institute
(ETSI). (ETSI).
[ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB);
Interaction Channel for Satellite Distribution Systems", European Interaction Channel for Satellite Distribution Systems", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI).
[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic
coding of moving pictures and associated audio information -- Part coding of moving pictures and associated audio information -- Part
6: Extensions for DSM-CC is a full software implementation", 6: Extensions for DSM-CC is a full software implementation",
skipping to change at line 1420 skipping to change at line 1529
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.
[ID-ipdvb-arch] "Requirements for transmission of IP datagrams over 12. Authors' Addresses
MPEG-2 networks", Internet Draft, Work in Progress.
11. 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.cosy.sbg.ac.at/sc/ Web: http://www.cosy.sbg.ac.at/sc/
Expires November 2004 [page 31] Expires December 2004 [page 33]
Full Copyright Statement 13. IPR Notices
"Copyright (C) The Internet Society (date). All Rights Reserved. 13.1 Intellectual Property Statement
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF takes no position regarding the validity or scope of any
revoked by the Internet Society or its successors or assigns. Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
12. IANA Considerations Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13.2 Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Expires December 2004 [page 34]
15. IANA Considerations
This document will require IANA involvement. This document will require IANA involvement.
The ULE type field defined in this document requires a registry. The ULE type field defined in this document requires a registry. The
This registry allocates values 0-1499 (decimal). It MUST NOT payload type field defined in this document requires creation of a
allocate values greater than or equal to 1536 (decimal), since such new IANA registry:
values overlap the assignments made in the IANA Ethertypes registry.
The following values need to be assigned by the IANA: ULE Next-Protocol-Header registry
ULE Type Field This registry allocates values 0-512 (decimal).
Expires November 2004 [page 32] 15.1 IANA Guidelines
The following contains the IANA guidelines for management of the ULE
Next-Protocol-Header registry. This registry allocates values
decimal 0-512 (0x0000-0x01FF, hexadecimal). It MUST NOT allocate
values greater than 0x01FF (decimal).
It subdivides the Next-Layer-Header registry in the following way:
1) 0-255 (decimal) IANA assigned values indicating Mandatory
Extension Headers (or link-dependent type fields) for ULE,
requiring prior issue of an IETF RFC.
Assignments made in this document:
0: Test-SNDU
1: Bridged-SNDU
2) 256-511 (decimal) IANA assigned values indicating Optional
Extension Headers for ULE, requiring prior issue of an IETF RFC.
Assignments made in this document:
256: Padding
Expires December 2004 [page 35]
ANNEXE A: Informative Appendix 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 1524 skipping to change at line 1679
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 November 2004 [page 33] Expires December 2004 [page 36]
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 1561 skipping to change at line 1716
| 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 November 2004 [page 34] Expires December 2004 [page 37]
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 1607 skipping to change at line 1762
+-----+------+- -+------+ +-----+------+- -+------+
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 November 2004 [page 35] Expires December 2004 [page 38]
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 1648 skipping to change at line 1803
+ ... | 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 November 2004 [page 36] Expires December 2004 [page 39]
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 1671 skipping to change at line 1826
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
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 November 2004 [page 37] Expires December 2004 [page 40]
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: 01:02:03:04:05:06 Destination ULE NPA Address: 01:02:03:04:05:06
ULE CRC32 : 0x784679a5 ULE CRC32 : 0x784679a5
skipping to change at line 1694 skipping to change at line 1849
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 01 02 03 04 05 06 60 00 00 00 00 0d 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d
0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00
0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00
0030: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78 0030: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78
0040: 46 79 a5 0040: 46 79 a5
Expires November 2004 [page 38] >>>> Author Note : This packet is not a valid IPv6 packet since it
has a unicast L3 IP address and a multicast L2 MAC address. A new
packet decode is required. <<<
Expires December 2004 [page 41]
Expires December 2004 [page 42]
 End of changes. 

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