idnits 2.17.1 draft-bernardos-detnet-crosshaul-requirements-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 date (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DETNET WG CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Informational UC3M 5 Expires: May 4, 2017 L. Cominardi 6 InterDigital 7 LM. Contreras 8 TID 9 October 31, 2016 11 DETNET crosshauling requirements 12 draft-bernardos-detnet-crosshaul-requirements-00 14 Abstract 16 Future 5G networks will not make a clear distinction between 17 fronthaul and backhaul transport networks, because varying portions 18 of radio access network functionality might be moved toward the 19 network as required for cost reduction and performance increase. 20 This will pose additional challenges on the transport network, 21 driving for a new design of integrated fronthaul and backhaul, 22 usually referred to as crosshaul. 24 This document present the crosshaul architecture framework being 25 developed by the EU 5G-Crosshaul project, as well as identifies 26 several key requirements for the transport network, with the goal of 27 fostering discussion at the DETNET WG. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 4, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. 5G-Crosshaul architecture . . . . . . . . . . . . . . . . . . 4 66 3.1. Data plane architecture . . . . . . . . . . . . . . . . . 6 67 4. Crosshaul requirements . . . . . . . . . . . . . . . . . . . 6 68 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 According to recent predictions, mobile data traffic will increase 80 11-fold between 2013 and 2018. Fifth generation (5G) radio access 81 network (RAN) technologies serving this mobile data tsunami will 82 require fronthaul and backhaul solutions between the RAN and packet 83 core to deal with this increased traffic load. Furthermore, there 84 will be a sizeable growth in the capillarity of the network since 85 traffic load increase in the 5G RAN is expected to stem from an 86 increased number of base stations with reduced coverage (i.e., mobile 87 network densification). To support the increased density of the 88 mobile network (e.g., in terms of interference coordination) and 89 achieve the required 5G capacity, extensive support for novel air 90 interface technologies such as cooperative multipoint (CoMP), carrier 91 aggregation (CA), and massive multiple-input multiple-output (MIMO) 92 will be needed. Such technologies require processing of information 93 from multiple base stations simultaneously at a common centralized 94 entity and also tight synchronization of different radio sites. 95 Hence, backhaul and fronthaul will have to meet more stringent 96 requirements not only in terms of data rate but also in terms of 97 latency, jitter, and bit error rate. 99 In this upcoming 5G network environment, the distinction between 100 fronthaul and backhaul transport networks will blur as varying 101 portions of functionality of 5G points of attachment might be moved 102 toward the network as required for cost efficiency reasons. The 103 traditional capacity over provisioning approach on the transport 104 infrastructure will no longer be possible with 5G. Hence, a new 105 generation of integrated fronthaul and backhaul technologies will be 106 needed to bring capital expenditure (CAPEX) and operational 107 expenditure (OPEX) to a reasonable return on investment (ROI) range. 108 Current transport networks cannot cope with the amount of bandwidth 109 required for 5G. Next generation radio interfaces, using 100 MHz 110 channels and squeezing the bit-per-megahertz ratio through massive 111 MIMO or even fullduplex radios, requires a 10-fold increase in 112 capacity on the integrated fronthaul and backhaul (crosshaul) 113 segment, which cannot be achieved just through the evolution of 114 current technologies [crosshaul_magazine]. 116 Current trend is moving towards defining an integrated fronthaul and 117 backhaul into a common packet-based network, as supported by the 118 works working towards the definition of a Next Generation Fronthaul 119 Interface (NGFI, IEEE 1914), the packetization and encapsulation on 120 Ethernet frames of this newly interface (IEEE 1914.1) or the 121 extensions to bridging for Time Sensitive Networking (IEEE 802.1TSN) 122 and their profiling for frontal traffic (IEEE 802.1CM). The design 123 of the crosshaul poses new challenges that need to be tackled. 124 Different project and initiatives are looking at the design of the 125 crosshaul, among which we present here the one by the 5G-Crosshaul EU 126 project (summarized in Section 3). [I-D.ietf-detnet-use-cases] 127 introduces and describes several use cases for DETNET. While there 128 are some documents analyzing DETNET requirements for backhaul and 129 fronthaul, such as [I-D.huang-detnet-xhaul], in this document 130 (Section 4) we derive identify some requirements relevant for the 131 DETNET WG posed by the 5G-Crosshaul design. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 While [RFC2119] describes interpretations of these key words in terms 140 of protocol specifications and implementations, they are used in this 141 document to describe requirements for DETNET mechanisms regarding 142 support for integrated backhaul and crosshaul. 144 The following terms are used in this document: 146 Backhaul: the network or links between radio base station sites 147 (or digital units) and network controller/gateway sites. 149 Common Public Radio Interface (CPRI): industry cooperation aimed 150 at defining a publicly available specification for the key 151 internal interface of radio base stations between the Radio 152 Equipment Control (REC) and the Radio Equipment (RE), which are 153 the two basic building blocks into which a radio base station can 154 be decomposed in order to provide flexible radio base station 155 system architectures for mobile networks. 157 Fronthaul: the connection from a radio base station site (or 158 digital unit) to a remote radio unit. The fronthaul is therefore 159 the transport connection between the functional building blocks of 160 a cellular radio base station. The fronthaul has traditionally 161 been implemented with point-to-point connections based on the 162 Common Public Radio Interface (CPRI) standard. 164 In-Phase and Quadrature (IQ): User plane data between the REC and 165 RE is transported in the form of one or many In-Phase and 166 Quadrature (IQ) data flows. Each IQ data flow reflects the radio 167 signal, sampled and digitised of one carrier at one independent 168 antenna element, the so- called Antenna Carrier (AxC). 170 3. 5G-Crosshaul architecture 172 The 5G-Crosshaul project is developing an architecture for the next 173 generation of 5G integrated backhaul and fronthaul networks enabling 174 a flexible and software-defined reconfiguration of all networking 175 elements in a multi-tenant and service-oriented unified management 176 environment. The envisioned crosshaul transport network will consist 177 of high-capacity switches and heterogeneous transmission links (e.g., 178 fiber or wireless optics, high-capacity copper, or millimeter-wave) 179 interconnecting remote radio heads, 5G wireless points of attachment 180 (e.g., macro and small cells), pooled-processing units (mini data 181 centers), and points of presence (PoPs) of the core networks of one 182 or multiple service providers. 184 The 5G-Crosshaul architecture is based on a novel unified data plane 185 protocol able to transport both backhaul and fronthaul traffic, 186 regardless of the functional RAN split. Major challenges for such a 187 protocol are the big amount of data to handle, the synchronization of 188 user data, and reflection of the channel structure of RAN protocols. 190 A unified data plane is adopted, supporting future RAN evolutions (as 191 they may happen on shorter timescales than transport network 192 upgrades). This new data plane allows CPRI data to be transported in 193 a packetized form over the unified crosshaul data plane. 195 5G-Crosshaul is also developing a unified control and management 196 plane (network model and interface primitives) to simplify network 197 operations across heterogeneous technologies. Co-existance with 198 legacy infrastructure and support for smooth migration are considered 199 as key requirements for operators. 201 Three main novel building blocks are considered in 5G-Crosshaul 203 o A control infrastructure using a unified, abstract network model 204 for control plane integration (Crosshaul Control Infrastructure, 205 XCI). The XCI is based on existing software defined network (SDN) 206 controllers, to provide the services for novel northbound and 207 southbound interfaces (NBI and SBI), and enable multi-tenancy 208 support in trusted environments. A key aspect of the XCI is the 209 development of new mechanisms to abstract the mobile transport 210 network and aggregate measured contextual information. 212 o A unified data plane encompassing innovative high-capacity 213 transmission technologies and novel latency-deterministic switch 214 architectures (Crosshaul Forwarding Element, XFE). This element 215 is the central part of the Xhaul infrastructure, integrating the 216 different physical technologies used for fronthaul and backhaul 217 through a common data frame and forwarding behavior. Developing a 218 flexible frame format is a key aspect of fronthaul/backhaul 219 integration, allowing the transport of fronthaul/backhaul traffic 220 on the same physical link, replacing different technologies by a 221 uniform transport technology for both network segments. 223 o A set of computing capabilities distributed across the network 224 (Crosshaul Processing Units, XPUs). 226 5G-Crosshaul follows a unique approach towards the integration of the 227 different network segments (fronthaul and backhaul) into a common 228 transport stratum. In order to integrate the different nature of the 229 fronthaul and backhaul traffic (with their very disparate 230 requirements) and the different technologies that can be used to 231 transport them, a new common transport framing format is defined (the 232 XCF, Crosshaul Common Frame) which is used to perform the forwarding 233 within the Crosshaul. This XCF is based on MAC-in-MAC Ethernet, and 234 all traffic going into a Crosshaul area is adapted to this frame 235 format. In this way, 5G-Crosshaul can leverage all the work 236 performed in IEEE 802.1 (IEEE 802.1TSN and IEEE802.1CM) to transport 237 flows with stringent delay requirements in Ethernet-based networks. 239 3.1. Data plane architecture 241 Essentially, the XFE is modeled as a modular multi-layer switch, that 242 can support single or multiple link technologies (mmWave, microwave, 243 Ethernet, copper, fiber, etc.). The XFE is mainly made up of a 244 packet switch (5GCrosshaul Packet Forwarding Element, XPFE) and a 245 circuit switch (5G-Crosshaul Circuit Switching Element, XCSE). The 246 packet switching path is the primary path for the transport of most 247 delay-tolerant fronthaul and backhaul traffic, whereas the circuit 248 switching path is there to complement the packet switching path for 249 those particular traffic profiles that are not suited for packet- 250 based transporting (e.g., legacy CPRI or traffic with extremely low 251 delay tolerance) or just for capacity offloading. The packet switch 252 is controlled by a unified Common Frame (XCF). The circuit switch 253 can have an optical cross-connection component (based on wavelength 254 selective switches) and a TDM part, based on OTN, a new cost 255 effective approach for deterministic delay switching. Note that in 256 this draft we focus on the packet switch only. 258 MAC-in-MAC has been chosen as the frame format for transporting 259 backhaul and fronthaul traffic within 5G-Crosshaul. Provider 260 Backbone Bridges belongs to IEEE Std 802.1Q and is a set of 261 architecture and protocols for switching over a provider's network, 262 allowing interconnection of multiple Provider Bridge Networks without 263 losing each customer's individually defined VLANs. 265 4. Crosshaul requirements 267 In this section we enumerate the main requirements for the XCF packet 268 technology (i.e., transport data plane architecture). Aditional 269 details will be provided in subsequent revisions of this document. 271 We start listing below the main functional (qualitative) 272 requirements: 274 o Support multiple functional splits simultaneously, 276 * Including Backhaul and CPRI-like Fronthaul. 278 o Multi-tenancy. 280 * Isolate traffic (guaranteed QoS). 282 * Separate traffic (tenant privacy). 284 * Differentiation of forwarding behavior. 286 * Multiplexing gain. 288 * Tenant ID (identification of tenants' traffic). 290 o Coexistence, Compatibility. 292 * Ethernet (same switching equipment, for example different 293 ports, etc.). 295 * Security support. 297 * Synchronization: IEEE1588, IEEE802.1AS. 299 o Transport efficiency. 301 * Short overhead. 303 * Multi-path support. 305 * Flow differentiation. 307 * Class of Service Differentiation. 309 o Management. 311 * In band control traffic (OAM info, ...). 313 o Energy efficiency. 315 * Energy usage proportional to handled traffic (e.g., sleep mode, 316 reduced rate). 318 o Support of multiple data link technologies. 320 * IEEE 802.3, 802.11 (including mmWave), etc. 322 o No vendor lock-in. 324 In addition to the qualitative requirements, there are performance/ 325 quantitative requirements: 327 o Latency: the maximum end-to-end latency for IQ data between REC 328 and RE MUST be 100 us, including the propagation delay of the 329 links between the devices, internal delays of the devices such as 330 Bridges. For Control and Management (C&M) there is no latency 331 requirement. 333 o Frame loss ratio (FLR): can be caused by bit error, network 334 congestion, failures, etc. Late delivery can also imply frame 335 loss for CPRI data. It MUST be less than 10E-7. For C&M the FLR 336 MUST be less than 10E-6. 338 o Synchronization. Depending on the type of radio access technology 339 the requirements are different: 341 * The maximum absolute time error SHOULD be less than 10ns for 342 intra-band contiguous carrier aggregation radio access 343 technologies. 345 * The maximum absolute time error MUST be less than 45ns for 346 Multiple-Input and Multiple-Output (MIMO) and transmit 347 diversity radio access technologies. 349 * The maximum absolute time error MUST be less than 110ns for 350 intra-band non-contiguous and inter-band carrier aggregation 351 radio access technologies. 353 * The maximum absolute time error MUST be less than 110ns for 354 time division duplex radio access technologies. 356 5. Summary 358 This document presents a specific solution for the integration of 359 fronthaul and backhaul (being carried out within the framework of the 360 5G-Crosshaul project), to then derive some key requirements for the 361 discussion and consideration of the DETNET WG. 363 6. IANA Considerations 365 N/A. 367 7. Security Considerations 369 TBD. 371 8. Acknowledgments 373 The authors would like to thank Akbar Rahman for his review of the 374 document. 376 This work is partially supported by the EU H2020 5G-Crosshaul Project 377 (grant no. 671598). 379 9. References 381 9.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 9.2. Informative References 390 [crosshaul_magazine] 391 "Xhaul: Towards an Integrated Fronthaul/Backhaul 392 Architecture in 5G Networks, IEEE Wireless Communications 393 Magazine", October 2015. 395 [I-D.huang-detnet-xhaul] 396 Huang, J., "Integrated Mobile Fronthaul and Backhaul", 397 draft-huang-detnet-xhaul-00 (work in progress), March 398 2016. 400 [I-D.ietf-detnet-use-cases] 401 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 402 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 403 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 404 X., Mahmoodi, T., Spirou, S., and P. Vizarreta, 405 "Deterministic Networking Use Cases", draft-ietf-detnet- 406 use-cases-11 (work in progress), October 2016. 408 Authors' Addresses 410 Carlos J. Bernardos 411 Universidad Carlos III de Madrid 412 Av. Universidad, 30 413 Leganes, Madrid 28911 414 Spain 416 Phone: +34 91624 6236 417 Email: cjbc@it.uc3m.es 418 URI: http://www.it.uc3m.es/cjbc/ 419 Antonio de la Oliva 420 Universidad Carlos III de Madrid 421 Av. Universidad, 30 422 Leganes, Madrid 28911 423 Spain 425 Phone: +34 91624 8803 426 Email: aoliva@it.uc3m.es 427 URI: http://www.it.uc3m.es/aoliva/ 429 Luca Cominardi 430 InterDigital Europe 432 Email: Luca.Cominardi@InterDigital.com 433 URI: http://www.InterDigital.com/ 435 Luis M. Contreras 436 Telefonica I+D 437 Ronda de la Comunicacion, S/N 438 Madrid 28050 439 Spain 441 Email: luismiguel.contrerasmurillo@telefonica.com