Skip to main content

IP compatible multipath framework for heterogeneous access networks
draft-amend-tsvwg-multipath-framework-mpdccp-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Markus Amend , Anna Brunstrom , Andreas Kassler , Veselin Rakocevic
Last updated 2019-03-11
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-amend-tsvwg-multipath-framework-mpdccp-00
Transport Area Working Group                                    M. Amend
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                              A. Brunstrom
Expires: September 12, 2019                                   A. Kassler
                                                     Karlstad University
                                                            V. Rakocevic
                                               City University of London
                                                          March 11, 2019

  IP compatible multipath framework for heterogeneous access networks
            draft-amend-tsvwg-multipath-framework-mpdccp-00

Abstract

   More and more of today's devices are multi-homing capable, in
   particular 3GPP user equipment like smartphones.  In the current
   standardization of the next upcoming mobile network generation 5G
   Rel. 16, this is especially targeted in the study group Access
   Traffic Steering Switching Splitting [3GPP, TR 23.793].  ATSSS
   describes the flexible selection or combination of 3GPP untrusted
   access like Wi-Fi and cellular access, overcoming the single-access
   limitation of today's devices and services.  Another multi-
   connectivity scenario is the Hybrid Access [draft-lhwxz-hybrid-
   access-network-architecture, draft-muley-network-based-bonding-
   hybrid-access], providing multiple access for CPEs, which extends the
   traditional way of single access connectivity at home to dual-
   connectivity over 3GPP and fixed access.  A missing piece in the
   ATSSS and Hybrid Access is the access and path measurement for
   efficient and beneficial traffic steering decisions.  This becomes
   particularly important in heterogeneous access networks with a
   multitude of volatile access paths.  MP-TCP can be employed in such
   scenarios and concerning the ATSSS, it is the agreed protocol for the
   traffic splitting mode.  A decision for MP-TCP though leaves the
   increasing share of UDP in today's traffic mix (https://arxiv.org/
   abs/1801.05168) unconsidered.  In this document, a network
   architecture leveraging the MP-DCCP network protocol is proposed,
   which enables above scenarios and address the formulated issues
   either independent or complementary to MP-TCP.

Status of This Memo

   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

Amend, et al.          Expires September 12, 2019               [Page 1]
Internet-Draft         MP-DCCP multipath framework            March 2019

   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://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 12, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IP compatible multipath framework based on MP-DCCP  . . . . .   3
   3.  Application and placement . . . . . . . . . . . . . . . . . .   5
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Multi-connectivity access networks are evolving.  Ongoing
   standardization at 3GPP for 5G mobile networks [3GPP, TR 23.793] or
   the so called Hybrid Access networks [draft-lhwxz-hybrid-access-
   network-architecture, draft-muley-network-based-bonding-hybrid-
   access] already provides or will provide in the near future the
   ability for multi-connectivity to a broad mass.  A superior
   resilience against network outages, higher capacities and network
   cost optimizations are only some of the reasons why it make sense to
   introduce multi-connectivity.  Since the multi-connectivity
   architectures are almost mature, it requires network protocols

Amend, et al.          Expires September 12, 2019               [Page 2]
Internet-Draft         MP-DCCP multipath framework            March 2019

   providing the technology to exploit multi-connectivity.  In the
   simplest case, multi-connectivity means load-balancing, distributing
   individual flows over multiple paths to distribute the load.
   However, this has no effect on resilience or capacity gain on those
   load balanced individual flows.  More complex are those scenarios
   where an individual flow can be seamlessly shifted between multiple
   paths or can even aggregate those paths for leveraging the sum
   capacities.  Like [3GPP, TR 23.793] this document refers to the three
   distribution schemes Steering (load balancing), Switching (seamless
   handover) and Splitting (capacity aggregation).

   MP-TCP [RFC6824] is a protocol, which can be applied in the above
   mentioned use cases and covers load-balancing, seamless communication
   handover and also capacity aggregation.  Further, it deals with
   heterogeneous and volatile access networks, since it profits from the
   TCP inherent congestion control.  By design, MP-TCP is limited to TCP
   services and excludes any other network protocol, in particular UDP.
   For future multi-connectivity systems, it is not sufficient anymore
   to rely on supporting only TCP.  The increasing share of UPD traffic,
   mainly impacted by the QUIC introduction, may significantly reduce
   the share from TCP.  It might be expected that with HTTP/3 carried
   over QUIC [draft-ietf-quic-http], the previous strong dominance of
   TCP will be challenged by UDP.

