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

Versions: 00 01

Internet Engineering Task Force                                S. Amante
Internet-Draft                              Level 3 Communications, Inc.
Intended status: Informational                                 J. Medved
Expires: August 16, 2013                                      S. Previdi
                                                     Cisco Systems, Inc.
                                                               T. Nadeau
                                                        Juniper Networks
                                                       February 12, 2013


                         Topology API Use Cases
                draft-amante-i2rs-topology-use-cases-00

Abstract

   This document describes use cases for gathering routing, forwarding
   and policy information, (hereafter referred to as topology
   information), about the network.  It describes several applications
   that need to view the topology of the underlying physical or logical
   network.  This document further demonstrates a need for a "Topology
   Manager" and related functions that collects topology data from
   network elements and other data sources, coalesces the collected data
   into a coherent view of the overall network topology, and normalizes
   the network topology view for use by clients -- namely, applications
   that consume topology information.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 August 16, 2013.



Amante, et al.           Expires August 16, 2013                [Page 1]


Internet-Draft           Topology API Use Cases            February 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Statistics Collection  . . . . . . . . . . . . . . . . . .  5
     1.2.  Inventory Collection . . . . . . . . . . . . . . . . . . .  5
     1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Orchestration, Collection & Presentation Framework . . . . . .  7
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Topology Manager . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Policy Manager . . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Orchestration Manager  . . . . . . . . . . . . . . . . . . 10
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Virtualized Views of the Network . . . . . . . . . . . . . 12
       4.1.1.  Capacity Planning and Traffic Engineering  . . . . . . 12
       4.1.2.  Services Provisioning  . . . . . . . . . . . . . . . . 15
       4.1.3.  Troubleshooting & Monitoring . . . . . . . . . . . . . 15
     4.2.  Path Computation Element (PCE) . . . . . . . . . . . . . . 16
     4.3.  ALTO Server  . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20









Amante, et al.           Expires August 16, 2013                [Page 2]


Internet-Draft           Topology API Use Cases            February 2013


1.  Introduction

   In today's networks, a variety of applications, such as Traffic
   Engineering, Capacity Planning, Security Auditing or Services
   Provisioning (for example, Virtual Private Networks), have a common
   need to acquire and consume network topology information.
   Unfortunately, all of these applications are (typically) vertically
   integrated: each uses its own proprietary normalized view of the
   network and proprietary data collectors, interpreters and adapters,
   which speak a variety of protocols, (SNMP, CLI, SQL, etc.) directly
   to network elements and to back-office systems.  While some of the
   topological information can be distributed using routing protocols,
   unfortunately it is not desirable for some of these applications to
   understand or participate in routing protocols.

   This approach is incredibly inefficient for several reasons.  First,
   developers must write duplicate 'network discovery' functions, which
   then become challenging to maintain over time, particularly as/when
   new equipment are first introduced to the network.  Second, since
   there is no common "vocabulary" to describe various components in the
   network, such as physical links, logical links, or IP prefixes, each
   application has its own data model.  To solve this, some solutions
   have distributed this information in the normalized form of routing
   distribution.  However, this information still does not contain
   "inactive" topological information, thus not containing information
   considered to be part of a network's inventory.

   These limitations lead to applications being unable to easily
   exchange information with each other.  For example, applications
   cannot share changes with each other that are (to be) applied to the
   physical and/or logical network, such as installation of new physical
   links, or deployment of security ACL's.  Each application must
   frequently poll network elements and other data sources to ensure
   that it has a consistent representation of the network so that it can
   carry out its particular domain-specific tasks.  In other cases,
   applications that cannot speak routing protocols must use proprietary
   CLI or other management interfaces which represent the topological
   information in non-standard formats or worse, semantic models.

   Overall, the software architecture described above at best results in
   incredibly inefficient use of both software developer resources and
   network resources, and at worst, it results in some applications
   simply not having access to this information.

   Figure 1 is an illustration of how individual applications collect
   data from the underlying network.  Applications retrieve inventory,
   network topology, state and statistics information by communicating
   directly with underlying Network Elements as well as with



Amante, et al.           Expires August 16, 2013                [Page 3]


