[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         N. Leymann
Internet-Draft                                              C. Heidemann
Intended status: Informational                       Deutsche Telekom AG
Expires: July 18, 2015                                      M. Wesserman
                                                       Painless Security
                                                                  L. Xue
                                                                M. Zhang
                                                                  Huawei
                                                        January 14, 2015


                   Hybrid Access Network Architecture
           draft-lhwxz-hybrid-access-network-architecture-02

Abstract

   Residential and Enterprise customers require continuously increasing
   bandwidth, however it may be difficult for operators to update or
   rebuild existing fixed access networks, especially when they are
   deployed in certain areas.  This document discusses a general way to
   address this problem by bundling together multiple heterogeneous
   access networks according to certain management policies.

Requirements Language

   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]

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
   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 April 27, 2015.






Leymann, et al.          Expires July 18, 2015                  [Page 1]


Internet-Draft                  HYA-arch                January 14, 2015


Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Customer Scenarios  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Traffic Distribution Schemes  . . . . . . . . . . . . . . . .   5
   5.  Hybrid Access Architecture  . . . . . . . . . . . . . . . . .   8
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Residential and Enterprise customers require continuously increasing
   bandwidth, however it may be difficult for operators to update or
   rebuild existing fixed access networks, especially when they are
   deployed in certain locations (e.g., old downtown areas).  Fiber to
   the Home (FTTH) is an option to solve this issue, however, it may be
   not deployable in some geographical circumstances (e.g., rural
   areas).  This document discusses a general way to address this
   problem by bundling together multiple heterogeneous access networks
   (e.g., LTE, DSL, etc.) in a flexible manner.

   This document calls HYbrid access (HYA) a generic mechanism for
   bundling together multiple heterogeneous access networks.  In this
   mechanism the Customer Premise Equipment (CPE) is enhanced to support
   the multiple heterogeneous access networks simultaneously.  The HYA
   mechanism needs to provide flexibility in deciding the paths over
   which to forward data traffic.  This document proposes a generic




Leymann, et al.          Expires July 18, 2015                  [Page 2]


Internet-Draft                  HYA-arch                January 14, 2015


   architectural design for the HYA mechanism and identifies potential
   issues and requirements.

   The remainder of this document is organized as follows.  Section 2
   lists the key terms used in this document.  Section 3 introduces
   customer scenarios and the associated requirements for bundling
   heterogeneous access networks.  Section 4 discusses the traffic
   distribution schemes among the multiple heterogeneous access
   networks, flow-based forwarding and packet-based forwarding.
   Section 6 discusses the technology issues and requirements to be
   addressed in IETF.

2.  Terminology

   Customer Premise Equipment (CPE):  A device that connects multiple
      hosts to provide connectivity to a service provider network.

   HYbrid Access (HYA):  The bundling of two or more access lines based
      on heterogeneous technologies (e.g., DSL and LTE) to provide to an
      residential or enterprise customer an higher bandwidth Internet
      connection.

   Bundling Gateway (BGW):  The service point that implements the
      bundling mechanism and provides a higher bandwidth Internet
      connection to the CPE from two or more heterogeneous access
      networks.  The BGW is a logical function.  It should support
      packets reordering, if needed.

   Path:  A sequence of links between the CPE and the BGW.

3.  Customer Scenarios

   Figure 1 illustrates a significant customer scenario.  In this
   scenario a customer site (either home or enterprise) is connected to
   the Internet through a CPE providing both wired and wireless
   connectivity through a fixed access network.  The customer site is
   also covered by 3G/4G cellular signal, able to provide Internet
   connectivity as well.

   Hosts in the customer site may connect to the Internet through the
   CPE, the 3G/4G network, or both.  In most cases the majority of the
   hosts connects to the Internet through the CPE only and will
   experience slow Internet access when the bandwidth provided by the
   fixed access network is fully utilized (e.g., the traffic over the
   fixed access network reached its maximum capacity or a pre-specified
   threshold set by the operator).  In this case, the problem could be
   addressed if the CPE is able to access the 3G/4G network and provide
   additional bandwidth to these hosts without requiring an upgrade of



