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
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.
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]
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.
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.
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 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.
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.
------ / \ %======+ +===+ | 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
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 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 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.
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.
|==============================================| | <............ 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:
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.
tbd
Many thanks to Dennis Kusidlo.
[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. |