IRS Use Case for IP and Transport Workflows

Versions: 00                                                            
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


   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

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

   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
   ( 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

   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

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

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

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,


   Tom Nadeau
   Juniper Networks
   1194 N. Matilda Ave, Sunnyvale, CA,