tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7491

Informational
Pages: 71
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~rtg

A PCE-Based Architecture for Application-Based Network Operations

Part 1 of 4, p. 1 to 24
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           D. King
Request for Comments: 7491                            Old Dog Consulting
Category: Informational                                        A. Farrel
ISSN: 2070-1721                                         Juniper Networks
                                                              March 2015


   A PCE-Based Architecture for Application-Based Network Operations

Abstract

   Services such as content distribution, distributed databases, or
   inter-data center connectivity place a set of new requirements on the
   operation of networks.  They need on-demand and application-specific
   reservation of network connectivity, reliability, and resources (such
   as bandwidth) in a variety of network applications (such as point-to-
   point connectivity, network virtualization, or mobile back-haul) and
   in a range of network technologies from packet (IP/MPLS) down to
   optical.  An environment that operates to meet these types of
   requirements is said to have Application-Based Network Operations
   (ABNO).  ABNO brings together many existing technologies and may be
   seen as the use of a toolbox of existing components enhanced with a
   few new elements.

   This document describes an architecture and framework for ABNO,
   showing how these components fit together.  It provides a cookbook of
   existing technologies to satisfy the architecture and meet the needs
   of the applications.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7491.

Page 2 
Copyright Notice

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

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
      1.1. Scope ......................................................5
   2. Application-Based Network Operations (ABNO) .....................6
      2.1. Assumptions ................................................6
      2.2. Implementation of the Architecture .........................6
      2.3. Generic ABNO Architecture ..................................7
           2.3.1. ABNO Components .....................................8
           2.3.2. Functional Interfaces ..............................15
   3. ABNO Use Cases .................................................24
      3.1. Inter-AS Connectivity .....................................24
      3.2. Multi-Layer Networking ....................................30
           3.2.1. Data Center Interconnection across
                  Multi-Layer Networks ...............................34
      3.3. Make-before-Break .........................................37
           3.3.1. Make-before-Break for Reoptimization ...............37
           3.3.2. Make-before-Break for Restoration ..................38
           3.3.3. Make-before-Break for Path Test and Selection ......40
      3.4. Global Concurrent Optimization ............................42
           3.4.1. Use Case: GCO with MPLS LSPs .......................43
      3.5. Adaptive Network Management (ANM) .........................45
           3.5.1. ANM Trigger ........................................46
           3.5.2. Processing Request and GCO Computation .............46
           3.5.3. Automated Provisioning Process .....................47
      3.6. Pseudowire Operations and Management ......................48
           3.6.1. Multi-Segment Pseudowires ..........................48
           3.6.2. Path-Diverse Pseudowires ...........................50
           3.6.3. Path-Diverse Multi-Segment Pseudowires .............51
           3.6.4. Pseudowire Segment Protection ......................52
           3.6.5. Applicability of ABNO to Pseudowires ...............52
      3.7. Cross-Stratum Optimization (CSO) ..........................53
           3.7.1. Data Center Network Operation ......................53
           3.7.2. Application of the ABNO Architecture ...............56
      3.8. ALTO Server ...............................................58
      3.9. Other Potential Use Cases .................................61
           3.9.1. Traffic Grooming and Regrooming ....................61
           3.9.2. Bandwidth Scheduling ...............................62
   4. Survivability and Redundancy within the ABNO Architecture ......62
   5. Security Considerations ........................................63
   6. Manageability Considerations ...................................63
   7. Informative References .........................................64
   Appendix A. Undefined Interfaces ..................................69
   Acknowledgements ..................................................70
   Contributors ......................................................71
   Authors' Addresses ................................................71

Top      ToC       Page 4 
1.  Introduction

   Networks today integrate multiple technologies allowing network
   infrastructure to deliver a variety of services to support the
   different characteristics and demands of applications.  There is an
   increasing demand to make the network responsive to service requests
   issued directly from the application layer.  This differs from the
   established model where services in the network are delivered in
   response to management commands driven by a human user.

   These application-driven requests and the services they establish
   place a set of new requirements on the operation of networks.  They
   need on-demand and application-specific reservation of network
   connectivity, reliability, and resources (such as bandwidth) in a
   variety of network applications (such as point-to-point connectivity,
   network virtualization, or mobile back-haul) and in a range of
   network technologies from packet (IP/MPLS) down to optical.  An
   environment that operates to meet this type of application-aware
   requirement is said to have Application-Based Network Operations
   (ABNO).

   The Path Computation Element (PCE) [RFC4655] was developed to provide
   path computation services for GMPLS- and MPLS-controlled networks.
   The applicability of PCEs can be extended to provide path computation
   and policy enforcement capabilities for ABNO platforms and services.

   ABNO can provide the following types of service to applications by
   coordinating the components that operate and manage the network:

   - Optimization of traffic flows between applications to create an
     overlay network for communication in use cases such as file
     sharing, data caching or mirroring, media streaming, or real-time
     communications described as Application-Layer Traffic Optimization
     (ALTO) [RFC5693].

   - Remote control of network components allowing coordinated
     programming of network resources through such techniques as
     Forwarding and Control Element Separation (ForCES) [RFC3746],
     OpenFlow [ONF], and the Interface to the Routing System (I2RS)
     [I2RS-Arch], or through the control plane coordinated through the
     PCE Communication Protocol (PCEP) [PCE-Init-LSP].

   - Interconnection of Content Delivery Networks (CDNi) [RFC6707]
     through the establishment and resizing of connections between
     content distribution networks.  Similarly, ABNO can coordinate
     inter-data center connections.

