[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc5679                               
MIPSHOP WG                                                   Gabor Bajko
Internet Draft                                                     Nokia
Intended Status: Proposed Standard                          May 19, 2008
Expires: November 19, 2008



                       Locating Mobility Servers using DNS
                    draft-ietf-mipshop-mos-dns-discovery-01


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 November 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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 11/19/08                  [Page 1]


Locating Mobility Servers using DNS                          April 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....................................................2
   2. Discovering a Mobility Server...................................3
        2.1 Selecting a Mobility Service..............................3
        2.2 Selecting the transport protocol..........................4
        2.3 Determining the IP address and port.......................5
   3. IANA Considerations.............................................6
   4. Security Considerations.........................................6
   5. Normative References............................................6
   6. Informative References..........................................7
   7. Author's Address................................................7


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)

G. Bajko                   Expires 11/19/08                  [Page 2]


Locating Mobility Servers using DNS                          April 2008

        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.

   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 of the network can either be pre-configured, discovered
   using DHCP or learned from a previous Information Service (IS) query
   [1] as described in [ID.ietf-mipshop-mstp-solution].
   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.

G. Bajko                   Expires 11/19/08                  [Page 3]


Locating Mobility Servers using DNS                          April 2008


   The server supporting any of the above services MUST support UDP and
   TCP as transport, as described in [ID.ietf-mipshop-mstp-solution].

2.2 Selecting the transport protocol

   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
   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, M2T
   for TCP and M2S for SCTP. 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 3403
   [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 3403 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

G. Bajko                   Expires 11/19/08                  [Page 4]


Locating Mobility Servers using DNS                          April 2008


   If the client implementation is configured to only use one specific
   transport protocol for a service, e.g. UDP for ES, then NAPTR query
   is not necessary, but only an SRV lookup of _ES._udp.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.
   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.

   Note, that the regexp field in the NAPTR example above is empty.
   This document discourages the use of this field as its usage can be
   complex and error prone; and the discovery of the MIH services do
   not require the flexibility provided by this field over a static
   target present in the TARGET field.

   If no SRV records are found, the client SHOULD use TCP to contact a
   server which hosts an IS service and UDP to contact a server which
   hosts an ES and/or 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. Default port
   numbers for IS, ES and CS services are requested from IANA in
   [ID.ietf-mipshop-mstp-solution].

2.3 Determining the 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.


G. Bajko                   Expires 11/19/08                  [Page 5]


Locating Mobility Servers using DNS                          April 2008

   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. Default port
   numbers for IS, ES and CS services are requested from IANA in
   [ID.ietf-mipshop-mstp-solution].

3. 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.

   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.

        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:

   Service Fields               Protocol
   IS+M2T                       TCP
   IS+M2U                       UDP
   IS+M2S                       SCTP
   ES+M2T                       TCP
   ES+M2U                       UDP
   ES+M2S                       SCTP
   CS+M2T                       TCP
   CS+M2U                       UDP
   CS+M2S                       SCTP

   New entries to the registry MAY be added by IANA on a "First Come
   First Served" basis.

4. Security considerations

   Fake DNS requests and responses may cause DoS. Where networks are
   exposed to such DoS, it is recommended that DNS service providers
   use the Domain Name System Security Extensions (DNSSEC) as described
   in [RFC4033].

G. Bajko                   Expires 11/19/08                  [Page 6]


Locating Mobility Servers using DNS                          April 2008

   Readers may also refer to [RFC4641] to consider the aspects of
   DNSSEC Operational Practices.

5. Normative References

   [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.

   [RFC4033] DNS Security Introduction and Requirements, Arends et al,
       March 2005


6. Informative References

   [1] IEEE 802.21 Standard for Local and Metropolitan Area Networks:
       Media Independent Handover Services

   [ID.ietf-mipshop-mstp-solution] Mobility Services Transport
       Protocol Design, Melia et al, April 2008, work in progress

   [RFC4641] DNSSEC Operational Practices, Kolkman et al, September
       2006


G. Bajko                   Expires 11/19/08                  [Page 7]


Locating Mobility Servers using DNS                          April 2008

7. Author's Address

   Gabor Bajko
   Nokia
   gabor.bajko@nokia.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 11/19/08                  [Page 8]