idnits 2.17.1 draft-xue-mptcp-tmpp-unware-hosts-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 12) being 80 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '...in data transfer SHOULD also be consid...' RFC 2119 keyword, line 190: '... also data transfer SHOULD be designed...' RFC 2119 keyword, line 226: '...rward packets. As a result, TMPP MUST...' RFC 2119 keyword, line 280: '...ch because the edge device SHOULD have...' RFC 2119 keyword, line 338: '... MPTCP network node SHOULD also insert...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2013) is 3962 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 6182' is mentioned on line 91, but not defined == Missing Reference: 'I-D.draft-hampel-mptcp-proxies-anchors' is mentioned on line 418, but not defined == Missing Reference: 'I-D.draft-ayar-transparent-sca-proxy' is mentioned on line 114, but not defined == Missing Reference: 'I-D.draft-ietf-mptcp-multiaddressed' is mentioned on line 430, but not defined == Unused Reference: 'RFC6182' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'I-D.ayar-transparent-sca-proxy' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'I-D.ford-mptcp-multiaddressed' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'I-D.hampel-mptcp-proxies-anchors' is defined on line 545, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6182 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multipath TCP K. Xue 3 Internet-Draft J. Guo 4 Intended status: Standards Track P. Hong 5 Expires: December 22, 2013 USTC 6 L. Zhu 7 F. Yu 8 Huawei 9 June 20, 2013 11 TMPP for Both Two MPTCP-unaware Hosts 12 draft-xue-mptcp-tmpp-unware-hosts-02 14 Abstract 16 Transparent MPTCP Proxy(TMPP) is an introduced network-based 17 function, which is under MPTCP architecture. It can help two MPTCP- 18 unaware hosts enjoy multipath support, and can be extensively used 19 both in the access networks and operators' networks. Meanwhile, in 20 MPTCP architecture with TMPP, TMPP needs to modify the received 21 packets and transmit them again(just like gateway in NAT 22 environment). In this document, we also discuss the guarantee for 23 data transfer on TMPP's side. The consideration of data transfer can 24 be expanded to the MPTCP architecture with proxy. 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 December 22, 2013. 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 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. TMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 6 77 3.1. TMPP Locates in the Access Networks . . . . . . . . . . . 6 78 3.2. TMPP Locates in the Operators' Networks . . . . . . . . . 7 79 4. Operation with TMPP . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Connection Establishment . . . . . . . . . . . . . . . . 8 81 4.2. Subflow Management with TMPP . . . . . . . . . . . . . . 9 82 4.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 6.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 90 MPTCP can help increase the resilience of the connectivity and the 91 efficiency of the resource usage [RFC 6182]. When two end hosts 92 communicate with each other, the real connection may pass through 93 multiple sections in the networks. There are differences in these 94 sections since networks can be divided into wired and wireless, 95 backhaul and core networks. 97 In [I-D.draft-hampel-mptcp-proxies-anchors], MPTCP proxy is only 98 introduced to help two end hosts(One is MPTCP-capable, and the other 99 is MPTCP-unware) communicate with each other. 101 In order to take the full advantage of MPTCP, we can use multipath 102 transport in a wider environment. For example, when a household 103 access device is used, the link between the access device and one end 104 host(the end host connects Internet via this device) performs quite 105 well. If the end host is MPTCP-unaware, it's appropriate to use an 106 access device with MPTCP support in MPTCP environment. Under this 107 situation, the mobile access device provides MPTCP function towards 108 network side, while runs traditional TCP towards end hosts. 110 With this method of using MPTCP, there must be some scenarios in 111 which both the end hosts are MPTCP-unaware. Currently, it's not 112 supported for both two MPTCP-unaware hosts to enjoy multipath 113 transport under MPTCP architecture[I-D.draft-hampel-mptcp-proxies- 114 anchors]. Recently, [I-D.draft-ayar-transparent-sca-proxy] presents 115 a new architecture, named SCA (Splitter/Combiner Architecture), which 116 enables non-MPTCP-capable single-homed hosts to benefit from 117 multipath by means of PEPs (Performance Enhancing Proxies) placed in 118 the access networks. This draft corresponds to this case, but it is 119 controversial since it's completely independent of MPTCP 120 architecture. 122 This document complements the work of Proxy in MPTCP by introducing a 123 kind of network-based function, TMPP (Transparent MPTCP Proxy), which 124 is under MPTCP architecture, and can help two MPTCP-unaware hosts 125 enjoy multipath support. Meanwhile, in MPTCP architecture with TMPP, 126 TMPP needs to modify the received packets and transmit them 127 again(just like gateway in NAT environment). In this document, we 128 also discuss the guarantee for data transfer on TMPP's side. The 129 consideration of data transfer can be expanded to the whole MPTCP 130 architecture with proxy, which is also the further key problem for 131 MPTCP proxy. 133 1.1. Background 135 With respect to proxy for MPTCP, there are three kinds of proxies 136 according to whether the end points run MPTCP fuction. 138 o One end host runs MPTCP, and the other end runs traditional TCP. 139 The MPTCP proxy allows two one end hosts separately run traditional 140 TCP and MPTCP. to run ordinary TCP (the other end is MPTCP), Twith 141 the proxy uses talking TCP to communicate with one end and MPTCP to 142 communicate with the other end 144 o Both end hosts run MPTCP. MPTCP anchor allows continuing 145 connectivity after two mobile hosts move simultaneously, or one end 146 host moves and the other is behind a firewall. 148 o Neither of two end hosts runs MPTCP, which is not supported in 149 current MPTCP architecture[I-D.draft-hampel-mptcp-proxies-anchors]. 150 The proxy creates multiple paths between the proxy and the other 151 (TCP) host. 153 [I-D.draft-hampel-mptcp-proxies-anchors] discusses relevant features 154 and signaling enhancements needed for MPTCP proxies and MPTCP 155 anchors, which are both especially suited for wireless access 156 environments. MPTCP proxies and MPTCP anchors in that draft 157 correspond to the first two cases. 159 MPTCP proxy provides multipath support for MPTCP-capable hosts on 160 behalf of their MPTCP-unaware peers, aiming at facilitating 161 incremental deployment of MPTCP, especially for wireless 162 environments, where traffic is dominated by interactions between 163 mobile clients and network-side servers. 165 MPTCP anchor permits subflow establishment for MPTCP connections when 166 direct interaction between end hosts fails. This permits tolerance 167 to local IP protocol restrictions and provides robustness in case of 168 break-before-make mobility events. 170 Since proxy in [I-D.draft-hampel-mptcp-proxies-anchors] is designed 171 for specific scenarios, which can't apply to the case when two end 172 points are both MPTCP-unaware, although the split model of TCP-MPTCP- 173 TCP seems to be the combination of two TCP-MPTCP models. The reason 174 is that, according to [I-D.draft-hampel-mptcp-proxies-anchors], when 175 the connection-initiating host is MPTCP-unaware, an initial SYN 176 packet would be added with a MP_CAPABLE option in which PROXY flag is 177 set when passing through an implicit MPTCP network node (if there is 178 one residing on the direct routing path).When another implicit MPTCP 179 network node inspects the SYN packet and finds the MP_CAPABLE option 180 with PROXY flag set, it should not insert MP_CAPABLE to the SYN-ACK 181 response. This will lead to no proxy service supports for a 182 connection whenever neither end hosts is MPTCP-capable. 184 In order to provide MPTCP support for a MPTCP-unaware couple of 185 peers, new signaling enhancement for connection establishment is 186 needed. At the same time, since there will be two network nodes 187 working for MPTCP transport (see the split model in section 2), 188 acknowledgement of data transfer turns to be complicated, then 189 details in data transfer SHOULD also be considered. So not only 190 connection establishment, but also data transfer SHOULD be designed 191 complying with the fundamental MPTCP architecture and signaling. 192 Meanwhile the consideration of data transfer can be expanded to the 193 whole MPTCP architecture with proxy. 195 1.2. Terminology 197 TMPP: Transparent MPTCP Proxy. 199 2. TMPP 201 TMPP is a kind of MPTCP network functions. It interacts with MPTCP 202 connections through MPTCP signaling. TMPP can reside on MPTCP 203 network nodes. 205 TCP MPTCP TCP 207 +--------+IP A0 +--------+ SFL 0 +--------+IP B0 +--------+ 208 | Host A |------| TMPP A |------------| TMPP B |------| Host B | 209 +--------+ +--------+ +--------+ +--------+ 210 | IP TMPP A | IP TMPP B 211 |\ SFL 1 /| 212 | ------------------- | 213 |\ SFL 2 /| 214 | ------------------- | 215 | : | 217 Figure 1: TCP-MPTCP-TCP split connection with TMPP 219 A couple of TMPPs work together to support MPTCP on behalf of MPTCP- 220 unaware hosts. They split the connection between two MPTCP-unaware 221 hosts into two TCP sections and one MPTCP section (Figure 1). All 222 subflows are established by one TMPP and terminate at its TMPP peer. 223 TMPP relays all packets arriving from one end host to another. 224 TMPP's operations involve inserting or removing MPTCP options, 225 translating locators (address and port) and sequence numbers, and 226 allocating subflows to forward packets. As a result, TMPP MUST 227 maintain the translation relationship of locators and sequence 228 numbers. 230 TMPP is designed as an implicit network function. It resides on the 231 direct routing path between two communicating hosts. During the 232 connection establishment on both two end hosts' side, they are 233 treated as interacting with each other directly, while TMPP can 234 obtain information about locators and MPTCP options via packet 235 inspection, modify packets as necessary and thereby create the split 236 connection. 238 3. Deployment Scenarios 240 TMPP is predominantly used when two MPTCP-unaware hosts are 241 communicating with each other. At least one of them is located in 242 mobile access networks enabling mobile access gateways with MPTCP 243 function towards network side, or one network element in the network 244 supporting multipath. In other words, the connection split-point may 245 locate in the access side or the operators' networks. 247 3.1. TMPP Locates in the Access Networks 249 The mobile access gateway provides MPTCP function towards network 250 side, and the multipath connection begins and ends both at the access 251 gateway. 253 +--------+ +--------+ 254 +------+ | Access |--------------|Access | +------+ 255 | Host | | Gateway| : : : |Gateway | | Host | 256 | A |---| A |--------------| B |---| B | 257 | | | | : : : | | | | 258 +------+ | |--------------| | +------+ 259 | (TMPP) | : : : | (TMPP) | 260 +--------+ +--------+ 262 Figure 2: TMPP locates in the access networks 264 For instance, 266 o A household access device is connected to the Internet via multiple 267 access methods, while the end device via a unique way to the access 268 device. 270 o A vehicle network has several access methods, while the mobile 271 devices hold by passengers can connect it via only one way (e.g. Wi- 272 Fi). 274 While it's not realistic to make all end devices MPTCP-capable, 275 keeping MPTCP function on network-side will be helpful by ensuring 276 the network access device is MPTCP-capable. 278 In this scenario, it simply solves the problem by providing a MPTCP- 279 capable access gateway, and it only needs network edge devices' 280 support. However, it costs nuch because the edge device SHOULD have 281 several SP signings. 283 3.2. TMPP Locates in the Operators' Networks 285 Currently, the bottleneck is the access side's entrance into the core 286 network. Although the inside core network works well, the low 287 efficiency in backhaul limits the whole system's performance. The 288 earlier for the multiple paths to aggregate, the better, which is the 289 same to separate, so it's suggested to put the split point into an 290 operator network element. In this way, it will be convenient for 291 operators' flexible management and charging. At the same time, since 292 the multiple paths are managed by the operator, this single 293 connection needs only one signing. 295 Here are two cases of this scenario. 297 1) The sender or the receiver is limited, the un-limited end host 298 locates in Internet, and a MPTCP-capable P-GW manages multipath. 300 +--------+ +--------+ 301 +------+ | |-------------| | +---------+ 302 | Host | | Access | : : | MPTCP | | Host B | 303 | A |---| Gateway|-------------|-capable|---|(locates | 304 | | | | : : | P-GW | | in the | 305 +------+ | |-------------| | |Internet)| 306 | (TMPP) | : : | (TMPP) | +---------+ 307 +--------+ +--------+ 309 Figure 3: Only one end host is limited 311 2) Both the sender and the receiver are limited, and there are two 312 MPTCP-capable P-GWs working for them separately. 314 +-------+ +--------+ +--------+ +-------+ 315 +----+ | |-----| | | |-----| | +----+ 316 | | |Access |: :| MPTCP | | MPTCP |: :|Access | | | 317 |Host| |Gateway|-----|-capable| |-capable|-----|Gateway| |Host| 318 | |---| A |: :| P-GW A |---| P-GW B |: :| B |---| | 319 | A | | |-----| | | |-----| | | B | 320 | | | |: :| | | |: :| | | | 321 +----+ |(TMPP) |-----| (TMPP) | | (TMPP) |-----|(TMPP) | +----+ 322 +-------+: :+--------+ +--------+: :+-------+ 324 Figure 4: Both two end hosts are limited 326 4. Operation with TMPP 328 4.1. Connection Establishment 330 As mentioned in section 1.1, with implicit proxy proposed in [I-D 331 .draft-hampel-mptcp-proxies-anchors], it's not supported when both 332 end hosts are MPTCP-unaware, because the MPTCP network node refuses 333 to add MP_CAPABLE option if the MP_CAPABLE option in the first SYN 334 packet is added by some other MPTCP network nodes. 336 In order to provide chances for a connection between two MPTCP- 337 unaware hosts also to enjoy multipath support, we make a change which 338 requires another implicit MPTCP network node SHOULD also insert 339 MP_CAPABLE to the SYN-ACK response even if finding the PROXY flag set 340 in the MP_CAPABLE option in SYN packets. 342 TCP MPTCP NETWORK MPTCP NETWORK TCP 343 HOST A NODE A NODE B HOST B 344 | | add MP_CAPAPBLE | | 345 | SYN |/ | | 346 |------------------X--------------------+----------------->| 347 | TMPP A | | 348 | P add MP_CAPAPBLE | | 349 | P \| SYN-ACK | 350 |<-----------------+--------------------X------------------| 351 | P | | 352 | P TMPP B | 353 | P add MP_CAPAPBLE P | 354 | ACK P/ P | 355 |------------------+--------------------+----------------->| 356 | P P | 358 Figure 5: Connection initiation by MPTCP-unaware host with TMPP 360 The signaling of connection establishment is as follows: 362 o SYN 363 One MPTCP-unaware host (host A in Figure 2) starts a connection by 364 sending a TCP SYN packet. TMPP resides on the routing path inspects 365 the packet, and then caches the locators of host A and its peer (host 366 B). Based on these locators, TMPP identifies and intercepts the 367 peer's SYN-ACK response packet, as well as data packets to be 368 transported after connection established. Here, TMPP does not change 369 the locators contained on the packet (which is different from data 370 transfer). 372 The closest TMPP to host A(namely TMPP A) is responsible for 373 initiating multipath support. Inspecting there is no MP_CAPABLE 374 option in SYN packets received from host A, it adds a MP_CAPABLE 375 option (with FLAG set) into the SYN packet, then forwards the packet 376 to host B. 378 Since another TMPP (TMPP B) potentially works for host B and resides 379 on the routing path just as TMPP A does, SYN packet will be received 380 by TMPP B before host B. TMPP B caches the locators of host A and 381 host B, inspects the MP_CAPABLE option with proxy flag set, then 382 becomes aware of that the host A is MPTCP-unaware and there must be a 383 TMPP working for it. After obtaining this information, TMPP B 384 forwards the SYN packet to host B without any change. 386 o SYN-ACK 388 After TMPP B receives the SYN-ACK response from host B, it creates a 389 key on behalf of host B, inserts a MP_CAPABLE option (proxy flag is 390 set) with this key into the SYN-ACK packet, and forwards the packet 391 to host A. 393 When SYN-ACK packet is passing through TMPP A, TMPP A inspects the 394 proxy flag, then caches the key produced by TMPP B for host B. The 395 key will be used for subflow establishment. 397 o ACK 399 When the ACK response from host A arrives at TMPP A, TMPP A still 400 SHOULD insert a MP_CAPABLE option (with PROXY flag set). Further, it 401 produces a key on behalf of host A, and this key will be cached by 402 TMPP B. 404 4.2. Subflow Management with TMPP 406 Splitting the established connection into two TCP sections and one 407 MPTCP section, the couples of TMPPs become the end points for all 408 further subflows. These subflows may be initiated by one TMPP and 409 ended by the other TMPP. Both these two TMPPs must inform about 410 their existence and IP addresses with each other. The PROXY flag on 411 those MP_CAPABLE options in SYN or SYN-ACK packets can help tell one 412 TMPP that another TMPP exists and works for a MPTCP-unaware host. 413 However, after connection established, TMPP is still unaware of 414 another TMPP's IP addresses. As a result, TMPP needs to advertise 415 its address via ADD_ADDR (as introduced in [I-D.draft-ietf-mptcp- 416 multiaddressed]) to another TMPP. 418 In [I-D.draft-hampel-mptcp-proxies-anchors], considering reliability, 419 SEEK_ADDR option is presented. This method is also accepted in this 420 document. 422 4.3. Data Transfer 424 TMPP is the endpoint of all subflows, while runs a regular TCP 425 connection with an end host, so TMPP SHOULD translate the 426 transformation mode between MPTCP and TCP by replacing IP header and 427 TCP header when forwards data packets. 429 MPTCP features acknowledgements at connection-level as well as 430 subflow-level[I-D.draft-ietf-mptcp-multiaddressed], in order to 431 provide a robust service to the application. When acknowledges a 432 packet, TMPP receiver should send ACK to TMPP sender at subfow level 433 as soon as the packet is accepted, while send date-level (i.e. 434 connection-level) ACK until accept the end host's (the real end 435 receiver) Acknowledgement. 437 TCP host A TMPP A TMPP B TCP host B 438 |(1)Data packet | | | 439 |---------------->| (2) | | 440 | |----------------->| | 441 | | subflow-level ACK| (3) | 442 | |<-----------------|---------------->| 443 | | | (4)ACK | 444 | | (5)Data-level ACK|<----------------| 445 | (6)ACK |<-----------------| | 446 |<----------------| | | 448 Figure 6: Data transfer with TMPP 450 o TCP host A sends a SYN packet that conveys A and B's IP addresses 451 in IP head and ports and sequence number in TCP head to host B. 453 o TMPP A assigns the segments received from host A to subflows that 454 already established between TMPP A and TMPP B, then changes IP head 455 and TCP head (the locators will be changed to those of TMPP A and 456 TMPP B's for the assigned subflows). The SN in the new TCP head and 457 the subflow sequence number in MPTCP option SHOULD be the SN of the 458 specific subflow, while the data sequence number in MPTCP option 459 SHOULD be the original SN of TCP flow (Figure 7). Since the 460 insertion of MPTCP option and the changes of some of fields, the 461 Check sum and TCP header length SHOULD also be reset accordingly. 462 Then TMPP A maintains the translation relationship and sends the 463 packet to TMPP B. 465 o With the reception of the packet from TMPP A, TMPP B acknowledges 466 it at the subflow level, sending ACK to TMPP A (the ACK number is at 467 the subflow level). 469 o At the same time, TMPP B recovers the locators to those of host A, 470 removes MPTCP option, and sends the packet to host B. 472 o Host B responds with a simple ACK. 474 o TMPP B establishes and sends ACK to TMPP A at the data level. 476 o TMPP A establishes and sends a simple ACK to host A, with host B's 477 locator. 479 0 1 2 3 480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 481 +---------------+---------------+-------+----------------------+ 482 | Source port | Destination port | 483 +---------------+---------------+-------+----------------------+ 484 | Sequence Number | 485 +---------------+-----------------------+----------------------+ 486 | ACK Number | 487 +---------------+-----------------------+----------------------+ 488 |TCPheader| | | | | | | | Window | 489 | length | | | | | | | | size | 490 +---------------+-----------------------+----------------------+ 491 | Check sum | Urgent pointer | 492 +---------------+-----------------------+----------------------+ 493 | Kind | Length |Subtype| (reserved) |F|m|M|a|A| 494 +---------------+-----------------------+----------------------+ 495 | Data ACK (4 or 8 octets, depending on flags) | 496 +---------------+-----------------------+----------------------+ 497 | Data Sequence Number (4 or 8 octets, depending on flags) | 498 +---------------+-----------------------+----------------------+ 499 | Subflow Sequence Number (4 octets) | 500 +---------------+---------------+-------+----------------------+ 501 | Data-level Length (2 octets) | Checksum (2 octets) | 502 +---------------+---------------+-------+----------------------+ 503 | | 504 ~ data ~ 505 +---------------+-----------------------+----------------------+ 507 Figure 7: TCP header format 509 As a result of the buffer capacity limitation to the network devices, 510 and in order not to bring too much overhead to these nodes, TMPPs are 511 not required to cache data packets. In case TMPP B in Figure 6 512 doesn't receive the ACK response from host B, the lost packet should 513 be retransmitted by the very beginner of the whole connection, i.e. 514 host A. Optimizations could be negotiated in future versions of this 515 protocol. 517 5. Security Considerations 519 It is recommended that before two TMPPs establish MPTCP connection, 520 security preservation is provided by TLS/SSL, which can be further 521 discussed in the next future work. 523 6. References 525 6.1. Normative References 527 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 528 Iyengar, "Architectural Guidelines for Multipath TCP 529 Development", RFC 6182, March 2011. 531 6.2. Informative References 533 [I-D.ayar-transparent-sca-proxy] 534 Ayar, T., Rathke, B., Budzisz, L., and A. Wolisz, "A 535 Transparent Performance Enhancing Proxy Architecture To 536 Enable TCP over Multiple Paths for Single-Homed Hosts", 537 draft-ayar-transparent-sca-proxy-00 (work in progress), 538 February 2012. 540 [I-D.ford-mptcp-multiaddressed] 541 Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for 542 Multipath Operation with Multiple Addresses", draft-ford- 543 mptcp-multiaddressed-03 (work in progress), March 2010. 545 [I-D.hampel-mptcp-proxies-anchors] 546 Hampel, G. and T. Klein, "MPTCP Proxies and Anchors", 547 draft-hampel-mptcp-proxies-anchors-00 (work in progress), 548 February 2012. 550 Authors' Addresses 552 Kaiping Xue 553 USTC 554 Room 305, EEIS Department, USTC West Campus 555 Shushan District , Hefei 230027 556 P. R. China 558 Phone: +86-551-3601334 559 Email: kpxue@ustc.edu.cn 561 Jing Guo 562 USTC 563 Room 305, EEIS Department, USTC West Campus 564 Shushan District , Hefei 230027 565 P. R. China 567 Phone: +86-551-3601334 568 Email: guojing1@mail.ustc.edu.cn 570 Peilin Hong 571 USTC 572 Room 305, EEIS Department, USTC West Campus 573 Shushan District , Hefei 230027 574 P. R. China 576 Phone: +86-551-3601334 577 Email: plhong@ustc.edu.cn 579 Lei Zhu 580 Huawei 581 Wireless network research department 582 Haidian District , Beijing 100085 583 P. R. China 585 Phone: +86-10-60611961 586 Email: lei.zhu@huawei.com 587 Fang Yu 588 Huawei 589 Wireless network research department 590 Haidian District , Beijing 100085 591 P. R. China 593 Phone: +86-10-60611961 594 Email: lei.zhu@huawei.com