Internet-Draft           Topology API Use Cases            February 2013


   intermediary proxies of the information.  In addition, applications
   transmit changes required of a Network Element's configuration and/or
   state directly to individual Network Elements, (most commonly using
   CLI or Netconf).  It is important to note that the "data models" or
   semantics of this information contained within Network Elements are
   largely proprietary with respect to most configuration and state
   information, hence why a proprietary CLI is often the only choice to
   reflect changes in a NE's configuration or state.  This remains the
   case even when standards-based mechanisms such as Netconf are used
   which provide a standard syntax model, but still often lack due to
   the proprietary semantics associated with the internal representation
   of the information.

                               +---------------+
                            +----------------+ |
                            |  Applications  |-+
                            +----------------+
                                  ^  ^  ^
              SQL, RPC, ReST      #  |  *    SQL, RPC, ReST ...
           ########################  |  ************************
           #                         |                         *
     +------------+                  |                   +------------+
     | Statistics |                  |                   | Inventory  |
     | Collection |                  |                   | Collection |
     +------------+                  |                   +------------+
           ^                         | NETCONF, I2RS, SNMP,    ^
           |                         | CLI, TL1, ...           |
           +-------------------------+-------------------------+
           |                         |                         |
           |                         |                         |
   +----------------+        +----------------+       +----------------+
   | Network Element|        | Network Element|       | Network Element|
   | +------------+ |<-LLDP->| +------------+ |<-LMP->| +------------+ |
   | | Data Model | |        | | Data Model | |       | | Data Model | |
   | +------------+ |        | +------------+ |       | +------------+ |
   +----------------+        +----------------+       +----------------+

               Figure 1: Applications getting topology data

   Figure 1 shows how current management interfaces such as NETCONF,
   SNMP, CLI, etc. are used to transmit or receive information to/from
   various Network Elements.  The figure also shows that protocols such
   as LLDP and LMP participate in topology discovery, specifically to
   discover adjacent network elements.

   The following sections describe the "Statistics Collection" and
   "Inventory Collection" functions.




Amante, et al.           Expires August 16, 2013                [Page 4]


Internet-Draft           Topology API Use Cases            February 2013


1.1.  Statistics Collection

   In Figure 1, "Statistics Collection" is a dedicated infrastructure
   that collects statistics from Network Elements.  It periodically
   polls Network Elements (for example, every 5-minutes) for octets
   transferred per interface, per LSP, etc.  Collected statistics are
   stored and collated, (for example, to provide hourly, daily, weekly
   95th-percentile figures), within the statistics data warehouse.
   Applications typically query the statistics data warehouse rather
   than poll Network Elements directly to get the appropriate set of
   link utilization figures for their analysis.

1.2.  Inventory Collection

   "Inventory Collection" is a network function responsible for
   collecting network element component and state (i.e.: interface up/
   down, SFP/XFP optics inserted into physical port, etc.) information
   directly from network elements, as well as storing inventory
   information about physical network assets that are not retrievable
   from network elements, (hereafter referred to as a inventory asset
   database).  Inventory Collection from network elements commonly use
   SNMP and CLI to acquire inventory information.  The information
   housed in the Inventory Manager is retrieved by applications using a
   variety of protocols: SQL, RPC, etc.  Inventory information,
   retrieved from Network Elements, is updated in the Inventory
   Collection system on a periodic basis to reflect changes in the
   physical and/or logical network assets.  The polling interval to
   retrieve updated information is varied depending on scaling
   constraints of the Inventory Collection systems and expected
   intervals at which changes to the physical and/or logical assets are
   expected to occur.

   Examples of changes in network inventory that need be learned by the
   Inventory Collection function are as follows:

   o  Discovery of new Network Elements.  These elements may or may not
      be actively used in the network (i.e.: provisioned but not yet
      activated).

   o  Insertion or removal of line cards or other modules, i.e.: optics
      modules, during service or equipment provisioning.

   o  Changes made to a specific Network Element through a management
      interface by a field technician.

   o  Indication of an NE's physical location and associated cable run
      list, at the time of installation.




Amante, et al.           Expires August 16, 2013                [Page 5]


Internet-Draft           Topology API Use Cases            February 2013


   o  Insertion of removal of cables that result in dynamic discovery of
      a new or lost adjacent neighbor, etc.

1.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119]


2.  Terminology

   The following briefly defines some of the terminology used within
   this document.

   Inventory Manager:  Describes a function of collecting network
      element inventory and state information directly from network
      elements, and potentially associated offline inventory databases,
      via standards-based data models.  Components contained in this
      super set might be visible or invisible to a specific network
      layer, i.e.: a physical link is visible within the IGP, however
      the Layer-2 switch through which the physical link traverses is
      unknown to the Layer-3 IGP. .

   Policy Manager:  Describes a function of attaching metadata to
      network components/attributes.  Such metadata is likely to include
      security, routing, L2 VLAN ID, IP numbering, etc. policies that
      enable the Topology Manager to: a) assemble a normalized view of
      the network for clients to access; b) allow clients (or, upper-
      layer applications) access to information collected from various
      network layers and/or network components, etc.  The Policy Manager
      function may be a sub-component of the Topology Manager or it may
      be a standalone.  This will be determined as the work with I2RS
      evolves.

   Topology Manager:  Network components (inventory, etc.) are retrieved
      from the Inventory Manager and synthesized with information from
      the Policy Manager into cohesive, normalized views of network
      layers.  The Topology Manager exposes normalized views of the
      network via standards-based data models to Clients, or higher-
      layer applications, to act upon in a read-only and/or read-write
      fashion.  The Topology Manager may also push information back into
      the Inventory Manager and/or Network Elements to execute changes
      to the network's behavior, configuration or state.







