MIF API extension for combining IEEE 802.21
draft-zhang-mif-api-extension-802-21-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2014-07-02
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
MIF                                                       Hongke Zhang
Internet Draft                                                Boxin Du
Intended status: Informational                                Mi Zhang
Expires: January 3, 2015                                      Fei Song
                                           Beijing Jiaotong University
                                                          July 3, 2014

                MIF API extension for combining IEEE 802.21
                draft-zhang-mif-api-extension-802-21-00.txt

Abstract

   The Application Program Interface (API) of MIF, specified in the MIF
   API consideration, must rely on lower layer functionalities when
   handover between homogeneous or heterogeneous networks is necessary.
   To improve the connectivity experience, the existing MIF API needs to
   be extended for solving such problem. IEEE is also aimed at the
   similar issue from different way. A kind of logical entities over the
   link layer protocol for handling the seamless handover has been
   defined in IEEE 802.21. This document proposes a mechanism via
   integrating MIF API and IEEE 802.21 to support application service
   better.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2015.

Zhang, et al.          Expires January 3, 2015                [Page 1]
Internet-Draft            MIF API extension                  July 2014

Copyright Notice

   Copyright (c) 2014 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 Simplified BSD License.

Zhang, et al.          Expires January 3, 2015                [Page 2]
Internet-Draft            MIF API extension                  July 2014

Table of Contents

   1. Introduction ................................................ 4
   2. Terminology ................................................. 4
   3. The Relationship between IEEE MIHF and MIF API .............. 4
   4. The Extension of MIF API for Handover: A Case Study ......... 8
      4.1. The MN-initiated Handover .............................. 8
         4.1.1. Get Information ................................... 9
         4.1.2. Information Post .................................. 9
         4.1.3. Parameter Report .................................. 9
         4.1.4. Check Resources MN ................................ 9
         4.1.5. Resource Availability ............................. 9
         4.1.6. Connect to Interface ............................. 10
         4.1.7. Resource Preparation Messages .................... 10
         4.1.8. Establish Link Messages .......................... 10
         4.1.9. Link Up .......................................... 10
         4.1.10. Handover Completed .............................. 10
         4.1.11. Handover Completion Confirmation ................ 11
      4.2. The Network-initiated Handover ........................ 11
         4.2.1. Candidate Query Notification ..................... 11
         4.2.2. Candidate Query Result ........................... 12
         4.2.3. Check Resources Net .............................. 12
         4.2.4. Confirm Chosen Target ............................ 12
         4.2.5. Establish Link Messages .......................... 12
         4.2.6. Link Up .......................................... 12
         4.2.7. Handover Completed ............................... 12
         4.2.8. Handover Completion Confirmation ................. 12
   5. Discussions for New Messages from MIF Perspective .......... 13
      5.1. Get Information ....................................... 13
      5.2. Release the Ongoing Connection ........................ 13
      5.3. Establish New L2 Connection ........................... 13
   6. Discussions for New Messages from IEEE Perspective ......... 13
   7. Security Considerations .................................... 16
   8. IANA Considerations ........................................ 16
   9. References ................................................. 16
      9.1. Normative References .................................. 16
      9.2. Informative References ................................ 17
   10. Acknowledgments ........................................... 17

Zhang, et al.          Expires January 3, 2015                [Page 3]
Internet-Draft            MIF API extension                  July 2014