Top      ToC       Page 5 
   - Network resource coordination to automate provisioning, and to
     facilitate traffic grooming and regrooming, bandwidth scheduling,
     and Global Concurrent Optimization using PCEP [RFC5557].

   - Virtual Private Network (VPN) planning in support of deployment of
     new VPN customers and to facilitate inter-data center connectivity.

   This document outlines the architecture and use cases for ABNO, and
   shows how the ABNO architecture can be used for coordinating control
   system and application requests to compute paths, enforce policies,
   and manage network resources for the benefit of the applications that
   use the network.  The examination of the use cases shows the ABNO
   architecture as a toolkit comprising many existing components and
   protocols, and so this document looks like a cookbook.  ABNO is
   compatible with pre-existing Network Management System (NMS) and
   Operations Support System (OSS) deployments as well as with more
   recent developments in programmatic networks such as Software-Defined
   Networking (SDN).

1.1.  Scope

   This document describes a toolkit.  It shows how existing functional
   components described in a large number of separate documents can be
   brought together within a single architecture to provide the function
   necessary for ABNO.

   In many cases, existing protocols are known to be good enough or
   almost good enough to satisfy the requirements of interfaces between
   the components.  In these cases, the protocols are called out as
   suitable candidates for use within an implementation of ABNO.

   In other cases, it is clear that further work will be required, and
   in those cases a pointer to ongoing work that may be of use is
   provided.  Where there is no current work that can be identified by
   the authors, a short description of the missing interface protocol is
   given in Appendix A.

   Thus, this document may be seen as providing an applicability
   statement for existing protocols, and guidance for developers of new
   protocols or protocol extensions.

Top      ToC       Page 6 
2.  Application-Based Network Operations (ABNO)

2.1.  Assumptions

   The principal assumption underlying this document is that existing
   technologies should be used where they are adequate for the task.
   Furthermore, when an existing technology is almost sufficient, it is
   assumed to be preferable to make minor extensions rather than to
   invent a whole new technology.

   Note that this document describes an architecture.  Functional
   components are architectural concepts and have distinct and clear
   responsibilities.  Pairs of functional components interact over
   functional interfaces that are, themselves, architectural concepts.

2.2.  Implementation of the Architecture

   It needs to be strongly emphasized that this document describes a
   functional architecture.  It is not a software design.  Thus, it is
   not intended that this architecture constrain implementations.
   However, the separation of the ABNO functions into separate
   functional components with clear interfaces between them enables
   implementations to choose which features to include and allows
   different functions to be distributed across distinct processes or
   even processors.

   An implementation of this architecture may make several important
   decisions about the functional components:

   - Multiple functional components may be grouped together into one
     software component such that all of the functions are bundled and
     only the external interfaces are exposed.  This may have distinct
     advantages for fast paths within the software and can reduce
     interprocess communication overhead.

     For example, an Active, Stateful PCE could be implemented as a
     single server combining the ABNO components of the PCE, the Traffic
     Engineering Database, the Label Switched Path Database, and the
     Provisioning Manager (see Section 2.3).

   - The functional components could be distributed across separate
     processes, processors, or servers so that the interfaces are
     exposed as external protocols.

Top      ToC       Page 7 
     For example, the Operations, Administration, and Maintenance (OAM)
     Handler (see Section 2.3.1.6) could be presented on a dedicated
     server in the network that consumes all status reports from the
     network, aggregates them, correlates them, and then dispatches
     notifications to other servers that need to understand what has
     happened.

   - There could be multiple instances of any or each of the components.
     That is, the function of a functional component could be
     partitioned across multiple software components with each
     responsible for handling a specific feature or a partition of the
     network.

     For example, there may be multiple Traffic Engineering Databases
     (see Section 2.3.1.8) in an implementation, with each holding the
     topology information of a separate network domain (such as a
     network layer or an Autonomous System).  Similarly, there could be
     multiple PCE instances, each processing a different Traffic
     Engineering Database, and potentially distributed on different
     servers under different management control.  As a final example,
     there could be multiple ABNO Controllers, each with capability to
     support different classes of application or application service.

   The purpose of the description of this architecture is to facilitate
   different implementations while offering interoperability between
   implementations of key components, and easy interaction with the
   applications and with the network devices.

2.3.  Generic ABNO Architecture

   Figure 1 illustrates the ABNO architecture.  The components and
   functional interfaces are discussed in Sections 2.3.1 and 2.3.2,
   respectively.  The use cases described in Section 3 show how
   different components are used selectively to provide different
   services.  It is important to understand that the relationships and
   interfaces shown between components in this figure are illustrative
   of some of the common or likely interactions; however, this figure
   does not preclude other interfaces and relationships as necessary to
   realize specific functionality.