Leymann, et al.          Expires July 18, 2015                  [Page 3]


Internet-Draft                  HYA-arch                January 14, 2015


   the fixed access network as shown in Figure 2.  Upgrading a fixed
   access network may be costly and slow, especially in the areas with
   limited accessibility.  Having a CPE able to take advantage of the
   bandwidth resources of the 3G/4G cellular network and of the fixed
   access network concurrently is very desirable for an operator,
   especially if the 3G/4G cellular backhaul network is not used at its
   fullest capacity.

     +----+
     |HOST%LTE only           ------
     +----+                /          \
                   %======+   Wireless +===+
     +----+               |    3G/4G   |    \   *****
     |    %LTE             \          /       **     **
     |HOST*WiFi               ------         *         *
     +----+     +-----+                     *  Internet *
            WiFi*     |       ------         *         *
     +----+     |     |    /          \       **     **
     |HOST+-----+ CPE +---+            |    /   *****
     +----+Wired|     |   |   Fixed    +---/
                |     |    \          /
     +----+     +-----+       ------
     |HOST*WiFi only
     +----+

                 Figure 1: Existing Home Network Scenario

   Additionally, the hosts without 3G/4G cellular interface will suffer
   from service interruption when the fixed access network fails.  If
   the CPE is able to access the 3G/4G network as shown in Figure 2, the
   reliability for the customer service connection is enhanced.

   As illustrated in Figure 2, in order to make use of both the fixed
   access network and the 3G/4G cellular network, the CPE of the
   customer should be connected to both networks.  The customer traffic
   may be routed over both these access networks simultaneously.  The
   network architecture proposed in Figure 2 is flexible and may be
   extended to cover multiple access network combinations.  To ensure
   that existing services are not influenced by this architecture,
   certain traffic (e.g., VoIP) must not be split over more than one
   path to guarantee required performance.  This traffic may be kept in
   the fixed access network.









Leymann, et al.          Expires July 18, 2015                  [Page 4]


Internet-Draft                  HYA-arch                January 14, 2015


    +----+                   ------
    |    |                /          \
    |HOST|     +-----+   |  Wireless  +---\
    |    *     *     | +-+    3G/4G   |    \   *****
    +----+ WiFi|     +-+  \          /       **     **
               |     |       ------         *         *
    +----+     | CPE |                     *  Internet *
    |    |     |     |       ------         *         *
    |HOST+-----+     +-+  /          \       **     **
    |    |Wired|     | +-+            |    /   *****
    +----+     +-----+   |    Fixed   +---/
                          \          /
                             ------

                Figure 2: High Level Hybrid Access Scenario

4.  Traffic Distribution Schemes

   Two forwarding schemes can be applied to the hybrid access scenario
   depicted in Figure 2, flow-based forwarding and packet-based
   forwarding.

   In flow-based forwarding, forwarding policies are specified at the
   flow level.  The customer traffic is classified in flows and each
   flow is associated to a single forwarding path.  Packets belonging to
   a certain flow may be identified by their destination IP address,
   source IP address, IP protocol type, destination port, and source
   port (i.e., the 5-tuple), or by any other means.  Upon receiving a
   packet from a host, the CPE identifies the flow that the packet
   belongs to and forwards the packet according to the policies
   specified for such a flow (e.g., flow A is forwarded into the 3G/4G
   network and flow B is forwarded into the fixed network, see
   Figure 3).  When one of the multiple heterogeneous access network
   fails, the CPE MAY select to forward the host packets into other
   available access networks.

   It is easy for a CPE to forward the upstream traffic (from hosts to
   the Internet) to pre-defined paths according to the flow based rules.
   However, the CPE itself cannot decide the paths over which the
   downstream traffic will be routed, as shown in Figure 7.  Deploying a
   Bundling Gateway (see Figure 8) at the Internet side will resolve
   this problem.  The BGW may apply the same flows classification rules
   of the CPE and forward the downstream traffic to the proper access
   network (see Figure 5).  In addition, tunneling or NAT technologies
   in the CPE (e.g., NAT66 on the CPE, or NAT deployed after the CPE in
   the 3G/4G network or in the fixed network, see Figure 4) may help to
   solve this problem.




