[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Routing Area Working Group                                      S. Hares
Internet-Draft                                   Hickory Hill Consulting
Intended status: Informational                         February 18, 2013
Expires: August 22, 2013


 Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network
              on Demand using Interface to Routing System
                   draft-hares-i2rs-use-case-vn-vc-00

Abstract

   Software Defined Networks (SDN) provide a way to virtualize and
   abstract the network and present the virtual or abstract resources to
   the third-party applications running in software.  The application
   can utilize a programmable interface to receiving these virtual or
   abstract resources in a form that allows monitoring or manipulation
   of resources.  Various programmatic interfaces have been proposed to
   interface directly to the forwarding plane (OpenFlow, ForCES), or do
   device configuration (NETCONF).  ALTO has proposed a informational
   interface to the application.  Only the progammatic Interface to the
   Routing System (IRS) provides an interface directly to the routing
   system to utilize all aspects of the routing system as a system.

   The IRS system interacts with the control plane processes to monitor
   best paths to any destination and to change the routing information
   base (RIB) or MPLS label information Base (LIB) which feeds the
   forwarding tables the information needed to actually switch traffic
   at a local level.

   This document outlines how SDN networks can use the IRS interface to
   implement an automated set of network services for Virtual Connection
   on Demand (VCoD) and Virtual Network on Demand (VNoD)

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."



Hares                    Expires August 22, 2013                [Page 1]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


   This Internet-Draft will expire on August 22, 2013.

Copyright Notice

   Copyright (c) 2013 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.



































Hares                    Expires August 22, 2013                [Page 2]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Virtual Circuit on Demand  . . . . . . . . . . . . . . . . . .  6
   4.  Virtual Network on Demand (VNoD) . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11









































Hares                    Expires August 22, 2013                [Page 3]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


1.  Introduction

   The Interface to the Routing System Framework [IRS] desribes a
   mechanism where the distributed control plane can be augmented by an
   outside control plane through an open, accessible interface,
   including the Routing Information Base (RIB) and the label interface
   (LIB) individual devices.  IRS provides a "halfway point" between
   completely replacing the traditional distributed control planes and
   directly configure devices via off-board processes.

   This draft proposes a set of use cases to use IRS mechanisms to
   implement a Software Defined Network (SDN) with virtual connections
   and virtual networks as automated services.  This document focuses on
   how IRS would support two automated network services: Virtual
   Connection on Demand (VCoD) and Virtual Network on Demand (VNoD).
   The SDN service provides the basic connection and a guidance ("self-
   help") functionality.

   This paper contains a background section, a use case for IRS in VCoD,
   and a use case for IRS in VNoD.

   SDN is a new adventure for the Internet space.  Each new adventure in
   the Internet space requires lots of use cases so that the IETF may
   determine the critical protocols.


2.  Background

   Applications and network layer flows have run independently since the
   Internet started in the late 1980s.  Provisioning of network
   servivces and big flows has been done by service providers statically
   or with proprietary.  Recently, new server and host technologies have
   increase application data traffic flows across the network.  With the
   advent of data center providers and cloud services, applications life
   cycles have shortened to weeks rather than years.  The need for fast
   automated provisioning of virtual network connections or quick
   provisioning of virtual private networks has increased.

   Software Defined Neworks have have three areas of challenge to
   provide such quick network services: a) how to control the network
   flows, b) interfaces to networks, and c) how do calculate where these
   network flows go.

   Network flows can be controlled at the forwarding device level or the
   network control plane level.  Various progammable interfaces have
   been proposed to provide control over individual forwarding devices.
   OpenFlow, for instance, provides a mechanism to replace the dynamic
   control plane processes on individual forwarding devices throughout a



