idnits 2.17.1 draft-zhang-mif-api-extension-802-21-06.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2017) is 2536 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIF Hongke Zhang 2 Internet Draft Fei Song 3 Intended status: Informational Boxin Du 4 Expires: November 18 2018 Mi Zhang 5 Beijing Jiaotong University 6 May 17, 2017 8 MIF API extension for combining IEEE 802.2 9 draft-zhang-mif-api-extension-802-21-06.txt 11 Abstract 13 The Application Program Interface (API) of MIF, specified in the 14 MIFAPI 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 17 to be extended. IEEE is also aimed at the similar issue from 18 different way. A kind of logical entities over the link layer 19 protocol for handling the seamless handover has been defined in 20 IEEE802.21. This document proposes a mechanism via integrating MIF 21 API and IEEE 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 31 Internet-Drafts is at http://datatracker.ietf.org/drafts/ 32 current/. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use 37 Internet-Drafts as reference material or to cite them other 38 than as "work in progress." 40 This Internet-Draft will expire on November 18, 2018. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described 54 in Section 4.e of the Trust Legal Provisions and are provided 55 without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................. 3 60 2. Terminology .................................................. 3 61 3. The Relationship between IEEE MIHF and MIF API ............... 3 62 4. The Extension of MIF API for Handover: A Case Study........... 7 63 4.1. The MN-initiated Handover ............................... 7 64 4.1.1. Get Information .................................... 7 65 4.1.2. Information Post ................................... 8 66 4.1.3. Parameter Report ................................... 8 67 4.1.4. Check Resources MN ................................. 8 68 4.1.5. Resource Availability .............................. 8 69 4.1.6. Connect to Interface ............................... 8 70 4.1.7. Resource Preparation Messages ...................... 9 71 4.1.8. Establish Link Messages ............................ 9 72 4.1.9. Link Up ............................................ 9 73 4.1.10. Handover Completed ................................ 9 74 4.1.11. Handover Completion Confirmation .................. 9 75 4.2. The Network-initiated Handover .......................... 9 76 4.2.1. Candidate Query Notification ...................... 10 77 4.2.2. Candidate Query Result ............................ 10 78 4.2.3. Check Resources Net ............................... 10 79 4.2.4. Confirm Chosen Target ............................. 11 80 4.2.5. Establish Link Messages ........................... 11 81 4.2.6. Link Up ........................................... 11 82 4.2.7. Handover Completed ................................ 11 83 4.2.8. Handover Completion Confirmation .................. 11 84 5. Discussions for New Messages from MIF Perspective ........... 11 85 5.1. Get Information......................................... 11 86 5.2. Release the Ongoing Connection ......................... 12 87 5.3. Establish New L2 Connection ............................ 12 88 6. Discussions for New Messages from IEEE Perspective............12 89 7. Security Considerations ..................................... 15 90 8. IANA Considerations ......................................... 15 91 9. References .................................................. 15 92 9.1. Normative References ................................... 15 93 9.2. Informative References ................................. 15 95 10. Acknowledgments ........................................... 15 97 1. Introduction 99 In MIF context, improved connectivity experiences SHOULD be created. 100 The main target is to enhance the performance of horizontal and 101 vertical switches between networks. Such situation is quite similar 102 with Media Independent Handover (MIH) described in [IEEE 802.21]. The 103 MIF Application Program Interface (API) specified in the MIF API 104 consideration [I-D.ietf-mif-api-extension] describes a set of message 105 calls to accomplish higher level APIs which solve the problems in 106 multiple interface scenarios. However, this draft only provides a 107 minimal set of message calls REQUIRED to implement the API. New 108 functions could be added. 110 According to [IEEE 802.21], the Media Independent Handover Function 111 (MIHF) is a logical entity that facilitates MIH decision making based 112 on inputs from the MIHF. It can provide abstracted services for 113 higher layers. Communications with the lower layer of the mobility- 114 management protocol stack can be achieved through technology-specific 115 interfaces in MIHF. 117 Although two mechanisms, MIF API and MIHF, are working in different 118 layers and defined by different organizations, the requirements of 119 compatibility are obvious. Some of the functions of MIF API SHOULD be 120 supported by a connection manager (i.e. the MIHF), and vice versa. 121 Owing to the advantages of both MIHF and its Service Access Points 122 (SAPs), the functions of MIHF could be utilized in MIF API in order 123 to handover issues. This document extends message calls of MIF API to 124 support the MIH. Like [I-D.ietf-mif-api-extension], no bindings for 125 programming languages are provided because they are left up to the 126 implementation. This document only describes the messages sending and 127 receiving, which can be read as a checklist for operating system 128 vendors. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC-2119 [RFC2119]. 136 3. The Relationship between IEEE MIHF and MIF API 138 Through facilitating handover among all IEEE 802 networks regardless 139 of whether they are of different media types or not, including both 140 wired and wireless, the purpose of IEEE 802.21 is to improve the user 141 experience of mobile devices. It also aims at making it possible for 142 mobile devices to perform seamless handover between IEEE 802 and non 143 IEEE networks. This standard defines: 145 1. A framework that enables service continuity while a Mobile Node 146 (MN) transitions between heterogeneous link-layer technologies. 148 2. MIHF. 150 3. MIH_SAP and associated primitives for users to get services of 151 MIHF. 153 4. The definitions of new link-layer SAPs and associated primitives 154 for each link-layer technology. They help MIHF to collect link 155 information and control link behaviors during handovers. 157 The content of MIHF is a functional entity to fulfill the high- 158 performance handovers. The primary advantage of MIHF is that it 159 provides media-independent services to higher layers no matter which 160 media-specific technology of lower layer is being used, such as IEEE 161 Std.802.3, IEEE Std.802.11, IEEE Std.802.16, 3GPP and 3GPP2. It also 162 defines three kinds of SAPs (will be detailed later) of MIHF and 163 their primitives that interact between different layers. The MIHF can 164 also act as a filter: the messages received from link layer SHOULD be 165 processed and submitted to higher layer for meeting the subscribers' 166 need. Therefore, MIHF should work under MIF API. In fact, MIF API 167 SHOULD be served as a user of MIHF, as shown in Figure 1. The 168 subscribers can then only interact with the MIHF via one kind of SAPs 169 (i.e. MIH_SAP) without knowing the lower things. The MIH protocol is 170 not in the scope of this document. 172 Three kinds of MIHF services are defined in the standard: Media 173 Independent Event Service (MIES), Media Independent Command Service 174 (MICS) and Media Independent Information Service (MIIS). 176 MIES provides event classification, event filtering and event 177 reporting corresponding to dynamic changes in link characteristics, 178 link status and link quality. It originates from lower layers and can 179 be passed to MIHF or upper layers for the detection of handover 180 requirement. MICS enables MIH users to manage and control link 181 behavior relevant to handover and mobility. It is invoked by users or 182 MIHF and makes effect on MIHF or lower layers. 184 For example, in MN-initiated handover scenario, MICS is adopted for 185 MN switching between different links. MIIS allows MN and network 186 entities to discover information which has influence on the selection 187 of appropriate networks during handovers. Figure 2 [IEEE 802.21] 188 shows MIH services and their initiation. 190 +-------------------------------------+ 191 | Application | 192 +-------------------------------------+ 193 /\ || /\ || /\ || 194 || \/ || || || || 195 +--------------+ || || || || 196 |High Level API| || || || || 197 +--------------+ || || || || 198 /\ || || || || || 199 || \/ || \/ || || 200 +------------------------+ || || 201 | MIF API | || || 202 +------------------------+ || || 203 /\ || || \/ 204 || || +--------------------+ 205 || || | Communication API | 206 || || +--------------------+ 207 || || /\ /\ 208 || || || || 209 || \/ \/ \/ 210 +-------------------------------------+ 211 | MIHF | 212 +-------------------------------------+ 213 /\ || 214 || \/ 215 +-------------------------------------+ 216 | Network Link API | 217 +-------------------------------------+ 218 /\ || /\ || 219 || \/ || \/ 220 +---------------+ +---------------+ 221 | Network | | Network | 222 | Interface 1 | | Interface 2 | 223 +---------------+ +---------------+ 224 The relationship of MIHF & MIF API 226 The letters a, b, c in Figure 2 respectively represent: 228 a. MIH_SAP 230 b. MIH_LINK_SAP 232 c. LLC_SAP 234 The SAPs are divided into two categories: 236 1) Media dependent SAP (including MIH_LINK_SAP and LLC_SAP). 238 2) Media independent SAP (MIH_SAP). 240 +-------------+ Command +-----------------------------+ 241 | + Service | | 242 | / \ <---------------+ | 243 | + + | MIH User | 244 | | | Event | | 245 | MIHF | | Service | Layer 3 or Higher | 246 | | a |--------------->| Mobility Protocol | 247 | Event | | | | 248 | Service | | Information | | 249 | + + Service | | 250 | Command \ /<--------------->| +-------+ +-------+ | 251 | Service + +--+ c +-+---+--+ c +-+ 252 | | Command + +-------+ | + +-------+ | 253 | Information | Service / \ | / \ | 254 | Service |--------------->+ + | + + | 255 | | | | Network1 | | | Network2 | 256 | | Event | | (e.g.IEEE| | | (e.g.IEEE| 257 | | Service | b | 802.16) | | b | 802.11) | 258 | |<---------------| | | | | | 259 | | | | | | | | 260 | | Information | | | | | | 261 | | Service + + | + + | 262 | |<--------------->\ / | \ / | 263 | | + | + | 264 | | | | | | 265 +-------------+ +------------+ +------------+ 266 MIH services and their initiation 268 SAP of the MIHF (i.e. MIH_SAP) is media independent. The MIH_SAP 269 defines the interface between the MIHF and MIH users such as an upper 270 layer mobility protocol or a handover function (e.g., MIF API) that 271 might reside at higher layer transport entity as well. MIH_SAP allows 272 the MIHF to provide services to the upper layers, the network 273 management plane and the data bearer plane. Upper layers need to 274 subscribe with the MIHF as users to receive MIHF events. In MIF case, 275 the MIF API can directly send commands to the local MIHF via messages 276 which use the service primitives of the MIH_SAP. 278 All the messages REQUIRED for communicating successfully in MIF 279 environment that described in the [I-D.ietf-mif-api-extension] MUST 280 also be used here. These messages define the way that MIF API 281 interacts with the higher layers or applications andneed to be added 282 into this set for handover process. These new messages SHOULD be 283 exchanged between MIHF and MIF API. Some of them may use the services 284 of MIHF. 286 4. The Extension of MIF API for Handover: A Case Study 288 This section introduces the extension of message calls of MIF API in 289 two parts based on the classification of handovers (MN-initiated 290 handover and the network-initiated handover). In order to handle 291 these two kinds of handovers successfully, MIF API SHOULD be extended 292 respectively based on the characteristics of process. 294 4.1. The MN-initiated Handover 296 The handover initated by MN includes the following seven steps: 298 1) Information query. The MN collects network information from the 299 MIIS server which the MN is connected to. 301 2) Resource availability check. The MIF API sends request to find 302 candidates and then receives a list of candidate networks in response 303 message. 305 3) Resource preparation. The MN SHOULD determine which target network 306 is suitable and request it for resource preparation. 308 4) Establish new L2 connection. The MIF API initiates a new link 309 connection. 311 5) Link up indication. The MIHF of MN notifies the MIF API that the 312 link is up. 314 6) Higher layer handover execution. 316 7) Resource release. The original serving network resources must be 317 released in the end. 319 The following messages need to be added, which describe interactions 320 between a MIHF and MIF APIs. 322 4.1.1. Get Information 324 This message is sent by the MIF API for the inquiry of the 325 neighboring networks information. In MIH, we can use the 326 MIH_Get_Information. request for the same purpose. After receiving 327 this message, the MIHF inquires the MIIS server for the information, 328 which will return a list of network information 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 attaching to a specific network, the MIF API needs to receive 339 the lower layers link status to better control the whole connection. 340 The MIHF can receive reports from the link layers and submit them to 341 the higher layers. If the link is going down, the MIF API must notify 342 its subscribers using "Interface is going away" message. The 343 application or higher API could try to establish new connections by 344 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 when the MIF API receives a "Wants to connect" 348 message from its subscriber, the MIF API SHOULD accordingly trigger a 349 whole connection process to a new network accordingly. This can also 350 begin from step 2. 352 4.1.4. Check Resources MN 354 In the connection starts period, 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 these messages to the MIF API. 364 The 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 includes 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 in order to inform the status of the 381 previously issued target notification request. 383 4.1.8. Establish Link Messages 385 MIF API can solve the connection establishment problem using the 386 MIH_Link_Action. request. This message primitively defined by the 387 [IEEE 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 using the "Link is going up" message. Then the higher 398 layer handover execution might be triggered and the traffic flow can 399 be re-established. 401 4.1.10. Handover Completed 403 This message is sent to the MIF API by the MIHF indicating that the 404 resource of the previous network is successfully released. 406 4.1.11. Handover Completion Confirmation 408 This message is sent to the MIF API by the MIHF indicating that the 409 resource of the previous network is successfully released. 411 4.2. The Network-initiated Handover 413 There are also seven steps in an intact network-initiated handover, 414 like the MN-initiated handover: 416 1) Information query. 418 2) Resource availability check. 420 3) Resource preparation. 422 4) Establish a L2 connection using MIH_Link_Action. request. 424 5) Sent link indications to the MIF API. 426 6) Higher layer handover execution. 428 7) Resource release. 430 The differences between Network-initiated case and MN-initiated case 431 are in step 1 and step 2. The Get Information request and Information 432 Query are respectively initiated by the MIH user of the serving 433 network. When such MIH user obtains the information from the MIIS 434 server, it sends requests to the MN for a response message containing 435 the MN's handover acknowledgement, MN's preferred link and PoS lists. 437 In step 3, the commitment of target network is also initiated by the 438 MIH user of a serving network. After the resource is prepared, the 439 PoS of serving network SHOULD notify the MN for the establishment of 440 L2 connection in step 4. 442 The following messages should be added in MIF API. 444 4.2.1. Candidate Query Notification 446 This message is sent to MN's MIHF from the PoS of the serving network 447 with a list of PoAs of each candidate network link. Such message 448 suggests the MN SHOULD consider new access network. This message can 449 use the MIH_Net_HO_Candidate_Query. indication. 451 4.2.2. Candidate Query Result 453 This message is sent to the local serving network's MIHF from MN's 454 MIF API, specifying whether the request of handover is permitted or 455 not. MIH_Net_HO_Candidate_Query. response can be used here. When the 456 handover is permitted, a new access network SHOULD be considered at 457 the handover initiation stage. 459 4.2.3. Check Resources Net 461 This message is sent to the MN's MIF API by the PoS of serving 462 network with a list of target network information and a set of 463 resource parameters assigned to the MN for handover. 465 MIH_Net_HO_Commit indication can be used. Then the MIF API can 466 trigger the establishment of L2 connection by using Link_Action. 467 request. After the link connection is done, MIF API needs to inform 468 the serving network. Link_Action request might also have a list of 469 actions for handover control during the link connection period. 471 4.2.4. Confirm Chosen Target 473 This message is sent by the MN's MIF API as a response to the 474 MIH_HO_Commit.indication, revealing that the indication is received. 475 MIH_Net_HO_Commit. response can be used. Also such message might 476 include a list of the results of previous actions. 478 4.2.5. Establish Link Messages 480 This message is exactly the same as that of the MN-initiated process, 481 for establishing a new L2 link connection. 483 4.2.6. Link Up 485 This message is exactly the same as that of the MN-initiated process, 486 for informing the MIF API that the L2 link is completed. 488 4.2.7. Handover Completed 490 This message is exactly the same as that of the MN-initiated process, 491 for releasing the resources that have already attained by the MN. 493 4.2.8. Handover Completion Confirmation 495 This message is exactly the same as that of the MN-initiated process, 496 for confirming that the resources of the previous network are 497 successful. 499 5. Discussions for New Messages from MIF Perspective 501 New messages described in this document are critical for information 502 exchanging and function achievement between MIHF and MIF API. Since 503 both "upper layer requirements gathering" and "lower layer command 504 delivering" (or reverse) can be achieved via messages, the logical 505 relationship should be discussed in-depth. The messages below are 506 only the examples. Further updating is needed. 508 5.1. Get Information 510 According to [IEEE 802 21] this information query is related to a 511 specific interface. It has the flexibility to query either a specific 512 data within a network interface or an extended schema of a given 513 network. As an advanced application or upper APIs send "Announce 514 Interface", "Announce PVD" and "Announce IE (Information Elements)", 515 the MIF API could obtain the information via the Get_information. 516 request in MIH. 518 5.2. Release the Ongoing Connection 520 The [I-D.ietf-mif-api-extension] defines a message "Connection can be 521 broken", which means that the MN can tolerate the connection being 522 broken, e.g. for power conservation. When the subscribers of MIF API 523 delivers this message, the MIF API SHOULD send "Release the ongoing 524 connection" to the MIHF so that directly releasing the current 525 resources of network to cut off this connection. This action will not 526 weaken the application function. 528 5.3. Establish New L2 Connection 530 According to [IEEE 802.21], the MIH_Link_Actions can trigger a L2 531 link connection. When MN wants to build a TCP connection with an IP 532 host, the MIF API will receive "Connect to Address" or "Connect to 533 Address from Address" messages. Then the MIF API can use the 534 MIH_Link_Actions. request to ask MIHF for new L2 link connection. 536 6. Discussions for New Messages from IEEE Perspective 538 The following tables, table1, 2, 3 and 4, are from the [IEEE 802.21]. 539 These messages might be used in the MIF API because they are 540 exchanged between the MIHF and its MIH users. Some of them have been 541 discussed above, but the specific usage of the rest is not 542 represented. This section presents only a direct list of their 543 category and brief descriptions. Further discussion is needed. 545 +---------------------+--------------------------------------------+ 546 | Messages | Description | 547 | (Information) | | 548 +---------------------+--------------------------------------------+ 549 | MIH_Get_Information | Request to get information from repository | 550 +---------------------+--------------------------------------------+ 551 | MIH_Push_Information| Notify the MN of operator policies or | 552 | | other information | 553 +---------------------+--------------------------------------------+ 554 Table 1 Information Messages of MIHF 556 +---------------------+--------------------------------------------+ 557 | Messages (Event) | Description | 558 +---------------------+--------------------------------------------+ 559 | MIH_Link_Detected | Link of a new access network has been | 560 | | detected. This event is typically on the | 561 | | MN when the first PoA of an access network | 562 | | is detected | 563 +---------------------+--------------------------------------------+ 564 | Track_timeout | This event is not generated when | 565 | | subsequent PoAs of the same access network | 566 | | are discovered | 567 +---------------------+--------------------------------------------+ 568 | MIH_Link_Up | L2 connection is established and link is | 569 | | available for use | 570 +---------------------+--------------------------------------------+ 571 | MIH_Link_Down | L2 connection is broken and link is not | 572 | | available for use | 573 +---------------------+--------------------------------------------+ 574 | MIH_Link_Paremeters | Link parameters have crossed a specified | 575 | _Report | threshold and need to be reported | 576 +---------------------+--------------------------------------------+ 577 | MIH_Link_Going_Down | Link conditions are degrading and | 578 | | connection loss is imminent | 579 +---------------------+--------------------------------------------+ 580 | MIH_Link_Handover | L2 handover is imminent based on either | 581 | _Imminent | the changes in the link conditions or | 582 | | additional information available in the | 583 | | network | 584 +---------------------+--------------------------------------------+ 585 | MIH_Link_Handover | L2 handover to a new PoA has been | 586 | _Complete | completed | 587 +---------------------+--------------------------------------------+ 588 | MIH_Link_PDU | Indicate transmission status of a PDU | 589 | _Transmit_Status | | 590 +---------------------+--------------------------------------------+ 591 Table 2 Event Messages of MIHF 593 +--------------------+---------------------------------------------+ 594 | Messages (Command) | Description | 595 +--------------------+---------------------------------------------+ 596 | MIH_Link_Get | Get the status of a link | 597 | _Parameters | | 598 +--------------------+---------------------------------------------+ 599 | MIH_Net_HO | Network initiates handover and sends a list | 600 | _Candidate _Query | of suggested networks and associated points | 601 | | of attachment | 602 +--------------------+---------------------------------------------+ 603 | MIH_Link_Configure | Configure link parameter thresholds | 604 | Thresholds | | 605 +--------------------+---------------------------------------------+ 606 | MIH_Link_Actions | Control the behavior of a set of links | 607 +--------------------+---------------------------------------------+ 608 | MIH_MN_HO_Candidate| Command used by MN to query and obtain | 609 | _Query | handover related information about possible | 610 | | candidate networks | 611 +--------------------+---------------------------------------------+ 612 | MIH_N2N_HO_Query | command sent by the serving MIHF entity to | 613 | _Resources | the target MIHF entity for resource query | 614 +--------------------+---------------------------------------------+ 615 | MIH_MN_HO_Commit | Command used by MN to notify the serving | 616 | | network of the decided target network | 617 | | information | 618 +--------------------+---------------------------------------------+ 619 | MIH_Net_HO_Commit | Command used by the network to notify the | 620 | | MN of the decided target network information| 621 +--------------------+---------------------------------------------+ 622 | MIH_N2N_HO_Commit | Command used by a serving network to inform | 623 | | a target network that an MN is about to | 624 | | move toward that network, initiate context | 625 | | transfer and perform handover preparation | 626 +--------------------+---------------------------------------------+ 627 | MIH_MN_HO_Complete | Notification from MIHF of the MN to the | 628 | | target or source MIHF indicating the | 629 | | status of handover completion | 630 +--------------------+---------------------------------------------+ 631 | MIH_N2N_HO_Complete| Notification from MIHF of the MN to the | 632 | | target or source MIHF indicating the | 633 | | status of handover completion | 634 +--------------------+---------------------------------------------+ 635 | MIH_N2N_HO_Complete| Notification from either source or target | 636 | | MIHF to the peer MIHF indicating the status | 637 | | of the handover completion | 638 +--------------------+---------------------------------------------+ 639 Table 3 Command Messages of MIHF 641 +---------------------+--------------------------------------------+ 642 | Messages | Description | 643 | (Service management)| | 644 +---------------------+--------------------------------------------+ 645 | MIH_Capability | Discover list of Events and Commands | 646 | _Discover | supported by MIHF | 647 +---------------------+--------------------------------------------+ 648 | MIH_Register | Register with a remote MIHF | 649 +---------------------+--------------------------------------------+ 650 | MIH_DeRegister | Deregister with a remote MIHF | 651 +---------------------+--------------------------------------------+ 652 | MIH_Event_Subscribe | Subscribe for MIH event notification | 653 +---------------------+--------------------------------------------+ 654 | MIH_Event_Unsubscibe| Unsubscribe from MIH event notification | 655 +---------------------+--------------------------------------------+ 656 Table 4 Service Management of MIHF 658 7. Security Considerations 660 This document does not contain any security considerations. 662 8. IANA Considerations 664 There are presently no IANA considerations with this document. 666 9. References 668 9.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicat 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 9.2. Informative References 675 [IEEE 802.21] IEEE, "IEEE Standard for Local and Metropolitan Area 676 Networks Part 21: Media Independent Handover Services", 677 IEEE LAN/MAN Std 802.21-2008, January 2009. 678 . 681 [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and 682 Z.Cao, "MIF API consideration", draft-ietf-mif-api- 683 extension-05 (work in progress), Feb. 2014. 685 10. Acknowledgments 687 This document was prepared using 2-Word-v2.0.template.dot. 689 Authors' Addresses 691 Hongke Zhang 692 Beijing Jiaotong University (BJTU) 693 Beijing, 100044, P.R.China 695 Email: hkzhang@bjtu.edu.cn 697 Fei Song 698 Beijing Jiaotong University (BJTU) 699 Beijing, 100044, P.R.China 701 Email: fsong@bjtu.edu.cn 703 Boxin Du 704 Beijing Jiaotong University (BJTU) 705 Beijing, 100044, P.R.China 707 Email: 10291070@bjtu.edu.cn 709 Mi Zhang 710 Beijing Jiaotong University (BJTU) 711 Beijing, 100044, P.R.China 713 Email: 13120174@bjtu.edu.cn