idnits 2.17.1 draft-liu-rtgwg-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 (October 25, 2021) is 914 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) == Unused Reference: 'I-D.ietf-rtgwg-net2cloud-gap-analysis' is defined on line 304, but no explicit reference was found in the text == 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 (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group S. Liu 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Zheng 5 Expires: April 28, 2022 Huawei Technologies 6 October 25, 2021 8 Accessing Cloud via Optical Network Problem Statement 9 draft-liu-rtgwg-optical2cloud-problem-statement-00 11 Abstract 13 This document describes the scenarios and requirements for the Cloud 14 accessing through optical network, as a complementary functionality 15 of the network and cloud coordination. The problem from optical 16 perspective is different with packet, and statement is made in this 17 document. 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 https://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 April 28, 2022. 36 Copyright Notice 38 Copyright (c) 2021 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 55 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Multi-cloud accessing . . . . . . . . . . . . . . . . . . . 3 57 2.2. High-quality leased line . . . . . . . . . . . . . . . . . 4 58 2.3. Cloud virtual reality . . . . . . . . . . . . . . . . . . . 5 59 3. Requirement and Problem statement . . . . . . . . . . . . . . 5 60 3.1. LxVPN of optical networks for multiple-to-multiple access . 5 61 3.2. Small Granularity Switching . . . . . . . . . . . . . . . . 6 62 3.3. High-performance and high-reliability . . . . . . . . . . . 6 63 4. Manageability Considerations . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 7.2. Informational References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 The cloud-related applications is becoming popular and wider 74 deployed, in enterprises and vertical industries. Companies with 75 multi-campus are interconnected together with the remote cloud, for 76 the purpose of storage and computation. Such cloud services require 77 high-level experiences including high availability, low latency, on- 78 demand adjustment and so on. 80 Optical is playing an important role in the transport network, with 81 its own large bandwidth and low latency feature. Based on the TDM 82 switching technology, the data transportation in optical networks 83 does not have any queuing problem to solve and can perfectly avoid 84 congestion. Such features can drastically improve the users 85 experience on the service quality. 87 Optical network is considered as the transportation solution for 88 long-distance. This feature is also suitable for the cloud 89 interconnections, especially when there is demand for large 90 bandwidth. 92 [I-D.ietf-rtgwg-net2cloud-problem-statement] and 93 [I-D.ietf-rtgwg-net2cloud-gap-analysis]gave a detailed description on 94 the coordination requirements between the network and the cloud, and 95 it is expected the description in this document can be used as a 96 complementary from the optical perspective. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Scenarios 108 With the prevalence of cloud services, enterprises services, home 109 services such as AR/VR, accessing clouds with optical networks is 110 increasingly attractive and becoming an option for the users. 111 Following scenarios provide a few typical applications. 113 2.1. Multi-cloud accessing 115 Cloud services are usually supported by multiple interconnected data 116 centers (DCs). Besides the on-demand, scalable, high available and 117 uses-based billing, mentioned in 118 [I-D.ietf-rtgwg-net2cloud-problem-statement], there are also needs 119 for Data Centre Interconnect (DCI) about high requirements on 120 capacity, latency, and flexible scheduling. This use case requires 121 specific capabilities of advanced OTN (Optical Transport Network) for 122 DCIs. 124 //------\\ /----\ 125 ||Enterprise|\\ |Vertical| 126 || CPE || \\ ------------ +-----+ /|Cloud | 127 \\------// \ +---*/ \*---+ |Cloud| // \----/ 128 |O-A| |O-E|----+ GW |/ 129 +---+ +---+ +-----+ 130 | OTN Networks | 131 //-----\\ ++---+ +---+ +-----+ /-----\ 132 || Vertical||-----+ O-A| |O-E|----+Cloud|---||Private|| 133 | CPE | +----*\ /*---+ | GW | | Cloud | 134 \\-----// ------------ +-----+ \-----/ 136 Figure 1: Cloud Accessing through Optical Network 138 A data center is a physical facility consisting of multiple bays of 139 interconnected servers, that performs computing, storage, and 140 communication needed for cloud services. Infrastructure-as-a-service 141 may be deployed in both public and private clouds, where virtual 142 servers and other virtual resources are made available to users on 143 demand and by self-service. 145 One typical scenario is the intra-city DCs, which communicate with 146 each other via the intra-city DCI network to meet the high 147 availability requirements. The active-active and Virtual Machine 148 (VM) migration services which require low latency are provided by the 149 intra-city DCI network. The intra-city DCI network supports the 150 public and/or the private cloud services, such as video, games, 151 desktop cloud, and cloud Internet cafe services. To ensure low 152 latency, intra-city DCI network is deployed in the same city or 153 adjacent cities. The distance is typically less than 100 km and more 154 likely less than 50km. One city may have several large DCs. 156 DCs are ideally interconnected through Layer 2/3 switches or routers 157 with full mesh connectivity. However, to improve interaction 158 efficiency as well as service experience, OTN is also evaluated as an 159 option to be used for DC interconnection. 161 There are three kinds of the connection relationship, point to point 162 access, single to multiple point access, and multiple to multiple 163 point access. Different types of connections are referring different 164 shapes, single point accessing single cloud, single point accessing 165 multiple clouds and multiple points accessing multiple clouds. 167 2.2. High-quality leased line 169 The high quality private line provides high security and reliability 170 and is suitable to ensure the end-to-end user experience for large 171 enterprises such asfinancial, medical centers and education 172 customers. The main advantages and drivers of the high quality 173 private line are as follows. 175 o High quality private lines provide large bandwidth, low latency, 176 secure and reliable for any type of connection. 178 o Accelerate the deployment of cloud services. The high-quality and 179 high-security of the private line connecting to the cloud can 180 enable enterprises to move more core assets to the cloud and use 181 low-latency services on the cloud. Cloud-based deployment helps 182 enterprises reduce heavy asset allocation and improve energy 183 saving, so that enterprises can focus on their major business. 185 o Reduce operator's CAPEX and OPEX. The end-to-end service 186 provisioning system enables quick provisioning of private line 187 services and improves user experience. Fault management can be 188 done from the device level to reduce the complexity of location. 190 o Enable operators to develop value-added services by providing 191 enterprise users with latency maps, availability maps, 192 comprehensive SLA reports, customized latency levels, and dynamic 193 bandwidth adjustment packages. 195 2.3. Cloud virtual reality 197 Cloud Virtual Reality (VR) offloads computing and cloud rendering in 198 VR services from local dedicated hardware to a shared cloud 199 infrastructure. Cloud rendered video and audio outputs are encoded, 200 compressed, and transmitted to user terminals through fast and stable 201 networks. In contrast to current VR services, where good user 202 experience primarily relies on the end user purchasing expensive 203 high-end PCs for local rendering, cloud VR promotes the 204 popularization of VR services by allowing users to enjoy various VR 205 services where rendering is carried out in the cloud. 207 Cloud VR service experience is impacted by several factors that 208 influence the achieved sense of reality, interaction, and immersion, 209 which are related to the network properties, e.g. bandwidth, latency 210 and packet loss. The network performance indicators, such as 211 bandwidth, latency, and packet loss rate, need to meet the 212 requirements to realize a pleasurable experience. 214 The current network may be able to support early versions of cloud VR 215 (e.g. 4K VR) with limited user experience, but will not meet the 216 requirements for large scale deployment of cloud VR with enhanced 217 experience (e.g. Interactive VR applications, cloud games). To 218 support more applications and ensure a high-quality experience, much 219 higher available and guaranteed bandwidth (e.g. larger than 1 Gbps), 220 lower latency (e.g. less than 10 ms) and lower jitter (e.g. less than 221 5 ms) are required. 223 3. Requirement and Problem statement 225 3.1. LxVPN of optical networks for multiple-to-multiple access 227 To establish MP2MP connections, TDM transport technologies, like OTN, 228 are adopting packet features. Some OTN equipments have adopted 229 packet processing functions, such as packet switching, MPLS VPN, 230 etc., which could provide an underlay performance guaranteed TDM 231 channel for cloud accessing, as an alternative of packet-based 232 connections. 234 3.2. Small Granularity Switching 236 Accroding to the ITU-T G.709 recommendation, the OTN is providing TDM 237 based connection with a granularity 1.25Gbps, which is more than the 238 demand for normal user. Most of the leased line is requesting a 239 bandwidth less than 10Mbps, and the request from big enterprises are 240 usually on the level of 100Mbps. Therefore, most of the leased lines 241 are with small granularity in the field. 243 The SDH was a good complementary of OTN for small granularity 244 solution, but SDH devices are gradually removed from the network due 245 to End of Services. As SDH networks gradually phase out, service 246 providers start to think about how to utilize OTN networks to 247 transmit small-granularity high-value SDH services. The OSU (optical 248 service unit) is proposed to solve the problem. 250 At ITU-T, two work items, G.sub1G.sup and G.OSU, have been initiated 251 aiming to enable OTN to support small-granularity services of 2M-1Gb/ 252 s. For G.OSU, the general idea is to put small granularity services 253 into OSU containers, and then put OSU containers into OPU payload 254 areas. OSU containers are flagged by Tributary Port Number (TPN) 255 tags located at the overhead of the OSU containers. At the 256 intermediate nodes, OSUs can be switched to different directions 257 based on the TPN tags in the overhead. Given the development of OSU, 258 the OTN is expected to be able to carry small granularity service and 259 create end-to-end optical connections. 261 3.3. High-performance and high-reliability 263 To support the above-mentioned applications some of the network 264 properties are critical to promise the Quality of Services (QoS). 265 For instance, high bandwidth (e.g. larger than 1 Gbps), low latency 266 (e.g. no more than 10 ms) and low jitter (e.g. no more than 5 ms), 267 are required for Cloud VR. In addition, small-granularity container 268 is required to improve the efficiency of the networks. 270 It is also critical to support highly reliable DCI for cloud 271 services. With advanced optical transport network protection and 272 automatic recovery technologies, services can still run properly even 273 fiber cuts occur in the DCI network. Specific protection and 274 restoration schemes are required, to provide high reliability for the 275 networks. 277 4. Manageability Considerations 279 TBD. 281 5. Security Considerations 283 TBD. 285 6. IANA Considerations 287 This document requires no IANA actions. 289 7. References 291 7.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 299 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 300 May 2017, . 302 7.2. Informational References 304 [I-D.ietf-rtgwg-net2cloud-gap-analysis] 305 Dunbar, L., Malis, A. G., and C. Jacquenet, "Networks 306 Connecting to Hybrid Cloud DCs: Gap Analysis", draft-ietf- 307 rtgwg-net2cloud-gap-analysis-07 (work in progress), July 308 2020. 310 [I-D.ietf-rtgwg-net2cloud-problem-statement] 311 Dunbar, L., Consulting, M., Jacquenet, C., and M. Toy, 312 "Dynamic Networks to Hybrid Cloud DCs Problem Statement", 313 draft-ietf-rtgwg-net2cloud-problem-statement-11 (work in 314 progress), July 2020. 316 Authors' Addresses 318 Sheng Liu 319 China Mobile 320 China 322 Email: liushengwl@chinamobile.com 323 Haomian Zheng 324 Huawei Technologies 325 H1, Xiliu Beipo Village, Songshan Lake, 326 Dongguan, Guangdong 523808 327 China 329 Email: zhenghaomian@huawei.com