2.  IP compatible multipath framework based on MP-DCCP

   A new approach, which overcomes MP-TCP's restriction to TCP services
   and providing IP compatibility, is depicted in Fig. 1.  The
   architecture employs MP-DCCP [draft mp-dccp] in combination with an
   encapsulation scheme.  For simplification, Fig. 1 assumes a traffic
   direction from the left (sender) to the right (receiver) and requires
   application in each direction for bi-directional transmission.  The
   architecture in Fig. 1 can replace or complement MP-TCP to reach IP
   compatibility.

Service           |<-            MP-DCCP           ->|          Service
or Device                                                       or Device
+---------+        ___ +------+  DCCP Flow 1 +-------+          +---------+
|         |    _  |Seq|| Path |--------------| Re-   |     _    |         |
| Sender  |___| \___&#709;__|      |       :      | order |____/ |___|Receiver |
|         | IP|_/      | Sched|       :      |       |    \_|IP |         |
|         |   VNIF_in  | uler |--------------| engine| VNIF_out |         |
+---------+            +------+  DCCP Flow n +-------+          +---------+

       Figure 1: IP compatible multipath framework based on MP-DCCP

Amend, et al.          Expires September 12, 2019               [Page 3]
Internet-Draft         MP-DCCP multipath framework            March 2019

   PDUs generated from the sender and travelling through the
   architecture in Fig. 1 passes the components in the following order:

   1.  Sender: Generates any PDU based on the IP protocol.

   2.  VNIF_in: IP based Virtual Network Interface as entry point to the
       MP-DCCP framework.  A simple routing logic in front (between (1)
       and (2)) can act as gatekeeper and decides upon redirecting
       traffic through the VNIF or bypassing it.  The VNIF adds an extra
       IP layer to reach the multi-connectivity termination point.

   3.  Seq: Sequencing of in (2) passed PDUs depending on the incoming
       order.  Adds an incrementing number, which is later added to the
       DCCP encapsulation in (4).

   4.  Path Scheduler: Decision logic for scheduling sequenced PDUs over
       the individual connected DCCP flows for multipath transmission.
       The path scheduler can use the information from the DCCP flows
       (see (5)) inherent congestion control information like CWND,
       packet loss, RTT, Jitter.  After selection of a DCCP flow, the
       PDU is encapsulated into the individual flow.  Further
       information, at least the sequencing, is added on top as DCCP
       option.

   5.  DCCP Flow(s): Responsible to transmit the encapsulated PDUs to
       the MP-DCCP exit point.

   6.  Reorder engine: Depending on the sequencing information of (3), a
       re-assembly of the PDU stream can be applied.  The strictness of
       re-ordering shall be configurable up to no re-ordering.

   7.  VNIF_out: Releases PDUs that have passed the re-ordering engine
       and strips the DCCP specific overhead.  Again routing is
       responsible to deliver the PDUs to the receiver based on the
       destination information in the PDU.

   8.  Receiver: Receive the PDU as generated in (1).

   The simple enclosing of the MP-DCCP with Virtual Network Interface
   (VNIF) provides the IP compatibility.  However, a service or protocol
   classifier between sender and VNIF can reduce the scope to particular
   traffic, e.g.  UDP, by simple routing decisions.  The MP-DCCP takes
   over responsibility for the multi-path transfer of the traffic, which
   is directed through the VNIF_in.  For possible re-assembly operations
   the IP packets are stamped with a continuously incremented stamped
   sequence number.  This is not a mandatory operation, but assumed
   required in most seamless handover and capacity aggregation use
   cases.  The path scheduler decides for each IP packet which DCCP flow

