[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-melia-mipshop-mstp-solution) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5677

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                     CISCO
Intended status: Standards Track                                G. Bajko
Expires: January 11, 2009                                          Nokia
                                                                  S. Das
                                             Telcordia Technologies Inc.
                                                               N. Golmie
                                                                    NIST
                                                              JC. Zuniga
                                        InterDigital Communications, LLC
                                                           July 10, 2008


               Mobility Services Framework Design (MSFD)
                  draft-ietf-mipshop-mstp-solution-05

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 January 11, 2009.

Abstract

   This document describes a mobility services framework design (MSFD)
   for the IEEE 802.21 Media Independent Handover (MIH) protocol that
   addresses identified issues associated with the transport of MIH
   messages.  The document also describes mechanisms for mobility
   service (MoS) discovery and transport layer mechanisms for the



Melia, et al.           Expires January 11, 2009                [Page 1]


Internet-Draft                    MSFD                         July 2008


   reliable delivery of MIH messages.

Requirements Language

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Scenario S1: Home Network MoS  . . . . . . . . . . . . . .  6
     3.2.  Scenario S2: Visited Network MoS . . . . . . . . . . . . .  6
     3.3.  Scenario S3: Third party MoS . . . . . . . . . . . . . . .  7
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 10
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  MoS Discovery when MN and MoSh are in the home network
           (Scenario S1)  . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  MoS Discovery when MN is in visited network and MoSv
           is also in visited network (Scenario S2) . . . . . . . . . 12
     5.3.  MoS discovery when MIH services are in a 3rd party
           remote network (scenario S3) . . . . . . . . . . . . . . . 12
   6.  MIH Transport Options  . . . . . . . . . . . . . . . . . . . . 13
     6.1.  MIH Message size . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  MIH Message rate . . . . . . . . . . . . . . . . . . . . . 15
     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 15
     6.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 16
     6.5.  General guidelines . . . . . . . . . . . . . . . . . . . . 16
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   11. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     11.1. Roaming MoS  . . . . . . . . . . . . . . . . . . . . . . . 20
     11.2. MOS Discovery when the MN is in a visited Network and
           Services are at the Home network . . . . . . . . . . . . . 21
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     12.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27





Melia, et al.           Expires January 11, 2009                [Page 2]


Internet-Draft                    MSFD                         July 2008


1.  Introduction

   This document proposes a solution to the issues identified in the
   problem statement document [RFC5164] for the layer 3 transport of
   IEEE 802.21 MIH protocols.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of a node that supports specific Mobility Services (MoS)
   and the transport of the information between a mobile node (MN) and
   the discovered node.  The discovery process is required for the MN to
   obtain the information needed for MIH protocol communication with a
   peer node.  The information includes the transport address (e.g., the
   IP address) of the peer node and the types of MoS provided by the
   peer node.

   This document lists the major MoS deployment scenarios.  It describes
   the solution architecture, including the MSFD reference model and
   MIHF identifiers.  MoS discovery procedures explain how the MN
   discovers MoS in its home network, in a visited network or in a third
   party network.  The remainder of this document describes the MIH
   transport architecture, example message flows for several signaling
   scenarios, and security issues.


2.  Terminology

   The following acronyms and terminology are used in this document:

   MIH  Media Independent Handover: the handover support architecture
      defined by the IEEE 802.21 working group that consists of the MIH
      Function (MIHF), MIH Network Entities and MIH protocol messages.

   MIHF  Media Independent Handover Function: a switching function that
      provides handover services including the Event Service (ES),
      Information Service (IS), and Command Service (CS), through
      service access points (SAPs) defined by the IEEE 802.21 working
      group [IEEE80221].

   MIHF User  An entity that uses the MIH SAPs to access MIHF services,
      and which is responsible for initiating and terminating MIH
      signaling.

   MIHFID  Media Independent Handover Function Identifier: an identifier
      required to uniquely identify the MIHF endpoints for delivering
      mobility services (MoS); it is implemented as either a FQDN or
      NAI.





Melia, et al.           Expires January 11, 2009                [Page 3]


Internet-Draft                    MSFD                         July 2008


   MoS  Mobility Services: those services, as defined in the MIH problem
      statement document [RFC5164] , which includes the MIH IS, CS, and
      ES services defined by the IEEE 802.21 standard.

   MoSh:  Mobility Services assigned in the mobile node's Home Network

   MoSv:  Mobility Services assigned in the Visited Network, which is
      any network other than the mobile node's home network

   MoS3:  Mobility Services assigned in a 3rd Party Network, which is a
      network that is neither the Home Network nor the current Visited
      Network.

   MN Mobile Node: an Internet device whose location changes, along with
      its point of connection to the network.

   MSTP  Mobility Services Transport Protocol: a protocol that is used
      to deliver MIH protocol messages from an MIHF to other MIH-aware
      nodes in a network.

   IS Information Service: a MoS that originates at the lower or upper
      layers of the protocol stack and sends information to the local or
      remote upper or lower layers of the protocol stack.  It can use
      secure or insecure ports to transport information elements (IEs)
      and information about various neighboring nodes.

   ES Event Service: a MoS that originates at a remote MIHF or the lower
      layers of protocol stack and sends information to the local MIHF
      or local higher layers.  The purpose of the ES is to report
      changes in link status (e.g.  Link Going Down messages) and
      transmission status.

   CS Command Service: a MoS that sends commands from the remote MIHF or
      local upper layers to the local lower layers of the protocol stack
      to switch links or to get link status.

   FQDN:  Fully-Qualified Domain Name: a complete domain name for a host
      on the Internet, consisting of a host name followed by a domain
      name (e.g. myexample.example.org)

   NAI  Network Access Identifier: the user ID that a user submits
      during network access authentication[RFC2486].  For mobile users,
      the NAI identifies the user and helps to route the authentication
      request message.