1. Introduction

   In MIF context, improved connectivity experiences SHOULD be created.
   Enhancing the performance of horizontal and vertical switches between
   networks is one of main targets. Such situation is quite similar with
   Media Independent Handover (MIH) described in [IEEE 802.21]. The MIF
   Application Program Interface (API) specified in the MIF API
   consideration [I-D.ietf-mif-api-extension] describes a set of message
   calls to implement higher level APIs that solve the problems in
   multiple interface scenarios. However, this draft only provides a
   minimal set of message calls REQUIRED to implement the API. New
   functions could be added.

   According to [IEEE 802.21], the Media Independent Handover Function
   (MIHF) is a logical entity that facilitates MIH decision making based
   on inputs from the MIHF. It provides abstracted services to higher
   layers. Communications with the lower layer of the mobility-
   management protocol stack can be achieved through technology-specific
   interfaces in MIHF.

   Although two mechanisms, MIF API and MIHF, are working in different
   layers and defined by different organizations, the requirements of
   compatibility are obvious. Some of the functions of MIF API SHOULD be
   supported by a connection manager (i.e. the MIHF), and vice versa.
   Owing to the advantages of both MIHF and its Service Access Points
   (SAPs), the functions of MIHF could be utilized in MIF API for
   handover issues. This document extends message calls of MIF API to
   support the MIH. Like [I-D.ietf-mif-api-extension], no bindings for
   programming languages are provided because they are left up to the
   implementation. This document only describes the messages sent and
   received. It can be read as a checklist for operating system vendors.

2. Terminology

   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. The Relationship between IEEE MIHF and MIF API

   The purpose of IEEE 802.21 is to improve the user experience of
   mobile devices by facilitating handover between IEEE 802 networks
   whether or not they are of different media types, including both
   wired and wireless. It also aims at making it possible for mobile
   devices to perform seamless handover between IEEE 802 and non IEEE
   networks. This standard defines:

Zhang, et al.          Expires January 3, 2015                [Page 4]
Internet-Draft            MIF API extension                  July 2014

   1) A framework that enables service continuity while a Mobile Node
      (MN) transitions between heterogeneous link-layer technologies;

   2) MIHF;

   3) MIH_SAP and associated primitives for users to get services of
      MIHF;

   4) The definitions of new link-layer SAPs and associated primitives
      for each link-layer technology. They help MIHF to collect link
      information and control link behaviors during handovers.

   The concept of MIHF is a functional entity to realize the high-
   performance handovers. The advantage of MIHF is that it provides
   media-independent services to higher layers no matter which media-
   specific technology of lower layer is being used, such as IEEE
   Std.802.3, IEEE Std.802.11, IEEE Std.802.16, 3GPP and 3GPP2. It also
   defines three kinds of SAPs (will be detailed later) of MIHF and
   their primitives that interact between different layers. The MIHF can
   also act as a filter: the messages received from link layer SHOULD be
   processed and submitted to higher layer for meeting the subscribers'
   need. Therefore, MIHF should work under MIF API. In fact, MIF API
   SHOULD be served as a user of MIHF, which is shown in Figure 1. The
   subscribers can then only interact with the MIHF via one kind of SAPs
   (i.e. MIH_SAP) without knowing lower things. The MIH protocol of this
   standard is not discussed in this document.

   Three kinds of MIHF services are defined in the standard. They are
   Media Independent Event Service (MIES), Media Independent Command
   Service (MICS) and Media Independent Information Service (MIIS). MIES
   provides event classification, event filtering, event reporting
   corresponding to dynamic changes in link characteristics, link status
   and link quality. It originates from lower layers and can be passed
   to MIHF or upper users for the detection of handover requirement.
   MICS enables MIH users to manage and control link behavior relevant
   to handover and mobility. It is invoked by users or MIHF and makes
   effect on MIHF or lower layers.

   For example, in MN-initiated handover scenario, MICS is adopted for
   MN switching between different links. MIIS allows MN and network
   entities to discover information that influences the selection of
   appropriate networks during handovers. Figure 2 [IEEE 802.21] shows
   MIH services and their initiation.

