INTERNET-DRAFT G. Mattson Intended Status: Informational T. Nadeau Expires: May 5, 2013 Juniper Networks November 5, 2012 IRS Use Case for IP and Transport Workflows draft-mattson-irs-usecase-00 Abstract This document describes use-cases for IRS to provide a lightweight method for common management and control state for typical operations and workflows of multilayer networks involving both IP and sub-IP transport. IRS provides a lightweight, streaming interface between routing systems and external applications. By extending the IRS model to transport systems, multi-layer networks can be managed and used more efficiently. IRS may enable the integration of IP and transport maintenance workflows leading to a reduction in operational costs. IRS server having visibility into both Optical Transport and IP domains will also be able to make optimal use of transport infrastructure. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IRS Agent Enhancements . . . . . . . . . . . . . . . . . . . . 4 2.1 Routing changes to degraded optical paths . . . . . . . . . 4 2.2 Fast path routing changes to degraded paths . . . . . . . . 5 2.3 Simplified management . . . . . . . . . . . . . . . . . . . 5 3 Interface to transmission system. . . . . . . . . . . . . . . . 6 3.1 Direct Mode . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Indirect Mode . . . . . . . . . . . . . . . . . . . . . . . 7 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The following is a use case for IRS as a dynamic, multi-layer, policy-based routing service. IP routers have very sophisticated policy and routing capabilities that allow them to manage aggregate traffic flows dynamically based on changing network conditions. But the state of transport paths tends to be viewed by routing systems in a binary fashion as being up or down. Thus, despite the policy and routing intelligence of the router, the decision it makes about a transport path is often very simple: to route traffic over it or to route traffic away from it. But a transport path may be in a state where it is degraded but still capable of bearing traffic. Consider the case of a path with a high, pre-FEC BER. The FEC is able to eliminate bit errors from reaching the router but the Pre-FEC BER may be predictive of an imminent failure. If a failure does occur, flows for applications using the link will be impacted until a recovery occurs and packets may be delayed or dropped. In such a case, the best policy may be to preemptively route away from the degraded path those flows that emanate from loss-sensitive and delay-sensitive applications. In this way, if the failure does occur, loss and delay sensitive applications will not be impacted. Alternatively, it may be advantageous to raise the IGP or path computation cost metric of the degraded path. In this way, traffic will be routed away from the degraded path unless no other path is available. In many cases, an application with visibility of both IP and Optical domains through an IRS server could make better decisions about how to manage traffic flows traversing the network. The goal of this use case is not to specify an all-encompassing system that would replace the NMS or craft interface of the transport system as well as the CLI/Netconf/SNMP interface and IP control plane of the router. The goal is rather to provide a means to automate typical workflows that operate over a router and transport system without interfering with the existing management and control plane systems. These workflows would be facilitated by a standardized IRS interface. Traditional network/element management systems and methods including TL1, SNMP, Netconf/CLI and proprietary interfaces may still be used for exceptional conditions. In this way, the bulk of operational tasks can be automated over a range of vendor equipment and the maintenance burden may be significantly reduced. Perhaps more importantly, the IRS server can orchestrate complex, policy-based changes to flow paths as a result of changes in the optical domain. Optical paths may be run more efficiently and with lower margin without propagating route flaps in the IP domain. Similarly, IRS could coordinate dynamic and on-demand coordination of routing changes to provisioning of optical paths. 1.2. Acronyms BER Bit Error Rate CD Chromatic Dispersion. CLI Command Line Interface. OSNR Optical Signal to Noise Ratio. PMD Polarization Mode Dispersion. TL1 Transaction Language 1. 2. IRS Agent Enhancements IRS agents have been proposed as a means to programmatically inject routes into routers and to stream information from them. It would be useful to also have the IRS agents on transport equipment such as transponders, wave selective switches, optical cross connects and amplifiers. The IRS agents would provide data to the IRS server and on to an application. The application could make intelligent decisions about how to direct flows by using realtime information about the state of the optical domain. Basic troubleshooting and provisioning between the router and the transmission equipment could be accomplished through the same programmatic. In this way, IRS would support automation of management, recovery and dynamic bandwidth allocation. 2.1 Routing changes to degraded optical paths Consider the case of an external transponder and a router interface. The line side may have a variety of parameters showing that the optical path is either degraded or in the process of becoming degraded. The transponder will have indications of decreasing OSNR due to CD, PMD, or even non-linear errors. With post-processing the BER may be kept low enough to avoid the line being taken down. But an increasing error rate may indicate a likelihood of imminent failure. Under this assumption, there are several different ways that the IRS server could react: the IRS server may be able to shift traffic away from such a link before it fails and thus avoid packet loss; It may also be useful for the IRS server to shift critical flows away from a link that may be likely to fail but allow best effort traffic to run over it; Or it may be acceptable to raise the routing metrics of such a link so that other paths will be preferred if they are available. 2.2 Fast path routing changes to degraded paths Because IRS can install state in both the router and the transmission domain, it is can be used to set up compatible behavior between transmission OAM and the routing system. For example, in the example above, assuming a grey interface between the router and transmission system, IRS could map changes in metrics referring to optical impairments to G.709 or Ethernet OAM indications to be propagated back to the router. The router would then have predefined actions to react most appropriately to the flavor of fault that the transmission network element has been configured to monitor. These examples are relatively simplistic. It is possible that the correct behavior is much more complex than has just been described. As with many softwaredefined networking initiatives, the real applications will ultimately be developed after the mechanisms are available. The key is that IRS can use information about the optical domain to influence traffic in the packet domain based on the policies of the network administrator. This model can also be extended to include basic provisioning tasks. It is possible to use IRS to control basic path parameters such as channel assignments and power levels. IRS could also provide basic information about the transponder such as the state of the each of the channels and the presence of alarms. In this way, IRS could provide a basic management interface that could be used to provision and monitor the transponder. Putting together this management plane integration with the visibility between the routing and optical domain, the router and external transponder would have many of the advantages of a transponder integrated in a router. Some of the important benefits of actual integration- unified management and faster recovery- would be provided by means of this virtual integration method. At the same time, the operator would be able to choose the most appropriate combination of router/switch and optical transmission gear based on cost, technology curve, availability, etc. In the case where a router is supporting "black links" as per G.698.2, IRS may also provide useful means to extract link property parameters from network element and to correlate them for a path. Although, this is not the primary motivation for extension of IRS to transmission networks, it is also worth considering. 2.3 Simplified management In transport networks today, a variety of interfaces are supported for the provisioning and management of the network elements including TL1, SNMP, CLI and other standard and proprietary methods. The diversity of these protocols raises the burden of software development for automation tools especially in networks where the equipment from multiple vendors is installed. Yet replacing these methods is unrealistic. What is needed is a common interface for a subset of functions related to common workflows. This interface can be standardized across heterogeneous products including routers, switches, transponders, cross-connects, and amplifiers. IRS is a good candidate for this. An IRS Agent could manage simple operations on the switch in a consistent way. 3 Interface to transmission system. There are three modes of access between IRS and the transport system. These three modes are called Direct Mode, Indirect Mode and Hybrid Mode. These modes correspond to whether the IRS agent is logically integrated with the NMS/EMS or the transmission network element or both. In direct mode, the IRS agent is logically associated with the network element. The IRS server can access the network element directly. In indirect mode the IRS server has access to the NMS/EMS system of a transport network. It is possible for either direct or indirect mode to be used independently. Hybrid mode refers to the case where both direct and indirect modes are used simultaneously. 3.1 Direct Mode In this mode, the IRS server communicates directly with transport network elements. IRS bypasses whatever NMS or EMS is in place. An IRS agent resides on the transport network element. This method has the advantage of allowing simple and direct access to the Transport Network Elements. Proprietary NMS/EMS systems may still be used and do not need to be integrated into the IRS architecture. Problems need to be considered such as how the NMS/EMS system is synchronizes with changes that committed by the IRS server. +----------------+ | IRS Server | +----------------+ ^ ^ IRS * * ************************ * ************************* * * * +------------+ * +------------+ * | Control | * | NMS/EMS | * | Plane | * | | * +------------+ * +------------+ * ^ * IRS ^ | * IRS | * | | * | * | | * | * | | * V V V V V +------------------+ +----------------+ +------------+ |IP Network Element| | IRS Agent | | IRS Agent | | |<------>| Transport NE |<>| Tprt NE | +------------------+ +----------------+ +------------+ 3.2 Indirect Mode In this mode, IRS server interfaces with an EMS or NMS system. The IRS agent functionality resides within the NMS/EMS and serves as a proxy to the network elements. This mode has the advantage that the NMS/EMS can abstract or virtualize the transport elements. The NMS/EMS system can easily remain synchronized with the IRS server. +----------------+ | IRS Server | +----------------+ ^ ^ IRS * * IRS ************************ * ************* V V +-------------+ +------------+ | IRS Agent | | IRS Agent | |Control Plane| | NMS/EMS | +-------------+ +------------+ ^ ^ ^ | | | | | | | | | V V V +------------------+ +----------------+ +---------------+ |IP Network Element| | Transport | |Transport | | |<------>| Network Element|<>|Network Element| +------------------+ +----------------+ +---------------+ 4. Conclusion IRS is a promising means to provide a programmatic interface to routing systems. By extending this capability to transmission networks, IRS would be even more useful. Common maintenance tasks may be automated and network control can be exerted with a view of both IP and Optical domains. As advances in optical networking such as coherent detection and post-processing increase the agility of these networks, IP-integrated, programmatic control and visibility will become even more useful. 6. Acknowledgements The authors wish to thank Shane Amante for his contributions to this document. 7. IANA Considerations This document does not raise any particular IANA considerations. 8. Security Considerations This document does not by itself raise any particular security considerations. 9. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors Addresses Geoffrey Mattson Juniper Networks 1194 N. Matilda Ave, Sunnyvale, CA, Email: gmattson@juniper.net Tom Nadeau Juniper Networks 1194 N. Matilda Ave, Sunnyvale, CA, Email: tnadeau@juniper.net