Melia, et al.           Expires January 11, 2009                [Page 4]


Internet-Draft                    MSFD                         July 2008


   NAT  Network Address Translator: A device that implements the Network
      Address Translation function described in [RFC3022], in which
      local or private network layer addresses are mapped to valid
      network addresses and port numbers.

   DHCP  Dynamic Host Configuration Protocol: a protocol described in
      [RFC2131] and [RFC3315] that allows Internet devices to obtain
      respectively IPv4 and IPv6 addresses, subnet masks, default
      gateway addresses, and other IP configuration information from
      DHCP servers.

   DNS  Domain Name System: a protocol described in [RFC1035] that
      translates domain names to IP addresses.

   AAA  Authentication, Authorization and Accounting: a set of network
      management services that respectively determine the validity of a
      user's ID, determine whether a user is allowed to use network
      resources, and track users' use of network resources.

   Home AAA  AAAh: an AAA server located on the MN's home network.

   Visited AAA  AAAv: an AAA server located in a visited network that is
      not the MN's home network.

   MIH ACK  MIH Acknowledgement Message: a MIH signaling message that a
      MIHF sends in response to an MIH message from a sending MIHF, when
      UDP is used as the MSTP.

   PoS  Point of Service, a network-side MIHF instance that exchanges
      MIH messages with a MN-based MIHF.

   NAS  Network Access Server: a server to which a MN initially connects
      when it is trying to gain a connection to a network and which
      determines whether the MN is allowed to connect to the NAS's
      network.

   UDP  User Datagram Protocol: a connectionless transport layer
      protocol used to send datagrams between a source and a destination
      at a given port, defined in RFC 768.

   TCP  Transmission Control Protocol: a stream-oriented transport layer
      protocol that provides a reliable delivery service with congestion
      control, defined in RFC 793.

   RTT  Round-Trip Time: an estimation of the time required for a
      segment to travel from a source to a destination and an
      acknowledgement to return to the source that is used by TCP in
      connection with timer expirations to determine when a segment is



Melia, et al.           Expires January 11, 2009                [Page 5]


Internet-Draft                    MSFD                         July 2008


      considered lost and should be resent.

   MTU  Maximum Transmission Unit: the largest size packet that can be
      sent on a network without requiring fragmentation [RFC1191].

   PMTU  Path MTU.

   TLS  Transport Layer Security Protocol: an application layer protocol
      that assures privacy and data integrity between two communicating
      network entities [RFC4346].

   SMSS  Sender Maximum Segment Size: size of the largest segment that
      the sender can transmit as per [RFC2581]


3.  Deployment Scenarios

   This section describes the various possible deployment scenarios for
   the MN and the MoS.  The relative positioning of MN and MoS affects
   MoS discovery as well as the performance of the MIH signaling
   service.

3.1.  Scenario S1: Home Network MoS

   In this scenario, the MN and the services are located in the home
   network.  We refer to this set of services as MoSh as in Figure 1.
   The MoSh can be located at the access network the MN uses to connect
   to the home network, or it can be located elsewhere.

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

                     Figure 1: MoS in the Home network

3.2.  Scenario S2: Visited Network MoS

   In this scenario, the MN is in the visited network and mobility
   services are provided by the visited network.  We refer to this as
   MoSv as shown in Figure 2.





Melia, et al.           Expires January 11, 2009                [Page 6]


Internet-Draft                    MSFD                         July 2008


             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/
    +====+ +-----------------+
    |MoSv| | VISITED NETWORK |
    +====+ +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                   Figure 2: MoSV in the Visited Network

3.3.  Scenario S3: Third party MoS

   In this scenario, the MN is in its home network or in a visited
   network and services are provided by a 3rd party network.  We refer
   to this situation as MoS3 as shown in Figure 3.  (Note that MoS can
   exist both in home and in visited networks).

                                      +--------------+
                                      | HOME NETWORK |
   +====+    +--------------+         +--------------+
   |MoS3|    | THIRD PARTY  |  <===>        /\
   +====+    +--------------+               ||
                                            \/
                                    +-----------------+
                                    | VISITED NETWORK |
                                    +-----------------+
                                            /\
                                            ||
                                            \/
                                        +--------+
                                        |   MN   |
                                        +--------+

                     Figure 3: MoS form a third party

   Different types of MoS can be provided independently of other types
   and there is no strict relationship between ES, CS and IS, nor is
   there a requirement that the entities that provide these services
   should be co-located.  However, while IS tends to involve a large
   amounts of static information, ES and CS are dynamic services and



Melia, et al.           Expires January 11, 2009                [Page 7]


Internet-Draft                    MSFD                         July 2008


   some relationships between them can be expected, e.g., a handover
   command (CS) could be issued upon reception of a link event (ES).
   This document does not make any assumption on the location of the MoS
   (although there might be some preferred configurations), and aims at
   flexible MSFD to discover different services in different locations
   to optimize handover performance.  MoS discovery is discussed in more
   detail in Section 5.


