idnits 2.17.1 draft-dhody-actn-poi-use-case-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 373: '... optical domains MAY be provided to th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2016) is 2927 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-requirements-02 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dhody 3 Internet-Draft X. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: October 16, 2016 O. Gonzalez de Dios 6 Telefonica 7 D. Ceccarelli 8 Ericsson 9 B. Yoon 10 ETRI 11 April 14, 2016 13 Packet Optical Integration (POI) Use Cases for Abstraction and Control 14 of TE Networks (ACTN) 15 draft-dhody-actn-poi-use-case-06 17 Abstract 19 This document describes the Abstraction and Control of TE Networks 20 (ACTN) use cases related to Packet and Optical Integration (POI), 21 that may be potentially deployed in various TE networks and apply to 22 different applications. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 16, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. POI Scenario . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Packet Optical Integration . . . . . . . . . . . . . . . . . 7 62 3.1. Traffic Planning, Monitoring and Automatic Network 63 Adjustments . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1.1. Automated Congestion Management . . . . . . . . . . . 8 65 3.2. Protection and Restoration Synergy . . . . . . . . . . . 8 66 3.3. Service Awareness . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Coordination between Multiple Network Domains . . . . . . 9 68 4. Typical Workflow . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 8.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Network operators build and operate multi-layered multi-domain 81 networks and these domains may be technology, administrative or 82 vendor specific (vendor islands). Interoperability for dealing with 83 different domains is a perpetual problem for operators. Due to these 84 issues, new service introduction, often requiring connections that 85 traverse multiple domains, need significant planning, and several 86 manual operations to interface different vendor equipment and 87 technology accross IP and Optical layers. 89 The aim of Abstraction and Control of Transport Networks (ACTN) is to 90 facilitate virtual network operation, creation of a virtualized 91 environment allowing operators to view and control multi-subnet 92 multi-technology networks into a single virtualized network. This 93 will accelerate rapid service deployment of new services, including 94 more dynamic and elastic services, and improve overall network 95 operations and scaling of existing services. 97 [ACTN-REQ] describes high-level ACTN requirements some of which are 98 derived from the usecases described in this document. 100 [ACTN-FWK] describes a business model of ACTN, comprising of 101 customers, service providers and network providers. This separates 102 the network operations on physical network from the business needs 103 (based on virtual network). It further describes the architecture 104 model for ACTN including the entities (Customer Network 105 Controller(CNC), Mult-domain Service Coordinator(MDSC), and Physical 106 Network Controller(PNC)) thier interfaces. 108 Discussion with operators has highlighted a need for virtual network 109 operation based on the abstraction of underlying technology and 110 vendor domains. This would be used for a variety of key use cases, 111 including: 113 o Physical network infrastructure providers who want to build 114 virtual network operations infrastructure via standards-based 115 interfaces that facilitates automation and operation of multiple 116 virtual networks for both internal and external trust domains. 118 o Data Center operators that need to lease facility from a number of 119 physical network infrastructure providers to offer their global 120 data center applications and services. As they face multi-domain 121 and diverse transport technology, interoperability based on 122 standard-based abstraction will enable dynamic and flexible 123 applications and services. 125 The transport networks are in an unique position to embrace the 126 concepts of software defined networking (SDN) because of the existing 127 separation in control and forwarding plane via GMPLS/ASON. The path 128 computation element (PCE) [RFC4655] and its stateful extension 129 [STATEFUL-PCE] can further provide a central control over the 130 resources. Also [STATEFUL-PCE-INITIATED] provides capability to 131 initiate and delete LSP dynamically. ACTN is focused on building 132 over the existing blocks by adding programmability, access and 133 control over abstract virtual topologies. [ACTN-FWK] provide 134 detailed information regarding this work. This document focuses on 135 the Packet and Optical Integration (POI) use cases of ACTN. We refer 136 to POI as packet over any connection-oriented transport technologies 137 such as MPLS-TE, MPLS-TP, OTN or WSON. 139 It is preferable to coordinate network resource control and 140 utilization rather than controlling and optimizing resources at each 141 network layer (packet and optical transport network) independently. 142 This facilitates network efficiency and network automation. 144 In a multi-layer network via client and server networking roles, 145 Label Switched Paths (LSPs) in a server (lower) layer are used to 146 carry client (higher) layer LSPs across the server (lower) layer 147 network. POI in a distributed control plane environment may be 148 achieved by some of the existing mechanism as specified in [RFC4208] 149 and [RFC5623]. This document explores the POI use cases of ACTN to 150 help provide programmable network services like orchestration, access 151 to abstract topology and control over the resources. 153 Increasingly there is a need for packet and optical transport 154 networks to work together to provide accelerated services. Transport 155 networks can provide useful information to the packet network 156 allowing it to make intelligent decisions and control its allocated 157 resources. 159 1.1. POI Scenario 161 This section explores some typical scenario for packet and optical 162 integration (POI). These include, but not limited to, a single 163 administrative domain as well as Carriers-of-Carrier case. 165 Figure 1 shows a single administrative domain comprising of both 166 Packet and Optical transport networks. A POI coordinator would help 167 build and operate a multi-layered multi-domain allowing operators to 168 view and control a single virtualized network. 170 +------------+ 171 +------------------+ POI | 172 | |Orchestrator| 173 | +-----+------+ (MDSC) 174 +-v---+ | 175 | | | 176 +-----+ +--v--+ 177 Packet | | 178 Control +-----+ 179 (PNC) Optical Control (PNC) 180 +------------+ +---------------------------+ +--------------+ 181 | | | | | | 182 | +-+ | | +-+ +-+ | | +-+ +-+ | 183 | |R| |***|O| |O|********|R| |R| | 184 | +-+ +-+ |*| +-+ +-+ +-+ | | +-+ +-+ | 185 | |R|*****| |O| | | | 186 | +-+*****| +-+ | | | 187 | +-+ |*| +-+ +-+ +-+ | | +-+ | 188 | |R| |*****|O| |O| |O|*******|R| | 189 | +-+ | | +-+ +-+ +-+ | | +-+ | 190 | | | | | | 191 +------------+ +---------------------------+ +--------------+ 192 Packet Optical Transport Packet 193 Network Network Network 195 Figure 1: POI for single adminstration 197 Figure 2 shows a Carriers-of-Carrier case, where an optical transport 198 infrastructure provider provides ACTN service to the ISP. 200 +-------------+ 201 | ISP | 202 | Controler | (CNC) 203 +------------+------+------+---------------+ 204 | | | 205 | | | 206 | V | 207 | +------------+ | 208 | | MDSC | | 209 | | | | 210 | +------------+ | 211 | | | 212 | | | 213 | V | 214 | +------------+ | 215 +-+-------+ | PNC | +--------+-+ 216 | -- | | | | -- | 217 | | | | +------------+ || | | 218 | -- | | -- -- | 219 | -- | +-----------------+ | -- | | | 220 | | |**** | -- -- | ***| | -- | 221 | -- |*****| | | |**** | -- | 222 +---------+ | -- -- | +----------+ 223 ISP | -- | ISP 224 (Packet) | | | -- | (Packet) 225 | -- | | | 226 | -- | 227 +-----------------+ 228 Infrastructre 229 Provider 230 (optical) 232 Figure 2: POI for Carriers-of-Carrier 234 2. Terminology 236 The following terms are as defined in [ACTN-FWK]: 238 o CNC:Customer Network Controller 240 o PNC:Physical Network Controller 242 o MDSC:Multi-domain Service Coordinator 244 The following terminology is used in this document. 246 ACTN: Abstraction and Control of Transport Networks. 248 PCE: Path Computation Element. An entity (component, application, 249 or network node) that is capable of computing a network path or 250 route based on a network graph and applying computational 251 constraints. 253 POI: Packet and Optical Integration 255 VNTM: Virtual Network Topology Manager 257 3. Packet Optical Integration 259 Connections (or tunnels) formed across the optical transport network, 260 can be used as virtual TE links in the packet network. The 261 relationship is reduced to determining which tunnels to set up, how 262 to trigger them, how to route them, and what capacity to assign them. 263 As the demands in the packet network vary, these tunnels may need to 264 be modified. 266 One possible way to envision POI is via considering packet network as 267 customer i.e. an entity in packet network - (maybe a Path Computation 268 Element (PCE), Virtual Network Topology Manager (VNTM) [RFC5623], 269 Controller etc..) should be aware of the abstract topology of the 270 optical transport network. This entity is the customer network 271 controller (CNC) as per [ACTN-FWK] which interacts with MDSC. This 272 is shown in Figure 2. Another way would be to consider Packet and 273 Optical transport networks as domains and a POI coordinator (MDSC) to 274 help build and operate a multi-layered multi-domain network allowing 275 operators to view and control a single virtualized network as shown 276 in Figure 1. 278 In either case, the abstract topology may consist of established 279 tunnels in optical transport network or ones that can be created on 280 demand. The level of abstraction is dependent on various management, 281 security and policy considerations. This abstract topology 282 information in the packet network can be utilized in various cases, 283 as detailed in the following sections. 285 3.1. Traffic Planning, Monitoring and Automatic Network Adjustments 287 Currently there is a schism between network planning for packet and 288 optical transport networks. Sometimes these networks are 289 administered, operated and planned independently even when they are a 290 part of a single trusted domain. Any change in traffic requirements 291 requires long business process to make changes in the network. In 292 dynamic networks this is no longer acceptable. 294 A unified Packet+Optical traffic planning tool can be developed which 295 uses the traffic demand matrix to plan the optical transport network. 297 Further based on traffic demand changes, historical data, traffic 298 prediction and monitoring, changes should be made to the optical 299 transport network. An access to abstract topology of the optical 300 transport network based on established and potential (on-demand) 301 tunnels in optical transport network can provide mechanism to handle 302 this. 304 Further optical bypass may be established automatically to offload 305 the continuous changing traffic to optical transport network allowing 306 streamlined business process between packet and optical transport 307 networks. 309 3.1.1. Automated Congestion Management 311 Congestion management and synergized network optimization for packet 312 and optical transport networks can eliminate the need for overbooking 313 of optical transport networks as dumb pipes. Application could be 314 written that provide automated congestion management and network 315 optimization. Automated congestion management recognizes prolonged 316 congestion in the network and works with the controllers to add 317 bandwidth at an optical transport layer, to alleviate the congestion, 318 or make changes in the packet layer to reroute traffic around the 319 congestion. 321 For such applications there is a clear need for an abstract network 322 topology of optical transport layer, further there is also a need for 323 a synergy of cost and SLA across optical and packet networks. 325 3.2. Protection and Restoration Synergy 327 The protection and restoration are usually handled individually in 328 Packet and optical layer. There is a need for synergy and optimized 329 handling of protection of resources across layers. A lot more 330 resources in the optical transport network are booked for backup then 331 actually required since there is a lack of coordination between 332 packet and optical layers. The access to abstract graph of optical 333 transport network with information pertaining to backup path 334 information can help the packet network to handle protection, shared 335 risk, fault restoration in an optimized way. Informing the packet 336 network about both working and protection path which are either 337 already established, or potential path can be useful. 339 A significant improvements in overall network availability that can 340 be achieved by using optical transport shared-risk link group (SRLG) 341 information to guide packet network decisions; for example, to avoid 342 or minimize common SRLGs for the main (working) path and the loop 343 free alternative or traffic engineered fast reroute (LFA/TE FRR) 344 back-up path. Shared risk information need to be synergized between 345 the packet and optical. A mechanism to provide abstracted SRLG 346 information can help the packet network consider this information 347 while handling protection and restoration. 349 3.3. Service Awareness 351 In certain networks like financial information network (stock/ 352 commodity trading) and enterprises using cloud based applications, 353 Latency (delay), Latency-Variation (jitter), Packet Loss and 354 Bandwidth Utilization are associated with the SLA. These SLAs must 355 be synergized across packet and optical transport networks. Network 356 optimization evaluates network resource usage at all layers and 357 recommends or executes service path changes while ensuring SLA 358 compliance. It thus makes more effective use of the network, and 359 relieves current or potential congestion. 361 The main economic benefits of ACTN arise from its ability to maintain 362 the SLA of the services at reduced overall network cost considering 363 both packet and optical transport network. Operational benefits of 364 the ACTN also stem from greater flexibility in handling dynamic 365 traffic such as demand uncertainty or variations over time, or 366 optimization based on cost or latency, or improved handling of 367 catastrophic failures. 369 3.4. Coordination between Multiple Network Domains 371 In some deployments, optical transport network may further be divided 372 into multiple domains, an abstracted topology comprising of multiple 373 optical domains MAY be provided to the packet network. A Seamless 374 aggregation and orchestration across multiple optical transport 375 domains is achieved via the MDSC, a great help in such deployments. 377 Another interesting deployment involves multiple packet network 378 domains. There exist scenarios where the topology provided to the 379 packet network domains may be different based on the initial demand 380 matrix as well as, management, security and policy considerations. 382 The ACTN framework as described in [ACTN-FWK] should support the 383 aggregation and orchestration across network domains and layers. 385 Further Figure 3 shows a multi-domain scenario where multiple PNC 386 (each controlling a packet or optical domain) and a MDSC coordinating 387 among them and providing a consolidated view. 389 +-------------------------+ 390 | MDSC | 391 | | 392 +-------------------------+ 393 * 394 +------------+---------+--+ * +-----------+---------+--+ 395 | +---------+ | * | +---------+ | 396 | | PNC ************************* PNC | | 397 | +---------+---------+ | * | +---------+---------+ | 398 | | | | * | | | | 399 | | | | * | | | | 400 | | | | * | | | | 401 | | Packet | | * | | Packet | | 402 | +-------------------+ | * | +-------------------+ | 403 | | * | | 404 | | * | | 405 | | * | | 406 | | * | | 407 | | * | | 408 | +---------+ | * | +---------+ | 409 | | PNC ************************* PNC | | 410 | +---------+---------+ | | +---------+---------+ | 411 | | | | | | | | 412 | | | | | | | | 413 | | | | | | | | 414 | | Optical | | | | Optical | | 415 | +-------------------+ | | +-------------------+ | 416 +---+-------------------+-+ +--+-------------------+-+ 418 Domain 1 Domain 2 420 Figure 3: Coordination between Multiple Network Domains 422 4. Typical Workflow 424 Consider a two-layer network where the higher-layer network is a 425 packet-based IP/MPLS or GMPLS network and the lower-layer network is 426 a GMPLS-controlled optical network both under a common administrative 427 control. 429 The PNC in both layers are under a common MDSC that coordinates 430 between the two layers. And this multi-layer network is used to 431 interconnect DCs, where the DC controller (customer network 432 controller - CNC) takes charge as shown in Figure 4. 434 Data Center 435 ***** Controller 436 -------------------------------------*CNC*------------- 437 | ***** | 438 | | Multi-layer | 439 | v Coordinator | 440 | ****** | 441 | *MDSC*-- | 442 Data | ****** | | 443 Center | | | 444 +----+ | ***** | +----+ | 445 | DC1|<- *PNC*<- | DC3|<- 446 +----+ | ***** | +----+ | 447 .....|.. Packet | .... | 448 +----+ | . +-----------------------------------+ | .+----+ | 449 | DC2|<- .. /R R R R..../...|..| DC4|<- 450 +----+ / R R / | +----+ 451 ........./....R . R . R R../.....|..... 452 +-----------------------------------+ | 453 Packet . . . . . . | 454 Layer . . . . . . | 455 . . . . . . ***** | 456 . . . . . . *PNC*<- 457 . . . . . . ***** Optical 458 +-----------------------------------+ 459 / O . O . O . O O / 460 / O . O O / 461 Optical / O O O O O / 462 Layer +-----------------------------------+ 464 Figure 4: Typical Workflow 466 Data centre controller (as Customer Network Controller) interfaces 467 the data centre application stratum, it understands multiple DC 468 application requirements and their service needs. DC Controller 469 provides its traffic demand matrix that describes bandwidth 470 requirements and other optional QoS parameters (e.g., latency, 471 diversity requirement, etc.) for each pair of inter-DC connections. 472 The MDSC (multi-layer coordinator) sits between the DC controller 473 (CNC - the one issuing connectivity requests) and the physical 474 network controllers (the one managing the resources). In this case 475 each layer has its own PNC managing the resources in each layer with 476 MDSC acting as a multi-layer coordinator. The PNC is in charge of 477 configuring the network elements, monitoring the physical topology of 478 the network and passing it, either raw or abstracted, to the MDSC. 480 MDSC with the help of PNC(s) coordinates network resource control and 481 utilization facilitating network efficiency and network automation. 482 The MDSC are also responsible for the abstract topology and the level 483 of abstraction, which facilitate various DC usecases like VM 484 Migrations, global load balancing among geographically distributed 485 DCs, Business continuity and disaster recovery etc using the ACTN 486 framework in an elastic and dynamic and way, improving overall 487 network operations and scaling. 489 Based on the Data centre controller's (acting as CNC) requests for 490 virtual network paths, the MDSC mediates with the PNCs and maps these 491 'virtual' request to inter-layer coordinated path computation and 492 provisioning requests in the 'physical' domain to the PNC. Thus MDSC 493 acts as a multi-layer coordinator both in respect to multi-layer end 494 to end optimized path computation as well as multi-layer signaling 495 and provisioning. The path computation and abstract topology 496 creation would be based on the guidelines set by the CNC including 497 the optimization criteria, traffic profile, policy etc. 499 In case the PNC could not fulfill the desired request from MDSC and 500 indirectly from DC controller, there should be a feedback loop to the 501 MDSC so that suitable actions including path recalculation and 502 signaling, negotiation of parameters and attributes with DC 503 controller etc can be undertaken. Thus MDSC effectively arbitrate 504 between the customers (DC) and the existing network (PNC) in this 505 example. 507 5. Security Considerations 509 TBD. 511 6. IANA Considerations 513 None, this is an informational document. 515 7. Acknowledgments 517 8. References 519 8.1. Normative References 521 [ACTN-FWK] 522 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 523 Control of Traffic Engineered Networks", draft-ceccarelli- 524 teas-actn-framework-02 (work in progress), April 2016. 526 [ACTN-REQ] 527 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 528 Ceccarelli, "Requirements for Abstraction and Control of 529 TE Networks", draft-ietf-teas-actn-requirements-02 (work 530 in progress), April 2016. 532 8.2. Informative References 534 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 535 "Generalized Multiprotocol Label Switching (GMPLS) User- 536 Network Interface (UNI): Resource ReserVation Protocol- 537 Traffic Engineering (RSVP-TE) Support for the Overlay 538 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 539 . 541 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 542 Element (PCE)-Based Architecture", RFC 4655, 543 DOI 10.17487/RFC4655, August 2006, 544 . 546 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 547 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 548 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 549 September 2009, . 551 [STATEFUL-PCE] 552 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 553 Extensions for Stateful PCE", draft-ietf-pce-stateful- 554 pce-14 (work in progress), March 2016. 556 [STATEFUL-PCE-INITIATED] 557 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 558 Extensions for PCE-initiated LSP Setup in a Stateful PCE 559 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 560 progress), October 2015. 562 Appendix A. Contributor Addresses 564 Udayasree Palle 565 Huawei Technologies 566 Divyashree Techno Park, Whitefield 567 Bangalore, Karnataka 560037 568 India 570 EMail: udayasree.palle@huawei.com 572 Authors' Addresses 574 Dhruv Dhody 575 Huawei Technologies 576 Divyashree Techno Park, Whitefield 577 Bangalore, Karnataka 560066 578 India 580 EMail: dhruv.ietf@gmail.com 582 Xian Zhang 583 Huawei Technologies 584 Bantian, Longgang District 585 Shenzhen, Guangdong 518129 586 P.R.China 588 EMail: zhang.xian@huawei.com 590 Oscar Gonzalez de Dios 591 Telefonica 592 Spain 594 EMail: ogondio@tid.es 596 Daniele Ceccarelli 597 Ericsson 598 Via E. Melen 77, Genova - Erzelli 599 Italy 601 EMail: daniele.ceccarelli@ericsson.com 602 Bin-Yeong Yoon 603 ETRI 604 South Korea 606 EMail: byyun@etri.re.kr