draft-fair-ipdvb-ar-03.txt		draft-fair-ipdvb-ar-02.txt
	Internet Engineering Task Force Gorry Fairhurst		Ôªø Internet Engineering Task Force Gorry Fairhurst
	Internet Draft University of Aberdeen		Internet Draft University of Aberdeen, U.K.
	Document: draft-fair-ipdvb-ar-03.txt Marie-Jose Montpetit		Document: draft-fair-ipdvb-ar-02.txt Marie-Jose Montpetit
	June 2005 Motorola		October 2004 MJMontpetit.com, USA
	Hidetaka Izumiyama		Hidetaka Izumiyama
	Wishnet		Wishnet, Japan
	Category: Informational Expires June 2005		Category: Informational Expires March 2005
	Address Resolution for IP datagrams over MPEG-2 networks		Address Resolution for IP datagrams over MPEG-2 networks
	Status of this Memo		Status of this Memo
	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-Drafts.		other groups may also distribute working documents as Internet
			Drafts. Internet-Drafts are draft documents valid for a maximum of
	Internet-Drafts are draft documents valid for a maximum of six		six months and may be updated, replaced, or obsoleted by other
	months and may be updated, replaced, or obsoleted by other documents		documents at any time. It is inappropriate to use Internet-Drafts
	at any time. It is inappropriate to use Internet-Drafts as reference		as reference material or to cite them other than as "work in
	material or to cite them other than as "work in progress".		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/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
	Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	networks February 2005		Copyright (C) The Internet Society (2004), All Rights Reserved
	Abstract		Abstract
	This document describes the current mechanisms to bind IPv4/IPv6		This document describes the current mechanisms to bind IPv4/IPv6
	addresses and flows to MPEG-2 Transport Streams (TS)and how these		addresses and flows to MPEG-2 Transport Streams (TS). For MPEG-2
	methods interact with well known protocols for address management		systems to become true subnetworks of the general Internet,
	like DHCP, ARP, NAT and DNS. For MPEG-2 subnetworks like any		methods are required to signal IPv4/v6 addresses to the link
	other IP networks methods are required to signal IPv4/v6		receivers and transmitters; this is known as Address Resolution
	addresses to the link receivers and transmitters; this is known		(AR), or Neighbour Discovery (ND). Although AR is often associated
	as Address Resolution (AR), or Neighbour Discovery (ND). Although		with Ethernet [RFC803], it is essential to the operation of any
	AR is often associated with Ethernet [RFC803], it is essential		L2 network. In MPEG-2 networks, address resolution is a three level
	to the operation of any L2 network. In MPEG-2 networks, an IP		process: the IP address is resolved to a NPA/MAC address, then
	address must be associated with a Packet ID (PID) and specific		associated with a Packet ID (PID) and finally to a specific
	transmission multiplex either statically or via the use of some		transmission multiplex. Address resolution complements the higher
	specific tables. Address resolution complements the higher		layer resource discovery tools that are used to advertise IP
	layer resource discovery tools that are used to advertise		sessions. In this document the different mechanisms used for
	IP sessions. In this document the different mechanisms for		address resolution for MPEG-2 are reviewed and their compliance
	address resolution for MPEG-2 networking as well as their usage		to AR requirements established.
	are reviewed.
			networks October 2004
	Table of Contents		Table of Contents
			Document History
	1. Introduction		1. Introduction
	2. Convention used in the document		2. Convention used in the document
	3. Address Resolution Requirement		3. Address Resolution Requirement
	4. MPEG-2 Address Resolution		4. MPEG-2 Address Resolution Operation
	5. Mapping IP addresses to NPA/MAC addresses		5. Mapping of IP addresses to NPA/MAC addresses
	6. Conclusions and Recommendations		6. Conclusions and Recommendations
	7. Security Considerations		7. Security Considerations
	8. Acknowledgements		8. Acknowledgements
	9. References		9. References
	10. Author's Addresses		10. Author's Addresses
	11. IPR Notices		11. IPR Notices
	12. Copyright Statements		12. Copyright Statements
	13. IANA Considerations		13. IANA Considerations
			networks October 2004
			[RFC EDITOR NOTE: this section must be deleted prior to publication]
	Document History		Document History
	-00 This draft is intended as a study item for proposed future		-00 This draft is intended as a study item for proposed future
	work by the IETF in this area.		work by the IETF in this area.
	-01 Review of initial content, major edit and refinement of		-01 Review of initial content, major edit and refinement of
	concepts		concepts.
	-02 fairly important review; took out all new protocol reference;		-02 fairly important review; took out all new protocol references
	added one author; added contribution on real implementation		and moved to a configuration draft; added one author Hidetaka
	-02 Added content to respond to 61st IETF comments;		Izumiyama who has contributions on UDLR experiments;
	refined ID goals; rewrote section 4.2 and 4.3; added cable		added a section on AR in UDLR; reworked the bibliography.
	information.
	networks February 2005		[END OF RFC EDITOR NOTE]
	1. Introduction		1. Introduction
	The MPEG-2 stream is defined in the specification ISO/IEC 138181.		The MPEG-2 stream is defined in the specification ISO/IEC 138181.
	It provides a time-division multiplexed (TDM) stream that may		It provides a time-division multiplexed (TDM) stream that may
	contain audio, video and data information. Each frame, known as		contain audio, video and other information. Each frame, known as
	an MPEG-2 TS Packet, contains 4 bytes of header and 188 bytes of		an MPEG-2 TS Packet, contains 4 bytes of header and 188 bytes of
	data. The standard also defines the Transport Stream (TS)		data. The standard also defines the PES packet (Packetized
	packet. Each MPEG-2 TS Packet is associated with one Transport		Elementary Stream) and the Section or Transport Stream (TS)
	Stream (TS) and is identified by a 13 bit Packet ID PID) carried		packet. The PES packet can carry video, audio, private data and
	in the MPEG-2 TS Packet header.		was originally used for some data streaming applications; this
			usage is now historical. Each MPEG-2 TS Packet is associated with
			one Transport Stream (TS) logical channel, which is identified by
			a 13 bit Packet ID (PID) carried in the MPEG-2 TS Packet header.
	The standard also defines a MPEG-2 control plane that may be used		The standard also defines a MPEG-2 control plane that may be used
	to transmit control information. For example, specific		to transmit control information. For example, using System
	transmission information is sent to the senders/receivers using		Information (SI) Tables (ETSI-SI, ETSI-SI1], or Program Specific
	System Information (SI) Tables (ETSI-SI, ETSI-SI1], or Program		Information (PSI) Tables. The Tables can be used to carry PID
	Specific Information (PSI)Tables. The standard also allows		information about the transported stream. MPEG-2 address
	Defining tables that can be used to carry IP and PID information		resolution assigns IP addresses to particular transmission
	about the transported stream. MPEG-2 address resolution assigns		multiplexes, and within a multiplex to a specific PID.
	IP addresses to particular transmission multiplexes, and within		The protocol signals this mapping to the other communicating
	a multiplex to a specific PID. The protocol signals this mapping		devices (Gateways and Receivers). In some address resolution
	to the other communicating devices. In some address resolution
	schemes, this address space is sub-divided into logical contexts		schemes, this address space is sub-divided into logical contexts
	known as Platforms or Sections. One use of this sub-division is		known as Platforms or Sections. One use of this sub-division is
	to associate a separate context with each IP service provider that		to associate a separate context with each IP service provider that
	shares a common MPEG-2 TS (uses the same PID).		shares a common MPEG-2 TS (uses the same PID).
			networks October 2004
	MPEG-2 Receivers may optionally be assigned a Network Point of		MPEG-2 Receivers may optionally be assigned a Network Point of
	Attachment (NPA) to uniquely identify the L2 node within the		Attachment (NPA) to uniquely identify the L2 node within the
	MPEG-2 transmission network. An example of an NPA is the IEEE		MPEG-2 transmission network. An example of an NPA is the IEEE
	Medium Access Control(MAC) address. Where such addresses are		Medium Access Control(MAC) address. Where such addresses are
	used, these must also be signalled by the address resolution		used, these must also be signalled by the address resolution
	procedure. Finally, address resolution may need to signal the		procedure. Finally, address resolution may need to signal the
	format of the data being transmitted. For example, the		format of the data being transmitted. For example, the
	encapsulation used or any compression scheme that was used at		encapsulation used or any compression scheme that was used at
	the sender [ID-IPDVB-ARCH].		the sender [ID-IPDVB-ARCH].
			This document describes current mechanisms to signal the TS
	This document describes current mechanisms and their usage to		Multiplex, the PID, and (if used) the MAC address or platform ID
	signal the TS Multiplex, the PID, and (if used) the MAC address		associated with each IP address or flow to the network layer at the
	or platform ID associated with each IP address or flow to the		sender and receiver. As will be seen below this can, for example, be
	network layer at the sender and receiver. As will be seen below		implemented via descriptors sent in MPEG-2 SI tables (using the
	this can, for example, be implemented via descriptors sent in		MPEG-2 control plane), via one or more new SI tables, or in-band
	MPEG-2 SI tables via one or more new SI tables, or in-band
	by a protocol using a data channel similarly to the IPv4 Address		by a protocol using a data channel similarly to the IPv4 Address
	Resolution Protocol, ARP, or IPv6 Neighbour Discovery (ND)		Resolution Protocol, ARP, or IPv6 Neighbour Discovery (ND) protocol.
	protocol.
	networks February 2005
	2. Conventions used in this document		2. Conventions used in this document
	AIT: Application Information Table specified by the Multimedia		AIT: Application Information Table specified by the Multimedia
	Home Platform (MHP) specifications [ETSI-MHP]. This table may		Home Platform (MHP) specifications [ETSI-MHP]. This table may
	carry IPv4/IPv6 to MPEG-2 TS address resolution information.		carry IPv4/IPv6 to MPEG-2 TS address resolution information.
	ATSC: Advanced Television Systems Committee [ATSC]. A set of		ATSC: Advanced Television Systems Committee [ATSC]. A set of
	framework and associated standards for the transmission of video,		framework and 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.
	DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and		DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and
	associated standards for the transmission of video, audio, and		associated standards for the transmission of video, audio, and
	data, using the ISO MPEG-2 standard.		data, using the ISO MPEG-2 standard.
	DVB-RCS: Digital Video Broadcast Return Channel via Satellite.		DVB-RCS: Digital Video Broadcast Return Channel via Satellite.
	A bi-directional IPv4/IPv6 service employing low-cost Receivers.		A bi-directional IPv4/IPv6 service employing low-cost Receivers.
			Feed: A router or host that has send-only connectivity to a UDL.
	INT: Internet/MAC Notification Table. A uni-directional		INT: Internet/MAC Notification Table. A uni-directional
	addressing resolution mechanism using SI and/or PSI Tables.		addressing resolution mechanism using SI and/or PSI Tables.
	MAC: Medium Access and Control of the Ethernet IEEE 802 standard		MAC: Medium Access and Control of the Ethernet IEEE 802 standard
	of protocols (see also NPA).		of protocols (see also NPA).
	MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia		MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia
	receiver, that may (in some cases) support IPv4/IPv6 services.		receiver, that may (in some cases) support IPv4/IPv6 services.
			networks October 2004
	MMT: Multicast Mapping Table (proprietary extension to DVB-RCS).		MMT: Multicast Mapping Table (proprietary extension to DVB-RCS).
	MPE: Multiprotocol Encapsulation [ETSI-DAT, ETSI-DAT1]. A scheme		MPE: Multiprotocol Encapsulation [ETSI-DAT, ETSI-DAT1]. A scheme
	that encapsulates Ethernet frames or IP Packets, creating a		that encapsulates Ethernet frames or IP Packets, creating a
	DSM-CC Section. The Section will be sent in a series of TS Packets		DSM-CC Section. The Section will be sent in a series of TS Packets
	over a TS Logical Channel.		over a TS Logical Channel.
	MPEG-2: A set of standards specified by the Motion Picture Experts		MPEG-2: A set of standards specified by the Motion Picture Experts
	Group (MPEG), and standardized by the International Standards		Group (MPEG), and standardized by the International Standards
	Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).		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).		IEEE MAC address).
	NPA: Network Point of Attachment. In this document, refers to a 6		PES: Packetized Elementary Stream. A format of MPEG-2 TS packet
	byte destination address (resembling an IEEE MAC address) within		payload usually used for video or audio information in MPEG-2
	the MPEG-2 transmission network that is used to identify individual		[ISO-MPEG].
	Receivers or groups of Receivers.
	PID: Packet Identifier[ISO-MPEG2]. A 13 bit field carried in the
	header of TS Packets. This is used to identify the TS Logical
	Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
	forming the parts of a Table Section, PES, or other Payload Unit
	must all carry the same PID value.
	networks February 2005		Receiver (in the UDL context): A router or a host that has receive
			only connectivity to a UDL. A receiver may have connectivity via an
			alternate interface, allowing possible transmission on this second
			interface.
	The all 1s PID value indicates a Null TS Packet introduced		UDL: Unidirectional link: A one-way transmission IP over DVB link,
	to maintain a constant bit rate of a TS Multiplex. There is no		e.g., a broadcast satellite link.
	required relationship between the PID values used for TS Logical
	Channels transmitted using different TS Multiplexes.
	PRIVATE SECTION: A syntactic structure constructed in accordance		PID: Packet Identifier. A 13-bit field carried in the header of
	with Table 2-30 of [ISO-MPEG2]. The structure may be used to		all MPEG-2 Transport Stream packets [ISO-MPEG]. This is used to
	identify private information (i.e. not defined by [ISO-MPEG2])		identify the TS Logical Channel to which it belongs.
	relating to one or more elementary streams, or a specific MPEG-2
	program, or the entire Transport Stream. Other Standards bodies,
	e.g. ETSI, ATSC, have defined sets of table structures using the
	private_section structure. A Private Section is transmitted as a
	sequence of TS Packets using a TS Logical Channel. A TS Logical
	Channel may carry sections from more than one set of tables.
	PSI: Program Specific Information [ISO-MPEG2]. PSI is used to		PRIVATE SECTION: A syntactic structure used for mapping all
	convey information about services carried in a TS Multiplex.		service information (e.g. an SI table) into TS Packets. A table
	It is carried in one of four specifically identified table		may be divided into a number of sections. All sections of a table
	section constructs [ISO-MPEG2], see also SI Table.		must be carried over a single TS Logical Channel.
	RECEIVER (in the UDL context): A router or a host that has receive		PSI: Programme Specific Information: In this document, the term is
	only connectivity to a UDL.		used to describe any table used to convey information about a
			subset of services carried in a TS Multiplex (e.g. [ISO-MPEG]).
			PSI tables are carried in MPEG-2 private sections.
	SI TABLE: Service Information Table. In this document, the term is		SI TABLE: Service Information Table. In this document, the term is
	used to describe any table used to convey information about the		used to describe any table used to convey information about the
	service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are		service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are
	carried in MPEG-2 private sections.		carried in MPEG-2 private sections.
	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		MPEG-2 level using TS Packets; it represents level 2 of the
	ISO/OSI reference model.		ISO/OSI
	See also TS Logical Channel and TS Multiplex.		reference model. See also TS Logical Channel and TS Multiplex.
	TS LOGICAL CHANNEL: Transport Stream Logical Channel. In this
	document, this term identifies a channel at the MPEG-2 level [ISO-
	MPEG2]. It exists at level 2 of the ISO/OSI reference model. All
	packets sent over a TS Logical Channel carry the same PID value
	(this value is unique within a specific TS Multiplex). According to
	MPEG-2, some TS Logical Channels are reserved for specific
	signalling. Other standards (e.g., ATSC, DVB) also reserve specific
	TS Logical Channels.
	TS MULTIPLEX: In this document, this term defines a set of MPEG-2 TS		networks October 2004
	Logical Channels sent over a single lower layer connection. This may
	be a common physical link (i.e. a transmission at a specified symbol
	rate, FEC setting, and transmission frequency) or an encapsulation
	provided by another protocol layer (e.g. Ethernet, or RTP over IP).
	The same TS Logical Channel may be repeated over more than one TS
	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.
	networks February 2005		TS LOGICAL CHANNEL: A channel identified at the MPEG-2 level; it
			represents level 2 of the ISO/OSI reference model. All packets
			sent over a channel carry the same PID value.
	TS PACKET: A fixed-length 188B unit of data sent over a TS		TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a
	Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header,		single common physical bearer (i.e. a link transmitting at a
	plus optional overhead including an Adaptation Field, encryption		specified symbol rate, FEC setting, and transmission frequency).
	details and time stamp information to synchronise a set of
	related TS Logical Channels.
	UDL: Unidirectional link: A one-way transmission IP over DVB link,		TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2
	e.g., a broadcast satellite link.		multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM
			networks, and is frequently also referred to as a TS_cell.
			Each TS Packet carries a 4B header, plus optional overhead. Each
			TS packet carries a PID value to associate it with a single TS
			Logical Channel.
	3. Address Resolution Requirements		3. Address Resolution Requirements
	The general IP over MPEG-2 AR requirements are summarized below;		The IP address resolution support should support both existing IP
	These requirements are generic, enable the usage of network layer		over MPEG-2 encapsulations (e.g., MPE [ETSI-DAT, ETSI-DAT1]), and
	protocols and will be used to evaluate existing approaches:		also any IETF encapsulation that may be defined [ID-IPDVB-ARCH].
	- Use SI tables for non-static allocation to promote AR scaling.		AR requirements are summarized below:
	- Provide mechanisms to install AR information at the server		- Use of a table based approach to promote AR scaling.
	(unsolicited registration).		- Mechanisms to install AR information at the server (unsolicited
	- Provide incremental table updates or purging of stale information.		registration).
	- Support address scoping.		- Incremental table updates or purging of stale information.
	- Provide security associations to authenticate the AR information.		- Support to scoping.
			- Security associations to authenticate the AR information.
	The MPEG IP address resolution is independent of encapsulation		In particular, an MPEG-2 Transmission Network may support multiple
	and supports existing IP over MPEG-2 (e.g., MPE [ETSI-DAT,		IP networks. If this is the case, it is important to recognise
	ETSI-DAT1]) and also any IETF encapsulation that may be defined		the context (scope) within which an address is resolved, to
	[ID-IPDVB-ARCH].		prevent packets from one addressed scope leaking into other
			scopes.
	A MPEG-2 Transmission Network may support multiple IP networks.		Examples of overlapping IP address assignments include:
	If this is the case, it is important to recognise the context
	(scope) within which an address is resolved, to prevent packets
	from one addressed scope leaking into other scopes. Examples of
	overlapping IP address assignments include:
	(i) Private unicast addresses (e.g. in IPv4, 10/8 prefix;		(i) Private unicast addresses (e.g. in IPv4, 10/8 prefix;
	172.16/12 prefix; 192.168/16 prefix) should be confined to		172.16/12 prefix; 192.168/16 prefix) should be confined to
	one addressed area.		one addressed area.
	(ii) Some multicast addresses, (e.g., the scoped multicast		(ii) Some multicast addresses, (e.g., the scoped multicast
	addresses sometimes used in private networks). These are		addresses sometimes used in private networks). These are
	only valid within an addressed area (examples for IPv4		only valid within an addressed area (examples for IPv4
	include; 239/8; 224.0.0/24; 224.0.1/24). Similar cases		include; 239/8; 224.0.0/24; 224.0.1/24). Similar cases
	exist for some IPv6 multicast addresses.		exist for some IPv6 multicast addresses.
	(iii) Scoped multicast addresses. Forwarding of these addresses		(iii) Scoped multicast addresses. Forwarding of these addresses
	is controlled by the scope associated with the address.		is controlled by the scope associated with the address.
	IP packets with these addresses must not be allowed to travel		IP packets with these addresses must not be allowed to travel
	outside their intended scope, and may cause unexpected behaviour		outside their intended scope, and may cause unexpected behaviour
	if allowed to do so.		if allowed to do so.
	networks February 2005		networks October 2004
	In addition, overlapping address assignments can arise when using		In addition, overlapping address assignments can arise when using
	Level 2 Network Point of Attachment (NPA) addresses [ID-IPDVB-		Level 2 Network Point of Attachment (NPA) addresses [ID-IPDVB-
	ARCH]:		ARCH]:
	(i) The NPA address must be unique within the addressed area.		(i) The NPA address must be unique within the addressed area.
	IEEE MAC addresses used in Ethernet LANs are globally		IEEE MAC addresses used in Ethernet LANs are globally
	unique. If the NPA addresses are not globally unique,		unique. If the NPA addresses are not globally unique,
	the same NPA address may be re-used by receivers in		the same NPA address may be re-used by receivers in
	different addressed areas.		different addressed areas.
	(ii) The NPA broadcast address (all 1 MAC address). Traffic		(ii) The NPA broadcast address (all 1 MAC address). Traffic
	skipping to change at page 7, line 41		skipping to change at page 7, line 41
	(DoS) opportunity.		(DoS) opportunity.
	When the Receiver acts as an IP router, the receipt of such packet		When the Receiver acts as an IP router, the receipt of such packet
	may lead to unexpected protocol behaviour. This also provides a		may lead to unexpected protocol behaviour. This also provides a
	security vulnerability since arbitrary packets may be passed to		security vulnerability since arbitrary packets may be passed to
	the IP layer.		the IP layer.
	3.2 Multicast Support		3.2 Multicast Support
	There are specific issues concerning IPv4 and IPv6 multicast over		There are specific issues concerning IPv4 and IPv6 multicast over
	MPEG-2 Transmission Networks:		MPEG-2 Transmission Networks.
	(i) Mapping IP multicast groups to the underlying MPEG-2 TS		(i) Mapping IP multicast groups to the underlying MPEG-2 TS
	Logical Channel (PID) and the MPEG-2 TS Multiplex.		Logical Channel (PID) and the MPEG-2 TS Multiplex.
	(ii) Provide signalling information to allow a receiver to		(ii) Provide signalling information to allow a receiver to
	locate an IP multicast flow within an MPEG-2 TS Multiplex.		locate an IP multicast flow within an MPEG-2 TS Multiplex.
	(iii) Determining group membership (e.g. utilising IGMP/MLD).		(iii) Determining group membership (e.g. utilising IGMP/MLD).
	Appropriate procedures need to be specified to identify the		Appropriate procedures need to be specified to identify the
	correct action when the same multicast group is available on		correct action when the same multicast group is available on
	separate TS Logical Channels. This could arise when different end		separate TS Logical Channels. This could arise when different end
	hosts act as senders to contribute IP packets with the same IP		hosts act as senders to contribute IP packets with the same IP
	group destination address.		group destination address.
			networks October 2004
	Another different case arises when a receiver may potentially		Another different case arises when a receiver may potentially
	receive more than one copy of the same packet. In some cases,		receive more than one copy of the same packet. In some cases,
	these may be sent in different TS Logical Channels, or even		these may be sent in different TS Logical Channels, or even
	different TS Multiplexes. In this case, at the IP level, the		different TS Multiplexes. In this case, at the IP level, the
	host/router may be unaware of this duplication.		host/router may be unaware of this duplication.
	networks February 2005
	The primary goal of multicast support will be efficient filtering		The primary goal of multicast support will be efficient filtering
	of IP-multicast packets by the receiver, and the mapping of IPv4		of IP-multicast packets by the receiver, and the mapping of IPv4
	and IPv6 multicast addresses onto the associated PID value and TS		and IPv6 multicast addresses onto the associated PID value and TS
	Multiplex. The design should permit a large number of active		Multiplex. The design should permit a large number of active
	multicast groups, and should minimise the processing load at the		multicast groups, and should minimise the processing load at the
	receiver when filtering and forwarding IP multicast packets. For		receiver when filtering and forwarding IP multicast packets. For
	example, schemes that may be easily implemented in hardware would		example, schemes that may be easily implemented in hardware would
	be beneficial, since these may relieve the drivers and operating		be beneficial, since these may relieve the drivers and operating
	systems from discarding unwanted multicast traffic.		systems from discarding unwanted multicast traffic.
	4. MPEG-2 Address Resolution		4. MPEG-2 Address Resolution Operations
	In this section, current MPEG-2 address resolution mechanisms are		In this section, current MPEG-2 address resolution mechanisms are
	reviewed.		reviewed. In MPEG-2, the information about the set of MPEG-2 TS
			Logical Channels carried over a TS Multiplex is usually
			distributed via tables (service information, SI) sent using
			channels assigned a specific (well-known) set of PIDs. This system
			was originally designed for audio/video distribution. The design
			requires access to and processing of the SI table information
			[ETSI-SI, ETSI-SI1]. This scheme is complex, and reflects the
			complexity of delivering and co-ordinating the various TS Logical
			Channels associated with a multimedia TV programme. Because of its
			historical usage, there is no direct support for IP mechanisms for
			identification of the TS multiplex and PID in use for a particular
			IP address. It is also important to highlight that a PID value is
			associated with a unidirectional channel, also a result of its
			initial usage.
	4.1 Static configuration.		4.1 Static configuration.
	The static mapping option (IP addresses or flows statically mapped		The static mapping option (IP addresses or flows statically mapped
	to PIDs) is the equivalent to signalling "out-of-band". The		to PIDs) is the equivalent to signalling "out-of-band". The
	application programmer, installing engineer, or user receives the		application programmer, installing engineer, or user receives the
	mapping via some outside means (not in the MPEG-2 TS). This is		mapping via some outside means (not in the MPEG-2 TS). This is
	useful for testing, experimental networks, small subnetworks and		useful for testing, experimental networks, small subnetworks and
	closed domains.		closed domains.
	A single "well-known" PID is a specialisation of this. This is the		A single "well-known" PID is a specialisation of this, but
	scheme used by the well known DOCSIS protocol in cable modems.		requires all IP traffic to be placed into the specified TS logical
	This results in all IP traffic to be placed into the specified TS		channel. Section filtering may be used to differentiate
	stream. Section or MAC filtering may be used to differentiate		subnetworks at the expense of added complexity and potential
	subnetworks.		performance penalties.
	4.2 Table-Based Address Resolution
	The information about the set of MPEG-2 TS streams carried		networks October 2004
	over a TS Multiplex can be distributed via tables that are
	assigned a specific and well-known set of PIDs. This design
	requires access to and processing of the SI table
	information [ETSI-SI, ETSI-SI1]. This scheme reflects
	the complexity of delivering and co-ordinating the various TS
	stream associated with multimedia TV. Because of its historical
	usage, there is no direct support for IP mechanisms for
	identification of the TS multiplex and PID in use for a particular
	IP address. It is also important to highlight that a PID value is
	unidirectional and does not define a virtual channel in the
	ATM sense.
	networks February 2005		4.2 Table-Based Address Resolution
	A TS multiplex may provide PID information for IP services by		MPEG-2 associates multimedia MPEG information with PIDs, using
	integrating additional information into the existing MPEG-2 tables,		MPEG-2 Tables. A TS multiplex may provide PID information for IP
	or to define additional tables specific to the IP service. This		services by integrating additional information into the existing
	has a dual advantage:		MPEG-2 tables, or to define additional tables specific to the IP
			service. This has a dual advantage:
	(i) IP specific information can be obtained directly.		(i) IP specific information can be obtained directly.
	(ii) The mechanism uses an already standardised mechanism.		(ii) The mechanism uses an already standardised mechanism.
	Examples of current implementations of systems for allowing		A large number of methods exist within the standards and current
	a MPEG-2 receiver to identify the appropriate PID and multiplex		implementations of systems for allowing a MPEG-2 receiver to
	used to transmit traffic to a specific IP address include:		identify the appropriate PID and multiplex using to transmit
			traffic to a specific IP address.
			Examples include:
	(i) IP/MAC Notification Table (INT) in the DVB Data standard		(i) IP/MAC Notification Table (INT) in the DVB Data standard
	[ETS_DAT]. This provides uni-directional address		[ETS_DAT]. This provides uni-directional address
	resolution of IPv4/IPv6 multicast addresses to MPEG-2		resolution of IPv4/IPv6 multicast addresses to MPEG-2
	TS.		TS.
	(ii) Application Information Table (AIT) in the Multimedia		(ii) Application Information Table (AIT) in the Multimedia
	Home Platform (MHP) specifications [ETSI-MHP].		Home Platform (MHP) specifications [ETSI-MHP].
	(iii) Multicast Mapping Table (MMT) an MPEG-2 Table employed		(iii) Multicast Mapping Table (MMT) an MPEG-2 Table employed
	by some DVB-RCS systems to provide uni-directional		by some DVB-RCS systems to provide uni-directional
	address resolution of IPv4 multicast addresses to MPEG-2		address resolution of IPv4 multicast addresses to MPEG-2
	TS.		TS.
	The MMT and AIT are used for specific applications. The INT is		The MMT and AIT are used for specific applications. The INT is
	DVB standardised and more general purpose. It supports both IPv4		DVB standardised and more general purpose. It supports both IPv4
	and IPv6 and can be used in combination with the other tables. It		and IPv6 and can be used in combination with the other tables. It
	is the favoured choice of some members of the DVB community for		is the favoured choice of some members of the DVB community for
	address management and is briefly described below.		address management and is briefly described below.
	4.2.1 IP/MAC Notification Table (INT) and its usage		4.2.1 Description of the IP/MAC Notification Table (INT) and its
			usage.
	The INT provides a mechanism for carrying information about the		The INT provides a mechanism for carrying information about the
	location of IP/MAC flows within DVB networks. An IP/MAC Platform		location of IP/MAC flows within DVB networks. An IP/MAC Platform
	represents a set of IP/MAC streams and/or receiver devices. Such a		represents a set of IP/MAC streams and/or receiver devices. Such a
	Platform may span several transport streams within one or multiple		Platform may span several transport streams within one or multiple
	DVB networks and represents a single IP network with a harmonized		DVB networks and represents a single IP network with a harmonized
	address space (i.e. one without address conflicts). The IP/MAC		address space (i.e. one without address conflicts). The IP/MAC
	Platform concept allows for the coexistence of several		Platform concept allows for the coexistence of several
	non-harmonized IP/MAC address spaces on the same DVB network.		non-harmonized IP/MAC address spaces on the same DVB network.
			networks October 2004
	The INT allows "subnets" and fully specified single destination		The INT allows "subnets" and fully specified single destination
	addresses to make signalling bandwidth efficient and flexible as		addresses to make signalling bandwidth efficient and flexible as
	required. The "subnet mask" (also for IPv6) can be given in full		required. The "subnet mask" (also for IPv6) can be given in full
	form or in slash notation (e.g. /127), this supports IPv6		form or in slash notation (e.g. /127), this supports IPv6
	prefixes.		prefixes.
	Multicast addresses can be given with or without source (address		Multicast addresses can be given with or without source (address
	or range), although if source address is given then only the slash		or range), although if source address is given then only the slash
	notation can be used for prefixes/subnets.		notation can be used for prefixes/subnets.
	networks February 2005
	In addition to identification and security descriptors the		In addition to identification and security descriptors the
	following descriptors are used for address binding in INT tables:		following descriptors are used for address binding in INT tables:
	(i) target_MAC_address_descriptor: The descriptor used to		(i) target_MAC_address_descriptor: The descriptor used to
	describe a single or group of MAC addresses (and		describe a single or group of MAC addresses (and
	their mask).		their mask).
	(ii) target_MAC_address_range_descriptor: May be used to		(ii) target_MAC_address_range_descriptor: May be used to
	setup filters.		setup filters.
	(iii) target_IP_address_descriptor: The descriptor		(iii) target_IP_address_descriptor: The descriptor
	describing a single or group of IPv4 unicast or		describing a single or group of IPv4 unicast or
	skipping to change at page 10, line 45		skipping to change at page 11, line 5
	The INT provides a set of descriptors to manage addressing in a		The INT provides a set of descriptors to manage addressing in a
	DVB network. Its drawbacks are that while the IP/MAC concept is		DVB network. Its drawbacks are that while the IP/MAC concept is
	general enough there is still a need to manage the addressing		general enough there is still a need to manage the addressing
	(and the traffic) at the PID level. It currently is defined only		(and the traffic) at the PID level. It currently is defined only
	for Multi-Protocol Encapsulation (MPE) and would need extension to		for Multi-Protocol Encapsulation (MPE) and would need extension to
	support other schemes. In addition the use of a centralized		support other schemes. In addition the use of a centralized
	management prevents the implementation of a more dynamic		management prevents the implementation of a more dynamic
	scheme.		scheme.
	4.2.2 Multicast Mapping Table (MMT) and its usage		networks October 2004
			4.2.2 Description of the Multicast Mapping Table and its usage
	The Multicast Mapping Table (MMT) is an example employing an MPEG-2		The Multicast Mapping Table (MMT) is an example employing an MPEG-2
	level control table to communicate a set of multicast addresses and		level control table to communicate a set of multicast addresses and
	their associated PID value. This table allows a DVB-RCS Forward		their associated PID value. This table allows a DVB-RCS Forward
	Link Subsystem (FLSS) to specify the mapping and Return Channel		Link Subsystem (FLSS) to specify the mapping and Return Channel
	Satellite Terminals (RCSTs) to determine the PID values are being		Satellite Terminals (RCSTs) to determine the PID values are being
	used by the traffic that need to be received. The MMT is not		used by the traffic that need to be received. The MMT is not
	currently a part of the DVB-RCS specification.		currently a part of the DVB-RCS specification.
	networks February 2005		4.2.3 Description of the Application Information Table and its usage
	4.2.3 Application Information Table (AIT) and its usage
	The DVB Multimedia Home Platform (MHP) specification does not define		The DVB Multimedia Home Platform (MHP) specification does not define
	a specific AR function. However, the MHP Standard specifies an		a specific AR function. However, the MHP Standard specifies an
	Application Information Table (AIT) that each MHP Receiver monitors		Application Information Table (AIT) that each MHP Receiver monitors
	to receive a variety of control information. The AIT is a DSMCC		to receive a variety of control information. The AIT is a DSMCC
	format table that provides information about data broadcasts, the		format table that provides information about data broadcasts, the
	required activation state of applications carried by a broadcast		required activation state of applications carried by a broadcast
	stream, etc. This information allows the broadcaster to request that		stream, etc. This information allows the broadcaster to request that
	the receiver change the activation state of an application, and to		the receiver change the activation state of an application, and to
	direct applications to receive specific multicast packet flows		direct applications to receive specific multicast packet flows
	(using IPv4 or IPv6 routing descriptors. In MHP, AR is not seen as		(using IPv4 or IPv6 routing descriptors. In MHP, AR is not seen as
	specific function, but a part of a wider configuration and control		specific function, but a part of a wider configuration and control
	function.		function.
	4.2.4 Comparison of table based approaches		4.2.4 Comparison of table based approached and compliance to
			requirements
	All tables meet the specified requirements of the groups that		All tables meet the specified requirements of the groups that
	created them and all have their strength: the INT in terms of		created them and all have their strength: the INT in terms of
	flexibility and extensibility, the MMT in its simplicity, the AIT in		flexibility and extensibility, the MMT in its simplicity, the AIT in
	its extensibility. However, they exhibit scalability constraints,		its extensibility. However, they exhibit scalability constraints,
	encourage the development of technology specific solutions and do		encourage the development of technology specific solutions and do
	not fully adopt IP-centric approaches that would enable easier use		not fully adopt IP-centric approaches that would enable easier use
	of the MPEG-2 bearer as a link technology within the wider Internet.		of the MPEG-2 bearer as a link technology within the wider Internet.
	5. Mapping IP addresses to NPA/MAC addresses		<<< more specifics to be added later >>>
	This section reviews IETF protocols that may be used to assign and
	manage the mapping of IP addresses to/from NPA/MAC addresses.
	Two IETF-defined protocols for mapping IP addresses to NPA/MAC
	addresses are ARP and ND for IPv4 and IPv6 respectively. Both
	protocols are normally used in a bi-directional mode, although
	both also permit unsolicited transmission of mappings, which could
	potentially be used in a uni-directional environment.
	The use of ARP does not raise specific issues with the MPEG-2
	Table-based AR for MPEG-2 Transmission Network Virtual Logical
	Channels, since ARP uses only broadcast and unicast addresses.
	The use of ND requires a multicast mapping of the set of
	addresses used by ND to one or more MPEG-2 Transmission Network
	Virtual Logical Channels.
	<<< Some text is required to describe operational experience >>>
	networks February 2005
	5.1 Link Layer Support
	This section considers two layer 2 issues that need to be
	considered. One is the code-point to be used at L2 and the
	other is the efficiency of encapsulation for transmission
	to utilise the AR method. The table below summarises the
	options for both MPE and ULE encapsulations.
	+------------------------------+--------+----------------------+		5. Mapping of IP addresses to NPA/MAC addresses
	| | PDU |L2 Frame Header Fields|
	| L2 Encapsulation |overhead+----------------------+
	| |[bytes] |src mac|dst mac| type |
	+------------------------------+--------+-------+-------+------+
	|a. ULE without dst MAC address| 8 | - | - | x |
	|b. ULE with dst MAC address | 14 | - | x | x |
	|c. MPE without LLC/SNAP | 16 | - | x | - |
	|d. MPE with LLC/SNAP | 24 | - | x | x |
	|e. ULE with Bridging extension| 22 | x | x | x |
	|f. ULE with Bridging & NPA | 28 | x | x | x |
	|g. MPE+LLC/SNAP+Bridging | 38 | x | x | x |
	+------------------------------+--------+-------+-------+------+
	Table of L2 support and overhead (x=supported, -=not supported)
	a. ULE with no dst MAC/NPA address		This section reviews the mechanisms to assign IP addresses to
			NPA/MAC addresses. This means millions of potential mappings and
			raises the issues of scaling. It is obvious that in this case the
			un-solicited distribution of addresses by tables that carry
			single mappings needs to be avoided.
			<<< specific examples to be added >>>
	<< to be written>>		5.1 Bi-directional case
			<<< To be added >>>
			networks October 2004
	b. ULE with dst MAC/NPA address		5.2 Uni-directional case
	The IPv4 Address Resolution Protocol (ARP) [RFC826] uses		This section introduces how to use UDLR link layer tunneling
	an IANA-assigned EtherType and is supported with ULE [IP-IPDVB-ULE].		mechanisms to use ARP and ND on Uni-Directional DVB links
			and shows the results of the evaluation of the combinations
			of UDLR and various IP over DB encapsulation protocols.
	The ND protocol of IPv6 [RFC2461] may be used.		5.2.1 Issues
	<< More info on use of ND is required, noting that in one		In order to use ARP and ND on IP over a DVB link, there are 2
	form of header there is no MAC src address>>		issues that need to be considered. One is uni-directional
			functionality, and the other is the efficiency of encapsulation for
			IP over DVB transmission which is not AR related.
	c. MPE without LLC/SNAP		The IP over DVB link is basically a Uni-Directional Link (UDL), so
			ARP and ND do not work as is, because these protocols assume the
			link to be bi-directional. The UDL receiver cannot send any response
			to a querier over the UDL link.
	MPE does not provide an IANA-assigned EtherType and therefore		In order to solve this, we propose to use the UDLR (RFC3077)
	can not support the Address Resolution Protocol (ARP) [RFC826].		link layer tunneling mechanism. UDLR emulates the UDL as a
			bi-directional broadcast type link at the datalink layer. The
			uni-directional functionality is hidden to IP and upper layer
			protocols.
	The ND protocol of IPv6 [RFC2461] may be used.		5.2.2 Evaluation
	<< More info on use of ND is required, noting that in one form		(i)Candidate of IP over DVB encapsulation protocols
	of header there is no MAC src address>>
	networks February 2005
	d. MPE with LLC/SNAP		In order to evaluate the functionality of ARP and ND on the IP over
			DVB with UDLR environment, we select major IP over DVB encapsulation
			protocols as candidates namely ULE and MPE.
	The LLC/SNAP format of MPE provides an IANA-assigned EtherType and		Field on Ethernet frame
	therefore may support the Address Resolution Protocol (ARP)		Total OH src mac dst mac type
	[RFC826]. There is no specification to define how this is		[bytes]
	performed. In its simplest form, no MAC source address is present
	in the L2 frame.
	LLC/SNAP format MPE frames may optionally carry and IEEE bridging		a. ULE without dst MAC address 8 x x o
	header [LLC]. This header supplies both a MAC source and destination		b. ULE with dst MAC address 14 x o o
	address, at the expense of larger encapsulation overhead.		c. MPE without LLC/SNAP 16 x o x
			d. MPE with LLC/SNAP 24 x o o
			e. ULE with Bridging extension
			(8+2+6+6 B)
			f. MPE+LLC/SNAP+Bridging
			(24+2+6+6)
	The ND protocol of IPv6 [RFC2461] may be used.		(ii)Results of evaluation
	<< More info on the use of ND is required, noting that in one form		a. ULE without dst MAC address
	of header there is no MAC src address>>		<< To be added>>
			networks October 2004
	5.2 Impact on Network Protocols when using Bi-directional		b. ULE with dst MAC address
	Transmission		<< To be added>>
	<<< Other real implementation experience is requested: >>>		c. MPE without LLC/SNAP
	<<< Please send any experience to ipdvb list >>>		For IPv4, the ARP request packet cannot be transmitted
			on the UDL (for either feed or receiver query) because of
			the lack of Ethertype field. As result, the ARP protocol
			does not work on the UDL.
	<<< text on DHCP, L2TP, PPoE, etc to be added by		ND works fine. Because ND uses ICMP6 on IPv6, the datalink
	other volunteers >>>		Protocol does not need to carry non-IPv6 packets.
	5.3 Impact on Network Protocols when using Uni-directional		It is worth noting that this is not an issue with the ULE
	Transmission		encapsulation [ID-IPDVB-ULE].
	The IP over DVB link is basically a Uni-Directional broadcast		d. MPE with LLC/SNAP
	(UDL). ARP and ND do not work in their normal form over
	such links, because these protocols assume the bi-directional
	layer 2 connectivity. The UDL receiver cannot send any response
	to a querier over the UDL link.
	To solve this, we propose to use the UDLR (RFC3077)link layer		There is no specification to carry ARP packets using LLC/SNAP.
	tunneling mechanism. UDLR emulates the UDL as a		However LLC effectively bridges therefore there is no need for
	bi-directional broadcast type link at the datalink layer. The		a specific address.
	uni-directional functionality is hidden to IP and upper layer
	protocols.
	This section introduces how to use UDLR link layer tunneling		<<< others to be added when appropriate>>>
	mechanisms to use ARP and ND on Uni-Directional DVB links
	and shows the results of the evaluation of the combinations
	of UDLR and various IP over DVB encapsulation protocols.
	<<< Will be completed later, inputs required from WG >>>		5.2.3 Discussion
	networks February 2005
	5.4 Cable Networks		(i)ULE
			<<To be added>>
	Cable networks use different transmission schemes for the upstream		(ii)MPE
	and downstream transmission. They do not usually employ table based
	approaches for address resolution. Until the deployment of DOCSIS
	and EuroDOCSIS most address resolution schemes in cable networks
	for IP traffic have been proprietary and are still used for
	some STB requiring interaction. In last case it is the role of
	specific headend equipment to act as gateways between
	cable set-top boxes and the Internet. These gateways receive STB
	layer 2 information and allocate IP addresses; there is no
	use of inband tables.
	The information is sent (on the downstream) to the STBs as		The data link driver of Feed and Receiver must see the IP
	IP/Ethernet encapsulated as MPEG frames on a well known PID.		version field on the IP header to identify the IP version.
	DOCSIS uses only one PID. On the upstream, traffic is handled		There is no such field on the MPE header if LLC/SNAP is
	just like any Ethernet frames and not as IP/Ethernet over MPEG-2.		not used.
	While this approach is widespread, other roprietary schemes are
	still used.
	In the DOCSIS world, Cable Modem Terminal Systems (CMTSs) act as		<< More discussions to be added >>>
	DHCP servers and allocate IP addresses to DOCSIS modems and STBs.
	DOCSIS acts as an Ethernet bridge between the Cable Modem and the
	CMTS. The CMTS transparently proxies DHCP requests on behalf of a
	DHCP server on the network. The DHCP option is "giadd" (Gateway
	Internet Address)also called a "helper address", which is usually
	the address of a real DHCP server. From the point of view of
	modems and attached devices, it appears that the CMTS (default
	gateway/router)is also the DHCP server.
	networks February 2005		<<< Other real implementations requested: DHCP etc. >>>
			networks October 2004
	6. Conclusions and Recommendations		6. Conclusions and Recommendations
	This document has examined addressing and address resolution
	issues concerning the use of IP protocols over MPEG-2 transmission
	networks. A number of specific IETF protocols are discussed along
	with their expected behaviour over MPEG-2 transmission networks
	and recommendations for usage.
	In current MPEG-2 networks, the bindings between IP addresses and		In current MPEG-2 networks, the bindings between IP addresses and
	PIDs can be done statically (such as in the cable		PIDs are usually either done statically (such as in the cable
	networks) or carried in tables such at the standard AIT in MHP,		networks) or carried in tables such at the standard AIT in MHP and
	the IP Notification Tables (INT) of DVB and the DVB-RCS		the IP Notification Tables (INT) of DVB. In addition, the DVB-RCS
	Multicast Mapping Tables (MMT). This document has reviewed		community has defined a Multicast Mapping Tables (MMT) to improve
	the status of these current address resolution mechanisms		the efficiency of multicast address mappings in DVB-RCS networks.
	in MPEG-2 networks, defined their usage and proved information		This brief document has reviewed the status of these current
	to identify what would be needed to improve their conformity		address resolution mechanisms in MPEG-2 networks to clearly define
	to standard IP practices.		their usage and allow to identify what would be needed to improve
			their conformity to standard IP practices.
	Limitations of the current methods include the dynamics of		Current limitations of the current methods include the dynamics of
	the table refresh support for IP scoping of addresses, a generic		the table refresh support for IP scoping of addresses, a generic
	access method for ARP and ND using the ULE encapsulation and the		access method for ARP and ND using the ULE encapsulation and the
	lack of a universal and generic table access methodology.		lack of a universal and generic table access methodology.
			The authors recommend that standards track activity is needed
			in the IPDVB WG to define an IP-oriented alternative to allow link
			configuration of a ULE/MPE link above the IP layer.
	7. Security Considerations		7. Security Considerations
	The normal security issues relating to the use of wireless links		The normal security issues relating to the use of wireless links
	for transport Internet traffic should be considered. Readers are		for transport Internet traffic should be considered. Readers are
	also referred to the known security issues associated with ARP		also referred to the known security issues associated with ARP
	RFC826] and ND. Consideration will be given to those methods that		RFC826] and ND. Consideration will be given to those methods that
	will ensure that usage of MPEG-2 network resources will be		will ensure that usage of MPEG-2 network resources will be
	restricted to IP addresses that are not a threat to those		restricted to IP addresses that are not a threat to those
	resources or other resources in the Internet.		resources or other resources in the Internet.
	8. Acknowledgments		8. Acknowledgments
	The authors wish to thank Rod Walsh, Jun Takei, Alexander Adolf,		The authors wish to thank Rod Walsh, Jun Takei, Alexander Adolf
	Michael Mercurio and the ipdvb WG members for their inputs.		and the ipdvb WG members for their inputs. The authors would also
	The authors would also like to acknowledge the support of the		like to acknowledge the support of the European Space Agency
	European Space Agency.		networks October 2004
	networks February 2005
	9. References		9. References
	9.1 Normative References		9.1 Normative References
			[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic
			coding of moving pictures and associated audio information -- Part
			6: Extensions for DSM-CC is a full software implementation",
			International Standards Organisation (ISO).
			9.2 Informative References
	[ATSC] A/53C, "ATSC Digital Television Standard", Advanced		[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
	Television Systems Committee (ATSC), Doc. A/53C, 2004.		Television Systems Committee (ATSC), Doc. A/53C, 2004.
	[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced		[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
	Television Systems Committee (ATSC), Doc. A/090, 2000.		Television Systems Committee (ATSC), Doc. A/090, 2000.
	[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines		[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
	for the ATSC Data Broadcast Standard", Advanced Television Systems		for the ATSC Data Broadcast Standard", Advanced Television Systems
	Committee (ATSC),Doc. A/91, 2001.		Committee (ATSC),Doc. A/91, 2001.
	skipping to change at page 17, line 5		skipping to change at page 16, line 5
	Multimedia Home Platform (MHP) Specification", v1.2.1, European		Multimedia Home Platform (MHP) Specification", v1.2.1, European
	Telecommunications Standards Institute (ETSI), June 2002.		Telecommunications Standards Institute (ETSI), June 2002.
	http://www.etsi/org/		http://www.etsi/org/
	[ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB);		[ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB);
	Specification for Service Information (SI) in DVB systems".		Specification for Service Information (SI) in DVB systems".
	[ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB);		[ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB);
	Allocation of Service Information (SI) codes for DVB systems".		Allocation of Service Information (SI) codes for DVB systems".
	networks February 2005		networks October 2004
	[ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,		[ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,
	Collini-Nocker, B., and H. Linder, "Architecture for IP transport		Collini-Nocker, B., and H. Linder, "Architecture for IP transport
	over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt,		over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt,
	February 2005, Work in Progress, IPDVB WG.		October 2004, Work in Progress, IPDVB WG.
			[IP-IPDVB-ULE] Fairhurst, G., Collini-Nocker, B., and H. Linder,
			"Ultra Light Encapsulation", Internet Draft, draft-ipdvb-ule-02.txt,
			October 2004, Work in Progress, IPDVB WG.
	[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",
	nternet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work		nternet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work
	in Progress,MMUSIC WG.		in Progress,MMUSIC WG.
	[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic
	coding of moving pictures and associated audio information -- Part
	6: Extensions for DSM-CC is a full software implementation",
	International Standards Organisation (ISO).
	[RFC826] Plummer, D. "An Ethernet Address Resolution Protocol",		[RFC826] Plummer, D. "An Ethernet Address Resolution Protocol",
	RFC 826, IETF, November 1982.		RFC 826, IETF, November 1982.
	[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -		[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
	Communication Layers", RFC 1122.		Communication Layers", RFC 1122.
	[RFC1112] Deering, S.E., "Host Extensions for IP Multicasting",		[RFC1112] Deering, S.E., "Host Extensions for IP Multicasting",
	RFC1112, (STD05), IETF. August 1989.		RFC1112, (STD05), IETF. August 1989.
	[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor		[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6), RFC 2461, December 1998.		Discovery for IP Version 6 (IPv6), RFC 2461, December 1998.
	[RFC2464] Crawford. M., "Transmission of IPv6 Packets over		[RFC2464] Crawford. M., "Transmission of IPv6 Packets over
	Ethernet Networks", RFC2464, IETF December 1998.		Ethernet Networks", RFC2464, IETF December 1998.
	9.2 Informative References
	[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting,
	European Telecommunications Standards Institute (ETSI).
	[ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB
	interaction channel for Cable TV distribution systems (CATV),
	European Telecommunications Standards Institute (ETSI).
	[ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information technology ?
	Generic coding of moving pictures and associated audio
	information: Systems", International Standards Organisation (ISO).
	[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting,
	European Telecommunications Standards Institute (ETSI).
	http://www.atsc.org/standards/Code_Point_Registry.pdf
	networks February 2005
	10. Authors' Addresses		10. Authors' Addresses
	Godred Fairhurst		Godred Fairhurst
	Department of Engineering		Department of Engineering
	University of Aberdeen		University of Aberdeen
	Aberdeen, AB24 3UE		Aberdeen, AB24 3UE
	UK		UK
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
	Web: http://www.erg.abdn.ac.uk/users/gorry		Web: http://www.erg.abdn.ac.uk/users/gorry
	Marie-Jose Montpetit		Marie-Jose Montpetit
	MJMontpetit.com		MJMontpetit.com
	Email: marie@mjmontpetit.com		Email: marie@mjmontpetit.com
	Hidetaka Izumiyama		Hidetaka Izumiyama
	President CEO, Wishnet Inc.		President CEO, Wishnet Inc.
	5-15-5-001 Shirokanedai, Minato-ku		5-15-5-001 Shirokanedai, Minato-ku
	Tokyo, 108-0071, Japan		Tokyo, 108-0071, Japan
	Email: izu@wishnet.co.jp		Email: izu@wishnet.co.jp
			networks October 2004
	11. IPR Notices		11. IPR Notices
	Intellectual Property Statement		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
	skipping to change at page 19, line 5		skipping to change at page 17, line 32
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	networks February 2005
	Disclaimer of Validity		Disclaimer of Validity
	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.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/