4.  Solution Overview

   As mentioned in Section 1, the solution space is being divided into
   two functional domains: discovery and transport.  The following
   assumptions have been made:

   o  The solution is aimed at supporting IEEE 802.21 MIH services,
      namely Information Service (IS), Event Service (ES), and Command
      Service (CS).

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.

   o  The solutions are chosen to cover all possible deployment
      scenarios as described in Section 3.

   o  MoS discovery can be performed during initial network attachment
      or at any time thereafter.

   The MN may know the realm of the MoS to be discovered.  The MN may
   also be pre-configured with the address of the MoS to be used.  In
   case the MN does not know what realm/MoS to query dynamic assignment
   methods are described in Section 5.

   The discovery of the MoS (and the related configuration at MIHF
   level) is required to bind two MIHF peers (e.g.  MN and MoS) with
   their respective IP addresses.  Discovery MUST be executed in the
   following conditions:

   o  Bootstrapping: upon successful layer 2 network attachment the MN
      MAY be required to use DHCP for address configuration.  These
      procedures can carry the required information for MoS
      configuration in specific DHCP options.

   o  If the MN does not receive MoS information during network
      attachment and the MN does not have a pre-configured MoS, it MUST
      run a discovery procedure upon initial IP address configuration.





Melia, et al.           Expires January 11, 2009                [Page 8]


Internet-Draft                    MSFD                         July 2008


   o  If the MN changes its IP address (e.g. upon handover) it MUST
      refresh MIHF peers binding (i.e.  MIHF registration process).  In
      case the MoS used is not suitable anymore (e.g. too large RTT
      experienced) the MN MAY need to perform a new discovery procedure.

   o  if the MN is a multi-homed device and it communicates with the
      same MoS via different IP addresses it MAY run discovery
      procedures if one of the IP addresses changes.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between MIH peers over a transport protocol such as UDP or
   TCP.  The usage of transport protocols is described in Section 6 and
   packing of the MIH messages does not require extra framing since the
   MIH protocol defined in [IEEE80221] already contains a length field.

4.1.  Architecture

   Figure 4 depicts the MSFD reference model and its components within a
   node.  The topmost layer is the MIHF user.  This set of applications
   consists of one or more MIH clients that are responsible for
   operations such as generating query and response, processing Layer 2
   triggers as part of the ES, and initiating and carrying out handover
   operations as part of the CS.  Beneath the MIHF user is the MIHF
   itself.  This function is responsible for MoS discovery, as well as
   creating, maintaining, modifying, and destroying MIH signaling
   associations with other MIHFs located in MIH peer nodes.  Below the
   MIHF are various transport layer protocols as well as address
   discovery functions.























Melia, et al.           Expires January 11, 2009                [Page 9]


Internet-Draft                    MSFD                         July 2008


    +--------------------------+
    |       MIHF User          |
    +--------------------------+
                 ||
    +--------------------------+
    |           MIHF           |
    +--------------------------+
        ||         ||       ||
        ||      +------+ +-----+
        ||      | DHCP | | DNS |
        ||      +------+ +-----+
        ||         ||       ||
    +--------------------------+
    |         TCP/UDP          |
    +--------------------------+

                            Figure 4: MN stack

   The MIHF relies on the services provided by TCP and UDP for
   transporting MIH messages, and relies on DHCP and DNS for peer
   discovery.  In cases where the peer MIHF IP address is not pre-
   configured, the source MIHF needs to discover it either via DHCP or
   DNS or a combination of both as described in Section 5.  Once the
   peer MIHF is discovered, MIHF must exchange messages with its peer
   over either UDP or TCP.  Specific recommendations regarding the
   choice of transport protocols are provided in Section 6.

   There are no security features currently defined as part of the MIH
   protocol level.  However, security can be provided either at the
   transport or IP layer where it is necessary.  Section 8 provides
   guidelines and recommendations for security.

4.2.  MIHF Identifiers (FQDN, NAI)

   MIHFID is an identifier required to uniquely identify the MIHF end
   points for delivering the mobility services (MoS).  Thus an MIHF
   identifier needs to be unique within a domain where mobility services
   are provided and independent of the configured IP addresse(s).  An
   MIHFID MUST be represented either in the form of an FQDN [RFC2181] or
   NAI [RFC4282].  An MIHFID can be pre-configured or discovered through
   the discovery methods described in Section 5.


5.  MoS Discovery

   The MoS discovery method depends on whether the MN attempts to
   discover an MoS in the home network, in the visited network, or in a
   3rd party remote network that is neither the home network nor the



Melia, et al.           Expires January 11, 2009               [Page 10]


Internet-Draft                    MSFD                         July 2008


   visited network.  In the case the MN has already a MoS address pre-
   configured it is not necessary to run the discovery procedure.  If
   the MN does not have pre-configured MoS the following applies.

   In the case where MoS is provided locally (scenarios S1 and S2) , the
   discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options]
   and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as
   described in Section 5.1 and Section 5.2

   In the case where MoS is provided in the home network while the MN is
   in the visited network, the DNS based discovery described in
   [I-D.ietf-mipshop-mos-dns-discovery] is applicable.

   In the case where MoS is provided by a third party network which is
   different from the current visited network (scenario S3), only the
   DNS based discovery method described in
   [I-D.ietf-mipshop-mos-dns-discovery] is applicable.

   It should be noted that authorization of a MN to use a specific MoS
   server is neither in scope of this document nor is currently
   specified in [IEEE80221].  We further assume all devices can access
   discovered MoS.  In case future deployments will implement
   authorization policies the mobile nodes should fall back to other
   learned MoS if authorization is denied.