Zhang, et al.          Expires January 3, 2015                [Page 5]
Internet-Draft            MIF API extension                  July 2014

                +-------------------------------------+
                |             Application             |
                +-------------------------------------+
                   /\     ||     /\   ||    /\   ||
                   ||     \/     ||   ||    ||   ||
                +--------------+ ||   ||    ||   ||
                |High Level API| ||   ||    ||   ||
                +--------------+ ||   ||    ||   ||
                   /\     ||     ||   ||    ||   ||
                   ||     \/     ||   \/    ||   ||
                +------------------------+  ||   ||
                |        MIF API         |  ||   ||
                +------------------------+  ||   ||
                    /\      ||              ||   \/
                    ||      ||   +--------------------+
                    ||      ||   | Communication API  |
                    ||      ||   +--------------------+
                    ||      ||         /\  /\
                    ||      ||         ||  ||
                    ||      \/         \/  \/
                +-------------------------------------+
                |                   MIHF              |
                +-------------------------------------+
                         /\              ||
                         ||              \/
                +-------------------------------------+
                |         Network Link API            |
                +-------------------------------------+
                    /\    ||              /\    ||
                    ||    \/              ||    \/
                +---------------+     +---------------+
                |    Network    |     |    Network    |
                |  Interface 1  |     |  Interface 2  |
                +---------------+     +---------------+

                Table 1 The relationship of MIHF & MIF API

   The letters a, b, c in Figure 2 are:

   a. MIH_SAP

   b. MIH_LINK_SAP

   c. LLC_SAP

   The SAPs are divided into two categories:

Zhang, et al.          Expires January 3, 2015                [Page 6]
Internet-Draft            MIF API extension                  July 2014

   1) Media dependent SAP (including MIH_LINK_SAP and LLC_SAP)

   2) Media independent SAP (MIH_SAP)

   +-------------+     Command      +-----------------------------+
   |             +     Service      |                             |
   |            / \ <---------------+                             |
   |           +   +                |       MIH User              |
   |           |   |    Event       |                             |
   | MIHF      |   |   Service      |    Layer 3 or Higher        |
   |           | a |--------------->|    Mobility Protocol        |
   | Event     |   |                |                             |
   | Service   |   |  Information   |                             |
   |           +   +   Service      |                             |
   | Command    \ /<--------------->|  +-------+        +-------+ |
   | Service     +                  +--+   c   +-+---+--+   c   +-+
   |             |     Command      +  +-------+ |   +  +-------+ |
   | Information |     Service     / \           |  / \           |
   | Service     |--------------->+   +          | +   +          |
   |             |                |   | Network1 | |   | Network2 |
   |             |      Event     |   | (e.g.IEEE| |   | (e.g.IEEE|
   |             |     Service    | b |  802.16) | | b |  802.11) |
   |             |<---------------|   |          | |   |          |
   |             |                |   |          | |   |          |
   |             |   Information  |   |          | |   |          |
   |             |     Service    +   +          | +   +          |
   |             |<--------------->\ /           |  \ /           |
   |             |                  +            |   +            |
   |             |                  |            |   |            |
   +-------------+                  +------------+   +------------+

                Table 2 MIH services and their initiation

   SAP of the MIHF (i.e. MIH_SAP) is media independent. The MIH_SAP
   defines the interface between the MIHF and MIH users such as an upper
   layer mobility protocol or a handover function (e.g., MIF API) that
   might reside at higher layer transport entity as well. MIH_SAP allows
   the MIHF to provide services to the upper layers, the network
   management plane and the data bearer plane. Upper layers need to
   subscribe with the MIHF as users to receive MIHF events. In MIF case,
   the MIF API can directly send commands to the local MIHF via messages
   which use the service primitives of the MIH_SAP.

   All the messages REQUIRED for communicating successfully in MIF
   environment that described in the [I-D.ietf-mif-api-extension] MUST
   also be used here. Those messages define the way that MIF API
   interacts with the higher layers or applications. New messages need

Zhang, et al.          Expires January 3, 2015                [Page 7]
Internet-Draft            MIF API extension                  July 2014

   to be added into this set for handover process. These new messages
   SHOULD be exchanged between MIHF and MIF API. Some of them may use
   the services of MIHF.

4. The Extension of MIF API for Handover: A Case Study

   This section introduces the extension of message calls of MIF API in
   two parts based on the classification of handovers (MN-initiated
   handover and the network-initiated handover). To handle these two
   kinds of handovers successfully, MIF API SHOULD be extended
   respectively based on the characteristics of process.