Hares                    Expires August 22, 2013                [Page 4]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


   network with off box processes that interact with the forwarding
   tables on each device.  Another example is NETCONF, which provides a
   fast and flexible mechanism to interact with device configuration and
   policy.

   The tradeoff with the device level approach to control flows has to
   do with benefits and challenges of having control systems off-board.
   The benefit of off-board control systems is that the calculation unit
   can be centralized.  The challenge of the off-board control system
   has a technical challenge and a deployment challenge.  The technical
   challenge is that off-board control systems may encounter time-delays
   and communication failure.  The deployment issues concerns utilizing
   new protocols for this communication which may also have issues in
   deployment.  The promised benefits of off-board devices are reduction
   in operational costs, improving scaling, control, and visiblity.
   OpenFlow, for instance, provides a mechanism to replace the dynamic
   control plane processes on individual forwarding devices throughout a
   network with off box processes that interact with the forwarding
   tables on each device.  Another example is NETCONF, which provides a
   fast and flexible mechanism to interact with device configuration and
   policy.

   The Interface to Routing System (IRS) interface provides an interface
   to all aspects of the routing system as a system.  This interface
   allows the SDN approach to utilize the existing control plane
   software without changing it.  The IRS system interacts with the
   control plane processes to monitor best paths to any destination and
   to interact with the routing information base (RIB) or MPLS label
   information base (LIB) which feeds the forwarding tables the
   information needed to actually switch traffic at a local level.

   Let us turn to the next challenge, the interface to the applciations.

   Many academic efforts (e.g.  Internet) have examined the benefits in
   allowing applications to obtain more network information when making
   decisions on how connect webs of interfaces.  Recently, the IETF ALTO
   protocol has been charted to provide resource information for peer-
   to-peer applications.  Expansions to ALTO's application interface
   have been proposed to pass information regarding bandwidth and
   network topologies.  This ALTO work may apply to some large flow
   Virtual Connections or Virtual Private networks need.  However, these
   ALTO use cases do not necessarily consider the on-demand issues or
   IRS.  This document presents these use cases.

   This document describes a set of use cases which describe how
   automated creation of Virtual Connection on Demand (VCoD) and Virtual
   Networks On Demand (VNoD) based in SDN logic can be accomplished by
   using an interface to the routing system (IRS).



Hares                    Expires August 22, 2013                [Page 5]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


   There are several types of network services that can be considered as
   network services over which virtual connections or virtual networks
   can be created.  These network services include: optical, Ethernet
   (VLAN and SPB), Internet Protocol (IP), Multiprotocol Label Switching
   (MPLS).  Each of these networks can provide traffic engineered paths,
   olicy control (e.g.  Access control Lists (ACLs)), security services,
   or some form of virtual LAN services (VLAN, VxAN, L2/L3 VPN).  The
   examples in this document focus on the transport and VPN related
   services that can be abstracted into Virtual Connection (VC) and
   Virtual Network (VN).

   These abstract services (VC or VN) are logical services that can be
   mapped to specific services.  For example, a flow can be mapped to a
   flow such as OpenFlow might provision through a set of networks.  Or
   a Flow might be mapped to a TE-LSP.  These logical services provide a
   uniform abstract service model that allows applications to configure
   VC or VN services independent of the actual network technology
   implementing it.

   The use cases below leverage the SDN architecture and model and the
   IRS Frmewaork to implement Virtual Circuit on Demand (VCoD) and
   Virtual Network on Demand (VNoD).

   Please note that this draft builds on the premise that SDN solutions
   can augment rather than replace traditional distributed control
   planes.  Each use case is presented in its own section.


3.  Virtual Circuit on Demand

   The Virtual circuit on demand (VCoD) first needs to discover where
   the IRS commissioners acting as controllers are.  After selecting the
   IRS commissioner which will control the VCoD circuit, the application
   sends a requests to create, delete, modify or query circuits.  At
   this point, the IRS Controller takes these requests and performs the
   appropriate operations.  The discovery protocol and these
   communications are outside the IRS protocol and framework.  The
   protocol could be ALTO that informs application which IRS
   commissioner can support VCoD service.

   Once the IRS Commissioner is chartered with the task of setting up
   virtual circuits, the IRS Commission will communicate with the IRS
   Agents in the nodes (routing/switching/optial) to set-up these
   virtual circuits.  In the example topoology below, IRS Commissioner 1
   has received a request to set up a Virtual circuit from edge 1 to
   edge 2.  The IRS commmissioner works with the IRS Agent1 on node 1,
   the IRS Agent 2 on node 2, the IRS Agent 3 on node 3, and the IRS
   Agent 4 on node 4 to set up the virtual circuit.  IRS Commissioner 1



