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