idnits 2.17.1 draft-hares-i2rs-use-case-vn-vc-03.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 (July 4, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-hares-i2rs-info-model-service-topo-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-04 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-04 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-05 == Outdated reference: A later version (-02) exists of draft-ji-i2rs-usecases-ccne-service-01 Summary: 0 errors (**), 0 flaws (~~), 7 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 M. Chen 4 Intended status: Informational Huawei Technologies 5 Expires: January 5, 2015 July 4, 2014 7 Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network 8 on Demand (VNoD) using Interface to Routing System 9 draft-hares-i2rs-use-case-vn-vc-03 11 Abstract 13 Software Defined Networks (SDN) provide a way to virtualize and 14 abstract the network in order to present virtual or abstract 15 resources to third-party applications running in software. 16 Applications can utilize a programmable interface to receive these 17 virtual or abstract resource descriptions in a form that allows 18 monitoring or manipulation of resources within the network. The 19 Interface to the Routing System (I2RS) provides an interface directly 20 to the routing System to monitor best paths to any destination or 21 change routes in the routing information base (RIB) or MPLS Label 22 Information Base (LIB). The I2RS interfaces may be combined with 23 other interfaces to the forwarding plane (ForCES (RFC3746)), device 24 configuration (NETCONF), or mid-level/peer-to-peer (ALTO, draft-ietf- 25 alto-protocol) system to create these virtual pathways. 27 This document outlines how SDN networks can use the I2RS interface to 28 implement an automated set of network services for the Virtual 29 Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). 30 These systems provide service routing a better way to create paths 31 within a hub and spoke environment, and provide service routing the 32 ability to create pathways based on service. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 5, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Summary of I2RS requirements . . . . . . . . . . . . . . . . 3 70 3. Virtual Circuit on Demand . . . . . . . . . . . . . . . . . . 5 71 3.1. Why I2RS enabled solutions are necessary . . . . . . . . 6 72 3.2. Why is not in scope for I2RS . . . . . . . . . . . . . . 6 73 3.3. Example Topology for Virtual Circuit on Demand (VCoD) . . 6 74 3.4. I2RS Requirements for Virtual Circuit on Demand (VCoD) . 7 75 4. Virtual Network on Demand (VNoD) . . . . . . . . . . . . . . 8 76 5. Automated On Demand Networks . . . . . . . . . . . . . . . . 10 77 6. What is Missing in RIB Informational Model (RIB IM) . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The Interface to the Routing System (I2RS) architecture 88 ([I-D.ietf-i2rs-architecture]) describes a mechanism where the 89 distributed control plane can be augmented by an outside control 90 plane through an open accessible programmatic interface. I2RS 91 provides a "halfway point" between completely an architecture that 92 replaces the traditional distributed control planes and directly 93 configuring devices via off-board processes. 95 This draft proposes a set of use cases using I2RS mechanisms to 96 implement a Software Defined Network (SDN) to enact virtual 97 connections and virtual networks as automated services. This 98 document focuses on how I2RS would support two automated network 99 services: Virtual Connection on Demand (VCoD) and Virtual Network on 100 Demand (VNoD). Virtual Connections on Demand (VCoD) and Virtual 101 Network on Demand (VNoD) may be used within hub-spoke networks and 102 improve service routing. In the future, an application enabled SDN 103 service may provide the Virtual Circuits (VCoD) and Virtual Networks 104 on Demand (VNoD) for any type of network service. 106 This document contains a summary of I2RS requirements from VCoD and 107 VNoD use case, background to I2RS, a VCoD use case, a VNoD use case, 108 and a discussion of what the RIB Information Model is missing. Those 109 familiar with I2RS problem statement 110 ([I-D.ietf-i2rs-problem-statement]), I2RS architecture 111 ([I-D.ietf-i2rs-architecture]), and the concepts of Virtual 112 Connections (VCs) or Virtual Networks (VNs) may wish to skip the 113 background section. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. Summary of I2RS requirements 123 This section contains a summary of what each use case indicates is 124 needed in the I2RS protocol (features and data). Section 3-5 provide 125 descriptions of the Virtual Circuit on Demand (VCoD), Virtual Network 126 on Demand (VNoD), and Automated on Demand Networks. Each of these 127 sections specifies a use case description followed by a summary of 128 I2RS requirements. 130 The use cases in this document have been numbered to allow coherent 131 compilation of the the I2RS requirements into a single list. In this 132 draft, each unique requirement for the I2RS protocol(I2RS client-I2RS 133 agent) for the Virtual Circuit on Demand (VCoD) use caes has the 134 label VCoD-REQnn where nn is an number. Each unique requirement for 135 the VNoD use case has the label VNoD-REQnn where nn is a number. 136 This use case also indicates things which are lacking in the Each 137 unique requirement for for VCoD additions to the I2RS RIB 138 Informational Model VCOD-IM-REQnn (where nn is a unique number). 139 Similarly, each unique requirement for VNoD additions to the RIB 140 informational Model is identified with VNoD-IM-REQnn where nn is a 141 unique number. Section 6 contains a list of what is missing in the 142 RIB Informational Model. 144 The requirements for Virtual Connections on Demand (VCoD) use cases 145 are: 147 o VCoD-REQ01: I2RS Agent SHOULD provide the ability to read the 148 virtual network topology database for the technology supported to 149 determine nodes and connections. For optical, these are the 150 optical connections and what node they connect to, and the 151 topologies created. For MPLS, this is virtual circuit available, 152 what nodes they connect to, and the network topologies created. 153 For IP technologies, this could include the GRE tunnels, what 154 interface it connects to, and the topologies created. For 155 Ethernet circuits this should involve circuit type (e.g, point-to- 156 point (P2P) or point-to-multipoint (P2MP)) and what nodes it can 157 reach, and the topologies created. 159 o VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the 160 configuration of a virtual circuit in a node. 162 o VCod-REQ03: I2RS Agent SHOULD provide monitor and provide 163 statistics on the virtual connection to the I2RS client via a Read 164 request or status Notification. The I2RS client can then 165 determine if the connection falls below a quality level the 166 application has requested. If the I2RS client does determine the 167 circuit is below the required quality, it could create another 168 circuit. The I2RS may choose to create the second virtual 169 circuit, transfer flows, and then break the first circuit. 171 The Virtual Network on Demand (VCoD) contains the same first three 172 requirements. This means that: 174 o VNoD-REQ01 = VCoD-REQ01, 176 o VNoD-REQ02 = VCoD-REQ02, and 178 o VNoD-REQ03 = VCoD-REQ03. 180 These requirements will not be repeated, so the VNoD begin with VNoD- 181 REQ-04. 183 The requirements for the Virtual Networks on Demand (VNoD) are: 185 o VT-VN-REQ04: I2RS Agent SHOULD provide the ability to influence 186 the configuration of a virtual network in a node. 188 o VT-VN-REQ05: I2RS Agent SHOULD provide the ability to report 189 statistics on the network nodes and end-to-end traffic flows via 190 read of status data or via notifications of status. 192 o VT-VN-REQ06: The I2RS protocol and RIB Informational Model (IM) 193 MUST support logical tunnels of type MPLS as well as IP, GRE, 194 VxLAN, and GRE. Large carrier networks utilize MPLS in a variety 195 of forms (LDP, static MPLS TE, or dynamic TE LSPs created by RSVP- 196 TE). 198 o VT-VN-REQ07: I2RS SHOULD support Informational Models and features 199 to allow MPLS technologies to create Hub-spoke topology and 200 service routing in networks in Carriers, Enterprise, and Data 201 Centers. 203 o VT-VN-REQ08: I2RS protocols, Information Models, and Data Models 204 MUST be able to support Carriers using these MPLS technologies to 205 support networks for Mobile BackHaul, on-demand MPLS overlays, and 206 on-demand video conferencing networkings. 208 3. Virtual Circuit on Demand 210 Virtual Circuit on Demand (VCoD) application associates to I2RS 211 client (or clients) which can communicate with the I2RS agent (or 212 agents) which control the VCoD circuit's creation, deletion, 213 modification, query for information or status changes. Information 214 for this application needs to include for network topology, interface 215 statistics, available circuits per node, available bandwidth on 216 circuits. Interface statistics might be required on a historical and 217 instantaneous time basis. The circuit statistics might also need 218 jitter, delay, and exit-point performance. 220 The virtual circuits may be obtained via RIB Informational Model (RIB 221 IM) ([I-D.ietf-i2rs-rib-info-model]) from the interface list, or from 222 the nexthop lists. Write access to set-up new interfaces is not 223 clearly spelled out in the current version of the RIB IM, nor are the 224 statistics (historical or time). This use case points out additional 225 Information Models (IMs) that need to be added to the I2RS 226 information models. 228 In the example topology below, the VCoD application's I2RS client 229 communicates with I2RS agents to set-up virtual circuits from Edge 1 230 to Edge 2. The I2RS client communicates with I2RS Agent-1 on node 1, 231 I2RS Agent-2 on node 2, I2RS Agent-3 on node 3, and I2RS Agent 4 on 232 node 4 for to set-up the virtual circuit. The VCoD application 233 contains the necessary logic to determine the pathway from Edge 1 to 234 Edge 2. 236 A second option for VCoD is to have an application communicate with 237 two I2RS clients who cooperate to set-up the virtual connections 238 between Edge 1 and Edge 2. Information passed between the two 239 clients can be done via other IETF protocols (E.g. stateful PCE or 240 ALTO). 242 3.1. Why I2RS enabled solutions are necessary 244 Past solutions in this area have included uses of device 245 configuration across multiple nodes (SNMP or NETCONF based) with 246 proprietary services combined with topology queries. The lack of 247 coordinated responses to routing topology queries has created 248 problems in quickly obtaining and configuring changes for Virtual 249 Circuits. New algorithms can create better services in routing and 250 switching. These algorithms include Fast-Reroute of RSVP or IGPs 251 which aid the automatic re-establishment of some circuits, but the 252 complexity of some of these algorithms increases cost within the 253 network elements. It's often difficult to justify the added 254 complexity in the database and algorithms of routing protocols to 255 solve what is considered a point case. 257 While the set-up of these virtual circuits is possible with current 258 technology, the lack of the I2RS-like framework makes VCoD network 259 complex. With this support, VCoD may be able to reduce complexity on 260 the individual nodes. 262 3.2. Why is not in scope for I2RS 264 The means by which the VCoD application determines which I2RS client 265 to associate with is outside the I2RS protocol and architecture. A 266 list of virtual circuits per node may be queried from the RIB 267 Informational Model's (RIB IM) ([I-D.ietf-i2rs-rib-info-model]) 268 interface and nexthop lists. However, other means may be used to 269 determine the possible interfaces on a node. For example, ALTO could 270 inform the application which nodes have an I2RS Agent supporting the 271 VCoD service, and SNMP/NETCONF could be used to determine which 272 interfaces were configured. 274 3.3. Example Topology for Virtual Circuit on Demand (VCoD) 275 +----------------------------+ 276 | Application (VCoD) | 277 +---*------------------------+ 278 | | 279 | | 280 +-------*------------++-------------------+< NETCONF 281 |I2RS client 1 |< PCE info> |I2RS Commissioner-2 |< PCEP 282 |VC controller | | VN controller | 283 +--*----------*--*-*-+ +-------------------+ 284 | | | | | | 285 | | | |--------------------------+ | 286 | | |-----------+ | | | 287 | | | | | | 288 +--------+ +--------+ +---------+ +----------+ 289 | I2RS | | I2RS | | I2RS | | I2RS | 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 3.4. I2RS Requirements for Virtual Circuit on Demand (VCoD) 300 The following things need to be supported for this application: 302 o VCoD-REQ01: I2RS Agents SHOULD provide the ability to read the 303 virtual network topology database for the technology supported. 304 For optical, these are the optical connections and what node they 305 connect to, and the topologies created. For MPLS, this is virtual 306 circuit available, what nodes they connect to, and the network 307 topologies created. For IP technologies, this could include the 308 GRE tunnels, what interface it connects to, and the topologies 309 created. For Ethernet circuits this should involve circuit type 310 (e.g, point-to-point (p2p) or point-to-multipoint (p2mp)) and what 311 nodes it can reach, and the topologies created. 313 o VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the 314 configuration of a virtual circuit in a node. 316 o VCoD-REQ03: I2RS Agent SHOULD provide monitor and provide 317 statistics on the virtual connection to the I2RS client via a Read 318 request or status Notification. The I2RS client can then 319 determine if the connection falls below a quality level the 320 application has requested. If the I2RS client does determine the 321 circuit is below the required quality, it could create another 322 circuit. The I2RS may choose to create the second virtual 323 circuit, transfer flows, and then break the first circuit. 325 What is needed in the RIB IM Model 327 o VCoD-RIB_IM-REQ01: The RIB IM model 328 ([I-D.ietf-i2rs-rib-info-model] provides with each route an 329 associated nexthop-list 0-N members. Each nexthop-list is flagged 330 with a protection preference (1 or 2), and a Load balance weight 331 (1 to 99). If the host routes for all nodes in the topology exist 332 within the RIB IM model's instantiation, then the nexthop member 333 on the nexthop-list SHOULD provide the following information: 335 * identifier for interface 337 * egress interface (logical, virtual, or physical) 339 * address of physical interface (IP address or MAC) plus RIB 341 * tunnel encapsulation for interface (IP GRE, MPLS tunnel), 343 * logical tunnel identifier 345 * RIB name (for look-up resolution) 347 * flags for specialized look-ups (Discard packets, discard with 348 error notification, receive) 350 o VT-VC-RIB_IM-REQ02: The RIB IM model's primitives SHOULD include 351 circuit type (p2p, mp2mp), optical connection information, and 352 additional statistics per virtual circuit. 354 o VT-VC_RIB_IM-REQ03:The RIB IM model's instantiation within the 355 protocol must provide an easy way to specify queries for this 356 information. 358 4. Virtual Network on Demand (VNoD) 360 Virtual Networks on Demand (VNoD) are simply extensions to the 361 Virtual Connections on Demand concept. The I2RS client is tasked to 362 create a virtual network instead of a single connection. 364 The example sequence would be that the application discovers the 365 appropriate I2RS clients (I2RS VNoD client 1 and I2RS VNoD Client 2) 366 which support VNoD via a protocol outside the I2RS framework (e.g. 367 ALTO). The I2RS Client-2 works with the I2RS Agents 1-4 to set-up a 368 virtual network. This involves the following: 370 o gathering potential topology information (in order to create the 371 network, 373 o set-up the virtual network (via influencing configurations on 374 node), 376 o monitoring changes in topology (in order to potential failovers, 378 o influencing changes to virtual network via configurations, and 380 o removing the virtual network after the demand has expired. 382 +-------------------------+ 383 | Application | 384 +-------------------------+ 385 | | 386 | | 387 +------------------+< Policy +-------------------+