Leymann, et al.          Expires July 18, 2015                  [Page 5]


Internet-Draft                  HYA-arch                January 14, 2015


                             ------
                          /          \
               +-----+   |  Wireless  +---\
               |     +---+    3G/4G   |    \   *****
    +----+     |     =======================>**     **
    |    =============    \  ------  /      *         *
    |HOST+-----+ CPE |                     *  Internet *
    |    .............    /  ------ \       *         *
    +----+     |     .......................>**     **
               |     +---+            |    /   *****
               +-----+   |    Fixed   +---/
                          \          /
                             ------

                 Figure 3: Flow-Based Forwarding-Upstream

                     Public IPv6 Prx1
                             /    ------
                            /  /          \
                    +-----+/  |  Wireless  +---\
     Local IPv6 Prx1|     *---+    3G/4G   |    \   *****
         +----+|    |     ========================**     **
         |    <*===========    \  ------  /      *         *
         |HOST+-----+ CPE |                     *  Internet *
         |    <*...........    /  ------ \       *         *
         +----+ \   |     ........................**     **
     Local IPv6 Prx2|NAT66*---+            |    /   *****
                    +-----+\  |    Fixed   +---/
                            \  \          /
                             \    ------
                     Public IPv6 Prx2

             Figure 4: Flow-Based Forwarding-Downstream Case 1


















Leymann, et al.          Expires July 18, 2015                  [Page 6]


Internet-Draft                  HYA-arch                January 14, 2015


                              ------
                           /          \
                +-----+   |  Wireless  +---\ +-----+
                |     +---+    3G/4G   |    \|     |        *****
     +----+     |     =======================|     |      **     **
     |    <============    \  ------  /      |     |     *         *
     |HOST+-----+ CPE |                      | BGW <=.=.= Internet *
     |    <............    /  ------ \       |     |     *         *
     +----+     |     .......................|     |      **     **
                |     +---+            |    /|     |        *****
                +-----+   |    Fixed   +---/ +-----+
                           \          /
                              ------

             Figure 5: Flow-Based Forwarding-Downstream Case 2

   In packet-based forwarding, forwarding policies are specified at the
   packet level.  Packets belonging to the same flow may be forwarded
   over different paths (see Figure 6).

   The packet-based forwarding enables a CPE to control the packet
   distribution over different paths in a more flexible and more fine-
   grained way.  However, with the packet-based forwarding the packets
   belonging to a same flow may reach their destination out of order.  A
   device (see the BGW in Figure 6) able to perform packets reordering
   at the remote side may be required.  In flow-based forwarding, the
   out-of-order packet issue does not occur.

                             ------
                          /          \
               +-----+   |  Wireless       +----+
               | CPE +---+   3G/4G    |    |BGW |      *****
    +----+     |     .........................  |    **     **
    |    |     |     .    \  ------  /     | .  |   *         *
    |HOST+-----+     .                     | .  +--*  Internet *
    |    <...........*    /  ------ \      | *.....>*         *
    +----+     |     .........................  |    **     **
               |     +---+            |    |    |      *****
               +-----+   |    Fixed   +---/+----+
                          \          /
                             ------

                     Figure 6: Packet-Based Forwarding

   Flow-based forwarding is very similar to load balancing technologies,
   and it is easy for operators to deploy.  On the other side, the
   static association of flows to specific paths is disadvantageous,
   because the bandwidth consumption of each flow may change over time



Leymann, et al.          Expires July 18, 2015                  [Page 7]