Amante, et al.           Expires August 16, 2013                [Page 6]


Internet-Draft           Topology API Use Cases            February 2013


   Orchestration Manager:  Describes a function of stitching together
      resources (i.e.: compute, storage) and/or services with the
      network or vice-versa.  The Orchestration Manager relies on the
      capabilities provided by the other "Managers" listed above in
      order to realize a complete service.

   Normalized Topology Data Model:  A data model that is constructed and
      represented using an open, standards-based model that is
      consistent between implementations.

   Data Model Abstraction:  The notion that one is able to represent the
      same set of elements in a data model at different levels of
      "focus" in order to limit the amount of information exchanged in
      order to convey this information.

   Multi-Layer Topology:  Topology is commonly referred to using the OSI
      protocol layering model.  For example, Layer 3 represents routed
      topologies that typically use IPv4 or IPv6 addresses.  It is
      envisioned that, eventually, multiple layers of the network may be
      represented in a single, normalized view of the network to certain
      applications, (i.e.: Capacity Planning, Traffic Engineering, etc.)

   Network Element (NE):  refers to a network device that typically is
      addressable (but not always), or a host.  It is sometimes referred
      to as a 'Node'.

   Links:  Every NE contains at least 1 link.  These are used to connect
      the NE to other NEs in the network.  Links may be in a variety of
      states including up, down, administratively down, internally
      testing, or dormant.  Links are often synonymous with network
      ports on NEs.


3.  Orchestration, Collection & Presentation Framework

3.1.  Overview

   Section 1 demonstrates the need for a network function that would
   provide a common, standard-based topology view to applications.  Such
   topology collection/management/presentation function would be a part
   wider framework, that would also include policy management and
   orchestration.  The framework is shown in Figure 2.









Amante, et al.           Expires August 16, 2013                [Page 7]


Internet-Draft           Topology API Use Cases            February 2013


                               +---------------+
                            +----------------+ |
                            |  Applications  |-+
                            +----------------+
                                    ^ Websockets, ReST, XMPP, I2RS, ...
          +-------------------------+-------------------------+
          |                         |                         |
     +------------+     +-------------------------+     +-------------+
     |   Policy   |<----|    Topology Manager     |---->|Orchestration|
     |   Manager  |     | +---------------------+ |     |   Manager   |
     +------------+     | | Topology Data Model | |     +-------------+
                        | +---------------------+ |
                        +-------------------------+
                                  ^  ^  ^
       Websockets, ReST, XMPP     #  |  *    Websockets, ReST, XMPP
           ########################  |  ************************
           #                         |                         *
     +------------+                  |                  +------------+
     | Statistics |                  |                  | Inventory  |
     | Collection |                  |                  | Collection |
     +------------+                  |                  +------------+
           ^                         | I2RS, NETCONF, SNMP,    ^
           |                         | TL1 ...                 |
           +-------------------------+-------------------------+
           |                         |                         |
           |                         |                         |
   +----------------+        +----------------+       +----------------+
   | Network Element|        | Network Element|       | Network Element|
   | +------------+ |<-LLDP->| +------------+ |<-LMP->| +------------+ |
   | | Data Model | |        | | Data Model | |       | | Data Model | |
   | +------------+ |        | +------------+ |       | +------------+ |
   +----------------+        +----------------+       +----------------+

                        Figure 2: Topology Manager

   The following sections describe in detail the Topology Manager,
   Policy Manager and Orchestration Manager functions.

3.2.  Topology Manager

   The Topology Manager is responsible for retrieving topological
   information from the network via a variety of sources.  The first
   most obvious source is the "live" IGP or an equivalent mechanism.
   "Live" IGP provides information about links that are components of
   the active topology, in other words links that are present in the
   Link State Database (LSDB) and are eligible for forwarding.  The
   second source of topology information is the Inventory Collection
   system, which provides information for network components not visible



Amante, et al.           Expires August 16, 2013                [Page 8]