Top      ToC       Page 8 
    +----------------------------------------------------------------+
    |          OSS / NMS / Application Service Coordinator           |
    +-+---+---+----+-----------+---------------------------------+---+
      |   |   |    |           |                                 |
   ...|...|...|....|...........|.................................|......
   :  |   |   |    |      +----+----------------------+          |     :
   :  |   |   | +--+---+  |                           |      +---+---+ :
   :  |   |   | |Policy+--+     ABNO Controller       +------+       | :
   :  |   |   | |Agent |  |                           +--+   |  OAM  | :
   :  |   |   | +-+--+-+  +-+------------+----------+-+  |   |Handler| :
   :  |   |   |   |  |      |            |          |    |   |       | :
   :  |   | +-+---++ | +----+-+  +-------+-------+  |    |   +---+---+ :
   :  |   | |ALTO  | +-+ VNTM |--+               |  |    |       |     :
   :  |   | |Server|   +--+-+-+  |               |  | +--+---+   |     :
   :  |   | +--+---+      | |    |      PCE      |  | | I2RS |   |     :
   :  |   |    |  +-------+ |    |               |  | |Client|   |     :
   :  |   |    |  |         |    |               |  | +-+--+-+   |     :
   :  | +-+----+--+-+       |    |               |  |   |  |     |     :
   :  | | Databases +-------:----+               |  |   |  |     |     :
   :  | |   TED     |       |    +-+---+----+----+  |   |  |     |     :
   :  | |  LSP-DB   |       |      |   |    |       |   |  |     |     :
   :  | +-----+--+--+     +-+---------------+-------+-+ |  |     |     :
   :  |       |  |        |    Provisioning Manager   | |  |     |     :
   :  |       |  |        +-----------------+---+-----+ |  |     |     :
   ...|.......|..|.................|...|....|...|.......|..|.....|......
      |       |  |                 |   |    |   |       |  |     |
      |     +-+--+-----------------+--------+-----------+----+   |
      +----/               Client Network Layer               \--+
      |   +----------------------------------------------------+ |
      |      |                         |        |          |     |
     ++------+-------------------------+--------+----------+-----+-+
    /                      Server Network Layers                    \
   +-----------------------------------------------------------------+

                    Figure 1: Generic ABNO Architecture

2.3.1.  ABNO Components

   This section describes the functional components shown as boxes in
   Figure 1.  The interactions between those components, the functional
   interfaces, are described in Section 2.3.2.

Top      ToC       Page 9 
2.3.1.1.  NMS and OSS

   A Network Management System (NMS) or an Operations Support System
   (OSS) can be used to control, operate, and manage a network.  Within
   the ABNO architecture, an NMS or OSS may issue high-level service
   requests to the ABNO Controller.  It may also establish policies for
   the activities of the components within the architecture.

   The NMS and OSS can be consumers of network events reported through
   the OAM Handler and can act on these reports as well as displaying
   them to users and raising alarms.  The NMS and OSS can also access
   the Traffic Engineering Database (TED) and Label Switched Path
   Database (LSP-DB) to show the users the current state of the network.

   Lastly, the NMS and OSS may utilize a direct programmatic or
   configuration interface to interact with the network elements within
   the network.

2.3.1.2.  Application Service Coordinator

   In addition to the NMS and OSS, services in the ABNO architecture may
   be requested by or on behalf of applications.  In this context, the
   term "application" is very broad.  An application may be a program
   that runs on a host or server and that provides services to a user,
   such as a video conferencing application.  Alternatively, an
   application may be a software tool that a user uses to make requests
   to the network to set up specific services such as end-to-end
   connections or scheduled bandwidth reservations.  Finally, an
   application may be a sophisticated control system that is responsible
   for arranging the provision of a more complex network service such as
   a virtual private network.

   For the sake of this architecture, all of these concepts of an
   application are grouped together and are shown as the Application
   Service Coordinator, since they are all in some way responsible for
   coordinating the activity of the network to provide services for use
   by applications.  In practice, the function of the Application
   Service Coordinator may be distributed across multiple applications
   or servers.

   The Application Service Coordinator communicates with the ABNO
   Controller to request operations on the network.

Top      ToC       Page 10 
2.3.1.3.  ABNO Controller

   The ABNO Controller is the main gateway to the network for the NMS,
   OSS, and Application Service Coordinator for the provision of
   advanced network coordination and functions.  The ABNO Controller
   governs the behavior of the network in response to changing network
   conditions and in accordance with application network requirements
   and policies.  It is the point of attachment, and it invokes the
   right components in the right order.

   The use cases in Section 3 provide a clearer picture of how the ABNO
   Controller interacts with the other components in the ABNO
   architecture.

2.3.1.4.  Policy Agent

   Policy plays a very important role in the control and management of
   the network.  It is, therefore, significant in influencing how the
   key components of the ABNO architecture operate.

   Figure 1 shows the Policy Agent as a component that is configured by
   the NMS/OSS with the policies that it applies.  The Policy Agent is
   responsible for propagating those policies into the other components
   of the system.

   Simplicity in the figure necessitates leaving out many of the policy
   interactions that will take place.  Although the Policy Agent is only
   shown interacting with the ABNO Controller, the ALTO Server, and the
   Virtual Network Topology Manager (VNTM), it will also interact with a
   number of other components and the network elements themselves.  For
   example, the Path Computation Element (PCE) will be a Policy
   Enforcement Point (PEP) [RFC2753] as described in [RFC5394], and the
   Interface to the Routing System (I2RS) Client will also be a PEP as
   noted in [I2RS-Arch].

