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]