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