2.3.1.5.  Interface to the Routing System (I2RS) Client

   The Interface to the Routing System (I2RS) is described in
   [I2RS-Arch].  The interface provides a programmatic way to access
   (for read and write) the routing state and policy information on
   routers in the network.

   The I2RS Client is introduced in [I2RS-PS].  Its purpose is to manage
   information requests across a number of routers (each of which runs
   an I2RS Agent) and coordinate setting or gathering state to/from
   those routers.

Top      ToC       Page 11 
2.3.1.6.  OAM Handler

   Operations, Administration, and Maintenance (OAM) plays a critical
   role in understanding how a network is operating, detecting faults,
   and taking the necessary action to react to problems in the network.

   Within the ABNO architecture, the OAM Handler is responsible for
   receiving notifications (often called alerts) from the network about
   potential problems, for correlating them, and for triggering other
   components of the system to take action to preserve or recover the
   services that were established by the ABNO Controller.  The OAM
   Handler also reports network problems and, in particular, service-
   affecting problems to the NMS, OSS, and Application Service
   Coordinator.

   Additionally, the OAM Handler interacts with the devices in the
   network to initiate OAM actions within the data plane, such as
   monitoring and testing.

2.3.1.7.  Path Computation Element (PCE)

   PCE is introduced in [RFC4655].  It is a functional component that
   services requests to compute paths across a network graph.  In
   particular, it can generate traffic-engineered routes for MPLS-TE and
   GMPLS Label Switched Paths (LSPs).  The PCE may receive these
   requests from the ABNO Controller, from the Virtual Network Topology
   Manager, or from network elements themselves.

   The PCE operates on a view of the network topology stored in the
   Traffic Engineering Database (TED).  A more sophisticated computation
   may be provided by a Stateful PCE that enhances the TED with a
   database (the LSP-DB -- see Section 2.3.1.8.2) containing information
   about the LSPs that are provisioned and operational within the
   network as described in [RFC4655] and [Stateful-PCE].

   Additional functionality in an Active PCE allows a functional
   component that includes a Stateful PCE to make provisioning requests
   to set up new services or to modify in-place services as described in
   [Stateful-PCE] and [PCE-Init-LSP].  This function may directly access
   the network elements or may be channeled through the Provisioning
   Manager.

   Coordination between multiple PCEs operating on different TEDs can
   prove useful for performing path computation in multi-domain or
   multi-layer networks.  A domain in this case might be an Autonomous
   System (AS), thus enabling inter-AS path computation.

Top      ToC       Page 12 
   Since the PCE is a key component of the ABNO architecture, a better
   view of its role can be gained by examining the use cases described
   in Section 3.

2.3.1.8.  Databases

   The ABNO architecture includes a number of databases that contain
   information stored for use by the system.  The two main databases are
   the TED and the LSP Database (LSP-DB), but there may be a number of
   other databases used to contain information about topology (ALTO
   Server), policy (Policy Agent), services (ABNO Controller), etc.

   In the text that follows, specific key components that are consumers
   of the databases are highlighted.  It should be noted that the
   databases are available for inspection by any of the ABNO components.
   Updates to the databases should be handled with some care, since
   allowing multiple components to write to a database can be the cause
   of a number of contention and sequencing problems.

2.3.1.8.1.  Traffic Engineering Database (TED)

   The TED is a data store of topology information about a network that
   may be enhanced with capability data (such as metrics or bandwidth
   capacity) and active status information (such as up/down status or
   residual unreserved bandwidth).

   The TED may be built from information supplied by the network or from
   data (such as inventory details) sourced through the NMS/OSS.

   The principal use of the TED in the ABNO architecture is to provide
   the raw data on which the Path Computation Element operates.  But the
   TED may also be inspected by users at the NMS/OSS to view the current
   status of the network and may provide information to application
   services such as Application-Layer Traffic Optimization (ALTO)
   [RFC5693].

2.3.1.8.2.  LSP Database

   The LSP-DB is a data store of information about LSPs that have been
   set up in the network or that could be established.  The information
   stored includes the paths and resource usage of the LSPs.

   The LSP-DB may be built from information generated locally.  For
   example, when LSPs are provisioned, the LSP-DB can be updated.  The
   database can also be constructed from information gathered from the
   network by polling or reading the state of LSPs that have already
   been set up.

Top      ToC       Page 13 
   The main use of the LSP-DB within the ABNO architecture is to enhance
   the planning and optimization of LSPs.  New LSPs can be established
   to be path-disjoint from other LSPs in order to offer protected
   services; LSPs can be rerouted in order to put them on more optimal
   paths or to make network resources available for other LSPs; LSPs can
   be rapidly repaired when a network failure is reported; LSPs can be
   moved onto other paths in order to avoid resources that have planned
   maintenance outages.  A Stateful PCE (see Section 2.3.1.7) is a
   primary consumer of the LSP-DB.

