draft-ietf-ipdvb-ule-03.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-03.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 November 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
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of RFC 3668.		aware will be disclosed, in accordance with Section 6 of RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts. Internet-Drafts are draft documents valid for a maximum of		Drafts. Internet-Drafts are draft documents valid for a maximum of
	six months and may be updated, replaced, or obsoleted by other		six months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts as		documents at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress".		reference material or to cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/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. ULE supports an		2 Transport Streams (TS) as TS Private Data. ULE supports an
	extension format that allows it to carry both optional (with an		extension format that allows it to carry both optional (with an
	explicit extension length) and mandatory (with an implicit extension		explicit extension length) and mandatory (with an implicit extension
	length) header information to assist in network/Receiver processing		length) header information to assist in network/Receiver processing
	of a SNDU.		of a SNDU.
			Expires 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
	skipping to change at page 3, line 4		skipping to change at line 93
	* 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 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
	skipping to change at page 4, line 5		skipping to change at line 145
	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 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.
	skipping to change at page 4, line 51		skipping to change at line 192
	* 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 (Now called Next-Header)		* Next-Layer-Header defined
	* Addition of Appendix B (to aide verification of SNDFU format)		* Addition of Appendix B (to aide verification of SNDFU format)
	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
	skipping to change at page 5, line 31		skipping to change at line 224
	* 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.
	--------------------------------------------------------------------		--------------------------------------------------------------------
	Working Group ID rev 02		Working Group ID rev 02
	Revised IPR disclosure		Revised IPR disclosure
	Revised copyright notice		Revised copyright notice
	Section 5 added to ULE to define optional Extension Headers (see		Section 5 added to ULE to define optional extension headers (see
	xule)		xule)
	Correction of figure numbering.		Correction of figure numbering.
	Correction to capitalisation in Transport Stream definition of fields		Correction to capitalisation in Transport Stream definition of fields
	Inserted space character after 1536 in line 2 of 4.4.2		Inserted space character after 1536 in line 2 of 4.4.2
	Replaced } with ] after ISO_DSMCC		Replaced } with ] after ISO_DSMCC
	Replace reference to section 6.3 with section 7.3 at end of section		Replace reference to section 6.3 with section 7.3 at end of section
	4.6.		4.6.
	Reference in 4.7.4 was changed to refer to figure 7 (not 6).		Reference in 4.7.4 was changed to refer to figure 7 (not 6).
	Note added after figure 9.		Note added after figure 9.
	Working Group ID rev 03		7.2 Changed, New text: <<SNDUs that contain an invalid CRC value MUST
			be discarded, causing the Receiver to processes the next in-sequence
	Changes with this revision of the document:		SNDU (if any).>> The rationale is that the this a SNDU-integrity
			check - rather than a framing issue. The mantra of being liberal in
	(i) The worked hexadecimal example in the annexe was reworked to		what is accepted suggests we discard, but not that we also discard
	include a valid MAC address for an IPv6 unicast packet. -		succeeding SNDUs.
	(BCN)
	(ii) The IANA procedures revised, based on inputs from IANA to
	improve consistency of the term Next-Header and to add the
	HLEN field to the IANA registry record for OPTIONAL headers.
	(GF)
	(iii) 7.2 Change to revert wording in the second para to MUST enter		Known issues with this revision of the document:
	IDLE after CRC failure of SNDU check.
	(iv) In normal operation, it is expected that any padding appended		(i) The worked hexadecimal example in the annexe needs to be
	to a bridged Ethernet frame SHOULD be removed prior to		reworked.
	forwarding. This requires the sender to be aware of such		(ii) The IANA procedures need to be checked with IANA.
	Ethernet padding (e.g. LLC). (Made this a SHOULD). (GF)		(iii) Format page breaks in next rev!
	NiTS:
	(v) Format of page Breaks was updated. (GF)
	(vi) Check for <- -> sequences of characters. (GF)
	(vii) Update refs to add RFC3667 / 3668. (GF)
	(viii) Changed text defining M in DSMCC definition to the word Media
	(ix) 7.1.1 Range of PP values corrected to 0-181.
	(x) Definition of END INDICATOR corrected in section 2 - this is
	not a TYPE value, but a LENGTH value.
	(xi) Next-Header used throughout the document to replace
	next-layer-header, and various other forms of wording.
	(xii) In section 7.2, added a ref the section on PP checking
	[END of RFC EDITOR NOTE]		[END of RFC EDITOR NOTE]
			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: Next-Header 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. Extension Headers		5. Extension Headers
	5.1 Mandatory Extension Header		5.1 Mandatory Extension Header
	5.2 Optional Extension Header		5.2 Optional Extension Header
	skipping to change at page 8, line 5		skipping to change at line 301
	12. Authors' Addresses		12. Authors' Addresses
	13. IPR Notices		13. IPR Notices
	14. Copyright Statement		14. Copyright Statement
	14.1 Intellectual Property Statement		14.1 Intellectual Property Statement
	14.2 Disclaimer of Validity		14.2 Disclaimer of Validity
	15. IANA Considerations		15. IANA Considerations
	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 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 page 9, line 5		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 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.
	ATSC: Advanced Television Systems Committee [ATSC]. A framework and		ATSC: Advanced Television Systems Committee [ATSC]. A framework and
	a set of associated standards for the transmission of video, audio,		a set of associated standards for the transmission of video, audio,
	and data using the ISO MPEG-2 standard.		and data using the ISO MPEG-2 standard.
	DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A		DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC].
	format for transmission of data and control information defined by		A format for transmission of data and control information defined by
	the ISO MPEG-2 standard that is carried in an MPEG-2 Private		the ISO MPEG-2 standard that is carried in an MPEG-2 Private
	Section.		Section.
	DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of		DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
	associated standards published by the European Telecommunications		associated standards published by the European Telecommunications
	Standards Institute (ETSI) for the transmission of video, audio, and		Standards Institute (ETSI) for the transmission of video, audio, and
	data, using the ISO MPEG-2 Standard.		data, using the ISO MPEG-2 Standard.
	ENCAPSULATOR: A network device that receives PDUs and formats these		ENCAPSULATOR: A network device that receives PDUs and formats these
	into Payload Units (known here as SNDUs) for output as a stream of		into Payload Units (known here as SNDUs) for output as a stream of
	TS Packets.		TS Packets.
	END INDICATOR: A value that indicates to the Receiver that there are		END INDICATOR: A Type value that indicates to the Receiver that
	no further SNDUs present within the current TS Packet.		there are no further SNDUs present within the current TS Packet.
	MAC: Medium Access and Control. The link layer header of the		MAC: Medium Access and Control. The link layer header of the
	Ethernet IEEE 802 standard of protocols, consisting of a 6B		Ethernet IEEE 802 standard of protocols, consisting of a 6B
	destination address, 6B source address, and 2B type field.		destination address, 6B source address, and 2B type field.
	MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A		MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A
	scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each		scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each
	Section is sent in a series of TS Packets using a single TS Logical		Section is sent in a series of TS Packets using a single TS Logical
	Channel.		Channel.
	MPEG-2: A set of standards specified by the Motion Picture Experts		MPEG-2: A set of standards specified by the Motion Picture Experts
	Group (MPEG), and standardized by the International Standards		Group (MPEG), and standardized by the International Standards
	Organisation (ISO) [ISO-MPEG].		Organisation (ISO) [ISO-MPEG].
	NEXT-HEADER: A Type value indicating an Extension Header.		NEXT-HEADER: A Type value indicating an extension header.
	NPA: Network Point of Attachment. In this document, refers to a 6 B		NPA: Network Point of Attachment. In this document, refers to a 6 B
	destination address (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.
	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 page 11, line 19		skipping to change at line 449
	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.
	skipping to change at page 12, line 5		skipping to change at line 480
	8b Synchronisation pattern equal 0x47		8b Synchronisation pattern equal 0x47
	*1b Transport Error Indicator		*1b Transport Error Indicator
	*1b Payload Unit Start Indicator (PUSI)		*1b Payload Unit Start Indicator (PUSI)
	1b Transport Priority		1b Transport Priority
	*13b Packet IDentifier (PID)		*13b Packet IDentifier (PID)
	2b Transport scrambling control		2b Transport scrambling control
	*2b Adaptation Field Control (AFC)		*2b Adaptation Field Control (AFC)
	*4b Continuity Counter (CC)		*4b Continuity Counter (CC)
			Expires December 2004 [page 10]
	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 page 13, line 5		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 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 page 13, line 39		skipping to change at line 570
	present (i.e. it is omitted).		present (i.e. it is omitted).
	By default, the D-bit value MUST be set to a value of 0, except for		By default, the D-bit value MUST be set to a value of 0, except for
	the transmission of an End Indicator (see 4.3), in which this bit		the transmission of an End Indicator (see 4.3), in which this bit
	MUST be set to the value of 1.		MUST be set to the value of 1.
	4.2 Length Field		4.2 Length Field
	A 15-bit value that indicates the length, in bytes, of the SNDU		A 15-bit value that indicates the length, in bytes, of the SNDU
	(encapsulated Ethernet frame, IP datagram or other packet) counted		(encapsulated Ethernet frame, IP datagram or other packet) counted
	from the byte following the Type field, up to and including the CRC.		from the byte following the type field up to and including the CRC.
	Note the special case described in 4.3.		Note the special case described in 4.3.
	4.3 End Indicator		4.3 End Indicator
	When the first two bytes of a SNDU have the value 0xFFFF, this		When the first two bytes of a SNDU have the value 0xFFFF, this
	denotes an End Indicator (i.e., all 1s length combined with a D-bit		denotes an End Indicator (i.e., all 1s length combined with a D-bit
	value of 1). 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 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
	length indicator. Ethernet receivers use this feature to		length indicator. Ethernet receivers use this feature to
	discriminate LLC format frames. Hence any IEEE EtherType < 1536		discriminate LLC format frames. Hence any IEEE Ethertype < 1536
	indicates an LLC frame, and the actual value indicates the length of		indicates an LLC frame, and the actual value indicates the length of
	the LLC frame.		the LLC frame.
	There is a potential ambiguous case when a Receiver receives a PDU		There is a potential ambiguous case when a Receiver receives a PDU
	with two length fields: The Receiver would need to validate the		with two length fields: The Receiver would need to validate the
	actual length and the Length field and ensure that inconsistent		actual length and the Length field and ensure that inconsistent
	values are not propagated by the network. Specification of two		values are not propagated by the network. Specification of two
	independent length fields is therefore undesirable. In the ULE		independent length fields is therefore undesirable. In the ULE
	header, this is avoided in the SNDU header by including only one		header, this is avoided in the SNDU header by including only one
	length value, but bridging of LLC frames re-introduces this		length value, but bridging of LLC frames re-introduces this
	consideration (section 4.7.5).		consideration (section 4.7.5).
	The Ethernet LLC mode of identification is not required in ULE,		The Ethernet LLC mode of identification is not required in ULE,
	since the SNDU format always carries an explicit Length Field, and		since the SNDU format always carries an explicit Length Field, and
	therefore the procedure in ULE is modified, as below:		therefore the procedure in ULE is modified, as below:
	The first set of ULE Type field values comprise the set of values <		The first set of ULE Type Field values comprise the set of values <
	1536. These Type field values are IANA assigned (see 4.4.1), and		1536. These Type Field values are IANA assigned (see 4.4.1), and
	indicate the Next-Header.		indicate the Next-Header.
	The second set of ULE Type field values comprise the set of values		The second set of ULE Type Field values comprise the set of values
	>= 1536. In ULE, this indicates that the value is identical to the		>= 1536. In ULE, this indicates that the value is identical to the
	corresponding type codes specified by the IEEE/DIX type assignments		corresponding type codes specified by the IEEE/DIX type assignments
	for Ethernet and recorded in the IANA EtherType registry.		for Ethernet and recorded in the IANA EtherType registry.
	4.4.1 Type 1: Next-Header Type Fields		4.4.1 Type 1: Next-Layer-Header
	The first part of the Type space corresponds to the values 0 to 1535		The first part of the Type space corresponds to the values 0 to
	Decimal. These values may be used to identify link-specific		1535 Decimal. These values may be used to identify link-specific
	protocols and/or to indicate the presence of Extension Headers that		protocols and/or to indicate the presence of extension headers that
	carry additional optional protocol fields (e.g. a bridging		carry additional optional protocol fields (e.g. a bridging
	encapsulation). Use of these values is co-ordinated by an IANA		encapsulation). Use of these values is co-ordinated by an IANA
	registry.		registry.
	The following types are defined in this document:		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.
	0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)		0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)
	0x0100: Padding, ignored by the Receiver.		0x0100: Padding, ignored by the Receiver.
	[XXX END OF IANA ACTION REQUIRED XXX]		[XXX END OF IANA ACTION REQUIRED XXX]
	The remaining values within the first part of the Type space are		The remaining values within the first part of the Type space are
	reserved for Next-Header values allocated by the IANA.		reserved for allocation by the IANA.
	4.4.2 Type 2: EtherType compatible Type Fields		Expires December 2004 [page 13]
			4.4.2 Type 2: Ethertype compatible Type Fields
	The second part of the Type space corresponds to the values 1536		The second part of the Type space corresponds to the values 1536
	Decimal (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
	The SNDU Destination Address Field is optional (see section 4.1).		The SNDU Destination Address Field is optional (see section 4.1).
	This field MUST be carried (i.e. D=0) for IP unicast packets		This field MUST be carried (i.e. D=0) for IP unicast packets
	destined to routers that are sent using shared links (i.e., where		destined to routers that are sent using shared links (i.e., where
	the same link connects multiple Receivers). A sender MAY omit this		the same link connects multiple Receivers). A sender MAY omit this
	skipping to change at page 16, line 5		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 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 0x104C11DB7 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
	processed in order of increasing position within the SNDU, the order		processed in order of increasing position within the SNDU, the order
	of processing bits is NOT reversed. This use resembles, but is		of processing bits is NOT reversed. This use resembles, but is
	skipping to change at page 16, line 45		skipping to change at line 720
	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 7.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:
	skipping to change at page 18, line 21		skipping to change at line 755
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1| 0x7FFF |		|1| 0x7FFF |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	= Arbitrary number (>= 0) bytes with value 0xFF =		= Arbitrary number (>= 0) bytes with value 0xFF =
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: SNDU Format for an End Indicator.		Figure 2: SNDU Format for an End Indicator.
			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 page 19, line 19		skipping to change at line 796
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	= 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 page 20, line 5		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 December 2004 [page 18]
	4.7.4 Test SNDU		4.7.4 Test SNDU
	A Test SNDU is of Type 1 (figure 7). 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 21, line 4		skipping to change at line 886
	| | EtherType (2B) |		| | EtherType (2B) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	= (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 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 page 21, line 33		skipping to change at line 917
	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		Note: The final two bytes of the bridging header also carry a Type
	field (see section 5). In this special case, the extension mandatory		field (see section 5). In this special case, the extension mandatory
	header format permits this to carry a LLC Length field, specified by		header format permits this to carry a LLC Length field, specified by
	IEEE 802 [LLC] rather than an IANA assigned value.		IEEE 802 [LLC] rather than an IANA assigned value.
	When an NPA address is specified (D=0), Receivers MUST discard all		When an NPA address is specified (D=0), Receivers MUST discard all
	SNDUs that carry an NPA 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/multicast address), the payload of the		address (or a broadcast/mcast address), the payload of the remaining
	remaining SNDUs are processed by the bridging rules that follow. An		SNDUs are processed by the bridging rules that follow. An SNDU
	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
	addresses denote the intended recipient in the destination LAN, and		addresses denote the intended recipient in the destination LAN, and
	therefore have a different function to the NPA addresses carried in		therefore have a different function to the NPA addresses carried in
	the SNDU header. The EtherType field of a frame is defined according		the SNDU header. The EtherType field of a frame is defined according
	to Ethernet/LLC [LLC].		to Ethernet/LLC [LLC].
	A frame Type < 1536 for a bridged frame, introduces a LLC Length		A frame type < 1536 for a bridged frame, introduces a LLC Length
	field. The Receiver MUST check this length and discard any frame		Field. The Receiver MUST check this length and discard any frame
	with a length greater than permitted by the SNDU payload size.		with a length greater than permitted by the SNDU payload size.
	In normal operation, it is expected that any padding appended to the		In normal operation, it is expected that any padding appended to the
	Ethernet frame SHOULD be removed prior to forwarding. This requires		Ethernet frame will be removed prior to forwarding. This requires
	the sender to be aware of such Ethernet padding (e.g. LLC).		the sender to be aware of such Ethernet padding.
	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
	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).
			Expires December 2004 [page 21]
	5. Extension Headers		5. Extension Headers
	This section describes an extension format for the ULE		This section describes an extension format for the ULE
	encapsulation. In ULE, a Type field value less than 1536 Decimal		encapsulation. In ULE, a Type field value less than 1536 Decimal
	indicates an Extension Header. These values are assigned from a		indicates a next-layer-header and is assigned from a separate IANA
	separate IANA registry defined for ULE.		registry defined for ULE.
	The use of a single Type/Next-Header field simplifies processing and		The use of a single Type/next-layer-header registry simplifies
	eliminates the need to maintain multiple IANA registries. The cost		processing and eliminates the need to maintain multiple IANA
	is that each Extension Header requires at least 2 bytes. This is		registries. The cost is that each extension header requires at least
	justified, on the basis of simplified processing and maintaining a		2 bytes. This is justified, on the basis of simplified processing
	simple lightweight header for the common case when no extensions are		and maintaining a simple lightweight header for the common case when
	present.		no extensions are present.
	A ULE Extension Header is identified by a 16-bit value in the Type		The 16-bit ULE next-layer-header field is used in place of the Type
	field. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field		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:		and an 8-bit H-Type field, as follows:
	+----+-----+--------+		+----+-----+--------+
	|0000|H-LEN| H-TYPE |		|0000|H-LEN| H-TYPE |
	+----+-----+--------+		+----+-----+--------+
	Figure 10: Structure of ULE Next-Header Field.		Figure 10: Structure of ULE Next-Layer-Header Extension Type.
	The H-LEN Assignment is described below:		The H-LEN Assignment
	0 Indicates a Mandatory Extension Header		0 Indicates a Mandatory Extension Header
	1 Indicates an Optional Extension Header of length 2B		1 Indicates an Optional Extension Header of length 2B
	2 Indicates an Optional Extension Header of length 4B		2 Indicates an Optional Extension Header of length 4B
	3 Indicates an Optional Extension Header of length 6B		3 Indicates an Optional Extension Header of length 6B
	4 Indicates an Optional Extension Header of length 8B		4 Indicates an Optional Extension Header of length 8B
	5 Indicates an Optional Extension Header of length 10B		5 Indicates an Optional Extension Header of length 10BX
	>=6 the combined H-LEN and H-TYPE values indicate the EtherType		>=6 the combined H-LEN and H-TYPE values indicate the Ethertype
	of a PDU that directly follows this Type field.		of a PDU that directly follows this Type field.
	A H-LEN of zero indicates a Mandatory Extension Header. Each		A H-LEN of zero indicates a Mandatory Extension Header. Each
	Mandatory Extension Header has a pre-defined length that is not		specific Mandatory Extension header has a pre-defined length, that
	communicated in the H-LEN field. No additional limit is placed on		is not communicated in the H-LEN field. No additional limit is
	the maximum length of a Mandatory Extension Header. A Mandatory		placed on the maximum length of a Mandatory Extension Header. A
	Extension Header MAY modify the format or encoding of the enclosed		Mandatory Extension header MAY modify the format or encoding of the
	PDU (e.g. to perform encryption and/or compression).		enclosed PDU (e.g. to perform encryption and/or compression).
	The H-Type is a one byte field that may be either one of 256		The H-Type is sent in a one byte field which may be either be
	Mandatory Header Extensions or one of 256 Optional Header		one of 256 Mandatory Header Extensions or one of 256 Optional
	Extensions. The set of currently permitted values for both types of		Header Extensions. The set of currently permitted H-Type values
	Extension Headers are defined by an IANA Registry (section 15).		for both types of header extension are defined by an IANA Registry.
	Registry values for Optional Extensions are specified in the form
	H=1 (i.e. a decimal number in the range 256-511), but may be used
	with an H-Length value in the range 1-5.
	Two examples of Extension Headers are the Test_SNDU and the use of		The simplest examples of Extension Headers are Test and Padding.
	Extension-Padding. The Test-SNDU Mandatory Extension Header results		The Test Mandatory Extension Header results in the entire PDU
	in the entire PDU being discarded. The Extension-Padding Optional		being discarded. The Padding Optional Extension Header results
	Extension Header results in the following (if any) option header		in the following (if any) option header being ignored.
	being ignored (i.e. a total of H-LEN 16-bit words).
	The general format for an SNDU with Extension Headers is:		Expires December 2004 [page 22]
			The general format for an SNDU with extension headers is:
	< -------------------------- SNDU ------------------------- >		<-------------------------- SNDU --------------------------->
	+---+--------------------------------------------------+--------+		+---+--------------------------------------------------+--------+
	|D=1| Length | T1 | H1 | T2 | PDU | CRC-32 |		|D=1| Length | T1 | H1 | T2 | PDU | CRC-32 |
	+---+--------------------------------------------------+--------+		+---+--------------------------------------------------+--------+
	< ULE base header >< ext 1 >		<-ULE base header->< ext 1 >
	Figure 11: SNDU Encapsulation with one Extension Header		Figure 11: SNDU Encapsulation with one Extension Header
	Where:		Where:
	D is the ULE D_bit (in this example D=1, however NPA addresses may		D is the ULE D_bit (in this example D=1, however NPA addresses may
	also be used in combination with Extension Headers).		also be used in combination with extension headers).
	T1 is the base header Type field. In this case, specifying a		T1 is the base header Type field. In this case, specifying a
	Next-Header value.		next-layer-header value.
	H1 is a set of fields defined for header type T1. There may be 0		H1 is a set of fields defined for header type T1. There may be 0
	or more bytes of information for a specific ULE Extension Header.		or more bytes of information for a specific ULE extension header.
	T2 is the Type field of the next header, or an EtherType > 1535 B		T2 is the Type field of the next header, i.e. a value > 1535 B
	indicating the type of the PDU being carried.		indicating the Ethertype of the PDU being carried.
	< -------------------------- SNDU ------------------------- >		<-------------------------- SNDU --------------------------->
	+---+---------------------------------------------------+--------+		+---+---------------------------------------------------+--------+
	|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |		|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
	+---+---------------------------------------------------+--------+		+---+---------------------------------------------------+--------+
	< ULE base header >< ext 1 >< ext 2 >		<ULE base header-> < ext 1 > < ext 2 >
	Figure 12: SNDU Encapsulation with two Extension Headers		Figure 12: SNDU Encapsulation with two Extension Headers
	Using this method, several Extension Headers MAY be chained in		Using this method several extension headers may be chained in
	series. Figure 12 shows an SNDU including two Extension Headers. The		series. Figure 12 shows an SNDU including two extension headers.
	values of T1 and T2 are both less than 1536 Decimal, each indicates		The values of T1 and T2 are both less than 1536 Decimal, each
	the presence of an Extension Header rather than a directly following		indicating the presence of a next-layer-header rather than a
	PDU. T3 has a value > 1535 indicating the EtherType of the PDU being		directly following PDU. T3 has a value > 1535 indicating the
	carried. Although an SNDU may contain an arbitrary number of		Ethertype of the PDU being carried. Although an SNDU may contain
	consecutive Extension Headers, it is not expected that SNDUs will		an arbitrary number of consecutive extension headers, it is not
	generally carry a large number of extensions.		expected that SNDUs will generally carry a large number.
			Expires December 2004 [page 23]
	6. Processing at the Encapsulator		6. Processing at the Encapsulator
	The Encapsulator forms the PDUs queued for transmission into SNDUs		The Encapsulator forms the PDUs queued for transmission into SNDUs
	by adding a header and trailer to each PDU (section 4). It then		by adding a header and trailer to each PDU (section 4). It then
	segments the SNDU into a series of TS Packet payloads (figure 9).		segments the SNDU into a series of TS Packet payloads (figure 9).
	These are transmitted using a single TS Logical Channel over a TS		These are transmitted using a single TS Logical Channel over a TS
	Multiplex. The TS Multiplex may be processed by a number of MPEG-2		Multiplex. The TS Multiplex may be processed by a number of MPEG-2
	(re)multiplexors before it is finally delivered to a Receiver.		(re)multiplexors before it is finally delivered to a Receiver.
	skipping to change at page 26, line 5		skipping to change at line 1099
	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 |
	skipping to change at page 26, line 53		skipping to change at line 1148
	Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2.		Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2.
	6.2 Procedure for Padding and Packing		6.2 Procedure for Padding and Packing
	Five possible actions may occur when an Encapsulator has completed		Five possible actions may occur when an Encapsulator has completed
	encapsulation of an SNDU:		encapsulation of an SNDU:
	(i) If the TS Packet has no remaining space, the Encapsulator		(i) If the TS Packet has no remaining space, the Encapsulator
	transmits this TS Packet. It starts transmission of the next SNDU in		transmits this TS Packet. It starts transmission of the next SNDU in
	a new TS Packet. (The standard rules [ISO-MPEG] require the header		a new TS Packet. (The standard rules require the header of this new
	of this new TS Packet to carry a PUSI value of 1, and a Payload		TS Packet to carry a PUSI value of 1, and a Payload Pointer value of
	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,
	skipping to change at page 27, line 32		skipping to change at line 1182
	over two TS Packets. The Encapsulator MUST start transmission of the		over two TS Packets. The Encapsulator MUST start transmission of the
	next SNDU in a new TS Packet. (The standard rules require the header		next SNDU in a new TS Packet. (The standard rules require the header
	of this new TS Packet to carry a PUSI value of 1 and a Payload		of this new TS Packet to carry a PUSI value of 1 and a Payload
	Pointer value of 0x00.)		Pointer value of 0x00.)
	(iv) If the TS Packet has more than two bytes of unused payload, the		(iv) If the TS Packet has more than two bytes of unused payload, the
	Encapsulator MAY transmit this partially full TS Packet but MUST		Encapsulator MAY transmit this partially full TS Packet but MUST
	first place the value 0xFF in all remaining unused bytes (i.e.		first place the value 0xFF in all remaining unused bytes (i.e.
	setting an End Indicator followed by Padding). The Encapsulator MUST		setting an End Indicator followed by Padding). The Encapsulator MUST
	start transmission of the next SNDU in a new TS Packet. (The		start transmission of the next SNDU in a new TS Packet. (The
	standard rules [ISO-MPEG] require the header of this new TS Packet		standard rules require the header of this new TS Packet to carry a
	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
	skipping to change at page 29, line 14		skipping to change at line 1219
	7. Receiver Processing		7. Receiver Processing
	A Receiver tunes to a specific TS Multiplex and sets a receive		A Receiver tunes to a specific TS Multiplex and sets a receive
	filter to accept all TS Packets with a specific PID. These TS		filter to accept all TS Packets with a specific PID. These TS
	Packets are associated with a specific TS Logical Channel and are		Packets are associated with a specific TS Logical Channel and are
	reassembled to form a stream of SNDUs. A single Receiver may be		reassembled to form a stream of SNDUs. A single Receiver may be
	able to receive multiple TS Logical Channels, possibly using a range		able to receive multiple TS Logical Channels, possibly using a range
	of TS Multiplexes. In each case, reassembly MUST be performed		of TS Multiplexes. In each case, reassembly MUST be performed
	independently for each TS Logical Channel. To perform this		independently for each TS Logical Channel. To perform this
			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
	skipping to change at page 29, line 40		skipping to change at line 1247
	with or without a Destination Address Field (i.e. D=0 and D=1).		with or without a Destination Address Field (i.e. D=0 and D=1).
	7.1 Idle State		7.1 Idle State
	After initialisation, errors, or on receipt of an End Indicator, the		After initialisation, errors, or on receipt of an End Indicator, the
	Receiver enters the Idle State. In this state, the Receiver discards		Receiver enters the Idle State. In this state, the Receiver discards
	all TS Packets until it discovers the start of a new SNDU, when it		all TS Packets until it discovers the start of a new SNDU, when it
	then enters the Reassembly State. Figure 16 outlines these state		then enters the Reassembly State. Figure 16 outlines these state
	transitions:		transitions:
			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
	skipping to change at page 30, line 4		skipping to change at line 1265
	+-------/| State |\-------+		+-------/| State |\-------+
	Insufficient | +----+-----+ |		Insufficient | +----+-----+ |
	unused space | | PUSI set | MPEG-2 TS Error		unused space | | PUSI set | MPEG-2 TS Error
	or | \/ | or		or | \/ | or
	End Indicator| +----------+ | SNDU Error		End Indicator| +----------+ | SNDU Error
	| |Reassembly| |		| |Reassembly| |
	+--------| State |--------+		+--------| State |--------+
	+----------+		+----------+
	Figure 16: Receiver state transitions		Figure 16: Receiver state transitions
	7.1.1 Idle State Payload Pointer Checking		7.1.1 Idle State Payload Pointer Checking
	A Receiver in the Idle State MUST check the PUSI value in the header		A Receiver in the Idle State MUST check the PUSI value in the header
	of all received TS Packets. A PUSI value of 1 indicates the presence		of all received TS Packets. A PUSI value of 1 indicates the presence
	of a Payload Pointer. Following a loss of synchronisation, values		of a Payload Pointer. Following a loss of synchronisation, values
	between 0 and 181 are permitted, in which case the Receiver MUST		between 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.
	7.2 Processing of a Received SNDU		7.2 Processing of a Received SNDU
	When in the Reassembly State, the Receiver reads a 2 byte SNDU		When in the Reassembly State, the Receiver reads a 2 byte SNDU
	Length 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 (see also 7.2.1). When Current SNDU length		TS Packet is reached. When Current SNDU length equals the value of
	equals the value of the Length Field, the Receiver MUST calculate		the Length Field, the Receiver MUST calculate and verify the CRC
	and verify the CRC value (section 4.6). SNDUs that contain an		value (section 4.6). SNDUs that contain an invalid CRC value MUST be
	invalid CRC value MUST be discarded. Mismatch of the CRC is an error		discarded, causing the Receiver to processes the next in-sequence
	event and SHOULD be recorded as a CRC error. The under-lying		SNDU (if any).
	physical-layer processing (e.g. forward error correction coding)
	often results in patterns of errors, rather than since bit errors,
	so the Receiver needs to be robust to arbitrary patterns of
	corruption to the TS Packet and payload, including potential
	corruption of the PUSI, PP, and SNDU Length fields. Therefore, a
	Receiver SHOULD discard the remaining TS Packet payload (if any)
	following a CRC musmatch and return to the Idle State.
	When the Destination Address is present (D=0), the Receiver accepts		When the Destination Address is present (D=0), the Receiver accepts
	SNDUs that match one of a set of addresses specified by the Receiver		SNDUs that match one of a set of addresses specified by the Receiver
	(this includes the NPA address of the Receiver, the NPA broadcast		(this includes the NPA address of the Receiver, the NPA broadcast
	address and any required multicast NPA addresses). The Receiver MUST		address and any required multicast NPA addresses). The Receiver MUST
	silently discard an SNDU with an unmatched address.		silently discard an SNDU with an unmatched address.
	After receiving a valid SNDU, the Receiver MUST check the Type Field		After receiving a valid SNDU, the Receiver MUST check the Type Field
	(and process any Type 1 Extension Headers). The SNDU payload is then		(and process any Type 1 extensions specified). The SNDU payload is
	passed to the next protocol layer specified. An SNDU with an unknown		then passed to the next protocol layer specified. An SNDU with an
	Type value < 1536 MUST be discarded. This error event SHOULD be		unknown Type value < 1536 MUST be discarded. This error event SHOULD
	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 page 31, line 37		skipping to change at line 1344
	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.
			Expires December 2004 [page 29]
	7.3 Other Error Conditions		7.3 Other Error Conditions
	The Receiver SHOULD check the MPEG-2 Transport Error Indicator		The Receiver SHOULD check the MPEG-2 Transport Error Indicator
	carried in the TS Packet header [ISO-MPEG]. This flag indicates a		carried in the TS Packet header. This flag indicates a transmission
	transmission error for a TS Logical Channel. If the flag is set to a		error for a TS Logical Channel. If the flag is set to a value of
	value of one, a transmission error event SHOULD be recorded. Any		one, a transmission error event SHOULD be recorded. Any partially
	partially received SNDU MUST be discarded. The Receiver then enters		received SNDU MUST be discarded. The Receiver then enters the Idle
	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.
	skipping to change at page 33, line 13		skipping to change at line 1382
	protocol.		protocol.
	8. Summary		8. Summary
	This document defines an Ultra Lightweight Encapsulation (ULE) to		This document defines an Ultra Lightweight Encapsulation (ULE) to
	perform efficient and flexible support for IPv4 and IPv6 network		perform efficient and flexible support for IPv4 and IPv6 network
	services over networks built upon the MPEG-2 Transport Stream (TS).		services over networks built upon the MPEG-2 Transport Stream (TS).
	The encapsulation is also suited to transport of other protocol		The encapsulation is also suited to transport of other protocol
	packets and bridged Ethernet frames.		packets and bridged Ethernet frames.
	ULE also provides an Extension Header format and defines an		ULE also provides an extension header format and defines an
	associated IANA registry for efficient and flexible support of both		associated IANA registry for efficient and flexible support of both
	mandatory and optional SNDU headers. This allows for future		mandatory and optional SNDU headers. This allows for future
	extension of the protocol, while providing backwards capability with		extension of the protocol, while providing backwards capability with
	existing implementations. In particular, Optional Extension Headers		existing implementations. In particular, Optional Extension Headers
	may safely be ignored by drivers that do not implement them, or		may safely be ignored by drivers that do not implement them, or
	choose not to process them.		choose not to process them.
			Expires December 2004 [page 30]
	9. Acknowledgments		9. Acknowledgments
	This draft is based on a previous draft authored by: Horst D.		This draft is based on a previous draft authored by: Horst D.
	Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry		Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry
	Fairhurst. The authors wish to thank the members of the ip-dvb		Fairhurst. The authors wish to thank the members of the ip-dvb
	mailing list for their input provided. In particular, the many		mailing list for their input provided. In particular, the many
	comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar		comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar
	Linder, Alain Ritoux, and William Stanislaus. Alain also provided		Linder, Alain Ritoux, and William Stanislaus. Alain also provided
	the original examples of usage.		the original examples of usage.
	skipping to change at page 34, line 37		skipping to change at line 1433
	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]. The		application layer security - not a replacement [ID-ipdvb-arch]. The
	approach is generic and decouples the encapsulation from future		approach is generic and decouples the encapsulation from future
	security extensions. The operation provides functions that resemble		security extensions. The operation provides functions that resemble
	those currently used with the MPE encapsulation.		those currently used with the MPE encapsulation.
	A ULE Mandatory Extension Header may in future be used to define a		A ULE Mandatory Extension Header may in future be used to define a
	method to perform link encryption. Additional security control		mechanism to perform link encryption . Additional security control
	fields may be provided as a part of the Extension Header, e.g. to		fields may be provided as a part of the extension header, e.g. to
	associate an SNDU with one of a set of Security Association (SA)		associate an SNDU with one of a set of Security Association (SA)
	parameters. As a part of the encryption process, it may also be		parameters. As a part of the encryption process, it may also be
	desirable to authenticate some/all of the SNDU headers. The method		desirable to authenticate some/all of the SNDU headers. The method
	of encryption and the way in which keys are exchanged is beyond the		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		scope of this specification, as also are the definition of the SA
	format and that of the related encryption keys.		format and that of the related encryption keys.
			Expires December 2004 [page 31]
	11. References		11. References
	11.1 Normative References		11.1 Normative References
	[ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic		[ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic
	coding of moving pictures and associated audio information:		coding of moving pictures and associated audio information:
	Systems", International Standards Organisation (ISO).		Systems", International Standards Organisation (ISO).
	[RFC2026] Bradner, S., "The Internet Standards Process - Revision		[RFC2026] Bradner, S., "The Internet Standards Process - Revision
	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.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
	3667, February 2004.
	[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.
	11.2 Informative References		11.2 Informative References
	[ID-ipdvb-arch] "Requirements for transmission of IP datagrams over		[ID-ipdvb-arch] "Requirements for transmission of IP datagrams over
	MPEG-2 networks", Internet Draft, Work in Progress.		MPEG-2 networks", Internet Draft, Work in Progress.
	[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television		[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
	Systems Committee (ATSC), Doc. A/53, 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.
	skipping to change at page 36, line 18		skipping to change at line 1501
	[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).
	[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", International Standards Organisation		6: Extensions for DSM-CC is a full software implementation",
	(ISO).		International Standards Organisation (ISO).
	[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification		[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
	Type AAL5, International Standards Organisation (ISO), 1996.		Type AAL5, International Standards Organisation (ISO), 1996.
	[LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2),		[LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2),
	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.
	skipping to change at page 37, line 21		skipping to change at line 1545
	UK		UK
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
	Web: http://www.erg.abdn.ac.uk/users/Gorry		Web: http://www.erg.abdn.ac.uk/users/Gorry
	Bernhard Collini-Nocker		Bernhard Collini-Nocker
	Department of Scientific Computing		Department of Scientific Computing
	University of Salzburg		University of Salzburg
	Jakob Haringer Str. 2		Jakob Haringer Str. 2
	5020 Salzburg		5020 Salzburg
	Austria		Austria
	Email: bnocker@cosy.sbg.ac.at		Email: [bnocker]@cosy.sbg.ac.at
	Web: http://www.scicomp.sbg.ac.at/		Web: http://www.cosy.sbg.ac.at/sc/
			Expires December 2004 [page 33]
	13. IPR Notices		13. IPR Notices
	13.1 Intellectual Property Statement		13.1 Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described		to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that		rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.		it has made any independent effort to identify any such rights.
	skipping to change at page 39, line 5		skipping to change at line 1592
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	14. Copyright Statement		14. Copyright Statement
	Copyright (C) The Internet Society (2004). This document is		Copyright (C) The Internet Society (2004). This document is
	subject to the rights, licenses and restrictions contained in		subject to the rights, licenses and restrictions contained in
	BCP 78, and except as set forth therein, the authors retain all		BCP 78, and except as set forth therein, the authors retain all
	their rights.		their rights.
			Expires December 2004 [page 34]
	15. IANA Considerations		15. IANA Considerations
	This document will require IANA involvement.		This document will require IANA involvement.
	The ULE Next-Header type field defined in this document requires a		The ULE type field defined in this document requires a registry. The
	registry:		payload type field defined in this document requires creation of a
			new IANA registry:
	ULE Next-Header registry		ULE Next-Protocol-Header registry
	This registry allocates values 0-512 (decimal).		This registry allocates values 0-512 (decimal).
	15.1 IANA Guidelines		15.1 IANA Guidelines
	The following contains the IANA guidelines for management of the ULE		The following contains the IANA guidelines for management of the ULE
	Next-Header registry. This registry allocates values decimal 0-512		Next-Protocol-Header registry. This registry allocates values
	(0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater		decimal 0-512 (0x0000-0x01FF, hexadecimal). It MUST NOT allocate
	than 0x01FF (decimal).		values greater than 0x01FF (decimal).
	It subdivides the Next-Header registry in the following way:		It subdivides the Next-Layer-Header registry in the following way:
	1) 0-255 (decimal) IANA assigned values indicating Mandatory		1) 0-255 (decimal) IANA assigned values indicating Mandatory
	Extension Headers (or link-dependent type fields) for ULE,		Extension Headers (or link-dependent type fields) for ULE,
	requiring expert review leading to prior issue of an IETF RFC.		requiring prior issue of an IETF RFC.
	This specification must define the value, and the name associated
	with the Extension Header. It must also define the need for the
	extension and the intended use. The size of the Extension Header
	must also be specified.
	Assignments made in this document:		Assignments made in this document:
	Type Name Reference		0: Test-SNDU
			1: Bridged-SNDU
	0: Test-SNDU Section 4.7.4.
	1: Bridged-SNDU Section 4.7.5.
	2) 256-511 (decimal) IANA assigned values indicating Optional		2) 256-511 (decimal) IANA assigned values indicating Optional
	Extension Headers for ULE, requiring expert review leading to		Extension Headers for ULE, requiring prior issue of an IETF RFC.
	prior issue of an IETF RFC. This specification must define the
	value, and the name associated with the Extension Header. The
	entry must specify range of allowable H-LEN values that are
	permitted (in the range 1-5). It must also define the need for the
	extension and the intended use.
	Assignments made in this document:		Assignments made in this document:
	Type Name H-LEN Reference		256: Padding
	256: Extension-Padding 1-5 Section 5.
			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 page 41, line 4		skipping to change at line 1678
	+-----+----*-+------+- -+------+-*----+------+- -+------+		+-----+----*-+------+- -+------+-*----+------+- -+------+
	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 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 page 42, line 4		skipping to change at line 1715
	+-----+------+------+------+- -+------+------+------+		+-----+------+------+------+- -+------+------+------+
	| 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 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 page 43, line 4		skipping to change at line 1761
	| HDR | B002 | ... | B185 |		| HDR | B002 | ... | B185 |
	+-----+------+- -+------+		+-----+------+- -+------+
	PUSI=0		PUSI=0
	End Stuffing		End Stuffing
	Indicator Bytes		Indicator Bytes
	+-----+------+- -+------+------+------+- -+------+		+-----+------+- -+------+------+------+- -+------+
	| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |		| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
	+-----+------+- -+------+------+------+- -+------+		+-----+------+- -+------+------+------+- -+------+
	PUSI=0		PUSI=0
			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 page 44, line 4		skipping to change at line 1802
	+ -+------+------+------+ -+------+------+------+- -+------+		+ -+------+------+------+ -+------+------+------+- -+------+
	+ ... | 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 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 page 45, line 4		skipping to change at line 1825
	| HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | ..		| HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | ..
	+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-		+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
	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 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: 00:01:02:03:04:05		Destination ULE NPA Address: 01:02:03:04:05:06
	ULE CRC32 : 0x4709a744		ULE CRC32 : 0x784679a5
	Source IPv6: 2001:660:3008:1789::5		Source IPv6: 2001:660:3008:1789::5
	Destination IPv6: 2001:660:3008:1789::6		Destination IPv6: 2001:660:3008:1789::6
	SNDU contents (including CRC-32):		SNDU contents (including CRC-32):
	0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d		0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d
	0016: 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
	0032: 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
	0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47		0030: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78
	0064: 09 a7 44		0040: 46 79 a5
			>>>> 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.19, available from http://www.levkowetz.com/ietf/tools/rfcdiff/