5.1.  MoS Discovery when MN and MoSh are in the home network (Scenario
      S1)

   To discover an MoS in the home network, the MN SHOULD use the DNS
   based MoS discovery method described in
   [I-D.ietf-mipshop-mos-dns-discovery].  In order to use that
   mechanism, the MN MUST have the home domain pre-configured in the MNs
   (i.e. subscription is tied to a network).  The DNS query option is
   shown in Figure 5a.  Alternatively, the MN MAY use the DHCP options
   for MoS discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown
   inFigure 5b (in some deployments DHCP relay may not be present).















Melia, et al.           Expires January 11, 2009               [Page 11]


Internet-Draft                    MSFD                         July 2008


                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                MN@xyz.com

                             (a) using DNS Query



                            +-----+      +------+
               +----+       |     |      |DHCP  |
               | MN |<----->| DHCP|<---->|Server|
               +----+       |Relay|      |      |
                            +-----+      +------+


                             (b)  Using DHCP Option

    Figure 5: MOS Discovery (a) Using DNS query, (b) using DHCP option

5.2.  MoS Discovery when MN is in visited network and MoSv is also in
      visited network (Scenario S2)

   To discover an MoS in the visited network, the MN SHOULD attempt to
   use the DHCP options for MoS discovery
   [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 6.

                            +-----+      +------+
               +----+       |     |      |DHCP  |
               | MN |<----->| DHCP|<---->|Server|
               +----+       |Relay|      |      |
                            +-----+      +------+


                      MoS Discovery using DHCP options

                   Figure 6: Discovery using DHCP option

5.3.  MoS discovery when MIH services are in a 3rd party remote network
      (scenario S3)

   To discover an MoS in a remote network other than home network, the
   MN MUST use the DNS based MoS discovery method described in
   [I-D.ietf-mipshop-mos-dns-discovery].  The MN MUST first learn the
   domain name of the network containing the MoS it is searching for.
   The MN can query its current MoS to find out the domain name of a



Melia, et al.           Expires January 11, 2009               [Page 12]


Internet-Draft                    MSFD                         July 2008


   specific network or the domain name of a network at a specific
   location (as in Figure 7 part (a), IEEE 802.21 defines information
   elements such as OPERATOR ID and SERVICE PROVIDER ID which can be a
   domain name.  An IS query can provide this information, see
   [IEEE80221]).

   Alternatively, the MN MAY query a MoS previously known to learn the
   domain name of the desired network .  Finally, the MN MUST use DNS
   queries to find MoS in the remote network as inFigure 7 part(b).  It
   should be noted that step c can only be performed upon obtaining the
   domain name of the remote network.


                               +------------+
                +----+         |            |
                |    |         |Information |
                | MN |-------->| Server     |
                |    |         |(previously |
                +----+         |discovered) |
                               +------------+

      (a) Using IS query to find the FQDN on the remote network

                                 +-------+
                  +----+         |Domain |
                  | MN |-------->|Name   |
                  +----+         |Server |
                                 +-------+
                   MN@xyz.com

            (b) using DNS Query in the remote network

   Figure 7: MOS Discovery using (a) IS Query to a known IS Server, (b)
                                 DNS Query


6.  MIH Transport Options

   Once the Mobility Services have been discovered, MIH peers run a
   capability discovery and subscription procedures as specified in
   [IEEE80221].  MIH peers MAY exchange information over TCP, UDP or any
   other transport supported by both the server and the client.  The
   client MAY use the DNS discovery mechanism to discover which
   transport protocols are supported by the server in addition to TCP
   and UDP that are recommended in this document.  While either protocol
   can provide the basic transport functionality required, there are
   performance trade-offs and unique characteristics associated with
   each that need to be considered in the context of the MIH services



Melia, et al.           Expires January 11, 2009               [Page 13]


Internet-Draft                    MSFD                         July 2008


   for different network loss and congestion conditions.  The objectives
   of this section are to discuss these trade-offs for different MIH
   settings such as the MIH message size and rate, and the
   retransmission parameters.  In addition, factors such as NAT
   traversal are also discussed.  Given the reliability requirements for
   the MIH transport, it is assumed in this discussion that the MIH ACK
   mechanism is to be used in conjunction with UDP, while it is
   preferred to avoid using MIH ACKs with TCP since TCP includes
   acknowledgement and retransmission functionality.

6.1.  MIH Message size

   Although the MIH message size varies widely from about 30 bytes (for
   a capability discovery request) to around 65000 bytes (for an IS
   MIH_Get_Information response primitive), a typical MIH message size
   for the ES/CS service ranges between 50 to 100 bytes [IEEE80221].
   Thus, considering the effects of the MIH message size on the
   performance of the transport protocol brings us to discussing two
   main issues, related to fragmentation of long messages in the context
   of UDP and the concatenation of short messages in the context of TCP.

   Since transporting long MIH messages may require fragmentation that
   is not available in UDP, if MIH is using UDP a limit MUST be set on
   the size of the MIH message based on the path MTU to destination (or
   the minimum where PMTU is not implemented).  The minimum PMTU depends
   on the IP version used for transmission, and is the lesser of 576
   bytes for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460], although
   applications may reduce these values to guard against the presence of
   tunnels.

   It should be noted that MIH layer fragmentation MUST NOT be used
   together with IP layer fragmentation as specified in [IEEE80221].

   The loss of an IP fragment leads to the retransmission of an entire
   MIH message, which in turn leads to poor end-to-end delay performance
   in addition to wasted bandwidth.  Additional recommendations in
   [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the
   MIH message when using UDP and assuming IP layer fragmentation.  In
   terms of dealing with short messages, TCP has the capability to
   concatenate very short messages in order to reduce the overall
   bandwidth overhead.  However, this reduced overhead comes at the cost
   of additional delay to complete an MIH transaction, which may not be
   acceptable for CS and ES services.  Note also that TCP is a stream
   oriented protocol and measures data flow in terms of bytes, not
   messages.  Thus it is possible to split messages across multiple TCP
   segments if they are long enough.  Even short messages can be split
   across two segments.  This can also cause unacceptable delays,
   especially if the link quality is severely degraded as is likely to



Melia, et al.           Expires January 11, 2009               [Page 14]


Internet-Draft                    MSFD                         July 2008


   happen when the MN is exiting a wireless access coverage area.  The
   use of the PUSH bit can alleviate this problem by triggering
   transmission of a segment less than the SMSS.

6.2.  MIH Message rate

   The frequency of MIH messages varies according to the MIH service
   type.  It is expected that CS/ES message arrive at a rate of one in
   hundreds of milliseconds in order to capture quick changes in the
   environment and/ or process handover commands.  On the other hand, IS
   messages are exchanged mainly every time a new network is visited
   which may be in order of hours or days.  Therefore a burst of either
   short CS/ES messages or long IS message exchanges (in the case where
   multiple MIH nodes request information) may lead to network
   congestion.  While the built-in rate-limiting controls available in
   TCP may be well suited for dealing with these congestion conditions,
   this may result in large transmission delays that may be unacceptable
   for the timely delivery of ES/CS messages.  On the other hand, if UDP
   is used, a rate-limiting effect similar to the one obtained with TCP
   may be obtained by adequately adjusting the parameters of a token
   bucket regulator as defined in the MIH specifications [IEEE80221].
   Recommendations for token bucket parameter settings are as follow:

   o  If MIHF knows the RTT, the rate can be based upon this

   o  If not, then on average it SHOULD NOT send more than one UDP
      message every 3 seconds.

6.3.  Retransmission

   For TCP, the retransmission timeout is adjusted according to the
   measured RTT.  However due to the exponential backoff mechanism, the
   delay associated with retransmission timeouts may increase
   significantly with increased packet loss.

   If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.
   An MIH message is retransmitted if its corresponding MIH ACK is not
   received by the generating node within a timeout interval set by the
   MIHF.  This approach does not include an exponential backoff and
   therefore tends to degrade more gracefully than TCP when the packet
   loss rate becomes large, in the sense that the expected delay does
   not increase exponentially.  The number of retransmissions is
   limited, which reduces head-of-line blocking of other MIH messages,
   but this can cause important ES/CS messages to be lost.  The default
   number of retransmissions is set to 2 and retransmissions are
   controlled by a timer with a default value of 10s.  No backoff
   mechanism is specified.




Melia, et al.           Expires January 11, 2009               [Page 15]


Internet-Draft                    MSFD                         July 2008


6.4.  NAT Traversal

   There are no known issues for NAT traversal when using TCP.  The
   default connection timeout of 24 hours is considered adequate for MIH
   transport purposes.  However, issues with NAT traversal using UDP are
   documented in [I-D.ietf-tsvwg-udp-guidelines].  Communication
   failures are experienced when middleboxes destroy the per-flow state
   associated with an application session during periods when the
   application does not exchange any UDP traffic.  Hence, communication
   between the MN and the MoS SHOULD be able to gracefully handle such
   failures and implement mechanisms to re-establish their UDP sessions.
   In addition and in order to avoid such failures, MIH messages MAY be
   sent periodically, similarly to keep-alive messages, to attempt to
   refresh middlebox state.  As [RFC4787] requires a minimum state
   timeout of two minutes or more, MIH messages using UDP as transport
   SHOULD be sent once every two minutes.  Re-registration or Event
   indication messages as defined in [IEEE80221] MAY be used for this
   purpose.

6.5.  General guidelines

   Since ES and CS messages are small in nature and have tight latency
   requirements, UDP in combination with MIH acknowledgement SHOULD be
   used for transporting ES and CS messages.  On the other hand, IS
   messages are more resilient in terms of latency constraints and some
   long IS messages could exceed the MTU of the path to the destination.
   Therefore, TCP SHOULD be used for transporting IS messages.  For both
   UDP and TCP cases, if a port number is not explicitly assigned (e.g.
   by the DNS SRV), MIH messages sent over UDP, TCP or other supported
   transport MUST use the default port number defined for that
   particular transport.

   MoS server MUST support both UDP and TCP for MIH transport and the MN
   MUST support TCP.  Additionally, the server and MN MAY support
   additional transport mechanisms.  The MN MAY use the procedures
   defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover
   additional transport protocols supported by the server.


7.  Operation Flows

   Figure 8 gives an example operation flow between MIHF peers when an
   MIH user requests an IS service and both the MN and the MoS are in
   the MN's home network.  DHCP is used for MoS discovery and TCP is
   used for establishing a transport connection to carry the IS
   messages.  When MoS is not pre-configured, the MIH user needs to
   discover the IP address of MoS to communicate with the remote MIHF.
   Therefore the MIH user sends a discovery request message to the local



Melia, et al.           Expires January 11, 2009               [Page 16]


Internet-Draft                    MSFD                         July 2008


   MIHF as defined in [IEEE80221].

   In this example (one could draw similar mechanisms with DHCPv6), we
   assume that MoS discovery is performed before a transport connection
   is established with the remote MIHF, and the DHCP client process is
   invoked via some internal APIs.  DHCP Client sends DHCP INFORM
   message according to standard DHCP and with the MoS option as defined
   in [I-D.ietf-mipshop-mos-dhcp-options].  DHCP server replies via DHCP
   ACK message with the IP address of the MoS.  The MoS address is then
   passed to the MIHF locally via some internal APIs.  MIHF generates
   the discovery response message and passes it on to the corresponding
   MIH user.  The MIH user generates an IS query addressed to the remote
   MoS.  MIHF invokes the underlying TCP client which establishes a
   transport connection with the remote peer.  Once the transport
   connection is established, MIHF sends the IS query via MIH protocol
   REQUEST message.  The message and query arrive at the destination
   MIHF and MIH user respectively.  The MoS MIH user responds to the
   corresponding IS query and the MoS MIHF sends the IS response via MIH
   protocol RESPONSE message.  The message arrives at the source MIHF
   which passes the IS response on to the corresponding MIH user.

                MN                                             MoS
|===================================|    |======|  |===================|
+ ---------+                                                + ---------+
| MIH USER |       +------+  +------+    +------+  +------+ | MIH USER |
| +------+ |       | TCP  |  |DHCP  |    |DHCP  |  | TCP  | | +------+ |
| | MIHF | |       |Client|  |Client|    |Server|  |Server| | | MIHF | |
+----------+       +------+  +------+    +------+  +------+ +----------+
    |                 |         |           |         |          |
    |MIH Discovery    |         |           |         |          |
    |Request          |         |           |         |          |
    |(MIH User-> MIHF)|         |           |         |          |
    |======>          |         |           |         |          |
    |                 |         |           |         |          |
    |Invoke DHCP Client         |           |         |          |
    |(Internal process with MoS)|DHCP INFORM|         |          |
    |==========================>|==========>|         |          |
    |                 |         |           |         |          |
    |                 |         |           |         |          |
    |                 |         |  DHCP ACK |         |          |
    |                 |         |<==========|         |          |
    |    Inform MoS address     |           |         |          |
    |<==========================|           |         |          |
    |    (internal process)     |           |         |          |
    |                           |           |         |          |
    |Discovery        |         |           |         |          |
    |Response         |         |           |         |          |
    |<======          |         |           |         |          |



Melia, et al.           Expires January 11, 2009               [Page 17]


Internet-Draft                    MSFD                         July 2008


    |(MIH User<- MIHF)|         |           |         |          |
    |                 |         |           |         |          |
    |IS Query         |         |           |         |          |
    |=======>         |         |           |         |          |
    |(MIH User-> MIHF)|         |           |         |          |
    |                 |         |           |         |          |
    |Invoke TCP Client|         |           |         |          |
    |================>|         |           |         |          |
    |(Internal process|         |           |         |          |
    |with MOS)        |         |           |         |          |
    |                 |         |           |         |          |
    |                 |  TCP connection established   |          |
    |                 |<=============================>|          |
    |                 |         |           |         |          |
    |                 |         |           |         |          |
    |                 |         |           |         |          |
    |                 IS  QUERY REQUEST (via MIH protocol)       |
    |===========================================================>|
    |                 |         |           |         |          |
    |                 |         |           |         |          |
    |                 |         |           |         |          |
    |                 |         |           |         |  IS QUERY|
    |                 |         |           |         |   REQUEST|
    |                 |         |           |         |    =====>|
    |                 |         |           |   (MIHF-> MIH User)|
    |                 |         |           |         |          |
    |                 |         |           |         |     QUERY|
    |                 |         |           |         |  RESPONSE|
    |                 |         |           |         |    <=====|
    |                 |         |           |  (MIHF <-MIH User) |
    |                 |         |           |         |          |
    |                 | IS QUERY RESPONSE (via MIH protocol)     |
    |<===========================================================|
    |                 |         |           |         |          |
    |    IS           |         |           |         |          |
    |RESPONSE         |         |           |         |          |
    |<========        |         |           |         |          |
    |(MIH User <-MIHF)|         |           |         |          |
    |                 |         |           |         |          |

          Figure 8: Example Flow of Operation Involving MIH User


8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [RFC5164]



Melia, et al.           Expires January 11, 2009               [Page 18]


Internet-Draft                    MSFD                         July 2008


   In the case where DHCP is used for node discovery and authentication
   of the source and content of DHCP messages is required, network
   administrators SHOULD use DHCP authentication option described in
   [RFC3118], where available or rely upon link layer security.  This
   will also protect the DHCP server against denial of service attacks
   to.  [RFC3118] provides mechanisms for both entity authentication and
   message authentication.

   In the case where DNS is used for discovering MoS, fake DNS requests
   and responses may cause DoS and the inability of the MN to perform a
   proper handover, respectively.  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].
   Readers may also refer to [RFC4641] to consider the aspects of DNSSEC
   Operational Practices.

   In the case where reliable transport protocol such as TCP is used for
   transport connection between two MIHF peers, TLS [RFC4346] with
   server-side certificates SHOULD be used for server only
   authentication, message confidentiality and data integrity.  Certain
   subscriptions may include client certificates, and in those cases
   servers MAY require the clients to authenticate themselves using
   client-side certificates.  Readers should also follow the
   recommendations in [RFC4366] that provides generic extension
   mechanisms for the TLS protocol suitable for wireless environments.

   In the case where unreliable transport protocol such as UDP is used
   for transport connection between two MIHF peers, DTLS [RFC4347]
   SHOULD be used for message confidentiality and data integrity.  The
   DTLS protocol is based on the Transport Layer Security (TLS) protocol
   and provides equivalent security guarantees.


