idnits 2.17.1 draft-korhonen-detnet-telreq-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 (May 27, 2015) is 3256 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-finn-detnet-architecture-01 == Outdated reference: A later version (-05) exists of draft-finn-detnet-problem-statement-01 == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-1588overmpls-06 == Outdated reference: A later version (-07) exists of draft-mirsky-mpls-residence-time-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen 3 Internet-Draft Broadcom Corporation 4 Intended status: Informational May 27, 2015 5 Expires: November 28, 2015 7 Deterministic networking for radio access networks 8 draft-korhonen-detnet-telreq-00 10 Abstract 12 This document describes requirements for deterministic networking in 13 cellular radio access and transport networks context. The 14 requirements include time synchronization, clock distribution and 15 ways of establishing time-sensitive streams for both Layer-2 and 16 Layer-3 user plane traffic using IETF protocol solutions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 28, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and background . . . . . . . . . . . . . . . . . 2 53 2. Network architecture . . . . . . . . . . . . . . . . . . . . 3 54 3. Time synchronization requirements . . . . . . . . . . . . . . 5 55 4. Time-sensitive stream requirements . . . . . . . . . . . . . 6 56 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 59 8. Informative References . . . . . . . . . . . . . . . . . . . 8 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 62 1. Introduction and background 64 The recent developments in telecommunication networks, especially in 65 the cellular domain, are heading towards transport networks where 66 precise time synchronization support has to be one of the basic 67 building blocks. While the transport networks themselves have 68 practically transitioned to all-AP packet based networks to meet the 69 bandwidth and cost requirements, a highly accurate clock distribution 70 has become a challenge. Earlier the transport networks in the 71 cellular domain were typically time division and multiplexing (TDM) 72 -based and provided frequency synchronization capabilities as a part 73 of the transport media. Alternatively other technologies such as 74 Global Positioning System (GPS) or Synchronous Ethernet (SyncE) 75 [SyncE] were used. New radio access network deployment models and 76 architectures may require time sensitive networking services with 77 strict requirements on other parts of the network that previously 78 were not considered to be packetized at all. The time and 79 synchronization support are already topical for backhaul and midhaul 80 packet networks [MEF], and becoming a real issue for fronthaul 81 networks. Specifically in the fronthaul networks the timing and 82 synchronization requirements can be extreme for packet based 83 technologies, for example, in order of sub +-20 ns packet delay 84 variation (PDV) and frequency accuracy of +0.002 PPM [Fronthaul]. 86 Both Ethernet and IP/MPLS [RFC3031] (and PseudoWires (PWE) [RFC3985] 87 for legacy transport support) have become popular tools to build and 88 manage new all-IP radio access networks (RAN) 89 [I-D.kh-spring-ip-ran-use-case]. Although various timing and 90 synchronization optimizations have already been proposed and 91 implemented including 1588 PTP enhancements 92 [I-D.ietf-tictoc-1588overmpls][I-D.mirsky-mpls-residence-time], these 93 solution are not necessarily sufficient for the forthcoming RAN 94 architectures or guarantee the higher time-synchronization 95 requirements [CPRI]. There are also existing solutions for the TDM 96 over IP [RFC5087] [RFC4553] or Ethernet transports [RFC5086]. The 97 really interesting and important existing work for time sensitive 98 networking has been done for Ethernet [TSNTG], which specifies the 99 use of IEEE 1588 time precision protocol (PTP) [IEEE1588] in the 100 context of IEEE 802.1D and IEEE 802.1Q. While IEEE 802.1AS 101 [IEEE8021AS] specifies a Layer-2 time synchronizing service other 102 specification, such as IEEE 1722 [IEEE1722] specify Ethernet-based 103 Layer-2 transport for time-sensitive streams. New promising work 104 seeks to enable the transport of time-sensitive fronthaul streams in 105 Ethernet bridged networks [IEEE8021CM]. Similarly to IEEE 1722 there 106 is an ongoing standardization effort to define Layer-2 transport 107 encapsulation format for transporting radio over Ethernet (RoE) in 108 IEEE 1904.3 Task Force [IEEE19043]. 110 As already mentioned all-IP RANs and various "haul" networks would 111 benefit from time synchronization and time-sensitive transport 112 services. Although Ethernet appears to be the unifying technology 113 for the transport there is still a disconnect providing Layer-3 114 services. The protocol stack typically has a number of layers below 115 the Ethernet Layer-2 that shows up to the Layer-3 IP transport. It 116 is not uncommon that on top of the lowest layer (optical) transport 117 there is the first layer of Ethernet followed one or more layers of 118 MPLS, PseudoWires and/or other tunneling protocols finally carrying 119 the Ethernet layer visible to the user plane IP traffic. While there 120 are existing technologies, especially in MPLS/PWE space, to establish 121 circuits through the routed and switched networks, there is a lack of 122 signaling the time synchronization and time-sensitive stream 123 requirements/reservations for Layer-3 flows in a way that the entire 124 transport stack is addressed and the Ethernet layers that needs to be 125 configured are addressed. Furthermore, not all "user plane" traffic 126 will be IP. Therefore, the same solution need also address the use 127 cases where the user plane traffic is again another layer or Ethernet 128 frames. There is existing work describing the problem statement 129 [I-D.finn-detnet-problem-statement] and the architecture 130 [I-D.finn-detnet-architecture] for deterministic networking (DetNet) 131 that eventually targets to provide solutions for time-sensitive (IP/ 132 transport) streams with deterministic properties over Ethernet-based 133 switched networks. 135 This document describes requirements for deterministic networking in 136 a cellular telecom transport networks context. The requirements 137 include time synchronization, clock distribution and ways of 138 establishing time-sensitive streams for both Layer-2 and Layer-3 user 139 plane traffic using IETF protocol solutions. 141 2. Network architecture 143 Figure Figure 1 illustrates a typical, 3GPP defined, cellular network 144 architecture, which also has fronthaul and midhaul network segments. 145 The fronthaul refers to the network connecting base stations (base 146 band processing units) to the remote radio heads (antennas). The 147 midhaul network typically refers to the network inter-connecting base 148 stations (or small/pico cells). 150 Fronthaul networks build on the available excess time after the base 151 band processing of the radio frame has completed. Therefore, the 152 available time for networking is actually very limited, which in 153 practise determines how far the remote radio heads can be from the 154 base band processing units (i.e. base stations). For example, in a 155 case of LTE radio the Hybrid ARQ processing of a radio frame is 156 allocated 3 ms. Typically the processing completes way earlier (say 157 up to 400 us, could be much less, though) thus allowing the remaining 158 time to be used e.g. for fronthaul network. 200 us equals roughly 40 159 km of optical fiber based transport (assuming round trip time would 160 be total 2*200 us). The base band processing time and the available 161 "delay budget" for the fronthaul is a subject to change, possibly 162 dramatically, in the forthcoming "5G" to meet, for example, the 163 envisioned reduced radio round trip times, and other architecural and 164 service requirements [NGMN]. 166 The maximum "delay budget" is then consumed by all nodes and required 167 buffering between the remote radio head and the base band processing 168 in addition to the distance incurred delay. Packet delay variation 169 (PDV) is problematic to fronthaul networks and must be minimized. If 170 the transport network cannot guarantee low enough PDV additional 171 buffering has to be introduced at the edges of the network to buffer 172 out the jitter. Any buffering will eat up the total available delay 173 budget, though. Section Section 3 will discuss the PDV requirements 174 in more detail. 176 Y (remote radios) 177 \ 178 Y__ \.--. .--. +------+ 179 \_( `. +---+ _(Back`. | 3GPP | 180 Y------( Front )----|eNB|----( Haul )----| core | 181 ( ` .Haul ) +---+ ( ` . ) ) | netw | 182 /`--(___.-' \ `--(___.-' +------+ 183 Y_/ / \.--. \ 184 Y_/ _( Mid`. \ 185 ( Haul ) \ 186 ( ` . ) ) \ 187 `--(___.-'\_____+---+ (small cells) 188 \ |SCe|__Y 189 +---+ +---+ 190 Y__|eNB|__Y 191 +---+ 192 Y_/ \_Y ("local" radios) 194 Figure 1: Generic 3GPP-based cellular network architecture with 195 Front/Mid/Backhaul networks 197 3. Time synchronization requirements 199 Cellular networks starting from long term evolution (LTE) [TS36300] 200 [TS23401] radio the phase synchronization is also needed in addition 201 to the frequency synchronization. The commonly referenced fronthaul 202 network synchronization requirements are typically drawn from the 203 common public radio interface (CPRI) [CPRI] specification that 204 defines the transport protocol between the base band processing - 205 radio equipment controller (REC) and the remote antenna - radio 206 equipment (RE). However, the fundamental requirements still 207 originate from the respective cellular system and radio 208 specifications such as the 3GPP ones [TS25104][TS36104][TS36211] 209 [TS36133]. 211 The fronthaul time synchronization requirements for the current 3GPP 212 LTE-based networks are listed below: 214 Transport link contribution to radio frequency error: 216 +-2 PPB. The given value is considered to be "available" for the 217 fronthaul link out of the total 50 PPB budget reserved for the 218 radio interface. 220 Delay accuracy: 222 +-8.138 ns i.e. +-1/32 Tc (UMTS Chip time, Tc, 1/3.84 MHz) to 223 downlink direction and excluding the (optical) cable length in one 224 direction. Round trip accuracy is then +-16.276 ns. The value is 225 this low to meet the 3GPP timing alignment error (TAE) measurement 226 requirements. 228 Packet delay variation (PDV): 230 * For multiple input multiple output (MIMO) or TX diversity 231 transmissions, at each carrier frequency, TAE shall not exceed 232 65 ns (i.e. 1/4 Tc). 234 * For intra-band contiguous carrier aggregation, with or without 235 MIMO or TX diversity, TAE shall not exceed 130 ns (i.e. 1/2 236 Tc). 238 * For intra-band non-contiguous carrier aggregation, with or 239 without MIMO or TX diversity, TAE shall not exceed 260 ns (i.e. 240 one Tc). 242 * For inter-band carrier aggregation, with or without MIMO or TX 243 diversity, TAE shall not exceed 260 ns. 245 The above listed time synchronization requirements are hard to meet 246 even with point to point connected networks, not to mention cases 247 where the underlying transport network actually constitutes of 248 multiple hops. It is expected that network deployments have to deal 249 with the jitter requirements buffering at the very ends of the 250 connections, since trying to meet the jitter requirements in every 251 intermediate node is likely to be too costly. However, every measure 252 to reduce jitter and delay on the path are valuable to make it easier 253 to meet the end to end requirements. 255 In order to meet the timing requirements both senders and receivers 256 must is perfect sync. This asks for a very accurate clock 257 distribution solution. Basically all means and hardware support for 258 guaranteeing accurate time synchronization in the network is needed. 259 As an example support for 1588 transparent clocks (TC) in every 260 intermediate node would be helpful. 262 4. Time-sensitive stream requirements 264 In addition to the time synchronization requirements listed in 265 Section Section 3 the fronthaul networks assume practically error 266 free transport. The maximum bit error rate (BER) has been defined to 267 be 10^-12. When packetized that would equal roughly to packet error 268 rate (PER) of 2.4*10^-9 (assuming ~300 bytes packets). 269 Retransmitting lost packets and/or using forward error coding (FEC) 270 to circumvent bit errors are practically impossible due additional 271 incurred delay. Using redundant streams for better guarantees for 272 delivery is also practically impossible due to high bandwidth 273 requirements fronthaul networks have. For instance, current 274 uncompressed CPRI bandwidth expansion ratio is roughly 20:1 compared 275 to the IP layer user payload it carries in a "radio sample form". 277 The other fundamental assumption is that fronthaul links are 278 symmetric. Last, all fronthaul streams (carrying radio data) have 279 equal priority and cannot delay or pre-empt each other. This implies 280 the network has always be sufficiently under subscribed to guarantee 281 each time-sensitive flow meets their schedule. 283 Mapping the fronthaul requirements to [I-D.finn-detnet-architecture] 284 Section 3 "Providing the DetNet Quality of Service" what is seemed 285 usable are: 287 (a) Zero congestion loss. 289 (b) Pinned-down paths. 291 The current time-sensitive networking features may still not be 292 sufficient for fronthaul traffic. Therefore, having specific 293 profiles that take the requirements of fronthaul into account are 294 deemed to be useful [IEEE8021CM]. 296 The actual transport protocols and/or solutions to establish required 297 transport "circuits" (pinned-down paths) for fronthaul traffic are 298 still undefined. Those are likely to include but not limited to 299 solutions directly over Ethernet, over IP, and MPLS/PseudoWire 300 transport. 302 5. Security considerations 304 Establishing time-sensitive streams in the network entails reserving 305 networking resources sometimes for a considerable long time. It is 306 important that these reservation requests must be authenticated to 307 prevent malicious reservation attempts from hostile nodes or even 308 accidental misconfiguration. This is specifically important in a 309 case where the reservation requests span administrative domains. 310 Furthermore, the reservation information itself should be digitally 311 signed to reduce the risk where a legitimate node pushed a stale or 312 hostile configuration into the networking node. 314 6. IANA Considerations 316 This document has no IANA considerations. 318 7. Acknowledgements 320 The author(s) ACK and NACK. 322 8. Informative References 324 [CPRI] CPRI Cooperation, "Common Public Radio Interface (CPRI); 325 Interface Specification", CPRI Specification V6.1, July 326 2014, . 329 [Fronthaul] 330 Chen, D. and T. Mustala, "Ethernet Fronthaul 331 Considerations", IEEE 1904.3, February 2015, 332 . 335 [I-D.finn-detnet-architecture] 336 Finn, N., Thubert, P., and M. Teener, "Deterministic 337 Networking Architecture", draft-finn-detnet- 338 architecture-01 (work in progress), March 2015. 340 [I-D.finn-detnet-problem-statement] 341 Finn, N. and P. Thubert, "Deterministic Networking Problem 342 Statement", draft-finn-detnet-problem-statement-01 (work 343 in progress), October 2014. 345 [I-D.ietf-tictoc-1588overmpls] 346 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 347 Montini, "Transporting Timing messages over MPLS 348 Networks", draft-ietf-tictoc-1588overmpls-06 (work in 349 progress), April 2014. 351 [I-D.kh-spring-ip-ran-use-case] 352 Khasnabish, B., hu, f., and L. Contreras, "Segment Routing 353 in IP RAN use case", draft-kh-spring-ip-ran-use-case-02 354 (work in progress), November 2014. 356 [I-D.mirsky-mpls-residence-time] 357 Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 358 and S. Vainshtein, "Residence Time Measurement in MPLS 359 network", draft-mirsky-mpls-residence-time-06 (work in 360 progress), May 2015. 362 [IEEE1588] 363 IEEE, "IEEE Standard for a Precision Clock Synchronization 364 Protocol for Networked Measurement and Control Systems", 365 IEEE Std 1588-2008, 2008, 366 . 369 [IEEE1722] 370 IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport 371 Protocol for Time Sensitive Applications in a Bridged 372 Local Area Network", IEEE Std 1722-2011, 2011, 373 . 376 [IEEE19043] 377 IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3, 378 2015, . 380 [IEEE8021AS] 381 IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 382 IEEE 802.1AS-2001, 2011, 383 . 386 [IEEE8021CM] 387 Farkas, J., "Time-Sensitive Networking for Fronthaul", 388 Unapproved PAR, PAR for a New IEEE Standard; IEEE 389 P802.1CM, April 2015, 390 . 393 [MEF] MEF, "Mobile Backhaul Phase 2 Amendment 1 -- Small Cells", 394 MEF 22.1.1, July 2014, 395 . 398 [NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0, 399 February 2015, . 402 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 403 Label Switching Architecture", RFC 3031, January 2001. 405 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 406 Edge (PWE3) Architecture", RFC 3985, March 2005. 408 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 409 Division Multiplexing (TDM) over Packet (SAToP)", RFC 410 4553, June 2006. 412 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 413 Pate, "Structure-Aware Time Division Multiplexed (TDM) 414 Circuit Emulation Service over Packet Switched Network 415 (CESoPSN)", RFC 5086, December 2007. 417 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 418 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 419 December 2007. 421 [SyncE] ITU-T, "G.8261 : Timing and synchronization aspects in 422 packet networks", Recommendation G.8261, August 2013, 423 . 425 [TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements 426 for Evolved Universal Terrestrial Radio Access Network 427 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 429 [TS25104] 3GPP, "Base Station (BS) radio transmission and reception 430 (FDD)", 3GPP TS 25.104 3.14.0, March 2007. 432 [TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access 433 (E-UTRA); Base Station (BS) radio transmission and 434 reception", 3GPP TS 36.104 10.11.0, July 2013. 436 [TS36133] 3GPP, "Evolved Universal Terrestrial Radio Access 437 (E-UTRA); Requirements for support of radio resource 438 management", 3GPP TS 36.133 12.7.0, April 2015. 440 [TS36211] 3GPP, "Evolved Universal Terrestrial Radio Access 441 (E-UTRA); Physical channels and modulation", 3GPP TS 442 36.211 10.7.0, March 2013. 444 [TS36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) 445 and Evolved Universal Terrestrial Radio Access Network 446 (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 447 10.11.0, September 2013. 449 [TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive 450 Networks Task Group", 2013, 451 . 453 Author's Address 455 Jouni Korhonen 456 Broadcom Corporation 457 3151 Zanker Road 458 San Jose, CA 95134 459 USA 461 Email: jouni.nospam@gmail.com