Internet-Draft                  HYA-arch                January 14, 2015


   and may be difficult to predict.  Thus, it is difficult to guarantee
   the traffic balance among the different paths over time.  In
   addition, in certain scenarios without a BGW, it may be difficult to
   guarantee that the upstream and downstream packets within the same
   flow are forwarded over the same path.  Then it is difficult to
   guarantee the service performance.

   Packet-based forwarding leverages the smallest granularity in current
   packet networks, so it provides the most flexible and fine-grained
   way to use the available bandwidth.  However, the reordering and
   buffering issues may lead to scalability limits.  It may cost more
   for operators.

   In this document, we do not conclude which one is the best.  Both
   distribution schemes can meet specific service requirements and be
   relevant depending on the situation.  The operators may evaluate the
   cost and efficiency aspects of both schemes in order to choose the
   best solution for their network.

5.  Hybrid Access Architecture

   Two high level hybrid access architectures (see Figure 2) enable a
   CPE to use all available access networks simultaneously (i.e.,
   through flow-based distribution or/and packet-based distribution):

   o  CPE-only, without Bundling Gateway, as shown in Figure 7.  In this
      architecture, the CPE is the only entity performing traffic
      distribution, based on pre-configured policies or on dynamic
      configurations.  This architecture cannot guarantee that the
      downstream traffic is routed on the same path of the upstream
      traffic and therefore it is useful mostly for redundancy only (see
      Figure 3 and Figure 4).

   This architecture is currently outside the scope of this document.

















Leymann, et al.          Expires July 18, 2015                  [Page 8]


Internet-Draft                  HYA-arch                January 14, 2015


    +----+                   ------
    |    |                /          \
    |HOST|     +-----+   |  Wireless  +---\
    |    *     *     | +-+    3G/4G   |    \   *****
    +----+ WiFi|     +-+  \          /       **     **
               |     |       ------         *         *
    +----+     | CPE |                     *  Internet *
    |    |     |     |       ------         *         *
    |HOST+-----+     +-+  /          \       **     **
    |    |Wired|     | +-+            |    /   *****
    +----+     +-----+   |    Fixed   +---/
                          \          /
                             ------

             Figure 7: Hybrid Access Architecture without BGW

   o  CPE with Bundling Gateway, as shown in Figure 8.  In this
      architecture, a BGW function is deployed at the remote side of a
      CPE, to ensure that the downstream traffic is routed on the same
      path of the upstream traffic.  An in-band control plane protocol
      between the CPE and the BGW may be used to negotiate distribution
      policies, such as flow-based distribution among policy different
      interfaces, packets reordering for the packet-based distribution
      scenario (see Figure 6), etc.  This architecture is what we need
      to consider in IETF.

   Referring to Figure 3, a distribution policy for the CPE may specify
   to forward upstream packets belonging to a certain flow over the
   3G/4G network when the load of the fixed network reaches a pre-
   specified threshold.  If later enough bandwidth of the fixed network
   becomes available, the CPE may switch back upstream packets to the
   fixed network.  The distribution policy should be defined by the
   operators.  Referring to Figure 6, the CPE and BGW can have
   independent packet-based behavior.  If operators desire only a subset
   of flows to be distributed over multiple paths, the CPE and BGW will
   use the in-band control plane protocol for negotiation.  More
   management policies should be negotiated, such as how to use the
   access networks metrics (capability, state, etc.) to enable dynamic
   traffic distribution policy adjustments, etc.












Leymann, et al.          Expires July 18, 2015                  [Page 9]


Internet-Draft                  HYA-arch                January 14, 2015


    +----+                   ------
    |    |                /          \
    |HOST|     +-----+   |  Wireless  +-----\+-----+
    |    *     *     | +-+    3G/4G   |      |     |       *****
    +----+ WiFi|     +-+  \          /       |     |     **     **
               |     |       ------          |     |    *         *
    +----+     | CPE |                       | BGW +---*  Internet *
    |    |     |     |       ------          |     |    *         *
    |HOST+-----+     +-+  /          \       |     |     **     **
    |    |Wired|     | +-+            |      |     |       *****
    +----+     +-----+   |    Fixed   +-----/+-----+
                          \          /
                             ------

               Figure 8: Hybrid Access Architecture with BGW

   In order to achieve the architecture shown in Figure 8, the data
   plane should provide bundling functions.  There could be two options,
   one is the overlay solution via tunnels, where the hosts are agnostic
   about access networks aggregation.  The CPE and BGW rely on tunneling
   to set-up the path via different access networks, as shown in
   Figure 9.  CPE should be able to distribute the traffic to the proper
   tunnel based on the traffic distribution policy.  Additionally, if
   BGW function is located at the edge router of the access network
   (e.g., P-GW in EPC or BNG), as shown in Figure 10, the CPE can set up
   a tunnel in order to overlay one access network to another, and rely
   on regular routing on the other side.
