4.1. The MN-initiated Handover

   7 steps are included in the MN-initiated handover:

   1) Information query. The MN collects network information from the
   MIIS server that the MN is connected to.

   2) Resource availability check. The MIF API sends request to find
   candidates and then receives a list of candidate networks in response
   message.

   3) Resource preparation. The MN SHOULD determine which target network
   is suitable and request it for resource preparation.

   4) Establish new L2 connection. The MIF API initiates a new link
   connection.

   5) Link up indication. The MIHF of MN notifies the MIF API that the
   link is up.

   6) Higher layer handover execution.

   7) Resource release. The original serving network resources must be
   released in the end.

   The following messages, which are only the interactions between a
   MIHF and MIF APIs, need to be added.

4.1.1. Get Information

   This message is sent by the MIF API for the inquiry of the
   neighbouring networks information. In MIH, we can use the
   MIH_Get_Information.request for the same purpose. After receiving
   this message, the MIHF inquires the MIIS server for the information,
   and then returns a list of network information needed for MIF API.

Zhang, et al.          Expires January 3, 2015                [Page 8]
Internet-Draft            MIF API extension                  July 2014

4.1.2. Information Post

   This message is sent to the MIF API by the MIIS server as a result of
   the Get Information message. MIH_Get_Information.confirm can be used
   to convey such information.

4.1.3. Parameter Report

   When attaching to a specific network, the MIF API needs to receive
   the link status from the lower layers to better control the whole
   connection. The MIHF can receive reports from the link layers and
   submit to the higher layers. If the link is going down, the MIF API
   must notify its subscribers using message "Interface is going away".
   The application or higher API could try to establish new connections
   by sending "Wants to connect" to MIHF and the connection process will
   begin from step 2 (i.e. Resource availability check).

   Another situation is that once the MIF API receives a "Wants to
   connect" message from its subscriber, the MIF API SHOULD accordingly
   trigger a whole connection process to a new network. This can also
   begin from step 2.

4.1.4. Check Resources MN

   Before the connection starts, the MN SHOULD check the resource
   availability at the candidate networks. This message is sent to the
   MIHF by the MIF API. The serving network SHOULD request each
   candidate. The final result SHOULD be returned to the higher layer.
   The MIH_MN_HO_Candidate_Query.request can be used in the MIH case.

4.1.5. Resource Availability

   When receiving the resource availability of the candidates from the
   serving network, the MIHF SHOULD provide them to the MIF API. The
   MIH_MN_HO_Candidate_Query.confirm can be used in the MIH case.

4.1.6. Connect to Interface

   This message is sent to the MIF API by the upper applications. When
   the MIF API receives the Resource Availability, it could post the
   message to the higher layer. The upper application can use "Connect
   to Interface" to choose a preferred network interface. More details
   about the choosing methods need further discussion.

Zhang, et al.          Expires January 3, 2015                [Page 9]
Internet-Draft            MIF API extension                  July 2014

4.1.7. Resource Preparation Messages

   The MIF API can use the MIH_MN_HO_Commit.request, including the
   target network information, to request the chosen network for
   resource preparation. When the preparation is done, the MIHF receives
   the response from the target network. It sends a
   MIH_MN_HO_Commit.confirm message to the MIF API for informing the
   status of the previously issued target notification request.

4.1.8. Establish Link Messages

   MIF API can use the MIH_Link_Action.request to solve the connection
   establishment problem. This primitive defined by the [IEEE 802.21] is
   to control the local or remote lower link layers. It includes a MIHF
   ID and a Link Actions List, which can realize many functions of
   controlling. After the action has been executed, the MIF API should
   receive a MIH_Link_Action.confirm for result indication.

4.1.9. Link Up

   After the new link is established, the MAC layers MUST deliver a
   Link_Up.indication to the MIHF. The MIHF then passes the
   MIH_Link_Up.indication message to the MIF API. The MIF API can notify
   the upper applications by delivering the "Link is going up" message.
   Then the higher layer handover execution might be triggered and the
   traffic flow can be re-established.

4.1.10. Handover Completed

   This message is sent to the local MIHF by the MIH API for releasing
   the resources of the previous serving network which was originally
   allocated to the MN. After identifying that the release is
   successfully done, the target network Point of Service (PoS) sends
   the confirm message to the MIHF and the MIHF SHOULD also inform the
   MIF API with the same information.

