One document matched: draft-bajko-mos-dns-discovery-00.txt
MIPSHOP WG Gabor Bajko
Internet Draft Nokia
Intended Status: Standards Track August 2007
Expires: February 20, 2008
Locating Mobility Servers
draft-bajko-mos-dns-discovery-00
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 February 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines application service tags that allow service
location without relying on rigid domain naming conventions, and DNS
procedures for discovering servers which provide Mobility Services.
Mobility Services are used to assist an MN in handover preparation
(network discovery) and handover decision (network selection). The
services addressed by this document are the Media Independent
Handover Services defined in [1].
Conventions used in this document
G. Bajko Expires 02/20/08 [Page 1]
Locating Mobility Services Servers August 2008
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 RFC-2119 [1].
Terminology and abbreviations used in this document
Mobility Services: comprises of a set of different services provided
by the network to mobile nodes to facilitate handover preparation
and handover decision.
Mobility Server: a network node providing Mobility Services.
MIH: Media Independent Handover, as defined in [1].
MIH Service: IS, ES or CS type of service, as defined in [1].
Application service: is a generic term for some type of
application, independent of the protocol that may be used to offer
it. Each application service will be associated with an IANA-
registered tag.
Application protocol: is used to implement the application service.
These are also associated with IANA-registered tags.
Table of Content
1. Introduction
IEEE 802.21 [1] defines three distinct service types to facilitate
link layer handovers across heterogeneous technologies:
a) Information Services (IS)
IS provides a unified framework to the higher layer entities
across the heterogeneous network environment to facilitate discovery
and selection of multiple types of networks existing within a
geographical area, with the objective to help the higher layer
mobility protocols to acquire a global view of the heterogeneous
networks and perform seamless handover across these networks.
b) Event Services (ES)
Events may indicate changes in state and transmission behavior
of the physical, data link and logical link layers, or predict state
changes of these layers. The Event Service may also be used to
indicate management actions or command status on the part of the
network or some management entity.
c) Command Services (CS)
The command service enables higher layers to control the
physical, data link, and logical link layers. The higher layers may
control the reconfiguration or selection of an appropriate link
through a set of handover commands.
G. Bajko Expires 01/10/08 [Page 2]
Locating Mobility Services Servers August 2008
In IEEE terminology these services are called Media Independent
Handover (MIH) services.
While these services may be co-located, the different pattern and
type of information they provide does not necessitate the co-
location.
An MN may make use of any of these MIH service types separately or
any combination of them.
It is anticipated that a Mobility Server will not necessarily host
all three of these MIH Services together, thus there is a need to
discover the MIH Service types separately.
This document defines a number of application service tags that
allow service location without relying on rigid domain naming
conventions.
2. Discovering a Mobility Server
The procedures defined here assume that the MN knows the domain name
of the network where it wants to locate a Mobility Server. The
domain name can either be pre-configured, discovered using DHCP or
learned from a previous Information Service (IS) query [1] [xxx].
The procedures defined here result in an IP address, port and
transport protocol where the MN can contact the Mobility Server
which hosts the service the MN is looking for.
2.1 Selecting a Mobility Service
The MN should know the characteristics of the Mobility Services
defined in [1] and based on that it should be able to select the
service it wants to use to facilitate its handover. The services it
can choose from are:
- Information Service (IS)
- Event Service (ES)
- Command Service (CS)
The service identifiers for the services are "IS", "ES" and "CS"
respectively.
The server supporting any of the above services MUST support UDP and
TCP as transport.
2.2 Selecting the transport
After the desired service has been chosen, the client selects the
transport protocol it prefers to use. Note, that transport selection
may impact the handover performance.
The services relevant for the task of transport protocol selection
are those with NAPTR service fields with values "IS+M2X" for IS
G. Bajko Expires 01/10/08 [Page 3]
Locating Mobility Services Servers August 2008
service, "ES+M2X" for the ES service, "CS+M2X" for the CS service,
where X is a letter that corresponds to a transport protocol
supported by the domain. This specification defines M2U for UDP and
M2T for TCP. We also establish an IANA registry for NAPTR service
name to transport protocol mappings.
These NAPTR [3] records provide a mapping from a domain to the SRV
[2] record for contacting a server with the specific transport
protocol in the NAPTR services field. The resource record will
contain an empty regular expression and a replacement value, which
is the SRV record for that particular transport protocol. If the
server supports multiple transport protocols, there will be multiple
NAPTR records, each with a different service value. As per RFC 2915
[3], the client discards any records whose services fields are not
applicable.
The MN MUST discard any service fields that identify a resolution
service whose value is not "M2X", for values of X that indicate
transport protocols supported by the client. The NAPTR processing
as described in RFC 2915 will result in the discovery of the most
preferred transport protocol of the server that is supported by the
client, as well as an SRV record for the server.
As an example, consider a client that wishes to find IS service in
the example.com domain. The client performs a NAPTR query for that
domain, and the following NAPTR records are returned:
order pref flags service regexp replacement
IN NAPTR 50 50 "s" "IS+M2T" "" _IS._tcp.example.com
IN NAPTR 90 50 "s" "IS+M2U" "" _IS._ucp.example.com
This indicates that the domain does have a server providing IS
services over TCP and UDP, in that order of preference. Since the
client supports TCP and UDP, TCP will be used, targeted to a host
determined by an SRV lookup of _IS._tcp.example.com. That lookup
would return:
;; Priority Weight Port Target
IN SRV 0 1 XXXX server1.example.com
IN SRV 0 2 XXXX server2.example.com
It is not necessary for the domain suffixes in the NAPTR replacement
field to match the domain of the original query (i.e., example.com
above). However, a domain MUST maintain SRV records for the domain
of the original query, even if the NAPTR record is in a different
domain, as the access network the MN is attached to might implement
policies which restrict access to certain domains. As an example,
even though the SRV record for TCP is _IS._tcp.school.edu, there
MUST also be an SRV record at _IS._tcp.example.com.
If no NAPTR records are found, the client constructs SRV queries for
those transport protocols it supports, and does a query for each.
G. Bajko Expires 01/10/08 [Page 4]
Locating Mobility Services Servers August 2008
Queries are done using the service identifier "_IS" for the
Information Service, "_ES" for the Event Service and "_CS" for
Command Service. A particular transport is supported if the query is
successful. The client MAY use any transport protocol it desires
which is supported by the server.
If no SRV records are found, the client SHOULD use TCP for the IS
service and UDP for the ES and CS service.
If the MN knows the IP address of the server, it may contact the
server using the default port number for that service.
2.3 Determining IP address and port
Once the server providing the desired service and the transport
protocol has been determined, the next step is to determine the IP
address and port.
If TARGET is a numeric IP address, the MN uses that IP address and
the already chosen transport to contact the server providing the
desired service.
If the TARGET was not a numeric IP address, then the MN performs an
A or AAAA record lookup of the domain name. The result will be a
list of IP addresses, each of which can be contacted using the
transport protocol determined previously.
If the result of the SRV query contains a port number, then the MN
SHOULD contact the server at that port number. If the SRV record did
not contain a port number then the MN SHOULD contact the server at
the default port number of that particular service.
5. IANA considerations
The usage of NAPTR records described here requires well known values
for the service fields for each transport supported by Mobility
Services. The table of mappings from service field values to
transport protocols is to be maintained by IANA. New entries in the
table MAY be added through the publication of standards track RFCs,
as described in RFC 2434 [4].
The registration in the RFC MUST include the following information:
Service Field: The service field being registered.
Protocol: The specific transport protocol associated with that
service field. This MUST include the name and acronym for the
protocol, along with reference to a document that describes the
transport protocol.
G. Bajko Expires 01/10/08 [Page 5]
Locating Mobility Services Servers August 2008
Name and Contact Information: The name, address, email address
and telephone number for the person performing the
registration.
The following values have been placed into the registry:
Services Field Protocol
IS+M2T TCP
IS+M2U UDP
ES+M2T TCP
ES+M2U UDP
CS+M2T TCP
CS+M2U UDP
6. Security considerations
7. Normative References
[1] IEEE 802.21 Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services
[2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
Specifying the Location of Services (DNS SRV)", RFC 2782, February
2000.
[3] Mealling, M., "DDDS, The Domain Name System (DNS) Database", RFC
3403, October 2002.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[xxx] MoS discovery procedures, work in progress
8. Informative References
8. Author's Addresses
Gabor Bajko
Nokia
gabor.bajko@nokia.com
G. Bajko Expires 01/10/08 [Page 6]
Locating Mobility Services Servers August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE
IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
G. Bajko Expires 01/10/08 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 07:37:10 |