2.3.1.8.3.  Shared Risk Link Group (SRLG) Databases

   The TED may, itself, be supplemented by SRLG information that assigns
   to each network resource one or more identifiers that associate the
   resource with other resources in the same TED that share the same
   risk of failure.

   While this information can be highly useful, it may be supplemented
   by additional detailed information maintained in a separate database
   and indexed using the SRLG identifier from the TED.  Such a database
   can interpret SRLG information provided by other networks (such as
   server networks), can provide failure probabilities associated with
   each SRLG, can offer prioritization when SRLG-disjoint paths cannot
   be found, and can correlate SRLGs between different server networks
   or between different peer networks.

2.3.1.8.4.  Other Databases

   There may be other databases that are built within the ABNO system
   and that are referenced when operating the network.  These databases
   might include information about, for example, traffic flows and
   demands, predicted or scheduled traffic demands, link and node
   failure and repair history, network resources such as packet labels
   and physical labels (i.e., MPLS and GMPLS labels), etc.

   As mentioned in Section 2.3.1.8.1, the TED may be enhanced by
   inventory information.  It is quite likely in many networks that such
   an inventory is held in a separate database (the Inventory Database)
   that includes details of the manufacturer, model, installation date,
   etc.

2.3.1.9.  ALTO Server

   The ALTO Server provides network information to the application layer
   based on abstract maps of a network region.  This information
   provides a simplified view, but it is useful to steer application-
   layer traffic.  ALTO services enable service providers to share
   information about network locations and the costs of paths between

Top      ToC       Page 14 
   them.  The selection criteria to choose between two locations may
   depend on information such as maximum bandwidth, minimum cross-domain
   traffic, lower cost to the user, etc.

   The ALTO Server generates ALTO views to share information with the
   Application Service Coordinator so that it can better select paths in
   the network to carry application-layer traffic.  The ALTO views are
   computed based on information from the network databases, from
   policies configured by the Policy Agent, and through the algorithms
   used by the PCE.

   Specifically, the base ALTO protocol [RFC7285] defines a single-node
   abstract view of a network to the Application Service Coordinator.
   Such a view consists of two maps: a network map and a cost map.  A
   network map defines multiple Provider-defined Identifiers (PIDs),
   which represent entrance points to the network.  Each node in the
   application layer is known as an End Point (EP), and each EP is
   assigned to a PID, because PIDs are the entry points of the
   application in the network.  As defined in [RFC7285], a PID can
   denote a subnet, a set of subnets, a metropolitan area, a Point of
   Presence (PoP), etc.  Each such network region can be a single domain
   or multiple networks; it is just the view that the ALTO Server is
   exposing to the application layer.  A cost map provides costs between
   EPs and/or PIDs.  The criteria that the Application Service
   Coordinator uses to choose application routes between two locations
   may depend on attributes such as maximum bandwidth, minimum cross-
   domain traffic, lower cost to the user, etc.

2.3.1.10.  Virtual Network Topology Manager (VNTM)

   A Virtual Network Topology (VNT) is defined in [RFC5212] as a set of
   one or more LSPs in one or more lower-layer networks that provides
   information for efficient path handling in an upper-layer network.
   For instance, a set of LSPs in a wavelength division multiplexed
   (WDM) network can provide connectivity as virtual links in a higher-
   layer packet-switched network.

   The VNT enhances the physical/dedicated links that are available in
   the upper-layer network and is configured by setting up or tearing
   down the lower-layer LSPs and by advertising the changes into the
   higher-layer network.  The VNT can be adapted to traffic demands so
   that capacity in the higher-layer network can be created or released
   as needed.  Releasing unwanted VNT resources makes them available in
   the lower-layer network for other uses.

Top      ToC       Page 15 
   The creation of virtual topology for inclusion in a network is not a
   simple task.  Decisions must be made about which nodes in the upper
   layer it is best to connect, in which lower-layer network to
   provision LSPs to provide the connectivity, and how to route the LSPs
   in the lower-layer network.  Furthermore, some specific actions have
   to be taken to cause the lower-layer LSPs to be provisioned and the
   connectivity in the upper-layer network to be advertised.

   [RFC5623] describes how the VNTM may instantiate connections in the
   server layer in support of connectivity in the client layer.  Within
   the ABNO architecture, the creation of new connections may be
   delegated to the Provisioning Manager as discussed in
   Section 2.3.1.11.

   All of these actions and decisions are heavily influenced by policy,
   so the VNTM component that coordinates them takes input from the
   Policy Agent.  The VNTM is also closely associated with the PCE for
   the upper-layer network and each of the PCEs for the lower-layer
   networks.

2.3.1.11.  Provisioning Manager

   The Provisioning Manager is responsible for making or channeling
   requests for the establishment of LSPs.  This may be instructions to
   the control plane running in the networks or may involve the
   programming of individual network devices.  In the latter case, the
   Provisioning Manager may act as an OpenFlow Controller [ONF].

   See Section 2.3.2.6 for more details of the interactions between the
   Provisioning Manager and the network.

