Internet DRAFT - draft-stiemerling-ipdvb-config
draft-stiemerling-ipdvb-config
IPDVB Working Group M. Stiemerling, Ed.
Internet-Draft NEC
Expires: April 27, 2006 G. Gardikis
Demokritos
H. Asgari
Thales
D. Negru
PRiSM
T. Ahmed
LaBRI
October 24, 2005
Problem Statement: Configuration of IP services for IPDVB
draft-stiemerling-ipdvb-config-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Future IPDVB networks will require a more powerful configuration
Stiemerling, et al. Expires April 27, 2006 [Page 1]
Internet-Draft IPDVB Address Configuration October 2005
management of IP addresses and related networking parameters as it is
currently provided in such networks. Current discussions within the
IPDVB working group have shown that the future usage scenarios and
requirements for dynamic configuration management are not yet clearly
defined. This memo identifies the problem space for dynamic
configuration of IP networking parameters in IPDVB networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Set-up Scenarios . . . . . . . . . . . . . . . . . . . 4
2.1 Hybrid Bi-directional Set-up - Scenario 1 . . . . . . . . 4
2.2 DVB-based Bi-directional Set-up: Scenario 2 . . . . . . . 5
2.3 DVB-based unidirectional Set-up: Scenario 3 . . . . . . . 6
3. Configuration Scenarios . . . . . . . . . . . . . . . . . . . 7
3.1 Static IP configuration . . . . . . . . . . . . . . . . . 7
3.2 IP configuration via the interaction network . . . . . . . 7
3.3 Complete Bootstrap . . . . . . . . . . . . . . . . . . . . 7
4. Requirements for dynamic IP configuration . . . . . . . . . . 8
5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Stiemerling, et al. Expires April 27, 2006 [Page 2]
Internet-Draft IPDVB Address Configuration October 2005
1. Introduction
Future IPDVB networks will require a more powerful IP address
configuration management as it is currently provided in such
networks. The required configuration may depend on the offered
services transmitted via DVB. Current discussions within the IPDVB
working group have shown that the future usage scenarios and
requirements for dynamic configuration of IP addresses and other
parameters are not yet clearly defined. Other parameters can be, but
are not limited to, multicast addresses, application level gateways
(proxies), DNS servers, etc. This memo identifies the problem space,
sketches possible future scenarios, and gives an outlook in 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
transport IP over DVB (MPEG-2 based) networks, the so-called
Unidirectional Lightweight Encapsulation [1]. This protocol assumes
that IP addresses have already been assigned to hosts, DVB receivers,
and that hosts are already aware of other networking related
parameters, such as IP gateway, DNS server, etc. Where today IP
addresses are statically assigned to those receivers, future
deployments may require more flexible IP address assignment
mechanisms such as the ones known from today's LANs, for instance,
via DHCP [3] [4]. Assigning IP addresses dynamically opens the path
for further IPv4 and IPv6 auto-configuration of DVB receivers.
This memo is a problem statement only and is intended to start
discussions within the IPDVB working group on how IP addresses and
additional related information can be configured dynamically.
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 3 describes two scenarios in details. Section 4 suggests the
requirements to which a possible auto-configuration solution would
comply. The document concludes with Section 5 listing similar areas
of interest.
The terminology used throughout this memo is defined in [2].
Stiemerling, et al. Expires April 27, 2006 [Page 3]
Internet-Draft IPDVB Address Configuration October 2005
2. Network Set-up Scenarios
The basic assumption for IPDVB networks with respect to IP address
configuration is the number of possible receivers (hosts) within a
single IP subnetwork. It is assumed that future IPDVB networks can
extend to 1*10E5 receivers per subnetwork but can also be limited to
10 or less receivers per subnetwork. This possible number of hosts
must be considered when describing scenarios and later the solution.
However, the remainder of this section discusses different network
scenarios with respect to their topology in the Internet and DVB
network.
2.1 Hybrid Bi-directional Set-up - Scenario 1
Figure 1 sketches a hybrid interactive topology, where the downlink
is a DVB trunk and the uplink is based on a common (wired or
wireless) data networking technology. The (unidirectional) DVB
downlink can be either cable, satellite or terrestrial, whereas the
(bi-directional) uplink can be, but is not limited to, ISDN, DSL,
WLAN/WMAN, or cellular networks based.
,-----.
IP link / DVB \
*########>>#########( Network )
# \ /
+----*------+ `--.--'
| Network | |
| Provider +-<->+ v DVB downlink
+-----------+ | |
| +-----v------+
+-<->--+ DVB |
uplink | Receiver |
+------------+
Figure 1: Hybrid set-up: scenario 1
The network provider's domain is connected to both, the DVB network
and IP bi-directional interaction network. Upon activation of the
user terminal, a bi-directional connection is thus established
between the receiver and the provider of the interaction network.
This communication is mostly based on asymmetric data flow, where
data destined to the user are included in the DVB downlink, and the
Stiemerling, et al. Expires April 27, 2006 [Page 4]
Internet-Draft IPDVB Address Configuration October 2005
uplink is mainly used for requests/acknowledgments and other related
signalling.
Typical scenarios would include set-ups as:
o DVB-S/S.2 with PSTN/ISDN (fixed broadband access)
o DVB-T with PSTN/ISDN/xDSL/WLAN/WMAN (fixed terrestrial)
o DVB-H with GPRS/3G (mobile use)
2.2 DVB-based Bi-directional Set-up: Scenario 2
Figure 2 shows a scenario where the DVB receiver utilizes DVB-based
technologies for both the downlink (DVB-S, DVB-T, DVB-H) and the
uplink (DVB-RCS, DVB-RCT). Such a configuration will be used, for
instance, on ships while being at sea with a DVB-S only solution
available. In this case, DVB-RCS can be used for interaction. In
another scenario, DVB-RCT can be used as an uplink in fixed or mobile
DVB-T/DVB-H reception, as an alternative to using a cellular network.
In all these configurations, all information, including IP addresses,
must be transmitted via the DVB links.
,-----.
IP link / DVB \
*#######<###>######( Network )
# \ /
+----*------+ `--.--'
| Network | | |
| Provider | DVB uplink ^ v DVB downlink
+-----------+ (RCT, RCS) | | (S,T,H)
^ v
| |
+-----+------+
| DVB |
| Receiver |
+------------+
Figure 2: Network set-up using DVB links in both directions: scenario
2
Stiemerling, et al. Expires April 27, 2006 [Page 5]
Internet-Draft IPDVB Address Configuration October 2005
2.3 DVB-based unidirectional Set-up: Scenario 3
This is a scenario similar to a today's common usage of DVB
broadcast, as is shown in Figure 3. The DVB part is an unicast link
and all data is broadcasted to all receivers. This configuration is
mainly used today for TV broadcasts services (based on MPEG-2) but it
can be used to broadcast IP data to the DVB receivers too. In such
case, DVB receivers do not have the ability to interact with any
external entity for configuration purpose. Address information can
be delivered from a network provider to the receivers by a push
mechanism only. However, a fine-grained unicast IP address
configuration per receiver does not to be very likely in this case,
since configuration of broadcast or multicast groups is mostly
appropriate.
Unicast IP address assignment should anyway be supported for the
(scarce but possible) case of operator-initiated unicast push. This
could be the scenario when a client issues a request for a block of
information (e.g. a movie) to be sent to it via a voice telephone
call or an SMS.
,-----.
IP link / DVB \
*########>>########( Network )
# \ /
+----*------+ `--.--'
| Network | |
| Provider | v DVB link
+-----------+ v
|
+-----+------+
| DVB |
| Receiver |
+------------+
Figure 3: DVB-based uni-directional set-up: Scenario 3
Stiemerling, et al. Expires April 27, 2006 [Page 6]
Internet-Draft IPDVB Address Configuration October 2005
3. Configuration Scenarios
3.1 Static IP configuration
This scenario assumes that the IP address of the user terminal along
with its networking (and DVB-related) parameters have been pre-
configured. This is an acceptable solution for fixed reception,
where the number of users is relatively small. No additional
protocol and signalling are required.
3.2 IP configuration via the interaction network
The following operation is intended for scenario 1. Figure 1 shows
such a configuration example. The DVB receiver will obtain its basic
IP address configuration via the non-DVB uplink (most likely via ISDN
and PPP, xDSL or 3G/GPRS). The interaction network assigns an IP
address, dynamic or static, public or private, to the connected
client. This address can represent the terminal as a whole (i.e.
there is no need to allocate a second IP address for the DVB receive-
only interface).
In any case, the scenario of the IP address being configured by the
interaction network requires additional configuration to be loaded
at the DVB receivers. Possible configurations include:
o IP service information, such as DNS server, proxies, etc
o multicast configuration and routing information
o broadcast configuration (service_id or PID in which the IP data
can be found, encapsulation method [ETH] ULE or MPE)
o security configuration, e.g., keys, policies, IPsec parameters.
3.3 Complete Bootstrap
Scenarios 2 and 3 can require a complete bootstrap of DVB receivers
without any pre-configuration available at the IP level. Those DVB
receivers may be pre-configured to known a basic DVB configuration,
such as PID assignment for a special data stream containing auto-
configuration data. Such a receiver would need to retrieve first an
IP address and learn about its IP environment (netmask, IP next hop,
...). Figure 2 shows such a scenario where a DVB receiver (and
transmitter) is installed aboard a ship and is a gateway between the
ship's network and the DVB network. The complete bootstrap scenario
includes the one shown in Figure 3 too.
Stiemerling, et al. Expires April 27, 2006 [Page 7]
Internet-Draft IPDVB Address Configuration October 2005
4. Requirements for dynamic IP configuration
Any proposed mechanism for the dynamic configuration of the host's
networking parameters should fulfil certain requirements.
Specifically, its necessary features should be:
1. Scalability: In contrast to LANs or dial-up environments, in
which DHCP or PPP is used, a DVB service can be addressed to
thousands of users. The mechanism should be able to process
numerous client requests and assign addresses from a large pool.
2. Support for both IPv4 and IPv6: Current DVB receivers support
mostly IPv4, because MPE is IPv4-oriented. The forthcoming ULE
supports IPv4 and IPv6 in an equal manner, so both protocols must
be supported. It might be desirable that a single IP address is
assigned to each receiver and not multiple ones (e.g. one for the
DVB interface and a second for the interactive interface).
3. Configuration of IP-related parameters: In addition to client IP
address, more configuration operations such as gateway address,
DNS server address, domain name and IPsec parameters must be
performed.
4. Configuration of DVB-related parameters: These parameters such as
service_id or PID where the data destined to the user are to be
found as well as encapsulation method used (ULE or MPE).
Although the association between IP and DVB parameters is
actually an address-resolution issue, it would be quite helpful
for the receiver to know in advance the TS logical channel
containing its data, before having to employ an AR protocol or
browse into the INT table (which is anyway impractical for a
large number of receivers). Anyway, regardless of the signalling
issue, it is the auto-configuration mechanism which should
allocate a TS Logical Channel (TSLC) for each user. Depending on
the number of associated receivers, this relation could be other
than one-to-one (i.e., one TSLC could correspond to multiple
users, or a user could retrieve information from multiple TSLCs).
5. Support for authentication mechanisms: The DVB broadcast downlink
is 'open' to anyone, but it is rational to assume that
bidirectional access is restricted only to authorized receivers.
Before sending the IP parameters the dynamic configuration server
would follow an authentication process to validate the identity
of the client terminal.
6. Handover support: In the case that the receiver moves across
neighbouring DVB macrocells (in the terrestrial scenario mostly),
the dynamic configuration mechanism should cooperate with the
Stiemerling, et al. Expires April 27, 2006 [Page 8]
Internet-Draft IPDVB Address Configuration October 2005
handover backplane to ensure that IP connectivity is maintained
in the destination cell. The operator can choose either to keep
the same IP parameters or allocate new ones to the client
terminal upon associating it to the new DVB cell. In the case of
SFN implementation, this issue does not exist, as the same
multiplex is present in all transmitters, and no handover process
actually takes place.
Stiemerling, et al. Expires April 27, 2006 [Page 9]
Internet-Draft IPDVB Address Configuration October 2005
5. Related Work
Configuration of DVB networks, or more generally MPEG-2 based
networks, are tackled in several other environments with different
prerequisites. The IP over Cable Data Networks (IPDCN) working group
is working in this area and is specifying several MIB modules with
respect to MPEG2 network configuration. DVB itself has defined
several mechanisms to configure receivers, such as system information
tables (SI tables), or within MHP.
Configuration of IP hosts is the focus of the Network Configuration
(NETCONF) working group, Dynamic Host Configuration (DHC) working
group, defined in several RFC documents (IPv4 Address Resolution
Protocol (ARP), IPv6 neighbour discovery (ND)) etc.
Stiemerling, et al. Expires April 27, 2006 [Page 10]
Internet-Draft IPDVB Address Configuration October 2005
6. Conclusions
This memo is the first attempt to answer the questions on how future
IPDVB networks can deal with dynamic IP address configuration. Open
questions are:
o What are the configuration scenarios?
o What exactly should be configured?
o How to configure?
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
have full control over their receiver and network operators
running their routers on DVB networks are likely not to give away
control over their equipment.
o Is it right to assume that the network provider and DVB network
operator are the same entity? For DVB only access networks this
might be true, but for future scenarios it is unlikely that the
DVB network operator and IP network operator is the same entity.
During the first discussions at the 61st IETF some differences
between IPDVB and other network configuration techniques have been
noted. The NETCONF approach is made for a single router
configuration and is not intended to configure thousands of host.
IPCDN on the other hand considers 1*10e3 hosts per cable head end to
be configured. IPDVB may consider up to 1*10e5 hosts per segment,
see Section 2. This must be definitely taken into account when
devising a solution.
Further discussions amongst the authors have raised the concern about
the density of the hosts per subnetwork. Initially, it has been
assumed that IPDVB-based subnetworks can consist out of 1*10e5 hosts,
because of the broadcast nature of DVB. This raises the scalability
issue of any solution.
This memo is neither accurate nor complete at this point of time and
should trigger the discussions within the IPDVB working group.
Feedback about this memo is welcome.
Stiemerling, et al. Expires April 27, 2006 [Page 11]
Internet-Draft IPDVB Address Configuration October 2005
7. Security Considerations
Security considerations are to be done in future revisions of this
document.
Stiemerling, et al. Expires April 27, 2006 [Page 12]
Internet-Draft IPDVB Address Configuration October 2005
8. References
8.1 Normative References
[1] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight
Encapsulation (ULE) for transmission of IP datagrams over an
MPEG-2 Transport Stream", draft-ietf-ipdvb-ule-06 (work in
progress), June 2005.
[2] Montpetit, M., "A Framework for transmission of IP datagrams
over MPEG-2 Networks", draft-ietf-ipdvb-arch-04 (work in
progress), May 2005.
8.2 Informative References
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
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.
Authors' Addresses
Martin Stiemerling (editor)
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 13
Email: stiemerling@netlab.nec.de
URI: http://www.stiemerling.org/ipdvb
Georgios J. Gardikis
NCSR "Demokritos", Institute of Informatics and Telecommunications
Greece
Email: gardikis@iit.demokritos.gr
Stiemerling, et al. Expires April 27, 2006 [Page 13]
Internet-Draft IPDVB Address Configuration October 2005
Hamid Asgari
Thales
United Kingdom
Email: Hamid.Asgari@thalesgroup.com
Daniel Negru
PRiSM - Research laboratory in computers sciences
France
Email: Daniel.Negru@prism.uvsq.fr
Toufik Ahmed
Laboratoire Bordelais de Recherche en Informatique
France
Email: tad@labri.fr
Stiemerling, et al. Expires April 27, 2006 [Page 14]
Internet-Draft IPDVB Address Configuration October 2005
Appendix A. Acknowledgments
Parts of this work are a product of the Enthrone project supported in
part by the European Commission under its Sixth Framework Programme.
It is provided as is and without any express or implied warranties,
including, without limitation, the implied warranties of fitness for
a particular purpose. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed
or implied, of the Enthrone project or the European Commission.
Stiemerling, et al. Expires April 27, 2006 [Page 15]
Internet-Draft IPDVB Address Configuration October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stiemerling, et al. Expires April 27, 2006 [Page 16]
