idnits 2.17.1 draft-dhody-actn-poi-use-case-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 (January 10, 2014) is 3730 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACTN BOF D. Dhody 3 Internet-Draft X. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: July 14, 2014 O. Gonzalez de Dios 6 Telefonica 7 January 10, 2014 9 Packet Optical Integration (POI) Use Cases for Abstraction and Control 10 of Transport Networks (ACTN) 11 draft-dhody-actn-poi-use-case-00 13 Abstract 15 This document describes the Abstraction and Control of Transport 16 Networks (ACTN) use cases related to Packet and Optical Integration 17 (POI), that may be potentially deployed in various transport networks 18 and apply to different applications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 14, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Packet Optical Integration . . . . . . . . . . . . . . . . . 3 58 3.1. Traffic Planning, Monitoring and Automatic Network 59 Adjustments . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. Automated Congestion Management . . . . . . . . . . . 4 61 3.2. Protection and Restoration Synergy . . . . . . . . . . . 4 62 3.3. Service Awareness . . . . . . . . . . . . . . . . . . . . 5 63 3.4. Coordination between Multiple Network Domains . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 7.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The transport networks are in an unique position to embrace the 75 concepts of software defined networking (SDN) because of the existing 76 separation in control and forwarding plane via GMPLS/ASON. The path 77 computation element (PCE) [RFC4655] and its stateful extension 78 [STATEFUL-PCE] can further provide a central control over the 79 resources. Abstraction and Control of Transport Network (ACTN) is 80 focused on building over the existing blocks by adding 81 programmability, access and control over abstract virtual topologies. 82 [ACTN-FWK] provides detailed information regarding this work. 84 It is preferable to coordinate network resource control and 85 utilization rather than controlling and optimizing resources at each 86 network layer (packet and optical transport network) independently. 87 This facilitates network efficiency and network automation. 89 This document explores the Packet and Optical Integration (POI) use 90 cases of ACTN to help provide programmable network services like 91 access to abstract topology and control over the resources. 92 Increasingly there is a need for packet and optical transport 93 networks to work together to provide accelerated services. Transport 94 networks can provide useful information to the packet network 95 allowing it to make intelligent decisions and control its allocated 96 resources. In this POI use-case, we regard packet networks as a 97 consumer to transport networks. It is interesting to note that the 98 Packet networks themselves may have their ultimate clients to 99 support. The use case described in this document are primarily 100 concerned with 'packet network as a consumer' in a single trusted 101 domain. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Terminology 111 The following terminology is used in this document. 113 ACTN: Abstraction and Control of Transport Networks. 115 PCE: Path Computation Element. An entity (component, application, 116 or network node) that is capable of computing a network path or 117 route based on a network graph and applying computational 118 constraints. 120 POI: Packet and Optical Integration 122 VNTM: Virtual Network Topology Manager 124 3. Packet Optical Integration 126 Connections (or tunnels) formed across the optical transport network, 127 can be used as virtual TE links in the packet network. The 128 relationship is reduced to determining which tunnels to set up, how 129 to trigger them, how to route them, and what capacity to assign them. 130 As the demands in the packet network vary, these tunnels may need to 131 be modified. 133 An entity in packet network (maybe a Path Computation Element (PCE), 134 Virtual Network Topology Manager (VNTM) [RFC5623], Controller etc..) 135 should be aware of the abstract topology of the transport network. 136 The topology may consist of established tunnels in transport network 137 or ones that can be created on demand. The level of abstraction is 138 dependent on various management, security and policy considerations. 139 This abstract topology information in the packet network can be 140 utilized in various cases, as detailed in the following sections. 142 3.1. Traffic Planning, Monitoring and Automatic Network Adjustments 144 Currently there is a schism between network planning for packet and 145 optical transport networks. Sometimes these networks are 146 administered, operated and planned independently even when they are a 147 part of a single trusted domain. Any change in traffic requirements 148 requires long business process to make changes in the network. In 149 dynamic networks this is no longer acceptable. 151 A unified Packet+Optical traffic planning tool can be developed which 152 uses the traffic demand matrix to plan the optical transport network. 153 Further based on traffic demand changes, historical data, traffic 154 prediction and monitoring, changes should be made to the optical 155 transport network. An access to abstract topology of the optical 156 transport network based on established and potential (on-demand) 157 tunnels in transport network can provide mechanism to handle this. 159 Further optical bypass may be established automatically to offload 160 the continuous changing traffic to transport network allowing 161 streamlined business process between packet and optical transport 162 networks. 164 3.1.1. Automated Congestion Management 166 Congestion management and synergized network optimization for packet 167 and transport networks can eliminate the need for overbooking of 168 transport networks as dumb pipes. Application could be written that 169 provide automated congestion management and network optimization. 170 Automated congestion management recognizes prolonged congestion in 171 the network and works with the controllers to add bandwidth at a 172 transport layer, to alleviate the congestion, or make changes in the 173 packet layer to reroute traffic around the congestion. 175 For such applications there is a clear need for an abstract network 176 topology of optical transport layer, further there is also a need for 177 a synergy of cost and SLA across optical and packet networks. 179 3.2. Protection and Restoration Synergy 181 The protection and restoration are usually handled individually in 182 Packet and optical layer. There is a need for synergy and optimized 183 handling of protection of resources across layers. A lot more 184 resources in the optical transport network are booked for backup then 185 actually required since there is a lack of coordination between 186 packet and optical layers. The access to abstract graph of transport 187 network with information pertaining to backup path information can 188 help the packet network to handle protection, shared risk, fault 189 restoration in an optimized way. Informing the packet network about 190 both working and protection path which are either already 191 established, or potential path can be useful. 193 A significant improvements in overall network availability that can 194 be achieved by using optical transport shared-risk link group (SRLG) 195 information to guide packet network decisions; for example, to avoid 196 or minimize common SRLGs for the main (working) path and the loop 197 free alternative or traffic engineered fast reroute (LFA/TE FRR) 198 back-up path. Shared risk information need to be synergized between 199 the packet and optical. A mechanism to provide abstracted SRLG 200 information can help the packet network consider this information 201 while handling protection and restoration. 203 3.3. Service Awareness 205 In certain networks like financial information network (stock/ 206 commodity trading) and enterprises using cloud based applications, 207 Latency (delay), Latency-Variation (jitter), Packet Loss and 208 Bandwidth Utilization are associated with the SLA. These SLAs must 209 be synergized across packet and optical transport networks. Network 210 optimization evaluates network resource usage at all layers and 211 recommends or executes service path changes while ensuring SLA 212 compliance. It thus makes more effective use of the network, and 213 relieves current or potential congestion. 215 The main economic benefits of ACTN arise from its ability to maintain 216 the SLA of the services at reduced overall network cost considering 217 both packet and optical transport network. Operational benefits of 218 the ACTN also stem from greater flexibility in handling dynamic 219 traffic such as demand uncertainty or variations over time, or 220 optimization based on cost or latency, or improved handling of 221 catastrophic failures. 223 3.4. Coordination between Multiple Network Domains 225 In some deployments, optical transport network may further be divided 226 into multiple domains, an abstracted topology comprising of multiple 227 optical domains MAY be provided to the packet network. A Seamless 228 aggregation and orchestration across multiple optical transport 229 domains will be a great help in such deployments. 231 Another interesting deployment involves multiple packet network 232 domains. There exist scenarios where the topology provided to the 233 packet network domains may be different based on the initial demand 234 matrix as well as, management, security and policy considerations. 236 The ACTN framework as described in [ACTN-FWK] should support the 237 aggregation and orchestration across network domains and layers. 239 4. Security Considerations 241 TBD. 243 5. IANA Considerations 245 None, this is an informational document. 247 6. Acknowledgments 249 TBD. 251 7. References 253 7.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, March 1997. 258 7.2. Informative References 260 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 261 Element (PCE)-Based Architecture", RFC 4655, August 2006. 263 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 264 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 265 Traffic Engineering", RFC 5623, September 2009. 267 [STATEFUL-PCE] 268 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 269 Extensions for Stateful PCE [draft-ietf-pce-stateful- 270 pce]", October 2013. 272 [ACTN-FWK] 273 Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez, 274 "Framework for Abstraction and Control of Transport 275 Networks (draft-ceccarelli-actn-framework)", January 2014. 277 Appendix A. Contributor Addresses 279 Udayasree Palle 280 Huawei Technologies 281 Leela Palace 282 Bangalore, Karnataka 560008 283 INDIA 285 EMail: udayasree.palle@huawei.com 287 Authors' Addresses 289 Dhruv Dhody 290 Huawei Technologies 291 Leela Palace 292 Bangalore, Karnataka 560008 293 INDIA 295 EMail: dhruv.ietf@gmail.com 297 Xian Zhang 298 Huawei Technologies 299 Bantian, Longgang District 300 Shenzhen, Guangdong 518129 301 P.R.China 303 EMail: zhang.xian@huawei.com 305 Oscar Gonzalez de Dios 306 Telefonica 307 SPAIN 309 EMail: ogondio@tid.es