9.  IANA Considerations

   This document registers the following TCP and UDP port(s) with IANA:















Melia, et al.           Expires January 11, 2009               [Page 19]


Internet-Draft                    MSFD                         July 2008


    Keyword       Decimal           Description
    -------       -------           -----------
    ieee-mih-IS   TBD_BY_IANA/tcp   MIH Information Services
    ieee-mih-IS   TBD_BY_IANA/udp   MIH Information Services
    ieee-mih-ES   TBD_BY_IANA/tcp   MIH Event Services
    ieee-mih-ES   TBD_BY_IANA/udp   MIH Event Services
    ieee-mih-CS   TBD_BY_IANA/tcp   MIH Command Services
    ieee-mih-CS   TBD_BY_IANA/udp   MIH Command Services


10.  Acknowledgements

   The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin
   Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their
   valuable comments, reviews and fruitful discussions.


11.  Appendix A

   In case any network provider wants to provision a roaming MN with the
   name of an MoS at home, it could do so if it defines the required
   DHCP options and required DHCP-AAA interface.  This annex is provided
   to help future standardisation work, if need arises.

   Similarly to what is specified in
   [I-D.ietf-mip6-bootstrapping-integrated-dhc], DHCP based discovery
   method requires an interaction between the DHCP and the AAA
   infrastructure and it assumes that MoS assignment is performed during
   access authentication and authorization.

