Internet DRAFT - draft-huang-detnet-xhaul
draft-huang-detnet-xhaul
Internet Engineering Task Force J. Huang, Ed.
Internet-Draft Huawei
Intended status: Informational March 21, 2016
Expires: September 22, 2016
Integrated Mobile Fronthaul and Backhaul
draft-huang-detnet-xhaul-00
Abstract
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.
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 September 22, 2016.
Copyright Notice
Copyright (c) 2016 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
Huang Expires September 22, 2016 [Page 1]
Internet-Draft Abbreviated Title March 2016
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Ethernet or MPLS or IP . . . . . . . . . . . . . . . . . . . . 4
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pinned Path . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Protection . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. CPRI Aware or Unaware . . . . . . . . . . . . . . . . . . 6
3.2. One Encapsulation over Multiple Technologies . . . . . . . 6
4. Packet Loss Due to BER . . . . . . . . . . . . . . . . . . . . 6
5. Time Synchronization for Re-timing . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Huang Expires September 22, 2016 [Page 2]
Internet-Draft Abbreviated Title March 2016
1. Introduction
1.1. Background
5G network will be a heterogeneous network supporting " multiple
types of access technologies" [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.
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
[NGMN-5G-WHITE-PAPER] and [METIS-D1.1] . This will give some common
requirements to both Fronthaul and Backhaul network.
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.
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
[XHaul] and [Crosshaul] are trying to develop and integrated
Fronthaul and Backhaul, and packet network device ("Xhaul Packet
Forwarding Element") will be considered. At the
[IWPC-Evolving-Transport-Networks] meeting, some operators and
vendors express the idea of "unified Fronthaul & Backhaul over
Ethernet".
1.2. 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] .
1.3. Terminology
BBU: Baseband Unit
BER: Bit Error Rate
CPRI: Common Public Radio Interface
CRAN: Cloud / Centralized RAN
Huang Expires September 22, 2016 [Page 3]
Internet-Draft Abbreviated Title March 2016
E2E: End to End
FEC: Forward Error Correction
FCS: Frame Check Sequence
FRR: Fast ReRoute
HARQ: Hybrid Automatic Repeat Request
IPWC: International Wireless Industry Consortium
RRU: Remote Radio Unit
TSN: Time Sensitive Network
2. Ethernet or MPLS or IP
2.1. Scope
The following analysis is on the Fronthaul / Backhaul use case.
MPLS includes L2VPN, L3VPN, PWE3, etc.
2.2. Pinned Path
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.
2.3. QoS
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
Huang Expires September 22, 2016 [Page 4]
Internet-Draft Abbreviated Title March 2016
resolve the interference from the low priority traffic. Besides, re-
timing should also be considered to achieve very low jitter.
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.
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.
2.4. Protection
Protection is a common feature in operator's network.
Ethernet supports linear protection [ITU-G.8031] and ring protection
[ITU-G.8032] , and a lot of other standard and proprietary solutions.
MPLS-TP can support multiple levels protection: LSP, PW and sector,
linear protection [ITU-G.8131] . E2E resource reservation is
retained after the protection switch.
Fast reroute is a MPLS (IP MPLS) [RFC4090] and IP [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.
2.5. Summary
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.
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.
Huang Expires September 22, 2016 [Page 5]
Internet-Draft Abbreviated Title March 2016
3. Encapsulation
3.1. CPRI Aware or Unaware
[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.
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.
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.
3.2. One Encapsulation over Multiple Technologies
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?
4. Packet Loss Due to BER
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.
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
Huang Expires September 22, 2016 [Page 6]
Internet-Draft Abbreviated Title March 2016
[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.
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.
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.
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.
Cut-through forwarding itself does not help in the bit error case.
5. Time Synchronization for Re-timing
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
[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
Huang Expires September 22, 2016 [Page 7]
Internet-Draft Abbreviated Title March 2016
propagation delay, processing delay, etc. On the other hand, the
delay (T3-T1) should be as low as possible.
Re-timing mechanism should be bi-directional.
+------+ +-----------------+ +-----+
| RRU1 |--| Ingress Switch1 |--| ... |---
+------+ +-----------------+ +-----+ \
\
\
+------+ +-----------------+ +-----+ +---------------+ +-----+
| RRU2 |--| Ingress Switch2 |--| ... |--| Egress Switch |--| BBU |
+------+ +-----------------+ +-----+ +---------------+ +-----+
add time stamp arrive at T2
T1 send out at T3
Figure 1
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.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Huang Expires September 22, 2016 [Page 8]
Internet-Draft Abbreviated Title March 2016
8.2. Informative References
[CPRI] CPRI Alliance, "CPRI Specification V7.0", 2015.
[Crosshaul]
5G-PPP, "5G-Crosshaul: The 5G Integrated fronthaul/
backhaul transport network", 2015,
<https://5g-ppp.eu/xhaul/>.
[ITU-G.8031]
ITU, "G.8031 : Ethernet linear protection switching",
2015, <https://www.itu.int/rec/T-REC-G.8031-201501-I/en>.
[ITU-G.8032]
ITU, "G.8032 : Ethernet ring protection switching", 2014,
<https://www.itu.int/rec/T-REC-G.8032-201508-I/en>.
[ITU-G.8131]
ITU, "G.8131 : Linear protection switching for MPLS
transport profile", 2014,
<https://www.itu.int/rec/T-REC-G.8131-201407-I/en>.
[IWPC-Evolving-Transport-Networks]
IWPC, "Evolving Transport Networks", 2016, <http://
www.iwpc.org/
ResearchLibrary.aspx?ArchiveID=234&Display=doc>.
[METIS-D1.1]
METIS, "Deliverable D1.1 Scenarios, requirements and KPIs
for 5G mobile and wireless system", 2013.
[NGMN-5G-WHITE-PAPER]
NGMN Alliance, "NGMN-5G-WhITE-PAPER", 2015, <https://
www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<http://www.rfc-editor.org/info/rfc5714>.
[XHaul] 5G-PPP, "5G-XHaul: Dynamically Reconfigurable Optical-
Wireless Backhaul/Fronthaul with Cognitive Control Plane
for Small Cells and Cloud-RANs", 2015,
<https://5g-ppp.eu/5g-xhaul/>.
Huang Expires September 22, 2016 [Page 9]
Internet-Draft Abbreviated Title March 2016
[applicability-of-qbu-and-qbv]
Farkas, J. and B. Varga, "Applicability of Qbu and Qbv to
Fronthaul", 2015, <http://www.ieee802.org/1/files/public/
docs2015/
cm-farkas-applicability-of-bu-and-bv-1115-v02.pdf>.
[packet-loss-consideration]
Varga, B. and J. Farkas, "Packet/Frame loss considerations
for CPRI over Ethernet", 2016, <http://www.ieee802.org/1/
files/public/docs2016/
cm-varga-CPRI-packetloss-considerations-0116-v02.pdf>.
Author's Address
James Huang (editor)
Huawei
Shenzhen,
China
Phone:
Email: james.huang@huawei.com
Huang Expires September 22, 2016 [Page 10]
