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]