MIF API extension for combining IEEE 802.2
draft-zhang-mif-api-extension-802-21-10

Document Type Active Internet-Draft (individual)
Last updated 2019-05-15
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized 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                                                 Fei Song
Intended status: Informational                                 Boxin Du
Expires: November 18 2019                                      Mi Zhang
                                            Beijing Jiaotong University
                                                            May 14,2019
                                            

                    MIF API extension for combining IEEE 802.2
                   draft-zhang-mif-api-extension-802-21-10.txt

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 November 18, 2019.

Copyright Notice

   Copyright (c) 2016 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 November 18, 2019             [Page 1]
Internet-Draft            MIF API extension                   May 2019

Abstract

   The Application Program Interface (API) of MIF, specified in the MIF
   API consideration, must lean upon lower layer functionalities when
   handover between homogeneous or heterogeneous networks is necessary.
   To improve the connectivity performance, the existing MIF API needs
   to be extended. IEEE also aims 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 IEEE802.21. This 
   document proposes a mechanism via integrating MIF API and IEEE 
   802.21 to support application service better.

Table of Contents

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

Zhang, et al            Expires November 18, 2019             [Page 2]
Internet-Draft            MIF API extension                   May 2019

   9. References ................................................. 16
      9.1. Normative References................................... 16
      9.2. Informative References................................. 16
   10. Acknowledgments ........................................... 16

1. Introduction

   In MIF context, the improvement of connectivity experiences SHOULD
   be produced. Enhancing the performance of horizontal and vertical 
   switches between networks is the main target. The aforementioned 
   situation is quite similar with Media Independent Handover (MIH) 
   described in [IEEE 802.21]. Although the MIF Application Program 
   Interface (API) specified in the MIF API consideration 
   [I-D.ietf-mif-api-extension] illustrates a series of messages in 
   multiple interface scenarios, this draft only provides a minimal set 
   of message calls REQUIRED to implement the API. Hence, new functions
   could be added.

   In terms of [IEEE 802.21], the Media Independent Handover Function
   (MIHF) is a logical entity, which can facilitate MIH decision making
   based on inputs from the MIHF. MIHF can provide abstracted services
   for higher layers. Furthermore, it can communicate with the lower 
   layer of the mobility-management protocol stack through technology 
   specific interfaces in MIHF.

   MIF API and MIHF, are both working in different layers and defined by 
   different organizations. Thus, the requirements of compatibility are 
   distinct. Connection manager (i.e. the MIHF) SHOULD support some of 
   the functions of MIF API, and vice versa. The MIF API can use the 
   capabilities of MIHF to hand over issues based on the advantages of 
   MIHF and its Service Access Point (SAP). Message calls of MIF API is 
   extended by this document to support the MIH. Similar with 
   [I-D.ietf-mif-api-extension], because they are left up to the 
   implementation, there are no bindings for programming languages being 
   provided. This document only illustrates the messages sending and 
   receiving, which 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].

Zhang, et al            Expires November 18, 2019             [Page 3]
Internet-Draft            MIF API extension                   May 2019

3. The Relationship between IEEE MIHF and MIF API

   The purpose of IEEE 802.21 is to extend the user experience of
   mobile devices through facilitating handover among all IEEE.802
   networks despite whether they are of different media types or not, 
   including both wired and wireless. Also, the aim is to make it 
   possible for mobile devices to perform seamless handover between
   IEEE 802 and non IEEE networks. This standard defines:

   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.

   MIHF is a functional entity to fulfill the high-performance 
   handovers. The essential advantage of MIHF is that it provides
   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.

   What's more, three kinds of SAPs (will be detailed later) of MIHF 
   are also defined 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 to meet 
   the subscribers' need. Therefore, MIHF should work under MIF API.
   In fact, MIF API SHOULD be served as a user of MIHF, as shown in 
   Figure 1. The subscribers can then only interact with the MIHF via 
   one kind of SAPs (i.e. MIH_SAP) without knowing the lower things. 
   The MIH protocol is not in the scope of this document.

   Three kinds of MIHF services are defined in the standard: Media
   Independent Event Service (MIES), Media Independent Command Service
   (MICS) and Media Independent Information Service (MIIS).

   MIES provides event's degree, for event filtering and event 
   eporting 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 layers for the detection of handover 
   requirement. MTH users manage and control link behavior related to  