2.3.1.12.  Client and Server Network Layers

   The client and server networks are shown in Figure 1 as illustrative
   examples of the fact that the ABNO architecture may be used to
   coordinate services across multiple networks where lower-layer
   networks provide connectivity in upper-layer networks.

   Section 3.2 describes a set of use cases for multi-layer networking.

2.3.2.  Functional Interfaces

   This section describes the interfaces between functional components
   that might be externalized in an implementation allowing the
   components to be distributed across platforms.  Where existing
   protocols might provide all or most of the necessary capabilities,
   they are noted.  Appendix A notes the interfaces where more protocol
   specification may be needed.

Top      ToC       Page 16 
   As noted at the top of Section 2.3, it is important to understand
   that the relationships and interfaces shown between components in
   Figure 1 are illustrative of some of the common or likely
   interactions; however, this figure and the descriptions in the
   subsections below do not preclude other interfaces and relationships
   as necessary to realize specific functionality.  Thus, some of the
   interfaces described below might not be visible as specific
   relationships in Figure 1, but they can nevertheless exist.

2.3.2.1.  Configuration and Programmatic Interfaces

   The network devices may be configured or programmed directly from the
   NMS/OSS.  Many protocols already exist to perform these functions,
   including the following:

   - SNMP [RFC3412]

   - The Network Configuration Protocol (NETCONF) [RFC6241]

   - RESTCONF [RESTCONF]

   - The General Switch Management Protocol (GSMP) [RFC3292]

   - ForCES [RFC5810]

   - OpenFlow [ONF]

   - PCEP [PCE-Init-LSP]

   The TeleManagement Forum (TMF) Multi-Technology Operations Systems
   Interface (MTOSI) standard [TMF-MTOSI] was developed to facilitate
   application-to-application interworking and provides network-level
   management capabilities to discover, configure, and activate
   resources.  Initially, the MTOSI information model was only capable
   of representing connection-oriented networks and resources.  In later
   releases, support was added for connectionless networks.  MTOSI is,
   from the NMS perspective, a north-bound interface and is based on
   SOAP web services.

   From the ABNO perspective, network configuration is a pass-through
   function.  It can be seen represented on the left-hand side of
   Figure 1.

2.3.2.2.  TED Construction from the Networks

   As described in Section 2.3.1.8, the TED provides details of the
   capabilities and state of the network for use by the ABNO system and
   the PCE in particular.

Top      ToC       Page 17 
   The TED can be constructed by participating in the IGP-TE protocols
   run by the networks (for example, OSPF-TE [RFC3630] and IS-IS TE
   [RFC5305]).  Alternatively, the TED may be fed using link-state
   distribution extensions to BGP [BGP-LS].

   The ABNO system may maintain a single TED unified across multiple
   networks or may retain a separate TED for each network.

   Additionally, an ALTO Server [RFC5693] may provide an abstracted
   topology from a network to build an application-level TED that can be
   used by a PCE to compute paths between servers and application-layer
   entities for the provision of application services.

2.3.2.3.  TED Enhancement

   The TED may be enhanced by inventory information supplied from the
   NMS/OSS.  This may supplement the data collected as described in
   Section 2.3.2.2 with information that is not normally distributed
   within the network, such as node types and capabilities, or the
   characteristics of optical links.

   No protocol is currently identified for this interface, but the
   protocol developed or adopted to satisfy the requirements of the
   Interface to the Routing System (I2RS) [I2RS-Arch] may be a suitable
   candidate because it is required to be able to distribute bulk
   routing state information in a well-defined encoding language.
   Another candidate protocol may be NETCONF [RFC6241] passing data
   encoded using YANG [RFC6020].

   Note that, in general, any combination of protocol and encoding that
   is suitable for presenting the TED as described in Section 2.3.2.4
   will likely be suitable (or could be made suitable) for enabling
   write-access to the TED as described in this section.

2.3.2.4.  TED Presentation

   The TED may be presented north-bound from the ABNO system for use by
   an NMS/OSS or by the Application Service Coordinator.  This allows
   users and applications to get a view of the network topology and the
   status of the network resources.  It also allows planning and
   provisioning of application services.

   There are several protocols available for exporting the TED north-
   bound:

   - The ALTO protocol [RFC7285] is designed to distribute the
     abstracted topology used by an ALTO Server and may prove useful for
     exporting the TED.  The ALTO Server provides the cost between EPs

Top      ToC       Page 18 
     or between PIDs, so the application layer can select which is the
     most appropriate connection for the information exchange between
     its application end points.

   - The same protocol used to export topology information from the
     network can be used to export the topology from the TED [BGP-LS].

   - The I2RS [I2RS-Arch] will require a protocol that is capable of
     handling bulk routing information exchanges that would be suitable
     for exporting the TED.  In this case, it would make sense to have a
     standardized representation of the TED in a formal data modeling
     language such as YANG [RFC6020] so that an existing protocol such
     as NETCONF [RFC6241] or the Extensible Messaging and Presence
     Protocol (XMPP) [RFC6120] could be used.

   Note that export from the TED can be a full dump of the content
   (expressed in a suitable abstraction language) as described above, or
   it could be an aggregated or filtered set of data based on policies
   or specific requirements.  Thus, the relationships shown in Figure 1
   may be a little simplistic in that the ABNO Controller may also be
   involved in preparing and presenting the TED information over a
   north-bound interface.

