[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]