One document matched: draft-huang-detnet-xhaul-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4090 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC5714 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-huang-detnet-xhaul-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">Integrated Mobile Fronthaul and
Backhaul</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="James Huang" initials="J." role="editor"
surname="Huang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Shenzhen</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>james.huang@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Ethernet can be a very promising technology for mobile Fronthaul
and Backhaul traffic transportation, even an integrated
Fronthaul / Backhaul (XHaul), although there are still some
challenges. This memo tries to analyze some of the challenges
and issues, such as L2 or L3 (MPLS/IP) forwarding, packet loss,
etc., and to find out some requirements.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Background">
<t>
5G network will be a heterogeneous network supporting "
multiple types of access technologies" <xref
target="NGMN-5G-WHITE-PAPER"/>
. A network with very low latency and jitter to support
these various access technologies can significantly increase
network flexibility; and network slicing should be
considered to separate technologies with different QoS
requirements, and separate difference operators, users or
use cases. Ethernet is a good candidate for this purpose.</t>
<t>Fronthaul network has very critical delay, jitter and
synchronization requirements, which is different from the
existing Backhaul network. But in the future, there will be
some new applications which require very low E2E latency,
such as 5ms or even 1ms, as defined in <xref
target="NGMN-5G-WHITE-PAPER"/>
and <xref target="METIS-D1.1"/>
. This will give some common requirements to both Fronthaul
and Backhaul network.</t>
<t>There have been quite some work in the industry, trying to
use Ethernet for Fronthaul, such as the IEEE 802.1CM and
IEEE 1904.3.</t>
<t>Now the existing Backhaul network is Ethernet based (IP RAN,
PTN, etc.), if the Fronthaul network can be Ethernet based
too, it is possible to build an integrated Fronthaul and
Backhaul</t>
<t><xref target="XHaul"/>
and <xref target="Crosshaul"/>
are trying to develop and integrated Fronthaul and Backhaul,
and packet network device ("Xhaul Packet Forwarding
Element") will be considered. At the <xref
target="IWPC-Evolving-Transport-Networks"/>
meeting, some operators and vendors express the idea of
"unified Fronthaul & Backhaul over Ethernet".</t>
</section>
<section 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>
</section>
<section title="Terminology">
<t>BBU: Baseband Unit</t>
<t>BER: Bit Error Rate</t>
<t>CPRI: Common Public Radio Interface</t>
<t>CRAN: Cloud / Centralized RAN</t>
<t>E2E: End to End</t>
<t>FEC: Forward Error Correction</t>
<t>FCS: Frame Check Sequence</t>
<t>FRR: Fast ReRoute</t>
<t>HARQ: Hybrid Automatic Repeat Request</t>
<t>IPWC: International Wireless Industry Consortium</t>
<t>RRU: Remote Radio Unit</t>
<t>TSN: Time Sensitive Network</t>
</section>
</section>
<section title="Ethernet or MPLS or IP">
<section title="Scope">
<t>The following analysis is on the Fronthaul / Backhaul use
case.</t>
<t>MPLS includes L2VPN, L3VPN, PWE3, etc.</t>
</section>
<section title="Pinned Path">
<t>If there are stringent QoS requirements, such as bandwidth
reservation to avoid congestion, limited number of hops and
distance to reduce delay, or even going through links with
low BER, the path should be fixed. Traditional L2 MAC
forwarding and L3 IP routing can not provided this
capability. SDN or flow-based solution may be able to meet
this requirement, either over L2 MAC forwarding or over L3
IP routing, in which forwarding decision will be made via
MAC forwarding table, IP routing table or flow table which
is installed by a controller, rather than being generated in
an autonomous way, such as using OSPF protocol. But this
type of solution is not yet widely used in the industrial.
MPLS is a better solution for this purpose. A management
system or PCE / RSVP / LDP can perform MPLS label planning
and distribution, this is a mature solution in the industry.</t>
</section>
<section title="QoS">
<t>In the Fronthaul / Backhaul use case, there will be Fronthaul
traffic and Backhaul traffic in a same network, and also
some other traffic types, such as WIFI, IoT traffic, etc.
These various types of traffic have different QoS
requirements. Priority based QoS mechanism is not
sufficient. Pre-emption is developed by IEEE TSN to resolve
the interference from the low priority traffic. Besides,
re-timing should also be considered to achieve very low
jitter.</t>
<t>E2E resource reservation is necessary to avoid congestion. In
a congestion case, the delay, jitter and packet loss will be
a problem. Usually MPLS is used for E2E resource
reservation.</t>
<t>If network slicing is considered to support various type of
traffic in a network, and support multiple operator or
tenants, traffic separation in the network is necessary.
VLAN can serve this purpose in some common cases where
bandwidth guarantee is not required. If the network will
cover an area of a city, or a broader area, MPLS should be
considered for E2E resource reservation and traffic
separation. Multiple routing instances (such as OSPF) can be
configured to serve this purpose, which usually work on
port or port + VLAN.</t>
</section>
<section title="Protection">
<t>Protection is a common feature in operator's network.</t>
<t>Ethernet supports linear protection <xref target="ITU-G.8031"/>
and ring protection
<xref target="ITU-G.8032"/>
, and a lot of other standard and proprietary solutions.</t>
<t>MPLS-TP can support multiple levels protection: LSP, PW and
sector, linear protection
<xref target="ITU-G.8131"/>
. E2E resource reservation is retained after the protection
switch.</t>
<t>Fast reroute is a MPLS (IP MPLS) <xref target="RFC4090"/>
and IP <xref target="RFC5714"/>
protection solution if there is link failure or router
failure, which can provide network recovery within 50ms. The
issue with IP fast reroute is, resource reservation can not
be done via signaling, but has to depend on static network
planning.</t>
</section>
<section title="Summary">
<t>Through the above analysis, MPLS (over Ethernet) is a good
candidate for the XHaul case, mainly due to the E2E resource
reservation and protection features. Support to MPLS should
be considered.</t>
<t>But MPLS does not means it will work for all the case, e.g.
in a pro-audio/video network, Ethernet may be a better
choice because the network is small and simple, there are
QoS requirements but not too stringent. It may be similar in
the industry control network.</t>
</section>
</section>
<section title="Encapsulation">
<section title="CPRI Aware or Unaware">
<t>
<xref target="CPRI"/>
is an open protocol, but it is not complete, some details
are missing, such as the sampling bit width. Some possible
values of sampling width are provided in the specification,
but not sure which one will be used for a specific wireless
technology, and if compression is considered to reduce
bandwidth requirement, a smaller sampling width value may be
used. If such a value is not specified, then it is difficult
to identify a CPRI frame.</t>
<t>A reasonable solution is to treat the CPRI traffic as a bit
stream. A fixed block of CPRI traffic, such as 1500byte
including the encapsulation, or the traffic over a fixed
period of time, is encapsulate into a packet.</t>
<t>One of the advantages of CPRI aware encapsulation, is to
perform compression, and some of the reserved bits in the
control bit are removed, the IQ data is compressed using
some compressing solution. But, maybe the RRU itself is a
better place to do this kind of processing, rather than in
the transport device.</t>
</section>
<section title="One Encapsulation over Multiple Technologies">
<t>IEEE 1904.3 defines encapsulation for CPRI over Ethernet.
Should that encapsulation format be used over MPLS or even
IP too, or should there be any necessary changes?</t>
</section>
</section>
<section title="Packet Loss Due to BER">
<t>The CPRI traffic carries the IQ data of baseband signal, in which
FEC function is usually used, e.g. the turbo coding function in
LTE. Some bit errors in the baseband signal or in the IQ data
can be corrected by the FEC module, and the left can be fixed
using HARQ retransmission mechanism. Due to this, when CPRI
traffic is carried by direct fiber link or by non-packet based
technology, such as OTN, even if there are bit errors, it is not
a big problem, the BBU can still process the IQ data.</t>
<t>But if CPRI traffic is carried over an Ethernet or other
packet-based link, when there is a bit error, usually the packet
is discarded. The packet size will decide how much CPRI traffic
be lost. Because CPRI requires a lot of bandwidth, the packet
size should be large enough for efficiency. For Ethernet the
payload size should be 1500byte or 9000byte (jumbo frame). If
such a continuous segment of CPRI data is lost, it will
significantly increases "equivalent" BER
<xref target="packet-loss-consideration"/>
. Issues caused by packet loss can not fixed by existing FEC
function in LTE. HARQ retransmission will have to be considered
as a final resort.</t>
<t>The packetization / framing will make the issue worse. The CPRI
traffic over a packet may expand across multiple CPRI basic
frame or even hyperframe, and further across multiple LTE code
block and transport block, which may lead to multiple LTE HAQR
retransmission. Further study on the impact to the wireless
network performance caused by packet lost is necessary.</t>
<t>Cut-through forwarding is to start forwarding actions such as
forwarding table lookup when the header of a packet is received,
before receiving the complete packet. Cut-through forwarding can
significantly reduce the delay in a network device. Receiving a
packet of 1500bytes on a 10GE interface will take about 1.2us,
if cut-through forwarding is used, more than 1us delay time can
be reduced. Cut-through forwarding is widely used in FCoE and
Infiniband, some Ethernet switches also provide this capability.</t>
<t>But cut-through forwarding has some issues, one of which is the
FCS error of a Ethernet packet. If there is a bit error, the FCS
validation will fail, and the packet should be discarded. But in
cut-through forwarding mode, before the switch can validate the
FCS, part of the packet is already on the wire and the packet
can not discarded. The packet with bit error will finally be
forwarded to a store-and-forward switch, or the final receiver.
Even the receiver, such as the BBU in the CRAN architecture,
finally receive the packet, it will has to discarded the packet,
because it does not know the bit error occurs in which part of
the packet, in the Ethernet or MPLS header, or the
encapsulation, or in the CPRI data.</t>
<t>Cut-through forwarding itself does not help in the bit error
case.</t>
</section>
<section title="Time Synchronization for Re-timing">
<t>
Due to the very critical jitter requirement, +/- 8.138ns for one
way jitter and +/- 16.276ns for round trip jitter, it is very
difficult to achieve this target simply via scheduling, neither
priority based nor pre-emption, or other algorithms. According
to
<xref target="applicability-of-qbu-and-qbv"/>, even if
pre-emption is used, a maximum delay of 114.4ns over a 10GE
interface still exist. To further reduce the jitter,
re-timing should be used. That is, put a time stamp T1 in
the packet at the ingress of the network; when the packet
arrive at the egress node at T2, buffer the packet until T3,
then send out the packet. T3 >= T2. (T3 - T1) is a fixed value,
and it should be long enough to cover all the possible jitter, fibre
propagation delay, processing delay, etc. On the other hand,
the delay (T3-T1) should be as low as possible.</t>
<t>Re-timing mechanism should be bi-directional.</t>
<figure align="center" anchor="re-timing">
<artwork align="left"><![CDATA[
+------+ +-----------------+ +-----+
| RRU1 |--| Ingress Switch1 |--| ... |---
+------+ +-----------------+ +-----+ \
\
\
+------+ +-----------------+ +-----+ +---------------+ +-----+
| RRU2 |--| Ingress Switch2 |--| ... |--| Egress Switch |--| BBU |
+------+ +-----------------+ +-----+ +---------------+ +-----+
add time stamp arrive at T2
T1 send out at T3
]]></artwork>
</figure>
<t>The re-timing mechanism depends on accuracy of time synchronization
at the ingress nodes and the egress nodes. In a common scenario, in
time synchronization a network device will trace to its uplink network device, such as
the ingress switch will trace to the egress switch as shown in the above figure. The
time alignment error (TAE) between the ingress switch and the egress switch may
impact the delay (T3-T1) if TAE is variable over the time. The variation of TAE over the
time must be small enough so as to minimize jitter; if the TAE is a fixed value over
the time, it is not a problem. The detail requirement needs further
study.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC4090; &RFC5714;
<!-- A reference written by by an organization not a person. -->
<reference anchor="packet-loss-consideration"
target="http://www.ieee802.org/1/files/public/docs2016/cm-varga-CPRI-packetloss-considerations-0116-v02.pdf">
<front>
<title>Packet/Frame loss considerations for CPRI over
Ethernet</title>
<author fullname="Balazs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization>
</author>
<author fullname="Janos Farkas" initials="J."
surname="Farkas">
<organization>Ericsson</organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="applicability-of-qbu-and-qbv"
target="http://www.ieee802.org/1/files/public/docs2015/cm-farkas-applicability-of-bu-and-bv-1115-v02.pdf">
<front>
<title>Applicability of Qbu and Qbv to Fronthaul</title>
<author fullname="Janos Farkas" initials="J."
surname="Farkas">
<organization>Ericsson</organization>
</author>
<author fullname="Balazs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="CPRI">
<front>
<title>CPRI Specification V7.0</title>
<author>
<organization>CPRI Alliance</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="XHaul" target="https://5g-ppp.eu/5g-xhaul/">
<front>
<title>5G-XHaul: Dynamically Reconfigurable Optical-Wireless
Backhaul/Fronthaul with Cognitive Control Plane for
Small Cells and Cloud-RANs</title>
<author>
<organization>5G-PPP</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="Crosshaul" target="https://5g-ppp.eu/xhaul/">
<front>
<title>5G-Crosshaul: The 5G Integrated fronthaul/backhaul
transport network</title>
<author>
<organization>5G-PPP</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="IWPC-Evolving-Transport-Networks"
target="http://www.iwpc.org/ResearchLibrary.aspx?ArchiveID=234&Display=doc">
<front>
<title>Evolving Transport Networks</title>
<author>
<organization>IWPC</organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="NGMN-5G-WHITE-PAPER"
target="https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf">
<front>
<title>NGMN-5G-WhITE-PAPER</title>
<author>
<organization>NGMN Alliance</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="METIS-D1.1">
<front>
<title>Deliverable D1.1 Scenarios, requirements and KPIs for
5G mobile and wireless system</title>
<author>
<organization>METIS</organization>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="ITU-G.8131"
target="https://www.itu.int/rec/T-REC-G.8131-201407-I/en">
<front>
<title>G.8131 : Linear protection switching for MPLS
transport profile</title>
<author>
<organization>ITU</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="ITU-G.8031"
target="https://www.itu.int/rec/T-REC-G.8031-201501-I/en">
<front>
<title>G.8031 : Ethernet linear protection switching</title>
<author>
<organization>ITU</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="ITU-G.8032"
target="https://www.itu.int/rec/T-REC-G.8032-201508-I/en">
<front>
<title>G.8032 : Ethernet ring protection switching</title>
<author>
<organization>ITU</organization>
</author>
<date year="2014"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:18:24 |