--- 1/draft-ietf-mptcp-architecture-00.txt 2010-06-22 12:13:26.000000000 +0200 +++ 2/draft-ietf-mptcp-architecture-01.txt 2010-06-22 12:13:26.000000000 +0200 @@ -1,118 +1,114 @@ Internet Engineering Task Force A. Ford, Ed. Internet-Draft Roke Manor Research Intended status: Informational C. Raiciu -Expires: September 1, 2010 University College London +Expires: December 24, 2010 University College London S. Barre Universite catholique de Louvain J. Iyengar Franklin and Marshall College - February 28, 2010 + June 22, 2010 Architectural Guidelines for Multipath TCP Development - draft-ietf-mptcp-architecture-00 + draft-ietf-mptcp-architecture-01 Abstract Endpoints are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the Multipath TCP (MPTCP) protocol. This document also lists certain high level design decisions that provide foundations for the MPTCP design, based upon these architectural requirements. Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 1, 2010. + This Internet-Draft will expire on December 24, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as - described in the BSD License. + described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Reference Scenario . . . . . . . . . . . . . . . . . . . . 5 - 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 6 - 2.2.1. Application Compatibility . . . . . . . . . . . . . . 6 + 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 7 + 2.2.1. Application Compatibility . . . . . . . . . . . . . . 7 2.2.2. Network Compatibility . . . . . . . . . . . . . . . . 7 2.2.3. Compatibility with other network users . . . . . . . . 8 - 3. An Architectural Basis For MPTCP . . . . . . . . . . . . . . . 8 + 3. An Architectural Basis For MPTCP . . . . . . . . . . . . . . . 9 4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 10 - 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 11 + 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 12 5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 12 5.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 14 + 5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 15 - 5.6. Connection Identification . . . . . . . . . . . . . . . . 15 + 5.6. Connection Identification . . . . . . . . . . . . . . . . 16 5.7. Network Layer Compatibility . . . . . . . . . . . . . . . 16 - 5.8. Congestion Control . . . . . . . . . . . . . . . . . . . . 16 - 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 5.8. Congestion Control . . . . . . . . . . . . . . . . . . . . 17 + 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Interactions with Applications . . . . . . . . . . . . . . . . 17 - 9. Interactions with Middleboxes . . . . . . . . . . . . . . . . 17 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Appendix A. Implementation Architecture . . . . . . . . . . . . . 19 - A.1. Functional Separation . . . . . . . . . . . . . . . . . . 19 - A.1.1. Application to default MPTCP protocol . . . . . . . . 19 - A.1.2. Generic architecture for MPTCP . . . . . . . . . . . . 22 - A.2. PM/MPS interface . . . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9. Interactions with Middleboxes . . . . . . . . . . . . . . . . 18 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Appendix A. Implementation Architecture . . . . . . . . . . . . . 21 + A.1. Functional Separation . . . . . . . . . . . . . . . . . . 21 + A.1.1. Application to default MPTCP protocol . . . . . . . . 21 + A.1.2. Generic architecture for MPTCP . . . . . . . . . . . . 24 + A.2. PM/MPS interface . . . . . . . . . . . . . . . . . . . . . 25 + Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 + B.1. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction As the Internet evolves, demands on Internet resources are ever- increasing, but often these resources (in particular, bandwidth) cannot be fully utilised due to protocol constraints both on the end- systems and within the network. If these resources could instead be used concurrently, end user experience could be greatly improved. Such enhancements would also reduce the necessary expenditure on network infrastructure which would otherwise be needed to create an @@ -177,23 +173,50 @@ endpoints. Subflow: A flow of TCP packets operating over an individual path, which forms part of a larger MPTCP connection. MPTCP Connection: A set of one or more subflows combined to provide a single Multipath TCP service to an application at an endpoint. 1.3. Reference Scenario - TBD - would this be useful? + The diagram shown in Figure 1 illustrates a typical usage scenario + for MPTCP. Two hosts, A and B, are communicating with each other. + These endpoints are multi-homed and multi-addressed, providing two + disjoint connections to the Internet. The addresses on each endpoint + are referred to as A1, A2, B1 and B2. There are therefore up to four + different paths between the two endpoints: A1-B1, A1-B2, A2-B1, + A2-B2. - Endpoints, routes. Addresses/path selection mechanisms? + +------+ __________ +------+ + | |A1 ______ ( ) ______ B1| | + | Host |--/ ( ) \--| Host | + | | ( Internet ) | | + | A |--\______( )______/--| B | + | |A2 (__________) B2| | + +------+ +------+ + + Figure 1: Simple MPTCP Usage Scenario + + The scenario could have any number of addresses (1 or more) on each + endpoint, so long as the number of paths available between the two + endpoints is 2 or more (i.e. num_addr(A) * num_addr(B) > 1). The + paths created by these address combinations through the Internet need + not be entirely disjoint - shared bottlenecks will be addressed by + the MPTCP congestion controller. Furthermore, the paths through the + Internet may be interrupted by any number of middleboxes including + NATs and Firewalls. Finally, although the diagram refers to the + Internet, MPTCP may be used over any network where there are multiple + paths that could be used concurrently. + + TBD - what further detail here would be useful? 2. Goals This section outlines primary goals that Multipath TCP aims to meet. These are broadly broken down into functional goals, which steer services and features that MPTCP must provide, and compatibility goals, which determine how MPTCP should appear to entities that interact with it. 2.1. Functional Goals @@ -252,49 +275,49 @@ to permit multipath-aware applications to specify preferences, nor for users to configure their systems in a different way from the default, for example switching on or off the automatic use of MPTCP. 2.2.2. Network Compatibility Traditional Internet architecture slots network devices in the network layer and lower layers of the OSI 7-layer stack, where the layers above the network layer - the transport layer and upper layers - are instantiated only at the end-hosts. While this architecture, - shown in Figure 1, was largely adhered to earlier, this layering no + shown in Figure 2, was largely adhered to earlier, this layering no longer reflects the "ground truth" in the Internet with the proliferation of middleboxes[8]. Middleboxes routinely interpose on the transport layer; sometimes even completely terminating transport connections, thus leaving the application layer as the first real - end-to-end layer, as shown in Figure 2. + end-to-end layer, as shown in Figure 3. +-------------+ +-------------+ | Application |<------------ end-to-end ------------->| Application | +-------------+ +-------------+ | Transport |<------------ end-to-end ------------->| Transport | +-------------+ +-------------+ +-------------+ +-------------+ | Network |<->| Network |<->| Network |<->| Network | +-------------+ +-------------+ +-------------+ +-------------+ End Host Router Router End Host - Figure 1: Traditional Internet Architecture + Figure 2: Traditional Internet Architecture +-------------+ +-------------+ | Application |<------------ end-to-end ------------->| Application | +-------------+ +-------------+ +-------------+ | Transport |<------------------->| Transport |<->| Transport | +-------------+ +-------------+ +-------------+ +-------------+ | Network |<->| Network |<->| Network |<->| Network | +-------------+ +-------------+ +-------------+ +-------------+ Firewall, End Host Router NAT, or Proxy End Host - Figure 2: Internet Reality + Figure 3: Internet Reality Middleboxes that interpose on the transport layer result in loss of "fate-sharing"[9], that is, they often hold "hard" state that, when lost or corrupted, results in loss or corruption of the end-to-end transport connection. MPTCP MUST remain backward compatible with the Internet as it exists today, including being able to traverse predominant middleboxes such as firewalls, NATs, and performance enhancing proxies[8]. This requirement comes from recognizing middleboxes as a significant @@ -331,104 +354,104 @@ | Application | +------------------+ ^ Application-oriented transport | | | functions (Semantic Layer) + - - Transport - -+ ---------------------------------- | | | Network-oriented transport +------------------+ v functions (Flow+Endpoint Layer) | Network | +------------------+ Existing Layers Tng Decomposition - Figure 3: Decomposition of Transport Functions + Figure 4: Decomposition of Transport Functions Tng loosely splits the transport layer into "application-oriented" - and "network-oriented" layers, as shown in Figure 3. The + and "network-oriented" layers, as shown in Figure 4. The application-oriented "Semantic" layer implements functions driven primarily by concerns of supporting and protecting the application's end-to-end communication, while the network-oriented "Flow+Endpoint" layer implements functions such as endpoint identification (using port numbers) and congestion control. These network-oriented functions, while traditionally located in the ostensibly "end-to-end" Transport layer, have proven in practice to be of great concern to network operators and the middleboxes they deploy in the network to enforce network usage policies[11] [12] or optimize communication - performance[13]. Figure 4 shows how middleboxes interact with + performance[13]. Figure 5 shows how middleboxes interact with different layers in this decomposed model of the transport layer: the application-oriented layer operates end-to-end, while the network- oriented layer operates "segment-by-segment" and can be interposed upon by middleboxes. +-------------+ +-------------+ | Application |<------------ end-to-end ------------->| Application | +-------------+ +-------------+ | Semantic |<------------ end-to-end ------------->| Semantic | +-------------+ +-------------+ +-------------+ +-------------+ |Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint| +-------------+ +-------------+ +-------------+ +-------------+ | Network |<->| Network |<->| Network |<->| Network | +-------------+ +-------------+ +-------------+ +-------------+ Firewall Performance End Host or NAT Enhancing Proxy End Host - Figure 4: Middleboxes in the new Internet model + Figure 5: Middleboxes in the new Internet model MPTCP's architectural design follows Tng's decomposition as shown in - Figure 5. The MPTCP component, which provides application + Figure 6. The MPTCP component, which provides application compatibility through the preservation of TCP-like semantics of global ordering of application data and reliability, is an instantiation of the "application-oriented" Semantic layer; whereas the legacy-TCP component, which provides network compatibility by appearing and behaving as a TCP flow in network, is an instantiation of the "network-oriented" Flow+Endpoint layer. +--------------------------+ +-------------------------+ | Application | | Application | +--------------------------+ +-------------------------+ | Semantic | | MPTCP | |--------------------------| + - - - - - + - - - - - + | Flow+Endpt | Flow+Endpt | | TCP | TCP | +--------------------------+ +-------------------------+ | Network | Network | | IP | IP | +--------------------------+ +-------------------------+ - Figure 5: MPTCP mapping to Tng + Figure 6: MPTCP mapping to Tng As a protocol extension to TCP, MPTCP thus explicitly acknowledges middleboxes in its design, and specifies a protocol that operates at two scales: the MPTCP component operates end-to-end, while it allows the TCP component to operate segment-by-segment. 4. A Functional Decomposition of MPTCP Having laid out the goals to be met and the architectural basis for MPTCP, we now provide a functional decomposition MPTCP's design. The MPTCP component relies upon (what appear to the network to be) standard TCP sessions, termed "subflows", to provide the underlying transport per path, and as such these retain the network compatibility desired. MPTCP as described in [3] carries MPTCP- specific information in a TCP-compatible manner, although this mechanism is separate from the actual information being transferred - so could evolve in future revisions. Figure 6 illustrates the + so could evolve in future revisions. Figure 7 illustrates the layered architecture. +-------------------------------+ | Application | +---------------+ +-------------------------------+ | Application | | MPTCP | +---------------+ + - - - - - - - + - - - - - - - + | TCP | | Subflow (TCP) | Subflow (TCP) | +---------------+ +-------------------------------+ | IP | | IP | IP | +---------------+ +-------------------------------+ - Figure 6: Comparison of Standard TCP and MPTCP Protocol Stacks + Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks Situated below the application, the MPTCP extension manages multiple TCP subflows below it and must implement the following functions: o Path Management: This is the function to detect and use multiple paths between two endpoints. In the case of the MPTCP design [3], this feature is implemented using multiple IP addresses at least one of the endpoints. Although this does not guarantee path diversity, and there may be shared bottlenecks, this is a simple mechanism that can be used with no additional features in the @@ -635,21 +658,26 @@ 5.5. Path Management Currently, the network does not expose multiple paths between endpoints. Multipath TCP will use multiple addresses at one or both endpoints to get different paths to the destination. The hope is that these paths, whilst not necesarily entirely non-overlapping, will be sufficiently disjoint to allow multipath achieve improved throughput and robustness. Multiple different (source, destination) address pairs will thus be - used as path selectors. + used as path selectors. Each path will be identified by a TCP + 4-tuple (i.e. source address, destination address, source port, + destination port), thus allowing the extension of MPTCP to use such + 4-tuples as path selectors if the network will route different ports + over different paths (which may be the case with technologies such as + ECMP). For increased chance of successfully setting up additional subflows (such as when one end is behind a firewall, NAT, or other restrictive middlebox), either endpoint should be able to add new subflows to a MPTCP connection. The modularity of path management will permit alternative mechanisms to be employed if appropriate in the future. 5.6. Connection Identification @@ -724,45 +752,88 @@ the protocol design [3]. 8. Interactions with Applications Interactions with applications - incuding, but not limited to, performances changes that may be expected, semantic changes, and new features that may be requested of an API, are presented in [7]. 9. Interactions with Middleboxes - TBD + As discussed in Section 2.2, it is a goal of MPTCP to be deployable + today and thus compatible with the majority of middleboxes. This + section summarises the issues that may arise with NATs, firewalls, + proxies, intrusion detection systems, and other middleboxes that, if + not considered in the protocol design, may hinder its deployment. - This section will contain a list of issues that may arise with NATs, - firewalls, proxies, intrusion detection systems, etc. + This section is intended primarily as a description of options and + considerations only. Protocol-specific solutions to these issues + will be given in the companion documents. - This will be an overview only, to the level of suggested high-level - solutions as presented in this document (e.g. dual-level sequence - space), but protocol-specific solutions to these issues will be given - in the companion documents. + Multipath TCP will be deployed in a network that no longer provides + just basic datagram delivery. A miriad of middleboxes are deployed + to optimize various perceived problems with the Internet protocols: + NATs primarily address space shortage [11], Performance Enhancing + Proxies (PEPs) optimize TCP for different link characteristics [13], + firewalls [12] and intrusion detection systems try to block malicious + content from reaching a host, and traffic normalizers [15] ensure a + consistent view of the traffic stream to IDSes and hosts. - Example points include: + All these middleboxes optimize current applications at the expense of + future applications. In effect, future applications must mimic + existing ones if they want to be deployed. Further, the precise + behaviour of all these middleboxes is not clearly specified, and + implementation errors make matters worse, raising the bar for the + deployment of new technologies. - o NATs: change addresses + The following list of middlebox classes documents behaviour that + could impact the use of MPTCP. This list is used in [3] to describe + the features of the MPTCP protocol that are used to mitigate the + impact of these middlebox behaviours. - o NATs/Firewalls: drop options; split, coalesce packets; change - sequence numbering? + o NATs: Network Address Translators decouple the endpoint's local IP + address with that which is seen in the wider Internet when the + packets are transmitted through a NAT. This adds complexity, and + reduces the chances of success, when signalling IP addresses. - o Firewalls: block incoming connection attempts; block unknown TCP - options + o PEPs: Performance Enhancing Proxies, which aim to improve the + performance of protocols over low-performance (e.g. high latency + or high error rate) links. As such, they may "split" a TCP + connection and behaviour such as proactive ACKing may occur. As + with NATs, it is no longer guaranteed that one endpoint is + communicating directly with another. - o Proxies: PEPs can terminate TCP sessions before an endpoint + o Traffic Normalizers: These aim to eliminate ambiguities and + potential attacks at the network level, and amongst other things + are unlikely to permit holes in sequence space. - o Intrusion Detection: require ways to correlate subflows + o TCP Options: many middleboxes are in a position to drop packets + with unknown TCP options, or strip those options from the packets. - o ... + o Segmentation/Colescing: middleboxes (or even something as close to + the end host as TCP Segmentation Offloading) may change the packet + boundaries from those which the sender intended. It may do this + by splitting packets, or coalescing them together. This leads to + two major impacts: we cannot guarantee where a packet boundary + will be, and we cannot say for sure what a middlebox will do with + TCP options in these cases (they may be repeated, dropped, or sent + only once). + + o Firewalls: on top of preventing incoming connections, firewalls + may also attempt additional protection such as sequence number + randomization. + + o Intrusion Detection Systems: IDSs may look for traffic patterns to + protect a network, and may have false positives with MPTCP and + drop the connections during normal operation. For future MPTCP- + aware middleboxes, they will require the ability to correlate the + various paths in use. 10. Acknowledgements Alan Ford, Costin Raiciu and Sebastien Barre are supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document. @@ -784,36 +854,36 @@ 13.2. Informative References [2] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, October 2008, . [3] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for Multipath Operation with Multiple Addresses", - draft-ford-mptcp-multiaddressed-02 (work in progress), - October 2009. + draft-ietf-mptcp-multiaddressed-00 (work in progress), + June 2010. [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath- - Aware Congestion Control", draft-raiciu-mptcp-congestion-00 - (work in progress), October 2009. + Aware Congestion Control", draft-raiciu-mptcp-congestion-01 + (work in progress), March 2010. [7] Scharf, M. and A. Ford, "MPTCP Application Interface - Considerations", draft-scharf-mptcp-api-00 (work in progress), - October 2009. + Considerations", draft-scharf-mptcp-api-01 (work in progress), + March 2010. [8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [9] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [10] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", ACM HotNets, October 2008. @@ -821,25 +891,27 @@ Translator (Traditional NAT)", RFC 3022, January 2001. [12] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000. [13] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001. [14] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path - TCP", draft-ietf-mptcp-threat-00 (work in progress), - February 2010. + TCP", draft-ietf-mptcp-threat-02 (work in progress), + March 2010. - [15] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion - Control", RFC 5681, September 2009. + [15] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion + Detection: Evasion, Traffic Normalization, and End-to-End + Protocol Semantics", Usenix Security 2001, 2001, . Appendix A. Implementation Architecture This section provides suggestions for an architecture to implement an extensible, modular multipath transport protocol. A.1. Functional Separation This section describes a generic view of the internal implementation of a Multipath TCP, through which the technical components specified @@ -851,21 +923,21 @@ is completely contained in the transport layer. That solution is described in more details in [3]. Then we generalize the approach to allow good extensibility of that solution. A.1.1. Application to default MPTCP protocol Although, in the default approach, MPTCP is fully contained in the transport layer, it can still be divided into two main modules. One manages the scheduling of packets as well as congestion control. The other one manages the control of paths. The interface between the - two is dealt with thanks to a Path Index. As shown in Figure 7, the + two is dealt with thanks to a Path Index. As shown in Figure 8, the Path Manager announces to the MultiPath Scheduler what paths can be used trough path indices, and maintains the mapping between that value and the particular action that it must apply to use the path (an example of such a mapping is in Table 1). In the case of the built-in Path Manager, the action is to replace an address/port pair with another one, in such a way that another path is used across the Internet to forward that packet. Control plane <-- | --> Data plane +---------------------------------------------------------------+ @@ -884,21 +956,21 @@ +--------------------------------------------------\------------+ / \ | \ /-----------------------------\ | /"\ /"\ /"\ /"\ | rewriting table: || | | | | | | | | | Subflow id <--> network_id || | | | | | | | | | || | | | | | | | | | [see table below] || | | | | | | | | | || \./ \./ \./ \./ +------------------------------+| path1 path2 path3 path4 - Figure 7: Functional separation of MPTCP in the transport layer + Figure 8: Functional separation of MPTCP in the transport layer The MultiPath Scheduler only deals with abstract paths, represented by numbers. It only sees one address pair throughout the communication, that we call the connection identifier. However, the MultiPath Scheduler must be able to perform per-subflow congestion control, and thus to distinguish between the subflows. This leads to define a subflow identifier, that consists of the usual transport identifier extended with the path index: . The following options, described in [3], are managed by the MultiPath Scheduler. @@ -969,21 +1041,21 @@ be able to fallback to the default PM in case the other end does not support the custom PM. Alternative Path Managers may be specified in separate documents in the future. A.1.2. Generic architecture for MPTCP Now that the functional decomposition has been shown for MPTCP with the built-in Path Manager, we show how that architecture can be generalized to allow the implementation of other Path Managers for MPTCP. A general overview of the architecture is provided in - Figure 8. The Multipath Scheduler (MPS) learns about the number of + Figure 9. The Multipath Scheduler (MPS) learns about the number of available paths through notifications received from the Path Manager (PM). From the point of view of the Multipath Scheduler, a path is just a number, called a Path Index. Notifications from the PM to the MPS MAY contain supporting information about the paths, if relevant, so that the MPS can make more intelligent decisions about where to route traffic. When the Multipath Scheduler initiates a communication to a new host, it can only send the packets to the default path. But since the Path manager is layered below the MPS, it can detect that a new communication is happening, and tell the MPS about the other paths it knows about. @@ -1004,25 +1076,25 @@ | Path Manager (PM) \__________zzzzz | +--------------------------------------------------------\------+ / \ | \ /---------------------------\ | /"\ /"\ /"\ | subflow_id Action | | | | | | | | | xxxxx | | | | | | | | | yyyyy | | \./ \./ \./ | zzzzz | | path1 path2 path3 +---------------------------+ - Figure 8: Overview of MPTCP architecture + Figure 9: Overview of MPTCP architecture From then on, it is possible for the MPS to associate a Path Index with its packets, so that the Path Manager can map this Path Index to - a particular action (see table in the lower left part of Figure 8). + a particular action (see table in the lower left part of Figure 9). The particular action depends on the network mechanism used to select a path. Examples are address rewriting, tunnelling or setting a path selector value inside the packet. Note that the Path Index is not supposed to be written inside the packet, but instead associated with it, internally to the implementation. The applicability of the architecture is not limited to the MPTCP protocol. While we define in this document an MPTCP MPS (MPTCP Multipath Scheduler), other Multipath Schedulers can be defined. For example, if an appropriate socket interface is designed, applications @@ -1064,20 +1136,30 @@ what outgoing path is acknowledged by an incoming packet. o Module interface: A PM MUST be able to notify the MPS about the number of available paths. Such notifications MUST contain the path indices that are legal for use by the MPS. In case the PM decides to stop providing service for one path, it MUST notify the MPS about path removal. Additionnaly, a PM MAY provide complementary path information when available, such as link quality or preference level. +Appendix B. Changelog + +B.1. Changes since draft-ietf-mptcp-architecture-00 + + o Added middlebox compatibility discussion (Section 9). + + o Clarified path identification (TCP 4-tuple) in Section 5.5. + + o Added brief scenario and diagram to Section 1.3. + Authors' Addresses Alan Ford (editor) Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK Phone: +44 1794 833 465 Email: alan.ford@roke.co.uk