[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01 02

Interdomain Routing Working Group                             N. Leymann
Internet-Draft                                              C. Heidemann
Intended status: Informational                       Deutsche Telekom AG
Expires: December 27, 2014                                  M. Wesserman
                                                       Painless Security
                                                                  X. Xue
                                                                D. Zhang
                                                                  Huawei
                                                           June 25, 2014


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

Abstract

   In practice, people have realized that it may be difficult to update
   or rebuild existing copper networks when they are deployed in certain
   areas.  At the same time, the requirements of customers on bandwidth
   are continually increased.  This document tries to discuss the
   general network architectures which could be used to address this
   problem by bundling multiple hybrid access networks together
   according to the 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 December 27, 2014.





Leymann, et al.         Expires December 27, 2014               [Page 1]


Internet-Draft                  HYA-arch                       June 2014


Copyright Notice

   Copyright (c) 2014 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.  Motivation Scenario . . . . . . . . . . . . . . . . . . . . .   3
   4.  Flow-Based Forwarding versus Packet-Based Forwarding  . . . .   4
   5.  An Architecture for  Packet-Based HYA . . . . . . . . . . . .   6
   6.  Existing Technologies and Gap Analysis  . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   It could be difficult for operators to upgrade or rebuild their
   copper access networks deployed in certain places (e.g., the old
   downtown areas).  However, at the same time, the requirements of
   customers on broader bandwidth become stronger.  To address this
   problem, the possibility of combining different or hybrid access
   networks (e.g., LTE and DSL) for a higher bandwidth is being
   discussed.

   To achieve this functionality, the mechanism for binding multiple
   hybrid access networks need to be designed, which is called as HYbrid
   access (HYA) mechanism in this document.  A HYA mechanism may need to
   have the capability in flexibly deciding the paths to forward data
   traffics.  This document attempts identify the potential issues and
   requirements related with the HYA mechanisms and proposes general
   architectural design suggestions.

   The remainder of this document is organized as follows.  Section 2
   lists the key terms used in this document.  Section 3 introduces a



Leymann, et al.         Expires December 27, 2014               [Page 2]


Internet-Draft                  HYA-arch                       June 2014


   motivation scenario and requirements in combining hybrid access
   networks.  Section 4 discusses the criteria of identifying the packet
   forwarding paths between the combined hybrid access networks.  In
   section 5, a general HYA architecture is proposed for constructing
   the packet-based forwarding solutions.  Section 6 discusses the
   possibility of using existing multi-path technologies in addressing
   the HYA issues and tries to identify the gaps.

2.  Terminology

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

   HYbrid Access (HYA):  HYbrid Access (HYA) is the bundling of two or
      more access lines over different technologies (e.g.  DSL and LTE)
      to one Internet connection for end customers.

   Hybrid Access Aggregation Point (HAAP):  The HAAP which acts as a
      service termination and a service creation implements bonding
      mechanism and sets up a high speed Internet dual stack IP
      connection with CPE on top of two or more hybrid access
      technologies.  The packet reorder, reassemble functions in packet-
      based solutions should be supported on HAAP.

   Path:  A sequence of links between the CPE and HAAP, typically DSL
      path and LTE path are defined in this document.

3.  Motivation Scenario

   The figureFigure 1 illustrates a motivation scenario, in which a
   customer accesses the Internet through a DSL access Network.  The
   requirements of the customer on broader bandwidth for better service
   experience become stronger.  However, the bandwidth of the DSL access
   network has been fully occupied (i.e., the traffics on the copper
   line has reached to a pre-specified threshold) and cannot satisfy any
   further bandwidth requirements from the customer.  In addition,
   because the customer is located in an old downtown street, it may
   take a long time or be extremely difficult for the operator to get
   the official construction permit to update the DSL access network or
   deploy a new one in that area.  Whereas, at the same time, the
   operator has already deployed a LTE backhaul network in the downtown
   area which is still not used to its fullest.  If the operator is able
   to take advantage of the bandwidth resources of the LTE and DSL
   network to transfer the traffics of the customer concurrently, it is
   possible to provide a higher bandwidth to the customer and guarantee
   good customer experiences.





Leymann, et al.         Expires December 27, 2014               [Page 3]


Internet-Draft                  HYA-arch                       June 2014


                             ------
                          /          \
                  %======+            +===+
                         |    LTE     |    \   *****
                          \          /       **     **
                             ------         *         *
               +-----+                     *  Internet *
    +----+     |     |       ------         *         *
    |    |     |     |    /          \       **     **
    |HOST+-----+ CPE +---+            |    /   *****
    |    |     |     |   |    DSL     +---/
    +----+     |     |    \          /
               +-----+       ------

                 Figure 1: Existing Home Network Scenario

   As illustrated in Figure 2, in order to bind the DSL and LTE access
   networks, the Customer Premise Equipment (CPE) of the customer's home
   network should have at least two Wide Area Network (WAN) interfaces
   (noted as E and D in Figure 2 ) for connecting the LTE and DSL access
   networks respectively.  The network architecture proposed in Figure 2
   could be extended if there are other access networks available for
   the combination.

                              ------
                           /          \
                +-----+   |            +---\
                |     | +-+    LTE     |    \   *****
     +----+     |    E+-+  \          /       **     **
     |    |     |     |       ------         *         *
     |HOST+-----+ CPE |                     *  Internet *
     |    |     |     |       ------         *         *
     +----+     |    D+-+  /          \       **     **
                |     | +-+            |    /   *****
                +-----+   |    DSL     +---/
                           \          /
                              ------

                     Figure 2: Hybrid Access Scenario

4.  Flow-Based Forwarding versus Packet-Based Forwarding

   According to the criteria of identifying the packet forwarding paths,
   HYA mechanisms can be classified into flow-based HYA mechanisms and
   packet-based HYA mechanisms.

   In a flow-based mechanism, customer traffics are broken into data
   flows, each of which is associated to a single forwarding path



Leymann, et al.         Expires December 27, 2014               [Page 4]


Internet-Draft                  HYA-arch                       June 2014


   Figure 3.  The packets of a certain flow can be identified by, for
   instance, its destination address, source address, or 5-tuple IP
   parameters, etc.  Upon on receiving a packet from the hosts, the CPE
   device will identify the flows that the packet belongs to and forward
   the packet according to the pre-specified policies, such as flow A is
   distributed into LTE path and flow B is distributed into DSL path.

                             ------
                          /          \
               +-----+   |            +---\
               |     +---+    LTE     |    \   *****
    +----<=======A===========================>**     **
    |          |     |    \  ------  /      *         *
    |HOST+-----+ CPE |                     *  Internet *
    |    |     |     |    /  ------ \       *         *
    +----<.......B...........................>**     **
               |     +---+            |    /   *****
               +-----+   |    DSL     +---/
                          \          /
                             ------

                      Figure 3: Flow-Based Forwarding

   Flow-based distribution is very similar to load balance technologies
   and easy for operator to deploy.  On the other side, the
   disadvantages of flow-based solutions are obvious.  The bandwidth
   consumption of each flow could change over time and it could be
   difficult to predict.  Thus, the traffic balance between the
   different paths is difficult to guarantee.  In addition, in certain
   scenarios, it may be difficult to guarantee the upstream and
   downstream packets within the same flow are transferred in the same
   data path.

   For instance, according to pre-specified policies, a CPE needs to
   select a flow and forward the packets within the flow through the LTE
   network when the overload of the DSL network reaches a per-specified
   threshold.  However, the bandwidth consumption of the flow associated
   with the LTE network becomes big later and causes the congestion of
   LTE work.  A more detailed gap analysis for flow-based solutions will
   be provided in the next version of this document.

   In a packet-based solution, instead, the forwarding policies are
   specified at the packet level.  A CPE can flexibly decide which
   packets should be forwarded through the LTE access network when the
   DSL network is heavily loaded.  Each packet is associated to a single
   forwarding path while different packets belonging to the same flow
   could be transferred by different pathsFigure 4.  Therefore, compared
   to flow-based solutions, the CPE in a packet-based solution can tune



Leymann, et al.         Expires December 27, 2014               [Page 5]


Internet-Draft                  HYA-arch                       June 2014


   the bandwidth consumption on different paths in a flexible and fine-
   grained way.

                             ------
                          /          \
               +-----+   |            +---\+----+
               | CPE +---+    LTE     |    |Agg.|      *****
    +----+     |     .........................  |    **     **
    |    |     |     .    \  ------  /     | .  |   *         *
    |HOST+-----+     .                     | .  +--*  Internet *
    |    <...........*    /  ------ \      | *.....>*         *
    +----+     |     .........................  |    **     **
               |     +---+            |    |    |      *****
               +-----+   |    DSL     +---/+----+
                          \          /
                             ------

                     Figure 4: Packet-Based Forwarding

   In packet-based solutions, due to different transporting delivery
   caused by LTE and DSL paths, the packets in the same flow may reach
   their destination in different orders.  It could desired to provide a
   device (see the Agg in Figure 4) to perform traffic reordering and
   reassembling at the remote side.  In a flow-based solution, the out-
   of-order packet issues will not occur in the upstream traffics, while
   it may occur in the downstream packets.

5.  An Architecture for Packet-Based HYA

   An architecture for packet-based HYA mechanisms with packet-based
   distribution is illustrated in Figure 5.In the diagram, an endpoint
   (Hybrid Access Aggregation Point (HAAP)) is deployed at the remote
   side of the CPE and carries out the packet reordering and
   reassembling functions.  Only if the utilization of DSL bandwidth has
   reached to a pre-specified threshold, CPE and HAAP would distribute
   customer traffic on packet-based between DSL and LTE path.















Leymann, et al.         Expires December 27, 2014               [Page 6]


Internet-Draft                  HYA-arch                       June 2014


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

               Figure 5: Hybrid Access Network Architecture

   A full-fledged packet-based HYA mechanism using this architecture
   should meet following several requirements:

   1.  Network Agnostic: On the client side, the CPE must implement the
       bond mechanism and distribute the customer traffic between these
       two interfaces based on per-packet.  On the network side, an
       endpoint HAAP cooperates with the CPE to achieve packet reorder,
       packet reassemble functions etc.  The HYA connection is only
       terminated and managed at the CPE and the HAAP.  Therefore either
       the DSL and LTE network infrastructure are not changed and
       impacted.

   2.  Path Management: As a result of successful authentication, the
       CPE needs to negotiate with HAAP so as to setup and manage the
       HYA connection dynamically through the DSL and LTE physical
       paths.  Additionally, the bundle two paths may have different
       characteristics such as rate, delay or MTU etc.  A mechanism of
       path management should also fix this gap.




Leymann, et al.         Expires December 27, 2014               [Page 7]


Internet-Draft                  HYA-arch                       June 2014


   3.  Traffic Overflow Function: In order to guarantee the cheapest
       path used first, the CPE need to get the downstream and upstream
       DSL bandwidth from the network, and periodically check the bypass
       bandwidth and notify the result to the HAAP.  Based on the
       negotiation, HAAP can adjust the threshold of the DSL path and
       adapt the packet-based routing decision dynamically.

   4.  Backward Compatibility: In order to ensure that existing services
       are not influenced by HYA architecture, certain traffic must not
       be routed through HYA connection,but directly over the specific
       interface.  The negotiation between HG and HAAP for this policy
       routing must be defined.

6.  Existing Technologies and Gap Analysis

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

   In MPTCP, the primary use case is to support application layer for
   the simultaneous use of multiple path between the multihomed hosts.
   It needs to analysis and consider the issues with various middleboxes
   impaction.  For example, MPTCP falls back to ordinary TCP if a
   middlebox alters the payload.  For HYA architecture in network layer,
   these mechanisms are overload.  By far, the MPTCP does not support
   packet-based distribution requirement between the multiple path
   specified in Section 5.  Therefore, only fair-share is supported by
   MPTCP, MPTCP does not meet the traffic overflow function specified in
   Section 5.  For backward compatibility, MPTCP can not recognize the
   IP layer information and consequently have issues to support existing
   traffic unimpaired requirement.

   In MLPPP, the link-layer protocol (PPP[RFC1990]) is extended to
   combine multiple PPP link.  The primary scenario is for fragmented
   protocol data units (PDU) on link layer to be transferred on multiple
   link and be reassembled back into the original PDU.  By far, the
   MLPPP does not apply to the HYA deployment scenario, which is IP
   network between CPE and HAAP.  Moreover, MLPPP does not meet the
   requirements as packet-based distribution between the multiple path
   and traffic overflow function specified in Section 5.  For backward
   compatibility,MLPPP can not recognize the IP layer information and
   consequently have issues to support existing traffic unimpaired
   requirement as MPTCP.








Leymann, et al.         Expires December 27, 2014               [Page 8]


Internet-Draft                  HYA-arch                       June 2014


7.  Security Considerations

   tbd

8.  Acknowledgements

   Many thanks to Dennis Kusidlo.

9.  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


   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




Leymann, et al.         Expires December 27, 2014               [Page 9]


Internet-Draft                  HYA-arch                       June 2014


   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


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

   Email: zhangdacheng@huawei.com



































Leymann, et al.         Expires December 27, 2014              [Page 10]


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