idnits 2.17.1 draft-mattson-irs-usecase-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 475 lines 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (November 5, 2012) is 4183 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'KEYWORDS' is defined on line 335, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT G. Mattson 3 Intended Status: Informational T. Nadeau 4 Expires: May 5, 2013 Juniper Networks 5 November 5, 2012 7 IRS Use Case for IP and Transport Workflows 8 draft-mattson-irs-usecase-00 10 Abstract 12 This document describes use-cases for IRS to provide a lightweight 13 method for common management and control state for typical operations 14 and workflows of multilayer networks involving both IP and sub-IP 15 transport. IRS provides a lightweight, streaming interface between 16 routing systems and external applications. By extending the IRS model 17 to transport systems, multi-layer networks can be managed and used 18 more efficiently. IRS may enable the integration of IP and transport 19 maintenance workflows leading to a reduction in operational costs. 20 IRS server having visibility into both Optical Transport and IP 21 domains will also be able to make optimal use of transport 22 infrastructure. 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 May 7, 2013. 41 Copyright Notice 43 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. IRS Agent Enhancements . . . . . . . . . . . . . . . . . . . . 4 61 2.1 Routing changes to degraded optical paths . . . . . . . . . 4 62 2.2 Fast path routing changes to degraded paths . . . . . . . . 5 63 2.3 Simplified management . . . . . . . . . . . . . . . . . . . 5 64 3 Interface to transmission system. . . . . . . . . . . . . . . . 6 65 3.1 Direct Mode . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2 Indirect Mode . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 72 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The following is a use case for IRS as a dynamic, multi-layer, 77 policy-based routing service. IP routers have very sophisticated 78 policy and routing capabilities that allow them to manage aggregate 79 traffic flows dynamically based on changing network conditions. But 80 the state of transport paths tends to be viewed by routing systems in 81 a binary fashion as being up or down. Thus, despite the policy and 82 routing intelligence of the router, the decision it makes about a 83 transport path is often very simple: to route traffic over it or to 84 route traffic away from it. 86 But a transport path may be in a state where it is degraded but still 87 capable of bearing traffic. Consider the case of a path with a high, 88 pre-FEC BER. The FEC is able to eliminate bit errors from reaching 89 the router but the Pre-FEC BER may be predictive of an imminent 90 failure. If a failure does occur, flows for applications using the 91 link will be impacted until a recovery occurs and packets may be 92 delayed or dropped. In such a case, the best policy may be to 93 preemptively route away from the degraded path those flows that 94 emanate from loss-sensitive and delay-sensitive applications. In this 95 way, if the failure does occur, loss and delay sensitive applications 96 will not be impacted. Alternatively, it may be advantageous to raise 97 the IGP or path computation cost metric of the degraded path. In this 98 way, traffic will be routed away from the degraded path unless no 99 other path is available. 101 In many cases, an application with visibility of both IP and Optical 102 domains through an IRS server could make better decisions about how 103 to manage traffic flows traversing the network. 105 The goal of this use case is not to specify an all-encompassing 106 system that would replace the NMS or craft interface of the transport 107 system as well as the CLI/Netconf/SNMP interface and IP control plane 108 of the router. The goal is rather to provide a means to automate 109 typical workflows that operate over a router and transport system 110 without interfering with the existing management and control plane 111 systems. 113 These workflows would be facilitated by a standardized IRS interface. 114 Traditional network/element management systems and methods including 115 TL1, SNMP, Netconf/CLI and proprietary interfaces may still be used 116 for exceptional conditions. In this way, the bulk of operational 117 tasks can be automated over a range of vendor equipment and the 118 maintenance burden may be significantly reduced. Perhaps more 119 importantly, the IRS server can orchestrate complex, policy-based 120 changes to flow paths as a result of changes in the optical domain. 121 Optical paths may be run more efficiently and with lower margin 122 without propagating route flaps in the IP domain. Similarly, IRS 123 could coordinate dynamic and on-demand coordination of routing 124 changes to provisioning of optical paths. 126 1.2. Acronyms 128 BER Bit Error Rate 130 CD Chromatic Dispersion. 132 CLI Command Line Interface. 134 OSNR Optical Signal to Noise Ratio. 136 PMD Polarization Mode Dispersion. 138 TL1 Transaction Language 1. 140 2. IRS Agent Enhancements 142 IRS agents have been proposed as a means to programmatically inject 143 routes into routers and to stream information from them. It would be 144 useful to also have the IRS agents on transport equipment such as 145 transponders, wave selective switches, optical cross connects and 146 amplifiers. The IRS agents would provide data to the IRS server and 147 on to an application. The application could make intelligent 148 decisions about how to direct flows by using realtime information 149 about the state of the optical domain. Basic troubleshooting and 150 provisioning between the router and the transmission equipment could 151 be accomplished through the same programmatic. In this way, IRS would 152 support automation of management, recovery and dynamic bandwidth 153 allocation. 155 2.1 Routing changes to degraded optical paths 157 Consider the case of an external transponder and a router interface. 158 The line side may have a variety of parameters showing that the 159 optical path is either degraded or in the process of becoming 160 degraded. The transponder will have indications of decreasing OSNR 161 due to CD, PMD, or even non-linear errors. With post-processing the 162 BER may be kept low enough to avoid the line being taken down. But an 163 increasing error rate may indicate a likelihood of imminent failure. 164 Under this assumption, there are several different ways that the IRS 165 server could react: the IRS server may be able to shift traffic away 166 from such a link before it fails and thus avoid packet loss; It may 167 also be useful for the IRS server to shift critical flows away from a 168 link that may be likely to fail but allow best effort traffic to run 169 over it; Or it may be acceptable to raise the routing metrics of 170 such a link so that other paths will be preferred if they are 171 available. 173 2.2 Fast path routing changes to degraded paths 175 Because IRS can install state in both the router and the transmission 176 domain, it is can be used to set up compatible behavior between 177 transmission OAM and the routing system. For example, in the example 178 above, assuming a grey interface between the router and transmission 179 system, IRS could map changes in metrics referring to optical 180 impairments to G.709 or Ethernet OAM indications to be propagated 181 back to the router. The router would then have predefined actions to 182 react most appropriately to the flavor of fault that the transmission 183 network element has been configured to monitor. 185 These examples are relatively simplistic. It is possible that the 186 correct behavior is much more complex than has just been described. 187 As with many softwaredefined networking initiatives, the real 188 applications will ultimately be developed after the mechanisms are 189 available. The key is that IRS can use information about the optical 190 domain to influence traffic in the packet domain based on the 191 policies of the network administrator. 193 This model can also be extended to include basic provisioning tasks. 194 It is possible to use IRS to control basic path parameters such as 195 channel assignments and power levels. IRS could also provide basic 196 information about the transponder such as the state of the each of 197 the channels and the presence of alarms. In this way, IRS could 198 provide a basic management interface that could be used to provision 199 and monitor the transponder. 201 Putting together this management plane integration with the 202 visibility between the routing and optical domain, the router and 203 external transponder would have many of the advantages of a 204 transponder integrated in a router. Some of the important benefits of 205 actual integration- unified management and faster recovery- would be 206 provided by means of this virtual integration method. At the same 207 time, the operator would be able to choose the most appropriate 208 combination of router/switch and optical transmission gear based on 209 cost, technology curve, availability, etc. 211 In the case where a router is supporting "black links" as per 212 G.698.2, IRS may also provide useful means to extract link property 213 parameters from network element and to correlate them for a path. 214 Although, this is not the primary motivation for extension of IRS to 215 transmission networks, it is also worth considering. 217 2.3 Simplified management 219 In transport networks today, a variety of interfaces are supported 220 for the provisioning and management of the network elements including 221 TL1, SNMP, CLI and other standard and proprietary methods. The 222 diversity of these protocols raises the burden of software 223 development for automation tools especially in networks where the 224 equipment from multiple vendors is installed. Yet replacing these 225 methods is unrealistic. 227 What is needed is a common interface for a subset of functions 228 related to common workflows. This interface can be standardized 229 across heterogeneous products including routers, switches, 230 transponders, cross-connects, and amplifiers. IRS is a good candidate 231 for this. 233 An IRS Agent could manage simple operations on the switch in a 234 consistent way. 236 3 Interface to transmission system. 238 There are three modes of access between IRS and the transport system. 239 These three modes are called Direct Mode, Indirect Mode and Hybrid 240 Mode. These modes correspond to whether the IRS agent is logically 241 integrated with the NMS/EMS or the transmission network element or 242 both. In direct mode, the IRS agent is logically associated with the 243 network element. The IRS server can access the network element 244 directly. In indirect mode the IRS server has access to the NMS/EMS 245 system of a transport network. It is possible for either direct or 246 indirect mode to be used independently. Hybrid mode refers to the 247 case where both direct and indirect modes are used simultaneously. 249 3.1 Direct Mode 251 In this mode, the IRS server communicates directly with transport 252 network elements. IRS bypasses whatever NMS or EMS is in place. An 253 IRS agent resides on the transport network element. This method has 254 the advantage of allowing simple and direct access to the Transport 255 Network Elements. Proprietary NMS/EMS systems may still be used and 256 do not need to be integrated into the IRS architecture. Problems need 257 to be considered such as how the NMS/EMS system is synchronizes with 258 changes that committed by the IRS server. 260 +----------------+ 261 | IRS Server | 262 +----------------+ 263 ^ ^ 264 IRS * * 265 ************************ * ************************* 266 * * * 267 +------------+ * +------------+ * 268 | Control | * | NMS/EMS | * 269 | Plane | * | | * 270 +------------+ * +------------+ * 271 ^ * IRS ^ | * IRS 272 | * | | * 273 | * | | * 274 | * | | * 275 V V V V V 276 +------------------+ +----------------+ +------------+ 277 |IP Network Element| | IRS Agent | | IRS Agent | 278 | |<------>| Transport NE |<>| Tprt NE | 279 +------------------+ +----------------+ +------------+ 281 3.2 Indirect Mode 283 In this mode, IRS server interfaces with an EMS or NMS system. The 284 IRS agent functionality resides within the NMS/EMS and serves as a 285 proxy to the network elements. This mode has the advantage that the 286 NMS/EMS can abstract or virtualize the transport elements. The 287 NMS/EMS system can easily remain synchronized with the IRS server. 289 +----------------+ 290 | IRS Server | 291 +----------------+ 292 ^ ^ 293 IRS * * IRS 294 ************************ * ************* 295 V V 296 +-------------+ +------------+ 297 | IRS Agent | | IRS Agent | 298 |Control Plane| | NMS/EMS | 299 +-------------+ +------------+ 300 ^ ^ ^ 301 | | | 302 | | | 303 | | | 304 V V V 305 +------------------+ +----------------+ +---------------+ 306 |IP Network Element| | Transport | |Transport | 307 | |<------>| Network Element|<>|Network Element| 308 +------------------+ +----------------+ +---------------+ 310 4. Conclusion 312 IRS is a promising means to provide a programmatic interface to 313 routing systems. By extending this capability to transmission 314 networks, IRS would be even more useful. Common maintenance tasks may 315 be automated and network control can be exerted with a view of both 316 IP and Optical domains. As advances in optical networking such as 317 coherent detection and post-processing increase the agility of these 318 networks, IP-integrated, programmatic control and visibility will 319 become even more useful. 321 6. Acknowledgements The authors wish to thank Shane Amante for his 322 contributions to this document. 324 7. IANA Considerations 326 This document does not raise any particular IANA considerations. 328 8. Security Considerations 330 This document does not by itself raise any particular security 331 considerations. 333 9. Normative References 335 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 Authors Addresses 340 Geoffrey Mattson 341 Juniper Networks 342 1194 N. Matilda Ave, Sunnyvale, CA, 344 Email: gmattson@juniper.net 346 Tom Nadeau 347 Juniper Networks 348 1194 N. Matilda Ave, Sunnyvale, CA, 350 Email: tnadeau@juniper.net