idnits 2.17.1 draft-hares-use-case-vn-vc-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 (October 15, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRS' is mentioned on line 81, but not defined == Unused Reference: 'I-D.amante-irs-topology-use-cases' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'I-D.atlas-irs-policy-framework' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'I-D.atlas-irs-problem-statement' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.bernstein-alto-large-bandwidth-cases' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.medved-irs-topology-requirements' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I-D.rfernando-irs-framework-requirement' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'I-D.ward-irs-framework' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'I-D.white-irs-use-case' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 411, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-amante-irs-topology-use-cases-00 == Outdated reference: A later version (-01) exists of draft-atlas-irs-policy-framework-00 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Hares 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational M. Chen 5 Expires: April 18, 2013 Huawei 6 October 15, 2012 8 Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network 9 on Demand using Interface to Routing System 10 draft-hares-use-case-vn-vc-00 12 Abstract 14 Software Defined Networks (SDN) provide a way to virtualize and 15 abstract the network and present the virtual or abstract resources to 16 the third-party applications running in software. The application 17 can utilize a programmable interface to receiving these virtual or 18 abstract resources in a form that allows monitoring or manipulation 19 of resources. Various programmatic interfaces have been proposed to 20 interface directly to the forwarding plane (OpenFlow, ForCES), or do 21 device configuration (NETCONF). ALTO has proposed a informational 22 interface to the application. Only the progammatic Interface to the 23 Routing System (IRS) provides an interface directly to the routing 24 system to utilize all aspects of the routing system as a system. 26 The IRS system interacts with the control plane processes to monitor 27 best paths to any destination and to change the routing information 28 base (RIB) or MPLS label information Base (LIB) which feeds the 29 forwarding tables the information needed to actually switch traffic 30 at a local level. 32 This document outlines how SDN networks can use the IRS interface to 33 implement an automated set of network services for Virtual Connection 34 on Demand (VCoD) and Virtual Network on Demand (VNoD) 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 18, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Virtual Circuit on Demand . . . . . . . . . . . . . . . . . . 6 73 4. Virtual Network on Demand (VNoD) . . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The Interface to the Routing System Framework [IRS] desribes a 82 mechanism where the distributed control plane can be augmented by an 83 outside control plane through an open, accessible interface, 84 including the Routing Information Base (RIB) and the label interface 85 (LIB) individual devices. IRS provides a "halfway point" between 86 completely replacing the traditional distributed control planes and 87 directly configure devices via off-board processes. 89 This draft proposes a set of use cases to use IRS mechanisms to 90 implement a Software Defined Network (SDN) with virtual connections 91 and virtual networks as automated services. This document focuses on 92 how IRS would support two automated network services: Virtual 93 Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). 94 The SDN service provides the basic connection and a guidance ("self- 95 help") functionality. 97 This paper contains a background section, a use case for IRS in VCoD, 98 and a use case for IRS in VNoD. 100 SDN is a new adventure for the Internet space. Each new adventure in 101 the Internet space requires lots of use cases so that the IETF may 102 determine the critical protocols. 104 2. Background 106 Applications and network layer flows have run independently since the 107 Internet started in the late 1980s. Provisioning of network 108 servivces and big flows has been done by service providers statically 109 or with proprietary. Recently, new server and host technologies have 110 increase application data traffic flows across the network. With the 111 advent of data center providers and cloud services, applications life 112 cycles have shortened to weeks rather than years. The need for fast 113 automated provisioning of virtual network connections or quick 114 provisioning of virtual private networks has increased. 116 Software Defined Neworks have have three areas of challenge to 117 provide such quick network services: a) how to control the network 118 flows, b) interfaces to networks, and c) how do calculate where these 119 network flows go. 121 Network flows can be controlled at the forwarding device level or the 122 network control plane level. Various progammable interfaces have 123 been proposed to provide control over individual forwarding devices. 124 OpenFlow, for instance, provides a mechanism to replace the dynamic 125 control plane processes on individual forwarding devices throughout a 126 network with off box processes that interact with the forwarding 127 tables on each device. Another example is NETCONF, which provides a 128 fast and flexible mechanism to interact with device configuration and 129 policy. 131 The tradeoff with the device level approach to control flows has to 132 do with benefits and challenges of having control systems off-board. 133 The benefit of off-board control systems is that the calculation unit 134 can be centralized. The challenge of the off-board control system 135 has a technical challenge and a deployment challenge. The technical 136 challenge is that off-board control systems may encounter time-delays 137 and communication failure. The deployment issues concerns utilizing 138 new protocols for this communication which may also have issues in 139 deployment. The promised benefits of off-board devices are reduction 140 in operational costs, improving scaling, control, and visiblity. 141 OpenFlow, for instance, provides a mechanism to replace the dynamic 142 control plane processes on individual forwarding devices throughout a 143 network with off box processes that interact with the forwarding 144 tables on each device. Another example is NETCONF, which provides a 145 fast and flexible mechanism to interact with device configuration and 146 policy. 148 The Interface to Routing System (IRS) interface provides an interface 149 to all aspects of the routing system as a system. This interface 150 allows the SDN approach to utilize the existing control plane 151 software without changing it. The IRS system interacts with the 152 control plane processes to monitor best paths to any destination and 153 to interact with the routing information base (RIB) or MPLS label 154 information base (LIB) which feeds the forwarding tables the 155 information needed to actually switch traffic at a local level. 157 Let us turn to the next challenge, the interface to the applciations. 159 Many academic efforts (e.g. Internet) have examined the benefits in 160 allowing applications to obtain more network information when making 161 decisions on how connect webs of interfaces. Recently, the IETF ALTO 162 protocol has been charted to provide resource information for peer- 163 to-peer applications. Expansions to ALTO's application interface 164 have been proposed to pass information regarding bandwidth and 165 network topologies. This ALTO work may apply to some large flow 166 Virtual Connections or Virtual Private networks need. However, these 167 ALTO use cases do not necessarily consider the on-demand issues or 168 IRS. This document presents these use cases. 170 This document describes a set of use cases which describe how 171 automated creation of Virtual Connection on Demand (VCoD) and Virtual 172 Networks On Demand (VNoD) based in SDN logic can be accomplished by 173 using an interface to the routing system (IRS). 175 There are several types of network services that can be considered as 176 network services over which virtual connections or virtual networks 177 can be created. These network services include: optical, Ethernet 178 (VLAN and SPB), Internet Protocol (IP), Multiprotocol Label Switching 179 (MPLS). Each of these networks can provide traffic engineered paths, 180 olicy control (e.g. Access control Lists (ACLs)), security services, 181 or some form of virtual LAN services (VLAN, VxAN, L2/L3 VPN). The 182 examples in this document focus on the transport and VPN related 183 services that can be abstracted into Virtual Connection (VC) and 184 Virtual Network (VN). 186 These abstract services (VC or VN) are logical services that can be 187 mapped to specific services. For example, a flow can be mapped to a 188 flow such as OpenFlow might provision through a set of networks. Or 189 a Flow might be mapped to a TE-LSP. These logical services provide a 190 uniform abstract service model that allows applications to configure 191 VC or VN services independent of the actual network technology 192 implementing it. 194 The use cases below leverage the SDN architecture and model and the 195 IRS Frmewaork to implement Virtual Circuit on Demand (VCoD) and 196 Virtual Network on Demand (VNoD). 198 Please note that this draft builds on the premise that SDN solutions 199 can augment rather than replace traditional distributed control 200 planes. Each use case is presented in its own section. 202 3. Virtual Circuit on Demand 204 The Virtual circuit on demand (VCoD) first needs to discover where 205 the IRS commissioners acting as controllers are. After selecting the 206 IRS commissioner which will control the VCoD circuit, the application 207 sends a requests to create, delete, modify or query circuits. At 208 this point, the IRS Controller takes these requests and performs the 209 appropriate operations. The discovery protocol and these 210 communications are outside the IRS protocol and framework. The 211 protocol could be ALTO that informs application which IRS 212 commissioner can support VCoD service. 214 Once the IRS Commissioner is chartered with the task of setting up 215 virtual circuits, the IRS Commission will communicate with the IRS 216 Agents in the nodes (routing/switching/optial) to set-up these 217 virtual circuits. In the example topoology below, IRS Commissioner 1 218 has received a request to set up a Virtual circuit from edge 1 to 219 edge 2. The IRS commmissioner works with the IRS Agent1 on node 1, 220 the IRS Agent 2 on node 2, the IRS Agent 3 on node 3, and the IRS 221 Agent 4 on node 4 to set up the virtual circuit. IRS Commissioner 1 222 is a VCoD capable IRS commissioner with logic to aid set-up, 223 monitoring, changing, and decommissioning of this circuit. IRS 224 Agents 1-4 contain the necessary logic to translate the IRS 225 Commissioner's commands to create the virtual circuit's link on their 226 interface. 228 The IRS framework defines the portion of this system that goes from 229 the VCoD-capable IRS commissioner to/from the VCoD-capable IRS 230 Agents. The IRS Commissioner can request information from the IRS 231 Agent such as topology or interface statics or available circuits, 232 and influence how the IRS Agents create the circuits. The topology 233 information passed between the IRS commission and Agent would include 234 for this application possible virtual connections to a destination 235 and the available bandwidth on that circuit. The interface 236 statistics exchanged could involve historical or instant statistics 237 on exit point performance, jitter, delay. The available of circuits 238 could involve any time-based availabilty for on-demand future usage. 240 Past solutions in this area have included uses of device 241 configuration across multiple nodes (SNMP or NETCONF based) with 242 proprietary services combined with topology queries. The lack of a 243 coordinated responses to routing topology queries has created 244 problems in quickly obtaining and configuring changes for Virtual 245 Circuits. New algorithms services in routing/switch such as Fast- 246 Reroute of RSVP or IGPs have aided the automatic re-establishment of 247 some circuits, but the complexity of some of these algorithms 248 increases cost within the network elements. It's often difficult to 249 justify the added complexity in the database and algorithms of 250 routing protools to solve what is considered a point case. 252 The following things need to be supported for this application: 254 o IRS Agents should provide the ability to read the virtual 255 connection topology database for the technology supported. For 256 optical, these are the optical connections and what node they 257 connect to. For MPLS, this is virtual circuit available, and what 258 nodes they connect to. For IP technologies, this could include 259 the GRE tunnels and what interface it connects to. For Ethernet 260 circuits this should involve circuit type (e.g, point-to-point 261 (p2p) or point-to-multipoint (p2mp)) and what nodes it can reach. 263 o IRS Agent should provide the ability to influence the 264 configuration of a virtual circuit in a node. 266 o IRS Agent should provide monitor and provide statistics on the 267 virtual connection to the IRS Commissioner. The IRS commissioner 268 can then determine if the connection falls below a quality level 269 the application has requested. If the IRS Commissioner does 270 determine the circuit is below the required quality, it could 271 create another circuit. The IRS Commission may choose to create 272 the second virtual circuit, transfer flows, and then break the 273 first circuit. 275 Example Topology for Virtual Circuit on Demand (VCoD). 277 ------------------------- 278 | Application | 279 --------------------------- 280 | | 281 | | 282 +------------------+< Policy +-------------------+< Policy 283 |IRS Commissioner-1|< PCE info |IRS Commissioner-2 |< PCEP 284 |VC controller | | VN controller | 285 +------------------+ +-------------------+ 286 | | |-----------+ | | 287 | | | | | 288 +--------+ +--------+ +---------+ +----------+ 289 | IRS | | IRS | | IRS | | IRS | 290 | Agent-1| |Agent-2 | | Agent-3 | | Agent-4 | 291 |--------| |--------+ +---------+ +----------+ 292 | node 1 | | node 2 | | node 3 | | node 4 | 293 +--------+ +--------+ +---------+ +----------+ 294 | | | | | | 295 edge1 |--------| |------------| | 296 |----edge2 298 While the set-up of these virtual circuits is possible with current 299 technoloyg, the lack of the IRS-like framework makes VCoD network 300 complex. With this support, VCoD may be able to reduce complexity on 301 the individual nodes. 303 4. Virtual Network on Demand (VNoD) 305 Virtual Networks on Demand (VNoD) are simply extensions to the 306 Virtual Connections on Demand concept. The IRS Commissioner is 307 tasked to create a Virtual network instead of a single connection. 309 The example sequence would be that the application discovers IRS 310 Commission-2 who is a VNoD via a protocol outside the IRS framework 311 (e.g. ALTO). The IRS Commissioner-2 works with the IRS AGents 1-4 312 to set-up a virtual network. This involves the following: 314 o gathering potential topology information (in order to create the 315 network, 317 o set-up the virtual network (via influencing configurations on 318 node), 320 o monitoring changes in topology (in order to potential failovers, 322 o influencing changes to virtual network via configurations, and 324 o removing the virtual network after the demand has epxired. 326 -------------------------- 327 | Application | 328 --------------------------- 329 | | 330 | | 331 +------------------+< Policy +-------------------+< Policy 332 |IRS Commissioner-1|< PCE info |IRS Commissioner-2 |< PCEP 333 |VC controller | | VN controller | 334 +------------------+ +-------------------+ 335 | | | | 336 |----------------------------+ | | | 337 | +------------------ | | 338 | | | | 339 +--------+ +--------+ +---------+ +----------+ 340 | IRS | | IRS | | IRS | | IRS | 341 | Agent-1| |Agent-2 | | Agent-3 | | Agent-4 | 342 |--------| |--------+ +---------+ +----------+ 343 | node 1 | | node 2 | | node 3 | | node 4 | 344 +--------+ +--------+ +---------+ +----------+ 345 | | | | | | | | | 346 | |--------| |------------| | +------+ |-end-point-3 347 | | | 348 end-point-1 | 349 |----end-point2 351 This topology shares some configuration needs with the central 352 membership computation for MPLS VPNs from (draft-white-irs-use-cases) 353 but the mechanisms are not specific to MPlS VPNS. 355 5. IANA Considerations 357 This document includes no request to IANA. 359 6. Security Considerations 361 This document has no security issues as just contains use cases. 363 7. Normative References 365 [I-D.amante-irs-topology-use-cases] 366 Amante, S., Medved, J., and T. Nadeau, "Topology API Use 367 Cases", draft-amante-irs-topology-use-cases-00 (work in 368 progress), October 2012. 370 [I-D.atlas-irs-policy-framework] 371 Atlas, A., Hares, S., and J. Halpern, "A Policy Framework 372 for the Interface to the Routing System", 373 draft-atlas-irs-policy-framework-00 (work in progress), 374 September 2012. 376 [I-D.atlas-irs-problem-statement] 377 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 378 Routing System Problem Statement", 379 draft-atlas-irs-problem-statement-00 (work in progress), 380 July 2012. 382 [I-D.bernstein-alto-large-bandwidth-cases] 383 Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth 384 Query and Control of Core Networks", 385 draft-bernstein-alto-large-bandwidth-cases-02 (work in 386 progress), July 2012. 388 [I-D.medved-irs-topology-requirements] 389 Medved, J., Gredler, H., Previdi, S., and S. Amante, 390 "Topology API Requirements", 391 draft-medved-irs-topology-requirements-00 (work in 392 progress), October 2012. 394 [I-D.rfernando-irs-framework-requirement] 395 Fernando, R., Medved, J., Ward, D., Atlas, A., and B. 396 Rijsman, "IRS Framework Requirements", 397 draft-rfernando-irs-framework-requirement-00 (work in 398 progress), October 2012. 400 [I-D.ward-irs-framework] 401 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 402 Routing System Framework", draft-ward-irs-framework-00 403 (work in progress), July 2012. 405 [I-D.white-irs-use-case] 406 White, R., Hares, S., and R. Fernando, "Use Cases for an 407 Interface to the Routing System", 408 draft-white-irs-use-case-00 (work in progress), 409 September 2012. 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 Authors' Addresses 416 Susan Hares 417 Huawei Technologies (USA) 418 2330 Central Expressway 419 Santa Clara, CA 95050 420 USA 422 Email: Susan.Hares@huawei.com 424 Mach Chen 425 Huawei 426 No. 3 Xinxi Road, Shangdo-di 427 Hai-Dan District, Beijing 100085 428 USA 430 Email: mach@huawei.com