Leymann, et al.          Expires July 18, 2015                 [Page 10]


Internet-Draft                  HYA-arch                January 14, 2015


                        Tunnel
        |==============================================|
        | <............ LTE path   ..................> |
   <--->| <............ DSL path   ..................> |<--->
        |==============================================|        -----
     +--+---+       Internet Connection            +---+---+   /      \
     |      |                                      |       |  |Internet|
     | CPE  |                                      |  BGW  +--+        |
     +-+--+-+                                      +---+---+   \      /
       |  |             4G Network                     |        -----
       |  |      *......................... *          |
       |  |      < +------+       +------+  >          |
       |  +--------+      +-------+      +-------------+
       |         < |eNodeB|       | EPC  |  >          |
       |         < +------+       +------+  >          |
       |         *..........................*          |
       |         *......................... *          |
       |         ( +------+       +------+  )          |
       +-----------+      +-------+      +-------------+
                 ( |  AN  |       | SN   |  )
                 ( +------+       +------+  )
                 *..........................*
                         Fixed Network
   Legend:
   AN      Access Node
   SN      Service Node
   EPC     Evolved Packet Core

                             Figure 9: Overlay






















Leymann, et al.          Expires July 18, 2015                 [Page 11]


Internet-Draft                  HYA-arch                January 14, 2015


                       Tunnel for LTE Access
        |==============================================|
        | <............ LTE path   ..................> |
    --->|==============================================|<---
        | <------------------------------------------->|
        |               Fixed Routing                  |
        |              4G Network                      |
        |       *......................... *           |
   +----+-+     < +------+       +------+  >           |
   |      +-------+      +-------+      +------------+ |
   |      |     < |eNodeB|       | PGW  |  >         | |        -----
   |      |     < +------+       +------+  > ........|.|...*  /       \
   | CPE  |     *..........................* .  +----+-+--+)
   |      |     *.............................  |         |) |         |
   |      |     ( +------+       +------+       |  BGW/   |)
   |      +-------+      +-------+      +-------|         |--+ Internet|
   |      |     ( |  AN  |       | SN   |       |  BNG    |)
   +------+     ( +------+       +------+       |         |)  \       /
                *.............................  +---- ----+)    -----
                        Fixed Network        ..............*

                          Figure 10: Interworking

6.  Requirements

   On the client side, the CPE implements the bundling mechanism and
   forwards the customer traffic among the available access networks on
   a pre-selected granularity (i.e., per-flow or per-packet).  On the
   network side, a logical function BGW cooperates with the CPE.  This
   logical function can be co-located with the exiting service gateway,
   such as PGW and BNG.

   The HYA mechanism should meet the following requirements:

   1.  Bundling of Multiple Heterogeneous Access Networks: The CPE and
       BGW should support the tunnel technologies on data plane to
       support the proper traffic distribution scheme, per-flow or per-
       packet.

   2.  In-band Control Plane between the RG and BGW: A control plane
       between the RG and the BGW is needed for the negotiation about
       the traffic distribution policy.  For example, in the flow-based
       distribution scenario, the BGW should configure the WTP with the
       distribution policy for the identified flow.  The access
       connection metrics (capacity, state, etc.) can be obtained by the
       in-band control plane and used as input to enable dynamic traffic
       distribution policy adjustments.  In the packet-based
       distribution scenario, the measurement about the access metrics



Leymann, et al.          Expires July 18, 2015                 [Page 12]


