| Network Working Group | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Updates: 6824 (if approved) | France Telecom |
| Intended status: Experimental | March 9, 2015 |
| Expires: September 10, 2015 |
An Extension to MPTCP for Symmetrical Sub-Flow Management
draft-boucadair-mptcp-symmetric-02
This document specifies a MPTCP extension that allows to achieve symmetrical subflow management. In particular, this extension allows both endpoints to add new subflows whenever needed without waiting for the endpoint which initiated the first subflow to add new ones.
This document updates RFC 6824.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
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). 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."
This Internet-Draft will expire on September 10, 2015.
Copyright (c) 2015 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 Simplified BSD License.
This document specifies a MPTCP [RFC6824] extension to achieve symmetrical subflow management. The problem space is further described in Section 2, while a proposed solution is discussed in Section 3.
This document assumes Port Control Protocol (PCP)-enabled networks [RFC6887]. But other procedures can be used to instantiate mappings and discover the external lP address/port assigned by an upstream flow-aware device (e.g., CGN [RFC6888], firewall, etc.).
The following is extracted from[I-D.ietf-mptcp-experience]:
This means that in practice only the client (that is the TCP endpoint that initiated the first subflow) can initiate new subflows. This is not optimal in situations where (1) the remote endpoints want to boost their sending rate or handover to a new IP address without waiting for the client to add new subflows, (2) or when the traffic distribution as observed by the remote endpoint does not meet its local policies. Adding new subflows should be subject to both the client's and server's local policies, not only those of the client.
OLD:
1 2 3
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
+---------------+---------------+--------+--------+---------------+
| Kind | Length |ADD_ADDR| IPVer | Address ID |
+---------------+---------------+--------+--------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+---------------------------------+
| Port (2 octets) |
+-------------------------------+
NEW:
1 2 3
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
+---------------+---------------+--------+--------+---------------+
| Kind | Length |ADD_ADDR| Flags | Address ID |
+---------------+---------------+--------+--------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+---------------------------------+
| Port (2 octets) |
+-------------------------------+
+-+-+-+-+
Flags is a set of 4 flags: |C|r|r|r|
+-+-+-+-+
C flag MUST be set to 1 when the address/port are checked.
"rrr" are for future assignment as additional flag bits.
r bits MUST each be sent as zero and MUST be ignored on receipt.
Figure 1
This procedure can be activated upon bootstrap or when a network attachment change occurs (e.g., attach to a new network); it is not executed for every new MPTCP connection:
PCP-related security considerations are discussed in [RFC6887]. MPTCP-related security considerations are documented in [RFC6824] and [I-D.ietf-mptcp-attacks].
TBC.
Many thank to Olivier Bonaventure who suggested the idea of updating ADD_ADDR.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6824] | Ford, A., Raiciu, C., Handley, M. and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. |