4.1.11. Handover Completion Confirmation

   This message is sent to the MIF API by the MIHF indicating that the
   resource of the previous network is successfully released.

4.2. The Network-initiated Handover

   There are also 7 steps in an intact network-initiated handover, like
   the MN-initiated handover:

   1) Information query.

Zhang, et al.          Expires January 3, 2015               [Page 10]
Internet-Draft            MIF API extension                  July 2014

   2) Resource availability check.

   3) Resource preparation.

   4) Establish a L2 connection using MIH_Link_Action.request.

   5) Sent link indications to the MIF API.

   6) Higher layer handover execution.

   7) Resource release.

   The differences between Network-initiated case and MN-initiated case
   are in step 1 and step 2: the Get Information request and Information
   Query are respectively initiated by the MIH user of the serving
   network. When such MIH user obtains the information from the MIIS
   server, it sends requests to the MN for response message containing
   the MN's handover acknowledgement, MN's preferred link and PoS lists.

   In step 3, the commit of target network is also initiated by the MIH
   user of a serving network. After the resource is prepared, the PoS of
   serving network SHOULD notify the MN for the establishment of L2
   connection in step 4.

   The following messages should be added in MIF API:

4.2.1. Candidate Query Notification

   This message is sent to MN's MIHF from the PoS of the serving network
   with a list of PoAs of each candidate network link. Such message
   means the MN SHOULD consider new access network. This message can use
   the MIH_Net_HO_Candidate_Query.indication.

4.2.2. Candidate Query Result

   This message is sent to the local serving network's MIHF from MN's
   MIF API, specifying whether the request of handover is permitted or
   not. MIH_Net_HO_Candidate_Query.response can be used here. If the
   handover is permitted, a new access network SHOULD be considered at
   handover initiation stage.

4.2.3. Check Resources Net

   This message is sent to the MN's MIF API by the PoS of serving
   network with a list of target network information and a set of
   resource parameters assigned to the MN for the handover.
   MIH_Net_HO_Commit.indication can be used here. Then the MIF API can

Zhang, et al.          Expires January 3, 2015               [Page 11]
Internet-Draft            MIF API extension                  July 2014

   trigger the establishment of L2 connection by using
   Link_Action.request. After the link connection is done, MIF API needs
   to inform the serving network. Link_Action.request might also have a
   list of actions for handover control during the link connection
   period.

4.2.4. Confirm Chosen Target

   This message is sent by the MN's MIF API as the response of the
   MIH_HO_Commit.indication, showing that the indication is received.
   MIH_Net_HO_Commit.response can be used here. Also such message might
   include a list of results of previous actions.

4.2.5. Establish Link Messages

   This message is exactly the same as that of the MN-initiated process,
   for establishing a new L2 link connection.

4.2.6.  Link Up

   This message is exactly the same as that of the MN-initiated process,
   for informing the MIF API that the L2 link is completed.

4.2.7. Handover Completed

   This message is exactly the same as that of the MN-initiated process,
   for releasing the resources that have already attained by the MN.

4.2.8. Handover Completion Confirmation

   This message is exactly the same as that of the MN-initiated process,
   for confirming that the resources of the previous network are
   successfully released.

5. Discussions for New Messages from MIF Perspective

   New messages described in this document are critical for information
   exchanging and function achievement between MIHF and MIF API. Since
   both "upper layer requirements gathering" and "lower layer command
   delivering" (or reverse) can be achieved via messages, the logical
   relationship should be discussed in-depth. The messages below are
   only the initial examples. Further updating is still needed.

5.1. Get Information

   According to [IEEE 802.21], this information query is related to a
   specific interface. It has the flexibility to query either a specific

Zhang, et al.          Expires January 3, 2015               [Page 12]
Internet-Draft            MIF API extension                  July 2014

   data within a network interface or an extended schema of a given
   network. When the advanced application or upper APIs send "Announce
   Interface", "Announce PVD" and "Announce IE (Information Elements)",
   the MIF API could obtain the information by using the
   Get_information.request in MIH.