Hares                    Expires August 22, 2013                [Page 6]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


   is a VCoD capable IRS commissioner with logic to aid set-up,
   monitoring, changing, and decommissioning of this circuit.  IRS
   Agents 1-4 contain the necessary logic to translate the IRS
   Commissioner's commands to create the virtual circuit's link on their
   interface.

   The IRS framework defines the portion of this system that goes from
   the VCoD-capable IRS commissioner to/from the VCoD-capable IRS
   Agents.  The IRS Commissioner can request information from the IRS
   Agent such as topology or interface statics or available circuits,
   and influence how the IRS Agents create the circuits.  The topology
   information passed between the IRS commission and Agent would include
   for this application possible virtual connections to a destination
   and the available bandwidth on that circuit.  The interface
   statistics exchanged could involve historical or instant statistics
   on exit point performance, jitter, delay.  The available of circuits
   could involve any time-based availabilty for on-demand future usage.

   Past solutions in this area have included uses of device
   configuration across multiple nodes (SNMP or NETCONF based) with
   proprietary services combined with topology queries.  The lack of a
   coordinated responses to routing topology queries has created
   problems in quickly obtaining and configuring changes for Virtual
   Circuits.  New algorithms services in routing/switch such as Fast-
   Reroute of RSVP or IGPs have aided the automatic re-establishment of
   some circuits, but the complexity of some of these algorithms
   increases cost within the network elements.  It's often difficult to
   justify the added complexity in the database and algorithms of
   routing protools to solve what is considered a point case.

   The following things need to be supported for this application:

   o  IRS Agents should provide the ability to read the virtual
      connection topology database for the technology supported.  For
      optical, these are the optical connections and what node they
      connect to.  For MPLS, this is virtual circuit available, and what
      nodes they connect to.  For IP technologies, this could include
      the GRE tunnels and what interface it connects to.  For Ethernet
      circuits this should involve circuit type (e.g, point-to-point
      (p2p) or point-to-multipoint (p2mp)) and what nodes it can reach.

   o  IRS Agent should provide the ability to influence the
      configuration of a virtual circuit in a node.

   o  IRS Agent should provide monitor and provide statistics on the
      virtual connection to the IRS Commissioner.  The IRS commissioner
      can then determine if the connection falls below a quality level
      the application has requested.  If the IRS Commissioner does



Hares                    Expires August 22, 2013                [Page 7]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


      determine the circuit is below the required quality, it could
      create another circuit.  The IRS Commission may choose to create
      the second virtual circuit, transfer flows, and then break the
      first circuit.

   Example Topology for Virtual Circuit on Demand (VCoD).

                  -------------------------
                  | Application             |
                  ---------------------------
                   |                      |
                   |                      |
        +------------------+< Policy   +-------------------+< Policy
        |IRS Commissioner-1|< PCE info |IRS Commissioner-2 |< PCEP
        |VC controller     |           | VN controller     |
        +------------------+           +-------------------+
           |          |  |-----------+    |            |
           |          |              |    |            |
         +--------+ +--------+      +---------+  +----------+
         | IRS    | | IRS    |      | IRS     |  | IRS      |
         | Agent-1| |Agent-2 |      | Agent-3 |  | Agent-4  |
         |--------| |--------+      +---------+  +----------+
         | node 1 | | node 2 |      | node 3  |  | node 4   |
         +--------+ +--------+      +---------+  +----------+
            |  |        | |            |  |
        edge1  |--------| |------------|  |
                                          |----edge2



   While the set-up of these virtual circuits is possible with current
   technoloyg, the lack of the IRS-like framework makes VCoD network
   complex.  With this support, VCoD may be able to reduce complexity on
   the individual nodes.