Internet-Draft           Topology API Use Cases            February 2013


   within the IGP's LSDB, (i.e.: links or nodes, or properties of those
   links or nodes, at lower layers of the network).  The third source
   source of topology information is the Statistics Collection system,
   which provides traffic information (traffic demands, link
   utilizations, etc.).

   The Topology Manager will synthesize retrieved information into
   cohesive, abstracted views of the network using a standards-based,
   normalized topology data model.  The Topology Manager can then expose
   these data models to Clients, or higher-layer applications using a
   northbound interface, which would be a protocol/API commonly used by
   higher-layer applications to retrieve and update information.
   Examples of such protocols are ReST, Websockets, or XMPP.  Topology
   Manager's clients would be able to act upon the information in a
   read-only and/or read-write fashion, (based on policies defined
   within the Policy Manager).

   It is envisioned that the Topology Manager will ultimately contain
   topology information for multiple layers of the network: Transport,
   Ethernet and IP/MPLS as well as multiple (IGP) areas and/or multiple
   Autonomous Systems (ASes).  This allows the Topology Manager to
   stitch together a holistic view of several layers of the network,
   which is an important requirement, particularly for upper-layer
   Traffic Engineering, Capacity Planning and Provisioning Clients
   (applications) used to design, augment and optimize IP/MPLS networks
   that require knowledge of underlying Shared Risk Link Groups (SRLG)
   within the Transport and/or Ethernet layers of the network.

   The Topology Manager must have the ability to discover and
   communicate with network elements who are not only active and visible
   within the Link State Database (LSDB) of an active IGP, but also
   network elements who are active, but invisible to a LSDB (e.g.: L2
   Ethernet switches, ROADM's, etc.) that are part of the underlying
   Transport network.  This requirement will influence the choice of
   protocols needed by the Topology Manager to communicate to/from
   network elements at the various network layers.

   It is also important to recognize that the Topology Manager will be
   gleaning not only (relatively) static inventory information from the
   Inventory Manager, i.e.: what linecards, interface types, etc. are
   actively inserted into network elements, but also dynamic inventory
   information, as well.  With respect to the latter, network elements
   are expected to rely on various Link Layer Discovery Protocols (i.e.:
   LLDP, LMP, etc.) that will aid in automatically identifying an
   adjacent node, port, etc. at the far-side of a link.  This
   information is then pushed to or pulled by the Topology Manager in
   order for it to have an accurate representation of the physical
   topology of the network.



Amante, et al.           Expires August 16, 2013                [Page 9]


Internet-Draft           Topology API Use Cases            February 2013


3.3.  Policy Manager

   The Policy Manager is the function used to enforce and program
   policies applicable to network component/attribute data.  Policy
   enforcement is a network-wide function that can be consumed by
   various network elements and services including the Inventory
   Manager, Topology Manager or other network elements.  Such policies
   are likely to encompass the following.

   o  Logical Identifier Numbering Policies

      *  Correlation of IP prefix to link based on type of link (P-P,
         P-PE, PE-CE, etc.)

      *  Correlation of IP Prefix to IGP Area

      *  Layer-2 VLAN ID assignments, etc.

   o  Routing Configuration Policies

      *  OSPF Area or IS-IS Net-ID to Node (Type) Correlation

      *  BGP routing policies, i.e.: nodes designated for injection of
         aggregate routes, max-prefix policies, AFI/SAFI to node
         correlation, etc.

   o  Security Policies

      *  Access Control Lists

      *  Rate-limiting

   o  Network Component/Attribute Data Access Policies.  Client's
      (upper-layer application) read-only or read-write access to
      Network Components/Attributes contained in the "Inventory Manager"
      as well as Policies contained within the "Policy Manager" itself.

   The Policy Manager function may be a sub-component of the Topology or
   Orchestration Manager or it may be a standalone.  This will be
   determined as the work with I2RS evolves.

3.4.  Orchestration Manager

   The Orchestration Manager provides the ability to stitch together
   resources (i.e.: compute, storage) and/or services with the network
   or vice-versa.  Examples of 'generic' services may include the
   following:




Amante, et al.           Expires August 16, 2013               [Page 10]


Internet-Draft           Topology API Use Cases            February 2013


   o  Application-specific Load Balancing

   o  Application-specific Network (Bandwidth) Optimization

   o  Application or End-User specific Class-of-Service

   o  Application or End-User specific Network Access Control

   The above services could then enable coupling of resources with the
   network to realize the following:

   o  Network Optimization: Creation and Migration of Virtual Machines
      (VM's) so they are adjacent to storage in the same DataCenter.

   o  Network Access Control: Coupling of available (generic) compute
      nodes within the appropriate point of the data-path to perform
      firewall, NAT, etc. functions on data traffic.

   The Orchestration Manager is expected to exchange data models with
   the Topology Manager, Policy Manager and Inventory Manager functions.
   In addition, the Orchestration Manager is expected to support publish
   and subscribe capabilities to those functions, as well as to Clients,
   to enable scalability with respect to event notifications.

   The Orchestration Manager may receive requests from Clients
   (applications) for immediate access to specific network resources.
   However, Clients may request to schedule future appointments to
   reserve appropriate network resources when, for example, a special
   event is scheduled to start and end.

   Finally, the Orchestration Manager should have the flexibility to
   determine what network layer(s) may be able to satisfy a given
   Client's request, based on constraints received from the Client as
   well as those constraints learned from the Policy and/or Topology
   Manager functions.  This could allow the Orchestration Manager to,
   for example, satisfy a given service request for a given Client using
   the optical network (via OTN service) if there is insufficient IP/
   MPLS capacity at the specific moment the Client's request is
   received.

   The operational model is shown in the following figure.

                                    TBD.

                     Figure 3: Overall Reference Model






Amante, et al.           Expires August 16, 2013               [Page 11]


Internet-Draft           Topology API Use Cases            February 2013


4.  Use Cases

4.1.  Virtualized Views of the Network

4.1.1.  Capacity Planning and Traffic Engineering

   When performing Traffic Engineering and/or Capacity Planning of an
   IP/MPLS network, it is important to account for SRLG's that exist
   within the underlying physical, optical and Ethernet networks.
   Currently, it's quite common to create and/or take "snapshots", at
   infrequent intervals, that comprise the inventory data of the
   underlying physical and optical layer networks.  This inventory data
   then needs to be massaged or normalized to conform to the data import
   requirements of sometimes separate Traffic Engineering and/or
   Capacity Planning tools.  This process is error-prone and
   inefficient, particularly as the underlying network inventory
   information changes due to introduction of, for example, new network
   element makes or models, linecards, capabilities, etc. at the optical
   and/or Ethernet layers of the underlying network.

   This is inefficient with respect to the time and expense consumed by
   software developer, Capacity Planning and Traffic Engineering
   resources to normalize and sanity check underlying network inventory
   information, before it can be consumed by IP/MPLS Capacity Planning
   and Traffic Engineering applications.  Due to this inefficiency, the
   underlying physical network inventory information, (containing SRLG
   and corresponding critical network asset information), used by the
   IP/MPLS Capacity Planning and TE applications is not updated
   frequently, thus exposing the network to, at minimum, inefficient
   utilization and, at worst, critical impairments.

   An Inventory Manager function is required that will, first, extract
   inventory information from network elements -- and potentially
   associated offline inventory databases to acquire physical cross-
   connects and other information that is not available directly from
   network elements -- at the physical, optical, Ethernet and IP/MPLS
   layers of the network via standards-based data models.  Data models
   and associated vocabulary will be required to represent not only
   components inside or directly connected to network elements, but also
   to represent components of a physical layer path (i.e.: cross-connect
   panels, etc.)  The aforementioned inventory will comprise the
   complete set of inactive and active network components.

   A Statistics Collection Function is also required.  As stated above,
   it will collect utilization statistics from Network Elements, archive
   and aggregate them in a statistics data warehouse.  Selected
   statistics and other dynamic data may be distributed through IGP
   routing protocols ([I-D.previdi-isis-te-metric-extensions] and



Amante, et al.           Expires August 16, 2013               [Page 12]


Internet-Draft           Topology API Use Cases            February 2013


   [I-D.ietf-ospf-te-metric-extensions]) and then collected at the
   Statistics Collection Function via BGP-LS
   ([I-D.ietf-idr-ls-distribution]).  Summaries of these figures then
   need to be exposed in normalized data models to the Topology Manager
   so it can easily acquire historical link and LSP utilization figures
   that can be used to, for example, build trended utilization models to
   forecast expected changes to the physical and/or logical network
   components to accommodate network growth.

   The Topology Manager function may then augment the Inventory Manager
   information by communicating directly with Network Elements to reveal
   the IGP-based view of the active topology of the network.  This will
   allow the Topology Manager to include dynamic information from the
   IGP, such as Available Bandwidth, Reserved Bandwidth, etc.  Traffic
   Engineering (TE) attributes associated with links, contained with the
   Traffic Engineering Database (TED) on Network Elements.

   It is important to recognize that extracting topology information
   from the network solely via an IGP, (such as IS-IS TE or OSPF TE), is
   inadequate for this use case.  First, IGP's only expose the active
   components (e.g. vertices of the SPF tree) of the IP network;
   unfortunately, they are not aware of "hidden" or inactive interfaces
   within IP/MPLS network elements, (e.g.: unused linecards or unused
   ports), or components that reside at a lower layer than IP/MPLS, e.g.
   Ethernet switches, Optical transport systems, etc.  This occurs
   frequently during the course of maintenance, augment and optimization
   activities on the network.  Second, IGP's only convey SRLG
   information that have been first applied within the router's
   configurations, either manually or programatically.  As mentioned
   previously, this SRLG information in the IP/MPLS network is subject
   to being infrequently updated and, as a result, may inadequately
   account for critical, underlying network fate sharing properties that
   are necessary to properly design resilient circuits and/or paths
   through the network.

   In this use case, the Inventory Manager will need to be capable of
   using a variety of existing protocols such as: NETCONF, CLI, SNMP,
   TL1, etc. depending on the capabilities of the network elements.  The
   Topology Manager will need to be capable of communicating via an IGP
   from a (set of) Network Elements.  It is important to consider that
   to acquire topology information from Network Elements will require
   read-only access to the IGP.  However, the end result of the
   computations performed by the Capacity Planning Client may require
   changes to various IGP attributes, (e.g.: IGP metrics, TE link-
   colors, etc.)  These may be applied directly by devising a new
   capability to either: a) inject information into the IGP that
   overrides the same information injected by the originating Network
   Element; or, b) allowing the Topology and/or Inventory Manager the



