draft-stiemerling-ipdvb-config-00.txt		draft-stiemerling-ipdvb-config-01.txt
	IPDVB Working Group M. Stiemerling		IPDVB Working Group M. Stiemerling
	Internet-Draft NEC		Internet-Draft NEC
	Expires: August 15, 2005 February 14, 2005		Expires: January 1, 2006 June 30, 2005
	Problem Statement: IP Address Configuration for IPDVB		Problem Statement: IP Address Configuration for IPDVB
	draft-stiemerling-ipdvb-config-00		draft-stiemerling-ipdvb-config-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 15, 2005.		This Internet-Draft will expire on January 1, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	Future IPDVB networks will require a more powerful IP address		Future IPDVB networks will require a more powerful IP address
	configuration management as currently provided in such networks.		configuration management as it is currently provided in such
	Current discussions within the IPDVB working group have shown that		networks. Current discussions within the IPDVB working group have
	the future usage scenarios and requirements for dynamic configuration		shown that the future usage scenarios and requirements for dynamic
	of IP addresses are not yet clear defined. This memo identifies the		configuration of IP addresses are not yet clear defined. This memo
	problem space for IP address resolution and configuration in IPDVB		identifies the problem space for dynamic IP address configuration in
	networks.		IPDVB networks.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Network Configuration Scenarios . . . . . . . . . . . . . . . 4		2. Network Configuration Scenarios . . . . . . . . . . . . . . . 4
	3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1 IP configuration available . . . . . . . . . . . . . . . . 6		3.1 IP configuration available . . . . . . . . . . . . . . . . 7
	3.2 Complete Bootstrap . . . . . . . . . . . . . . . . . . . . 6		3.2 Complete Bootstrap . . . . . . . . . . . . . . . . . . . . 7
	4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10		7.1 Normative References . . . . . . . . . . . . . . . . . . . 11
	7.2 Informative References . . . . . . . . . . . . . . . . . . . 10		7.2 Informative References . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
	A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . 13
	1. Introduction		1. Introduction
	Future IPDVB networks will require a more powerful IP address		Future IPDVB networks will require a more powerful IP address
	configuration management as currently provided in such networks.		configuration management as it is currently provided in such
	Current discussions within the IPDVB working group have shown that		networks. Current discussions within the IPDVB working group have
	the future usage scenarios and requirements for dynamic configuration		shown that the future usage scenarios and requirements for dynamic
	of IP addressesare not yet clear defined. This memo identifies the		configuration of IP addresses are not yet clear defined. This memo
	problem space for IP address resolution and configuration in IPDVB		identifies the problem space, sketches possible future scenarios, and
	networks.		gives an outlook into related areas. The IP address mapping to Layer
			2 identifier, known as IP address resolution, and the reverse way are
			out of scope of this memo. This topic is discussed in [5].
	The IPDVB working group has defined a new encapsulation scheme to		The IPDVB working group has defined a new encapsulation scheme to
	transport IP over DVB (MPEG2 based) networks, the so-called		transport IP over DVB (MPEG2 based) networks, the so-called Ultra-
	Ultra-lightweight Encapsulation [1]. This scheme assumes that IP		lightweight Encapsulation [1]. This protocol assumes that IP
	addresses have been already mapped to DVB identifiers (NPA, Network		addresses have been already assignment to hosts, DVB receivers, and
	Point of Attachment) or NPAs have been mapped to IP addresses		that hosts are already aware about other networking related
	(reverse address resolution) vice versa . Another issues concerns		parameters, such as IP gateway, DNS server, etc. Whereas today IP
	the assignment of IP addresses to DVB receivers. Whereas today IP
	addresses are statically to those receivers, future deployments may		addresses are statically to those receivers, future deployments may
	require a more flexible IP address assignment as known from today's		require a more flexible IP address assignment as known from today's
	LAN, for instance, via DHCP [3]. Assigning IP addresses dynamically		LAN, for instance, via DHCP [3] [4]. Assigning IP addresses
	opens the space for further auto-configuration of DVB receivers, such		dynamically opens the space for further auto-configuration of DVB
	as DNS server addresses or additional service layer information.		receivers. information.
	This memo is a problem statement only and is intended to start		This memo is a problem statement only and is intended to start
	discussions within the IPDVB working group. Comments and discussions		discussions within the IPDVB working group on how IP addresses and
	should be sent to the IPDVB's mailing list at ipdvb@erg.abdn.ac.uk		additional related information can be dynamically configured.
			Comments and discussions should be sent to the IPDVB's mailing list
			at ipdvb@erg.abdn.ac.uk. The working group charter is available
			here: http://www.ietf.org/html.charters/ipdvb-charter.html.
	Section 2 introduces the network configuration for IPDVB networks.		Section 2 introduces the network configuration for IPDVB networks.
	Section 3 describe two scenarios in detail. The document concludes		Section 3 describe two scenarios in detail. The document concludes
	with Section 4 listing similar areas of interest.		with Section 4 listing similar areas of interest.
	The terminology used throughout this memo is defined in [2]		The terminology used throughout this memo is defined in [2]
	2. Network Configuration Scenarios		2. Network Configuration Scenarios
	The basic assumption for IPDVB networks with respect to IP address		The basic assumption for IPDVB networks with respect to IP address
	receiver configuration and address resolution is the number of		configuration is the number of possible receivers (hosts) within a
	possible receivers (hosts) within a single IP subnetwork. It is		single IP subnetwork. It is assumed that future IPDVB networks may
	assumed that future IPDVB networks may extend to 1*10E5 receivers but		extend to 1*10E5 receivers per subnetwork but also may be limited to
	also may be limited to 10 or less receivers. Where the number of		10 or less receivers per subnetwork. This possible number of hosts
	hosts per sub-network in IPv4 networks, IPv6 networks can logically		should be consider when describing scenarios and later the solution.
	extend to a large number of hosts. Such an IPv6 IPDVB network could		However, the remainder of this section discusses different network
	comprise easily of 1*10E5 receivers, but the number can even break		scenarios with respect to their topology in the Internet and DVB
	down to only a few hosts, e.g., 10 or smaller. This possible number		network. Figure 1 sketches a typical configuration of DVB receivers
	of hosts should be consider when describing scenarios and later the		with an additional uplink, separated from DVB. This uplink can be,
	solution. Figure 1 sketches a typical configuration of DVB receivers
	with an additional uplink, separate from DVB. This uplink could be,
	but is not limited to, ISDN, DSL, or cellular networks based.		but is not limited to, ISDN, DSL, or cellular networks based.
	,-----.		,-----.
	DVB uplink / DVB \		DVB uplink / DVB \
	*##################( Network )		*########>>#########( Network )
	# \ /		# \ /
	+----*------+ `--.--'		+----*------+ `--.--'
	| Network | |		| Network | |
	| Provider +-<-+ v DVB downlink		| Provider +-<->+ v DVB downlink
	+-----------+ | |		+-----------+ | |
	| +-----v------+		| +-----v------+
	+--<<--+ DVB |		+-<->--+ DVB |
	uplink | Receiver |		uplink | Receiver |
	+------------+		+------------+
	Figure 1: Basic configuration scenario		Figure 1: Basic configuration scenario
	The uplink from DVB receiver to network provider can be bidirectional		The network provider is connected to the DVB network and IP network.
	and not as shown unidirectional only.		Data from the IP network towards the DVB receiver is transmitted
			either over the DVB uplink or the uplink connecting them directly.
			Data transmitted via the DVB uplink is transported of the DVB network
			and broadcasted to the DVB receivers. The uplink connecting network
			provider and DVB receiver can be unidirectional. The scenario
			depicted in this figure is well-known for DVB-S based high speed
			Internet access with modem or ISDN uplink. This type of installation
			is used to replace or substitute DSL deployments in geographical
			areas where DSL cannot be provided, for instance.
	Figure 1 shows a typical scenario of an installation used to replace		Figure 2 shows a scenario where the DVB receiver is connected via a
	or substitute DSL deployments in areas where DSL cannot be provided,		DVB link only and this link is used in a bidirectional way. Such a
	for instance. Figure 2 shows a scenario where the DVB receiver is		configuration will be used, for instance, on ships while being at sea
	connected via DVB only and the DVB link is used bidirectional. Such		and DVB-S is available only. In this configuration all information,
	a configuration will be used on ships while being on sea and only		including IP addresses, must be transmitted via the DVB link.
	DVB-S is available.
	,-----.		,-----.
	DVB link / DVB \		DVB link / DVB \
	*##################( Network )		*#######<###>######( Network )
	# \ /		# \ /
	+----*------+ `--.--'		+----*------+ `--.--'
	| Network | |		| Network | |
	| Provider | | DVB link		| Provider | ^ DVB link
	+-----------+ |		+-----------+ |
			v
			|
	+-----+------+		+-----+------+
	| DVB |		| DVB |
	| Receiver |		| Receiver |
	+------------+		+------------+
	Figure 2: DVB only configuration scenario		Figure 2: DVB only configuration scenario
	A scenario common to today's DVB broadcast usage is depicted in		A scenario similar to a today's common usage is the DVB broadcast as
	Figure 3. DVB receivers are using IP based transmission but receive		it is shown in Figure 3. The DVB part is an unicast link and all
	the data via broadcast only. Such DVB receivers do not have the		data is broadcasted to all receivers. This configuration is mainly
	ability to interact with any other entity and can be configured by a		used today for TV broadcasts (based on MPEG-2) but can be used to
	push mechanism only.		broadcast IP data to the DVB receivers too. In such case, DVB
			receivers do not have the ability to interact with any other entity
			to be configured. Address information can be delivered from a
			network provider to the receivers by a push mechanism only. However,
			a fine-grained IP address configuration per receiver seems to be out
			of scope in this case, since configuration of broadcast or multicast
			groups is appropriate only.
	,-----.		,-----.
	DVB link / DVB \		DVB link / DVB \
	*#######>>>########( Network )		*########>>########( Network )
	# \ /		# \ /
	+----*------+ `--.--'		+----*------+ `--.--'
	| Network | |		| Network | |
	| Provider | v DVB link		| Provider | v DVB link
	+-----------+ v		+-----------+ v
	|		|
	+-----+------+		+-----+------+
	| DVB |		| DVB |
	| Receiver |		| Receiver |
	+------------+		+------------+
	Figure 3: DVB based IP broadcast		Figure 3: DVB based IP broadcast
	3. Scenarios		3. Scenarios
	3.1 IP configuration available		3.1 IP configuration available
	This section considers scenarios where DVB receivers have IP		This section considers scenarios where DVB receivers have IP
	addresses already configured and only additional configuration		addresses already configured, or can obtain these through another way
	information is required. This configuration of DVB receivers, for		such as the ISDN uplink in Figure 1, and only configuration of
	example, may be either pre-configured by the service provider or be		additional information is required. This address configuration of
	configured by users. Figure 1 shows such a configuration example.		DVB receivers, for example, may be either pre-configured by the
	The DVB receiver will obtain its basic IP address configuration via		service provider or be configured by users. Figure 1 shows such a
	the non DVB uplink (most likely via ISDN and PPP). This scenario		configuration example. The DVB receiver will obtain its basic IP
	requires only additional configuration to be loaded at the DVB		address configuration via the non-DVB uplink (most likely via ISDN
	receivers. Possible things to configure:		and PPP). This scenario requires additional configuration to be
			loaded at the DVB receivers. Possible things to configure:
	o IP service information, such as DNS server, proxies, etc		o IP service information, such as DNS server, proxies, etc
	o multicast configuration and routing information		o multicast configuration and routing information
	o broadcast configuration ("open bitstream" without any		o broadcast configuration ("open bitstream" without any
	registration, DVB receivers just receive IP streams)		registration, DVB receivers just receive IP streams)
	o security configuration, e.g., keys, policies.		o security configuration, e.g., keys, policies.
	3.2 Complete Bootstrap		3.2 Complete Bootstrap
	Future scenarios may require a complete bootstrap of DVB receivers		Future scenarios can require a complete bootstrap of DVB receivers
	without any pre-configuration available on the IP level. Those DVB		without any pre-configuration available on the IP level. Those DVB
	receivers may be pre-configured to known a basic DVB configuration,		receivers may be pre-configured to known a basic DVB configuration,
	such as PID assignment for system information tables (SI tables).		such as PID assignment for system information tables (SI tables).
	Such a receiver would need to retrieve first an IP address and learn		Such a receiver would need to retrieve first an IP address and learn
	about its IP environment (netmask, IP next hop, ...). Figure 2 shows		about its IP environment (netmask, IP next hop, ...). Figure 2 shows
	such a scenario where a DVB receiver (and transmitter) would be		such a scenario where a DVB receiver (and transmitter) is installed
	installed aboard a ship and would function as a gateway between the		aboard a ship and is a gateway between the ship's network and the DVB
	ship's network and the DVB network.		network. The complete bootstrap scenario includes the one shown in
			Figure 3 too.
	4. Related Work		4. Related Work
	Configuration of DVB, or more general MPEG2 based, networks is		Configuration of DVB, or more general MPEG2 based, networks is
	tackled in several other environments with different prerequisites.		tackled in several other environments with different prerequisites.
	IP over Cable Data Networks (IPDCN) working group is working in this		The IP over Cable Data Networks (IPDCN) working group is working in
	area and is specifying several MIB modules with respect to MPEG2		this area and is specifying several MIB modules with respect to MPEG2
	network configuration. DVB itself has defined several mechanism to		network configuration. DVB itself has defined several mechanism to
	configure receivers, such as system information tables (SI tables),		configure receivers, such as system information tables (SI tables),
	or within MHP.		or within MHP.
	Configuration of IP hosts is focus of the Network Configuration		Configuration of IP hosts is focus of the Network Configuration
	(NETCONF) working group, Dynamic Host Configuration (DHC) working		(NETCONF) working group, Dynamic Host Configuration (DHC) working
	group, and defined in several RFC documents (IPV6 neighbor discovery,		group, and defined in several RFC documents (IPV6 neighbor discovery,
	IPv4 Address Resolution Protocol (ARP)).		IPv4 Address Resolution Protocol (ARP)).
	5. Conclusions		5. Conclusions
	This memo is first attempt to solve the questions on how future IPDVB		This memo is first attempt to solve the questions on how future IPDVB
	networks can deal with IP address resolution and address		networks can deal with dynamic IP address configuration. Open
	configuration. Open questions are:		questions are:
	o What are the configuration scenarios?		o What are the configuration scenarios?
	o What exactly should be configured?		o What exactly should be configured?
	o How to configure?		o How to configure?
	o Who is in control of the receiver? The operator is in control of		o Who is in control of the receiver? The operator is in control of
	the receiver in the case of MHP. Users running a DVB PC adaptor		the receiver in the case of MHP. Users running a DVB PC adaptor
	have full control over their receiver and network operators		have full control over their receiver and network operators
	running their routers on DVB network a likely not to give away		running their routers on DVB network a likely not to give away
	control over their equipment.		control over their equipment.
			o Is it right to assume that the network provider and DVB network
			operator are the same entity.
	During the first discussions at the 61st IETF some differences		During the first discussions at the 61st IETF some differences
	between IPDVB and other network configuration techniques have been		between IPDVB and other network configuration techniques have been
	noted. The NETCONF approach is made for single router configuration		noted. The NETCONF approach is made for single router configuration
	and is not intended to configure thousands of host at the same time.		and is not intended to configure thousands of host at the same time.
	IPCDN on the other hand considers 1*10e3 hosts per cable head end to		IPCDN on the other hand considers 1*10e3 hosts per cable head end to
	be configured. IPDVB must consider up to 1*10e5 hosts per segment,		be configured. IPDVB must consider up to 1*10e5 hosts per segment,
	see Section 2. This must be definitely taken into account when		see Section 2. This must be definitely taken into account when
	designing a solution.		designing a solution.
	This memo is neither accurate nor complete at this point of time and		This memo is neither accurate nor complete at this point of time and
	should trigger the discussions within the IPDVB working group. Feed		should trigger the discussions within the IPDVB working group.
	back to this memo is welcome.		Feedback about this memo is welcome.
	6. Security Considerations		6. Security Considerations
	Security considerations are to be done in future revisions of this		Security considerations are to be done in future revisions of this
	document.		document.
	7. References		7. References
	7.1 Normative References		7.1 Normative References
	[1] Fairhurst, G. and B. Collini-Nocker, "Ultra Lightweight		[1] Fairhurst, G. and B. Collini-Nocker, "Ultra Lightweight
	Encapsulation (ULE) for transmission of IP datagrams over		Encapsulation (ULE) for transmission of IP datagrams over MPEG-
	MPEG-2/DVB networks", draft-fair-ipdvb-ule-02 (work in		2/DVB networks", draft-fair-ipdvb-ule-02 (work in progress),
	progress), November 2003.		November 2003.
	[2] Montpetit, M., "A Framework for transmission of IP datagrams		[2] Montpetit, M., "A Framework for transmission of IP datagrams
	over MPEG-2 Networks", draft-ietf-ipdvb-arch-03 (work in		over MPEG-2 Networks", draft-ietf-ipdvb-arch-04 (work in
	progress), January 2005.		progress), May 2005.
	7.2 Informative References		7.2 Informative References
	[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,		[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	October 1993.		March 1997.
			[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
			Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
			RFC 3315, July 2003.
			[5] Fairhurst, G., "Address Resolution for IP datagrams over MPEG-2
			networks", draft-fair-ipdvb-ar-04 (work in progress),
			April 2005.
	Author's Address		Author's Address
	Martin Stiemerling		Martin Stiemerling
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 905 11 13		Phone: +49 (0) 6221 905 11 13
	EMail: stiemerling@netlab.nec.de		Email: stiemerling@netlab.nec.de
	URI: http://www.stiemerling.org/ipdvb		URI: http://www.stiemerling.org/ipdvb
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	Parts of this work are a product of the Enthrone project supported in		Parts of this work are a product of the Enthrone project supported in
	part by the European Commission under its Sixth Framework Programme.		part by the European Commission under its Sixth Framework Programme.
	It is provided as is and without any express or implied warranties,		It is provided as is and without any express or implied warranties,
	including, without limitation, the implied warranties of fitness for		including, without limitation, the implied warranties of fitness for
	a particular purpose. The views and conclusions contained herein are		a particular purpose. The views and conclusions contained herein are
	those of the authors and should not be interpreted as necessarily		those of the authors and should not be interpreted as necessarily
End of changes.
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/