idnits 2.17.1 draft-ietf-mif-api-extension-00.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 1, 2012) is 4410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.scharf-mptcp-api' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC3493' is defined on line 691, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-scharf-mptcp-api-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Liu 2 Internet-Draft China Mobile 3 Intended status: Informational Ted. Lemon 4 Expires: Sep. 1, 2012 Nominum 5 Yuri. Ismailov 6 Ericsson 7 Z. Cao 8 China Mobile 9 March 1, 2012 11 MIF API consideration 12 draft-ietf-mif-api-extension-00 14 Abstract 16 This document describes an abstract API that provides the minimal 17 functionality required for a program to communicate effectively with 18 peers and services on the network while running on a host that has 19 more than one active network interface. This API is abstract: we 20 describe the functionality that must be provided, not the bindings 21 that should be used to provide that functionality. The functionality 22 described here provides the building blocks from which higher-level 23 APIs might be built, and is not intended to be used directly by 24 typical applications. 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 May 3, 2012. 43 Copyright Notice 45 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions used in this document . . . . . . . . . . . . . . 4 62 3. MIF API Concept . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Provisioning Domains . . . . . . . . . . . . . . . . . . . 5 64 3.2. Provisioning Domain Agnosticism . . . . . . . . . . . . . 5 65 3.3. MIF API Elements . . . . . . . . . . . . . . . . . . . . . 6 66 3.3.1. Application Element . . . . . . . . . . . . . . . . . 6 67 3.3.2. High Level API . . . . . . . . . . . . . . . . . . . . 7 68 3.3.3. MIF API . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3.4. Communications API . . . . . . . . . . . . . . . . . . 7 70 3.3.5. Network Link API . . . . . . . . . . . . . . . . . . . 7 71 3.4. MIF API communication model . . . . . . . . . . . . . . . 8 72 3.4.1. POST MESSAGE call . . . . . . . . . . . . . . . . . . 8 73 3.4.2. CHECK MESSAGE call . . . . . . . . . . . . . . . . . . 8 74 3.4.3. GET MESSAGE call . . . . . . . . . . . . . . . . . . . 8 75 3.5. MIF Messages . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.5.1. Announce Interfaces . . . . . . . . . . . . . . . . . 9 77 3.5.2. Stop Announcing Interfaces . . . . . . . . . . . . . . 9 78 3.5.3. Interface Announcement . . . . . . . . . . . . . . . . 9 79 3.5.4. No Interface Announcement . . . . . . . . . . . . . . 9 80 3.5.5. Announce Provisioning Domain . . . . . . . . . . . . . 9 81 3.5.6. Stop Announcing Provisioning Domains . . . . . . . . . 10 82 3.5.7. Provisioning Domain Announcement . . . . . . . . . . . 10 83 3.5.8. No Provisioning Domain Announcement . . . . . . . . . 10 84 3.5.9. Announce Configuration Element . . . . . . . . . . . . 10 85 3.5.10. Configuration Element Announcement . . . . . . . . . . 11 86 3.5.11. No Configuration Element Announcement . . . . . . . . 11 87 3.5.12. Announce Address . . . . . . . . . . . . . . . . . . . 11 88 3.5.13. Address Announcement . . . . . . . . . . . . . . . . . 12 89 3.5.14. No Address Announcement . . . . . . . . . . . . . . . 12 90 3.5.15. Get Configuration Data . . . . . . . . . . . . . . . . 12 91 3.5.16. Translate Name . . . . . . . . . . . . . . . . . . . . 12 92 3.5.17. Stop Translating Name . . . . . . . . . . . . . . . . 13 93 3.5.18. Name Translation . . . . . . . . . . . . . . . . . . . 13 94 3.5.19. Connect to Address . . . . . . . . . . . . . . . . . . 13 95 3.5.20. Connect to Address From Address . . . . . . . . . . . 13 96 3.5.21. Connected . . . . . . . . . . . . . . . . . . . . . . 14 97 3.5.22. Not Connected . . . . . . . . . . . . . . . . . . . . 14 98 4. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 101 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 104 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 107 1. Introduction 109 Traditionally, hosts that communicate on the network have done so 110 over a single network link, which is provided by a single service 111 provider. This simple environment is relatively easy to program to, 112 and relatively predictable. 114 However, this relatively simple case is no longer the norm. A 115 typical modern host may have one or two wireless interfaces: a 116 wireless interface connected to a broadband network, and possibly 117 another connected to some kind of cellular network. The same host 118 may also have a wired interface which is sometimes connected to 119 another broadband link. It is also quite common for hosts to have 120 VPN links that are configured, for example, for access to corporate 121 networks, or for access to network privacy services. 123 As a result, it is now quite typical that a program attempting to 124 communicate in such an environment will be presented with conflicting 125 configuration information from more than one provider. In addition, 126 the cost of bandwidth on different links and the power required ny 127 those links may require consideration. 129 The API specified in this document is intended to describe the 130 minimal complete set of API calls required to implement higher level 131 APIs that solve these problems. It is not expected that applications 132 will be implemented to this API, although it should be possible to do 133 so. Rather, we expect this API to be used as a basis for building 134 higher-level APIs that provide domain-specific solutions to these 135 problems. The reason for specifying a lower-level API is to enable 136 any arbitrary domain- specific API to be implemented, since no single 137 higher-level API is likely to satisfy the needs of every application. 139 The API specified here is an abstract API. This means that we 140 specify the functionality that is required to implement the API, but 141 we do not provide specific bindings for any programming language: 142 these are left up to the implementation. The API is described in 143 terms of messages sent and messages received, rather than in terms of 144 procedure calls, because it is necessary to be able to interleave 145 these messages; a procedure call API necessarily precludes 146 interleaving. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 3. MIF API Concept 156 The MIF API is intended to deal with situations where more than one 157 interface may be active at a time. It must also deal with situations 158 where a single interface is connected to a link that provides more 159 than one type of network service. The most common example of this 160 that we expect is a dual-stack network configuration. 162 3.1. Provisioning Domains 164 To properly handle these multiple-service interfaces, we specify the 165 API not in terms of interfaces, but in terms of provisioning domains. 166 So in the case of a dual-stack network attached to a single network 167 interface, there would be two provisioning domains. If the host has 168 a second interface that is connected to a link that only supports 169 IPv6 service, then that host would be connected to a total of two 170 network links, but three provisioning domains. 172 From the perspective of the MIF API, a provisioning domain consists 173 of a link, plus all the configuration information received on that 174 link for that provisioning domain. So for an IPv4 provisioning 175 domain, that would be whatever information is received from the DHCP 176 server. For an IPv6 provisioning domain, the information received 177 through router advertisements would be combined with the information 178 recieved via DHCPv6. 180 **point of discussion: it's actually possible to have two separate 181 provisioning domains for IPv6 on the same wire. Is this a case that 182 could happen in practice, and that we ought to support? I know that 183 some asian countries have arrangements where the operator of the 184 physical network is distinct from one or more operators who provide 185 transit; I think this is all handled transparently to the host, but I 186 don't really know the details. 188 **point of discussion: is IPv4 stateless/Bonjour a separate 189 provisioning domain? What about IPv6 ULA? 191 3.2. Provisioning Domain Agnosticism 193 Although it is possible that a high-level API built on top of this 194 API may be able to distinguish between provisioning domains, at the 195 level of this API, no such distinction can be made. Each 196 provisioning domain is treated separately, and it is the 197 responsibility of the higher-level API or of the application to 198 decide which provisioning domain or domains to actually use. 200 3.3. MIF API Elements 202 There are a number of different, essentially independent, pieces of 203 software that need to be connected together in order to fully support 204 a successful MIF communication strategy. These elements are shown in 205 figure 3.1. 207 +-------------------------------------------+ 208 | Application | 209 +-------------------------------------------+ 210 /\ || /\ || /\ || 211 || \/ || || || || 212 +--------------------+ || || || || 213 | High Level API | || || || || 214 +--------------------+ || || || || 215 /\ || || || || || 216 || \/ || \/ || || 217 +------------------------------+ || || 218 | MIF API | || || 219 +------------------------------+ || || 220 /\ || || \/ 221 || || +-------------------------------+ 222 || || + Communications API + 223 || || +-------------------------------+ 224 || || /\ || 225 || \/ || \/ 226 +-------------------------------------------+ 227 | Network Link API | 228 +-------------------------------------------+ 229 /\ || /\ || 230 || \/ || \/ 231 +-------------------+ +--------------------+ 232 | Network Interface | | Network Interface | 233 | 1 | | 2 | 234 +-------------------+ +--------------------+ 236 Figure 1 238 3.3.1. Application Element 240 This is an actual application. Applications fall into a variety of 241 broad categories, including network servers, web browsers, peer-to- 242 peer programs, and so on. Although we are focusing here on the 243 mechanisms required to allow these applications to originate 244 connections to remote nodes, it is worth noting that applications 245 must also be able to receive connections from remote nodes. 247 3.3.2. High Level API 249 Applications are generally expected to originate connections using 250 some general-purpose high-level API suited to their particular 251 function. It is likely that different applications may use different 252 high-level APIs to communicate, depending on their particular needs. 253 We do not describe the functioning of such high-level APIs; however, 254 one such API under current consideration is the Happy Eyeballs for 255 MIF [reference]. These APIs are expected to be able to be 256 implemented using functionality like that described in the MIF API. 258 3.3.3. MIF API 260 This is the API being described in this document. Generally 261 speaking, this API is used by higher-level APIs. However, it is 262 permissible for applications to use the MIF API when it is deemed 263 necessary. Currently, several modern web browsers take this approach 264 to establishing network connections, rather than relying on vendor- 265 provided connection mechanisms. 267 3.3.4. Communications API 269 Once an application has originated a connection with a remote node 270 using either a high-level API or the MIF API, it must communicate. 271 Similarly, when an application receives a connection from a remote 272 node, it must communicate with that remote node. The communications 273 API is used for this communication. Popular examples of such APIs 274 include the POSIX socket API and a variety of other related APIs. 276 It is likely that in some instances, implementations of the MIF API 277 will be done as extensions to the Communications API provided by a 278 particular operating system; the functional separation we show here 279 is intended to allow us to illustrate only those features required in 280 a MIF environment, while relying on existing communications APIs to 281 provide the rest. 283 3.3.5. Network Link API 285 This is the software that is responsible for actually managing 286 whatever network links are present on a node, whether these are 287 physical links or tunnels. What precisely this functional box 288 contains may vary greatly from device to device. On a typical modern 289 computer workstation, this functionality would almost certainly 290 reside entirely in the system kernel; however, on an embedded device 291 everything from the Application down to the Network Link API could 292 easily be running together on the bare metal as a single program. 294 The Network Link API can completely concealed from the Application, 295 so we don't show a connection between them on the functional diagram, 296 and indeed we do not talk about the functionality provided by this 297 API. The reason for showing it on the functional diagram is simply 298 to show that there likely is an API in common between MIF and the 299 Communications API. 301 3.4. MIF API communication model 303 MIF API requests are made in the form of messages posted to the MIF 304 API, and messages received from it. To accomplish this, several API 305 calls are available. These calls mediate communication between the 306 MIF API and the High Level API, or between the MIF API and the 307 Application. In addition, the CHECK MESSAGE call allows the 308 application to probe for or wait for messages from any of the APIs. 310 3.4.1. POST MESSAGE call 312 This call causes a message to be posted to the MIF API. The call 313 posts the message, and then returns. 315 3.4.2. CHECK MESSAGE call 317 This call checks to see if there is a message waiting either from the 318 High Level API, the MIF API, or the Communications API. Ideally it 319 should be able to report the availability of any message or event 320 that the application might anticipate receiving, so that the 321 application can simply block waiting for such an event using this 322 call. The application should be able to do a non-blocking probe, 323 wait for some limited period of time, or wait indefinitely. 325 An example of a function of this type in existing practice is the 326 POSIX poll() system call. 328 3.4.3. GET MESSAGE call 330 This call checks to see if there is a message waiting. If there is 331 no message, it returns a status code indicating that there is no 332 message waiting. If there is a message, it returns the message. 334 3.5. MIF Messages 336 MIF messages always go in one direction or the other: from the 337 subscriber to the MIF API, or to the subscriber from the MIF API. We 338 use the term "subscriber" here to mean either the Application or the 339 High Level API, since either is permitted to communicate with the MIF 340 API. 342 Messages described here are grouped according to function. 344 3.5.1. Announce Interfaces 346 This message is sent to the MIF API to ask it to send a message 347 announcing the existence of any interface. When the MIF API receives 348 this message from a subscriber, it iterates across the list of all 349 known interfaces; for each known interface, it sends an Interface 350 Announcement message to the subscriber. 352 In addition, the MIF API sets a flag indicating that the subscriber 353 is interested in learning about new interfaces. When the MIF API 354 detects the presence of a new interface, it sends an Interface 355 Announcement message for that interface to the subscriber. This 356 would happen, for instance, when a new tunnel is configured, or when 357 a USB device that is a network interface is discovered by the Network 358 API. 360 Also, if a network interface goes away, either because the physical 361 network device is disconnected, or because a tunnel is disabled, the 362 MIF API will send a No Interface Announcement message to the 363 subscriber. 365 3.5.2. Stop Announcing Interfaces 367 This message is sent to the MIF API when a subscriber is no longer 368 interested in receiving announcements about new interfaces. 369 Subsequently, the MIF API will no longer send Interface Announcement 370 or No Interface Announcement messages to the subscriber. 372 3.5.3. Interface Announcement 374 This message announces the existence of an interface. The 375 announcement includes an interface display name and interface 376 identifier. 378 3.5.4. No Interface Announcement 380 This message announces that an interface that had been previously 381 announced is no longer present. The announcement includes the 382 interface identifier. 384 3.5.5. Announce Provisioning Domain 386 This message requests the MIF API to announce the availability of any 387 provisioning domains configured on a particular interface. The 388 interface identifier must be specified. 390 Upon receipt, the MIF API will iterate across the list of 391 Provisioning Domains present for a particular interface, and will 392 send a Provisioning Domain Announcement for each such Provisioning 393 Domain. 395 In addition, the MIF API will set a flag indicating that the 396 subscriber wishes to know about new provisioning domains as they 397 appear. Subsequently, when a new Provisioning Domain appears, the 398 MIF API will send a Provisioning Domain Announcement message to the 399 subscriber. 401 Finally, if a Provisioning Domain expires or is invalidated, the MIF 402 API will send the subscriber a No Provisioning Domain Announcement 403 message for that Provisioning Domain. 405 In the event that an interface on which provisioning domains has been 406 announced goes away, a No Provisioning Domain Announcement message 407 will be sent for each provisioning domain that had previously been 408 announced on that interface before the No Interface Announcement 409 message is sent. 411 Once a No Interface Announcement message has been sent, any 412 subscriber that had subscribed to Provisioning Domain announcements 413 for that interface will be automatically unsubscribed. 415 3.5.6. Stop Announcing Provisioning Domains 417 This message requests that the MIF API stop sending the subscriber 418 Provisioning Domain Announcement and No Provisioning Domain 419 Announcement messages. The subscriber must indicate the interface 420 for which it no longer wishes to receive Provisioning Domain 421 announcements. 423 3.5.7. Provisioning Domain Announcement 425 This message is sent by the MIF API to the subscriber to indicate 426 that a new Provisioning Domain has successfully been configured on an 427 interface. The announcement includes the interface identifier and 428 the provisioning domain identifier. 430 3.5.8. No Provisioning Domain Announcement 432 This message is sent by the MIF API to the subscriber to indicate 433 that an existing, previously announced provisioning domain has 434 expired or otherwise become invalid, and can no longer be used. 436 3.5.9. Announce Configuration Element 438 This message is sent by the subscriber to request a specific 439 configuration element from a specific provisioning domain. A 440 provisioning domain identifier must be specified. 442 The MIF API will respond by iterating across the complete list of 443 configuration elements for a provisioning domain, sending a 444 Configuration Element Announcement message to the subscriber for each 445 one. 447 Additionally, if any Configuration Elements subsequently complete for 448 a particular provisioning domain, the MIF API will send a 449 Configuration Element Announcement message to the subscriber for each 450 such element. If a Configuration Element becomes invalidated after 451 it has been announced, the MIF API will send a No Configuration 452 Element message. 454 If a provisioning domain expires or becomes invalid, the MIF API will 455 iterate across the list of remaining configuration elements for that 456 provisioning domain amd send a No Configuration Element Announcement 457 message for each such configuration element. 459 3.5.10. Configuration Element Announcement 461 The Configuration Element Announcement message includes a 462 Provisioning Domain ID and a Configuration Element Type, which can be 463 one of the following: 464 Config Element RA 465 Config Element DHCPv6 466 Config Element DHCPv4 467 ...TBD... 469 3.5.11. No Configuration Element Announcement 471 The No Configuration Element Announcement message indicates that a 472 previously valid configuration element for a provisioning domain is 473 no longer valid. The message includes a provisioning domain 474 identifier and a configuration element type. 476 3.5.12. Announce Address 478 This message is sent by the subscriber to request announcements of 479 valid IP addresses for a specific provisioning domain. A 480 provisioning domain identifier must be specified. 482 The MIF API will respond by iterating across the complete list of 483 configuration elements for a provisioning domain, sending a Address 484 Announcement message to the subscriber. 486 Additionally, if any new Address is subsequently configured on a 487 particular provisioning domain, the MIF API will send an Address 488 Announcement message to the subscriber for each such element. If an 489 address becomes invalidated after it has been announced, the MIF API 490 will send a No Address Announcement message. 492 If a provisioning domain expires or becomes invalid, the MIF API will 493 iterate across the list of remaining configuration elements for that 494 provisioning domain amd send a No Address Announcement message for 495 each such address. 497 3.5.13. Address Announcement 499 The Address Announcement message includes single IPv4 or IPV6 address 500 and a Provisioning Domain identifier, as well as the valid and 501 preferred lifetimes for that IP address (IPv6 only). 503 3.5.14. No Address Announcement 505 The No Address Announcement message indicates that a previously valid 506 address for a provisioning domain is no longer valid. The message 507 includes a provisioning domain identifier and an IPv4 or IPv6 508 address. 510 3.5.15. Get Configuration Data 512 The Get Configuration Data message is sent to the MIF API, and 513 includes a Provisioning Domain ID, a Configuration Element Type, and 514 a Configuration Information Identifier. 516 Configuration Information Identifiers: 517 DNS Server List 518 ...TBD... 520 The MIF API searches the configuration database for the specific type 521 of Configuration Element on the specified Provisioning Domain to see 522 if there is any configuration data of the specified type. If so, the 523 MIF API sends a Configuration Data message to the subscriber; 524 otherwise it sends a No Configuration Data message to the subscriber. 526 3.5.16. Translate Name 528 The Translate Name message is sent to the MIF API. It includes a 529 provisioning domain and a name, which is a UTF8 string naming a 530 network node. The message also includes a Translation Identifier, 531 which the subscriber must ensure is unique across all outstanding 532 name service requests. 534 The MIF API begins a name resolution process. As results come in 535 from the name resolution process, the MIF API sends Name Translation 536 messages to the subscriber for each such result. 538 Name resolution can be handled by one or more translations systems 539 such as local host table lookup, Domain Name System, NIS, LLMNR, and 540 is implementation-dependent. **need to think about this 542 3.5.17. Stop Translating Name 544 This message is sent to the MIF API to indicate that the subscriber 545 is no longer interested in additional results from a particular name 546 translation process. The message includes the Translation 547 Identifier. 549 3.5.18. Name Translation 551 The MIF API sends a Name Translation message to subscribers whenever 552 results come in from a name translation process being performed on 553 behalf of the subscriber. The Name Translation message includes the 554 Translation ID generated by the subscriber, and an IP address 555 returned by the translation process. If a single translation result 556 contains more than one IP address, or IP addresses of different 557 types, the MIF API sends a single Name Translation message for each 558 such IP address. 560 3.5.19. Connect to Address 562 The Connect to Address message contains an IP address, a provisioning 563 domain identifier, and a connection identifier which the subscriber 564 must ensure is unique. The MIF API attempts to initiate a TCP 565 connection to the specified IP address using one or more source 566 addresses that are valid for the specified provisioning domain, 567 according to the source address selection policy for that 568 provisioning domain. 570 If the connection subsequently succeeds, the MIF API will send a 571 Connected message to the subscriber. If it subsequently fails, the 572 MIF API will send a Not Connected message to the subscriber. 574 3.5.20. Connect to Address From Address 576 The Connect to Address From Address message contains a source IP 577 address, a destination IP address, a provisioning domain identifier, 578 and a connection identifier which the subscriber must ensure is 579 unique. The MIF API attempts to initiate a TCP connection to the 580 specified IP address using the specified source address. 582 If the connection subsequently succeeds, the MIF API will send a 583 Connected message to the subscriber. If it subsequently fails, the 584 MIF API will send a Connection Failed message to the subscriber. 586 3.5.21. Connected 588 The Connected message contains the connection identifier that was 589 provided in a previous Connect to Address or Connect to Address From 590 Address message sent by the subscriber. It also contains an token, 591 suitable for use with the connection API, for communicating with the 592 end node to which the connection was established. 594 3.5.22. Not Connected 596 The Not Connected message contains the connection identifier that was 597 provided in a previous Connect to Address or Connect to Address From 598 Address message sent by the subscriber. It also contains an 599 indication as to what went wrong with the connection. 601 4. Example Usage 603 below is an example that shows how MIF API in use: 605 +-------+ +-------+ 606 | APP | | API | 607 +-------+ +-------+ 608 | Announce Interfaces | 609 |-------------------------------------------->| 610 | Interface 1, eth0 | 611 |<--------------------------------------------| 612 | Announce PDs on Interface 1 | 613 |-------------------------------------------->| 614 | PD 1 | 615 |<--------------------------------------------| 616 | Interface 2, wa0 | 617 |<--------------------------------------------| 618 | PD 2 | 619 |<--------------------------------------------| 620 | Announce PDs on Interface 2 | 621 |-------------------------------------------->| 622 | PD 3 | 623 |DNS query 2001::1, host.example.com A,AAAA | 624 |DNS query 192.168.1.1,host.example.com A,AAAA| 625 |DNS query 2001::1, host.example.com A,AAAA | 626 |-------------------------------------------->| 627 |14. 2001::1 DNS response: | 628 | host.example.com | 629 | IN A 14.15.16.17 | 630 | IN AAAA 2001:192:321::1 | 631 | | 632 | 2002::1 DNS response:... | 633 | 192.168.1.1 DNS response: | 634 | IN A 192.168.1.1 | 635 |<--------------------------------------------| 636 | 15. SYN: 14.15.16.17 @ IF1 | 637 | SYN: 2001:192:321::1 @ IF1 | 638 | SYN: 2001:192:321::1 @ IF2 | 639 | SYN: 192.168.1.1 @ IF1 | 640 |-------------------------------------------->| 641 | 16. SYN+ACK @ 192.168.1.1 IF1 | 642 | SYN+ACK @ 2001:192:321::1 IF2 | 643 | SYN+ACK @ 2001:192:321::1 IF1 | 644 |<--------------------------------------------| 645 | | 647 Figure 2 649 As described in the above communication model, the application first 650 invoke the MIF API to query how many interfaces in the host. then, 651 the application invokes MIF API to query how many networks attaches 652 in each interface. application then invoke MIF API to query each DNS 653 configuration on each interface's attached network. application then 654 send DNS query to each DNS server on each network. The DNS servers 655 may return multiple IP address of the queried host name. The 656 application then try to connect to each IP addresses of the host by 657 sending tcp SYN packet to each destination IP addresses through 658 multiple interfaces. Some of the destination IP address may return 659 ACK packet some may not. The application then chose a best 660 connection based on certain criteria. for example, the criteria may 661 based on the qulity of the link. 663 5. Security Considerations 665 TBD 667 6. IANA Considerations 669 None 671 7. Acknowledgments 673 The authors want to thank Teemu Savolainen from Nokia, Dayi Zhao from 674 Bitway, Dave Thaler from Microsoft and others for their useful 675 suggestions and discussions. 677 8. References 679 8.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, March 1997. 684 8.2. Informative References 686 [I-D.scharf-mptcp-api] 687 Scharf, M. and A. Ford, "MPTCP Application Interface 688 Considerations", draft-scharf-mptcp-api-02 (work in 689 progress), July 2010. 691 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 692 Stevens, "Basic Socket Interface Extensions for IPv6", 693 RFC 3493, February 2003. 695 Authors' Addresses 697 Dapeng Liu 698 China Mobile 699 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 700 Beijing 100053 701 China 703 Email: liudapeng@chinamobile.com 705 Ted Lemon 706 Nominum 707 Redwood City 708 CA 94063 709 USA 711 Email: Ted.Lemon@nominum.com 713 Yuri Ismailov 714 Ericsson 715 Stockholm 716 Sweden 718 Email: yuri@ismailov.eu 720 Zhen Cao 721 China Mobile 722 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 723 Beijing 100053 724 China 726 Email: caozhen@chinamobile.com