Amend, et al.          Expires September 12, 2019               [Page 4]
Internet-Draft         MP-DCCP multipath framework            March 2019

   is appropriate, based on a configurable decision logic and supported
   by the congestion control information of the DCCP flows available for
   transmission.  A DCCP flow selection for a PDU leads to its
   encapsulation into the respective DCCP flow and adding extra
   information required for the multipath transmission, e.g. the
   sequence number.  Encapsulation also means, that to the original PDU
   a DCCP and IP header is added to reach the multi-connectivity end-
   point.  When the encapsulated PDUs arrive at the multi-path
   termination point, they are re-ordered depending on the carried
   sequence number and a configurable logic.  The re-ordering engine may
   also include a logic in which packets are just forwarded (no re-
   ordering).  Re-ordering needs to be considered carefully since any
   active intervention changes the latency responsiveness.  The multi-
   path termination is finally completed when the DCCP overhead is
   stripped and the PDU leaves VNIF_out.  Further routing depends again
   on the IP layer of the original PDU.

3.  Application and placement

   The framework of Fig. 1 gives most flexibility in applying multipath
   support in different architectures and allows MP-DCCP to be applied
   at any place between sender and receiver.  Fig2. to Fig. 5 gives an
   impression about the universality which covers any imaginable
   architecture.

    Device       Middlebox 1        Middlebox 2       Device
   +------+    +-------------+    +------------+    +--------+
   |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver|
   +------+    +-------------+    +------------+    +--------+

             Figure 2: Sender and receiver independent MP-DCCP

          Device                  Middlebox        Device
   +----------------------+    +------------+    +--------+
   |Sender + MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver|
   +----------------------+    +------------+    +--------+

       Figure 3: Sender integrated but receiver independent MP-DCCP

    Device        Middlebox                 Device
   +------+    +-------------+    +-----------------------+
   |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit + Receiver|
   +------+    +-------------+    +-----------------------+

       Figure 4: Sender independent and receiver integrated MP-DCCP

Amend, et al.          Expires September 12, 2019               [Page 5]
Internet-Draft         MP-DCCP multipath framework            March 2019

           Device                       Device
   +----------------------+    +-----------------------+
   |Sender + MP-DCCP entry| -> |MP-DCCP exit + Receiver|
   +----------------------+    +-----------------------+

             Figure 5: Sender and receiver integrated MP-DCCP

4.  Conclusion

   The specified IP compatible multipath framework based on MP-DCCP in
   this document comprises several benefits:

   o  Pure routing

   o  Inherent path estimation and measurement

   o  Imposes no reliability or in-order delivery

   o  Modular re-ordering

   o  Modular scheduling

   o  IP compatible

   o  Based on the standardized DCCP.

   Middle-box traversing, when the framework is applied in uncontrolled
   environments, is addressed in [RFC6733] and [draft u-dccp].

5.  Security Considerations

   [Tbd]

6.  Acknowledgments

7.  Informative References

   [I-D.ietf-quic-http]
              Bishop, M., "Hypertext Transfer Protocol Version 3
              (HTTP/3)", draft-ietf-quic-http-18 (work in progress),
              January 2019.

   [I-D.lhwxz-hybrid-access-network-architecture]
              Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.
              Zhang, "Hybrid Access Network Architecture", draft-lhwxz-
              hybrid-access-network-architecture-02 (work in progress),
              January 2015.

Amend, et al.          Expires September 12, 2019               [Page 6]
Internet-Draft         MP-DCCP multipath framework            March 2019

   [I-D.muley-network-based-bonding-hybrid-access]
              Muley, P., Henderickx, W., Geng, L., Liu, H., Cardullo,
              L., Newton, J., Seo, S., Draznin, S., and B. Patil,
              "Network based Bonding solution for Hybrid Access", draft-
              muley-network-based-bonding-hybrid-access-03 (work in
              progress), October 2018.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <https://www.rfc-editor.org/info/rfc6733>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

Authors' Addresses

   Markus Amend
   Deutsche Telekom
   T-Online-Allee 1
   Darmstadt
   Germany

   Email: Markus.Amend@telekom.de

   Anna Brunstrom
   Karlstad University
   Universitetsgatan 2
   651 88 Karlstad
   Sweden

   Email: anna.brunstrom@kau.se

   Andreas Kassler
   Karlstad University
   Universitetsgatan 2
   651 88 Karlstad
   Sweden

   Email: andreas.kassler@kau.se

Amend, et al.          Expires September 12, 2019               [Page 7]
Internet-Draft         MP-DCCP multipath framework            March 2019

   Veselin Rakocevic
   City University of London
   Northampton Square
   London
   United Kingdom

   Email: veselin.rakocevic.1@city.ac.uk

Amend, et al.          Expires September 12, 2019               [Page 8]