Amante, et al.           Expires August 16, 2013               [Page 13]


Internet-Draft           Topology API Use Cases            February 2013


   ability to write changes to the Network Element's configuration in
   order to have it adjust the appropriate IGP attribute(s) and re-flood
   them throughout the IGP.  It would be desirable to have a single
   mechanism (data model or protocol) that allows the Topology Manager
   to read and write IGP attributes.

   Once the Topology Manager function has assembled a normalized view of
   the topology and synthesized associated metadata with each component
   of the topology (link type, link properties, statistics, intra-layer
   relationships, etc.), it can then expose this information via its
   northbound API to Clients.  In this use case that means Capacity
   Planning and Traffic Engineering applications, which are not required
   to know innate details of individual network elements, but do require
   generalized information about the node and links that comprise the
   network, e.g.: links used to interconnect nodes, SRLG information
   (from the underlying network), utilization rates of each link over
   some period of time, etc.  In this case, it is important that any
   Client that understands both the web services API and the normalized
   data model can communicate with the Topology Manager in order to
   understand the network topology information that was provided by
   network elements from potentially different vendors, all of which
   likely represent that topology information internally using different
   models.  If the Client had gone directly to the network elements
   themselves, it would have to translate and then normalize these
   different representations for itself.  However, in this case, the
   Topology Manager has done that for it.

   When this information is consumed by the Traffic Engineering
   application, it may run a variety of CSPF algorithms the result of
   which is likely a list of RSVP LSP's that need to be
   (re-)established, or torn down, in the network to globally optimize
   the packing efficiency of physical links throughout the network.  The
   end result of the Traffic Engineering application is "pushing" out to
   the Topology Manager, via a standard data model to be defined here, a
   list of RSVP LSP's and their associated characteristics, (i.e.: head
   and tail-end LSR's, bandwidth, priority, preemption, etc.).  The
   Topology Manager then would consume this information and carry out
   those instructions by speaking directly to network elements, perhaps
   via PCEP Extensions for Stateful PCE [I-D.ietf-pce-stateful-pce],
   which in turn initiates RSVP signaling through the network to
   establish the LSP's.

   After this information is consumed by the Capacity Planning
   application, it may run a variety of algorithms the result of which
   is a list of new inventory that is required to be purchased (or,
   redeployed) as well as associated work orders for field technicians
   to augment the network for expected growth.  It would be ideal if
   this information was also "pushed" back into the Topology and, in