11.1.  Roaming MoS

   In this scenario, the MN is located in the visited network and all
   MIH services are provided by the home network, as shown in Figure 9.

















Melia, et al.           Expires January 11, 2009               [Page 20]


Internet-Draft                    MSFD                         July 2008


    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

            Figure 9: MoS provided by the home while in visited

11.2.  MOS Discovery when the MN is in a visited Network and Services
       are at the Home network

   To discover an MoS in the visited network when MIH services are
   provided by the home network, both the DNS based discovery method
   described in [I-D.ietf-mipshop-mos-dns-discovery] and the DHCP based
   discovery method described in [I-D.ietf-mipshop-mos-dhcp-options] are
   applicable.

   To discover the MoS at home while in a visited network using DNS, the
   MN SHOULD use the procedures described in Section 5.1

   Alternatively, the MN MAY also use the DHCP based discovery method.
   Using the DHCP based discovery may be required in deployments where
   the usage of MoS located in the home network is enforced and included
   in the subscription profile.  Similar to
   [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated
   scenario the mobile node is required to perform network access
   authentication before it can obtain the MoS information.  This allows
   for MoS discovery at the time of access authentication.  Also, the
   mechanism defined in this document requires the NAS to support MIH
   specific AAA attributes and a collocated DHCP relay agent.  How the
   MoS information is delivered to the NAS is out of scope of this
   document.  One mechanism for this would be to use Diameter extensions
   to deliver the MoS information to the NAS when the mobile node
   performs access authentication with the NAS as described in
   [I-D.stupar-dime-mos-options].

   In these deployment scenarios the AAAh sends the MoS address at home
   to the AAAv during the network access authentication.  The relation



Melia, et al.           Expires January 11, 2009               [Page 21]


Internet-Draft                    MSFD                         July 2008


   between functional components supporting such procedure is shown in
   Figure 10.

   This Annex describes, as example, how the procedure work for the IPv6
   case.  Draft [I-D.ietf-mipshop-mos-dhcp-options] contains the
   necessary specifications also for the IPv4 case.

   The mobile node executes the network access authentication procedure
   (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS.  The NAS
   is in the visited and it interacts with AAAh via AAAv to authenticate
   the mobile node.  Optionally, in the process of authorizing the
   mobile node, the AAAh could verify in the AAA profile that the mobile
   node is allowed to use MoS services.  The AAAh assigns the MoS in the
   home and returns this information to the NAS.  The NAS may keep the
   received information for a configurable duration or it may keep the
   information for as long as the MN is connected to the NAS.

   The mobile node sends a DHCPv6 Information Request message [RFC3315]
   to the All_DHCP_Relay_Agents_and_Servers multicast address.  In this
   message the mobile node (DHCP client) MUST include the Option Code
   for MoS Identifier Option [I-D.ietf-mipshop-mos-dhcp-options] in the
   OPTION_ORO.  The mobile node MUST also include the OPTION_CLIENTID to
   identify itself to the DHCP server.

   The Relay Agent intercepts the Information-request from the mobile
   node and forwards it to the DHCP server.  The Relay Agent also
   includes the received MoS information from the AAAh in the IPv6 Relay
   Agent MoS Option [I-D.ietf-mipshop-mos-dhcp-options].  If a NAS
   implementation does not store the received information as long as the
   MN's session remains in the visited network, and if the MN delays
   sending DHCP request, the NAS/DHCP relay does not include the IPv6
   Relay Agent MoS Option in the Relay Forward message.

   The DHCP server identifies the client by looking at the DUID for the
   client in the OPTION_CLIENTID.  The DHCP server determines that the
   MoS is allocated by the AAAh by looking at the IPv6 Relay Agent Sub-
   Option in the IPv6 Relay Agent MoS Option.  The DHCP server extracts
   the allocated MoS information from the IPv6 Relay Agent Sub-Option
   and includes it in the MoS Information Option
   [I-D.ietf-mipshop-mos-dhcp-options] in the Reply Message.  If the
   requested information is not available in the DHCP server, it follows
   the behavior described in [RFC3315].

   The Relay Agent relays the Reply Message from the DHCP server to the
   mobile node.  At this point, the mobile node has the MoS information
   that it requested.

   In should be noted, that using the DHCP Options and procedures



Melia, et al.           Expires January 11, 2009               [Page 22]


Internet-Draft                    MSFD                         July 2008


   defined in [I-D.ietf-mipshop-mos-dhcp-options] the MN can not specify
   the network (local or home) where it wants the MoS address from.
   Whether the MN receives an MoS address from local or home network
   will depend on the actual network deployment (scenario S2 or S3) and
   operator policy.  In an integrated scenario, where the network access
   authentication is performed by the home network the MoS information
   will be always sent to the AAAv, then stored in the relay agent and
   ultimately sent to the MN if the MN asks for it, using the procedures
   defined in [I-D.ietf-mipshop-mos-dhcp-options].


                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |
                           |AAAV   |-----------|--------|AAAH   |
                           |       |           |        |       |
                           |       |           |        |       |
                           +-------+           |        +-------+
                               |               |
                               |               |
                               |               |
                               |               |
                               |               |       +--------+
                               |               |       |        |
                               |               |       |  MoSh  |
                           +-----+    +------+ |       +--------+
               +----+      |     |    |DHCP  | |
               | MN |------| NAS/|----|Server| |
               +----+      | DHCP|    |      | |
                           |Relay|    |      | |
                           +-----+    +------+ |
                                               |


          AAAv -- Visited AAA
          AAAH -- Home AAA
          NAS  -- Network Access Server

   Figure 10: MOS Discovery using Network Access Authentication and DHCP
                                  options


12.  References






Melia, et al.           Expires January 11, 2009               [Page 23]


Internet-Draft                    MSFD                         July 2008


12.1.  Normative References

   [I-D.ietf-mipshop-mos-dhcp-options]
              Bajko, G. and S. Das, "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Options for Mobility  Server (MoS)
              discovery", draft-ietf-mipshop-mos-dhcp-options-03 (work
              in progress), June 2008.

   [I-D.ietf-mipshop-mos-dns-discovery]
              Bajko, G., "Locating Mobility Servers using DNS",
              draft-ietf-mipshop-mos-dns-discovery-01 (work in
              progress), May 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

12.2.  Informative References

   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
              Integrated Scenario",
              draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
              progress), April 2008.

   [I-D.ietf-tsvwg-udp-guidelines]
              Eggert, L. and G. Fairhurst, "Guidelines for Application
              Designers on Using Unicast UDP",
              draft-ietf-tsvwg-udp-guidelines-09 (work in progress),
              July 2008.

   [I-D.stupar-dime-mos-options]



