idnits 2.17.1 draft-zhang-mif-api-extension-802-21-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 30, 2015) is 3070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIF Hongke Zhang 2 Internet Draft Boxin Du 3 Intended status: Informational Mi Zhang 4 Expires: May 28, 2016 Fei Song 5 Beijing Jiaotong University 6 November 30, 2015 8 MIF API extension for combining IEEE 802.21 9 draft-zhang-mif-api-extension-802-21-03.txt 11 Abstract 13 The Application Program Interface (API) of MIF, specified in the MIF 14 API consideration, must rely on lower layer functionalities when 15 handover between homogeneous or heterogeneous networks is necessary. 16 To improve the connectivity performance,the existing MIF API needs to 17 be extended. IEEE is also aimed at the similar issue from different 18 way. A kind of logical entities over the link layer protocol for 19 handling the seamless handover has been defined in IEEE 802.21. This 20 document proposes a mechanism via conbining the MIF API and IEEE 21 802.21 to support application service better. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 28, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ................................................ 4 58 2. Terminology ................................................. 4 59 3. The Relationship between IEEE MIHF and MIF API .............. 4 60 4. The Extension of MIF API for Handover: A Case Study.......... 8 61 4.1. The MN-initiated Handover .............................. 8 62 4.1.1. Get Information ................................... 8 63 4.1.2. Information Post .................................. 9 64 4.1.3. Parameter Report ................................. 9 65 4.1.4. Check Resources MN ................................ 9 66 4.1.5. Resource Availability ............................. 9 67 4.1.6. Connect to Interface .............................. 9 68 4.1.7. Resource Preparation Messages .................... 10 69 4.1.8. Establish Link Messages .......................... 10 70 4.1.9. Link Up .......................................... 10 71 4.1.10. Handover Completed .............................. 10 72 4.1.11. Handover Completion Confirmation ................ 10 73 4.2. The Network-initiated Handover ........................ 10 74 4.2.1. Candidate Query Notification ..................... 11 75 4.2.2. Candidate Query Result ........................... 11 76 4.2.3. Check Resources Net .............................. 11 77 4.2.4. Confirm Chosen Target ............................ 12 78 4.2.5. Establish Link Messages .......................... 12 79 4.2.6. Link Up .......................................... 12 80 4.2.7. Handover Completed ............................... 12 81 4.2.8. Handover Completion Confirmation ................. 12 82 5. Discussions for New Messages from MIF Perspective .......... 12 83 5.1. Get Information........................................ 12 84 5.2. Release the Ongoing Connection ........................ 13 85 5.3. Establish New L2 Connection .......................... 13 86 6. Discussions for New Messages from IEEE Perspective ......... 13 87 7. Security Considerations .................................... 16 88 8. IANA Considerations ........................................ 16 89 9. References ................................................. 16 90 9.1. Normative References ................................. 16 91 9.2. Informative References ................................ 16 92 10. Acknowledgments ........................................... 17 94 1. Introduction 96 In MIF context, improved connectivity experiences SHOULD be created. 97 Enhancing the performance of horizontal and vertical switches between 98 networks is one of the main targets. Such situation is quite similar 99 with Media Independent Handover (MIH) described in [IEEE 802.21]. The 100 MIF Application Program Interface (API) specified in the MIF API 101 consideration [I-D.ietf-mif-api-extension] describes a set of message 102 calls to implement higher level APIs that solve the problems in 103 multiple interface scenarios. However, this draft only provides a 104 minimal set of message calls REQUIRED to implement the API. New 105 functions could be added. 107 According to [IEEE 802.21], the Media Independent Handover Function 108 (MIHF) is a logical entity that facilitates MIH make decisions based 109 on the inputs from the MIHF. It provides abstracted services to 110 higher layers. Communications with the lower layer of the mobility- 111 management protocol stack can be achieved through technology-specific 112 interfaces in MIHF. 114 Although two mechanisms, MIF API and MIHF,work in different layers 115 and are defined by different organizations, the requirements of 116 compatibility are clear. Some of the functions of MIF API SHOULD be 117 supported by a connection manager (i.e. the MIHF), and vice versa. 118 Owing to the advantages of both MIHF and its Service Access Points 119 (SAPs), the functions of MIHF could be utilized in MIF API for 120 handover issues. This document extends message calls of MIF API to 121 support the MIH. Like [I-D.ietf-mif-api-extension], no bindings for 122 programming languages are provided because they are left up to the 123 implementation. This document only describes the messages sent and 124 received,which can be read as a checklist for operating system 125 vendors. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC-2119 [RFC2119]. 133 3. The Relationship between IEEE MIHF and MIF API 135 The purpose of IEEE 802.21 is to improve the user experience of 136 mobile devices by facilitating handover among all IEEE 802 networks 137 regardless of whether they are of different media types or not, 138 including both wired and wireless. It also aims at making it possible 139 for mobile devices to perform seamless handover between IEEE 802 and 140 non IEEE networks. This standard defines: 142 1) A framework that enables service continuity while a Mobile Node 143 (MN) transitions between heterogeneous link-layer technologies. 145 2) MIHF. 147 3) MIH_SAP and associated primitives for users to get services of 148 MIHF. 150 4) The definitions of new link-layer SAPs and associated primitives 151 for each link-layer technology. They help MIHF to collect link 152 information and control link behaviors during handovers. 154 The concept of MIHF is a functional entity to realize the high- 155 performance handovers. The primary advantage of MIHF is that it 156 provides media-independent services to higher layers without 157 considering the media-specific technology of lower layer being used, 158 such as IEEE Std.802.3, IEEE Std.802.11, IEEE Std.802.16, 3GPP and 159 3GPP2. It also defines three kinds of SAPs (will be detailed later) 160 of MIHF and their primitives that interact between different layers. 161 The MIHF can also act as a filter: the messages received from link 162 layer SHOULD be processed and submitted to higher layer for meeting 163 the subscribers' need. Therefore, MIHF should work under MIF API. In 164 fact, MIF API SHOULD be served as a user of MIHF, which is shown in 165 Figure 1. The subscribers can then only interact with the MIHF via 166 one kind of SAPs (i.e. MIH_SAP) without knowing lower level 167 information. The MIH protocol is not in the scope of this document. 169 Three kinds of MIHF services are defined in the standard, including 170 Media Independent Event Service (MIES), Media Independent Command 171 Service (MICS) and Media Independent Information Service (MIIS). 173 MIES provides event classification, event filtering and event 174 reporting corresponding to dynamic changes in link characteristics, 175 link status and link quality. It originates from lower layers and can 176 be passed to MIHF or upper users for the detection of handover 177 requirement. MICS enables MIH users to manage and control link 178 behavior relevant to handover and mobility. It is invoked by users or 179 MIHF and makes effect on MIHF or lower layers. 181 For example, in MN-initiated handover scenario, MICS is adopted for 182 MN switching between different links. MIIS allows MN and network 183 entities to discover information that influences the selection of 184 appropriate networks during handovers. Figure 2 [IEEE 802.21] shows 185 MIH services as well as their initiation. 187 +-------------------------------------+ 188 | Application | 189 +-------------------------------------+ 190 /\ || /\ || /\ || 191 || \/ || || || || 192 +--------------+ || || || || 193 |High Level API| || || || || 194 +--------------+ || || || || 195 /\ || || || || || 196 || \/ || \/ || || 197 +------------------------+ || || 198 | MIF API | || || 199 +------------------------+ || || 200 /\ || || \/ 201 || || +--------------------+ 202 || || | Communication API | 203 || || +--------------------+ 204 || || /\ /\ 205 || || || || 206 || \/ \/ \/ 207 +-------------------------------------+ 208 | MIHF | 209 +-------------------------------------+ 210 /\ || 211 || \/ 212 +-------------------------------------+ 213 | Network Link API | 214 +-------------------------------------+ 215 /\ || /\ || 216 || \/ || \/ 217 +---------------+ +---------------+ 218 | Network | | Network | 219 | Interface 1 | | Interface 2 | 220 +---------------+ +---------------+ 222 Figure 1 The relationship of MIHF & MIF API 224 The letters a, b, c in Figure 2 respectively represent: 226 a. MIH_SAP 228 b. MIH_LINK_SAP 230 c. LLC_SAP 232 The SAPs are divided into two categories: 234 1) Media dependent SAP (including MIH_LINK_SAP and LLC_SAP). 236 2) Media independent SAP (MIH_SAP). 238 +-------------+ Command +-----------------------------+ 239 | + Service | | 240 | / \ <---------------+ | 241 | + + | MIH User | 242 | | | Event | | 243 | MIHF | | Service | Layer 3 or Higher | 244 | | a |--------------->| Mobility Protocol | 245 | Event | | | | 246 | Service | | Information | | 247 | + + Service | | 248 | Command \ /<--------------->| +-------+ +-------+ | 249 | Service + +--+ c +-+---+--+ c +-+ 250 | | Command + +-------+ | + +-------+ | 251 | Information | Service / \ | / \ | 252 | Service |--------------->+ + | + + | 253 | | | | Network1 | | | Network2 | 254 | | Event | | (e.g.IEEE| | | (e.g.IEEE| 255 | | Service | b | 802.16) | | b | 802.11) | 256 | |<---------------| | | | | | 257 | | | | | | | | 258 | | Information | | | | | | 259 | | Service + + | + + | 260 | |<--------------->\ / | \ / | 261 | | + | + | 262 | | | | | | 263 +-------------+ +------------+ +------------+ 265 Figure 2 MIH services and their initiation 267 SAP of the MIHF (i.e. MIH_SAP) is media independent. The MIH_SAP 268 defines the users' interface between the MIHF and MIH such as an 269 upper layer mobility protocol or a handover function (e.g., MIF API) 270 that might reside at higher layer transport entity as well. MIH_SAP 271 allows the MIHF to provide services to the upper layers, the network 272 management plane and the data bearer plane. Upper layers need to 273 subscribe with the MIHFto receive MIHF events. In MIF case, the MIF 274 API can directly send commands to the local MIHF via messages which 275 use the service primitives of the MIH_SAP. 277 All the messages REQUIRED for communicating successfully in MIF 278 environment that described in the [I-D.ietf-mif-api-extension] MUST 279 also be used here. These messages define the way that MIF API 280 interacts with the higher layers or applications. New messages need 281 to be added into this set for handover process. These new messages 282 SHOULD be exchanged between MIHF and MIF API. Some of them may use 283 the services of MIHF. 285 4. The Extension of MIF API in Handover: A Case Study 287 This section introduces the extension of message calls of MIF API in 288 two parts based on the classification of handovers (MN-initiated 289 handover and the network-initiated handover). To handle these two 290 kinds of handovers successfully, MIF API SHOULD be extended 291 respectively based on the characteristics of process. 293 4.1. The MN-initiated Handover 295 The MN-initated handover includes the following steps: 297 1) Information query. The MN collects network information from the 298 MIIS server which the MN is connected to. 300 2) Resource availability check. The MIF API sends request to find 301 candidates and then receives a list of candidate networks in response 302 message. 304 3) Resource preparation. The MN SHOULD determine which target network 305 is suitable and request it for resource preparation. 307 4) Establish new L2 connection. The MIF API initiates a new link 308 connection. 310 5) Link up indication. The MIHF of MN notifies the MIF API that the 311 link is up. 313 6) Higher layer handover execution. 315 7) Resource release. The original serving network resources must be 316 released in the end. 318 The following messages, which are only the interactions between a 319 MIHF and MIF APIs, need to be added. 321 4.1.1. Get Information 323 This message is sent by the MIF API for the inquiry of the 324 neighboring networks information. In MIH, we can use the 325 MIH_Get_Information.request to realize the same purpose. After 326 receiving this message, the MIHF inquires the MIIS server for the 327 information, which will return a list of network information needed 328 for MIF API. 330 4.1.2. Information Post 332 This message is sent to the MIF API by the MIIS server as a response 333 to the Get Information message. MIH_Get_Information.confirm can be 334 used to convey such information. 336 4.1.3. Parameter Report 338 When attached to a specific network, the MIF API needs to receive the 339 link status from the lower layers in order to better control the 340 whole connection. The MIHF can receive reports from the link layers 341 and submit them to the higher layers. If the link goesdown, the MIF 342 API must notify its subscribers by "Interface is going away" message. 343 The application or higher API could try to establish new connections 344 by sending "Wants to connect" to MIHF and the connection process will 345 restart from step 2 (i.e. Resource availability check). 347 Another situation is that once the MIF API receives a "Wants to 348 connect" message from its subscriber, the MIF API SHOULD accordingly 349 trigger a whole connection process to a new network. This can also 350 begin from step 2. 352 4.1.4. Check Resources MN 354 Before the start of connection, the MN SHOULD check the resource 355 availability at the candidate networks. This message is sent to the 356 MIHF by the MIF API. The serving network SHOULD request each 357 candidate. The final result SHOULD be returned to the higher layer. 358 The MIH_MN_HO_Candidate_Query.request can be used in the MIH case. 360 4.1.5. Resource Availability 362 When receiving the resource availability of the candidates from the 363 serving network, the MIHF SHOULD submit them to the MIF API. The 364 MIH_MN_HO_Candidate_Query.confirm can be used in the MIH case. 366 4.1.6. Connect to Interface 368 This message is sent to the MIF API by the upper applications. When 369 the MIF API receives the Resource Availability, it could post the 370 message to the higher layer. The upper application can use "Connect 371 to Interface" to choose a better network interface. More about the 372 choosing methods need further discussion. 374 4.1.7. Resource Preparation Messages 376 The MIF API can use the MIH_MN_HO_Commit. request, which includs the 377 target network information, to request the network chose for resource 378 preparation. When the preparation is done, the MIHF receives the 379 response from the target network. It sends a MIH_MN_HO_Commit. 380 confirm message to the MIF API to inform the status of the 381 previously issued target notification request. 383 4.1.8. Establish Link Messages 385 MIF API can use the MIH_Link_Action. request to solve the problem in 386 connection establishment. This message primitively in the [IEEE 387 802.21] is to control the local or remote lower link layers. It 388 includes a MIHF ID and a Link Actions List, which can realize many 389 controlling functions. After the action has been executed, the MIF 390 API should receive a MIH_Link_Action. confirm to indicate the result. 392 4.1.9. Link Up 394 After the new link is established, the MAC layers MUST deliver a 395 Link_Up.indication to the MIHF. The MIHF then passes the MIH_Link_Up. 396 indication message to the MIF API. The MIF API can notify the upper 397 applications bythe "Link is going up" message. Then the higher layer 398 handover execution might be triggered and the traffic flow can be re- 399 established. 401 4.1.10. Handover Completed 403 This message is sent to the local MIHF by the MIH API to release the 404 resources of the previous serving network which was originally 405 allocated to the MN. After identifying that the release is done, the 406 target network Point of Service (PoS) sends the confirm message to 407 the MIHF and the MIHF SHOULD also reply the MIF API with the same 408 information. 410 4.1.11. Handover Completion Confirmation 412 This message is sent to the MIF API by the MIHF indicating that the 413 resource of the previous network is successfully released. 415 4.2. The Network-initiated Handover 417 There are also seven steps in an intact network-initiated handover, 418 like the MN-initiated handover: 420 1) Information query. 422 2) Resource availability check. 424 3) Resource preparation. 426 4) Establish a L2 connection using MIH_Link_Action.request. 428 5) Sent link indications to the MIF API. 430 6) Higher layer handover execution. 432 7) Resource release. 434 The differences between Network-initiated case and MN-initiated case 435 are in step 1 and step 2: the Get Information request and Information 436 Query are respectively initiated by the MIH user of the serving 437 network. When such MIH user obtains the information from the MIIS 438 server, it sends requests to the MN for a response message containing 439 the MN's handover acknowledgement, MN's preferred link and PoS lists. 441 In step 3, the commitment of target network is also initiated by the 442 MIH user of a serving network. After the resource is prepared, the 443 PoS of serving network SHOULD notify the MN for the establishment of 444 L2 connection in step 4. 446 The following messages should be added in MIF API: 448 4.2.1. Candidate Query Notification 450 This message is sent to MN's MIHF from the PoS of the serving network 451 with a list of PoAs of each candidate network link. Such message 452 suggests the MN SHOULD consider new access network. This message can 453 use the MIH_Net_HO_Candidate_Query. indication. 455 4.2.2. Candidate Query Result 457 This message is sent to the local serving network's MIHF from MN's 458 MIF API, specifying whether the request of handover is permitted or 459 not. MIH_Net_HO_Candidate_Query.response can be used here. If the 460 handover is permitted, a new access network SHOULD be considered at 461 the handover initiation stage. 463 4.2.3. Check Resources Net 465 This message is sent to the MN's MIF API by the PoS of serving 466 network with a list of target network information and a set of 467 resource parameters assigned to the MN for handover operations. 468 MIH_Net_HO_Commit.indication can be used here. Then the MIF API can 469 trigger the establishment of L2 connection by using 470 Link_Action.request. After the link connection is done, MIF API needs 471 to inform the serving network. Link_Action. request might also have a 472 list of actions for handover control during the link connection 473 period. 475 4.2.4. Confirm Chosen Target 477 This message is sent by the MN's MIF API as a response to the 478 MIH_HO_Commit.indication, revealing that the indication is received. 479 MIH_Net_HO_Commit.response can be used here. Also such message might 480 include a list of the results of previous actions. 482 4.2.5. Establish Link Messages 484 This message is exactly the same as that of the MN-initiated process, 485 for establishing a new L2 link connection. 487 4.2.6. Link Up 489 This message is exactly the same as that of the MN-initiated process, 490 for informing the MIF API that the L2 link is completed. 492 4.2.7. Handover Completed 494 This message is exactly the same as that of the MN-initiated process, 495 for releasing the resources that have already attained by the MN. 497 4.2.8. Handover Completion Confirmation 499 This message is exactly the same as that of the MN-initiated process, 500 for confirming that the resources of the previous network are 501 successfully released. 503 5. Discussions for New Messages from MIF Perspective 505 New messages described in this document are critical for information 506 exchanging and function achievement between MIHF and MIF API. Since 507 both "upper layer requirements gathering" and "lower layer command 508 delivering" (or reverse) can be achieved via messages, the logical 509 relationship should be discussed in-depth. The messages below are 510 only the examples. Further updating is needed. 512 5.1. Get Information 514 According to [IEEE 802.21], this information query is related to a 515 specific interface. It has the flexibility to query either a specific 516 data within a network interface or an extended schema of a given 517 network. As an advanced application or upper APIs send "Announce 518 Interface", "Announce PVD" and "Announce IE (Information Elements)", 519 the MIF API could obtain the information by using the 520 MIH_Get_information. request. 522 5.2. Release the Ongoing Connection 524 The [I-D.ietf-mif-api-extension] defines a message "Connection can be 525 broken", which means that the MN can tolerate the connection being 526 broken, e.g. for power conservation. When the subscribers of MIF API 527 delivers this message, the MIF API SHOULD send "Release the ongoing 528 connection" to the MIHF so that directly releasing the current 529 resources of network to cut off this connection. This action will not 530 weaken the function of the application. 532 5.3. Establish New L2 Connection 534 According to [IEEE 802.21], the MIH_Link_Actions can trigger a L2 535 link connection. When MN wants to build a TCP connection with an IP 536 host, the MIF API will receive "Connect to Address" or "Connect to 537 Address from Address" messages. Then the MIF API can use the 538 MIH_Link_Actions.request to ask MIHF for a new L2 link connection. 540 6. Discussions for New Messages from IEEE Perspective 542 Table1, 2, 3 and 4, are from the [IEEE 802.21]. These messages might 543 be used in the MIF API because they are exchanged between the MIHF 544 and its MIH users. Some of them have been discussed above, but the 545 specific usage of the rest is not represented. This section presents 546 only a direct list of all these messages, their category and brief 547 descriptions. Further discussion is still needed. 549 +---------------------+--------------------------------------------+ 550 | Messages | Description | 551 | (Information) | | 552 +---------------------+--------------------------------------------+ 553 | MIH_Get_Information | Request to get information from repository | 554 +---------------------+--------------------------------------------+ 555 | MIH_Push_Information| Notify the MN of operator policies or | 556 | | other information | 557 +---------------------+--------------------------------------------+ 559 Table 1 Information Messages of MIHF 561 +---------------------+--------------------------------------------+ 562 | Messages (Event) | Description | 563 +---------------------+--------------------------------------------+ 564 | MIH_Link_Detected | Link of a new access network has been | 565 | | detected. This event is typically on the | 566 | | MN when the first PoA of an access network | 567 | | is detected | 568 +---------------------+--------------------------------------------+ 569 | Track_timeout | This event is not generated when | 570 | | subsequent PoAs of the same access network | 571 | | are discovered | 572 +---------------------+--------------------------------------------+ 573 | MIH_Link_Up | L2 connection is established and link is | 574 | | available for use | 575 +---------------------+--------------------------------------------+ 576 | MIH_Link_Down | L2 connection is broken and link is not | 577 | | available for use | 578 +---------------------+--------------------------------------------+ 579 | MIH_Link_Paremeters | Link parameters have crossed a specified | 580 | _Report | threshold and need to be reported | 581 +---------------------+--------------------------------------------+ 582 | MIH_Link_Going_Down | Link conditions are degrading and | 583 | | connection loss is imminent | 584 +---------------------+--------------------------------------------+ 585 | MIH_Link_Handover | L2 handover is imminent based on either | 586 | _Imminent | the changes in the link conditions or | 587 | | additional information available in the | 588 | | network | 589 +---------------------+--------------------------------------------+ 590 | MIH_Link_Handover | L2 handover to a new PoA has been | 591 | _Complete | completed | 592 +---------------------+--------------------------------------------+ 593 | MIH_Link_PDU | Indicate transmission status of a PDU | 594 | _Transmit_Status | | 595 +---------------------+--------------------------------------------+ 597 Table 2 Event Messages of MIHF 599 +--------------------+---------------------------------------------+ 600 | Messages (Command) | Description | 601 +--------------------+---------------------------------------------+ 602 | MIH_Link_Get | Get the status of a link | 603 | _Parameters | | 604 +--------------------+---------------------------------------------+ 605 | MIH_Net_HO | Network initiates handover and sends a list | 606 | _Candidate _Query | of suggested networks and associated points | 607 | | of attachment | 608 +--------------------+---------------------------------------------+ 609 | MIH_Link_Configure | Configure link parameter thresholds | 610 | Thresholds | | 611 +--------------------+---------------------------------------------+ 612 | MIH_Link_Actions | Control the behavior of a set of links | 613 +--------------------+---------------------------------------------+ 614 | MIH_MN_HO_Candidate| Command used by MN to query and obtain | 615 | _Query | handover related information about possible | 616 | | candidate networks | 617 +--------------------+---------------------------------------------+ 618 | MIH_N2N_HO_Query | command sent by the serving MIHF entity to | 619 | _Resources | the target MIHF entity for resource query | 620 +--------------------+---------------------------------------------+ 621 | MIH_MN_HO_Commit | Command used by MN to notify the serving | 622 | | network of the decided target network | 623 | | information | 624 +--------------------+---------------------------------------------+ 625 | MIH_Net_HO_Commit | Command used by the network to notify the | 626 | | MN of the decided target network information| 627 +--------------------+---------------------------------------------+ 628 | MIH_N2N_HO_Commit | Command used by a serving network to inform | 629 | | a target network that an MN is about to | 630 | | move toward that network, initiate context | 631 | | transfer and perform handover preparation | 632 +--------------------+---------------------------------------------+ 633 | MIH_MN_HO_Complete | Notification from MIHF of the MN to the | 634 | | target or source MIHF indicating the | 635 | | status of handover completion | 636 +--------------------+---------------------------------------------+ 637 | MIH_N2N_HO_Complete| Notification from MIHF of the MN to the | 638 | | target or source MIHF indicating the | 639 | | status of handover completion | 640 +--------------------+---------------------------------------------+ 641 | MIH_N2N_HO_Complete| Notification from either source or target | 642 | | MIHF to the peer MIHF indicating the status | 643 | | of the handover completion | 644 +--------------------+---------------------------------------------+ 645 Table 3 Command Messages of MIHF 647 +---------------------+--------------------------------------------+ 648 | Messages | Description | 649 | (Service management)| | 650 +---------------------+--------------------------------------------+ 651 | MIH_Capability | Discover list of Events and Commands | 652 | _Discover | supported by MIHF | 653 +---------------------+--------------------------------------------+ 654 | MIH_Register | Register with a remote MIHF | 655 +---------------------+--------------------------------------------+ 656 | MIH_DeRegister | Deregister with a remote MIHF | 657 +---------------------+--------------------------------------------+ 658 | MIH_Event_Subscribe | Subscribe for MIH event notification | 659 +---------------------+--------------------------------------------+ 660 | MIH_Event_Unsubscibe| Unsubscribe from MIH event notification | 661 +---------------------+--------------------------------------------+ 663 Table 4 Service Management of MIHF 665 7. Security Considerations 667 This document does not contain any security considerations. 669 8. IANA Considerations 671 There are presently no IANA considerations with this document. 673 9. References 675 9.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 9.2. Informative References 682 [IEEE 802.21] IEEE, "IEEE Standard for Local and Metropolitan Area 683 Networks Part 21: Media Independent Handover Services", 684 IEEE LAN/MAN Std 802.21-2008, January 2009. 685 . 688 [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and Z. 689 Cao, "MIF API consideration", draft-ietf-mif-api-extension- 690 05 (work in progress), Feb. 2014. 692 10. Acknowledgments 694 This document was prepared using 2-Word-v2.0.template.dot. 696 Authors' Addresses 698 Hongke Zhang 699 Beijing Jiaotong University (BJTU) 700 Beijing, 100044, P.R.China 702 Email: hkzhang@bjtu.edu.cn 704 Boxin Du 705 Beijing Jiaotong University (BJTU) 706 Beijing, 100044, P.R.China 708 Email: 10291070@bjtu.edu.cn 710 Mi Zhang 711 Beijing Jiaotong University (BJTU) 712 Beijing, 100044, P.R.China 714 Email: 13120174@bjtu.edu.cn 716 Fei Song 717 Beijing Jiaotong University (BJTU) 718 Beijing, 100044, P.R.China 720 Email: fsong@bjtu.edu.cn