Internet-Draft                  HYA-arch                January 14, 2015


       may be used as input to calculate the buffering which decides the
       subsequent actions.

   3.  Traffic Distribution Path Adjust Dynamically: In order to
       guarantee that the cheapest path is used first, the CPE must use
       the downstream and upstream fixed bandwidth first, periodically
       check the free bandwidth, and notify the results to the BGW.
       Based on the negotiation, BGW can adjust the threshold of the
       fixed path and adapt the traffic forwarding path decision
       dynamically.  Additionally, Load-balance is use both accesses all
       the time, balancing the traffic evenly or unevenly based on the
       proportion of two access bandwidth, or balancing based on the
       defined traffic policy.

   4.  Path Management: After successful authentication, the CPE needs
       to negotiate with the BGW how to setup and manage the tunnels
       dynamically through the available access network paths.
       Additionally, the available paths may have different
       characteristics in terms of bandwidth, delay, MTU, etc.  A path
       management function is therefore needed.

   5.  Backward Compatibility: In order to ensure that existing services
       are not influenced by the HYA architecture, certain traffic types
       must not be routed through the bundling heterogeneous access
       networks, but directly over a specific interface.  The
       negotiation between CPE and BGW for this policy routing must be
       defined.

   6.  Support both IPv4 and IPv6: IPv4 and IPv6 must be considered both
       for customer traffic and transport infrastructure.

7.  Gap Analysis

   There are various technologies (e.g., MPTCP[RFC6182] and
   MLPPP[RFC1990]) which enable simultaneous use of multiple data paths.

   In MPTCP, the primary use case is supporting the simultaneous use of
   multiple path between multihomed hosts or between hosts and server.
   It needs to be analyzed to determine how it is impacted by non
   transparent routing devices (i.e., middle boxes).  MPTCP only support
   TCP traffic.  MPTCP does not support packet-based forwarding among
   multiple paths.  Moreover, only fair-share forwarding is supported by
   MPTCP, therefore it does not support the traffic overflow function
   specified in Section 6.  For backward compatibility, MPTCP does not
   recognize the IP layer information and consequently has issues in
   supporting existing traffic unimpaired.





Leymann, et al.          Expires July 18, 2015                 [Page 13]


Internet-Draft                  HYA-arch                January 14, 2015


   In MLPPP, the link-layer protocol (PPP[RFC1990]) is extended to
   combine multiple PPP links.  Its primary use scenario is to enable
   fragmented protocol data units (PDU) on the link layer to be
   transferred over multiple links.  MLPPP can be used over L2TP for
   data plane.  In the control plane, there are still gaps.  L2TP
   control plane can not support the bundling action right now, for
   example, traffic distribution configuration, tunnel management etc.
   The control plane defined by IETF should satisfy the requirements
   listed in Section 6.

8.  Security Considerations

   In this architecture, CPE and BGW can redirect the traffic while end
   nodes (server and terminal) are not aware about the redirection. This
   may result in man-in-the-middle attacks.  So the system must have
   strong authentication mechanisms (i.e., a CPE must be able to
   authenticate the BGW, and vice versa).

9.  Acknowledgements

   The authors would like to thank Dennis Kusidlo and Pierrick Seite,
   who gave valuable comments for this draft.

10.  Normative References

   [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
              Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
              August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, March 2011.

Authors' Addresses

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781
   Germany

   Phone: +49-170-2275345
   Email: n.leymann@telekom.de





Leymann, et al.          Expires July 18, 2015                 [Page 14]


Internet-Draft                  HYA-arch                January 14, 2015


   Cornelius Heidemann
   Deutsche Telekom AG
   Heinrich-Hertz-Strasse 3-7
   Darmstadt  64295
   Germany

   Phone: +4961515812721
   Email: heidemannc@telekom.de


   Margaret Wesserman
   Painless Security

   Email: mrw@painless-security.com


   Li Xue
   Huawei
   No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan
   Beijing, Haidian District 100095
   China

   Email: xueli@huawei.com


   Mingui Zhang
   Huawei
   No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan
   Beijing, Haidian District 100095
   China

   Email: zhangmingui@huawei.com



















Leymann, et al.          Expires July 18, 2015                 [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/