Zhang, et al            Expires November 18, 2019             [Page 4]
Internet-Draft            MIF API extension                   May 2019

   handover and mobility through MICS. It is invoked by users or MIHF 
   and has an impact on MIHF or lower layers.

   For example, in MN-initiated handover scenario, MICS is adopted for
   MN switching between different links. MIIS makes it possible for MN
   and network entities discovering information which has effect on
   the selection of appropriate networks during handovers. Figure 2
   [IEEE 802.21] shows MIH services and their initiation.

   +------------------------------------------------------+
   |                                                      |
   |                    Application                       |
   |                                                      |
   +---+--------+-------+---+------------+-----+----------+
       ^        |       ^   |            ^     |
       |        |       |   |            |     |
       |        v       |   |            |     |
   +---+--------+----+  |   |            |     |
   |                 |  |   |            |     |
   | High Level API  |  |   |            |     |
   |                 |  |   |            |     |
   +---+--------+----+  |   |            |     |
       ^        |       |   |            |     |
       |        |       |   |            |     |
       |        v       |   v            |     |
   +---+--------+-------+---+----+       |     |
   |                             |       |     |
   |         MIF API             |       |     |
   |                             |       |     |
   +---+--------+----------------+       |     |
       |        |                        |     v
       |        |       +----------------+-----+-----------+
       |        |       |                                  |
       |        |       |         Communication API        |
       |        |       |                                  |
       |        |       +---------+----+-------------------+
       |        |                 ^    ^
       |        |                 |    |
       |        |                 v    v
   +---+--------+-----------------+----+-------------------+
   |                                                       |
   |                         MIHF                          |
   |                                                       |

Zhang, et al            Expires November 18, 2019             [Page 5]
Internet-Draft            MIF API extension                   May 2019

   +-------------+------------------------+----------------+
                 ^                        |
                 |                        |
   +-------------+------------------------v----------------+
   |                                                       |
   |                  Network Link API                     |
   |                                                       |
   +------+--------+-----------------------+-------+-------+
          ^        |                       ^       |
          |        |                       |       |
          |        |                       |       |
   +------+--------v-----+          +------+-------v-------+
   |                     |          |                      |
   |        Network      |          |       Network        |
   |      Interface 1    |          |     Interface 2      |
   |                     |          |                      |
   +---------------------+          +----------------------+
             The relationship of the MIHF & MIF API

   The letters a, b, c in Figure 2 respectively represent:
   a. MIH_SAP
   b. MIH_LINK_SAP
   c. LLC_SAP
   The SAPs are divided into two categories:
   1) Media dependent SAP (including MIH_LINK_SAP and LLC_SAP).
   2) Media independent SAP (MIH_SAP).

   +--------------+-+    Command     +--------------------------------+
   |              |      Service     |                                |
   |              |                  |       MIH User                 |
   |           +--+--+  <---------+  |                                |
   |           |     |               |       Layer 3 or Higher        |
   | MIHF      |     |  Event        |       Mobility Protocol        |
   |           |     |  Service      |                                |
   | Event     |  a  |               |                                |
   | Service   |     | +-----------> |                                |
   |           |     |  Information  |                                |

Zhang, et al            Expires November 18, 2019              [Page 6]
Internet-Draft            MIF API extension                   May 2019

   | Command   |     |  Service      |   +--------+       +--------+  |
   | Service   |     |               +---+   c  +-+----+--+    c   +--+
   |           +--+--+  <----------> |   |        | |     |  |     |  |
   | Information  |     Command      |   +--------+ |     |  +-----+  |
   | Service      |     Service    +-+--+           |     |           |
   |              |                |    |           |     |           |
   |              | +----------->  |    |           |     |           |
   |              |     Event      |    | Network1  | +-+--+ Network2 |
   |              |     Service    |  b | (e.g.IEEE | |    |(e.g.IEEE |
   |              |                |    |  802.16)  | |  b |  802.11) |
   |              |  <----------+  |    |           | |    |          |
   |              |     Information|    |           | |    |          |
   |              |     Service    |    |           | |    |          |
   |              |                +-+--+           | |    |          |
   |              | <------------>   |              | +---++          |
   |              |                  |              |     |           |
   |              |                  |              |     |           |
   |              |                  +--------------+     +-----------+
   +--------------+
                     MIH services and their initiation

   SAP of the MIHF (i.e. MIH_SAP) is media independent. The interface
   between the MIHF and MIH users is defined by the MIH_SAP 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. MIHF is
   allowed by MIH_SAP 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 uses 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. These messages define how the MIF API interacts 
   with higher layers or applications and need to be added to this 
   collection for the switching process. These new messages SHOULD
   be exchanged between MIHF and MIF API. The service of MIHF is used
   by some of them.

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

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

