MIF Hongke Zhang
Internet Draft Fei Song
Intended status: Informational Boxin Du
Expires: May 18 2018 Mi Du
Mi Zhang
Beijing Jiaotong University
November 17, 2017
MIF API extension for combining IEEE 802.2
draft-zhang-mif-api-extension-802-21-07.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 May 18, 2018.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires May 17,2018 [Page 1]
Internet-Draft MIF API extension NOV 2017
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.
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.
Abstract
The Application Program Interface (API) of MIF, specified in the
MIFAPI consideration, must rely on 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 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
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 ................................................ 4
2. Terminology ................................................. 4
3. The Relationship between IEEE MIHF and MIF API ............... 5
Zhang, et al. Expires May 17, 2018 [Page 2]
Internet-Draft MIF API extension NOV 2017
4. The Extension of MIF API for Handover: A Case Study........... 9
4.1. The MN-initiated Handover ............................... 9
4.1.1. Get Information ................................... 10
4.1.2. Information Post .................................. 10
4.1.3. Parameter Report .................................. 10
4.1.4. Check Resources MN ................................ 10
4.1.5. Resource Availability ............................. 11
4.1.6. Connect to Interface .............................. 11
4.1.7. Resource Preparation Messages ..................... 11
4.1.8. Establish Link Messages ........................... 11
4.1.9. Link Up ............................................ 11
4.1.10. Handover Completed ................................ 12
4.1.11. Handover Completion Confirmation .................. 12
4.2. The Network-initiated Handover ......................... 12
4.2.1. Candidate Query Notification ...................... 13
4.2.2. Candidate Query Result ............................ 13
4.2.3. Check Resources Net ............................... 13
4.2.4. Confirm Chosen Target ............................. 13
4.2.5. Establish Link Messages ........................... 14
4.2.6. Link Up ........................................... 14
4.2.7. Handover Completed ................................ 14
4.2.8. Handover Completion Confirmation .................. 14
5. Discussions for New Messages from MIF Perspective ........... 14
5.1. Get Information ........................................ 14
5.2. Release the Ongoing Connection ......................... 15
5.3. Establish New L2 Connection ............................ 15
6. Discussions for New Messages from IEEE Perspective .......... 15
7. Security Considerations ..................................... 18
8. IANA Considerations ........................................ 18
9. References ................................................. 19
9.1. Normative References ................................... 19
9.2. Informative References ................................. 19
10. Acknowledgments ........................................... 19
Zhang, et al. Expires May 17, 2018 [Page 3]
Internet-Draft MIF API extension NOV 2017
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]. Even though the MIF Application Program
Interface (API) specified in the MIF API consideration [I-D.ietf-
mif-api-extension] illustrates a series of message 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. Abstracted services can be provided
for higher layers by MIHF. Also, it can communicate with the lower
layer of the mobility-management protocol stack through technology-
specific interfaces in MIHF.
As two mechanisms, MIF API and MIHF, are working in different layers
and defined by different organizations, 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
functions of MIHF could be utilized in MIF API in order to handover
issues according to the advantages of both MIHF and its Service
Access Points (SAPs). 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 May 17, 2018 [Page 4]
Internet-Draft MIF API extension NOV 2017
3. The Relationship between IEEE MIHF and MIF API
The purpose of IEEE 802.21 is to further the user experience of
mobile devices through facilitating handover among all IEEE.802
networks despite of whether they are of different media types or not,
including both wired and wireless. Also, the target 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 fundamental 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.
Besides, 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 for meeting
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).
Zhang, et al. Expires May 17, 2018 [Page 5]
Internet-Draft MIF API extension NOV 2017
MIES provides event's degree, for event filtering and 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 layers for the detection of handover
requirement. MTH users manage and control link behavior relevant to
handover and mobility by MICS. 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 makes it possible for MN
and network entities discovering information which has influence 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 |
Zhang, et al. Expires November 15, 2018 [Page 6]
Internet-Draft MIF API extension NOV 2017
| | | |
| | +---------+----+-------------------+
| | ^ ^
| | | |
| | v v
+---+--------+-----------------+----+-------------------+
| |
| MIHF |
| |
+-------------+------------------------+----------------+
^ |
| |
+-------------+------------------------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).
Zhang, et al. Expires November 15, 2018 [Page 7]
Internet-Draft MIF API extension NOV 2017
+--------------+-+ Command +------------------------------------+
| | Service | |
| | | MIH User |
| +--+--+ <---------+ | |
| | | | Layer 3 or Higher |
| MIHF | | Event | Mobility Protocol |
| | | Service | |
| Event | a | | |
| Service | | +-----------> | |
| | | Information | |
| 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 use the service primitives of the MIH_SAP.
Zhang, et al. Expires May 17, 2018 [Page 8]
Internet-Draft MIF API extension NOV 2017
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 the way that MIF API
interacts with the higher layers or applications and need to be
added into this set for handover 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 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). In order 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
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.
Zhang, et al. Expires May 17, 2018 [Page 9]
Internet-Draft MIF API extension NOV 2017
7)Resource release. The original serving network resources must be
released in the end.
The following messages need to be added, which describe interactions
between a MIHF and MIF APIs.
4.1.1. Get Information
This message is sent by the MIF API for the inquiry of the
neighboring networks information. In MIH, the MIH_Get_Information. is
use 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
then submit to the higher layers. If the link is going down, the MIF
API must notify its subscribers using "Interface is going away"
message. The application or higher API SHOULD establish 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. This message is sent to
the MIHF by the MIF API. Then each candidate SHOULD be requested by
Zhang, et al. Expires May 17, 2018 [Page 10]
Internet-Draft MIF API extension NOV 2017
the serving network. 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 submits 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
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 use "Connect to
Interface" to choose a better network interface. More about the
choosing methods need 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 chose for resource
preparation. The MIHF receives the response from the target network
when the preparation is done. 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. This message primitively 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 controlling functions. The MIF API should receive a
MIH_Link_Action. confirm to indicate the result, after the action has
been executed.
4.1.9. Link Up
After the new link is established, a Link_Up. indication is delivered
by MAC layers to MIHF. The MIHF then passes the MIH_Link_Up.
Zhang, et al. Expires May 17, 2018 [Page 11]
Internet-Draft MIF API extension NOV 2017
indication message to the MIF API. The MIF API can notify the upper
applications 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
This message is sent to the MIF API by the MIHF, 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
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.
Zhang, et al. Expires May 17, 2018 [Page 12]
Internet-Draft MIF API extension NOV 2017
In step 3, the commitment 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
MN's MIHF receives this message from the PoS of the serving network
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
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. A new
access network SHOULD be considered at the handover initiation stage,
when the handover is permitted.
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 handover.
MIH_Net_HO_Commit. indication can be used. TThen the establishment of
L2 can be triggered by the MIF API using Link_Action. request. After
the link connection is done, MIF API needs 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
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 May 17, 2018 [Page 13]
Internet-Draft MIF API extension NOV 2017
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
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 messages below 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.
Zhang, et al. Expires May 17, 2018 [Page 14]
Internet-Draft MIF API extension NOV 2017
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
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
Zhang, et al. Expires May 17, 2018 [Page 15]
Internet-Draft MIF API extension NOV 2017
+---------------------+--------------------------------------------+
| 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 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
Zhang, et al. Expires May 17, 2018 [Page 16]
Internet-Draft MIF API extension NOV 2017
+---------------------+--------------------------------------------+
| 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 |
+---------------------+--------------------------------------------+
| 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
Zhang, et al. Expires May 17, 2018 [Page 17]
Internet-Draft MIF API extension NOV 2017
+---------------------+-------------------------------------------+
| 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.
Zhang, et al. Expires May 17, 2018 [Page 18]
Internet-Draft MIF API extension NOV 2017
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicat
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 May 17, 2018 [Page 19]
Internet-Draft MIF API extension NOV 2017
Authors' Addresses
Hongke Zhang
Beijing Jiaotong University (BJTU)
Beijing, 100044, P.R.China
Email: hkzhang@bjtu.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 May 17, 2018 [Page 20]