idnits 2.17.1 draft-huang-detnet-xhaul-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Huang, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational March 21, 2016 5 Expires: September 22, 2016 7 Integrated Mobile Fronthaul and Backhaul 8 draft-huang-detnet-xhaul-00 10 Abstract 12 Ethernet can be a very promising technology for mobile Fronthaul and 13 Backhaul traffic transportation, even an integrated Fronthaul / 14 Backhaul (XHaul), although there are still some challenges. This 15 memo tries to analyze some of the challenges and issues, such as L2 16 or L3 (MPLS/IP) forwarding, packet loss, etc., and to find out some 17 requirements. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 22, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Ethernet or MPLS or IP . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Pinned Path . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4. Protection . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. CPRI Aware or Unaware . . . . . . . . . . . . . . . . . . 6 65 3.2. One Encapsulation over Multiple Technologies . . . . . . . 6 66 4. Packet Loss Due to BER . . . . . . . . . . . . . . . . . . . . 6 67 5. Time Synchronization for Re-timing . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 1.1. Background 79 5G network will be a heterogeneous network supporting " multiple 80 types of access technologies" [NGMN-5G-WHITE-PAPER] . A network with 81 very low latency and jitter to support these various access 82 technologies can significantly increase network flexibility; and 83 network slicing should be considered to separate technologies with 84 different QoS requirements, and separate difference operators, users 85 or use cases. Ethernet is a good candidate for this purpose. 87 Fronthaul network has very critical delay, jitter and synchronization 88 requirements, which is different from the existing Backhaul network. 89 But in the future, there will be some new applications which require 90 very low E2E latency, such as 5ms or even 1ms, as defined in 91 [NGMN-5G-WHITE-PAPER] and [METIS-D1.1] . This will give some common 92 requirements to both Fronthaul and Backhaul network. 94 There have been quite some work in the industry, trying to use 95 Ethernet for Fronthaul, such as the IEEE 802.1CM and IEEE 1904.3. 97 Now the existing Backhaul network is Ethernet based (IP RAN, PTN, 98 etc.), if the Fronthaul network can be Ethernet based too, it is 99 possible to build an integrated Fronthaul and Backhaul 101 [XHaul] and [Crosshaul] are trying to develop and integrated 102 Fronthaul and Backhaul, and packet network device ("Xhaul Packet 103 Forwarding Element") will be considered. At the 104 [IWPC-Evolving-Transport-Networks] meeting, some operators and 105 vendors express the idea of "unified Fronthaul & Backhaul over 106 Ethernet". 108 1.2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119] . 114 1.3. Terminology 116 BBU: Baseband Unit 118 BER: Bit Error Rate 120 CPRI: Common Public Radio Interface 122 CRAN: Cloud / Centralized RAN 123 E2E: End to End 125 FEC: Forward Error Correction 127 FCS: Frame Check Sequence 129 FRR: Fast ReRoute 131 HARQ: Hybrid Automatic Repeat Request 133 IPWC: International Wireless Industry Consortium 135 RRU: Remote Radio Unit 137 TSN: Time Sensitive Network 139 2. Ethernet or MPLS or IP 141 2.1. Scope 143 The following analysis is on the Fronthaul / Backhaul use case. 145 MPLS includes L2VPN, L3VPN, PWE3, etc. 147 2.2. Pinned Path 149 If there are stringent QoS requirements, such as bandwidth 150 reservation to avoid congestion, limited number of hops and distance 151 to reduce delay, or even going through links with low BER, the path 152 should be fixed. Traditional L2 MAC forwarding and L3 IP routing can 153 not provided this capability. SDN or flow-based solution may be able 154 to meet this requirement, either over L2 MAC forwarding or over L3 IP 155 routing, in which forwarding decision will be made via MAC forwarding 156 table, IP routing table or flow table which is installed by a 157 controller, rather than being generated in an autonomous way, such as 158 using OSPF protocol. But this type of solution is not yet widely 159 used in the industrial. MPLS is a better solution for this purpose. 160 A management system or PCE / RSVP / LDP can perform MPLS label 161 planning and distribution, this is a mature solution in the industry. 163 2.3. QoS 165 In the Fronthaul / Backhaul use case, there will be Fronthaul traffic 166 and Backhaul traffic in a same network, and also some other traffic 167 types, such as WIFI, IoT traffic, etc. These various types of 168 traffic have different QoS requirements. Priority based QoS 169 mechanism is not sufficient. Pre-emption is developed by IEEE TSN to 170 resolve the interference from the low priority traffic. Besides, re- 171 timing should also be considered to achieve very low jitter. 173 E2E resource reservation is necessary to avoid congestion. In a 174 congestion case, the delay, jitter and packet loss will be a problem. 175 Usually MPLS is used for E2E resource reservation. 177 If network slicing is considered to support various type of traffic 178 in a network, and support multiple operator or tenants, traffic 179 separation in the network is necessary. VLAN can serve this purpose 180 in some common cases where bandwidth guarantee is not required. If 181 the network will cover an area of a city, or a broader area, MPLS 182 should be considered for E2E resource reservation and traffic 183 separation. Multiple routing instances (such as OSPF) can be 184 configured to serve this purpose, which usually work on port or port 185 + VLAN. 187 2.4. Protection 189 Protection is a common feature in operator's network. 191 Ethernet supports linear protection [ITU-G.8031] and ring protection 192 [ITU-G.8032] , and a lot of other standard and proprietary solutions. 194 MPLS-TP can support multiple levels protection: LSP, PW and sector, 195 linear protection [ITU-G.8131] . E2E resource reservation is 196 retained after the protection switch. 198 Fast reroute is a MPLS (IP MPLS) [RFC4090] and IP [RFC5714] 199 protection solution if there is link failure or router failure, which 200 can provide network recovery within 50ms. The issue with IP fast 201 reroute is, resource reservation can not be done via signaling, but 202 has to depend on static network planning. 204 2.5. Summary 206 Through the above analysis, MPLS (over Ethernet) is a good candidate 207 for the XHaul case, mainly due to the E2E resource reservation and 208 protection features. Support to MPLS should be considered. 210 But MPLS does not means it will work for all the case, e.g. in a pro- 211 audio/video network, Ethernet may be a better choice because the 212 network is small and simple, there are QoS requirements but not too 213 stringent. It may be similar in the industry control network. 215 3. Encapsulation 217 3.1. CPRI Aware or Unaware 219 [CPRI] is an open protocol, but it is not complete, some details are 220 missing, such as the sampling bit width. Some possible values of 221 sampling width are provided in the specification, but not sure which 222 one will be used for a specific wireless technology, and if 223 compression is considered to reduce bandwidth requirement, a smaller 224 sampling width value may be used. If such a value is not specified, 225 then it is difficult to identify a CPRI frame. 227 A reasonable solution is to treat the CPRI traffic as a bit stream. 228 A fixed block of CPRI traffic, such as 1500byte including the 229 encapsulation, or the traffic over a fixed period of time, is 230 encapsulate into a packet. 232 One of the advantages of CPRI aware encapsulation, is to perform 233 compression, and some of the reserved bits in the control bit are 234 removed, the IQ data is compressed using some compressing solution. 235 But, maybe the RRU itself is a better place to do this kind of 236 processing, rather than in the transport device. 238 3.2. One Encapsulation over Multiple Technologies 240 IEEE 1904.3 defines encapsulation for CPRI over Ethernet. Should 241 that encapsulation format be used over MPLS or even IP too, or should 242 there be any necessary changes? 244 4. Packet Loss Due to BER 246 The CPRI traffic carries the IQ data of baseband signal, in which FEC 247 function is usually used, e.g. the turbo coding function in LTE. 248 Some bit errors in the baseband signal or in the IQ data can be 249 corrected by the FEC module, and the left can be fixed using HARQ 250 retransmission mechanism. Due to this, when CPRI traffic is carried 251 by direct fiber link or by non-packet based technology, such as OTN, 252 even if there are bit errors, it is not a big problem, the BBU can 253 still process the IQ data. 255 But if CPRI traffic is carried over an Ethernet or other packet-based 256 link, when there is a bit error, usually the packet is discarded. 257 The packet size will decide how much CPRI traffic be lost. Because 258 CPRI requires a lot of bandwidth, the packet size should be large 259 enough for efficiency. For Ethernet the payload size should be 260 1500byte or 9000byte (jumbo frame). If such a continuous segment of 261 CPRI data is lost, it will significantly increases "equivalent" BER 263 [packet-loss-consideration] . Issues caused by packet loss can not 264 fixed by existing FEC function in LTE. HARQ retransmission will have 265 to be considered as a final resort. 267 The packetization / framing will make the issue worse. The CPRI 268 traffic over a packet may expand across multiple CPRI basic frame or 269 even hyperframe, and further across multiple LTE code block and 270 transport block, which may lead to multiple LTE HAQR retransmission. 271 Further study on the impact to the wireless network performance 272 caused by packet lost is necessary. 274 Cut-through forwarding is to start forwarding actions such as 275 forwarding table lookup when the header of a packet is received, 276 before receiving the complete packet. Cut-through forwarding can 277 significantly reduce the delay in a network device. Receiving a 278 packet of 1500bytes on a 10GE interface will take about 1.2us, if 279 cut-through forwarding is used, more than 1us delay time can be 280 reduced. Cut-through forwarding is widely used in FCoE and 281 Infiniband, some Ethernet switches also provide this capability. 283 But cut-through forwarding has some issues, one of which is the FCS 284 error of a Ethernet packet. If there is a bit error, the FCS 285 validation will fail, and the packet should be discarded. But in 286 cut-through forwarding mode, before the switch can validate the FCS, 287 part of the packet is already on the wire and the packet can not 288 discarded. The packet with bit error will finally be forwarded to a 289 store-and-forward switch, or the final receiver. Even the receiver, 290 such as the BBU in the CRAN architecture, finally receive the packet, 291 it will has to discarded the packet, because it does not know the bit 292 error occurs in which part of the packet, in the Ethernet or MPLS 293 header, or the encapsulation, or in the CPRI data. 295 Cut-through forwarding itself does not help in the bit error case. 297 5. Time Synchronization for Re-timing 299 Due to the very critical jitter requirement, +/- 8.138ns for one way 300 jitter and +/- 16.276ns for round trip jitter, it is very difficult 301 to achieve this target simply via scheduling, neither priority based 302 nor pre-emption, or other algorithms. According to 303 [applicability-of-qbu-and-qbv], even if pre-emption is used, a 304 maximum delay of 114.4ns over a 10GE interface still exist. To 305 further reduce the jitter, re-timing should be used. That is, put a 306 time stamp T1 in the packet at the ingress of the network; when the 307 packet arrive at the egress node at T2, buffer the packet until T3, 308 then send out the packet. T3 >= T2. (T3 - T1) is a fixed value, and 309 it should be long enough to cover all the possible jitter, fibre 310 propagation delay, processing delay, etc. On the other hand, the 311 delay (T3-T1) should be as low as possible. 313 Re-timing mechanism should be bi-directional. 315 +------+ +-----------------+ +-----+ 316 | RRU1 |--| Ingress Switch1 |--| ... |--- 317 +------+ +-----------------+ +-----+ \ 318 \ 319 \ 320 +------+ +-----------------+ +-----+ +---------------+ +-----+ 321 | RRU2 |--| Ingress Switch2 |--| ... |--| Egress Switch |--| BBU | 322 +------+ +-----------------+ +-----+ +---------------+ +-----+ 323 add time stamp arrive at T2 324 T1 send out at T3 326 Figure 1 328 The re-timing mechanism depends on accuracy of time synchronization 329 at the ingress nodes and the egress nodes. In a common scenario, in 330 time synchronization a network device will trace to its uplink 331 network device, such as the ingress switch will trace to the egress 332 switch as shown in the above figure. The time alignment error (TAE) 333 between the ingress switch and the egress switch may impact the delay 334 (T3-T1) if TAE is variable over the time. The variation of TAE over 335 the time must be small enough so as to minimize jitter; if the TAE is 336 a fixed value over the time, it is not a problem. The detail 337 requirement needs further study. 339 6. IANA Considerations 341 This memo includes no request to IANA. 343 7. Security Considerations 345 TBD. 347 8. References 349 8.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 353 RFC2119, March 1997, 354 . 356 8.2. Informative References 358 [CPRI] CPRI Alliance, "CPRI Specification V7.0", 2015. 360 [Crosshaul] 361 5G-PPP, "5G-Crosshaul: The 5G Integrated fronthaul/ 362 backhaul transport network", 2015, 363 . 365 [ITU-G.8031] 366 ITU, "G.8031 : Ethernet linear protection switching", 367 2015, . 369 [ITU-G.8032] 370 ITU, "G.8032 : Ethernet ring protection switching", 2014, 371 . 373 [ITU-G.8131] 374 ITU, "G.8131 : Linear protection switching for MPLS 375 transport profile", 2014, 376 . 378 [IWPC-Evolving-Transport-Networks] 379 IWPC, "Evolving Transport Networks", 2016, . 383 [METIS-D1.1] 384 METIS, "Deliverable D1.1 Scenarios, requirements and KPIs 385 for 5G mobile and wireless system", 2013. 387 [NGMN-5G-WHITE-PAPER] 388 NGMN Alliance, "NGMN-5G-WhITE-PAPER", 2015, . 391 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 392 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 393 DOI 10.17487/RFC4090, May 2005, 394 . 396 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 397 RFC 5714, DOI 10.17487/RFC5714, January 2010, 398 . 400 [XHaul] 5G-PPP, "5G-XHaul: Dynamically Reconfigurable Optical- 401 Wireless Backhaul/Fronthaul with Cognitive Control Plane 402 for Small Cells and Cloud-RANs", 2015, 403 . 405 [applicability-of-qbu-and-qbv] 406 Farkas, J. and B. Varga, "Applicability of Qbu and Qbv to 407 Fronthaul", 2015, . 411 [packet-loss-consideration] 412 Varga, B. and J. Farkas, "Packet/Frame loss considerations 413 for CPRI over Ethernet", 2016, . 417 Author's Address 419 James Huang (editor) 420 Huawei 421 Shenzhen, 422 China 424 Phone: 425 Email: james.huang@huawei.com