2.3.2.5.  Path Computation Requests from the Network

   As originally specified in the PCE architecture [RFC4655], network
   elements can make path computation requests to a PCE using PCEP
   [RFC5440].  This facilitates the network setting up LSPs in response
   to simple connectivity requests, and it allows the network to
   reoptimize or repair LSPs.

2.3.2.6.  Provisioning Manager Control of Networks

   As described in Section 2.3.1.11, the Provisioning Manager makes or
   channels requests to provision resources in the network.  These
   operations can take place at two levels: there can be requests to
   program/configure specific resources in the data or forwarding
   planes, and there can be requests to trigger a set of actions to be
   programmed with the assistance of a control plane.

Top      ToC       Page 19 
   A number of protocols already exist to provision network resources,
   as follows:

   o  Program/configure specific network resources

      - ForCES [RFC5810] defines a protocol for separation of the
        control element (the Provisioning Manager) from the forwarding
        elements in each node in the network.

      - The General Switch Management Protocol (GSMP) [RFC3292] is an
        asymmetric protocol that allows one or more external switch
        controllers (such as the Provisioning Manager) to establish and
        maintain the state of a label switch such as an MPLS switch.

      - OpenFlow [ONF] is a communications protocol that gives an
        OpenFlow Controller (such as the Provisioning Manager) access to
        the forwarding plane of a network switch or router in the
        network.

      - Historically, other configuration-based mechanisms have been
        used to set up the forwarding/switching state at individual
        nodes within networks.  Such mechanisms have ranged from
        non-standard command line interfaces (CLIs) to various
        standards-based options such as Transaction Language 1 (TL1)
        [TL1] and SNMP [RFC3412].  These mechanisms are not designed for
        rapid operation of a network and are not easily programmatic.
        They are not proposed for use by the Provisioning Manager as
        part of the ABNO architecture.

      - NETCONF [RFC6241] provides a more active configuration protocol
        that may be suitable for bulk programming of network resources.
        Its use in this way is dependent on suitable YANG modules being
        defined for the necessary options.  Early work in the IETF's
        NETMOD working group is focused on a higher level of routing
        function more comparable with the function discussed in
        Section 2.3.2.8; see [YANG-Rtg].

      - The [TMF-MTOSI] specification provides provisioning, activation,
        deactivation, and release of resources via the Service
        Activation Interface (SAI).  The Common Communication Vehicle
        (CCV) is the middleware required to implement MTOSI.  The CCV is
        then used to provide middleware abstraction in combination with
        the Web Services Description Language (WSDL) to allow MTOSIs to
        be bound to different middleware technologies as needed.

Top      ToC       Page 20 
   o  Trigger actions through the control plane

      - LSPs can be requested using a management system interface to the
        head end of the LSP using tools such as CLIs, TL1 [TL1], or SNMP
        [RFC3412].  Configuration at this granularity is not as time-
        critical as when individual network resources are programmed,
        because the main task of programming end-to-end connectivity is
        devolved to the control plane.  Nevertheless, these mechanisms
        remain unsuitable for programmatic control of the network and
        are not proposed for use by the Provisioning Manager as part of
        the ABNO architecture.

      - As noted above, NETCONF [RFC6241] provides a more active
        configuration protocol.  This may be particularly suitable for
        requesting the establishment of LSPs.  Work would be needed to
        complete a suitable YANG module.

      - The PCE Communication Protocol (PCEP) [RFC5440] has been
        proposed as a suitable protocol for requesting the establishment
        of LSPs [PCE-Init-LSP].  This works well, because the protocol
        elements necessary are exactly the same as those used to respond
        to a path computation request.

        The functional element that issues PCEP requests to establish
        LSPs is known as an "Active PCE"; however, it should be noted
        that the ABNO functional component responsible for requesting
        LSPs is the Provisioning Manager.  Other controllers like the
        VNTM and the ABNO Controller use the services of the
        Provisioning Manager to isolate the twin functions of computing
        and requesting paths from the provisioning mechanisms in place
        with any given network.

   Note that I2RS does not provide a mechanism for control of network
   resources at this level, as it is designed to provide control of
   routing state in routers, not forwarding state in the data plane.

Top      ToC       Page 21 
2.3.2.7.  Auditing the Network

   Once resources have been provisioned or connections established in
   the network, it is important that the ABNO system can determine the
   state of the network.  Similarly, when provisioned resources are
   modified or taken out of service, the changes in the network need to
   be understood by the ABNO system.  This function falls into four
   categories:

   - Updates to the TED are gathered as described in Section 2.3.2.2.

   - Explicit notification of the successful establishment and the
     subsequent state of the LSP can be provided through extensions to
     PCEP as described in [Stateful-PCE] and [PCE-Init-LSP].

   - OAM can be commissioned and the results inspected by the OAM
     Handler as described in Section 2.3.2.14.

   - A number of ABNO components may make inquiries and inspect network
     state through a variety of techniques, including I2RS, NETCONF, or
     SNMP.

