idnits 2.17.1 draft-pan-sdn-bod-problem-statement-and-use-case-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 130 == Unused Reference: '1' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 395, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Ping Pan 2 Internet Draft (Infinera) 3 Lyndon Ong 4 (Ciena) 5 Shane Amante 6 (Level 3) 8 Expires: April 31, 2012 October 31, 2011 10 Software-Defined Network (SDN) Use Case for 11 Bandwidth on Demand Applications 13 draft-pan-sdn-bod-problem-statement-and-use-case-01.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, and it may not be 23 published except as an Internet-Draft. 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, except to publish it 28 as an RFC and to translate it into languages other than English. 30 This document may contain material from IETF Documents or IETF 31 Contributions published or made publicly available before November 32 10, 2008. The person(s) controlling the copyright in some of this 33 material may not have granted the IETF Trust the right to allow 34 modifications of such material outside the IETF Standards Process. 35 Without obtaining an adequate license from the person(s) controlling 36 the copyright in such materials, this document may not be modified 37 outside the IETF Standards Process, and derivative works of it may 38 not be created outside the IETF Standards Process, except to format 39 it for publication as an RFC or to translate it into languages other 40 than English. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on January 31, 2012. 60 Copyright Notice 62 Copyright (c) 2011 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. 72 Abstract 74 Bandwidth on Demand services are offered by network operators in 75 industry and research sectors to support the needs of selected 76 customers needing high bandwidth point-to-point connections. 78 Without a standard interface for controlling the use of network 79 resources, user applications and services are subject to limits of 80 layering, security and interoperability across multiple vendors of 81 network equipment. 83 In this document, we argue the necessity in providing network 84 information to the applications, thereby enabling the applications 85 to directly provision network elements associated with the relevant 86 applications. 88 Table of Contents 90 1. Introduction...................................................3 91 2. Related Work...................................................4 92 3. Problem Definition.............................................4 93 4. The Role of an SDN Layer.......................................6 94 5. Use Cases......................................................7 95 5.1. Scheduled/ Dynamic Bandwidth On-Demand Service............7 96 5.2. Multi-Layer BoD Support...................................8 97 5.3. Virtualized Network Service...............................9 98 5.4. BoD Actions Supported by the SDN Orchestrator.............9 99 6. Security Consideration........................................10 100 7. IANA Considerations...........................................10 101 8. Normative References..........................................10 102 9. Acknowledgments...............................................11 104 1. Introduction 106 Bandwidth on Demand services are offered by network operators in 107 industry and research sectors to support the needs of selected 108 customers needing high bandwidth point-to-point connections. Such 109 services take advantage of dynamic control of the underlying network 110 to set up forwarding and resource allocation as requested by the 111 customer. Some control is given directly to the customer via a 112 portal so that there is no need to go through an intermediate 113 stage of service order provisioning on the part of the network 114 operator. 116 Currently such services are often based on management interfaces to 117 vendor equipment that are vendor-specific, and as a result the 118 operator must redesign its supporting control application for each 119 vendor domain, or limit their offering to a single vendor domain. 121 In this document, we propose that providing a common interface to 122 networks of different vendors and technologies would enable the 123 network provider to offer Bandwidth on Demand and other services 124 that are faster to deploy across a wide range of network equipment 125 by using additional network information. 127 Here are some of the conventions used in this document. The key 128 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC-2119 [RFC2119]. 132 2. Related Work 134 There has been much work in this area in recent years. OpenFlow has 135 defined an architecture for offering virtualized network control 136 through a centralized controller and proxies called FlowVisors. 137 These allow users to configure forwarding of packets within slices 138 of the network partitioned off for their use. The controller is 139 designed to control each network element directly through a 140 dedicated control interface. It is not designed to work with 141 existing control plane protocols. 143 More generally, TMF has developed models and interfaces for 144 operations and administration of networks through the north-bound 145 interface provided by the element management system. These 146 interfaces are not intended for real-time control of the network 147 element and need to take into account variations in the design and 148 features of different types of equipment. 150 PCE is a client-server protocol that operates in MPLS networks that 151 enables the network operators to compute and potentially provision 152 optimal point-to-point and point-to-multipoint connections. However, 153 PCE does not interface with applications to optimize traffic from 154 user applications. 156 3. Problem Definition 158 Figure 1 illustrates the relationship between application and 159 network today, where customer control of bandwidth on demand is 160 provided through applications created by the network operator 161 supporting the user interface, features and backend accounting for 162 the service. Such applications are used in single domain 163 deployments and have limited visibility of underlying IP/MPLS and 164 Transport networks and, most importantly, resource availability on 165 those networks. 167 +-------------+ +-------------+ 168 | Application | | Application | 169 | #1 | | #2 | 170 +-------------+ +-------------+ 171 | | 172 | | 173 +------------------+ +------------------+ 174 | Network | | Network | 175 | Domain #1 | | Domain #2 | 176 +------------------+ +------------------+ 178 Figure 1: Application to network relationship today 180 This presents a number of challenges and problems. Without a 181 standard interface to the network elements that comprise one or more 182 network domains and their associated control software, each 183 bandwidth on demand supporting application must be built for a 184 specific set of vendor equipment and is not easily generalizable to 185 different vendors or even different equipment offered by a single 186 vendor. While signaling interfaces such as the UNI could offer 187 standardized access to network control, such interfaces have not 188 been adopted because they provide minimal security and functionality 189 and are designed for more of a peer relationship between network 190 elements, traditionally at only a single (peer) layer of the 191 network. 193 Similarly, bandwidth on demand applications must be designed for a 194 single technology, which restricts the range of use and potential 195 users. If Domain #1 uses SDH, for example, and Domain #2 uses OTN 196 it may be necessary to design supporting Application #2 from scratch 197 even though Application #1 has been successfully offering service. 198 Ideally the interface should allow some level of technology 199 independence, as well as potentially integration to permit control 200 of multiple layers simultaneously (esp. packet and circuit). 202 Third, the application is generally limited to simple services 203 connecting a source to destination, because interfaces hide network 204 topology and do not allow visualization of the topology for 205 different customer views. For some services users may wish to 206 exercise control over path routing aspects such as shared risk, 207 required latency characteristics or inclusion or exclusion of areas 208 for policy reasons. 210 4. The Role of an SDN Layer 212 To solve the above problem, the proposal is to introduce a software- 213 driven network (SDN) layer (as shown in Figure 2), that is 214 responsible for network virtualization, programmability and 215 monitoring, between supporting applications and the network. 217 +-------------+ +-------------+ +-------------+ 218 | Application | | Application | | Application | 219 | #1 | | #2 | | #3 | 220 +-------------+ +-------------+ +-------------+ 221 | | | 222 | | | 223 +---------------------------------------------------+ 224 | SDN Layer | 225 | (Network virtualization, programmability | 226 | and Monitoring) | 227 +---------------------------------------------------+ 228 | | 229 | | 230 +------------------+ +------------------+ 231 | Physical Network | | Physical Network | 232 | Domain #1 | | Domain #2 | 233 +------------------+ +------------------+ 235 Figure 2: Application to network relationship for SDN 237 The purpose of the SDN Layer is to enable the applications 238 supporting bandwidth on demand services to access information about 239 and control (aggregate) traffic flows at various layers of the 240 network through a standard, secure and customizable interface. 241 Applications can visualize the traffic flows at the network layer, 242 and manage the mapping or binding between its traffic flows from 243 edge-to-edge through the associated networks. 245 The implementation of an SDN Layer involves interfacing among 246 different types of applications and different types of network 247 domains, based on technology or vendor, administrative or policy 248 control. Standardized interfaces must be defined to support this. 250 The architecture should be agnostic as to the type of network 251 control plan used in a supporting domain. The focus of work should 252 be on providing richer access to control of network resources rather 253 than on the scheme for network control used in the domain. 255 5. Use Cases 257 5.1. Scheduled/ Dynamic Bandwidth On-Demand Service 259 Figure 3 illustrates the flow of a scheduled or dynamic bandwidth 260 service. In the simplest case, connectivity may already be provided 261 between user-specified endpoints, however the bandwidth allocated 262 between endpoints can be varied within some overall limit based on a 263 predefined schedule or on spontaneous customer request. Note that 264 allowing bandwidth to be partitioned so that a scheduling 265 application has control over some pre-allocated set of resources is 266 necessary to support the scheduled BoD service. Also, the SDN layer 267 ideally hides the specific technology used to support the 268 connection, offering control of the service with associated rate, 269 latency and recovery features. 271 In more sophisticated services, the customer may be allowed to 272 create new connections within a specified set of endpoints and 273 delete such connections when the connectivity is no longer required. 275 User 276 Req's +------------+ 277 -------->| Controller | 278 +------------+ 279 | 280 | <----- North-bound protocol to adjust connections 281 | 282 \|/ 283 +---------+ +--------+ 284 | PE1 | | PE2 | 285 | |===== Provisioned Connection ===>| | 286 +---------+ +--------+ 288 Figure 3: Scheduled/Dynamic BoD Service 290 5.2. Multi-Layer BoD Support 292 User 293 Req's +------------+ 294 -------->| Controller | 295 +------------+ 296 | 297 | <----- North-bound protocol to map packets to circuits 298 | 299 \|/ 300 +--------------------+ +--------------------+ 301 Pkt | PE1 | Transport | PE2 | Pkt 302 ====>| Classifer<->Tunnel |<=== Circuit ===>| Classifer<->Tunnel |====> 303 +--------------------+ +--------------------+ 305 Figure 4: Multi-Layer BoD service 307 Figure 4 illustrates a BoD service that supports multi-layer network 308 control. This extends allows the network operator's supporting 309 applications to combine control of packet forwarding through 310 guaranteed bandwidth tunnels that connect sites in a (virtual) 311 private network as requested dynamically by the BoD customer. 312 Different transport network technologies may be used to provide the 313 server layer transport functions so that the application can evolve 314 easily with new transport technologies. 316 5.3. Virtualized Network Service 318 User 319 Req's +------------+ 320 -------->| Controller | 321 +------------+ 322 /|\ | 323 Topology --->| |<----- North-bound protocol to adjust connections 324 Gathering | | 325 | \|/ 326 +---------+ +--------+ 327 | PE1 | | PE2 | 328 | |===== Provisioned Connection ===>| | 329 +---------+ +--------+ 331 Figure 5: Virtualized network service 333 Figure 5 illustrates the flow of a virtualized network service that 334 offers some degree of topology visibility and control in addition to 335 the features of scheduled or dynamic BoD. For some customers it may 336 be desirable to provide visibility into the topology of the 337 resources they control, in order for the customer so they may 338 control the physical and/or virtual topology of the resources used 339 within their dedicated domain. 341 If this topology information is provided together with associated 342 cost, latency, SRLG, etc. for the links and nodes in the topology, 343 the customer is provided with additional flexibility to manipulate 344 routing of their data flows so as to balance the cost, latency, 345 energy efficiency or survivability using knowledge of client 346 applications and their particular needs and priorities. 348 At this time such visibility is not possible to provide, as 349 protocols provide either no visibility into topology or full 350 visibility into topology. For security reasons it is likely that a 351 supporting network operator will want to limit visibility and 352 control to some virtualized topology using functionality provided by 353 the SDN orchestrator. 355 5.4. BoD Actions Supported by the SDN Orchestrator 356 The following summarizes actions that would be supported by 357 the SDN orchestrator as part of a BoD service: 359 - increase or decrease bandwidth on an existing path between 360 two, or more, network clients; 362 - dynamically learn if resources are available, (e.g.: bandwidth, 363 latency, SRLG, etc.) to create a path between two, or more, 364 network clients; 366 - create a path and assign associated characteristics, (e.g.: 367 bandwidth, latency, SRLG, etc.) that connect two, or more, network 368 clients; 370 - configure mapping of packets, Ethernet frames, OTN frames, etc. 371 from a client interface into a specified network path (or paths) 372 connecting the appropriate ingress and egress client interfaces; 374 - configure some partition of network resources (e.g., links and 375 link capacity connecting some set of nodes and client endpoints) 376 to be controlled by a specific application; 378 - provide real or virtual topology information (links, nodes and 379 associated information such as costs, latency, etc.) for this 380 partition to the associated application. 382 6. Security Consideration 384 TBD 386 7. IANA Considerations 388 This document has no actions for IANA. 390 8. Normative References 392 [1] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 396 Syntax Specifications: ABNF", RFC 2234, Internet Mail 397 Consortium and Demon Internet Ltd., November 1997. 399 9. Acknowledgments 401 This work is based on the conversation with many people, including 402 Thomas Nadeau and Benson Schliesser. 404 Authors' Addresses 406 Ping Pan 407 Email: ppan@infinera.com 409 Lyndon Ong 410 Email: lyong@ciena.com 412 Shane Amante 413 Email: shane@level3.net