4.  Virtual Network on Demand (VNoD)

   Virtual Networks on Demand (VNoD) are simply extensions to the
   Virtual Connections on Demand concept.  The IRS Commissioner is
   tasked to create a Virtual network instead of a single connection.

   The example sequence would be that the application discovers IRS
   Commission-2 who is a VNoD via a protocol outside the IRS framework
   (e.g.  ALTO).  The IRS Commissioner-2 works with the IRS AGents 1-4
   to set-up a virtual network.  This involves the following:





Hares                    Expires August 22, 2013                [Page 8]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


   o  gathering potential topology information (in order to create the
      network,

   o  set-up the virtual network (via influencing configurations on
      node),

   o  monitoring changes in topology (in order to potential failovers,

   o  influencing changes to virtual network via configurations, and

   o  removing the virtual network after the demand has epxired.


           --------------------------
                  | Application             |
                  ---------------------------
                   |                      |
                   |                      |
        +------------------+< Policy   +-------------------+< Policy
        |IRS Commissioner-1|< PCE info |IRS Commissioner-2 |< PCEP
        |VC controller     |           | VN controller     |
        +------------------+           +-------------------+
                                        | |  |       |
           |----------------------------+ |  |       |
           |            +------------------  |       |
           |            |                    |       |
         +--------+ +--------+      +---------+  +----------+
         | IRS    | | IRS    |      | IRS     |  | IRS      |
         | Agent-1| |Agent-2 |      | Agent-3 |  | Agent-4  |
         |--------| |--------+      +---------+  +----------+
         | node 1 | | node 2 |      | node 3  |  | node 4   |
         +--------+ +--------+      +---------+  +----------+
            |  |        | |            |  | |      |  |
            |  |--------| |------------|  | +------+  |-end-point-3
            |                             |           |
        end-point-1                       |
                                          |----end-point2


   This topology shares some configuration needs with the central
   membership computation for MPLS VPNs from (draft-white-irs-use-cases)
   but the mechanisms are not specific to MPlS VPNS.


5.  IANA Considerations

   This document includes no request to IANA.




Hares                    Expires August 22, 2013                [Page 9]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


6.  Security Considerations

   This document has no security issues as just contains use cases.


7.  Normative References

   [I-D.amante-irs-topology-use-cases]
              Amante, S., Medved, J., and T. Nadeau, "Topology API Use
              Cases", draft-amante-irs-topology-use-cases-00 (work in
              progress), October 2012.

   [I-D.atlas-irs-policy-framework]
              Atlas, A., Hares, S., and J. Halpern, "A Policy Framework
              for the Interface to the Routing System",
              draft-atlas-irs-policy-framework-00 (work in progress),
              September 2012.

   [I-D.atlas-irs-problem-statement]
              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Problem Statement",
              draft-atlas-irs-problem-statement-00 (work in progress),
              July 2012.

   [I-D.bernstein-alto-large-bandwidth-cases]
              Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth
              Query and Control of Core Networks",
              draft-bernstein-alto-large-bandwidth-cases-02 (work in
              progress), July 2012.

   [I-D.medved-irs-topology-requirements]
              Medved, J., Gredler, H., Previdi, S., and S. Amante,
              "Topology API Requirements",
              draft-medved-irs-topology-requirements-00 (work in
              progress), October 2012.

   [I-D.rfernando-irs-framework-requirement]
              Fernando, R., Medved, J., Ward, D., Atlas, A., and B.
              Rijsman, "IRS Framework Requirements",
              draft-rfernando-irs-framework-requirement-00 (work in
              progress), October 2012.

   [I-D.ward-irs-framework]
              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Framework", draft-ward-irs-framework-00
              (work in progress), July 2012.

   [I-D.white-irs-use-case]



Hares                    Expires August 22, 2013               [Page 10]


Internet-Draft           IRS Use Cases VCoD VNoD           February 2013


              White, R., Hares, S., and R. Fernando, "Use Cases for an
              Interface to the Routing System",
              draft-white-irs-use-case-00 (work in progress),
              September 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Author's Address

   Susan Hares
   Hickory Hill Consulting
   7453 Hickory Hill
   Saline, CA  48176
   USA

   Email: shares@ndzh.com

































Hares                    Expires August 22, 2013               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/