idnits 2.17.1 draft-scharf-mptcp-api-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 15, 2009) is 5305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) == Outdated reference: A later version (-03) exists of draft-ford-mptcp-multiaddressed-01 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-09 == Outdated reference: A later version (-12) exists of draft-ietf-hip-native-api-09 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-19 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Scharf 3 Internet-Draft Alcatel-Lucent Bell Labs 4 Intended status: Informational A. Ford 5 Expires: April 18, 2010 Roke Manor Research 6 October 15, 2009 8 MPTCP Application Interface Considerations 9 draft-scharf-mptcp-api-00 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 18, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Multipath TCP (MPTCP) adds the capability of using multiple paths to 48 a regular TCP session. Even though it is designed to be totally 49 backward compatible, the data transport differs to the existing TCP, 50 and there are several additional degrees of freedom that affect 51 applications. This document summarizes the impact that MPTCP may 52 have on applications, such as changes in performance. Furthermore, 53 it describes an optional extended application interface that provides 54 access to multipath information and enables control of some aspects 55 of the MPTCP implementation's behaviour. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Impact of MPTCP on Applications . . . . . . . . . . . . . . . 4 62 3.1. Performance Improvement . . . . . . . . . . . . . . . . . 4 63 3.1.1. Throughput . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.3. Resilience . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . . 5 67 3.2.1. Impact of Middleboxes . . . . . . . . . . . . . . . . 5 68 3.2.2. Outdated Implicit Assumptions . . . . . . . . . . . . 5 69 4. Implications of MPTCP on Existing Interfaces . . . . . . . . . 6 70 4.1. Overview of the Network Stack . . . . . . . . . . . . . . 6 71 4.2. Impact on the Use of Socket Options . . . . . . . . . . . 6 72 4.3. Impact on Existing Other System-wide Settings . . . . . . 7 73 4.4. Impact on Existing API Calls . . . . . . . . . . . . . . . 8 74 4.5. Impact on Existing Sockets API Enhancements . . . . . . . 8 75 5. Application Requirements . . . . . . . . . . . . . . . . . . . 8 76 5.1. MPTCP Usage Scenarios . . . . . . . . . . . . . . . . . . 8 77 5.2. Requirements on API Extensions . . . . . . . . . . . . . . 10 78 6. Specification of API Extensions for MPTCP . . . . . . . . . . 11 79 6.1. Design Considerations . . . . . . . . . . . . . . . . . . 11 80 6.2. Overview of Sockets Interface Extensions . . . . . . . . . 12 81 6.3. Detailed Description . . . . . . . . . . . . . . . . . . . 12 82 6.3.1. TCP_MP_ENABLE . . . . . . . . . . . . . . . . . . . . 12 83 6.3.2. TCP_MP_MAXSUBFLOW . . . . . . . . . . . . . . . . . . 12 84 6.4. Usage examples . . . . . . . . . . . . . . . . . . . . . . 12 85 6.5. Discussion of Interactions . . . . . . . . . . . . . . . . 12 86 6.6. Advice to Application Developers . . . . . . . . . . . . . 12 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 Multipath TCP (MPTCP) [4] adds the capability of using multiple paths 98 to a regular TCP session [1]. MPTCP offers the same reliable, in- 99 order, byte-stream transport like TCP and is designed to be backward- 100 compatible. It requires support inside the network stack of both 101 endpoints. This document presents the impacts that MPTCP may have on 102 applications, such as performance changes. Furthermore, it specifies 103 an extended Application Programming Interface (API) describing how 104 applications can exploit additional features of multipath transport. 105 While MPTCP needs to be usable without any application changes, this 106 API is an optional extension that provides access to multipath 107 information and enables control of some aspects of the MPTCP 108 implementation's behaviour. 110 The de facto standard API for TCP/IP applications is the "sockets" 111 interface. This document defines experimental MPTCP-specific 112 extensions, in particular additional socket options. It is up to the 113 applications, or high-level programming languages or libraries, to 114 decide whether to use these optional extensions. For instance, an 115 application may want to turn on or off the MPTCP mechanism for 116 certain data transfers, or provide some guidance concerning its 117 usage. The syntax and semantics of the specification is in line with 118 the Posix standard [5] as much as possible. 120 There are various related extensions of the sockets interface: [7] 121 specifies sockets API extensions for the multihoming shim layer. The 122 API enables interactions between applications and the multihoming 123 shim layer for advanced locator management, and access to information 124 about failure detection and path exploration. Other experimental 125 extensions to the sockets API are defined for the Host Identity 126 Protocol (HIP) [8] in order to manage the bindings of identifiers and 127 locator. There can be interactions of these APIs with MPTCP. Other 128 related API extensions exist for IPv6 [6]. The MPTCP API also has 129 some similarity to the SCTP socket API [9]. 131 The target readers of this document are application programmers who 132 develop application software that may benefit significantly from 133 MPTCP. This document also provides the necessary information for 134 developers of MPTCP to implement the API in a TCP/IP network stack. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [3]. 142 This document uses the terminology introduced in [4]. 144 3. Impact of MPTCP on Applications 146 3.1. Performance Improvement 148 One of the key goals of adding multipath capability to TCP is to 149 improve the performance of a transport connection. Furthermore, it 150 is an explicit goal of MPTCP that it should not provide a worse 151 performing connection that would have existed through the use of 152 legacy, single-path TCP. 154 3.1.1. Throughput 156 The most obvious performance improvement that will be gained with the 157 use of MPTCP is an increase in throughput, since MPTCP will pool more 158 than one path (where available) between two endpoints. This will 159 provide greater bandwidth for an application. If there are shared 160 bottlenecks between the flows, then the congestion control algorithms 161 will ensure that load is correctly spread and the end user receives 162 no worse performance than single-path TCP. 164 Furthermore, this means that an MPTCP session could achieve 165 throughput that is greater than the capacity of a single interface on 166 the device. If any applications make assumptions about interfaces 167 due to throughput (or vice versa), they must take this into account. 169 A small overhead will be present, through the use of MPTCP options, 170 and as such the impact of this when there are multiple subflows over 171 a shared bottleneck (or bottlenecks) should be considered, but is 172 FFS, and will be part of the definition of a suitable congestion 173 control algorithm. 175 3.1.2. Delay 177 If the delays on the constituent subflows of an MPTCP connection 178 differ, the jitter perceivable to an application may appear higher as 179 the data is striped across the subflows. Although MPTCP will ensure 180 in-order delivery to the application, the application must be able to 181 cope with the data being burstier than may be usual with single-path 182 TCP. Since burstiness is commonplace on the Internet today, it is 183 unlikely that applications will suffer from such an impact on traffic 184 profile, but application authors may wish to consider this in future 185 development. 187 In addition, applications that make round trip time (RTT) estimates 188 at the application level may have some issues. Whilst the average 189 delay calculated will be accurate, whether this is useful for an 190 application will depend on what it requires this information for. If 191 a new application wishes to derive such information, it should 192 consider how multiple subflows may affect its measurements, and thus 193 how it may wish to respond. In such a case, an application may wish 194 to express its scheduling preferences, as described later in this 195 document. 197 3.1.3. Resilience 199 The use of multiple subflows simultaneously means that, if one should 200 fail, all traffic will move to the remaining subflow(s), and 201 additionally any lost packets can be retransmitted on these subflows. 203 Subflow failure may be caused by issues within the network, which an 204 application would be unaware of, or interface failure on the node. 205 An application may, under certain circumstances, be in a position to 206 be aware of such failure (e.g. by radio signal strength, or simply an 207 interface enabled flag), and so must not make assumptions of an MPTCP 208 flow's stablity based on this. MPTCP will never override an 209 application's request for a given interface, however, so the cases 210 where this issue may be applicable are limited. 212 3.2. Potential Problems 214 3.2.1. Impact of Middleboxes 216 MPTCP has been designed in order to pass through the majority of 217 middleboxes, for example through its ability to open subflows in 218 either direction, and through its use of a data-level sequence 219 number. 221 Nevertheless some middleboxes may still refuse to pass MPTCP messages 222 due to the presence of TCP options. If this is the case, MPTCP 223 should fall back to regular TCP. Although this will not create a 224 problem for the application (its communication will be set up either 225 way), there may be additional (and indeed, user-perceivable) delay 226 while the first handshake fails. 228 Empirical evidence suggests that new TCP options can successfully be 229 used on most paths in the Internet. But they can also have other 230 unexpected implications. For instance, intrusion detection systems 231 could be triggered. 233 3.2.2. Outdated Implicit Assumptions 235 MPTCP overcomes the one-to-one mapping of the socket interface to a 236 flow through the network. As a result, applications cannot 237 implicitly rely on this one-to-one mapping any more. Applications 238 that require the transport along a single path can disable the use of 239 MPTCP as described later in this document. One example are 240 monitoring tools that want to measure the available bandwidth on a 241 path. 243 Security implications: TODO 245 4. Implications of MPTCP on Existing Interfaces 247 4.1. Overview of the Network Stack 249 MPTCP is an extension of TCP. TCP interacts with other parts of the 250 network stack by different interfaces. The de facto standard API 251 between TCP and applications is the sockets interface. The position 252 of MPTCP in the protocol stack can be illustrated as follows: 254 +-------------------------------+ 255 | Application | 256 +-------------------------------+ 257 ^ | 258 ~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~ 259 | v 260 +-------------------------------+ 261 | MPTCP | 262 + - - - - - - - + - - - - - - - + 263 | Subflow (TCP) | Subflow (TCP) | 264 +-------------------------------+ 265 | IP | IP | 266 +-------------------------------+ 268 MPTCP protocol stack 270 In general, MPTCP affects all interfaces that rely on the coupling of 271 a TCP connection to a single IP address and TCP port pair, to one 272 sockets endpoint, to one network interface, or to a given path 273 through the network. 275 A design objective of MPTCP is that applications can continue to use 276 the established sockets API without any changes. Still, some aspects 277 have to be taken into account: In MPTCP, there is a one-to-many 278 mapping between the socket endpoint and the subflows. As a 279 consequence, the existing sockets interface functions cannot 280 configure each subflow individually. In order to be backward 281 compatible, existing APIs therefore should apply to all subflows 282 within one connection, as far as possible. 284 4.2. Impact on the Use of Socket Options 286 The sockets API includes options that modify the behavior of sockets 287 and their underlying communications protocols. Various socket 288 options exist on socket, TCP, and IP level. The value of an option 289 can usually be set by the setsockopt() system function. The 290 getsockopt() function gets information. 292 One commonly used TCP socket option (TCP_NODELAY) disables the Nagle 293 algorithm as described in [2]. This option is also specified in the 294 Posix standard [5]. Applications can use this option in combination 295 with MPTCP exactly in the same way. It then disables the Nagle 296 algorithm for the MPTCP connection, i.e., all subflows. 298 TODO: Setting this option could also trigger a different path 299 scheduler algorithm - specifically, that which is designed for 300 latency-sensitive traffic, as described in a later section. 302 Applications can also explicitly configure send and receive buffer 303 sizes by the sockets API (SO_SNDBUF, SO_RCVBUF). These socket 304 options can also be used in combination with MPTCP and then affect 305 the buffer size of the MPTCP connection. However, when defining 306 buffer sizes, application programmers should take into account that 307 the transport over several subflows requires a certain amount of 308 buffer for resequencing. Therefore, it does not make sense to use 309 MPTCP in combination with very small receive buffers. Small send 310 buffers may prevent MPTCP from efficiently scheduling data over 311 different subflows. 313 It is assumed that any application that binds to INADDR_ANY does not 314 care which addresses are in use locally, and so MPTCP can freely set 315 up multiple subflows on such a connection. If an application uses a 316 specific address, or sets the SO_BINDTODEVICE socket option to bind 317 to a specific interface, then MPTCP MUST respect this and not 318 interfere in the application's choices. The extended sockets API 319 will allow applications to express such preferences in an MPTCP- 320 compatible way (e.g. bind to a subset of devices only). 322 Some network stacks also provide other implementation-specific socket 323 options that affect TCP's behavior. If a network stack supports 324 MPTCP, it must be ensured that these options do not interfere. 326 4.3. Impact on Existing Other System-wide Settings 328 TODO: Socker buffer dimensioning: Requirement of larger resequencing 329 buffer space 331 TODO: Could also affect interface configuration, information in local 332 routing table, buffer management, etc. 334 4.4. Impact on Existing API Calls 336 There is an issue, to be resolved, regarding what data should be 337 returned on a getpeername() or getsockname() request on the socket, 338 i.e. to retrieve the IP address of the peer or of the local socket. 339 Our initial thinking is that it should return the IP address pair 340 that was first connected to, in all circumstances, even if that 341 particular subflow is no longer in use. MPTCP-aware applications can 342 use new API calls, documented later, in order to retrieve the full 343 list of address pairs for the subflows in use. 345 4.5. Impact on Existing Sockets API Enhancements 347 The use of MPTCP can interact with various related sockets API 348 extensions: 350 o SHIM API [7]: This API specifies sockets API extensions for the 351 multihoming shim layer. TODO: Potential interactions will be 352 addressed in a future revision of this memo. 354 o HIP API [8]: The Host Identity Protocol (HIP) also results in a 355 new API. TODO: Potential interactions will be addressed in a 356 future revision of this memo. 358 o IPv6 API [6]: The API for IPv6 leaves open the interaction with 359 TCP. 361 5. Application Requirements 363 5.1. MPTCP Usage Scenarios 365 Applications that use TCP have different requirements on the 366 transport layer. While developers have become used to the 367 characteristics of regular TCP, new opportunities created by MPTCP 368 could allow the service provided to be optimised further. 370 An application that wishes to transmit bulk data will want MPTCP to 371 provide a high throughput service immediately, through creating and 372 maximising utilisation of all available subflows. This is the 373 default MPTCP use case. 375 But at the other extreme, there are applications that are highly 376 interactive, but require only a small amount of throughput, and these 377 are optimally served by low latency and jitter stability. In such a 378 situation, it would be preferable for the traffic to use only the 379 lowest latency subflow (assuming it has sufficient capacity), with 380 one or two additional subflows for resilience and recovery purposes. 382 The choice between these two options affects the scheduler in terms 383 of whether traffic should be, by default, sent on one subflow or 384 across both. Even if the total bandwidth required is less than that 385 available on an individual path, it is desirable to spread this load 386 to reduce stress on potential bottlenecks, and this is why this 387 method should be the default. It is recognised, however, that this 388 may not benefit all applications that require latency/jitter 389 stability, so the other (single path) option is provided. 391 In the case of the latter option, however, a further question arises: 392 should additional subflows be used whenever the primary subflow is 393 overloaded, or only when the primary path fails (hot-standby)? In 394 other words, is latency stability or bandwidth more important to the 395 application? 397 We therefore divide this option into two: Firstly, there is the 398 single path which can overflow into an additional subflow; and 399 secondly there is single-path with hot-standby, whereby an 400 application may want an alternative backup subflow in order to 401 improve resilience. In case that data delivery on the first subflow 402 fails, the data transport could immediately be continued on the 403 second subflow, which is idle otherwise. 405 In summary, there are three different "application profiles" 406 concerning the use of MPTCP: 408 1. Bulk data transport 410 2. Latency-sensitive transport (with overflow) 412 3. Latency-sensitive transport (hot-standby) 414 These different application profiles affect both the management of 415 subflows, i. e., the decisions when to set up additional subflows to 416 which addresses as well as the assignment of data (including 417 retransmissions) to the existing subflows. In both cases different 418 policies can exist. 420 These profiles have been defined to cover the common application use 421 cases. It is not possible to cover all application requirements, 422 however, and as such applications should additionally have finer 423 control over subflow and scheduling should they require. 424 Requirements are TBD. 426 Although it is intended that such functionality will be achieved 427 through new MPTCP-specific options, it may also be possible to infer 428 some application preferences from existing socket options, such as 429 TCP_NODELAY. Whether this would be reliable, and indeed appropriate, 430 is FFS. 432 5.2. Requirements on API Extensions 434 Because of the importance of the sockets interface there are several 435 fundamental design objectives for the interface between MPTCP and 436 applications: 438 o Consistency with existing sockets APIs must be maintained. In 439 order to support the large base of applications using the original 440 API, an application must be able to continue to use all standard 441 socket interface functions when run on a system supporting MPTCP. 443 o Sockets API extensions must be minimized and independent of an 444 implementation. 446 o The interface should both handle IPv4 and IPv6. 448 The following is a list of specific requirements from applications: 450 TODO: This list of requirements is preliminary and requires further 451 discussion. Some requirements have to be removed. 453 REQ1: Turn on/off MPTCP: An application should be able to request 454 to turn on or turn off the usage of MPTCP. This means that 455 an application should be able to explicitly request the use 456 of MPTCP if this is possible. Applications should also be 457 able to request not to enable MPTCP and to use regular TCP 458 transport instead. (This can be implicit in many cases, 459 e.g., by the use of binding to a specific address versus all 460 addresses). 462 REQ2: An application will want to be able to restrict MPTCP to 463 binding to a given set of addresses or interfaces. 465 REQ3: An application should be able to know if multiple subflows 466 are in use. 468 REQ4: An application should be able to extract a unique identifier 469 for the connection (per endpoint), analogous to a port, i.e. 470 it should be able to retrieve MPTCP's connection identifier. 472 REQ5: An application should be able to enumerate all subflows in 473 use, obtain information on the addresses used by a subflow, 474 and obtain a subflow's usage (e.g., ratio of traffic sent via 475 this subflow). 477 REQ6: Set/get application profile, as discussed in the previous 478 section. 480 REQ7: Constrain the maximum number of subflows to be used by an 481 MPTCP connection. (Or just infer from application profile?) 483 REQ8: Request a change in scheduling between subflows? (i.e. a more 484 granular version of application profile?) 486 REQ9: Request a change in the number of subflows in use, thus 487 triggering removal or addition of subflows. (A finer control 488 granularity would be: Request the establishment of a new 489 subflow to a provided destination, and request the 490 termination of a specified, existing subflow.) 492 REQ10: Control automatic establishment/termination of subflows? 493 There could be different configurations of the path manager, 494 e.g., 'try ASAP', 'wait until there is a bunch of data, etc. 495 (Tied to application profile?) 497 REQ11: Set/get preferred subflows or subflow usage policies? There 498 could be different configurations of the multipath scheduler, 499 e.g., 'all-or-nothing', 'overflow', etc. (Again, tied to 500 application profile). 502 REQ12: Set/get sporadic sending of segments on unused paths 503 ("keepalives"). 505 REQ13: An application should be able to modify the MPTCP 506 configuration while communication is ongoing, i.e., after 507 establishment of the MPTCP connection. 509 6. Specification of API Extensions for MPTCP 511 6.1. Design Considerations 513 Multipath transport results in many degrees of freedom. MPTCP 514 manages the data transport over different subflows automatically. By 515 default, this is transparent to the application. But applications 516 can use the sockets API extensions defined in this section to 517 interface with the MPTCP layer and to control important aspects of 518 the MPTCP implementation's behaviour. The API uses non-mandatory 519 socket options and is designed to be as light-weight as possible. 521 MPTCP mainly affects the sending of data. Therefore, most of the new 522 socket options must be set in the sender side of a data transfer in 523 order to take effect. TODO: Any control on the receiver side? 524 As this document specifies sockets API extensions, it is written so 525 that the syntax and semantics are in line with the Posix standard [5] 526 as much as possible. 528 6.2. Overview of Sockets Interface Extensions 530 The extended MPTCP API consist of several new socket options that are 531 specific to MPTCP. All of these socket options are defined at TCP 532 level (IPPROTO_TCP). These socket options can be used either by the 533 getsockopt() or by the setsockopt() system call. 535 o TCP_MP_ENABLE: MPTCP enabled/disabled 537 o TCP_MP_MAXSUBFLOWS: Get/set maximum number of paths 539 o ... 541 TODO: Table of socket options 543 6.3. Detailed Description 545 6.3.1. TCP_MP_ENABLE 547 TODO: Description 549 6.3.2. TCP_MP_MAXSUBFLOW 551 TODO: Description 553 6.4. Usage examples 555 TODO: Example C code for one or more API functions 557 6.5. Discussion of Interactions 559 TODO: Some of the socket options defined in this document are 560 overlapping with existing sockets API and care should be taken for 561 the usage not to confuse with the overlapping features. 563 TODO: Interactions with system-wide settings? 565 6.6. Advice to Application Developers 567 TODO: E. g. use primary addresses and connection identifiers in a 568 tuple instead of the traditional 5-tuple 570 7. Security Considerations 572 Will be added in a later version of this document. 574 8. IANA Considerations 576 No IANA considerations. 578 9. Conclusion 580 This document discusses MPTCP's application implications and 581 specifies an extended API. From an architectural point of view, 582 MPTCP offers additional degrees of freedom concerning the transport 583 of data. The extended sockets API allows applications to have 584 additional control of some aspects of the MPTCP implementation's 585 behaviour and to obtain information about its usage. The new socket 586 options for MPTCP can be used by getsockopt() and/or setsockopt() 587 system calls. But it is also ensured that the existing sockets API 588 continues to work. 590 10. Acknowledgments 592 Michael Scharf is supported by the German-Lab project 593 (http://www.german-lab.de/) funded by the German Federal Ministry of 594 Education and Research (BMBF). Alan Ford is supported by Trilogy 595 (http://www.trilogy-project.org/), a research project (ICT-216372) 596 partially funded by the European Community under its Seventh 597 Framework Program. The views expressed here are those of the 598 author(s) only. The European Commission is not liable for any use 599 that may be made of the information in this document. 601 11. References 603 11.1. Normative References 605 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 606 September 1981. 608 [2] Braden, R., "Requirements for Internet Hosts - Communication 609 Layers", STD 3, RFC 1122, October 1989. 611 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 612 Levels", BCP 14, RFC 2119, March 1997. 614 [4] Ford, A., Raiciu, C., Handley, M., and S. Barre, "TCP Extensions 615 for Multipath Operation with Multiple Addresses", 616 draft-ford-mptcp-multiaddressed-01 (work in progress), 617 July 2009. 619 [5] "IEEE Std. 1003.1-2008 Standard for Information Technology -- 620 Portable Operating System Interface (POSIX). Open Group 621 Technical Standard: Base Specifications, Issue 7, 2008.". 623 11.2. Informative References 625 [6] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced 626 Sockets Application Program Interface (API) for IPv6", RFC 3542, 627 May 2003. 629 [7] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket 630 Application Program Interface (API) for Multihoming Shim", 631 draft-ietf-shim6-multihome-shim-api-09 (work in progress), 632 July 2009. 634 [8] Komu, M. and T. Henderson, "Basic Socket Interface Extensions 635 for Host Identity Protocol (HIP)", draft-ietf-hip-native-api-09 636 (work in progress), September 2009. 638 [9] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, 639 "Sockets API Extensions for Stream Control Transmission Protocol 640 (SCTP)", draft-ietf-tsvwg-sctpsocket-19 (work in progress), 641 February 2009. 643 Authors' Addresses 645 Michael Scharf 646 Alcatel-Lucent Bell Labs 647 Lorenzstrasse 10 648 70435 Stuttgart 649 Germany 651 EMail: michael.scharf@alcatel-lucent.com 653 Alan Ford 654 Roke Manor Research 655 Old Salisbury Lane 656 Romsey, Hampshire SO51 0ZN 657 UK 659 Phone: +44 1794 833 465 660 EMail: alan.ford@roke.co.uk