2.3.2.8.  Controlling the Routing System

   As discussed in Section 2.3.1.5, the Interface to the Routing System
   (I2RS) provides a programmatic way to access (for read and write) the
   routing state and policy information on routers in the network.  The
   I2RS Client issues requests to routers in the network to establish or
   retrieve routing state.  Those requests utilize the I2RS protocol,
   which will be based on a combination of NETCONF [RFC6241] and
   RESTCONF [RESTCONF] with some additional features.

2.3.2.9.  ABNO Controller Interface to PCE

   The ABNO Controller needs to be able to consult the PCE to determine
   what services can be provisioned in the network.  There is no reason
   why this interface cannot be based on standard PCEP as defined in
   [RFC5440].

2.3.2.10.  VNTM Interface to and from PCE

   There are two interactions between the Virtual Network Topology
   Manager and the PCE:

   The first interaction is used when VNTM wants to determine what LSPs
   can be set up in a network: in this case, it uses the standard PCEP
   interface [RFC5440] to make path computation requests.

Top      ToC       Page 22 
   The second interaction arises when a PCE determines that it cannot
   compute a requested path or notices that (according to some
   configured policy) a network is low on resources (for example, the
   capacity on some key link is nearly exhausted).  In this case, the
   PCE may notify the VNTM, which may (again according to policy) act to
   construct more virtual topology.  This second interface is not
   currently specified, although it may be that the protocol selected or
   designed to satisfy I2RS will provide suitable features (see
   Section 2.3.2.8); alternatively, an extension to the PCEP Notify
   message (PCNtf) [RFC5440] could be made.

2.3.2.11.  ABNO Control Interfaces

   The north-bound interface from the ABNO Controller is used by the
   NMS, OSS, and Application Service Coordinator to request services in
   the network in support of applications.  The interface will also need
   to be able to report the asynchronous completion of service requests
   and convey changes in the status of services.

   This interface will also need strong capabilities for security,
   authentication, and policy.

   This interface is not currently specified.  It needs to be a
   transactional interface that supports the specification of abstract
   services with adequate flexibility to facilitate easy extension and
   yet be concise and easily parsable.

   It is possible that the protocol designed to satisfy I2RS will
   provide suitable features (see Section 2.3.2.8).

2.3.2.12.  ABNO Provisioning Requests

   Under some circumstances, the ABNO Controller may make requests
   directly to the Provisioning Manager.  For example, if the
   Provisioning Manager is acting as an SDN Controller, then the ABNO
   Controller may use one of the APIs defined to allow requests to be
   made to the SDN Controller (such as the Floodlight REST API [Flood]).
   Alternatively, since the Provisioning Manager may also receive
   instructions from a Stateful PCE, the use of PCEP extensions might be
   appropriate in some cases [PCE-Init-LSP].

Top      ToC       Page 23 
2.3.2.13.  Policy Interfaces

   As described in Section 2.3.1.4 and throughout this document, policy
   forms a critical component of the ABNO architecture.  The role of
   policy will include enforcing the following rules and requirements:

   - Adding resources on demand should be gated by the authorized
     capability.

   - Client microflows should not trigger server-layer setup or
     allocation.

   - Accounting capabilities should be supported.

   - Security mechanisms for authorization of requests and capabilities
     are required.

   Other policy-related functionality in the system might include the
   policy behavior of the routing and forwarding system, such as:

   - ECMP behavior

   - Classification of packets onto LSPs or QoS categories.

   Various policy-capable architectures have been defined, including a
   framework for using policy with a PCE-enabled system [RFC5394].
   However, the take-up of the IETF's Common Open Policy Service
   protocol (COPS) [RFC2748] has been poor.

   New work will be needed to define all of the policy interfaces within
   the ABNO architecture.  Work will also be needed to determine which
   are internal interfaces and which may be external and so in need of a
   protocol specification.  There is some discussion that the I2RS
   protocol may support the configuration and manipulation of policies.

2.3.2.14.  OAM and Reporting

   The OAM Handler must interact with the network to perform several
   actions:

   - Enabling OAM function within the network.

   - Performing proactive OAM operations in the network.

   - Receiving notifications of network events.

Top      ToC       Page 24 
   Any of the configuration and programmatic interfaces described in
   Section 2.3.2.1 may serve this purpose.  NETCONF notifications are
   described in [RFC5277], and OpenFlow supports a number of
   asynchronous event notifications [ONF].  Additionally, Syslog
   [RFC5424] is a protocol for reporting events from the network, and IP
   Flow Information Export (IPFIX) [RFC7011] is designed to allow
   network statistics to be aggregated and reported.

   The OAM Handler also correlates events reported from the network and
   reports them onward to the ABNO Controller (which can apply the
   information to the recovery of services that it has provisioned) and
   to the NMS, OSS, and Application Service Coordinator.  The reporting
   mechanism used here can be essentially the same as the mechanism used
   when events are reported from the network; no new protocol is needed,
   although new data models may be required for technology-independent
   OAM reporting.



(page 24 continued on part 2)

Next RFC Part