Amante, et al.           Expires August 16, 2013               [Page 14]


Internet-Draft           Topology API Use Cases            February 2013


   turn, Inventory Manager as "inactive" links and/or nodes, so that as
   new equipment is installed it can be automatically correlated with
   original design and work order packages associated with that augment.

4.1.2.  Services Provisioning

   Beyond Capacity Planning and Traffic Engineering applications, having
   a normalized view of just the IP/MPLS layer of the network is still
   very important for other mission critical applications such as
   Security Auditing and IP/MPLS Services Provisioning, (e.g.: L2VPN,
   L3VPN, etc.).  With respect to the latter, these types of
   applications should not need a detailed understanding of, for
   example, SRLG information, assuming that the underlying MPLS Tunnel
   LSP's are known to account for the resiliency requirements of all
   services that ride over them.  Nonetheless, for both types of
   applications it is critical that they have a common and up-to-date
   normalized view of the IP/MPLS network in order to easily instantiate
   new services at the appropriate places in the network, in the case of
   VPN services, or validate that ACL's are configured properly to
   protect associated routing, signaling and management protocols on the
   network, with respect to Security Auditing.

   For this use case, what is most commonly needed by a VPN Service
   Provisioning application is as follows.  First, Service PE's need to
   be identified in all markets/cities where the customer has identified
   they want service.  Next, does their exist one, or more, Servies PE's
   in each city with connectivity to the access network(s), e.g.: SONET/
   TDM, used to deliver the PE-CE tail circuits to the Service's PE.
   Finally, does the Services PE have available capacity on both the
   PE-CE access interface and its uplinks to terminate the tail circuit?
   If this were to be generalized, this would be considered an Resource
   Selection function.  Namely, the VPN Provisioning application would
   iteratively query the Topology Manager to narrow down the scope of
   resources to the set of Services PE's with the appropriate uplink
   bandwidth and access circuit capability plus capacity to realize the
   requested VPN service.  Once the VPN Provisioning application has a
   candidate list of resources it then requests the Topology Manager to
   go about configuring the Services PE's and associated access circuits
   to realize the customer's VPN service.