5.2. Release the Ongoing Connection

   The [I-D.ietf-mif-api-extension] defines a message called "Connection
   can be broken", which means that the MN can tolerate the connection
   being broken, e.g. for power conservation. When the subscribers of
   MIF API delivers this message, the MIF API SHOULD send "Release the
   ongoing connection" to the MIHF so that directly releasing the
   current resources of network to cut off this connection. But this
   action will not weaken the function of the application.

5.3. Establish New L2 Connection

   According to [IEEE 802.21], the MIH_Link_Actions can trigger a L2
   link connection. When MN wants to set up a TCP connection with an IP
   host, the MIF API will receive "Connect to Address" or "Connect to
   Address from Address" messages. Then the MIF API can use the
   MIH_Link_Actions.request to ask MIHF for a new L2 link connection.

6. Discussions for New Messages from IEEE Perspective

   The following tables, table1, 2, 3 and 4, are from the [IEEE 802.21].
   These messages might be used in the MIF API because they are
   exchanged between the MIHF and its MIH users. Some of them have been
   discussed above, but the specific usage of the rest is not
   represented. This section is only a direct listing of all these
   messages, their category and brief descriptions. Further discussion
   is still needed.

   +---------------------+--------------------------------------------+
   | Messages            | Description                                |
   | (Information)       |                                            |
   +---------------------+--------------------------------------------+
   | MIH_Get_Information | Request to get information from repository |
   +---------------------+--------------------------------------------+
   | MIH_Push_Information| Notify the MN of operator policies or      |
   |                     | other information                          |
   +---------------------+--------------------------------------------+

                   Table 1 Information Messages of MIHF

Zhang, et al.          Expires January 3, 2015               [Page 13]
Internet-Draft            MIF API extension                  July 2014

   +---------------------+--------------------------------------------+
   | Messages (Event)    | Description                                |
   +---------------------+--------------------------------------------+
   | MIH_Link_Detected   | Link of a new access network has been      |
   |                     | detected. This event is typically on the   |
   |                     | MN when the first PoA of an access network |
   |                     | is detected                                |
   +---------------------+--------------------------------------------+
   | Track_timeout       | This event is not generated when           |
   |                     | subsequent PoAs of the same access network |
   |                     | are discovered                             |
   +---------------------+--------------------------------------------+
   | MIH_Link_Up         | L2 connection is established and link is   |
   |                     | available for use                          |
   +---------------------+--------------------------------------------+
   | MIH_Link_Down       | L2 connection is broken and link is not    |
   |                     | available for use                          |
   +---------------------+--------------------------------------------+
   | MIH_Link_Paremeters | Link parameters have crossed a specified   |
   | _Report             | threshold and need to be reported          |
   +---------------------+--------------------------------------------+
   | MIH_Link_Going_Down | Link conditions are degrading and          |
   |                     | connection loss is imminent                |
   +---------------------+--------------------------------------------+
   | MIH_Link_Handover   | L2 handover is imminent based on either    |
   | _Imminent           | the changes in the link conditions or      |
   |                     | additional information available in the    |
   |                     | network                                    |
   +---------------------+--------------------------------------------+
   | MIH_Link_Handover   | L2 handover to a new PoA has been          |
   | _Complete           | completed                                  |
   +---------------------+--------------------------------------------+
   | MIH_Link_PDU        | Indicate transmission status of a PDU      |
   | _Transmit_Status    |                                            |
   +---------------------+--------------------------------------------+

                      Table 2 Event Messages of MIHF

