idnits 2.17.1 draft-liu-ccamp-optical2cloud-problem-statement-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 (7 March 2022) is 779 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-net2cloud-gap-analysis-07 == Outdated reference: A later version (-39) exists of draft-ietf-rtgwg-net2cloud-problem-statement-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group S. Liu 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Zheng 5 Expires: 8 September 2022 Huawei Technologies 6 A. Guo 7 Futurewei Technologies 8 Y. Zhao 9 China Mobile 10 7 March 2022 12 Problem Statement and Requirements of Accessing Cloud via Optical 13 Network 14 draft-liu-ccamp-optical2cloud-problem-statement-00 16 Abstract 18 This document describes the problem statement and requirements for 19 accessing cloud via optical network. The supported scenarios include 20 the multi-cloud access, optical leased line and cloud VR. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 8 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Multi-cloud access . . . . . . . . . . . . . . . . . . . 3 59 2.2. High-quality leased line . . . . . . . . . . . . . . . . 5 60 2.3. Cloud virtual reality (VR) . . . . . . . . . . . . . . . 5 61 3. Requirement and problem Statement . . . . . . . . . . . . . . 6 62 3.1. LxVPN over optical networks for multiple-to-multiple 63 access . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Service-awareness . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Deterministic performance . . . . . . . . . . . . . . . . 6 66 3.4. High performance and high reliability . . . . . . . . . . 7 67 4. Manageability Considerations . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Cloud-related applications are becoming popular and widely deployed 79 in enterprises and vertical industries. Companies with multiple 80 campuses are interconnected together with the remote cloud for 81 storage and computing. Such cloud services require high quality 82 experiences including high availability, low latency, on- demand 83 bandwidth adjustments and so on. 85 Optical network is playing an increasingly important role for bearing 86 cloud traffic due to its large bandwidth and low latency. With the 87 TDM switching technology, there is no need for queuing and scheduling 88 in optical networks as opposed to IP-based networks, which can 89 drastically improve the users experience on service quality. 91 Optical network using OTN (Optical Transport Network) or wavelength- 92 switching provides TDM-based connections with an access bandwidth 93 granularity of 1.25Gbps, i.e. ODU0 (Optical Data Unit) and above, 94 which is usually more than the demand for normal user, and user 95 traffic are usually aggregated before they are carried into the 96 network. However, recent development in ITU-T work items have aimed 97 to enable OTN to support small-granularity services of 2Mbps-1Gbps 98 through the introduction of Optical Service Unit (OSU). This 99 potentially allows L2/L3 services to be carried directly over optical 100 networks and transport end to end, making it even a more suitable 101 solution for bearing cloud network traffic. 103 [I-D.ietf-rtgwg-net2cloud-problem-statement] and 104 [I-D.ietf-rtgwg-net2cloud-gap-analysis] gave a detailed description 105 on the coordination requirements between the network and the cloud 106 assuming the network is IP-based. This document complements the 107 analysis by further examining the requirements from an optical 108 network perspective. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 2. Scenarios 120 With the prevalence of cloud services, enterprises services, home 121 services such as AR/VR, accessing clouds with optical networks is 122 increasingly attractive and becoming an option for the users. 123 Following scenarios provide a few typical applications. 125 2.1. Multi-cloud access 127 Cloud services are usually supported by multiple interconnected data 128 centers (DCs). Besides the on-demand, scalable, high available and 129 uses-based billing, mentioned in 130 [I-D.ietf-rtgwg-net2cloud-problem-statement], there are also needs 131 for Data Centre Interconnect (DCI) about high requirements on 132 capacity, latency, and flexible scheduling. This use case requires 133 specific capabilities of advanced OTN for DCIs. 135 //------\\ /----\ 136 ||Enterprise|\\ |Vertical| 137 || CPE || \\ ------------ +-----+ /|Cloud | 138 \\------// \ +---*/ \*---+ |Cloud| // \----/ 139 |O-A| |O-E|----+ GW |/ 140 +---+ +---+ +-----+ 141 | OTN Networks | 142 //-----\\ ++---+ +---+ +-----+ /-----\ 143 || Vertical||-----+ O-A| |O-E|----+Cloud|---||Private|| 144 | CPE | +----*\ /*---+ | GW | | Cloud | 145 \\-----// ------------ +-----+ \-----/ 147 Figure 1: Cloud Accessing through Optical Network 149 A data center is a physical facility consisting of multiple bays of 150 interconnected servers, that performs computing, storage, and 151 communication needed for cloud services. Infrastructure-as-a-service 152 may be deployed in both public and private clouds, where virtual 153 servers and other virtual resources are made available to users on 154 demand and by self-service. 156 One typical scenario is the intra-city DCs, which communicate with 157 each other via the intra-city DCI network to meet the high 158 availability requirements. The active-active and Virtual Machine 159 (VM) migration services which require low latency are provided by the 160 intra-city DCI network. The intra-city DCI network supports the 161 public and/or the private cloud services, such as video, games, 162 desktop cloud, and cloud Internet cafe services. To ensure low 163 latency, intra-city DCI network is deployed in the same city or 164 adjacent cities. The distance is typically less than 100 km and more 165 likely less than 50km. One city may have several large DCs. 167 DCs are ideally interconnected through Layer 2/3 switches or routers 168 with full mesh connectivity. However, to improve interaction 169 efficiency as well as service experience, OTN is also evaluated as an 170 option to be used for DC interconnection. 172 There are three kinds of the connection relationship, point to point 173 access, single to multiple point access, and multiple to multiple 174 point access. Different types of connections are referring different 175 shapes, single point accessing single cloud, single point accessing 176 multiple clouds and multiple points accessing multiple clouds. 178 2.2. High-quality leased line 180 The high-quality private line provides high security and reliability 181 and is suitable to ensure the end-to-end user experience for large 182 enterprises such as financial, medical centers and education 183 customers. The main advantages and drivers of the high quality 184 private line are as follows. 186 * High quality private lines provide large bandwidth, low latency, 187 secure and reliable for any type of connection. 189 * Accelerate the deployment of cloud services. The high quality and 190 high security of the private line connecting to the cloud can 191 enable enterprises to move more core assets to the cloud and use 192 low-latency services on the cloud. Cloud-based deployment helps 193 enterprises reduce heavy asset allocation and improve energy 194 saving, so that enterprises can focus on their major business. 196 * Reduce operator's CAPEX and OPEX. The end-to-end service 197 provisioning system enables quick provisioning of private line 198 services and improves user experience. Fault management can be 199 done from the device level to reduce the complexity of location. 201 * Enable operators to develop value-added services by providing 202 enterprise users with latency maps, availability maps, 203 comprehensive SLA reports, customized latency levels, and dynamic 204 bandwidth adjustment packages. 206 2.3. Cloud virtual reality (VR) 208 Cloud VR offloads computing and cloud rendering in VR services from 209 local dedicated hardware to a shared cloud infrastructure. Cloud 210 rendered video and audio outputs are encoded, compressed, and 211 transmitted to user terminals through fast and stable networks. In 212 contrast to current VR services, where good user experience primarily 213 relies on the end user purchasing expensive high-end PCs for local 214 rendering, cloud VR promotes the popularization of VR services by 215 allowing users to enjoy various VR services where rendering is 216 carried out in the cloud. 218 Cloud VR service experience is impacted by several factors that 219 influence the achieved sense of reality, interaction, and immersion, 220 which are related to the network properties, e.g. bandwidth, latency 221 and packet loss. The network performance indicators, such as 222 bandwidth, latency, and packet loss rate, need to meet the 223 requirements to realize a pleasurable experience. 225 The current network may be able to support early versions of cloud VR 226 (e.g. 4K VR) with limited user experience, but will not meet the 227 requirements for large scale deployment of cloud VR with enhanced 228 experience (e.g. Interactive VR applications, cloud games). To 229 support more applications and ensure a high-quality experience, much 230 higher available and guaranteed bandwidth (e.g. larger than 1 Gbps), 231 lower latency (e.g. less than 10 ms) and lower jitter (e.g. less than 232 5 ms) are required. 234 3. Requirement and problem Statement 236 3.1. LxVPN over optical networks for multiple-to-multiple access 238 L2VPN or L3VPN are used as overlay services on an optical network to 239 support multi-cloud access. Therefore, it is required for optical 240 networks as underlay to support multipoint-to-multipoint (MP2MP) 241 connections. 243 3.2. Service-awareness 245 Overlay packet-based services are usually configured separately from 246 the configuration of underly connections in optical networks. The 247 connections in optical networks are treated as static connections for 248 packet routing, therefore, they usually result in suboptimal routing 249 of traffic and inefficient use of network resources at both packet 250 and optical layer, making the network unable to adapt to dynamic 251 network traffic changes. 253 To support carrying dynamic cloud traffic, an optical network should 254 be capable of understanding the traffic type and patterns, as well as 255 the bandwidth and QoS requirement of the traffic, and map the traffic 256 onto the best feasible connections in the optical network. This 257 requires both the control and management plane of optical networks to 258 be able to sense the traffic and exchange the feasible QoS of 259 underlay optical connections with the packet layer, such that the 260 packet layer can make the best route selection. 262 3.3. Deterministic performance 264 Accessing cloud-based services requires deterministic performance 265 from the underlay optical networks in order to achieve good user 266 experience. Connections built on optical networks need to be 267 deterministic in many quality factors, such as end-to-end latency, 268 delay jitter, bandwidth, and availability supported by end-to-end 269 protection and restoration. These deterministic performances are 270 hard to reach on shared resources but can be achieved relatively 271 easier on TDM-based optical networks. 273 Traditionally in an optical network, connections are pre-configured 274 and the speed of dynamic restoration and reconfiguration of 275 connections are in the order of several hundred milliseconds to 276 several minutes. The control and management plane of the optical 277 network should be enhanced to significantly improve the speed of 278 connection operations and be able to convey accurate estimate of the 279 performance to the upper layer to achieve end-to-end deterministic 280 performance. Extensions to existing control plane and management 281 interfaces are likely needed to support this capability. 283 3.4. High performance and high reliability 285 To support the above-mentioned applications some of the network 286 properties are critical to promise the Quality of Services (QoS). 287 For instance, high bandwidth (e.g. larger than 1 Gbps), low latency 288 (e.g. no more than 10 ms) and low jitter (e.g. no more than 5 ms), 289 are required for Cloud VR. In addition, small-granularity container 290 is required to improve the efficiency of the networks. 292 It is also critical to support highly reliable DCI for cloud 293 services. With advanced optical transport network protection and 294 automatic recovery technologies, services can still run properly even 295 fiber cuts occur in the DCI network. Specific protection and 296 restoration schemes are required, to provide high reliability for the 297 networks. 299 4. Manageability Considerations 301 TBD 303 5. Security Considerations 305 TBD 307 6. IANA Considerations 309 This document requires no IANA actions. 311 7. References 313 7.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 7.2. Informative References 326 [I-D.ietf-rtgwg-net2cloud-gap-analysis] 327 Dunbar, L., Malis, A. G., and C. Jacquenet, "Networks 328 Connecting to Hybrid Cloud DCs: Gap Analysis", Work in 329 Progress, Internet-Draft, draft-ietf-rtgwg-net2cloud-gap- 330 analysis-07, 26 July 2020, 331 . 334 [I-D.ietf-rtgwg-net2cloud-problem-statement] 335 Dunbar, L., Consulting, M., Jacquenet, C., and M. Toy, 336 "Dynamic Networks to Hybrid Cloud DCs Problem Statement", 337 Work in Progress, Internet-Draft, draft-ietf-rtgwg- 338 net2cloud-problem-statement-11, 26 July 2020, 339 . 342 Acknowledgments 344 TBD 346 Authors' Addresses 348 Sheng Liu 349 China Mobile 350 Email: liushengwl@chinamobile.com 352 Haomian Zheng 353 Huawei Technologies 354 Email: zhenghaomian@huawei.com 356 Aihua Guo 357 Futurewei Technologies 358 Email: aihuaguo.ietf@gmail.com 360 Yang Zhao 361 China Mobile 362 Email: zhaoyangyjy@chinamobile.com