Hybrid Access Network Architecture
draft-lhwxz-hybrid-access-network-architecture-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Nicolai Leymann , Cornelius Heidemann , Margaret Cullen , Dacheng Zhang | ||
| Last updated | 2014-06-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lhwxz-hybrid-access-network-architecture-00
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]