Internet Engineering Task Force Z. Cao
Internet-Draft China Mobile
Intended status: Informational A. Ding
Expires: May 12, 2013 University of Helsinki
November 8, 2012
Service Discovery in a Multiple Connection Environment: Problem
Statement
draft-cao-mif-srv-dis-ps-01
Abstract
This document analyzes the problem of service discovery in a multiple
connection environment. A multiple connection environment consists
of multiple-interfaces nodes connecting to multiple networks or
multiple provisioning domains. Given a type of service a multiple-
interfaced client is looking for, the discovery progress ought to
return a correct pointer to the service instance that the client is
able to access.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 12, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Cao & Ding Expires May 12, 2013 [Page 1]
Internet-Draft MIF SRV Discovery November 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Cao & Ding Expires May 12, 2013 [Page 2]
Internet-Draft MIF SRV Discovery November 2012
1. Introduction
A multihomed host have multiple provisioning domains via physical
and/or virtual interfaces. A multihomed host receives node
configuration information from each of its access networks, through
various mechanisms such as DHCP, PPP and IPv6 Router Advertisements.
When the received node-scoped configuration objects have different
values from each administration domains, such as different DNS
servers IP addresses, different default gateways or different address
selection policies, the node has to decide which it will use or how
it will merge them.
Issues regarding how the multi-homed host uses the configuration
objects have been addresses in [RFC6418]. Current practices of how
the various implementations handle these problems are introduced in
[RFC6419]. DNS based Service Discovery (DNS-SD) has been specified
in [I-D.cheshire-dnsext-dns-sd]. And
[I-D.ietf-mif-dns-server-selection] extends DHCPv6 to inform the host
which DNS server it ought to select to send the query request.
This document analyzes the problem of service discovery in a multiple
connection environment. A multiple connection environment consists
of multiple-interfaces nodes connecting to multiple networks or
multiple provisioning domains. Given a type of service a multiple-
interfaced client is looking for, the discovery progress ought to
return a correct pointer to the service instance that the a client is
able to access.
2. Requirements and Terminology
2.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. Terminology
Service Domain
TBD.
Service Discovery
TBD.
Cao & Ding Expires May 12, 2013 [Page 3]
Internet-Draft MIF SRV Discovery November 2012
Multiple Connection Environment
TBD.
3. Problem Analysis
The following figure shows where and how the problem arises. The
host with multiple interfaces is a common case in today's mobile
Internet. On the service domain, different services are deployed and
some services may not be accessible to a certain interface on the
host. The service discovery process should return a correct point to
the host and makes sure that the host can access the service via this
pointer. This situation makes the multiple interface service
discovery different from the one-interface scenario.
+-------------------------------------------+
| Host with multiple interfaces |
| |
| |
| +---+ +---+ +---+ ... +---+ |
| | | | | | | ... | | |
+-----+--------+--------+-------------+-----+
| | | ... |
3G WLAN__ Wired ... ...
/ \________ \__ \
/ \____ \ \
------------------------------------------------------------------------
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ Service Domain
( Service ) ( Service )
\________________/ \_______________/
Figure 1: Multiple Interface Host with Multiple Available Services
The service discovery process can be summarized as query request,
query handling and response, and service access.
1. Determine Service Discovery Server: the host determines which
interface it should send a query request.
2. Service Query Request: the host sends a query request to find a
service. The query should include a description of the service,
for example, a full-qualified domain name, a URI, or an
application-specific naming of the service.
Cao & Ding Expires May 12, 2013 [Page 4]
Internet-Draft MIF SRV Discovery November 2012
3. Service Request Handling: any entity that receives the query
request should handle the request. The entity should understand
the meaning of the request, and check the semantics of the
request language before giving an answer back.
4. Service Query Response: the entity that receives the query
request should reply with an answer to the query. The answer
should include a pointer to the service.
5. Service Access: the host accesses the service via the pointer
provided in the query response. The host is supposed to be able
to get the service instance via the pointer under a successful
and efficient service discovery mechanism, unless the servers in
such service domain encounter problems e.g. a web server is down.
The problems that a multiple-interfaced host may meet during the
service discovery include:
1. How the query requests are sent? Because there are multiple
interfaces available and multiple service rendezvous existing,
the host should decide which destination it ought to send the
query to. And if there is a round-robin mechanism, the host
should determine the order of the query request.
2. How to handle the query and reply? Some pointers to the service
are restricted to a local scope or a certain interface, e.g., an
office printer may not be accessible to the 3G-interface. The
service discovery process is supposed to return a pointer that is
accessible to the host.
3. How to access the service? Given the pointer to the service, the
host should be able to determine from which interface it can
access the service.
In a DNS based service discovery, the problem of domain split is
analyzed in the MIF-DNS-Selection document
[I-D.ietf-mif-dns-server-selection]. The MIF-DNS-Selection document
actually defines an extension to the DHCPv4 and DHCPv6 to inform the
MIF host which domain scope the Recursive DNS Server(RDNSS) is
serving for, so that the "service query request" can be sent to the
correct RDNSS to get an answer. This method resolves the partial
problem in the service discovery process mentioned above.
In a more complicated network, as what is shown in Figure 2 , the
host connects to the enterprise network via the wired interface, a
WLAN network with the 802.11 interface, and an operator's network via
the cellular interface. The three intranets have their own Firewall
policies to the global Internet. On the enterprise network, many
Cao & Ding Expires May 12, 2013 [Page 5]
Internet-Draft MIF SRV Discovery November 2012
outgoing ports are restricted, and on the WLAN and operator's public
network, there is more freedom. If the MIF host makes a DNS-SRV
query to a service in a global domain, all the RDNS servers have the
corresponding records. But say the service port number has been
blocked by the enterprise network administrator, the DNS has no such
information. Even if the DNS returns a pointer to the MIF host, the
MIF host cannot access this service via the wired interface.
+---------------+
| RDNSS with | | Enterprise
+------+ | public + |----| Intranet
| | | enterprise's | |
| |------Wired -----| private names | |
| | +---------------+ +----------+----+
| MIF | | FW |
| node | +----+
| | +---------------+ +----+ |
| |----- WLAN ------| RDNSS with |--| FW |-----| Public
| | | public names | +----+ | Internet
| | +---------------+ |
| | +----+
| | | FW |
| | +---------------+ +----------+----+
| |---- Cellular ---| RDNSS with | |
+------+ | public + | | Operator
| operator's |----| Intranet
| private names | |
+---------------+
Figure 2: Scenario of Multiple Interface DNS Service Discovery
As a summary of the above analysis, the general problems and
requirements of service discovery in a MIF environment can be
summarized as follows:
Service Directory Service Configuration: Service directory is the
entity that store or can get the stored relationship between
service names and service pointers. Different interfaces or
provisioning domains have their different service directories.
How to configure them on the MIF host and how the MIF host utilize
the configured information are important for the service discovery
process to behave correctly.
Cao & Ding Expires May 12, 2013 [Page 6]
Internet-Draft MIF SRV Discovery November 2012
Service Directory Selection: After the service directory
information is configured on the host, the host is able to select
the correct directory to send the query. The host can utilize
auxiliary information available or send the query to all the
directories that have been configured. The behavior of MIF host
to select a correct directory is also important for a stable
system.
Service Pointer/Address Resolution: The same service may have
different available addresses and pointers, and some service has
limited connectivity. So the resolution process should be able to
return to the MIF host a record that is accessible from at least
one of the interfaces.
Service Route Selection: With the pointers returned, the host should
route the service level data to the service instance identified by
the return pointers.
4. IANA Considerations
This document has no IANA requests.
5. Security Considerations
The query response exchanges should be protected by security
mechanisms. If the response contains invalid information, e.g. a
pointer to a worm website, it harms. As a consequence, the service
discovery should protect bogus information injected by attackers or
intruders. The security consideration ought to be made by the
underlining protocols, and it is out of scope of this problem
statement document.
6. References
6.1. Normative References
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
[I-D.ietf-mif-dns-server-selection]
Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", draft-ietf-mif-dns-server-selection-12 (work in
Cao & Ding Expires May 12, 2013 [Page 7]
Internet-Draft MIF SRV Discovery November 2012
progress), August 2012.
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, November 2011.
Authors' Addresses
Zhen Cao
China Mobile
Xuanwumenxi Ave. No. 32
Beijing, 100871
China
Phone: +86-10-52686688
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Aaron Yi Ding
University of Helsinki
Department of Computer Science, P. O. Box 68
FI-00014 Helsinki
Finland
Phone: +358-9-19151296
Email: yding@cs.helsinki.fi
Cao & Ding Expires May 12, 2013 [Page 8]