idnits 2.17.00 (12 Aug 2021) /tmp/idnits11003/draft-mm-sdn-vc-vn-on-demand-use-case-01.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 (July 16, 2012) is 3595 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 Network Working Group M. Chen 3 Internet-Draft M. McBride 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: January 17, 2013 L. Ou 6 China Telecom 7 July 16, 2012 9 Software Defined Networks Use Case for Virtual Connection and Network on 10 Demand 11 draft-mm-sdn-vc-vn-on-demand-use-case-01 13 Abstract 15 Software Defined Networks (SDN) provide a way to virtualize and 16 abstract the network and presents the virtual/abstract resources to 17 the third-party applications/software. The applications/software 18 can, by the programmable interface or Northbound API, request, 19 manipulate and monitor the services that the network provided. With 20 this SDN capability, more innovative services can be introduced and 21 rapidly deployed. Additionally, existing services can be deployed 22 and managed in a much more simple way. 24 This document outlines two use cases that leverage the SDN 25 architecture/model to implement a kind of "self-help" and automated 26 set of network services: Virtual Connection on Demand (VCoD) and 27 Virtual Network on Demand (VNoD). 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 17, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Reference Architecture . . . . . . . . . . . . . . . . . . 5 71 2.2. VC on Demand . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.3. VN on Demand . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 76 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 At present, applications and networks are independent of each other, 82 and there is almost no interaction between the two layers. The 83 applications normally have no idea about how the application data be 84 transmitted over the network nor the status of the network. The 85 application requirements and constraints to the network are passed to 86 service providers by some bill forms or contracts, and then the 87 network operators set up the network according to the bill forms or 88 contracts. These processes will take a considerably long time to 89 take effect and are error-prone. If there are some new requirements 90 and updates, the processes will be re-done. This network service 91 architecture and model is increasingly unable to meet the needs of 92 modern applications (e.g., Cloud service, Data Center, etc.), which 93 may frequently request to create/delete network connections, adjust 94 the existing paths or choose the desired paths per performance 95 characteristic (e.g., delay, loss, jitter, etc.), price or some other 96 conditions. So, a new network service architecture and model is 97 required, and Software Defined Networks (SDNs) are considered to be a 98 set of promising solutions, which opens the network and provides 99 programmable interface (e.g., Northbound API) to the applications and 100 third-party software. 102 There are several kinds of network services: transport service 103 (Optical, Ethernet, Internet Protocol (IP), Multiprotocol Label 104 Switching (MPLS) Traffic Engineering (TE ) Label Switched Path (LSP), 105 etc.), Virtual Private Network (VPN ) service(VLAN, VxLAN, L2/L3 VPN, 106 etc.), policy related service (e.g., Access Control List (ACL)), 107 security service, etc. This document mainly focuses on the transport 108 and VPN related services that can be abstracted and categorized into 109 two types: Virtual Connection (VC) and Virtual Network(VN) services. 110 Other services are basically dependent on these two services. For 111 example, when you want to configure an ACL, load balance or security 112 service, you must configure it on a specific connection or network. 113 That is, they are the subordinate services of the connection and 114 network services. The VC or VN is a kind of logical/abstract network 115 services, where the VC can be mapped to a flow (as defined in 116 Openflow), an optical path(a lambda, fiber, etc.), an E-line, a 117 Pseudo Wire (PW), a TE LSP etc., and the VN can be mapped to a VLAN, 118 a VxLAN, an L2/L3 VPN, etc. With the VC and VN concept, it could 119 present a set of uniform abstract services and interfaces to the 120 applications, independent of the underlying network diversity and 121 complexity. 123 This document describes the use cases which leverage the SDN 124 architecture and model to implement the Virtual Connection on Demand 125 (VCoD) and Virtual Network on Demand (VNoD) services. 127 2. Use Cases 129 2.1. Reference Architecture 131 +-------------+ 132 | Application | 133 +-------------+ 134 ...................................|.................................. 135 +-------------+ +-------------+ +-------------+ 136 | Controller1 | | Controller2 | | Controller3 | 137 +-------------+ +-------------+ +-------------+ 138 .............|................|..................|............. 139 +------------+ +------------+ +-------------+ 140 Site1-|VDE | | |+ | VDE|--Site3 141 | \ ...-VDB|---|VDB ... VDB|++---|VDB- ... / | 142 | / | | ||| | \ | 143 Site2-|VDE | | ||| | VDE|--Site4 144 +-----VD1----+ +-++--VD2----+|| +-----VD3-----+ 145 ++---VDx----+| 146 +----VDy----+ 148 VD - Virtual Domain 149 VDE - Virtual Domain Edge 150 VDB - Virtual Domain Boundary 152 Figure 1 SDN Reference Architecture 154 Figure 1 is a SDN reference architecture that consists of 3 tiers, 155 application, controller and the physical network. For a large scale 156 network, there normally should be multiple controllers and each of 157 them is responsible for a specific domain of the network. Here, we 158 introduce a concept of Virtual Domain (VD) that provides a way to 159 abstract and split the physical network into controllable domains, 160 where each domain has its own controller. Each VD has its own 161 Virtual Domain Edges (VDE) that are the service access points for the 162 VD, and the Virtual Domain Boundaries (VDB) are the boundaries 163 between VDs. 165 There are many ways to split and plan the domains, for example, it 166 could simply be based on the natural routing domains(e.g., per an 167 area or AS) to split and form the VD . And it also could be based on 168 the service to split the domain, meaning the same physical network 169 could be abstracted to different VDs and each providing different 170 services; e.g., an IP/MPLS metro network could be abstracted to an L2 171 VPN VD and an L3 VPN VD simultaneously. 173 2.2. VC on Demand 175 +---------+ +----------------------+ 176 | APP |<----->| SDN Discovery Server | 177 +----+----+ +----------------------+ 178 +--------+ | 179 | Policy |\ | 180 +--------+ \+--------+------+ +---------------+ 181 +--------+ /| VC Controller | ... | VC Controller | 182 | PCE |/ +------------+--+ +---------------+ 183 +--------+ | 184 --+-------------------- 185 //////// \\\\\\\\ 186 |//// \\\\| 187 | | 188 |VDE1===========================================VDE2| 189 | | 190 |\\\\ Physical Network ////| 191 \\\\\\\\ //////// 192 ----------------------- 194 Figure 2 VC on Demand 196 Figure 2 illustrates the flow, involved with requesting a new Virtual 197 Connection, which includes the following steps: 199 1. Service Discovery 201 First, the application needs to discover the VC controller and its 202 capabilities and services. Typically , there will be multiple 203 controllers. The locations, capabilities, and supplied services of 204 the controllers may change over time. The SDN discovery server could 205 present a relevant fixed access location to the application and in 206 order to help make the model more robust. 208 The application sends a query message to the SDN discovery Server 209 (similar to ALTO server discovery) to retrieve the candidate 210 controllers and their relevant locations, capabilities, services, 211 etc. The App needs to determine which controller is the correct one 212 to use. 214 2. VC Request/Response 216 When the controller is determined, the application sends a VC request 217 to the VC Controller to Create/Delete/Modify/Query a VC (e.g., 218 request a new VC from VDE1 to VDE2). The VC controller could choose 219 to respond to the application immediately, or wait for the VC to be 220 successfully constructed and then respond to the application. 222 3. VC Path Compute 224 According to the requirements and constraints (e.g., bandwidth, 225 delay, loss etc.) from the App, the VC controller needs to determine 226 a specific network service to serve the VC request, map the VC to a 227 specific network path (e.g., mapping the VC to an openflow-based 228 flow/an E-line/an E-tree/a PW/a TE LSP... ) and then compute/find the 229 path. VC controller could finish the path computation by itself (for 230 example, the controller has an embedded path computation engine), or 231 it may send a path compute request to another entity(e.g., Path 232 Computation Element (PCE)) to finish the path computation. 234 4. VC Provisioning 236 When the VC path is determined, the VC controller will then send VC 237 provisioning request to the related network devices to provision the 238 path. For example, the request could be to install an entry in the 239 openflow table, or trigger the ingress PE to signal a TE LSP or PW, 240 etc. The communication channel between VC controller and the network 241 devices could be either the existing protocols (e.g., Openflow, 242 Netconf, Command Line Interface(CLI), etc.) or new APIs defined in 243 the future. 245 5. VC Monitoring 247 Once a VC is established, the application may require the ability to 248 monitor the status of the VC. The application data could be 249 directed, according to the VC status, to switchover the data to a 250 backup path when the master path is broken, or to switchover the data 251 to a more cost-effective path, etc. 253 6. VC Policy 255 TBD 257 2.3. VN on Demand 258 +--------+ +----------------------+ 259 | APP |<----->| SDN Discovery Server| 260 +----+---+ +----------------------+ 261 | 262 +--------+ +--------+------+ +---------------+ 263 | Policy |--| VN Controller | ... | VN Controller | 264 +--------+ +------------+--+ +---------------+ 265 | 266 --+-------------------- 267 //////// VDE3 \\\\\\\\ 268 |//// \\\\| 269 | | 270 |VDE1 VDE2| 271 | Physical Network | 272 |\\\\ ////| 273 \\\\\\\\ VDE4 //////// 274 ----------------------- 276 Figure 3 VN on Demand 278 Figure 3 illustrates the flow, involved with requesting a new Virtual 279 Network: 281 1. Service Discovery 283 Similar to VC on Demand, the application first needs to find where 284 the VN controller is located and the capabilities and services that 285 the controller can provide. Then it can be determined who the proper 286 controller is according to response from the SDN discovery server. 288 2. VN Request/Response 290 Once the controller is determined, the application sends a VN request 291 to the VN Controller to Create/Delete/Modify/Query a VN. The VN 292 controller could choose to respond to the application immediately, or 293 wait for the VN to be successfully constructed and then respond to 294 the application. 296 3. VN Orchestration 298 According to the requirements and constraints from the application, 299 the VN controller needs to determine a specific network service to 300 serve the VN request, map the VN to one or several specific physical 301 or logical networks (e.g., mapping the VN to a VLAN/VxLAN/L2VPN/ 302 L3VPN, or a combination of them) and then finish the VN computation/ 303 orchestration. 305 4. VN Provisioning 306 When the VN orchestration is completed, the VN controller will then 307 send a VN provisioning request to the related network devices to 308 provision the VN. 310 5. VN Monitoring 312 Once a VN is constructed, the application may require the ability to 313 monitor the status of the VN where it could steer the application 314 data according to the VN status. 316 6. VN Policy 318 TBD 320 3. IANA Considerations 322 This document makes no request of IANA. 324 Note to RFC Editor: this section may be removed on publication as an 325 RFC. 327 4. Security Considerations 329 TBD 331 5. Acknowledgements 333 6. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 Authors' Addresses 340 Mach(Guoyi) Chen 341 Huawei Technologies Co., Ltd 342 No. 3 Xinxi Road, Shang-di, Hai-dian District 343 Beijing 100085 344 China 346 Email: mach@huawei.com 347 Mike McBride 348 Huawei Technologies Co., Ltd 349 2330 Central Expressway 350 Santa Clara, CA 95050 351 USA 353 Email: michael.mcbride@huawei.com 355 Liang Ou 356 China Telecom 358 Email: oul@gsta.com