idnits 2.17.00 (12 Aug 2021) /tmp/idnits59364/draft-seite-mif-cm-02.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 (August 14, 2013) is 3195 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PID' is mentioned on line 167, but not defined == Unused Reference: 'RFC2119' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC6089' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'I-D.deng-mif-api-session-continuity-guide' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netext-logical-interface-support' is defined on line 431, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-deng-mif-api-session-continuity-guide-03 == Outdated reference: A later version (-05) exists of draft-ietf-mif-api-extension-03 == Outdated reference: draft-ietf-netext-logical-interface-support has been published as RFC 7847 == Outdated reference: A later version (-05) exists of draft-korhonen-dmm-prefix-properties-03 == Outdated reference: A later version (-02) exists of draft-zuniga-mif-802-21-overview-00 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF WG P. Seite 3 Internet-Draft Orange 4 Intended status: Informational JC. Zuniga 5 Expires: February 15, 2014 InterDigital Communications, LLC 6 August 14, 2013 8 MIF API for Connection Management 9 draft-seite-mif-cm-02.txt 11 Abstract 13 There is currently a need to present a coherent connection management 14 behaviour for different terminal platforms (e.g. mobile phones, PCs, 15 tablets, etc.). This document discusses how a connection manager can 16 use the MIF API to provide this coherent behaviour and enhance the 17 end user's experience when a terminal is able to connect to multiple 18 interfaces. The goal of this document is not to define a connection 19 manager specification, but to focus on the interaction with the MIF 20 API and suggest relevant generic messages for the interface. 22 This document is for discussion and its intention is to help 23 clarifying the utilization of the MIF API in a connection management 24 context and propose some relevant considerations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 15, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Architecture of a MIF terminal . . . . . . . . . . . . . . . 2 62 3. Use-case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Functions of the connection manager . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 [I-D.ietf-mif-api-extension] describes an abstract API that provides 75 commands and services for applications and higher layer APIs running 76 on a terminal with more than one interface. There is currently a 77 need to present a coherent connection management behaviour for 78 different terminal platforms (e.g. mobile phones, PCs, tablets, 79 etc.), as users often experience a very different behaviour when 80 connecting with various platforms to the same networks and for the 81 same purposes (e.g. web browsing, email access, dedicated 82 applications, etc.). This document builds on top of the MIF API and 83 aims to discuss how connection managers can use the MIF API to 84 provide a coherent and constant behaviour to the users. The goal of 85 this document is not to define a connection manager specification, 86 but to focus on the interaction with the MIF API and suggest relevant 87 generic messages for the interface. 89 This document is only for discussion; its intention is to help 90 clarifying the utilization of the MIF API in a connection management 91 context. 93 2. Architecture of a MIF terminal 94 The terminal's MIF API based architecture is an instantiation of the 95 MIF API model described in [I-D.ietf-mif-api-extension]; main 96 functions and APIs are described below: 98 o MIF API: it provides information as per 99 [I-D.ietf-mif-api-extension]. 101 o Connection Manager: it is an application relying on the MIF API; 102 this application acts on behalf of other runing applications. The 103 connection manager decides about the mapping between IP flows and 104 interfaces, then configures the IP stack, and lower layers, 105 accordingly, e.g. configuration of the routing table. The 106 connection manager relies on information provided either by the 107 MIF API or the OS API. Only interface with the MIF API is in the 108 scope of this document. 110 o OS API: Provides the interface to manipulate IP object 111 configuration, e.g. routing table. 113 +------------------------------+ +------------------------------+ 114 | Connection manager | | Application | 115 +------------------------------+ +------------------------------+ 116 /\ || /\ || /\ || || || 117 || || || \/ || || || \/ 118 || || +------------------------+ +-------------------+ 119 || || | MIF API | |Communications API | 120 || || +------------------------+ +-------------------+ 121 || || /\ || /\ || 122 || \/ || || || || 123 +--------------------+ || \/ || \/ 124 +| OS API (Kernel) |-----------------------------------------+ 125 |+--------------------+ Network Link API | 126 +---------------------------------------------------------------+ 127 /\ || /\ || 128 || \/ || \/ 129 +-------------------+ +--------------------+ 130 | Network Interface | | Network Interface | 131 | 1 | | 2 | 132 +-------------------+ +--------------------+ 134 Figure 1: MIF API framework 136 3. Use-case 137 The presented use-case aims to illustrate the behaviour of the MIF 138 API in a concrete situation. The use-case is as follows: 140 1. Multiple IP communications are running simultaneously; each can 141 be mapped to different interfaces/provisioning domains. 143 2. The connection manager selects the appropriate interface/ 144 provisioning domain for the application; making a decision 145 according to various criteria (information provided by the MIF 146 and lower layers APIs, user preferences, and so on). 148 The interaction between the different APIs is depicted in Figure 2. 149 It is assumed that at least one IP communication is running. Then, 150 an interface event occurs and the connection manager decides to move 151 the communication to a different interface. 153 Connection Manager MIF API Network Link API OS API 154 | | | | 155 |announce.subscribe | | 156 (1) |------------------>| | | 157 | | subcribe.request | | 158 | |------------------->| | 159 | | subcribe.confirm | | 160 | subscr.confirm |<-------------------| | 161 |<------------------| | | 162 | | | | 163 (2) | | event occurs | 164 | event.announce | event.notif | | 165 (3) |<----------------- |<------------------ | | 166 | | | | 167 | config.get[PID] | | | 168 (4) |------------------>|------------------->| | 169 | config.resp | | | 170 |<----------------- |<-------------------| | 171 | | config-object.get | | 172 (5?) |---------------------------------------------------->| 173 | | config-object.resp | | 174 |<----------------------------------------------------| 175 (6) decision made | | | 176 | | request.config | | 177 (7) |---------------------------------------------------->| 178 | | config.resp | | 179 |<----------------------------------------------------| 180 | request.config | | | 181 or |------------------>| | | 182 | |------------------->| | 184 (8) | |<------------------ | | 185 | |-------------------------------->| 186 both | config.resp |<--------------------------------| 187 7 and 8?|<----------------- | | 188 | | | 190 Figure 2: APIs interaction 192 Operations are as follows: 194 1. The connection manager subscribes to the MIF API notifications 195 [I-D.ietf-mif-api-extension]. 197 2. An event, to which the connection manager has subscribed, occurs; 198 e.g. a new interface becomes available or a low radio signal 199 level is crossed. 201 3. The connection manager is notified about the event. 203 4. In order to take its decision, the connection manager gets some 204 configuration information from the MIF API. 206 5. The connection manager fetches additional information from the OS 207 API 209 6. The connection manager decides to move the ongoing IP 210 communication to another interface. 212 7. The connection manager requests the OS API to reconfigure one or 213 multiple interfaces according to the decision; for example, the 214 connection manager could request reconfiguration of the routing 215 table or trigger a MIP operation. 217 4. Functions of the connection manager 219 This section focuses on the interactions between the connection 220 manager and the MIF API and OS API. The interactions between the 221 connection manager and other complementary APIs, like user 222 preferences and/or ANDSF network operator policies are out of the 223 scope of this document. 225 A connection manager may also rely on different abstraction layers 226 together with the MIF API. The IEEE 802.21 MIH SAP [IEEE802.21] is 227 an example of such an abstraction layer, which can be seen as a 228 partial instantiation of the MIF API. A companion document 230 [I-D.zuniga-mif-802-21-overview] adresses interaction between IEEE 231 802.21 and MIF API. 233 Generic connection manager functions and their relation to the MIF 234 API are described below. The following assumes the MIF API is the 235 unique API for any manipulation of IP objects. However, current MIF 236 API allows to gather information from the IP stack but not to 237 configure it. As a consequence three functions are added to the MIF 238 API: GetIPtype(), ConfigFlowRouting() and SetSourceAddress(). 240 Subscribe(eventID) 242 Description: register for a MIF API event notification, e.g. WLAN 243 scan results ready, WLAN connected, WLAN disconnected, interface 244 is going to be disconnected detected (e.g. because of low radio 245 signal level detected), Cellular connected, Cellular disconnected, 246 etc. 248 Input: identifier of the event to be notified. Some events are 249 defined in [I-D.ietf-mif-api-extension] 251 API: MIF API 253 UnSubscribe(eventID) 255 Description: unregister to a MIF API notification. 257 Input: identifier of event. Some events are defined in 258 [I-D.ietf-mif-api-extension] 260 API: MIF API 262 ListInterfaces() 264 Description: return the list of available interfaces with their 265 characteristics. Interfaces may have different access 266 technologies. 268 Input: n/a 270 API: MIF API 272 ListProvisioningDomains() 274 Description: return the list of available provisioning domains 275 with their characteristics. 277 Input: n/a 278 API: MIF API 280 GetStatus(IID) 282 Description: provide the status of the interface, e.g. enabled/ 283 disabled, active, idle, connection failed, connecting, 284 disconnecting, scanning, unknown state, etc. 286 Input:Interface Identifier 288 API: MIF API 290 IPconnectivityCheck(PID, IP[]) 292 Description: check IP connectivity to the intranet/Internet: the 293 interface may have a valid IP address but no IP connectivity to 294 data networks (e.g. web based authentication through a captive 295 portal). 297 Input: Provisioning domain Identifier, IP addresses to be tested 299 API: MIF API 301 GetConfiguration(IID) 303 Description: retrieve layer 2 configuration information for a 304 given interface. 306 Input: Interface Identifier 308 API: OS API 310 SetConfiguration(IID) 312 Description: configures an interface, e.g. enable/disable, scan, 313 etc. 315 Input: Interface Identifier 317 API: OS API 319 GetConfiguration(PID) 321 Description: retrieve configuration information for a given 322 provisioning domain(IP address(es), DNS, default gateway, 323 authentication method, associated interface(s)) 325 Input: Provisioning domain Identifier 326 API: MIF API 328 SetConfiguration(PID) 330 Description: configure provisioning domain information (IP 331 addresse(s), default gateway, authentication method, associated 332 interface, routing table, etc.) 334 Input: Provisioning domain Identifier 336 API: MIF API 338 GetTheoriticalQoS(IID) 340 Description: provide information on the theoretical interface 341 capabilities (e.g. upload/download speed) 343 Input: Interface Identifier 345 API: MIF API 347 GetAvailableQoS(IID) 349 Description: provide information on the quality of communication 350 (Jitter, delay, average upload data rate, average Download data 351 rate, signal strength, etc.) 353 Input: Interface Identifier 355 API: MIF API 357 GetIPtype(IP address) 359 Description: return the type of address and properties (e.g. 360 local, remote, mobile IP anchored, etc.). This function is to be 361 added to the MIF API as per [I-D.ietf-mif-api-extension]. 362 [I-D.korhonen-dmm-prefix-properties]. 364 Input: IP address 366 API: updated MIF API 368 ConfigFlowRouting(ROUTE, FlowID) 370 Description: associate a route, ROUTE, to the IP flow identified 371 by FlowID, e.g. as defined in [RFC6088]. This function is to be 372 added to the MIF API as per [I-D.ietf-mif-api-extension]. 374 Input: routing table identifier, flow identifier 376 API: updated MIF API 378 SetSourceAddress(IP, FlowID) 380 Description: influence source address selection for a given IP 381 flow. This function is to be added to the MIF API as per 382 [I-D.ietf-mif-api-extension]. 384 Input: IP source address, flow identifier 386 API: updated MIF API 388 5. Security Considerations 390 TBD. 392 6. IANA Considerations 394 This document has no actions for IANA. 396 7. Acknowledgements 398 The authors would like to express their gratitude to Ralph Droms, Ted 399 Lemon and Dave Thaler for the fruitful discussions regarding MIF API 400 and connection managers. 402 8. References 404 8.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 410 "Traffic Selectors for Flow Bindings", RFC 6088, January 411 2011. 413 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 414 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 415 Network Mobility (NEMO) Basic Support", RFC 6089, January 416 2011. 418 8.2. Informative References 420 [I-D.deng-mif-api-session-continuity-guide] 421 Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, 422 "Guide for application developers on session continuity by 423 using MIF API", draft-deng-mif-api-session-continuity- 424 guide-03 (work in progress), October 2012. 426 [I-D.ietf-mif-api-extension] 427 Liu, D., Lemon, T., and Z. Cao, "MIF API consideration", 428 draft-ietf-mif-api-extension-03 (work in progress), 429 November 2012. 431 [I-D.ietf-netext-logical-interface-support] 432 Melia, T. and S. Gundavelli, "Logical Interface Support 433 for multi-mode IP Hosts", draft-ietf-netext-logical- 434 interface-support-07 (work in progress), April 2013. 436 [I-D.korhonen-dmm-prefix-properties] 437 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 438 Liu, "IPv6 Prefix Mobility Management Properties", draft- 439 korhonen-dmm-prefix-properties-03 (work in progress), 440 October 2012. 442 [I-D.zuniga-mif-802-21-overview] 443 Zuniga, J. and P. Seite, "IEEE 802.21 Overview", draft- 444 zuniga-mif-802-21-overview-00 (work in progress), February 445 2013. 447 [IEEE802.21] 448 IEEE, "IEEE Standard for Local and Metropolitan Area 449 Networks - Part 21: Media Independent Handover Services", 450 IEEE LAN/MAN Std 802.21-2008, January 2009.", 2009, < 451 http://www.ieee802.org/21/private/Published%20Spec/ 452 802.21-2008.pdf>. 454 Authors' Addresses 456 Pierrick Seite 457 Orange 458 4, rue du Clos Courtel, BP 91226 459 Cesson-Sevigne 35512 460 France 462 Email: pierrick.seite@orange.com 463 Juan Carlos Zuniga 464 InterDigital Communications, LLC 465 1000 Sherbrooke Street West, 10th floor 466 Montreal, Quebec H3A 3G4 467 Canada 469 Email: JuanCarlos.Zuniga@InterDigital.com