doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc5677.txt b/doc/rfc/rfc5677.txt
new file mode 100644
index 0000000..63f14a9
--- /dev/null
+++ b/doc/rfc/rfc5677.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                      T. Melia, Ed.
+Request for Comments: 5677                                Alcatel-Lucent
+Category: Standards Track                                       G. Bajko
+                                                                   Nokia
+                                                                  S. Das
+                                             Telcordia Technologies Inc.
+                                                               N. Golmie
+                                                                    NIST
+                                                              JC. Zuniga
+                                        InterDigital Communications, LLC
+                                                           December 2009
+
+
+         IEEE 802.21 Mobility Services Framework Design (MSFD)
+
+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
+   Services (MoS) discovery and transport-layer mechanisms for the
+   reliable delivery of MIH messages.  This document does not provide
+   mechanisms for securing the communication between a mobile node (MN)
+   and the Mobility Server.  Instead, it is assumed that either lower-
+   layer (e.g., link-layer) security mechanisms or overall system-
+   specific proprietary security solutions are used.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+IESG Note
+
+   As described later in this specification, this protocol does not
+   provide security mechanisms.  In some deployment situations lower-
+   layer security services may be sufficient.  Other situations require
+   proprietary mechanisms or as yet incomplete standard mechanisms, such
+   as the ones currently considered by IEEE.  For these reasons, the
+   specification recommends careful analysis before considering any
+   deployment.
+
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 1]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   The IESG emphasizes the importance of these recommendations.  The
+   IESG also notes that this specification deviates from the traditional
+   IETF requirement that support for security in the open Internet
+   environment is a mandatory part of any Standards Track protocol
+   specification.  An exception has been made for this specification,
+   but this should not be taken to mean that other future specifications
+   are free from this requirement.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 2]
+
+RFC 5677                          MSFD                     December 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................4
+      2.1. Requirements Language ......................................7
+   3. Deployment Scenarios ............................................7
+      3.1. Scenario S1: Home Network MoS ..............................8
+      3.2. Scenario S2: Visited Network MoS ...........................8
+      3.3. Scenario S3: Third-Party MoS ...............................9
+      3.4. Scenario S4: Roaming MoS ...................................9
+   4. Solution Overview ..............................................10
+      4.1. Architecture ..............................................11
+      4.2. MIHF Identifiers (FQDN, NAI) ..............................12
+   5. MoS Discovery ..................................................12
+      5.1. MoS Discovery When MN and MoSh Are in the Home
+           Network (Scenario S1) .....................................13
+      5.2. MoS Discovery When MN and MoSv Both Are in Visited
+           Network (Scenario S2) .....................................14
+      5.3. MoS Discovery When MIH Services Are in a
+           Third-Party Remote Network (Scenario S3) ..................14
+      5.4. MoS Discovery When the MN Is in a Visited Network
+           and Services Are at the Home Network (Scenario S4) ........15
+   6. MIH Transport Options ..........................................15
+      6.1. MIH Message Size ..........................................16
+      6.2. MIH Message Rate ..........................................17
+      6.3. Retransmission ............................................17
+      6.4. NAT Traversal .............................................18
+      6.5. General Guidelines ........................................18
+   7. Operation Flows ................................................19
+   8. Security Considerations ........................................21
+      8.1. Security Considerations for MoS Discovery .................21
+      8.2. Security Considerations for MIH Transport .................21
+   9. IANA Considerations ............................................22
+   10. Acknowledgements ..............................................23
+   11. References ....................................................23
+      11.1. Normative References .....................................23
+      11.2. Informative References ...................................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 3]
+
+RFC 5677                          MSFD                     December 2009
+
+
+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 into 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 Mobility Servers 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.
+
+   This document does not provide mechanisms for securing the
+   communication between a mobile node and the Mobility Server.
+   Instead, it is assumed that either lower layer (e.g., link layer)
+   security mechanisms, or overall system-specific proprietary security
+   solutions, are used.  The details of such lower layer and/or
+   proprietary mechanisms are beyond the scope of this document.  It is
+   RECOMMENDED against using this protocol without careful analysis that
+   these mechanisms meet the desired requirements, and encourages future
+   standardization work in this area.  The IEEE 802.21a Task Group has
+   recently started work on MIH security issues that may provide some
+   solution in this area.  For further information, please refer to
+   Section 8.
+
+2.  Terminology
+
+   The following acronyms and terminology are used in this document:
+
+   Media Independent Handover (MIH): 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.
+
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 4]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   Media Independent Handover Function (MIHF): 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.
+
+   Media Independent Handover Function Identifier (MIHFID): an
+      identifier required to uniquely identify the MIHF endpoints for
+      delivering mobility services (MoS); it is implemented as either a
+      FQDN or NAI.
+
+   Mobility Services (MoS): composed of Information Service, Command
+      Service, and Event Service provided by the network to mobile nodes
+      to facilitate handover preparation and handover decision, as
+      described in [IEEE80221] and [RFC5164].
+
+   MoSh:  Mobility Services provided by the mobile node's Home Network.
+
+   MoSv:  Mobility Services provided by the Visited Network.
+
+   MoS3: Mobility Services provided by a third-party network, which is a
+      network that is neither the Home Network nor the current Visited
+      Network.
+
+   Mobile Node (MN): an Internet device whose location changes, along
+      with its point of connection to the network.
+
+   Mobility Services Transport Protocol (MSTP): a protocol that is used
+      to deliver MIH protocol messages from an MIHF to other MIH-aware
+      nodes in a network.
+
+   Information Service (IS): 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.  The purpose
+      of IS is to exchange information elements (IEs) relating to
+      various neighboring network information.
+
+   Event Service (ES): a MoS that originates at a remote MIHF or the
+      lower layers of the local 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 various lower layer events.
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 5]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   Command Service (CS): a MoS that sends commands from the remote MIHF
+      or local upper layers to the remote or local lower layers of the
+      protocol stack to switch links or to get link status.
+
+   Fully Qualified Domain Name (FQDN): a complete domain name for a host
+      on the Internet, showing (in reverse order) the full delegation
+      path from the DNS root and top-level domain down to the host name
+      (e.g., myexample.example.org).
+
+   Network Access Identifier (NAI): the user ID that a user submits
+      during network access authentication [RFC4282].  For mobile users,
+      the NAI identifies the user and helps to route the authentication
+      request message.
+
+   Network Address Translator (NAT): a device that implements the
+      Network Address Translation function described in [RFC3022], in
+      which local or private network layer addresses are mapped to
+      routable (outside the NAT domain) network addresses and port
+      numbers.
+
+   Dynamic Host Configuration Protocol (DHCP): protocols described in
+      [RFC2131] and [RFC3315] that allow Internet devices to obtain
+      respectively IPv4 and IPv6 addresses, subnet masks, default
+      gateway addresses, and other IP configuration information from
+      DHCP servers.
+
+   Domain Name System (DNS): a protocol described in [RFC1035] that
+      translates domain names to IP addresses.
+
+   Authentication, Authorization, and Accounting (AAA): 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 Acknowledgement (MIH ACK): an MIH signaling message that an MIHF
+      sends in response to an MIH message from a sending MIHF.
+
+   Point of Service (PoS): a network-side MIHF instance that exchanges
+      MIH messages with an MN-based MIHF.
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 6]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   Network Access Server (NAS): a server to which an MN initially
+      connects when it is trying to gain a connection to a network and
+      that determines whether the MN is allowed to connect to the NAS's
+      network.
+
+   User Datagram Protocol (UDP): a connectionless transport-layer
+      protocol used to send datagrams between a source and a destination
+      at a given port, defined in RFC 768.
+
+   Transmission Control Protocol (TCP): a stream-oriented transport-
+      layer protocol that provides a reliable delivery service with
+      congestion control, defined in RFC 793.
+
+   Round-Trip Time (RTT): 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
+      considered lost and should be resent.
+
+   Maximum Transmission Unit (MTU): the largest size of an IP packet
+      that can be sent on a network segment without requiring
+      fragmentation [RFC1191].
+
+   Path MTU (PMTU): the largest size of an IP packet that can be sent on
+      an end-to-end network path without requiring IP fragmentation.
+
+   Transport Layer Security Protocol (TLS): an application layer
+      protocol that primarily assures privacy and data integrity between
+      two communicating network entities [RFC5246].
+
+   Sender Maximum Segment Size (SMSS): size of the largest segment that
+      the sender can transmit as per [RFC5681].
+
+2.1.  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].
+
+3.  Deployment Scenarios
+
+   This section describes the various possible deployment scenarios for
+   the MN and the Mobility Server.  The relative positioning of the MN
+   and Mobility Server affects MoS discovery as well as the performance
+   of the MIH signaling service.  This document addresses the scenarios
+   listed in [RFC5164] and specifies transport options to carry the MIH
+   protocol over IP.
+
+
+
+Melia, et al.               Standards Track                     [Page 7]
+
+RFC 5677                          MSFD                     December 2009
+
+
+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 shown 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.
+
+                                  +--------------+
+                                  | HOME NETWORK |
+                                  +--------------+
+                                            /\
+                                            ||
+                                            \/
+                        +====+ +-----------------+
+                        |MoSv| | VISITED NETWORK |
+                        +====+ +-----------------+
+                                            /\
+                                            ||
+                                            \/
+                                      +--------+
+                                      |   MN   |
+                                      +--------+
+
+                   Figure 2: MoSv in the Visited Network
+
+
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                     [Page 8]
+
+RFC 5677                          MSFD                     December 2009
+
+
+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 third-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 from a Third Party
+
+3.4.  Scenario S4: 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 4.
+
+                    +====+   +--------------+
+                    |MoSh|   | HOME NETWORK |
+                    +====+   +--------------+
+                                   /\
+                                   ||
+                                   \/
+                          +-----------------+
+                          | VISITED NETWORK |
+                          +-----------------+
+                                   /\
+                                   ||
+                                   \/
+                               +--------+
+                               |   MN   |
+                               +--------+
+
+            Figure 4: MoS Provided by the Home While in Visited
+
+
+
+
+Melia, et al.               Standards Track                     [Page 9]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   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
+   amount of static information, ES and CS are dynamic services and 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 primarily 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 Mobility Server to be discovered.
+   The MN may also be pre-configured with the address of the Mobility
+   Server to be used.  In case the MN does not know what realm /
+   Mobility Server to query, dynamic assignment methods are described in
+   Section 5.
+
+   The discovery of the Mobility Server (and the related configuration
+   at MIHF level) is required to bind two MIHF peers (e.g., MN and
+   Mobility Server) 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.
+
+
+
+
+Melia, et al.               Standards Track                    [Page 10]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   o  If the MN does not receive MoS information during network
+      attachment and the MN does not have a pre-configured Mobility
+      Server, it MUST run a discovery procedure upon initial IP address
+      configuration.
+
+   o  If the MN changes its IP address (e.g., upon handover), it MUST
+      refresh MIHF peer bindings (i.e., MIHF registration process).  In
+      case the Mobility Server 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 Mobility Server 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 5 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.               Standards Track                    [Page 11]
+
+RFC 5677                          MSFD                     December 2009
+
+
+                    +--------------------------+
+                    |       MIHF User          |
+                    +--------------------------+
+                                 ||
+                    +--------------------------+
+                    |           MIHF           |
+                    +--------------------------+
+                        ||         ||       ||
+                        ||      +------+ +-----+
+                        ||      | DHCP | | DNS |
+                        ||      +------+ +-----+
+                        ||         ||       ||
+                    +--------------------------+
+                    |         TCP/UDP          |
+                    +--------------------------+
+
+                         Figure 5: 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 as described in Section 5.  Once the peer MIHF is discovered, the
+   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 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 address(es).  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 a Mobility Server in the home network, in the visited
+   network, or in a third-party remote network that is neither the home
+   network nor the visited network.  In the case where the MN already
+
+
+
+Melia, et al.               Standards Track                    [Page 12]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   has a Mobility Server address pre-configured, it is not necessary to
+   run the discovery procedure.  If the MN does not have pre-configured
+   Mobility Server, the following procedure applies.
+
+   In the case where a Mobility Server is provided locally (scenarios S1
+   and S2), the discovery techniques described in [RFC5678] and
+   [RFC5679] are both applicable as described in Sections 5.1 and 5.2.
+
+   In the case where a Mobility Server is located in the home network
+   while the MN is in the visited network (scenario S4), the DNS-based
+   discovery described in [RFC5679] is applicable.
+
+   In the case where a Mobility Server is located in a third-party
+   network that is different from the current visited network (scenario
+   S3), only the DNS-based discovery method described in [RFC5679] is
+   applicable.
+
+   It should be noted that authorization of an MN to use a specific
+   Mobility 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 a Mobility Server in the home network, the MN SHOULD use
+   the DNS-based MoS discovery method described in [RFC5679].  In order
+   to use that mechanism, the MN MUST have its home domain pre-
+   configured (i.e., subscription is tied to a network).  The DNS query
+   option is shown in Figure 6a.  Alternatively, the MN MAY use the DHCP
+   options for MoS discovery [RFC5678] as shown in Figure 6b (in some
+   deployments, a DHCP relay may not be present).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                    [Page 13]
+
+RFC 5677                          MSFD                     December 2009
+
+
+            (a)                       +-------+
+                       +----+         |Domain |
+                       | MN |-------->|Name   |
+                       +----+         |Server |
+                     MN@example.org   +-------+
+
+            (b)
+                                    +-----+      +------+
+                       +----+       |     |      |DHCP  |
+                       | MN |<----->| DHCP|<---->|Server|
+                       +----+       |Relay|      |      |
+                                    +-----+      +------+
+
+   Figure 6: MOS Discovery (a) Using DNS Query, (b) Using DHCP Option
+
+5.2.  MoS Discovery When MN and MoSv Both Are in Visited Network
+      (Scenario S2)
+
+   To discover a Mobility Server in the visited network, the MN SHOULD
+   attempt to use the DHCP options for MoS discovery [RFC5678] as shown
+   in Figure 7.
+
+                            +-----+      +------+
+               +----+       |     |      |DHCP  |
+               | MN |<----->| DHCP|<---->|Server|
+               +----+       |Relay|      |      |
+                            +-----+      +------+
+
+                Figure 7: MoS Discovery Using DHCP Options
+
+5.3.  MoS Discovery When MIH Services Are in a Third-Party Remote
+      Network (Scenario S3)
+
+   To discover a Mobility Server in a remote network other than home
+   network, the MN MUST use the DNS-based MoS discovery method described
+   in [RFC5679].  The MN MUST first learn the domain name of the network
+   containing the MoS it is searching for.  The MN can query its current
+   Mobility Server to find out the domain name of a specific network or
+   the domain name of a network at a specific location (as in Figure
+   8a).  IEEE 802.21 defines information elements such as OPERATOR ID
+   and SERVICE PROVIDER ID that can be a domain name.  An IS query can
+   provide this information, see [IEEE80221].
+
+   Alternatively, the MN MAY query a Mobility Server previously known to
+   learn the domain name of the desired network.  Finally, the MN MUST
+   use DNS-based discovery mechanisms to find a Mobility Server in the
+
+
+
+
+
+Melia, et al.               Standards Track                    [Page 14]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   remote network as in Figure 8b.  It should be noted that step b can
+   only be performed upon obtaining the domain name of the remote
+   network.
+
+            (a)
+                                      +------------+
+                       +----+         |            |
+                       |    |         |Information |
+                       | MN |-------->| Server     |
+                       |    |         |(previously |
+                       +----+         |discovered) |
+                                      +------------+
+
+            (b)
+                                      +-------+
+                       +----+         |Domain |
+                       | MN |-------->|Name   |
+                       +----+         |Server |
+                    MN@example.org    +-------+
+
+   Figure 8: MOS Discovery Using (a) IS Query to a Known IS Server,
+                                 (b) DNS Query
+
+5.4.  MoS Discovery When the MN Is in a Visited Network and Services Are
+      at the Home Network (Scenario S4)
+
+   To discover a Mobility Server in the visited network when MIH
+   services are provided by the home network, the DNS-based discovery
+   method described in [RFC5679] is applicable.  To discover the
+   Mobility Server at home while in a visited network using DNS, the MN
+   SHOULD use the procedures described in Section 5.1.
+
+6.  MIH Transport Options
+
+   Once the MoS have been discovered, MIH peers run a capability
+   discovery and subscription procedure 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 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
+
+
+
+Melia, et al.               Standards Track                    [Page 15]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   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 MUST NOT be used 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 or CS 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 MTU where PMTU is not implemented).  The Minimum MTU
+   depends on the IP version used for transmission, and is the lesser of
+   the first hop MTU, and 576 or 1280 bytes for IPv4 [RFC1122] or for
+   IPv6 [RFC2460], respectively, although applications may reduce these
+   values to guard against the presence of tunnels.
+
+   According to [IEEE80221], when an MIH message is sent using an L3 or
+   higher-layer transport, L3 takes care of any fragmentation issue and
+   the MIH protocol does not handle fragmentation in such cases.  Thus,
+   MIH layer fragmentation MUST NOT be used together with IP layer
+   fragmentation and MUST not be used when MIH packets are carried over
+   TCP.
+
+   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
+   [RFC5405] 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.  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 happen when the MN is exiting a wireless
+   access coverage area.  The use of the TCP_NODELAY option can
+
+
+
+Melia, et al.               Standards Track                    [Page 16]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   alleviate this problem by triggering transmission of a segment less
+   than the SMSS.  (It should be noted that [RFC4960] addresses both of
+   these problems, but discussion of SCTP is omitted here, as it is
+   generally not used for the mobility services discussed in this
+   document.)
+
+6.2.  MIH Message Rate
+
+   The frequency of MIH messages varies according to the MIH service
+   type.  It is expected that CS/ES messages 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 or CS messages.  On the other hand, if
+   UDP is used, a rate-limiting effect similar to the one obtained with
+   TCP SHOULD 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 follows:
+
+   o If the MIHF knows the RTT (e.g., based on the request/response MIH
+      protocol exchange between two MIH peers), the rate can be based
+      upon this as specified in [IEEE80221].
+
+   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 MUST 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.  The maximum number of retransmissions is configurable and the
+   value of the retransmission timer is computed according to the
+   algorithm defined in [RFC2988].  The default maximum number of
+
+
+
+
+
+Melia, et al.               Standards Track                    [Page 17]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   retransmissions is set to 2 and the initial retransmission timer
+   (TMO) is set to 3s when RTT is not known.  The maximum TMO is set to
+   30s.
+
+6.4.  NAT Traversal
+
+   There are no known issues for NAT traversal when using TCP.  The
+   default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a
+   2-hour TCP keep-alive) is considered adequate for MIH transport
+   purposes.  However, issues with NAT traversal using UDP are
+   documented in [RFC5405].  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 Mobility Server
+   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, in an attempt to refresh middlebox
+   state.  As [RFC4787] requires a minimum state timeout of 2 minutes or
+   more, MIH messages using UDP as transport SHOULD be sent once every 2
+   minutes.  Re-registration or event indication messages as defined in
+   [IEEE80221] MAY be used for this purpose.
+
+6.5.  General Guidelines
+
+   The ES and CS messages are small in nature and have tight latency
+   requirements.  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.  TCP SHOULD be used as the
+   default transport for all messages.  However, UDP in combination with
+   MIH acknowledgement SHOULD be used for transporting ES and CS
+   messages that are shorter than or equal to the path MTU as described
+   in Section 6.1.
+
+   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 in
+   Section 9 for that particular transport.
+
+   A Mobility 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 [RFC5679] to discover additional transport protocols
+   supported by the server (e.g., SCTP).
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                    [Page 18]
+
+RFC 5677                          MSFD                     December 2009
+
+
+7.  Operation Flows
+
+   Figure 9 gives an example operation flow between MIHF peers when an
+   MIH user requests an IS and both the MN and the Mobility Server are
+   in the MN's home network.  DHCP is used for Mobility Services (MoS)
+   discovery, and TCP is used for establishing a transport connection to
+   carry the IS messages.  When the Mobility Server is not pre-
+   configured, the MIH user needs to discover the IP address of the
+   Mobility Server to communicate with the remote MIHF.  Therefore, the
+   MIH user sends a discovery request message to the local 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.  The DHCP client sends a DHCP INFORM
+   message according to standard DHCP and with the MoS option as defined
+   in [RFC5678].  The DHCP server replies via a DHCP ACK message with
+   the IP address of the Mobility Server.  The Mobility Server address
+   is then passed to the MIHF locally via some internal APIs.  The 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 Mobility Server.  The MIHF invokes the underlying TCP
+   client, which establishes a transport connection with the remote
+   peer.  Once the transport connection is established, the MIHF sends
+   the IS query via an MIH protocol REQUEST message.  The message and
+   query arrive at the destination MIHF and MIH user, respectively.  The
+   Mobility Server MIH user responds to the corresponding IS query and
+   the Mobility Server MIHF sends the IS response via an MIH protocol
+   RESPONSE message.  The message arrives at the source MIHF, which
+   passes the IS response on to the corresponding MIH user.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melia, et al.               Standards Track                    [Page 19]
+
+RFC 5677                          MSFD                     December 2009
+
+
+                MN                                         MoS
+|===================================|    |======| |===================|
++ ---------+                                                +---------+
+| MIH USER |       +------+  +------+    +------+  +------+ | MIH USER|
+| +------+ |       | TCP  |  |DHCP  |    |DHCP  |  | TCP  | | +------+|
+| | MIHF | |       |Client|  |Client|    |Server|  |Server| | | MIHF ||
++----------+       +------+  +------+    +------+  +------++----------+
+    |                 |         |           |         |          |
+  MIH Discovery       |         |           |         |          |
+  Request             |         |           |         |          |
+    |                 |         |           |         |          |
+    |Invoke DHCP Client         |           |         |          |
+    |(Internal process with MoS)|DHCP INFORM|         |          |
+    |==========================>|==========>|         |          |
+    |                 |         |           |         |          |
+    |  Inform Mobility Server   |  DHCP ACK |         |          |
+    |         Address           |<==========|         |          |
+    |<==========================|           |         |          |
+    |    (internal process)     |           |         |          |
+    |                 |         |           |         |          |
+  MIH Discovery       |         |           |         |          |
+  Response            |         |           |         |          |
+    |                 |         |           |         |          |
+  IS Query            |         |           |         |          |
+  MIH User-> MIHF     |         |           |         |          |
+    |                 |         |           |         |          |
+    |Invoke TCP Client|         |           |         |          |
+    |================>|  TCP connection established   |          |
+  Internal process    |<=============================>|          |
+    |                 |         |           |         |          |
+    |                 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 9: Example Flow of Operation Involving MIH User
+
+
+
+
+Melia, et al.               Standards Track                    [Page 20]
+
+RFC 5677                          MSFD                     December 2009
+
+
+8.  Security Considerations
+
+   There are two components to the security considerations: MoS
+   discovery and MIH transport.  For MoS discovery, DHCP and DNS
+   recommendations are hereby provided per IETF guidelines.  For MIH
+   transport, we describe the security threats and expect that the
+   system deployment will have means to mitigate such threats when
+   sensitive information is being exchanged between the mobile node and
+   Mobility Server.  Since IEEE 802.21 base specification does not
+   provide MIH protocol level security, it is assumed that either lower
+   layer security (e.g., link layer) or overall system-specific (e.g.,
+   proprietary) security solutions are available.  The present document
+   does not provide any guidelines in this regard.  It is stressed that
+   the IEEE 802.21a Task Group has recently started work on MIH security
+   issues that may provide some solution in this area.  Finally,
+   authorization of an MN to use a specific Mobility Server, as stated
+   in Section 5, is neither in scope of this document nor is currently
+   specified in [IEEE80221].
+
+8.1.  Security Considerations for MoS Discovery
+
+   There are a number of security issues that need to be taken into
+   account during node discovery.  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 the DHCP
+   authentication option described in [RFC3118], where available, or
+   rely upon link layer security.  [RFC3118] provides mechanisms for
+   both entity authentication and message authentication.  In the case
+   where the DHCP authentication mechanism is not available,
+   administrators may need to rely upon the underlying link layer
+   security.  In such cases, the link between the DHCP client and Layer
+   2 termination point may be protected, but the DHCP message source and
+   its messages cannot be authenticated or the integrity of the latter
+   checked unless there exits a security binding between link layer and
+   DHCP layer.
+
+   In the case where DNS is used for discovering MoS, fake DNS requests
+   and responses may cause denial of service (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.
+
+8.2.  Security Considerations for MIH Transport
+
+   The communication between an MN and a Mobility Server is exposed to a
+   number of security threats:
+
+
+
+Melia, et al.               Standards Track                    [Page 21]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   o  Mobility Server identity spoofing.  A fake Mobility Server could
+      provide the MNs with bogus data and force them to select the wrong
+      network or to make a wrong handover decision.
+
+   o  Tampering.  Tampering with the information provided by a Mobility
+      Server may result in the MN making wrong network selection or
+      handover decisions.
+
+   o  Replay attack.  Since Mobility Services as defined in [IEEE80221]
+      support a 'PUSH model', they can send large amounts of data to the
+      MNs whenever the Mobility Server thinks that the data is relevant
+      for the MN.  An attacker may intercept the data sent by the
+      Mobility Server to the MNs and replay it at a later time, causing
+      the MNs to make network selection or handover decisions that are
+      not valid at that point in time.
+
+   o  Eavesdropping.  By snooping the communication between an MN and a
+      Mobility Server, an attacker may be able to trace a user's
+      movement between networks or cells, or predict future movements,
+      by inspecting handover service messages.
+
+   There are many deployment-specific system security solutions
+   available, which can be used to countermeasure the above mentioned
+   threats.  For example, for the MoSh and MoSv scenarios (including
+   roaming scenarios), link layer security may be sufficient to protect
+   the communication between the MN and Mobility Server.  This is a
+   typical mobile operator environment where link layer security
+   provides authentication, data confidentiality, and integrity.  In
+   other scenarios, such as the third-party MoS, link layer security
+   solutions may not be sufficient to protect the communication path
+   between the MN and the Mobility Server.  The communication channel
+   between MN and Mobility Server needs to be secured by other means.
+
+   The present document does not provide any specific guidelines about
+   the way these security solutions should be deployed.  However, if in
+   the future the IEEE 802.21 Working Group amends the specification
+   with MIH protocol level security or recommends the deployment
+   scenarios, IETF may revisit the security considerations and recommend
+   specific transport-layer security as appropriate.
+
+9.  IANA Considerations
+
+   This document registers the following TCP and UDP ports with IANA:
+
+    Keyword    Decimal             Description
+    --------   ---------------     ------------
+    ieee-mih   4551/tcp            MIH Services
+    ieee-mih   4551/udp            MIH Services
+
+
+
+Melia, et al.               Standards Track                    [Page 22]
+
+RFC 5677                          MSFD                     December 2009
+
+
+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.  References
+
+11.1.  Normative References
+
+   [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., Ed., and W. Arbaugh, Ed., "Authentication for
+               DHCP Messages", RFC 3118, June 2001.
+
+   [RFC3315]   Droms, R., Ed., 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.
+
+   [RFC5678]   Bajko, G. and S. Das, "Dynamic Host Configuration
+               Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21
+               Mobility Services (MoS) Discovery", RFC 5678, December
+               2009.
+
+   [RFC5679]   Bajko, G., "Locating IEEE 802.21 Mobility Services Using
+               DNS", RFC 5679, December 2009.
+
+11.2.  Informative References
+
+   [IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks -
+               Part 21: Media Independent Handover Services", IEEE
+               LAN/MAN Std 802.21-2008, January 2009,
+               http://www.ieee802.org/21/private/Published%20Spec/
+               802.21-2008.pdf (access to the document requires
+               membership).
+
+
+
+
+
+Melia, et al.               Standards Track                    [Page 23]
+
+RFC 5677                          MSFD                     December 2009
+
+
+   [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.
+
+   [RFC2988]   Paxson, V. and M. Allman, "Computing TCP's Retransmission
+               Timer", RFC 2988, November 2000.
+
+   [RFC3022]   Srisuresh, P. and K. Egevang, "Traditional IP Network
+               Address Translator (Traditional NAT)", RFC 3022, January
+               2001.
+
+   [RFC4641]   Kolkman, O. and R. Gieben, "DNSSEC Operational
+               Practices", RFC 4641, September 2006.
+
+   [RFC4787]   Audet, F., Ed., and C. Jennings, "Network Address
+               Translation (NAT) Behavioral Requirements for Unicast
+               UDP", BCP 127, RFC 4787, January 2007.
+
+   [RFC4960]   Stewart, R., Ed., "Stream Control Transmission Protocol",
+               RFC 4960, September 2007.
+
+   [RFC5164]   Melia, T., Ed., "Mobility Services Transport: Problem
+               Statement", RFC 5164, March 2008.
+
+   [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
+               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5382]   Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and
+               P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP
+               142, RFC 5382, October 2008.
+
+   [RFC5405]   Eggert, L. and G. Fairhurst, "Unicast UDP Usage
+               Guidelines for Application Designers", BCP 145, RFC 5405,
+               November 2008.
+
+   [RFC5681]   Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+               Control", RFC 5681, September 2009.
+
+
+
+Melia, et al.               Standards Track                    [Page 24]
+
+RFC 5677                          MSFD                     December 2009
+
+
+Authors' Addresses
+
+   Telemaco Melia (editor)
+   Alcatel-Lucent
+   Route de Villejust
+   Nozay  91620
+   France
+
+   EMail: telemaco.melia@alcatel-lucent.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.               Standards Track                    [Page 25]
+