Zhang, et al            Expires November 18, 2019             [Page 7]
Internet-Draft            MIF API extension                   May 2019

   4.1. The MN-initiated Handover

   The handover initiated by MN includes the following seven steps:

   1) Information query. The MN collects network information from the
   MIIS server which 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 need to be added, which describes
   interactions between a MIHF and MIF APIs.

   4.1.1. Get Information

   This message is sent by the MIF API for the inquiring of the
   neighboring networks information. In MIH, the MIH_Get_Information is
   used to request for the same purpose. After receiving this message,
   the MIHF inquires the MIIS server for the information, which will
   return a list of network information for MIF API.

   4.1.2. Information Post

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

   4.1.3. Parameter Report

   The lower layers link status needs to be sent to the MIF API to
   better control the whole connection when connecting to a specific
   network. Reports can be sent to the MIHF from the link layers and   

Zhang, et al            Expires November 18, 2019             [Page 8]
Internet-Draft            MIF API extension                   May 2019

   then submit to the higher layers. If the link is breaking down, the 
   MIF API must notify its subscribers using "Interface is going away"
   message. The application or higher API SHOULD construct new
   connections by sending "Wants to connect" to MIHF and the connection
   process will restart from step 2 (i.e. Resource availability check).

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

   4.1.4. Check Resources MN

   In the connection starts period, the resource availability SHOULD
   be checked by the MN at the candidate networks. MIF API sends this 
   message to the MIHF. Then, the service network should request each 
   candidate. The higher layer can receive the final result. 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 submit these messages to the MIF
   API. The MIH_MN_HO_Candidate_Query confirm can be used in the MIH
   case.

   4.1.6. Connect to Interface

   Upper applications sends this message to the MIF API. When the MIF 
   API receives the resource availability, it could post the message 
   to the higher layer. The upper application use "Connect to Interface" 
   to choose a better network interface. More about the choosing methods
   needs further discussion.

   4.1.7. Resource Preparation Messages

   The MIF API can use the MIH_MN_HO_Commit request, which includes the
   target network information to request the network choose for resource
   preparation. When the preparation is done, the MIHF receives the 
   response from the target network. In order to inform the status of the
   previously issued target notification request, it sends a
   MIH_MN_HO_Commit confirm message to the MIF API.

   4.1.8. Establish Link Messages

   The connection establishment problem can be solved by MIF API using
   the MIH_Link_Action request. The [IEEE 802.21] defines this message

Zhang, et al            Expires November 18, 2019             [Page 9]
Internet-Draft            MIF API extension                   May 2019

   primitively to control the local or remote lower link layers. It
   includes a MIHF ID and a Link Actions List, which can realize many
   controlling functions. After the action having been executed, the 
   MIF API should receive a MIH_Link_Action confirm to indicate the
   result. 

   4.1.9. Link Up

   After the new link being established, a Link_Up indication is
   delivered by MAC layers to MIHF. The MIHF then passes the
   MIH_Link_Up indication message to the MIF API. The upper 
   applications can be notified by the MIF API using 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

   MIHF sends this message to MIF API, which indicates that the 
   resource of the previous network is successfully released.

   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 seven steps in an intact network-initiated handover,
   like the MN-initiated handover:

   1) Information query.

   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 MIH user of the serving network can 
   initiate the Get Information Request and Information Query 

