< draft-zhang-mif-api-extension-802-21-09.txt   draft-zhang-mif-api-extension-802-21-10.txt >
MIF Hongke Zhang MIF Hongke Zhang
Internet Draft Fei Song Internet Draft Fei Song
Intended status: Informational Boxin Du Intended status: Informational Boxin Du
Expires: May 18 2019 Mi Zhang Expires: November 18 2019 Mi Zhang
Beijing Jiaotong University Beijing Jiaotong University
Nov 15,2018 May 14,2019
MIF API extension for combining IEEE 802.2 MIF API extension for combining IEEE 802.2
draft-zhang-mif-api-extension-802-21-09.txt draft-zhang-mif-api-extension-802-21-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in reference material or to cite them other than as "work in
progress." This Internet-Draft will expire on May 18, 2019. progress." This Internet-Draft will expire on November 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
The Application Program Interface (API) of MIF, specified in the MIF The Application Program Interface (API) of MIF, specified in the MIF
API consideration, must rely on lower layer functionalities when API consideration, must lean upon lower layer functionalities when
handover between homogeneous or heterogeneous networks is necessary. handover between homogeneous or heterogeneous networks is necessary.
To improve the connectivity performance, the existing MIF API needs To improve the connectivity performance, the existing MIF API needs
to be extended. IEEE is also aimed at the similar issue from to be extended. IEEE also aims at the similar issue from different
different way. A kind of logical entities over the link layer way. A kind of logical entities over the link layer protocol for
protocol for handling the seamless handover has been defined in handling the seamless handover has been defined in IEEE802.21. This
IEEE802.21. This document proposes a mechanism via integrating MIF document proposes a mechanism via integrating MIF API and IEEE
API and IEEE 802.21 to support application service better. 802.21 to support application service better.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
2. Terminology ................................................. 3 2. Terminology ................................................. 3
3. The Relationship between IEEE MIHF and MIF API ...............4 3. The Relationship between IEEE MIHF and MIF API ...............4
4. The Extension of MIP API for Handover: A Case Study...........7 4. The Extension of MIP API for Handover: A Case Study...........7
4.1. The MN-initiated Handover............................... 8 4.1. The MN-initiated Handover............................... 8
4.1.1. Get Information.................................... 8 4.1.1. Get Information.................................... 8
4.1.2. Information Post................................... 8 4.1.2. Information Post................................... 8
skipping to change at page 3, line 12 skipping to change at page 3, line 12
7. Security Considerations..................................... 16 7. Security Considerations..................................... 16
8. IANA Considerations ........................................ 16 8. IANA Considerations ........................................ 16
9. References ................................................. 16 9. References ................................................. 16
9.1. Normative References................................... 16 9.1. Normative References................................... 16
9.2. Informative References................................. 16 9.2. Informative References................................. 16
10. Acknowledgments ........................................... 16 10. Acknowledgments ........................................... 16
1. Introduction 1. Introduction
In MIF context, the improvement of connectivity experiences SHOULD In MIF context, the improvement of connectivity experiences SHOULD
be produced. The main target is to enhance the performance of be produced. Enhancing the performance of horizontal and vertical
horizontal and vertical switches between networks. The switches between networks is the main target. The aforementioned
aforementioned situation is quite similar with Media Independent situation is quite similar with Media Independent Handover (MIH)
Handover (MIH) described in [IEEE 802.21]. Even though the MIF described in [IEEE 802.21]. Although the MIF Application Program
Application Program Interface (API) specified in the MIF API Interface (API) specified in the MIF API consideration
consideration [I-D.ietf-mif-api-extension] illustrates a series of [I-D.ietf-mif-api-extension] illustrates a series of messages in
message in multiple interface scenarios, this draft only provides a multiple interface scenarios, this draft only provides a minimal set
minimal set of message calls REQUIRED to implement the API. Hence, of message calls REQUIRED to implement the API. Hence, new functions
new functions could be added. could be added.
In terms of [IEEE 802.21], the Media Independent Handover Function In terms of [IEEE 802.21], the Media Independent Handover Function
(MIHF) is a logical entity, which can facilitate MIH decision making (MIHF) is a logical entity, which can facilitate MIH decision making
based on inputs from the MIHF. MIHF can provide abstracted services based on inputs from the MIHF. MIHF can provide abstracted services
for higher layers. Also, it can communicate with the lower layer of for higher layers. Furthermore, it can communicate with the lower
the mobility-management protocol stack through technology specific layer of the mobility-management protocol stack through technology
interfaces in MIHF. specific interfaces in MIHF.
As two mechanisms, MIF API and MIHF, are working in different layers MIF API and MIHF, are both working in different layers and defined by
and defined by different organizations. Thus, the requirements of different organizations. Thus, the requirements of compatibility are
compatibility are distinct. Connection manager (i.e. the MIHF) distinct. Connection manager (i.e. the MIHF) SHOULD support some of
SHOULD support some of the functions of MIF API, and vice versa. the functions of MIF API, and vice versa. The MIF API can use the
The MIF API can use the capabilities of MIHF to hand over issues capabilities of MIHF to hand over issues based on the advantages of
based on the advantages of MIHF and its Service Access Point (SAP). MIHF and its Service Access Point (SAP). Message calls of MIF API is
Message calls of MIF API is extended by this document to support the extended by this document to support the MIH. Similar with
MIH. Similar with [I-D.ietf-mif-api-extension], because they are left [I-D.ietf-mif-api-extension], because they are left up to the
up to the implementation, there are no bindings for programming implementation, there are no bindings for programming languages being
languages being provided. This document only illustrates the messages provided. This document only illustrates the messages sending and
sending and receiving, which can be read as a checklist for operating receiving, which can be read as a checklist for operating system
system vendors. vendors.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
3. The Relationship between IEEE MIHF and MIF API 3. The Relationship between IEEE MIHF and MIF API
The purpose of IEEE 802.21 is to further the user experience of The purpose of IEEE 802.21 is to extend the user experience of
mobile devices through facilitating handover among all IEEE.802 mobile devices through facilitating handover among all IEEE.802
networks despite of whether they are of different media types or networks despite whether they are of different media types or not,
not, including both wired and wireless. Also, the target is to make including both wired and wireless. Also, the aim is to make it
it possible for mobile devices to perform seamless handover between possible for mobile devices to perform seamless handover between
IEEE 802 and non IEEE networks. This standard defines: IEEE 802 and non IEEE networks. This standard defines:
1. A framework that enables service continuity while a Mobile Node 1. A framework that enables service continuity while a Mobile Node
(MN) transitions between heterogeneous link-layer technologies. (MN) transitions between heterogeneous link-layer technologies.
2. MIHF 2. MIHF
3. MIH_SAP and associated primitives for users to get services of 3. MIH_SAP and associated primitives for users to get services of
MIHF. MIHF.
4. The definitions of new link-layer SAPs and associated primitives 4. The definitions of new link-layer SAPs and associated primitives
for each link-layer technology. They help MIHF to collect link for each link-layer technology. They help MIHF to collect link
information and control link behaviors during handovers. information and control link behaviors during handovers.
MIHF is a functional entity to fulfill the high- performance MIHF is a functional entity to fulfill the high-performance
handovers. The fundamental advantage of MIHF is that it provides handovers. The essential advantage of MIHF is that it provides
media-specific technology of lower layer is being used, such as IEEE media-specific technology of lower layer is being used, such as
Std.802.3, IEEE Std.802.11, IEEE Std.802.16, 3GPP and 3GPP2. 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 What's more, three kinds of SAPs (will be detailed later) of MIHF
also defined and their primitives that interact between different are also defined and their primitives that interact between
layers. different layers.
The MIHF can also act as a filter: the messages received from link The MIHF can also act as a filter: the messages received from link
layer SHOULD be processed and submitted to higher layer for meeting layer SHOULD be processed and submitted to higher layer to meet
the subscribers' need. Therefore, MIHF should work under MIF API. In the subscribers' need. Therefore, MIHF should work under MIF API.
fact, MIF API SHOULD be served as a user of MIHF, as shown in Figure In fact, MIF API SHOULD be served as a user of MIHF, as shown in
1. The subscribers can then only interact with the MIHF via one kind Figure 1. The subscribers can then only interact with the MIHF via
of SAPs (i.e. MIH_SAP) without knowing the lower things. The MIH one kind of SAPs (i.e. MIH_SAP) without knowing the lower things.
protocol is not in the scope of this document. The MIH protocol is not in the scope of this document.
Three kinds of MIHF services are defined in the standard: Media Three kinds of MIHF services are defined in the standard: Media
Independent Event Service (MIES), Media Independent Command Service Independent Event Service (MIES), Media Independent Command Service
(MICS) and Media Independent Information Service (MIIS). (MICS) and Media Independent Information Service (MIIS).
MIES provides event's degree, for event filtering and event MIES provides event's degree, for event filtering and event
reporting corresponding to dynamic changes in link characteristics, eporting corresponding to dynamic changes in link characteristics,
link status and link quality. It originates from lower layers and link status and link quality. It originates from lower layers and
can be passed to MIHF or upper layers for the detection of handover can be passed to MIHF or upper layers for the detection of handover
requirement. MTH users manage and control link behavior related to requirement. MTH users manage and control link behavior related to
handover and mobility through MICS. It is invoked by users or MIHF handover and mobility through MICS. It is invoked by users or MIHF
and has an impact on MIHF or lower layers. and has an impact on MIHF or lower layers.
For example, in MN-initiated handover scenario, MICS is adopted for For example, in MN-initiated handover scenario, MICS is adopted for
MN switching between different links. MIIS makes it possible for MN MN switching between different links. MIIS makes it possible for MN
and network entities discovering information which has influence on and network entities discovering information which has effect on
the selection of appropriate networks during handovers. Figure 2 the selection of appropriate networks during handovers. Figure 2
[IEEE 802.21] shows MIH services and their initiation. [IEEE 802.21] shows MIH services and their initiation.
+------------------------------------------------------+ +------------------------------------------------------+
| | | |
| Application | | Application |
| | | |
+---+--------+-------+---+------------+-----+----------+ +---+--------+-------+---+------------+-----+----------+
^ | ^ | ^ | ^ | ^ | ^ |
| | | | | | | | | | | |
skipping to change at page 7, line 28 skipping to change at page 7, line 28
| | <------------> | | +---++ | | | <------------> | | +---++ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | +--------------+ +-----------+ | | +--------------+ +-----------+
+--------------+ +--------------+
MIH services and their initiation MIH services and their initiation
SAP of the MIHF (i.e. MIH_SAP) is media independent. The interface 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 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) upper layer mobility protocol or a handover function (e.g., MIF API)
that might reside at higher layer transport entity as well.MIHF is that might reside at higher layer transport entity as well. MIHF is
allowed by MIH_SAP to provide services to the upper layers, the allowed by MIH_SAP to provide services to the upper layers, the
network management plane and the data bearer plane. Upper layers network management plane and the data bearer plane. Upper layers
need to subscribe with the MIHF as users to receive MIHF events. In need to subscribe with the MIHF as users to receive MIHF events. In
MIF case, the MIF API can send commands to the local MIHF via MIF case, the MIF API can directly send commands to the local MIHF via
messages which uses the service primitives of the MIH_SAP directly. messages which uses the service primitives of the MIH_SAP.
All the messages REQUIRED for communicating successfully in MIF All the messages REQUIRED for communicating successfully in MIF
environment that described in the [I-D.ietf-mif-api-extension] MUST environment that described in the [I-D.ietf-mif-api-extension] MUST
also be used here. These messages define how the MIF API interacts also be used here. These messages define how the MIF API interacts
with higher layers or applications and need to be added to this with higher layers or applications and need to be added to this
collection for the switching process. These new messages SHOULD collection for the switching process. These new messages SHOULD
be exchanged between MIHF and MIF API. The service of MIHF is used be exchanged between MIHF and MIF API. The service of MIHF is used
by some of them. by some of them.
4. The Extension of MIP API for Handover: A Case Study 4. The Extension of MIP API for Handover: A Case Study
This section introduces the extension of message calls of MIF API in This section introduces the extension of message calls of MIF API in
two parts based on the classification of handovers (MN-initiated two parts depends on the classification of handovers (MN-initiated
handover and the network-initiated handover). In order to handle handover and the network-initiated handover). In order to handle
these two kinds of handovers successfully, MIF API SHOULD be these two kinds of handovers successfully, MIF API SHOULD be
extended respectively based on the characteristics of process. extended respectively based on the characteristics of process.
4.1. The MN-initiated Handover 4.1. The MN-initiated Handover
The handover initiated by MN includes the following seven steps: The handover initiated by MN includes the following seven steps:
1) Information query. The MN collects network information from the 1) Information query. The MN collects network information from the
MIIS server which the MN is connected to. MIIS server which the MN is connected to.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
6) Higher layer handover execution. 6) Higher layer handover execution.
7) Resource release. The original serving network resources must be 7) Resource release. The original serving network resources must be
released in the end. released in the end.
The following messages need to be added, which describes The following messages need to be added, which describes
interactions between a MIHF and MIF APIs. interactions between a MIHF and MIF APIs.
4.1.1. Get Information 4.1.1. Get Information
This message is sent by the MIF API for the inquiry of the This message is sent by the MIF API for the inquiring of the
neighboring networks information. In MIH, the MIH_Get_Information is neighboring networks information. In MIH, the MIH_Get_Information is
used to request for the same purpose. After receiving this message, used to request for the same purpose. After receiving this message,
the MIHF inquires the MIIS server for the information, which will the MIHF inquires the MIIS server for the information, which will
return a list of network information for MIF API. return a list of network information for MIF API.
4.1.2. Information Post 4.1.2. Information Post
This message is sent to the MIF API by the MIIS server as a response 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 to the Get Information message. MIH_Get_Information confirm can be
used to convey such information. used to convey such information.
4.1.3. Parameter Report 4.1.3. Parameter Report
The lower layers link status needs to be sent to the MIF API to The lower layers link status needs to be sent to the MIF API to
better control the whole connection when connecting to a specific better control the whole connection when connecting to a specific
network. Reports can be sent to the MIHF from the link layers and 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 then submit to the higher layers. If the link is breaking down, the
API must notify its subscribers using "Interface is going away" MIF API must notify its subscribers using "Interface is going away"
message. The application or higher API SHOULD establish new message. The application or higher API SHOULD construct new
connections by sending "Wants to connect" to MIHF and the connection connections by sending "Wants to connect" to MIHF and the connection
process will restart from step 2 (i.e. Resource availability check). process will restart from step 2 (i.e. Resource availability check).
Another situation is, when the MIF API receives a "Wants to connect" Another situation is, when the MIF API receives a "Wants to connect"
message from its subscriber, it SHOULD trigger a whole connection message from its subscriber, it SHOULD trigger a whole connection
process to a new network accordingly. This can also begin from step process to a new network accordingly. This can also begin from step
2. 2.
4.1.4. Check Resources MN 4.1.4. Check Resources MN
In the connection starts period, the resource availability SHOULD In the connection starts period, the resource availability SHOULD
be checked by the MN at the candidate networks. This message is sent be checked by the MN at the candidate networks. MIF API sends this
to the MIHF by the MIF API. The service network should then request message to the MIHF. Then, the service network should request each
each candidate. The higher layer can receive the final result. The candidate. The higher layer can receive the final result. The
MIH_MN_HO_Candidate_Query request can be used in the MIH case. MIH_MN_HO_Candidate_Query request can be used in the MIH case.
4.1.5. Resource Availability 4.1.5. Resource Availability
When receiving the resource availability of the candidates from the When receiving the resource availability of the candidates from the
serving network, the MIHF SHOULD submit these messages to the MIF 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 API. The MIH_MN_HO_Candidate_Query confirm can be used in the MIH
case. case.
4.1.6. Connect to Interface 4.1.6. Connect to Interface
This message is sent to the MIF API by the upper applications. When Upper applications sends this message to the MIF API. When the MIF
the MIF API receives the Resource Availability, it could post the API receives the resource availability, it could post the message
message to the higher layer. The upper application use "Connect to to the higher layer. The upper application use "Connect to Interface"
Interface" to choose a better network interface. More about the to choose a better network interface. More about the choosing methods
choosing methods need further discussion. needs further discussion.
4.1.7. Resource Preparation Messages 4.1.7. Resource Preparation Messages
The MIF API can use the MIH_MN_HO_Commit request, which includes the The MIF API can use the MIH_MN_HO_Commit request, which includes the
target network information to request the network chose for resource target network information to request the network choose for resource
preparation. The MIHF receives the response from the target network preparation. When the preparation is done, the MIHF receives the
when the preparation is done. In order to inform the status of the response from the target network. In order to inform the status of the
previously issued target notification request, it sends a previously issued target notification request, it sends a
MIH_MN_HO_Commit confirm message to the MIF API. MIH_MN_HO_Commit confirm message to the MIF API.
4.1.8. Establish Link Messages 4.1.8. Establish Link Messages
The connection establishment problem can be solved by MIF API using The connection establishment problem can be solved by MIF API using
the MIH_Link_Action request. The [IEEE 802.21] defines this message the MIH_Link_Action request. The [IEEE 802.21] defines this message
primitively to control the local or remote lower link layers. It primitively to control the local or remote lower link layers. It
includes a MIHF ID and a Link Actions List, which can realize many includes a MIHF ID and a Link Actions List, which can realize many
controlling functions. The MIF API should receive a MIH_Link_Action controlling functions. After the action having been executed, the
confirm to indicate the result, after the action having been MIF API should receive a MIH_Link_Action confirm to indicate the
executed. result.
4.1.9. Link Up 4.1.9. Link Up
After the new link being established, a Link_Up indication is After the new link being established, a Link_Up indication is
delivered by MAC layers to MIHF. The MIHF then passes the delivered by MAC layers to MIHF. The MIHF then passes the
MIH_Link_Up indication message to the MIF API. The MIF API can MIH_Link_Up indication message to the MIF API. The upper
notify the upper applications using the "Link is going up" message. applications can be notified by the MIF API using the "Link is
Then the higher layer handover execution might be triggered and the going up" message. Then the higher layer handover execution might
traffic flow can be re-established. be triggered and the traffic flow can be re-established.
4.1.10. Handover Completed 4.1.10. Handover Completed
This message is sent to the MIF API by the MIHF, which indicates MIHF sends this message to MIF API, which indicates that the
that the resource of the previous network is successfully released. resource of the previous network is successfully released.
4.1.11. Handover Completion Confirmation 4.1.11. Handover Completion Confirmation
This message is sent to the MIF API by the MIHF indicating that the This message is sent to the MIF API by the MIHF indicating that the
resource of the previous network is successfully released. resource of the previous network is successfully released.
4.2. The Network-initiated Handover 4.2. The Network-initiated Handover
There are also seven steps in an intact network-initiated handover, There are also seven steps in an intact network-initiated handover,
like the MN-initiated handover: like the MN-initiated handover:
skipping to change at page 11, line 9 skipping to change at page 11, line 9
7) Resource release. 7) Resource release.
The differences between Network-initiated case and MN-initiated case 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 are in step 1 and step 2. The MIH user of the serving network can
initiate the Get Information Request and Information Query initiate the Get Information Request and Information Query
respectively. Such MIH user will send requests to the MN for a respectively. Such MIH user will send requests to the MN for a
response message containing the MN's handover acknowledgement response message containing the MN's handover acknowledgement
for MN's preferring link and PoS lists, when it obtains the for MN's preferring link and PoS lists, when it obtains the
information from the MIIS server. information from the MIIS server.
In step 3, the commitment of target network is also initiated by the In step 3, MIH user of the service network initiates the commitment
MIH user of the service network. After the resource being prepared, of target network . The PoS of serving network SHOULD notify the MN
the PoS of serving network SHOULD notify the MN for the for the establishment of L2 connection in step 4, after the resource
establishment of L2 connection in step 4. being prepared.
The following messages should be added in MIF API. The following messages should be added in MIF API.
4.2.1. Candidate Query Notification 4.2.1. Candidate Query Notification
MN's MIHF receives this message from the PoS of the serving network The PoS of the serving network sends this message to MN's MIHF with
with a list of PoAs of each candidate network link. Such message a list of PoAs of each candidate network link. Such message suggests
suggests the MN SHOULD consider new access network. This message can the MN SHOULD consider new access network. This message can use the
use the MIH_Net_HO_Candidate_Query indication. MIH_Net_HO_Candidate_Query indication.
4.2.2. Candidate Query Result 4.2.2. Candidate Query Result
This message is sent to the local serving network's MIHF from MN's MN's MIF API sends this message to the local serving network's MIHF,
MIF API, specifying whether the request of handover is permitted or specifying whether the request of handover is permitted or not.
not. MIH_Net_HO_Candidate_Query response can be used here. When the MIH_Net_HO_Candidate_Query response can be used here. , the new
handover is allowed, the new access network SHOULD be considered access network SHOULD be considered during the handover initiation
during the handover initiation phase. phase when the handover is allowed.
4.2.3. Check Resources Net 4.2.3. Check Resources Net
This message is sent to the MN's MIF API by the PoS of serving The PoS of serving network sends this message to the MN's MIF API
network with a list of target network information and a set of with a list of target network information and a set of resource
resource parameters assigned to the MN for handover. parameters assigned to the MN for handover.
MIH_Net_HO_Commit indication can be used. Then the establishment of MIH_Net_HO_Commit indication can be used. Then the establishment of
L2 can be triggered by the MIF API using Link_Action request. After L2 can be triggered by the MIF API using Link_Action request. MIF
the link connection is done, MIF API needs inform the serving API needs inform the serving network after the link connection being
network. Link_Action request might also have a list of actions for done. Link_Action request might also have a list of actions for
handover control during the link connection period. handover control during the link connection period.
4.2.4. Confirm Chosen Target 4.2.4. Confirm Chosen Target
The MN's MIF API sent this message as a response to the The MN's MIF API sent this message as a response to the
MIH_HO_Commit indication, revealing that the indication is received. MIH_HO_Commit indication, revealing that the indication is received.
MIH_Net_HO_Commit response can be used. Also such message might MIH_Net_HO_Commit response can be used. Also such message might
include a list of the results of previous actions. include a list of the results of previous actions.
4.2.5. Establish Link Messages 4.2.5. Establish Link Messages
This message is exactly the same as that of the MN-initiated This message is exactly the same as which of the MN-initiated
process, for establishing a new L2 link connection. process, for establishing a new L2 link connection.
4.2.6. Link up 4.2.6. Link up
This message is exactly the same as that of the MN-initiated This message is exactly the same as that of the MN-initiated
process, for informing the MIF API that the L2 link is completed. process, for informing the MIF API that the L2 link is completed.
4.2.7. Handover Completed 4.2.7. Handover Completed
This message is exactly the same as that of the MN-initiated This message is exactly the same as that of the MN-initiated
 End of changes. 34 change blocks. 
102 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/