draft-ietf-ipdvb-arch-03.txt		draft-ietf-ipdvb-arch-02.txt
	Internet Engineering Task Force M.J. Montpetit ed.		Internet Engineering Task Force M.J. Montpetit ed.
	Internet Draft MJMontpetit.com, USA		Internet Draft MJMontpetit.com, USA
	Document: draft-ietf-ipdvb-arch-03.txt Gorry Fairhurst		Document: draft-ietf-ipdvb-arch-02.txt Gorry Fairhurst
	University of Aberdeen, U.K.		University of Aberdeen, U.K.
	Horst D. Clausen		Horst D. Clausen
	TIC Systems,USA		TIC Systems,USA
	Bernhard Collini-Nocker		Bernhard Collini-Nocker
	Hilmar Linder		Hilmar Linder
	University of Salzburg, Austria		University of Salzburg, Austria
	Category: Informational January 2005		Category: Informational December 2004
	A Framework for transmission of IP datagrams over MPEG-2 Networks		A Framework for transmission of IP datagrams over MPEG-2 Networks
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, we certify that any applicable		By submitting this Internet-Draft, we certify that any applicable
	patent or other IPR claims of which we are aware have been		patent or other IPR claims of which we are aware have been
	disclosed, or will be disclosed, and any of which we become aware		disclosed, or will be disclosed, and any of which we become aware
	will be disclosed, in accordance with RFC 3668.		will be disclosed, in accordance with RFC 3668.
	skipping to change at page 2, line 6		skipping to change at page 2, line 6
	Standards for Digital Television.		Standards for Digital Television.
	The document identifies the need for a set of Internet standards		The document identifies the need for a set of Internet standards
	defining the interface between the MPEG-2 Transport Stream and an		defining the interface between the MPEG-2 Transport Stream and an
	IP subnetwork. It suggests a new encapsulation method for IP		IP subnetwork. It suggests a new encapsulation method for IP
	datagrams and proposes protocols to perform IPv6/IPv4 address		datagrams and proposes protocols to perform IPv6/IPv4 address
	resolution, to associate IP packets with the properties of the		resolution, to associate IP packets with the properties of the
	Logical Channels provided by an MPEG-2 TS.		Logical Channels provided by an MPEG-2 TS.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1 Salient Features of the Architecture		1.1 Salient Features of the Architecture
	2. Conventions Used in This Document		2. Conventions Used in This Document
	3. Architecture		3. Architecture
	3.1 MPEG-2 Transmission Networks		3.1 MPEG-2 Transmission Networks
	3.2 TS Logical Channels		3.2 TS Logical Channels
	3.3 Multiplexing and Re-Multiplexing		3.3 Multiplexing and Re-Multiplexing
	skipping to change at page 3, line 6		skipping to change at page 3, line 6
	9. Acknowledgments		9. Acknowledgments
	10. References		10. References
	10.1 Normative References		10.1 Normative References
	10.2 Informative References		10.2 Informative References
	11. Author's Addresses		11. Author's Addresses
	12. IPR Notices		12. IPR Notices
	13. Copyright Statements		13. Copyright Statements
	14. IANA Considerations		14. IANA Considerations
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	[***RFC Editor Note: Remove following text prior to publication***]		[***RFC Editor Note: Remove following text prior to publication***]
	Change Notice:		Change Notice:
	- v00 Original ipdvb WG Version		- v00 Original ipdvb WG Version
	Document has been shortened and focused.		Document has been shortened and focused.
	Some annexe material has been removed.		Some annexe material has been removed.
	Restructured to describe the full framework.		Restructured to describe the full framework.
	New text describing the various scenarios.		New text describing the various scenarios.
	Text added on various issues including compatibility		Text added on various issues including compatibility
	with services on DVB and ATSC (and different physical links).		with services on DVB and ATSC (and different physical links).
	skipping to change at page 4, line 6		skipping to change at page 4, line 6
	- v02 Revised version following WGLC discussions		- v02 Revised version following WGLC discussions
	Updated figure 1.		Updated figure 1.
	Fixed author's affiliation.		Fixed author's affiliation.
	Fixed remaining typos and inconsistencies in page numbering.		Fixed remaining typos and inconsistencies in page numbering.
	Added DVB-S2, Open Cable and MHP references.		Added DVB-S2, Open Cable and MHP references.
	Removed a controversial paragraph in the Appendix.		Removed a controversial paragraph in the Appendix.
	[***RFC Editor Note: End of text to be removed***]		[***RFC Editor Note: End of text to be removed***]
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	1. Introduction		1. Introduction
	This document identifies requirements and an architecture for		This document identifies requirements and an architecture for
	transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2].		transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2].
	The prime focus is the efficient and flexible delivery of IP		The prime focus is the efficient and flexible delivery of IP
	services over those subnetworks that use the MPEG-2 Transport		services over those subnetworks that use the MPEG-2 Transport
	Stream (TS).		Stream (TS).
	The architecture is designed to be compatible with services		The architecture is designed to be compatible with services
	skipping to change at page 5, line 6		skipping to change at page 5, line 6
	Although many MPEG-2 systems carry a mixture of data types, MPEG-2		Although many MPEG-2 systems carry a mixture of data types, MPEG-2
	components may, and are, also used to build IP-only networks.		components may, and are, also used to build IP-only networks.
	Standard system components offer advantages of improved		Standard system components offer advantages of improved
	interoperability and larger deployment. However, often, MPEG-2		interoperability and larger deployment. However, often, MPEG-2
	networks do not implement all parts of a DVB / ATSC system,		networks do not implement all parts of a DVB / ATSC system,
	and may for instance support minimal, or no, signalling of		and may for instance support minimal, or no, signalling of
	Service Information (SI) tables.		Service Information (SI) tables.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	1.1 Salient Features of the Architecture		1.1 Salient Features of the Architecture
	The architecture defined in this document describes a set of		The architecture defined in this document describes a set of
	protocols that support transmission of IP packets over the MPEG-2		protocols that support transmission of IP packets over the MPEG-2
	TS. Key characteristics of these networks are that they may		TS. Key characteristics of these networks are that they may
	provide link-level broadcast capability, and that many supported		provide link-level broadcast capability, and that many supported
	applications require access to a very large number of subnetwork		applications require access to a very large number of subnetwork
	nodes.		nodes.
	skipping to change at page 6, line 6		skipping to change at page 6, line 6
	Logical Channel may also be used to provide Quality of Service		Logical Channel may also be used to provide Quality of Service
	(QoS). Mapping functions are required to relate TS Logical Channels		(QoS). Mapping functions are required to relate TS Logical Channels
	to IP addresses, to map TS Logical Channels to IP-level QoS, and to		to IP addresses, to map TS Logical Channels to IP-level QoS, and to
	associate IP flows with specific subnetwork capabilities. An		associate IP flows with specific subnetwork capabilities. An
	important feature of the architecture is that these functions may be		important feature of the architecture is that these functions may be
	provided in a dynamic way, allowing transparent integration with		provided in a dynamic way, allowing transparent integration with
	other IP-layer protocols. Collectively, these will form an MPEG-2		other IP-layer protocols. Collectively, these will form an MPEG-2
	TS address resolution protocol suite.		TS address resolution protocol suite.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	2. Conventions Used In This Document		2. Conventions Used In This Document
	A2. Conventions Used In This Document
	Adaptation Field: An optional variable-length extension field of		Adaptation Field: An optional variable-length extension field of
	the fixed-length TS Packet header, intended to convey clock		the fixed-length TS Packet header, intended to convey clock
	references and timing and synchronization information as well as		references and timing and synchronization information as well as
	stuffing over an MPEG-2 Multiplex [ISO-MPEG].		stuffing over an MPEG-2 Multiplex [ISO-MPEG].
	ATSC: Advanced Television Systems Committee [ATSC]. A framework		ATSC: Advanced Television Systems Committee [ATSC]. A framework
	and a set of associated standards for the transmission of video,		and a set of associated standards for the transmission of video,
	audio, and data using the ISO MPEG-2 standard.		audio, and data using the ISO MPEG-2 standard.
	DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC].		DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC].
	A format for transmission of data and control information defined		A format for transmission of data and control information defined
	by the ISO MPEG-2 standard that is carried in an MPEG-2 Private		by 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 set of framework and
	associated standards published by the European Telecommunications		associated standards published by the European Telecommunications
	Standards Institute (ETSI) for the transmission of video, audio,		Standards Institute (ETSI) for the transmission of video, audio,
	and data, using the ISO MPEG-2 Standard.		and 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.
	Forward Direction: The dominant direction of data transfer over a		FORWARD DIRECTION: The dominant direction of data transfer over a
	network path. Data transfer in the forward direction is called		network path. Data transfer in the forward direction is called
	"forward transfer". Packets travelling in the forward direction		"forward transfer". Packets travelling in the forward direction
	follow the forward path through the IP network.		follow the forward path through the IP network.
	MAC: Medium Access and Control. The link layer header of the		MAC: Medium Access and Control. The link layer header of the
	Ethernet IEEE 802 standard of protocols, consisting of a 6B		Ethernet IEEE 802 standard of protocols, consisting of a 6B
	destination address, 6B source address, and 2B type field (see		destination address, 6B source address, and 2B type field (see
	also NPA).		also NPA).
	MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG].		MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG].
	A scheme that encapsulates PDUs, forming a DSM-CC Table Section.		A scheme that encapsulates PDUs, forming a DSM-CC Table Section.
	Each Section is sent in a series of TS Packets using a single TS		Each Section is sent in a series of TS Packets using a single TS
	Logical Channel.		Logical Channel.
	MPEG-2: A set of standards specified by the Motion Picture		MPEG-2: A set of standards specified by the Motion Picture
	Experts Group (MPEG), and standardized by the International		Experts Group (MPEG), and standardized by the International
	Standards Organisation (ISO) [ISO-MPEG].		Standards Organisation (ISO) [ISO-MPEG].
	NPA: Network Point of Attachment. Addresses primarily used for		NPA: Network Point of Attachment. Addresses primarily used for
	station (Receiver) identification within a local network (e.g.		station (Receiver) identification within a local network (e.g.
	IEEE MAC address). An address may identify individual Receivers		IEEE MAC address).
	or groups of Receivers.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
	IPv4 or IPv6 datagrams, and other network packets.
	PES: Packetized Elementary Steam [ISO-MPEG]. A format of MPEG-2 TS		PES: Packetized Elementary Stream. A format of MPEG-2 TS packet
	packet payload usually used for video or audio information.		payload usually used for video or audio information in MPEG-2
			[ISO-MPEG].
	PID: Packet Identifier [ISO_MPEG]. A 13 bit field carried in the		PID: Packet Identifier. A 13 bit field carried in the header of TS
	header of TS Packets. This is used to identify the TS Logical		Packets. This is used to identify the TS Logical Channel to which a
	Channel to which a TS Packet belongs [ISO-MPEG]. The TS Packets		TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a
	forming the parts of a Table Section, PES, or other Payload Unit		Table Section, PES, or other payload unit must all carry the same
	must all carry the same PID value. The all 1s PID value indicates		PID value. The all 1s PID value (0x1FFF in hexadecimal) indicates
	a Null TS Packet introduced to maintain a constant bit rate of		a Null TS Packet introduced to maintain a constant bit rate of a
	a TS Multiplex. There is no required relationship between the PID		TS Multiplex.
	values used for TS LogicalChannels transmitted using different
	TS Multiplexes.
	PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that		PP: Payload Pointer. An optional one byte pointer that directly
	directly follows the TS Packet header. It contains the number of		follows the TS Packet header. It contains the number of bytes
	bytes between the end of the TS Packet header and the start of a		between the end of the TS Packet header and the start of a Payload
	Payload Unit. The presence of the Payload Pointer is indicated by		Unit. The presence of the Payload Pointer is indicated by the value
	the value of the PUSI bit in the TS Packet header. The Payload		of the PUSI bit in the TS Packet header. The Payload Pointer is
	Pointer is present in DSM-CC, and Table Sections, it is not present		present in DSM-CC, and Table Sections, it is not present in TS
	in TS Logical Channels that use the PES-format.		Logical Channels that use the PES-format.
	Private Section: A syntactic structure constructed in accordance		PU: Payload Unit.
	with Table 2-30 of [ISO-MPEG]. The structure may be used to
	identify private information (i.e. not defined by [ISO-MPEG])
	relating to one or more elementary streams, or a specific MPEG-2
	program, or the entire TS. Other Standards bodies, e.g. ETSI,
	ATSC, have defined sets of table structures using the
	private_section structure. A Private Section is transmitted as a
	sequence of TS Packets using a TS Logical Channel. A TS Logical
	Channel may carry sections from more than one set of tables.
	PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey		PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single
	information about services carried in a TS Multiplex. It is carried		bit flag carried in the TS Packet header. A PUSI value of 0
	in one of four specifically identified table section constructs		indicates that the TS Packet does not carry the start of a new
	[ISO-MPEG], see also SI Table.		Payload Unit. A PUSI value of 1 indicates that the TS Packet does
			carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1
			also indicates the presence of a one byte Payload Pointer (PP).
	PU: Payload Unit. A sequence of bytes sent using a TS. Examples of		PRIVATE SECTION: A syntactic structure used for mapping all
	Payload Units include: an MPEG-2 Table Section or a ULE SNDU.		service information (e.g. an SI table) into TS Packets. A table
			may be divided into a number of sections. All sections of a table
			must be carried over a single TS Logical Channel.
	PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. A single bit flag		PSI: Program Specific Information. Tables used to convey information
	carried in the TS Packet header. A PUSI value of zero indicates		about the service carried in a TS Multiplex. The set of PSI tables
	that the TS Packet does not carry the start of a new Payload Unit.		is defined by [ISO-MPEG], see also SI Table.
	A PUSI value of one indicates that the TS Packet does carry the
	start of a new Payload Unit. In ULE, a PUSI bit set to 1 also
	indicates the presence of a one byte Payload Pointer (PP).
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		Receiver: An equipment that processes the signal from a TS Multiplex
	January 2005		and performs filtering and forwarding of encapsulated PDUs to the
			network-layer service (or bridging module when operating at the link
			layer).
	Receiver: An equipment that processes the signal from a		SI TABLE: Service Information Table. In this document, the term is
	TS Multiplex and performs filtering and forwarding of encapsulated		used to describe any table used to convey information about the
	PDUs to the network-layer service (or bridging module when		service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are
	operating at the link layer).		carried in MPEG-2 Private Sections.
	SI Table: Service Information Table [ISO-MPEG]. In this document,		SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
	this term describes a table that is used to convey information		Payload Unit.
	about the services carried in a TS Multiplex, that has been defined
	by another standards body. A Table may consist of one or more Table
	Sections, however all sections of a particular SI Table must be
	carried over a single TS Logical Channel [ISO-MPEG].
	SNDU: Subnetwork Data Unit [RFC3819]. An encapsulated PDU sent as		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	an MPEG-2 Payload Unit.		December 2004
	STB: Set-Top Box. A consumer equipment (Receiver) for reception of		STB: Set-Top Box. A consumer equipment (Receiver) for reception of
	digital TV services.		digital TV services.
	Table Section: A Payload Unit carrying all or a part of an SI or		TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table.
	PSI Table [ISO-MPEG].
	TS: Transport Stream [ISO-MPEG], a method of transmission at the		TS: Transport Stream [ISO-MPEG], a method of transmission at the
	MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI		MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI
	reference model. See also TS Logical Channel and TS Multiplex.		reference model. See also TS Logical Channel and TS Multiplex.
	TS Header: The 4 byte header of a TS Packet [ISO-MPEG].		TS HEADER: The 4 byte header of a TS Packet.
	TS Logical Channel: Transport Stream Logical Channel. In this		TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel
	document, this term identifies a channel at the MPEG-2 level		identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of
	[ISO-MPEG]. It exists at level 2 of the ISO/OSI reference model.		the ISO/OSI reference model. All packets sent over a TS Logical
	All packets sent over a TS Logical Channel carry the same PID value		Channel carry the same PID value. According to MPEG-2, some TS
	(this value is unique within a specific TS Multiplex). According to		Logical Channels are reserved for specific signalling purposes.
	MPEG-2, some TS Logical Channels are reserved for specific		Other standards (e.g., ATSC, DVB) also reserve specific TS Logical
	signalling. Other standards (e.g., ATSC, DVB) also reserve specific		Channels.
	TS Logical Channels.
	TS Multiplex: In this document, this term defines a set of MPEG-2		TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single
	TS Logical Channels sent over a single lower layer connection.		common physical link (i.e. a transmission at a specified symbol
	This may be a common physical link (i.e. a transmission at a		rate, FEC setting, and transmission frequency). The same TS Logical
	specified symbol rate, FEC setting, and transmission frequency) or		Channel may be repeated over more than one TS Multiplex, for example
	an encapsulation provided by another protocol layer (e.g. Ethernet,		to redistribute the same multicast content to two terrestrial TV
	or RTP over IP). The same TS Logical Channel may be repeated over		transmission cells.
	more than one TS Multiplex (possibly associated with a different
	PID value) [ID-ipdvb-arch], for example to redistribute the same
	multicast content to two terrestrial TV transmission cells.
	TS Packet: A fixed-length 188B unit of data sent over a		TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex
	TS Multiplex [ISO-MPEG]. Each TS Packet carries a 4B header, plus		[ISO-MPEG]. Each TS Packet carries a 4B header, plus optional
	optional overhead including an Adaptation Field, encryption details		overhead including an Adaptation Field, encryption details and time
	and time stamp information to synchronise a set of related TS		stamp information to synchronise a set of related TSs.
	Logical Channels. It is also referred to as a TS_cell. Each TS		It is also referred to as a TS_cell. Each TS packet carries a PID
	Packet carries a PID value to associate it with a single TS Logical		value to associate it with a single TS Logical Channel.
	Channel.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	3. Architecture		3. Architecture
	The following sections introduce the components of the MPEG-2		The following sections introduce the components of the MPEG-2
	Transmission Network and relate these to a networking framework.		Transmission Network and relate these to a networking framework.
	3.1 MPEG-2 Transmission Networks		3.1 MPEG-2 Transmission Networks
	There are many possible topologies for MPEG-2 Transmission		There are many possible topologies for MPEG-2 Transmission
	Networks. A number of example scenarios are briefly described		Networks. A number of example scenarios are briefly described
	skipping to change at page 10, line 6		skipping to change at page 10, line 6
	The Uni-directional Star IP Scenario utilises a Hub station to		The Uni-directional Star IP Scenario utilises a Hub station to
	provide a data network delivering a common bit stream to typically		provide a data network delivering a common bit stream to typically
	medium-sized groups of Receivers. MPEG-2 transmission technology		medium-sized groups of Receivers. MPEG-2 transmission technology
	provides the forward direction physical and link layers for this		provides the forward direction physical and link layers for this
	transmission, the return link (if required) is provided by other		transmission, the return link (if required) is provided by other
	means. IP services typically form the main proportion of the		means. IP services typically form the main proportion of the
	transmission traffic. Such networks do not necessarily implement		transmission traffic. Such networks do not necessarily implement
	the MPEG-2 control plane, i.e. PSI/SI tables.		the MPEG-2 control plane, i.e. PSI/SI tables.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	D) Datacast Overlay		D) Datacast Overlay
	The Datacast Overlay scenario employs MPEG-2 physical and link		The Datacast Overlay scenario employs MPEG-2 physical and link
	layers to provide additional connectivity such as uni-directional		layers to provide additional connectivity such as uni-directional
	multicast to supplement an existing IP-based Internet service.		multicast to supplement an existing IP-based Internet service.
	Examples of such a network includes IP Datacast to mobile wireless		Examples of such a network includes IP Datacast to mobile wireless
	receivers [ID-MMUSIC-IMG].		receivers [ID-MMUSIC-IMG].
	E) Point-to-Point Links		E) Point-to-Point Links
	Point-to-Point connectivity may be provided using a pair of		Point-to-Point connectivity may be provided using a pair of
	skipping to change at page 11, line 6		skipping to change at page 11, line 6
	Note that only Scenarios A-B actually carry MPEG-2 video and audio		Note that only Scenarios A-B actually carry MPEG-2 video and audio
	intended for reception by digital Set Top Boxes (STBs) as the		intended for reception by digital Set Top Boxes (STBs) as the
	primary traffic. The other scenarios are IP-based data networks and		primary traffic. The other scenarios are IP-based data networks and
	need not necessarily implement the MPEG-2 control plane.		need not necessarily implement the MPEG-2 control plane.
	Scenarios E-F provide two-way connectivity using the MPEG-2		Scenarios E-F provide two-way connectivity using the MPEG-2
	Transmission Network. Such networks provide direct support for		Transmission Network. Such networks provide direct support for
	bi-directional protocols above and below the IP layer.		bi-directional protocols above and below the IP layer.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	The complete MPEG-2 transmission network may be managed by a		The complete MPEG-2 transmission network may be managed by a
	transmission service operator. In such cases, the assignment of		transmission service operator. In such cases, the assignment of
	addresses and TS Logical Channels at Receivers are usually under		addresses and TS Logical Channels at Receivers are usually under
	the control of the service operator. Examples include a TV		the control of the service operator. Examples include a TV
	operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2		operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2
	transmission networks are also used for private networks. These		transmission networks are also used for private networks. These
	typically involve a smaller number of Receivers and do not require		typically involve a smaller number of Receivers and do not require
	the same level of centralised control. Examples include companies		the same level of centralised control. Examples include companies
	wishing to connect DVB-capable routers to form links within the		wishing to connect DVB-capable routers to form links within the
	skipping to change at page 12, line 6		skipping to change at page 12, line 6
	| | | |		| | | |
	/-------- / | ---------		/-------- / | ---------
	/ \----/-----------------------\----/		/ \----/-----------------------\----/
	/ MPEG-2 TS MUX B		/ MPEG-2 TS MUX B
	TS-LC-B-1		TS-LC-B-1
	Figure 2: Example showing MPEG-2 TS Logical Channels carried		Figure 2: Example showing MPEG-2 TS Logical Channels carried
	Over 2 MPEG-2 TS Multiplexes.		Over 2 MPEG-2 TS Multiplexes.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	TS Logical Channels are independently numbered on each MPEG-2 TS		TS Logical Channels are independently numbered on each MPEG-2 TS
	Multiplex (MUX). In most cases the data sent over the TS Logical		Multiplex (MUX). In most cases the data sent over the TS Logical
	Channels will differ for different multiplexes. Figure 2		Channels will differ for different multiplexes. Figure 2
	shows a set of TS Logical Channels sent using two MPEG-2 TS		shows a set of TS Logical Channels sent using two MPEG-2 TS
	Multiplexes (A and B).		Multiplexes (A and B).
	There are cases where the same data may be distributed over two or		There are cases where the same data may be distributed over two or
	more multiplexes (e.g., some SI tables; multicast content which		more multiplexes (e.g., some SI tables; multicast content which
	needs to be received by Receivers tuned to either MPEG-2 TS; unicast		needs to be received by Receivers tuned to either MPEG-2 TS; unicast
	skipping to change at page 13, line 6		skipping to change at page 13, line 6
	part of the remultiplexing process, a remultiplexor may renumber the		part of the remultiplexing process, a remultiplexor may renumber the
	PID values associated with one or more TS Logical Channels to		PID values associated with one or more TS Logical Channels to
	prevent clashes between input TS Logical Channels with the same PID		prevent clashes between input TS Logical Channels with the same PID
	carried on different input multiplexes. It may also modify and/or		carried on different input multiplexes. It may also modify and/or
	insert new SI data into the control plane.		insert new SI data into the control plane.
	In all cases, the final result is a "TS Multiplex" which is		In all cases, the final result is a "TS Multiplex" which is
	transmitted over the physical bearer towards the Receiver.		transmitted over the physical bearer towards the Receiver.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
	January 2005		December 2004
	+------------+ +------------+		+------------+ +------------+
	| IP | | IP |		| IP | | IP |
	| End Host | | End Host |		| End Host | | End Host |
	+-----+------+ +------------+		+-----+------+ +------------+
	| ^		| ^
	+------------>+---------------+ |		+------------>+---------------+ |
	+ IP | |		+ IP | |
	+-------------+ Encapsulator | |		+-------------+ Encapsulator | |
	SI-Data | +------+--------+ |		SI-Data | +------+--------+ |
	skipping to change at page 14, line 6		skipping to change at page 14, line 6
	SNDUs are subsequently fragmented into a series of TS Packets.		SNDUs are subsequently fragmented into a series of TS Packets.
	To receive IP packets over a MPEG-2 TS Multiplex, a Receiver		To receive IP packets over a MPEG-2 TS Multiplex, a Receiver
	needs to identify the specific TS Multiplex (physical link) and also		needs to identify the specific TS Multiplex (physical link) and also
	the TS Logical Channel (the PID value of a logical link). It is		the TS Logical Channel (the PID value of a logical link). It is
	common for a number of MPEG-2 TS Logical Channels to carry SNDUs,		common for a number of MPEG-2 TS Logical Channels to carry SNDUs,
	and a Receiver must therefore filter (accept) IP packets sent with a		and a Receiver must therefore filter (accept) IP packets sent with a
	number of PID values, and must independently reassemble each SNDU.		number of PID values, and must independently reassemble each SNDU.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	A Receiver that simultaneously receives from several TS Logical		A Receiver that simultaneously receives from several TS Logical
	Channels, must filter other unwanted TS Logical Channels by		Channels, must filter other unwanted TS Logical Channels by
	employing for example specific hardware support. Packets for one IP		employing for example specific hardware support. Packets for one IP
	flow (i.e. a specific combination of IP source and destination		flow (i.e. a specific combination of IP source and destination
	addresses) must be sent using the same PID. It should not be assumed		addresses) must be sent using the same PID. It should not be assumed
	that all IP packets are carried on a single PID, as in some cable		that all IP packets are carried on a single PID, as in some cable
	modem implementations, and multiple PIDs must be allowed in the		modem implementations, and multiple PIDs must be allowed in the
	architecture. Many current hardware filters limit the maximum number		architecture. Many current hardware filters limit the maximum number
	of active PIDs (e.g. 32), although if needed, future systems may		of active PIDs (e.g. 32), although if needed, future systems may
	skipping to change at page 15, line 6		skipping to change at page 15, line 6
	(i) Guidance on which MPEG-2 features are pre-requisites for the IP		(i) Guidance on which MPEG-2 features are pre-requisites for the IP
	service, and identification of any optional fields that impact		service, and identification of any optional fields that impact
	performance/correct operation.		performance/correct operation.
	(ii) Standards to provide an efficient and flexible encapsulation		(ii) Standards to provide an efficient and flexible encapsulation
	scheme that may be easily implemented in an Encapsulator or		scheme that may be easily implemented in an Encapsulator or
	Receiver. The payload encapsulation requires a type field for		Receiver. The payload encapsulation requires a type field for
	the SNDU to indicate the type of packet and a mechanism to		the SNDU to indicate the type of packet and a mechanism to
	signal which encapsulation is used on a certain PID.		signal which encapsulation is used on a certain PID.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	(iii) Standards to associate a particular IP address with a Network		(iii) Standards to associate a particular IP address with a Network
	Point of Attachment (NPA) that could or may not be a MAC		Point of Attachment (NPA) that could or may not be a MAC
	Address. This process resembles the IPv4 Address Resolution		Address. This process resembles the IPv4 Address Resolution
	Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-		Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
	DRAFT]. In addition, the standard will be compatible with IPv6		DRAFT]. In addition, the standard will be compatible with IPv6
	autoconfiguration.		autoconfiguration.
	(iv) Standards to associate a MPEG-2 TS interface with one or more		(iv) Standards to associate a MPEG-2 TS interface with one or more
	specific TS Logical Channels (PID, TS Multiplex). Bindings are		specific TS Logical Channels (PID, TS Multiplex). Bindings are
	required for both unicast transmission, and multicast		required for both unicast transmission, and multicast
	skipping to change at page 16, line 6		skipping to change at page 16, line 6
	The specified architecture and techniques should be suited to a		The specified architecture and techniques should be suited to a
	range of systems employing the MPEG-2 TS, and may also suit other		range of systems employing the MPEG-2 TS, and may also suit other
	(sub)networks offering similar transfer capabilities.		(sub)networks offering similar transfer capabilities.
	The following section, 4, describes encapsulation issues.		The following section, 4, describes encapsulation issues.
	Sections 6 and 7 describe address resolution issues for unicast and		Sections 6 and 7 describe address resolution issues for unicast and
	multicast respectively.		multicast respectively.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	4. Encapsulation Protocol Requirements		4. Encapsulation Protocol Requirements
	This section identifies requirements and provides examples of		This section identifies requirements and provides examples of
	mechanisms that may be used to perform the encapsulation of IPv4/v6		mechanisms that may be used to perform the encapsulation of IPv4/v6
	unicast and multicast packets over MPEG-2 Transmission Networks.		unicast and multicast packets over MPEG-2 Transmission Networks.
	A network device, known as an Encapsulator receives PDUs (e.g. IP		A network device, known as an Encapsulator receives PDUs (e.g. IP
	Packets or Ethernet frames) and formats these into Subnetwork Data		Packets or Ethernet frames) and formats these into Subnetwork Data
	Units,SNDUs. An encapsulation (or convergence) protocol transports		Units,SNDUs. An encapsulation (or convergence) protocol transports
	skipping to change at page 17, line 6		skipping to change at page 17, line 6
	|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |		|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
	|Header| Payload | |Header| Payload | |Header| Payload |		|Header| Payload | |Header| Payload | |Header| Payload |
	+------+----------+ +------+----------+ +------+----------+		+------+----------+ +------+----------+ +------+----------+
	Figure 5: Encapsulation of an PDU (e.g., IP packet) into a		Figure 5: Encapsulation of an PDU (e.g., IP packet) into a
	Series of MPEG-2 TS Packets. Each TS Packet carries a header		Series of MPEG-2 TS Packets. Each TS Packet carries a header
	with a common Packet ID (PID) value denoting the MPEG-2 TS		with a common Packet ID (PID) value denoting the MPEG-2 TS
	Logical Channel.		Logical Channel.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	The DVB family of standards currently defines a mechanism for		The DVB family of standards currently defines a mechanism for
	transporting an IP packet, or Ethernet frame using the		transporting an IP packet, or Ethernet frame using the
	Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme		Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme
	is also supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows		is also supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows
	transmission of IP packets or (by using LLC) Ethernet frames by		transmission of IP packets or (by using LLC) Ethernet frames by
	encapsulation within a Table Section (with the format used by the		encapsulation within a Table Section (with the format used by the
	control plane associated with the MPEG-2 transmission). The MPE		control plane associated with the MPEG-2 transmission). The MPE
	specification includes a set of optional header components and		specification includes a set of optional header components and
	requires decoding of the control headers. This processing is		requires decoding of the control headers. This processing is
	skipping to change at page 18, line 6		skipping to change at page 18, line 6
	does not carry the first byte of a Table Section, the PUSI is set to		does not carry the first byte of a Table Section, the PUSI is set to
	'0', indicating that no Payload Pointer is present.		'0', indicating that no Payload Pointer is present.
	Using this PUSI bit, the start of the first Payload Unit in a TS		Using this PUSI bit, the start of the first Payload Unit in a TS
	Packet is exactly known by the Receiver, unless that TS Packet has		Packet is exactly known by the Receiver, unless that TS Packet has
	been corrupted or lost in the transmission. In which case, the		been corrupted or lost in the transmission. In which case, the
	payload is discarded until the next TS Packet is received with a		payload is discarded until the next TS Packet is received with a
	PUSI value of '1'.		PUSI value of '1'.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	The encapsulation should allow packing of more than one SNDU into		The encapsulation should allow packing of more than one SNDU into
	the same TS Packet and should not limit the number of SNDUs that can		the same TS Packet and should not limit the number of SNDUs that can
	be sent in a TS Packet. In addition, it should allow an IP		be sent in a TS Packet. In addition, it should allow an IP
	Encapsulator to insert padding when there is an incomplete TS Packet		Encapsulator to insert padding when there is an incomplete TS Packet
	payload. A mechanism needs to be identified to differentiate this		payload. A mechanism needs to be identified to differentiate this
	padding from the case where another encapsulated SNDU follows.		padding from the case where another encapsulated SNDU follows.
	A combination of the PUSI and a Length Indicator (see below) allows		A combination of the PUSI and a Length Indicator (see below) allows
	an efficient MPEG-2 convergence protocol to receive accurate		an efficient MPEG-2 convergence protocol to receive accurate
	skipping to change at page 19, line 6		skipping to change at page 19, line 6
	etc). Most protocols use a type field to identify a specific		etc). Most protocols use a type field to identify a specific
	process at the next higher layer that is the originator or the		process at the next higher layer that is the originator or the
	recipient of the payload (SNDU). This method is used by IPv4,		recipient of the payload (SNDU). This method is used by IPv4,
	IPv6, and also by the original Ethernet protocol (DIX). OSI		IPv6, and also by the original Ethernet protocol (DIX). OSI
	uses the concept of a 'Selector' for this, (e.g. in the IEEE		uses the concept of a 'Selector' for this, (e.g. in the IEEE
	802/ISO 8802 standards for CSMA/CD [LLC], although in this		802/ISO 8802 standards for CSMA/CD [LLC], although in this
	case a SNAP (subnetwork access protocol) header is also		case a SNAP (subnetwork access protocol) header is also
	required for IP packets.		required for IP packets.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	A Next Level Protocol Type field is also required if compression		A Next Level Protocol Type field is also required if compression
	(e.g. Robust Header Compression [RFCROHC]) is supported. No		(e.g. Robust Header Compression [RFCROHC]) is supported. No
	compression method has currently been defined that is directly		compression method has currently been defined that is directly
	applicable to this architecture, however the ROHC framework		applicable to this architecture, however the ROHC framework
	defines a number of header compression techniques that may yield		defines a number of header compression techniques that may yield
	considerable improvement in throughput on links which have a limited		considerable improvement in throughput on links which have a limited
	capacity. Since many MPEG-2 Transmission Networks are wireless,		capacity. Since many MPEG-2 Transmission Networks are wireless,
	the ROHC framework will be directly applicable for many		the ROHC framework will be directly applicable for many
	applications. The benefit of ROHC is greatest for smaller SNDUs		applications. The benefit of ROHC is greatest for smaller SNDUs
	skipping to change at page 20, line 6		skipping to change at page 20, line 6
	unicast packets within the (software) interface driver at the		unicast packets within the (software) interface driver at the
	Receiver, but must also perform forwarding checks based on the IP		Receiver, but must also perform forwarding checks based on the IP
	address. IP multicast and broadcast may also filter using the		address. IP multicast and broadcast may also filter using the
	NPA, but Receivers must also filter unwanted packets at the network		NPA, but Receivers must also filter unwanted packets at the network
	layer based on source and destination IP addresses. This does not		layer based on source and destination IP addresses. This does not
	imply that each IP address must map to a unique NPA (more than one		imply that each IP address must map to a unique NPA (more than one
	IP address may map to the same NPA). If a separate NPA address is		IP address may map to the same NPA). If a separate NPA address is
	not required, the IP address is sufficient for both functions.		not required, the IP address is sufficient for both functions.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	If it is required to address an individual Receiver in an MPEG-2		If it is required to address an individual Receiver in an MPEG-2
	transport system, this can be achieved either at the network level		transport system, this can be achieved either at the network level
	(IP address) or via a hardware-level NPA address (MAC-address). If		(IP address) or via a hardware-level NPA address (MAC-address). If
	both addresses used, they must be mapped either in a static or a		both addresses used, they must be mapped either in a static or a
	dynamic way (e.g., by an address resolution process). A similar		dynamic way (e.g., by an address resolution process). A similar
	requirement may also exist to identify the PID and TS multiplex on		requirement may also exist to identify the PID and TS multiplex on
	which services are carried.		which services are carried.
	Using an NPA address in a MPEG-2 TS may enhance security, in that		Using an NPA address in a MPEG-2 TS may enhance security, in that
	skipping to change at page 21, line 6		skipping to change at page 21, line 6
	MPEG-2 TS Packet header).		MPEG-2 TS Packet header).
	An encapsulation must provide a strong integrity check for each		An encapsulation must provide a strong integrity check for each
	IP packet. The requirements for usage of a link CRC are provided		IP packet. The requirements for usage of a link CRC are provided
	in [RFC3819]. To ease hardware implementation, this check should		in [RFC3819]. To ease hardware implementation, this check should
	be carried in a trailer following the SNDU. A CRC-32 is sufficient		be carried in a trailer following the SNDU. A CRC-32 is sufficient
	for operation with up to a 12 KB payload, and may still provide		for operation with up to a 12 KB payload, and may still provide
	adequate protection for larger payloads.		adequate protection for larger payloads.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	4.6 Identification of Scope.		4.6 Identification of Scope.
	The MPE section header contains information that could be used by		The MPE section header contains information that could be used by
	The Receiver to identify the scope of the (MAC) address carried as a		The Receiver to identify the scope of the (MAC) address carried as a
	NPA, and prevent TS Packets intended for one scope being received by		NPA, and prevent TS Packets intended for one scope being received by
	another. Similar functionality may be achieved by ensuring that only		another. Similar functionality may be achieved by ensuring that only
	IP packets that do not have overlapping scope are sent on the same		IP packets that do not have overlapping scope are sent on the same
	TS Logical Channel. In some cases, this may imply the use of		TS Logical Channel. In some cases, this may imply the use of
	multiple TS Logical Channels.		multiple TS Logical Channels.
	skipping to change at page 22, line 6		skipping to change at page 22, line 6
	- a fully specified algorithm that allows a sender to pack		- a fully specified algorithm that allows a sender to pack
	multiple packets per SNDU and to easily locate packet		multiple packets per SNDU and to easily locate packet
	fragments		fragments
	- extensibility		- extensibility
	- compatibility with legacy deployments		- compatibility with legacy deployments
	- ability to allow link encryption, when required		- ability to allow link encryption, when required
	- capability to support a full network architecture including		- capability to support a full network architecture including
	data, control and management planes		data, control and management planes
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	5. Address Resolution Functions		5. Address Resolution Functions
	Address Resolution (AR) provides a mechanism that associates L2		Address Resolution (AR) provides a mechanism that associates L2
	information with the IP address of a system. Many L2 technologies		information with the IP address of a system. Many L2 technologies
	employ unicast AR at the sender: an IP system wishing to send an IP		employ unicast AR at the sender: an IP system wishing to send an IP
	packet encapsulates it and places it into a L2 frame. It then		packet encapsulates it and places it into a L2 frame. It then
	identifies the appropriate L3 adjacency (e.g. next hop router, end		identifies the appropriate L3 adjacency (e.g. next hop router, end
	host) and determines the appropriate L2 adjacency (e.g. MAC address		host) and determines the appropriate L2 adjacency (e.g. MAC address
	in Ethernet) to which the frame should be sent so that the packet		in Ethernet) to which the frame should be sent so that the packet
	skipping to change at page 23, line 6		skipping to change at page 23, line 6
	Elements (ii) and (iii) need to be de-referenced via indexes to the		Elements (ii) and (iii) need to be de-referenced via indexes to the
	Service Information (i.e. the Program Map Table, PMT) when the		Service Information (i.e. the Program Map Table, PMT) when the
	MPEG-2 Transmission Network includes remultiplexors that renumber		MPEG-2 Transmission Network includes remultiplexors that renumber
	the PID values of the TS Logical Channels that they process. (Note		the PID values of the TS Logical Channels that they process. (Note
	that PIDs are not intended to be end-to-end identifiers). However,		that PIDs are not intended to be end-to-end identifiers). However,
	although remultiplexing is common in broadcast TV networks		although remultiplexing is common in broadcast TV networks
	(scenarios A and B), many private networks do not need to employ		(scenarios A and B), many private networks do not need to employ
	multiplexors that renumber PIDs (see section 3.2).		multiplexors that renumber PIDs (see section 3.2).
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	The third element (iii) allows an AR client to resolve to a		The third element (iii) allows an AR client to resolve to a
	different MPEG TS Multiplex. This is used when there are several		different MPEG TS Multiplex. This is used when there are several
	channels that may be used for communication (i.e. multiple		channels that may be used for communication (i.e. multiple
	outbound/inbound links). In a mesh system, this could be used to		outbound/inbound links). In a mesh system, this could be used to
	determine connectivity. This AR information is used in two ways at a		determine connectivity. This AR information is used in two ways at a
	Receiver:		Receiver:
	(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG		(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG
	TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set		TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set
	skipping to change at page 24, line 6		skipping to change at page 24, line 6
	| Hub |/		| Hub |/
	| +\ /-----\		| +\ /-----\
	\ / \ / \		\ / \ / \
	\-----/ \ | Receiver|		\-----/ \ | Receiver|
	\-----------+ B |		\-----------+ B |
	\ /		\ /
	\-----/		\-----/
	Figure 6: MPEG-2 Transmission Network with 2 Receivers		Figure 6: MPEG-2 Transmission Network with 2 Receivers
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	There are three possibilities for unicast AR:		There are three possibilities for unicast AR:
	(1) A system at a Receiver, A, needs to resolve an address of a		(1) A system at a Receiver, A, needs to resolve an address of a
	system that is at the Hub;		system that is at the Hub;
	(2) A system at a Receiver, A, needs to resolve an address that is		(2) A system at a Receiver, A, needs to resolve an address that is
	at another Receiver, B;		at another Receiver, B;
	(3) A host at the Hub needs to resolve an address that is at a		(3) A host at the Hub needs to resolve an address that is at a
	Receiver. The sender (encapsulation gateway), uses AR to provide the		Receiver. The sender (encapsulation gateway), uses AR to provide the
	the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast,		the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast,
	skipping to change at page 25, line 6		skipping to change at page 25, line 6
	There are three distinct cases in which AR may be used:		There are three distinct cases in which AR may be used:
	(i) Multiple TS-Mux and the use of re-multiplexors; e.g. Digital		(i) Multiple TS-Mux and the use of re-multiplexors; e.g. Digital
	Terrestrial, Satellite TV broadcast multiplexes. Many such systems		Terrestrial, Satellite TV broadcast multiplexes. Many such systems
	employ remultiplexors that modify the PID values associated with TS		employ remultiplexors that modify the PID values associated with TS
	Logical Channels as they pass through the MPEG-2 transmission		Logical Channels as they pass through the MPEG-2 transmission
	network (as in Scenario A of Section 3.1).		network (as in Scenario A of Section 3.1).
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	(ii) Tuner configuration(s) that are fixed or controlled by some		(ii) Tuner configuration(s) that are fixed or controlled by some
	other process. In these systems, the PID value associated with a TS		other process. In these systems, the PID value associated with a TS
	Logical Channel may be known by the Sender.		Logical Channel may be known by the Sender.
	(iii) A service run over one TS Mux (i.e., uses only one PID, for		(iii) A service run over one TS Mux (i.e., uses only one PID, for
	example DOCSIS and some current DVB-RCS multicast systems). In these		example DOCSIS and some current DVB-RCS multicast systems). In these
	systems, the PID value of a TS Logical Channel may be known by the		systems, the PID value of a TS Logical Channel may be known by the
	Sender.		Sender.
	5.2.1 Table-based AR over MPEG-2		5.2.1 Table-based AR over MPEG-2
	skipping to change at page 26, line 6		skipping to change at page 26, line 6
	A query/response protocol may be used at the IP level (similar to,		A query/response protocol may be used at the IP level (similar to,
	or based on IPv6 Neighbor Advertisements of the ND protocol). The AR		or based on IPv6 Neighbor Advertisements of the ND protocol). The AR
	protocol may operate over an MPEG-2 TS Logical Channel using a		protocol may operate over an MPEG-2 TS Logical Channel using a
	previously agreed PID (e.g. configured, or communicated using a SI		previously agreed PID (e.g. configured, or communicated using a SI
	table). In this case, the AR could be performed by the target system		table). In this case, the AR could be performed by the target system
	itself (as in ARP and ND). This has good soft-state properties, and		itself (as in ARP and ND). This has good soft-state properties, and
	is very tolerant to failures. To find an address, a system sends a		is very tolerant to failures. To find an address, a system sends a
	"query" to the network, and the "target" (or its proxy) replies.		"query" to the network, and the "target" (or its proxy) replies.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	5.3 Unicast Address Scoping		5.3 Unicast Address Scoping
	In some case, an MPEG-2 Transmission Network may support multiple IP		In some case, an MPEG-2 Transmission Network may support multiple IP
	networks. If this is the case, it is important to recognise the		networks. If this is the case, it is important to recognise the
	context (scope) within which an address is resolved, to prevent		context (scope) within which an address is resolved, to prevent
	packets from one addressed scope leaking into other scopes.		packets from one addressed scope leaking into other scopes.
	An examples of overlapping IP address assignments is the use of		An examples of overlapping IP address assignments is the use of
	private unicast addresses (e.g. in IPv4, 10/8 prefix;		private unicast addresses (e.g. in IPv4, 10/8 prefix;
	skipping to change at page 27, line 6		skipping to change at page 27, line 6
	the additional network traffic may contribute to processing load but		the additional network traffic may contribute to processing load but
	should not lead to unexpected protocol behaviour. It does however		should not lead to unexpected protocol behaviour. It does however
	introduce a potential Denial of Service (DoS) opportunity.		introduce a potential Denial of Service (DoS) opportunity.
	When the Receiver acts as an IP router, the receipt of such an IP		When the Receiver acts as an IP router, the receipt of such an IP
	packet may lead to unexpected protocol behaviour. This also provides		packet may lead to unexpected protocol behaviour. This also provides
	a security vulnerability since arbitrary packets may be passed to		a security vulnerability since arbitrary packets may be passed to
	the IP layer.		the IP layer.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	5.4 AR Authentication		5.4 AR Authentication
	In many AR designs authentication has been overlooked, because of		In many AR designs authentication has been overlooked, because of
	the wired nature of most existing IP networks, which makes it easy		the wired nature of most existing IP networks, which makes it easy
	to control hosts physically connected [RFC3819]. With wireless		to control hosts physically connected [RFC3819]. With wireless
	connections, this is changing: unauthorised hosts actually can		connections, this is changing: unauthorised hosts actually can
	claim L2 resources. The address resolution client (i.e. Receiver)		claim L2 resources. The address resolution client (i.e. Receiver)
	may also need to verify the integrity and authenticity of the		may also need to verify the integrity and authenticity of the
	AR information that it receives. There are trust relationships		AR information that it receives. There are trust relationships
	skipping to change at page 28, line 6		skipping to change at page 28, line 6
	(unsolicited registration).		(unsolicited registration).
	(iii) Mechanisms to verify AR information held at the server		(iii) Mechanisms to verify AR information held at the server
	(solicited responses). Appropriate timer values need to be		(solicited responses). Appropriate timer values need to be
	defined.		defined.
	(iv) An ability to purge client AR information (after IP network		(iv) An ability to purge client AR information (after IP network
	renumbering, etc.).		renumbering, etc.).
	(v) Support of IP subnetwork scoping.		(v) Support of IP subnetwork scoping.
	(vi) Appropriate security associations to authenticate the sender.		(vi) Appropriate security associations to authenticate the sender.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	6. Multicast Support		6. Multicast Support
	This section addresses specific issues concerning IPv4 and IPv6		This section addresses specific issues concerning IPv4 and IPv6
	multicast [RFC1112] over MPEG-2 Transmission Networks. The primary		multicast [RFC1112] over MPEG-2 Transmission Networks. The primary
	goal of multicast support will be efficient filtering of IP		goal of multicast support will be efficient filtering of IP
	multicast packets by the Receiver, and the mapping of IPv4 and		multicast packets by the Receiver, and the mapping of IPv4 and
	IPv6 multicast addresses [RFC3171] to the associated PID value		IPv6 multicast addresses [RFC3171] to the associated PID value
	and TS Multiplex.		and TS Multiplex.
	skipping to change at page 29, line 6		skipping to change at page 29, line 6
	host/router may be unaware of this duplication.		host/router may be unaware of this duplication.
	6.1 Multicast AR Functions		6.1 Multicast AR Functions
	The functions required for multicast AR may be summarised as:		The functions required for multicast AR may be summarised as:
	(i) The Sender needs to know L2 mapping of a multicast group.		(i) The Sender needs to know L2 mapping of a multicast group.
	(ii) The Receiver needs to know L2 mapping of a multicast group.		(ii) The Receiver needs to know L2 mapping of a multicast group.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	In the Internet, multicast AR is normally a mapping function rather		In the Internet, multicast AR is normally a mapping function rather
	than a one-to-one association using a protocol. In Ethernet, the		than a one-to-one association using a protocol. In Ethernet, the
	sender maps an IP address to a L2 MAC address, and the Receiver uses		sender maps an IP address to a L2 MAC address, and the Receiver uses
	the same mapping to determine the L2 address to set a L2		the same mapping to determine the L2 address to set a L2
	hardware/software filter entry.		hardware/software filter entry.
	A typical sequence of actions for the dynamic case is:		A typical sequence of actions for the dynamic case is:
	L3) Populate the IP L3 membership tables at the Receiver.		L3) Populate the IP L3 membership tables at the Receiver.
	skipping to change at page 30, line 6		skipping to change at page 30, line 6
	+---+----+ +---------+ +------------+		+---+----+ +---------+ +------------+
	| | |		| | |
	+---+----+ +---+-----+ +---+----+		+---+----+ +---+-----+ +---+----+
	| IP | | AR | |IGMP/MLD|		| IP | | AR | |IGMP/MLD|
	+---+----+ +---+-----+ +---+----+		+---+----+ +---+-----+ +---+----+
	| | |		| | |
	*------------+------------+		*------------+------------+
	Figure 7: Receiver Processing Architecture		Figure 7: Receiver Processing Architecture
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	6.2 Multicast Address Scoping		6.2 Multicast Address Scoping
	As in unicast, it is important to recognise the context (scope)		As in unicast, it is important to recognise the context (scope)
	within which a multicast IP address is resolved, to prevent		within which a multicast IP address is resolved, to prevent
	packets from one addressed scope leaking into other scopes.		packets from one addressed scope leaking into other scopes.
	Examples of overlapping IP multicast address assignments, include:		Examples of overlapping IP multicast address assignments, include:
	(i) Some multicast addresses, (e.g., scoped multicast addresses		(i) Some multicast addresses, (e.g., scoped multicast addresses
	skipping to change at page 31, line 6		skipping to change at page 31, line 6
	networks built upon the MPEG-2 Transport Stream (TS). It also		networks built upon the MPEG-2 Transport Stream (TS). It also
	describes existing approaches. The focus is on IP networking, the		describes existing approaches. The focus is on IP networking, the
	mechanisms that are used and their applicability to supporting IP		mechanisms that are used and their applicability to supporting IP
	unicast and multicast services.		unicast and multicast services.
	The requirements for a new encapsulation of IPv4 and IPv6 packets is		The requirements for a new encapsulation of IPv4 and IPv6 packets is
	described, outlining the limitations of current methods and the need		described, outlining the limitations of current methods and the need
	for a streamlined IP-centric approach.		for a streamlined IP-centric approach.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	The architecture also describes MPEG-2 Address Resolution (AR)		The architecture also describes MPEG-2 Address Resolution (AR)
	procedures to allow dynamic configuration of the sender and Receiver		procedures to allow dynamic configuration of the sender and Receiver
	using an MPEG-2 transmission link/network. These support IPv4 and		using an MPEG-2 transmission link/network. These support IPv4 and
	IPv6 services in both the unicast and multicast modes. Resolution		IPv6 services in both the unicast and multicast modes. Resolution
	protocols will support IP packet transmission using both the		protocols will support IP packet transmission using both the
	Multiprotocol Encapsulation (MPE), which is currently		Multiprotocol Encapsulation (MPE), which is currently
	widely deployed, and also any IETF defined ULE encapsulation		widely deployed, and also any IETF defined ULE encapsulation
	[ID-IPDVB-ULE].		[ID-IPDVB-ULE].
	skipping to change at page 32, line 6		skipping to change at page 32, line 6
	cannot enforce the use of end-to-end mechanisms.		cannot enforce the use of end-to-end mechanisms.
	A related role for subnetwork security is to protect users against		A related role for subnetwork security is to protect users against
	traffic analysis, i.e., identifying the communicating parties (by IP		traffic analysis, i.e., identifying the communicating parties (by IP
	or MAC address) and determining their communication patterns, even		or MAC address) and determining their communication patterns, even
	when their actual contents are protected by strong end-to-end		when their actual contents are protected by strong end-to-end
	security mechanisms (this is important for networks such as		security mechanisms (this is important for networks such as
	broadcast/radio, where eaves-dropping is easy).		broadcast/radio, where eaves-dropping is easy).
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	Where it is possible for an attacker to inject traffic into the		Where it is possible for an attacker to inject traffic into the
	subnetwork control plane, subnetwork security can additionally		subnetwork control plane, subnetwork security can additionally
	protect the subnetwork assets. This threat must specifically be		protect the subnetwork assets. This threat must specifically be
	considered for the protocols used for subnetwork control functions		considered for the protocols used for subnetwork control functions
	(e.g. address resolution, management, configuration). Possible		(e.g. address resolution, management, configuration). Possible
	threats include theft of service and denial of service; shared media		threats include theft of service and denial of service; shared media
	subnets tend to be especially vulnerable to such attacks [RFC3819].		subnets tend to be especially vulnerable to such attacks [RFC3819].
	Appropriate security functions must therefore be provided for ipdvb		Appropriate security functions must therefore be provided for ipdvb
	skipping to change at page 33, line 6		skipping to change at page 33, line 6
	MPE supports optional link encryption using a pair of bits within		MPE supports optional link encryption using a pair of bits within
	the MPE protocol header to indicate the use of encryption. To		the MPE protocol header to indicate the use of encryption. To
	support optional link level encryption, it is recommended that a new		support optional link level encryption, it is recommended that a new
	encapsulation also supports optional encryption of the SNDU payload.		encapsulation also supports optional encryption of the SNDU payload.
	Furthermore, it may be desirable to encrypt/authenticate some/all of		Furthermore, it may be desirable to encrypt/authenticate some/all of
	the SNDU headers. However, the specification must provide		the SNDU headers. However, the specification must provide
	appropriate code points to allow such encryption to be implemented		appropriate code points to allow such encryption to be implemented
	at the link layer.		at the link layer.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	9. Acknowledgments		9. Acknowledgments
	The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre		The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre
	Loyer, Luoma Juha-Pekka and and Rod Walsh for their detailed inputs.		Loyer, Luoma Juha-Pekka and and Rod Walsh for their detailed inputs.
	We also wish to acknowledge the input provided by the members of		We also wish to acknowledge the input provided by the members of
	the IETF ipdvb WG.		the IETF ipdvb WG.
	10. References		10. References
	skipping to change at page 34, line 6		skipping to change at page 34, line 6
	Committee (ATSC), Doc. A/65B, 2003.		Committee (ATSC), Doc. A/65B, 2003.
	[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV		[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
	(DTV) Applications over Satellite", Advanced Television Systems		(DTV) Applications over Satellite", Advanced Television Systems
	Committee (ATSC), Doc. A/80, 1999.		Committee (ATSC), Doc. A/80, 1999.
	[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet		[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
	over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.		over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",		[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
	European Telecommunications Standards Institute (ETSI).		European Telecommunications Standards Institute (ETSI).
	[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB		[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
	interaction channel for Cable TV distribution systems (CATV)",		interaction channel for Cable TV distribution systems (CATV)",
	European Telecommunications Standards Institute (ETSI).		European Telecommunications Standards Institute (ETSI).
	[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);		[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);
	Interaction channel for satellite distribution systems", European		Interaction channel for satellite distribution systems", European
	skipping to change at page 35, line 6		skipping to change at page 35, line 6
	[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.		[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
	Schulzrinne, "Protocol Requirements for Internet Media Guides",		Schulzrinne, "Protocol Requirements for Internet Media Guides",
	Internet Draft, draft-ietf-mmusic-img-req.txt, Work in Progress,		Internet Draft, draft-ietf-mmusic-img-req.txt, Work in Progress,
	MMUSIC WG.		MMUSIC WG.
	[ISO-AUD] ISO/IEC 13818-3:1995 "Information technology; Generic		[ISO-AUD] ISO/IEC 13818-3:1995 "Information technology; Generic
	coding of moving pictures and associated audio information; Part		coding of moving pictures and associated audio information; Part
	3: Audio", International Standards Organisation (ISO).		3: Audio", International Standards Organisation (ISO).
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology; Generic		[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology; Generic
	coding of moving pictures and associated audio information; Part		coding of moving pictures and associated audio information; Part
	6: Extensions for DSM-CC", International Standards Organisation		6: Extensions for DSM-CC", International Standards Organisation
	(ISO).		(ISO).
	[ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology;		[ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology;
	Generic coding of moving pictures and associated audio information;		Generic coding of moving pictures and associated audio information;
	Video", International Standards Organisation (ISO).		Video", International Standards Organisation (ISO).
	skipping to change at page 36, line 6		skipping to change at page 36, line 6
	Unidirectional Links", RFC 3077, March 2001.		Unidirectional Links", RFC 3077, March 2001.
	[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,		[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
	H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,		H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
	Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,		Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
	Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):		Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
	Framework and four profiles: RTP, UDP, ESP, and uncompressed",		Framework and four profiles: RTP, UDP, ESP, and uncompressed",
	RFC 3095, July 2001.		RFC 3095, July 2001.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,		[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
	"IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51,		"IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51,
	RFC 3171, August 2001.		RFC 3171, August 2001.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B.,		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B.,
	and A. Thyagarajan, "Internet Group Management Protocol,		and A. Thyagarajan, "Internet Group Management Protocol,
	Version 3", RFC 3376, October 2002.		Version 3", RFC 3376, October 2002.
	RFC3569] Bhattacharyya, S., "An Overview of Source-Specific		RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
	skipping to change at page 37, line 6		skipping to change at page 37, line 6
	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.network-research.org		Web: http://www.network-research.org
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	Hilmar Linder		Hilmar Linder
	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: hlinder@cosy.sbg.ac.at		Email: hlinder@cosy.sbg.ac.at
	Web: http://www.network-research.org		Web: http://www.network-research.org
	skipping to change at page 38, line 6		skipping to change at page 38, line 6
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	13. Copyright Statement		13. 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.
	14. IANA Considerations		14. IANA Considerations
	skipping to change at page 39, line 6		skipping to change at page 39, line 6
	of the broadcast descriptor table [SI-DAT] sent separately		of the broadcast descriptor table [SI-DAT] sent separately
	over another MPEG-2 TS within the TS multiplex.		over another MPEG-2 TS within the TS multiplex.
	MPE is currently a widely deployed scheme. Due to		MPE is currently a widely deployed scheme. Due to
	Investments in existing systems, usage is likely to continue		Investments in existing systems, usage is likely to continue
	in current and future MPEG-2 Transmission Networks. ATSC		in current and future MPEG-2 Transmission Networks. ATSC
	provides a scheme similar to MPE [ATSC-DAT] with some small		provides a scheme similar to MPE [ATSC-DAT] with some small
	differences.		differences.
	INTERNET DRAFT Architecture for IP transport over MPEG-2 networks		INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
	January 2005		December 2004
	(ii) Data Piping.		(ii) Data Piping.
	The Data Piping profile [ETSI-DAT] is a minimum overhead,		The Data Piping profile [ETSI-DAT] is a minimum overhead,
	simple and flexible profile that makes no assumptions		simple and flexible profile that makes no assumptions
	concerning the format of the data being sent. In this		concerning the format of the data being sent. In this
	profile, the Receiver is intended to provide PID filtering,		profile, the Receiver is intended to provide PID filtering,
	packet reassembly according to [DVB-SIDAT-368], error		packet reassembly according to [DVB-SIDAT-368], error
	detection and optional Conditional Access (link encryption).		detection and optional Conditional Access (link encryption).
End of changes.
This html diff was produced by rfcdiff 1.22, available from http://www.levkowetz.com/ietf/tools/rfcdiff/