Zhang, et al            Expires November 18, 2019            [Page 10]
Internet-Draft            MIF API extension                   May 2019

   respectively. Such MIH user will send requests to the MN for a 
   response message containing the MN's handover acknowledgement 
   for MN's preferring link and PoS lists, when it obtains the 
   information from the MIIS server.

   In step 3, MIH user of the service network initiates the commitment 
   of target network . The PoS of serving network SHOULD notify the MN 
   for the establishment of L2 connection in step 4, after the resource 
   being prepared.

   The following messages should be added in MIF API.

   4.2.1. Candidate Query Notification

   The PoS of the serving network sends this message to MN's MIHF with 
   a list of PoAs of each candidate network link. Such message suggests
   the MN SHOULD consider new access network. This message can use the 
   MIH_Net_HO_Candidate_Query indication.

   4.2.2. Candidate Query Result

   MN's MIF API sends this message to the local serving network's MIHF, 
   specifying whether the request of handover is permitted or not. 
   MIH_Net_HO_Candidate_Query response can be used here. , the new 
   access network SHOULD be considered during the handover initiation 
   phase when the handover is allowed.

   4.2.3. Check Resources Net

   The PoS of serving network sends this message to the MN's MIF API 
   with a list of target network information and a set of resource 
   parameters assigned to the MN for handover.

   MIH_Net_HO_Commit indication can be used. Then the establishment of
   L2 can be triggered by the MIF API using Link_Action request. MIF 
   API needs inform the serving network after the link connection being 
   done. Link_Action request might also have a list of actions for
   handover control during the link connection period.

   4.2.4. Confirm Chosen Target

   The MN's MIF API sent this message as a response to the
   MIH_HO_Commit indication, revealing that the indication is received.
   MIH_Net_HO_Commit response can be used. Also such message might
   include a list of the results of previous actions.

Zhang, et al            Expires November 18, 2019            [Page 11]
Internet-Draft            MIF API extension                   May 2019

   4.2.5. Establish Link Messages

   This message is exactly the same as which 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 successful.

   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 bellowing messages
   are only the examples. Further updating is 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 data within a network interface or an extended schema of a 
   given network. As "Announce Interface", "Announce PVD" and "Announce 
   IE(Information Elements)" are sent by an advanced application or 
   upper APIs, the MIF API could obtain the information via the
   Get_information request in MIH.

   5.2. Release the Ongoing Connection

   The [I-D.ietf-mif-api-extension] defines a message "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

Zhang, et al            Expires November 18, 2019            [Page 12]
Internet-Draft            MIF API extension                   May 2019

   ongoing connection" to the MIHF so that directly releasing the
   current resources of network to cut off this connection, which will
   not weaken the application function.

   5.3. Establish New L2 Connection

   According to [IEEE 802.21], a L2 link connection can be triggered by
   the MIH_Link_Actions. The MIF API will receive "Connect to Address"
   or "Connect to Address from Address" messages, when MN wants to
   build a TCP connection with an IP host. Then the MIF API can use the
   MIH_Link_Actions request to ask MIHF for 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. Even though some of
   them have been discussed above, the specific usage of the rest is
   not represented. This section presents only a direct list of their
   category and brief descriptions. Further discussion is 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

   +---------------------+--------------------------------------------+
   | 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                      |

Zhang, et al            Expires November 18, 2019            [Page 13]
Internet-Draft            MIF API extension                   May 2019

   +---------------------+--------------------------------------------+
   | MIH_Link_Down       |  L2 connection is broken and link is       |
   |                     |  not available for use                     |
   +---------------------+--------------------------------------------+
   | MIH_Link_Paremeters |  Link parameters have crossed a speci-     |
   | _Report             |  fied 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 ei-      |
   | _Imminent           |  ther the changes in the link condition    |
   |                     |  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

   +---------------------+--------------------------------------------+
   | 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_          | Command used by MN to query and obtain     |
   | _Candidate 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  |

Zhang, et al            Expires November 18, 2019            [Page 14]
Internet-Draft            MIF API extension                   May 2019

   +---------------------+--------------------------------------------+
   | 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 informatio|
   +---------------------+--------------------------------------------+
   | 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_         | Notification from MIHF of the MN to the    |
   | Complete            | target or source MIHF indicating the       |
   |                     | status of handover completion              |
   +---------------------+--------------------------------------------+
   | MIH_N2N_HO          | Notification from either source or target  |
   | Complete            | MIHF to the peer MIHF indicating the status|
   |                     | of the handover completion                 |
   +---------------------+--------------------------------------------+
                     Table 3 Command Messages of MIHF

   +---------------------+-------------------------------------------+
   | 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

Zhang, et al            Expires November 18, 2019            [Page 15]
Internet-Draft            MIF API extension                   May 2019

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.

   10. Acknowledgments

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

Zhang, et al            Expires November 18, 2019            [Page 16]
Internet-Draft            MIF API extension                   May 2019

   Authors' Addresses

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

   Email: hkzhang@bjty.edu.cn

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

   Email: fsong@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

Zhang, et al            Expires November 18, 2019             [Page 17]