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]