Zhang, et al.          Expires January 3, 2015               [Page 14]
Internet-Draft            MIF API extension                  July 2014

   +--------------------+---------------------------------------------+
   | Messages (Command) | Description                                 |
   +--------------------+---------------------------------------------+
   | MIH_Link_Get       | Get the status of a link                    |
   | _Parameters        |                                             |
   +--------------------+---------------------------------------------+
   | MIH_Net_HO         | Network initiates handover and sends a list |
   | _Candidate _Query  | of suggested networks and associated points |
   |                    | of attachment                               |
   +--------------------+---------------------------------------------+
   | MIH_Link_Configure | Configure link parameter thresholds         |
   | Thresholds         |                                             |
   +--------------------+---------------------------------------------+
   | MIH_Link_Actions   | Control the behavior of a set of links      |
   +--------------------+---------------------------------------------+
   | MIH_MN_HO_Candidate| Command used by MN to query and obtain      |
   | _Query             | handover related information about possible |
   |                    | candidate networks                          |
   +--------------------+---------------------------------------------+
   | MIH_N2N_HO_Query   | command sent by the serving MIHF entity to  |
   | _Resources         | the target MIHF entity for resource query   |
   +--------------------+---------------------------------------------+
   | MIH_MN_HO_Commit   | Command used by MN to notify the serving    |
   |                    | network of the decided target network       |
   |                    | information                                 |
   +--------------------+---------------------------------------------+
   | MIH_Net_HO_Commit  | Command used by the network to notify the   |
   |                    | MN of the decided target network information|
   +--------------------+---------------------------------------------+
   | MIH_N2N_HO_Commit  | Command used by a serving network to inform |
   |                    | a target network that an MN is about to     |
   |                    | move toward that network, initiate context  |
   |                    | transfer and perform handover preparation   |
   +--------------------+---------------------------------------------+
   | MIH_MN_HO_Complete | Notification from MIHF of the MN to the     |
   |                    | target or source MIHF indicating the        |
   |                    | status of handover completion               |
   +--------------------+---------------------------------------------+
   | MIH_N2N_HO_Complete| Notification from MIHF of the MN to the     |
   |                    | target or source MIHF indicating the        |
   |                    | status of handover completion               |
   +--------------------+---------------------------------------------+
   | MIH_N2N_HO_Complete| Notification from either source or target   |
   |                    | MIHF to the peer MIHF indicating the status |
   |                    | of the handover completion                  |
   +--------------------+---------------------------------------------+
                     Table 3 Command Messages of MIHF

Zhang, et al.          Expires January 3, 2015               [Page 15]
Internet-Draft            MIF API extension                  July 2014

   +---------------------+--------------------------------------------+
   | Messages            | Description                                |
   | (Service management)|                                            |
   +---------------------+--------------------------------------------+
   | MIH_Capability      | Discover list of Events and Commands       |
   | _Discover           | supported by MIHF                          |
   +---------------------+--------------------------------------------+
   | MIH_Register        | Register with a remote MIHF                |
   +---------------------+--------------------------------------------+
   | MIH_DeRegister      | Deregister with a remote MIHF              |
   +---------------------+--------------------------------------------+
   | MIH_Event_Subscribe | Subscribe for MIH event notification       |
   +---------------------+--------------------------------------------+
   | MIH_Event_Unsubscibe| Unsubscribe from MIH event notification    |
   +---------------------+--------------------------------------------+

                    Table 4 Service Management of MIHF

7. Security Considerations

   This document does not contain any security considerations.

8. IANA Considerations

   There are presently no IANA considerations with this document.

9. References

9.1. Normative References

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

9.2. Informative References

   [IEEE 802.21] IEEE, "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>.

   [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and Z.
             Cao, "MIF API consideration", draft-ietf-mif-api-extension-
             05 (work in progress), Feb. 2014.

Zhang, et al.          Expires January 3, 2015               [Page 16]
Internet-Draft            MIF API extension                  July 2014

10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Hongke Zhang
   Beijing Jiaotong University (BJTU)
   Beijing, 100044, P.R.China

   Email: hkzhang@bjtu.edu.cn

   Boxin Du
   Beijing Jiaotong University (BJTU)
   Beijing, 100044, P.R.China

   Email: 10291070@bjtu.edu.cn

   Mi Zhang
   Beijing Jiaotong University (BJTU)
   Beijing, 100044, P.R.China

   Email: 13120174@bjtu.edu.cn

   Fei Song
   Beijing Jiaotong University (BJTU)
   Beijing, 100044, P.R.China

   Email: fsong@bjtu.edu.cn

Zhang, et al.          Expires January 3, 2015               [Page 17]