4.1.3.  Troubleshooting & Monitoring

   Once the Topology Manager has a normalized view of several layers of
   the network, it's then possible to more easily expose a richer set of
   data to network operators when performing diagnosis, troubleshooting
   and repairs on the network.  Specifically, there is a need to
   (rapidly) assemble a current, accurate and comprehensive network
   diagram of a L2VPN or L3VPN service for a particular customer when



Amante, et al.           Expires August 16, 2013               [Page 15]


Internet-Draft           Topology API Use Cases            February 2013


   either: a) attempting to diagnose a service fault/error; or, b)
   attempting to augment the customer's existing service.  Information
   that may be assembled into a comprehensive picture could include
   physical and logical components related specifically to that
   customer's service, i.e.: VLAN's or channels used by the PE-CE access
   circuits, CoS policies, historical PE-CE circuit utilization, etc.
   The Topology Manager would assemble this information, on behalf of
   each of the network elements and other data sources in and associated
   with the network, and could present this information in a vendor-
   independent data model to applications to be displayed allowing the
   operator (or, potentially, the customer through a SP's Web portal) to
   visualize the information.

4.2.  Path Computation Element (PCE)

   As described in [RFC4655] a PCE can be used to compute MPLS-TE paths
   within a "domain" (such as an IGP area) or across multiple domains
   (such as a multi-area AS, or multiple ASes).

   o  Within a single area, the PCE offers enhanced computational power
      that may not be available on individual routers, sophisticated
      policy control and algorithms, and coordination of computation
      across the whole area.

   o  If a router wants to compute a MPLS-TE path across IGP areas its
      own TED lacks visibility of the complete topology.  That means
      that the router cannot determine the end-to-end path, and cannot
      even select the right exit router (Area Border Router - ABR) for
      an optimal path.  This is an issue for large-scale networks that
      need to segment their core networks into distinct areas, but which
      still want to take advantage of MPLS-TE.

   The PCE presents a computation server that may have visibility into
   more than one IGP area or AS, or may cooperate with other PCEs to
   perform distributed path computation.  The PCE needs access to the
   topology and the Traffic Engineering Database (TED) for the area(s)
   it serves, but [RFC4655] does not describe how this is achieved.
   Many implementations make the PCE a passive participant in the IGP so
   that it can learn the latest state of the network, but this may be
   sub-optimal when the network is subject to a high degree of churn, or
   when the PCE is responsible for multiple areas.

   The following figure shows how a PCE can get its TED information
   using a Topology Server.







Amante, et al.           Expires August 16, 2013               [Page 16]


Internet-Draft           Topology API Use Cases            February 2013


                  +----------+
                  |  -----   | TED synchronization via Topology API
                  | | TED |<-+----------------------------------+
                  |  -----   |                                  |
                  |    |     |                                  |
                  |    |     |                                  |
                  |    v     |                                  |
                  |  -----   |                                  |
                  | | PCE |  |                                  |
                  |  -----   |                                  |
                  +----------+                                  |
                       ^                                        |
                       | Request/                               |
                       | Response                               |
                       v                                        |
         Service  +----------+   Signaling  +----------+   +----------+
         Request  | Head-End |   Protocol   | Adjacent |   | Topology |
         -------->|  Node    |<------------>|   Node   |   | Manager  |
                  +----------+              +----------+   +----------+

           Figure 4: Topology use case: Path Computation Element

4.3.  ALTO Server

   An ALTO Server [RFC5693] is an entity that generates an abstracted
   network topology and provides it to network-aware applications over a
   web service based API.

   Example applications are Content Delivery Network (CDNs), peer-to-
   peer clouds/swarms, as well as inter-layer optimization cases such as
   mobile network willing to understand the congestion level of
   underneath backhaul infrastructure.

   ALTO mechanisms are based on "Maps" that contain an abstracted
   version of the topology.  Such Maps are built by the ALTO server or
   made available to the ALTO server by a Topology Manager.  The content
   of Maps are multiple: a mapping list where each prefix is mapped into
   a Partition Identifier (called PID) and the cost matrix (representing
   the distance) between PIDs.  For more details, see
   [I-D.ietf-alto-protocol].

   ALTO abstract network topologies (represented in the Maps) can be
   generated in multiple ways among which the Topology Manager provides
   the abstracted topology to the ALTO server so that the ALTO server is
   capable of serving applications.  ALTO Maps may represent the whole
   network infrastructure and are not limited to a specific layer.
   E.g.: the cost matrix (called the Cost Map) can represent the IP/MPLS
   layer path costs as well as integrating the optical cost.



Amante, et al.           Expires August 16, 2013               [Page 17]


Internet-Draft           Topology API Use Cases            February 2013


   The generation would typically be based on policies and rules set by
   the operator.  All the relevant information such as Nodes, Links,
   Prefixes, TE paths (LSPs/Tunnels), etc. is required so for the ALTO
   server to have an exhaustive and consistent view of the
   infrastructure.

   Typically, a Topology Manager would aggregate all the necessary
   information and would produce ALTO maps.  Mechanisms through which a
   Topology Manager acquires topology information include interaction
   with the IGP and the use of BGP-LS extension.

   The mechanism defined in this document provides a single interface
   through which an ALTO Server can retrieve all the necessary prefix
   and network topology data from the underlying network (i.e.: the
   Topology Manager).  Note an ALTO Server can use other mechanisms to
   get network data, for example, peering with multiple IGP and BGP
   Speakers.

   The following figure shows how an ALTO Server can get network
   topology information from the underlying network using the Topology
   API.

      +--------+
      | Client |<--+
      +--------+   |
                   |    ALTO    +--------+                  +----------+
      +--------+   |  Protocol  |  ALTO  | Network Topology | Topology |
      | Client |<--+------------| Server |<-----------------| Manager  |
      +--------+   |            |        |                  |          |
                   |            +--------+                  +----------+
      +--------+   |
      | Client |<--+
      +--------+

                 Figure 5: Topology use case: ALTO Server


5.  Acknowledgements

   The authors wish to thank Alia Atlas, Dave Ward and Hannes Gredler
   for their valuable contributions and feedback to this draft.


6.  IANA Considerations

   This memo includes no request to IANA.





Amante, et al.           Expires August 16, 2013               [Page 18]


Internet-Draft           Topology API Use Cases            February 2013


7.  Security Considerations

   At the moment, the Use Cases covered in this document apply
   specifically to a single Service Provider or Enterprise network.
   Therefore, network administrations should take appropriate
   precautions to ensure appropriate access controls exist so that only
   internal applications and end-users have physical or logical access
   to the Topology Manager.  This should be similar to precautions that
   are already taken by Network Administrators to secure their existing
   Network Management, OSS and BSS systems.

   As this work evolves, it will be important to determine the
   appropriate granularity of access controls in terms of what
   individuals or groups may have read and/or write access to various
   types of information contained with the Topology Manager.  It would
   be ideal, if these access control mechanisms were centralized within
   the Topology Manager itself.


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              draft-ietf-alto-protocol-13 (work in progress),
              September 2012.

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-01
              (work in progress), October 2012.

   [I-D.ietf-ospf-te-metric-extensions]
              Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", draft-ietf-ospf-te-metric-extensions-02 (work
              in progress), December 2012.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",



Amante, et al.           Expires August 16, 2013               [Page 19]


Internet-Draft           Topology API Use Cases            February 2013


              draft-ietf-pce-stateful-pce-02 (work in progress),
              October 2012.

   [I-D.previdi-isis-te-metric-extensions]
              Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
              A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
              Metric Extensions",
              draft-previdi-isis-te-metric-extensions-02 (work in
              progress), October 2012.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.


Authors' Addresses

   Shane Amante
   Level 3 Communications, Inc.
   1025 Eldorado Blvd
   Broomfield, CO  80021
   USA

   Email: shane@level3.net


   Jan Medved
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: jmedved@cisco.com


   Stefano Previdi
   Cisco Systems, Inc.
   Via Del Serafico 200
   Rome  00144
   IT

   Email: sprevidi@cisco.com






Amante, et al.           Expires August 16, 2013               [Page 20]


Internet-Draft           Topology API Use Cases            February 2013


   Thomas D. Nadeau
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   Email: tnadeau@juniper.net












































Amante, et al.           Expires August 16, 2013               [Page 21]


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