Melia, et al.           Expires January 11, 2009               [Page 24]


Internet-Draft                    MSFD                         July 2008


              Korhonen, J. and T. Melia, "Diameter extensions for MoS
              discovery", draft-stupar-dime-mos-options-00 (work in
              progress), February 2008.

   [IEEE80221]
              "Draft IEEE Standard for Local and Metropolitan Area
              Networks: Media Independent Handover Services", IEEE LAN/
              MAN Draft  IEEE P802.21/D12.00, June 2008.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
              Control", RFC 2581, April 1999.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
              RFC 4641, September 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation



Melia, et al.           Expires January 11, 2009               [Page 25]


Internet-Draft                    MSFD                         July 2008


              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5164]  Melia, T., "Mobility Services Transport: Problem
              Statement", RFC 5164, March 2008.


Authors' Addresses

   Telemaco Melia (editor)
   CISCO

   Email: telemaco.melia@gmail.com


   Gabor Bajko
   Nokia

   Email: Gabor.Bajko@nokia.com


   Subir Das
   Telcordia Technologies Inc.

   Email: subir@research.telcordia.com


   Nada Golmie
   NIST

   Email: nada.golmie@nist.gov


   Juan Carlos Zuniga
   InterDigital Communications, LLC

   Email: j.c.zuniga@ieee.org














Melia, et al.           Expires January 11, 2009               [Page 26]


Internet-Draft                    MSFD                         July 2008


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.











Melia, et al.           Expires January 11, 2009               [Page 27]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/