One document matched: draft-lhwxz-hybrid-access-network-architecture-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-lhwxz-hybrid-access-network-architecture-00"
ipr="trust200902">
<front>
<title abbrev="HYA-arch">Hybrid Access Network Architecture</title>
<author fullname="Nicolai Leymann" initials="N.L." surname="Leymann">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Winterfeldtstrasse 21-27</street>
<city>Berlin</city>
<code>10781</code>
<country>Germany</country>
</postal>
<phone>+49-170-2275345</phone>
<email>n.leymann@telekom.de</email>
</address>
</author>
<author fullname="Cornelius Heidemann" initials="C.H." surname="Heidemann">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Heinrich-Hertz-Strasse 3-7</street>
<city>Darmstadt</city>
<code>64295</code>
<country>Germany</country>
</postal>
<phone>+4961515812721</phone>
<email>heidemannc@telekom.de</email>
</address>
</author>
<author fullname="Margaret Wesserman" initials="M.W." surname="Wesserman">
<organization>Painless Security</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>mrw@painless-security.com</email>
<uri/>
</address>
</author>
<author fullname="Li Xue" initials="X.L." surname="Xue">
<organization>Huawei</organization>
<address>
<postal>
<street>NO.156 Beiqing Rd. Z-park,
Shi-Chuang-Ke-Ji-Shi-Fan-Yuan</street>
<city>Beijing, HaiDian District 100095</city>
<region/>
<code/>
<country>China</country>
</postal>
<email>xueli@huawei.com</email>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D.Z" surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street>NO.156 Beiqing Rd. Z-park,
Shi-Chuang-Ke-Ji-Shi-Fan-Yuan</street>
<city>Beijing.Haidian District 100095</city>
<region/>
<code/>
<country>China</country>
</postal>
<email>zhangdacheng@huawei.com</email>
</address>
</author>
<date day="25" month="June" year="2014"/>
<area>Routing Area</area>
<workgroup>Interdomain Routing Working Group</workgroup>
<keyword>Hybrid Access Network</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref></t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="Customer Premise Equipment (CPE):">A device that
connects multiple hosts to provide connectivity to the service
providers network.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Path:">A sequence of links between the CPE and HAAP,
typically DSL path and LTE path are defined in this document.</t>
</list></t>
</section>
<section title="Motivation Scenario">
<t>The figure<xref target="EHN"/> 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.</t>
<t><figure anchor="EHN" title="Existing Home Network Scenario">
<artwork><![CDATA[ ------
/ \
%======+ +===+
| LTE | \ *****
\ / ** **
------ * *
+-----+ * Internet *
+----+ | | ------ * *
| | | | / \ ** **
|HOST+-----+ CPE +---+ | / *****
| | | | | DSL +---/
+----+ | | \ /
+-----+ ------
]]></artwork>
</figure></t>
<t>As illustrated in <xref target="HYA"/>, 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 <xref target="HYA"/> ) for connecting
the LTE and DSL access networks respectively. The network architecture
proposed in <xref target="HYA"/> could be extended if there are other
access networks available for the combination.</t>
<t><figure anchor="HYA" title="Hybrid Access Scenario">
<artwork><![CDATA[ ------
/ \
+-----+ | +---\
| | +-+ LTE | \ *****
+----+ | E+-+ \ / ** **
| | | | ------ * *
|HOST+-----+ CPE | * Internet *
| | | | ------ * *
+----+ | D+-+ / \ ** **
| | +-+ | / *****
+-----+ | DSL +---/
\ /
------
]]></artwork>
</figure></t>
</section>
<section title="Flow-Based Forwarding versus Packet-Based Forwarding">
<t>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.</t>
<t>In a flow-based mechanism, customer traffics are broken into data
flows, each of which is associated to a single forwarding path <xref
target="flb"/>. 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.</t>
<figure anchor="flb" title="Flow-Based Forwarding">
<artwork><![CDATA[ ------
/ \
+-----+ | +---\
| +---+ LTE | \ *****
+----<=======A===========================>** **
| | | \ ------ / * *
|HOST+-----+ CPE | * Internet *
| | | | / ------ \ * *
+----<.......B...........................>** **
| +---+ | / *****
+-----+ | DSL +---/
\ /
------
]]></artwork>
</figure>
<t/>
<t>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.</t>
<t>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.</t>
<t>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 paths<xref target="plb"/>. 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.</t>
<t><figure anchor="plb" title="Packet-Based Forwarding">
<artwork><![CDATA[ ------
/ \
+-----+ | +---\+----+
| CPE +---+ LTE | |Agg.| *****
+----+ | ......................... | ** **
| | | . \ ------ / | . | * *
|HOST+-----+ . | . +--* Internet *
| <...........* / ------ \ | *.....>* *
+----+ | ......................... | ** **
| +---+ | | | *****
+-----+ | DSL +---/+----+
\ /
------
]]></artwork>
</figure></t>
<t>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 <xref target="plb"/>) 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.</t>
</section>
<section title="An Architecture for Packet-Based HYA">
<t>An architecture for packet-based HYA mechanisms with packet-based
distribution is illustrated in <xref target="NetworkArch"/>.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.</t>
<t><figure anchor="NetworkArch"
title="Hybrid Access Network Architecture">
<artwork><![CDATA[
|==============================================|
| <............ 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 ]]></artwork>
</figure></t>
<t>A full-fledged packet-based HYA mechanism using this architecture
should meet following several requirements:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Existing Technologies and Gap Analysis">
<t>There are various technologies (e.g., MPTCP<xref target="RFC6182"/> ,
MLPPP<xref target="RFC1990"/> ) which enable to similar requirements to
support the simultaneous use of multiple data paths.</t>
<t>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.</t>
<t>In MLPPP, the link-layer protocol (PPP<xref target="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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>tbd</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Dennis Kusidlo.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.1990'?>
<?rfc include='reference.RFC.6182'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:33:57 |