summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7491.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7491.txt')
-rw-r--r--doc/rfc/rfc7491.txt3979
1 files changed, 3979 insertions, 0 deletions
diff --git a/doc/rfc/rfc7491.txt b/doc/rfc/rfc7491.txt
new file mode 100644
index 0000000..57011b7
--- /dev/null
+++ b/doc/rfc/rfc7491.txt
@@ -0,0 +1,3979 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+King & Farrel Informational [Page 1]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 2]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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
+
+
+
+
+
+King & Farrel Informational [Page 3]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+King & Farrel Informational [Page 4]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ - 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.
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 5]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 6]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 7]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +----------------------------------------------------------------+
+ | 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.
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 8]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 9]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+King & Farrel Informational [Page 10]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+King & Farrel Informational [Page 11]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+
+King & Farrel Informational [Page 12]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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
+
+
+
+King & Farrel Informational [Page 13]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+
+
+
+
+King & Farrel Informational [Page 14]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+King & Farrel Informational [Page 15]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+King & Farrel Informational [Page 16]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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
+
+
+
+King & Farrel Informational [Page 17]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 18]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+
+
+
+
+King & Farrel Informational [Page 19]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 20]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+King & Farrel Informational [Page 21]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 22]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+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.
+
+
+
+
+
+
+King & Farrel Informational [Page 23]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 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.
+
+3. ABNO Use Cases
+
+ This section provides a number of examples of how the ABNO
+ architecture can be applied to provide application-driven and
+ NMS/OSS-driven network operations. The purpose of these examples is
+ to give some concrete material to demonstrate the architecture so
+ that it may be more easily comprehended, and to illustrate that the
+ application of the architecture is achieved by "profiling" and by
+ selecting only the relevant components and interfaces.
+
+ Similarly, it is not the intention that this section contain a
+ complete list of all possible applications of ABNO. The examples are
+ intended to broadly cover a number of applications that are commonly
+ discussed, but this does not preclude other use cases.
+
+ The descriptions in this section are not fully detailed applicability
+ statements for ABNO. It is anticipated that such applicability
+ statements, for the use cases described and for other use cases,
+ could be suitable material for separate documents.
+
+3.1. Inter-AS Connectivity
+
+ The following use case describes how the ABNO framework can be used
+ to set up an end-to-end MPLS service across multiple Autonomous
+ Systems (ASes). Consider the simple network topology shown in
+ Figure 2. The three ASes (ASa, ASb, and ASc) are connected at AS
+ Border Routers (ASBRs) a1, a2, b1 through b4, c1, and c2. A source
+ node (s) located in ASa is to be connected to a destination node (d)
+ located in ASc. The optimal path for the LSP from s to d must be
+ computed, and then the network must be triggered to set up the LSP.
+
+
+
+
+King & Farrel Informational [Page 24]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +--------------+ +-----------------+ +--------------+
+ |ASa | | ASb | | ASc |
+ | +--+ | | +--+ +--+ | | +--+ |
+ | |a1|-|-|-|b1| |b3|-|-|-|c1| |
+ | +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
+ | |s| | | | | |d| |
+ | +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
+ | |a2|-|-|-|b2| |b4|-|-|-|c2| |
+ | +--+ | | +--+ +--+ | | +--+ |
+ | | | | | |
+ +--------------+ +-----------------+ +--------------+
+
+ Figure 2: Inter-AS Domain Topology with Hierarchical PCE (Parent PCE)
+
+ The following steps are performed to deliver the service within the
+ ABNO architecture:
+
+ 1. Request Management
+
+ As shown in Figure 3, the NMS/OSS issues a request to the ABNO
+ Controller for a path between s and d. The ABNO Controller
+ verifies that the NMS/OSS has sufficient rights to make the
+ service request.
+
+ +---------------------+
+ | NMS/OSS |
+ +----------+----------+
+ |
+ V
+ +--------+ +-----------+-------------+
+ | Policy +-->-+ ABNO Controller |
+ | Agent | | |
+ +--------+ +-------------------------+
+
+ Figure 3: ABNO Request Management
+
+ 2. Service Path Computation with Hierarchical PCE
+
+ The ABNO Controller needs to determine an end-to-end path for the
+ LSP. Since the ASes will want to maintain a degree of
+ confidentiality about their internal resources and topology, they
+ will not share a TED and each will have its own PCE. In such a
+ situation, the Hierarchical PCE (H-PCE) architecture described in
+ [RFC6805] is applicable.
+
+ As shown in Figure 4, the ABNO Controller sends a request to the
+ parent PCE for an end-to-end path. As described in [RFC6805], the
+ parent PCE consults its TED, which shows the connectivity between
+
+
+
+King & Farrel Informational [Page 25]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ ASes. This helps it understand that the end-to-end path must
+ cross each of ASa, ASb, and ASc, so it sends individual path
+ computation requests to each of PCEs a, b, and c to determine the
+ best options for crossing the ASes.
+
+ Each child PCE applies policy to the requests it receives to
+ determine whether the request is to be allowed and to select the
+ types of network resources that can be used in the computation
+ result. For confidentiality reasons, each child PCE may supply
+ its computation responses using a path key [RFC5520] to hide the
+ details of the path segment it has computed.
+
+ +-----------------+
+ | ABNO Controller |
+ +----+-------+----+
+ | A
+ V |
+ +--+-------+--+ +--------+
+ +--------+ | | | |
+ | Policy +-->-+ Parent PCE +---+ AS TED |
+ | Agent | | | | |
+ +--------+ +-+----+----+-+ +--------+
+ / | \
+ / | \
+ +-----+-+ +---+---+ +-+-----+
+ | | | | | |
+ | PCE a | | PCE b | | PCE c |
+ | | | | | |
+ +---+---+ +---+---+ +---+---+
+ | | |
+ +--+--+ +--+--+ +--+--+
+ | TEDa| | TEDb| | TEDc|
+ +-----+ +-----+ +-----+
+
+ Figure 4: Path Computation Request with Hierarchical PCE
+
+ The parent PCE collates the responses from the children and
+ applies its own policy to stitch them together into the best
+ end-to-end path, which it returns as a response to the ABNO
+ Controller.
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 26]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 3. Provisioning the End-to-End LSP
+
+ There are several options for how the end-to-end LSP gets
+ provisioned in the ABNO architecture. Some of these are described
+ below.
+
+ 3a. Provisioning from the ABNO Controller with a Control Plane
+
+ Figure 5 shows how the ABNO Controller makes a request through
+ the Provisioning Manager to establish the end-to-end LSP. As
+ described in Section 2.3.2.6, these interactions can use the
+ NETCONF protocol [RFC6241] or the extensions to PCEP described
+ in [PCE-Init-LSP]. In either case, the provisioning request
+ is sent to the head-end Label Switching Router (LSR), and that
+ LSR signals in the control plane (using a protocol such as
+ RSVP-TE [RFC3209]) to cause the LSP to be established.
+
+ +-----------------+
+ | ABNO Controller |
+ +--------+--------+
+ |
+ V
+ +------+-------+
+ | Provisioning |
+ | Manager |
+ +------+-------+
+ |
+ V
+ +--------------------+------------------------+
+ / Network \
+ +-------------------------------------------------+
+
+ Figure 5: Provisioning the End-to-End LSP
+
+ 3b. Provisioning through Programming Network Resources
+
+ Another option is that the LSP is provisioned hop by hop from
+ the Provisioning Manager using a mechanism such as ForCES
+ [RFC5810] or OpenFlow [ONF] as described in Section 2.3.2.6.
+ In this case, the picture is the same as that shown in
+ Figure 5. The interaction between the ABNO Controller and the
+ Provisioning Manager will be PCEP or NETCONF as described in
+ option 3a, and the Provisioning Manager will be responsible
+ for fanning out the requests to the individual network
+ elements.
+
+
+
+
+
+
+King & Farrel Informational [Page 27]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 3c. Provisioning with an Active Parent PCE
+
+ The Active PCE is described in Section 2.3.1.7, based on the
+ concepts expressed in [PCE-Init-LSP]. In this approach, the
+ process described in option 3a is modified such that the PCE
+ issues a direct PCEP command to the network, without a
+ response being first returned to the ABNO Controller.
+
+ This situation is shown in Figure 6 and could be modified so
+ that the Provisioning Manager still programs the individual
+ network elements as described in option 3b.
+
+ +-----------------+
+ | ABNO Controller |
+ +----+------------+
+ |
+ V
+ +--+----------+ +--------------+
+ +--------+ | | | Provisioning |
+ | Policy +-->-+ Parent PCE +---->----+ Manager |
+ | Agent | | | | |
+ +--------+ +-+----+----+-+ +-----+--------+
+ / | \ |
+ / | \ |
+ +-----+-+ +---+---+ +-+-----+ V
+ | | | | | | |
+ | PCE a | | PCE b | | PCE c | |
+ | | | | | | |
+ +-------+ +-------+ +-------+ |
+ |
+ +--------------------------------+------------+
+ / Network \
+ +-------------------------------------------------+
+
+ Figure 6: LSP Provisioning with an Active PCE
+
+ 3d. Provisioning with Active Child PCEs and Segment Stitching
+
+ A mixture of the approaches described in options 3b and 3c can
+ result in a combination of mechanisms to program the network
+ to provide the end-to-end LSP. Figure 7 shows how each child
+ PCE can be an Active PCE responsible for setting up an edge-
+ to-edge LSP segment across one of the ASes. The ABNO
+ Controller then uses the Provisioning Manager to program the
+ inter-AS connections using ForCES or OpenFlow, and the LSP
+ segments are stitched together following the ideas described
+ in [RFC5150]. Philosophers may debate whether the parent PCE
+
+
+
+
+King & Farrel Informational [Page 28]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ in this model is active (instructing the children to provision
+ LSP segments) or passive (requesting path segments that the
+ children provision).
+
+ +-----------------+
+ | ABNO Controller +-------->--------+
+ +----+-------+----+ |
+ | A |
+ V | |
+ +--+-------+--+ |
+ +--------+ | | |
+ | Policy +-->-+ Parent PCE | |
+ | Agent | | | |
+ +--------+ ++-----+-----++ |
+ / | \ |
+ / | \ |
+ +---+-+ +--+--+ +-+---+ |
+ | | | | | | |
+ |PCE a| |PCE b| |PCE c| |
+ | | | | | | V
+ +--+--+ +--+--+ +---+-+ |
+ | | | |
+ V V V |
+ +----------+-+ +------------+ +-+----------+ |
+ |Provisioning| |Provisioning| |Provisioning| |
+ |Manager | |Manager | |Manager | |
+ +-+----------+ +-----+------+ +-----+------+ |
+ | | | |
+ V V V |
+ +--+-----+ +----+---+ +--+-----+ |
+ / AS a \=====/ AS b \=====/ AS c \ |
+ +------------+ A +------------+ A +------------+ |
+ | | |
+ +-----+----------------+-----+ |
+ | Provisioning Manager +----<-------+
+ +----------------------------+
+
+ Figure 7: LSP Provisioning with Active Child PCEs and Stitching
+
+ 4. Verification of Service
+
+ The ABNO Controller will need to ascertain that the end-to-end LSP
+ has been set up as requested. In the case of a control plane
+ being used to establish the LSP, the head-end LSR may send a
+ notification (perhaps using PCEP) to report successful setup, but
+ to be sure that the LSP is up, the ABNO Controller will request
+ the OAM Handler to perform Continuity Check OAM in the data plane
+ and report back that the LSP is ready to carry traffic.
+
+
+
+King & Farrel Informational [Page 29]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 5. Notification of Service Fulfillment
+
+ Finally, when the ABNO Controller is satisfied that the requested
+ service is ready to carry traffic, it will notify the NMS/OSS.
+ The delivery of the service may be further checked through
+ auditing the network, as described in Section 2.3.2.7.
+
+3.2. Multi-Layer Networking
+
+ Networks are typically constructed using multiple layers. These
+ layers represent separations of administrative regions or of
+ technologies and may also represent a distinction between client and
+ server networking roles.
+
+ It is preferable to coordinate network resource control and
+ utilization (i.e., consideration and control of multiple layers),
+ rather than controlling and optimizing resources at each layer
+ independently. This facilitates network efficiency and network
+ automation and may be defined as inter-layer traffic engineering.
+
+ The PCE architecture supports inter-layer traffic engineering
+ [RFC5623] and, in combination with the ABNO architecture, provides a
+ suite of capabilities for network resource coordination across
+ multiple layers.
+
+ The following use case demonstrates ABNO used to coordinate
+ allocation of server-layer network resources to create virtual
+ topology in a client-layer network in order to satisfy a request for
+ end-to-end client-layer connectivity. Consider the simple multi-
+ layer network in Figure 8.
+
+ +--+ +--+ +--+ +--+ +--+ +--+
+ |P1|---|P2|---|P3| |P4|---|P5|---|P6|
+ +--+ +--+ +--+ +--+ +--+ +--+
+ \ /
+ \ /
+ +--+ +--+ +--+
+ |L1|--|L2|--|L3|
+ +--+ +--+ +--+
+
+ Figure 8: Multi-Layer Network
+
+ There are six packet-layer routers (P1 through P6) and three optical-
+ layer lambda switches (L1 through L3). There is connectivity in the
+ packet layer between routers P1, P2, and P3, and also between routers
+ P4, P5, and P6, but there is no packet-layer connectivity between
+ these two islands of routers, perhaps because of a network failure or
+ perhaps because all existing bandwidth between the islands has
+
+
+
+King & Farrel Informational [Page 30]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ already been used up. However, there is connectivity in the optical
+ layer between switches L1, L2, and L3, and the optical network is
+ connected out to routers P3 and P4 (they have optical line cards).
+ In this example, a packet-layer connection (an MPLS LSP) is desired
+ between P1 and P6.
+
+ In the ABNO architecture, the following steps are performed to
+ deliver the service.
+
+ 1. Request Management
+
+ As shown in Figure 9, the Application Service Coordinator issues a
+ request for connectivity from P1 to P6 in the packet-layer
+ network. That is, the Application Service Coordinator requests an
+ MPLS LSP with a specific bandwidth to carry traffic for its
+ application. The ABNO Controller verifies that the Application
+ Service Coordinator has sufficient rights to make the service
+ request.
+
+ +---------------------------+
+ | Application Service |
+ | Coordinator |
+ +-------------+-------------+
+ |
+ V
+ +------+ +------------+------------+
+ |Policy+->-+ ABNO Controller |
+ |Agent | | |
+ +------+ +-------------------------+
+
+ Figure 9: Application Service Coordinator Request Management
+
+ 2. Service Path Computation in the Packet Layer
+
+ The ABNO Controller sends a path computation request to the
+ packet-layer PCE to compute a suitable path for the requested LSP,
+ as shown in Figure 10. The PCE uses the appropriate policy for
+ the request and consults the TED for the packet layer. It
+ determines that no path is immediately available.
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 31]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +-----------------+
+ | ABNO Controller |
+ +----+------------+
+ |
+ V
+ +--------+ +--+-----------+ +--------+
+ | Policy +-->--+ Packet-Layer +---+ Packet |
+ | Agent | | PCE | | TED |
+ +--------+ +--------------+ +--------+
+
+ Figure 10: Path Computation Request
+
+ 3. Invocation of VNTM and Path Computation in the Optical Layer
+
+ After the path computation failure in step 2, instead of notifying
+ the ABNO Controller of the failure, the PCE invokes the VNTM to
+ see whether it can create the necessary link in the virtual
+ network topology to bridge the gap.
+
+ As shown in Figure 11, the packet-layer PCE reports the
+ connectivity problem to the VNTM, and the VNTM consults policy to
+ determine what it is allowed to do. Assuming that the policy
+ allows it, the VNTM asks the optical-layer PCE to find a path
+ across the optical network that could be provisioned to provide a
+ virtual link for the packet layer. In addressing this request,
+ the optical-layer PCE consults a TED for the optical-layer
+ network.
+
+ +------+
+ +--------+ | | +--------------+
+ | Policy +-->--+ VNTM +--<--+ Packet-Layer |
+ | Agent | | | | PCE |
+ +--------+ +---+--+ +--------------+
+ |
+ V
+ +---------------+ +---------+
+ | Optical-Layer +---+ Optical |
+ | PCE | | TED |
+ +---------------+ +---------+
+
+ Figure 11: Invocation of VNTM and Optical-Layer Path Computation
+
+ 4. Provisioning in the Optical Layer
+
+ Once a path has been found across the optical-layer network, it
+ needs to be provisioned. The options follow those in step 3 of
+ Section 3.1. That is, provisioning can be initiated by the
+ optical-layer PCE or by its user, the VNTM. The command can be
+
+
+
+King & Farrel Informational [Page 32]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ sent to the head end of the optical LSP (P3) so that the control
+ plane (for example, GMPLS RSVP-TE [RFC3473]) can be used to
+ provision the LSP. Alternatively, the network resources can be
+ provisioned directly, using any of the mechanisms described in
+ Section 2.3.2.6.
+
+ 5. Creation of Virtual Topology in the Packet Layer
+
+ Once the LSP has been set up in the optical layer, it can be made
+ available in the packet layer as a virtual link. If the GMPLS
+ signaling used the mechanisms described in [RFC6107], this process
+ can be automated within the control plane; otherwise, it may
+ require a specific instruction to the head-end router of the
+ optical LSP (for example, through I2RS).
+
+ Once the virtual link is created as shown in Figure 12, it is
+ advertised in the IGP for the packet-layer network, and the link
+ will appear in the TED for the packet-layer network.
+
+ +--------+
+ | Packet |
+ | TED |
+ +------+-+
+ A
+ |
+ +--+ +--+
+ |P3|....................|P4|
+ +--+ +--+
+ \ /
+ \ /
+ +--+ +--+ +--+
+ |L1|--|L2|--|L3|
+ +--+ +--+ +--+
+
+ Figure 12: Advertisement of a New Virtual Link
+
+ 6. Path Computation Completion and Provisioning in the Packet Layer
+
+ Now there are sufficient resources in the packet-layer network.
+ The PCE for the packet layer can complete its work, and the MPLS
+ LSP can be provisioned as described in Section 3.1.
+
+ 7. Verification and Notification of Service Fulfillment
+
+ As discussed in Section 3.1, the ABNO Controller will need to
+ verify that the end-to-end LSP has been correctly established
+ before reporting service fulfillment to the Application Service
+ Coordinator.
+
+
+
+King & Farrel Informational [Page 33]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ Furthermore, it is highly likely that service verification will be
+ necessary before the optical-layer LSP can be put into service as
+ a virtual link. Thus, the VNTM will need to coordinate with the
+ OAM Handler to ensure that the LSP is ready for use.
+
+3.2.1. Data Center Interconnection across Multi-Layer Networks
+
+ In order to support new and emerging cloud-based applications, such
+ as real-time data backup, virtual machine migration, server
+ clustering, or load reorganization, the dynamic provisioning and
+ allocation of IT resources and the interconnection of multiple,
+ remote Data Centers (DCs) is a growing requirement.
+
+ These operations require traffic being delivered between data
+ centers, and, typically, the connections providing such inter-DC
+ connectivity are provisioned using static circuits or dedicated
+ leased lines, leading to an inefficiency in terms of resource
+ utilization. Moreover, a basic requirement is that such a group of
+ remote DCs can be operated logically as one.
+
+ In such environments, the data plane technology is operator and
+ provider dependent. Their customers may rent lambda switch capable
+ (LSC), packet switch capable (PSC), or time division multiplexing
+ (TDM) services, and the application and usage of the ABNO
+ architecture and Controller enable the required dynamic end-to-end
+ network service provisioning, regardless of underlying service and
+ transport layers.
+
+ Consequently, the interconnection of DCs may involve the operation,
+ control, and management of heterogeneous environments: each DC site
+ and the metro-core network segment used to interconnect them, with
+ regard to not only the underlying data plane technology but also the
+ control plane. For example, each DC site or domain could be
+ controlled locally in a centralized way (e.g., via OpenFlow [ONF]),
+ whereas the metro-core transport infrastructure is controlled by
+ GMPLS. Although OpenFlow is specially adapted to single-domain
+ intra-DC networks (packet-level control, lots of routing exceptions),
+ a standardized GMPLS-based architecture would enable dynamic optical
+ resource allocation and restoration in multi-domain (e.g., multi-
+ vendor) core networks interconnecting distributed data centers.
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 34]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ The application of an ABNO architecture and related procedures would
+ involve the following aspects:
+
+ 1. Request from the Application Service Coordinator or NMS
+
+ As shown in Figure 13, the ABNO Controller receives a request from
+ the Application Service Coordinator or from the NMS, in order to
+ create a new end-to-end connection between two end points. The
+ actual addressing of these end points is discussed in the next
+ section. The ABNO Controller asks the PCE for a path between
+ these two end points, after considering any applicable policy as
+ defined by the Policy Agent (see Figure 1).
+
+ +---------------------------+
+ | Application Service |
+ | Coordinator or NMS |
+ +-------------+-------------+
+ |
+ V
+ +------+ +------------+------------+
+ |Policy+->-+ ABNO Controller |
+ |Agent | | |
+ +------+ +-------------------------+
+
+ Figure 13: Application Service Coordinator Request Management
+
+ 2. Address Mapping
+
+ In order to compute an end-to-end path, the PCE needs to have a
+ unified view of the overall topology, which means that it has to
+ consider and identify the actual end points with regard to the
+ client network addresses. The ABNO Controller and/or the PCE may
+ need to translate or map addresses from different address spaces.
+ Depending on how the topology information is disseminated and
+ gathered, there are two possible scenarios:
+
+ 2a. The Application Layer Knows the Client Network Layer
+
+ Entities belonging to the application layer may have an
+ interface with the TED or with an ALTO Server allowing those
+ entities to map the high-level end points to network
+ addresses. The mechanism used to enable this address
+ correlation is out of scope for this document but relies on
+ direct interfaces to other ABNO components in addition to the
+ interface to the ABNO Controller.
+
+
+
+
+
+
+King & Farrel Informational [Page 35]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ In this scenario, the request from the NMS or Application
+ Service Coordinator contains addresses in the client-layer
+ network. Therefore, when the ABNO Controller requests the PCE
+ to compute a path between two end points, the PCE is able to
+ use the supplied addresses, compute the path, and continue the
+ workflow in communication with the Provisioning Manager.
+
+ 2b. The Application Layer Does Not Know the Client Network Layer
+
+ In this case, when the ABNO Controller receives a request from
+ the NMS or Application Service Coordinator, the request
+ contains only identifiers from the application-layer address
+ space. In order for the PCE to compute an end-to-end path,
+ these identifiers must be converted to addresses in the
+ client-layer network. This translation can be performed by
+ the ABNO Controller, which can access the TED and ALTO
+ databases allowing the path computation request that it sends
+ to the PCE to simply be contained within one network and TED.
+ Alternatively, the computation request could use the
+ application-layer identifiers, leaving the job of address
+ mapping to the PCE.
+
+ Note that in order to avoid any confusion both approaches in
+ this scenario require clear identification of the address
+ spaces that are in use.
+
+ 3. Provisioning Process
+
+ Once the path has been obtained, the Provisioning Manager receives
+ a high-level provisioning request to provision the service.
+ Since, in the considered use case, the network elements are not
+ necessarily configured using the same protocol, the end-to-end
+ path is split into segments, and the ABNO Controller coordinates
+ or orchestrates the establishment by adapting and/or translating
+ the abstract provisioning request to concrete segment requests by
+ means of a VNTM or PCE that issues the corresponding commands or
+ instructions. The provisioning may involve configuring the data
+ plane elements directly or delegating the establishment of the
+ underlying connection to a dedicated control plane instance
+ responsible for that segment.
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 36]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ The Provisioning Manager could use a number of mechanisms to
+ program the network elements, as shown in Figure 14. It learns
+ which technology is used for the actual provisioning at each
+ segment by either manual configuration or discovery.
+
+ +-----------------+
+ | ABNO Controller |
+ +-------+---------+
+ |
+ |
+ V
+ +------+ +------+-------+
+ | VNTM +--<--+ PCE |
+ +---+--+ +------+-------+
+ | |
+ V V
+ +-----+---------------+------------+
+ | Provisioning Manager |
+ +----------------------------------+
+ | | | | |
+ V | V | V
+ OpenFlow V ForCES V PCEP
+ NETCONF SNMP
+
+ Figure 14: Provisioning Process
+
+ 4. Verification and Notification of Service Fulfillment
+
+ Once the end-to-end connectivity service has been provisioned, and
+ after the verification of the correct operation of the service,
+ the ABNO Controller needs to notify the Application Service
+ Coordinator or NMS.
+
+3.3. Make-before-Break
+
+ A number of different services depend on the establishment of a new
+ LSP so that traffic supported by an existing LSP can be switched with
+ little or no disruption. This section describes those use cases,
+ presents a generic model for make-before-break within the ABNO
+ architecture, and shows how each use case can be supported by using
+ elements of the generic model.
+
+3.3.1. Make-before-Break for Reoptimization
+
+ Make-before-break is a mechanism supported in RSVP-TE signaling where
+ a new LSP is set up before the LSP it replaces is torn down
+ [RFC3209]. This process has several benefits in situations such as
+ reoptimization of in-service LSPs.
+
+
+
+King & Farrel Informational [Page 37]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ The process is simple, and the example shown in Figure 15 utilizes a
+ Stateful PCE [Stateful-PCE] to monitor the network and take
+ reoptimization actions when necessary. In this process, a service
+ request is made to the ABNO Controller by a requester such as the
+ OSS. The service request indicates that the LSP should be
+ reoptimized under specific conditions according to policy. This
+ allows the ABNO Controller to manage the sequence and prioritization
+ of reoptimizing multiple LSPs using elements of Global Concurrent
+ Optimization (GCO) as described in Section 3.4, and applying policies
+ across the network so that, for instance, LSPs for delay-sensitive
+ services are reoptimized first.
+
+ The ABNO Controller commissions the PCE to compute and set up the
+ initial path.
+
+ Over time, the PCE monitors the changes in the network as reflected
+ in the TED, and according to the configured policy may compute and
+ set up a replacement path, using make-before-break within the
+ network.
+
+ Once the new path has been set up and the network reports that it is
+ being used correctly, the PCE tears down the old path and may report
+ the reoptimization event to the ABNO Controller.
+
+ +---------------------------------------------+
+ | OSS / NMS / Application Service Coordinator |
+ +----------------------+----------------------+
+ |
+ +------------+------------+
+ | ABNO Controller |
+ +------------+------------+
+ |
+ +------+ +-------+-------+ +-----+
+ |Policy+-----+ PCE +-----+ TED |
+ |Agent | +-------+-------+ +-----+
+ +------+ |
+ |
+ +----------------------+----------------------+
+ / Network \
+ +-------------------------------------------------+
+
+ Figure 15: The Make-before-Break Process
+
+3.3.2. Make-before-Break for Restoration
+
+ Make-before-break may also be used to repair a failed LSP where there
+ is a desire to retain resources along some of the path, and where
+ there is the potential for other LSPs to "steal" the resources if the
+
+
+
+King & Farrel Informational [Page 38]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ failed LSP is torn down first. Unlike the example in Section 3.3.1,
+ this case addresses a situation where the service is interrupted, but
+ this interruption arises from the break in service introduced by the
+ network failure. Obviously, in the case of a point-to-multipoint
+ LSP, the failure might only affect part of the tree and the
+ disruption will only be to a subset of the destination leaves so that
+ a make-before-break restoration approach will not cause disruption to
+ the leaves that were not affected by the original failure.
+
+ Figure 16 shows the components that interact for this use case. A
+ service request is made to the ABNO Controller by a requester such as
+ the OSS. The service request indicates that the LSP may be restored
+ after failure and should attempt to reuse as much of the original
+ path as possible.
+
+ The ABNO Controller commissions the PCE to compute and set up the
+ initial path. The ABNO Controller also requests the OAM Handler to
+ initiate OAM on the LSP and to monitor the results.
+
+ At some point, the network reports a fault to the OAM Handler, which
+ notifies the ABNO Controller.
+
+ The ABNO Controller commissions the PCE to compute a new path,
+ reusing as much of the original path as possible, and the PCE sets up
+ the new LSP.
+
+ Once the new path has been set up and the network reports that it is
+ being used correctly, the ABNO Controller instructs the PCE to tear
+ down the old path.
+
+ +---------------------------------------------+
+ | OSS / NMS / Application Service Coordinator |
+ +----------------------+----------------------+
+ |
+ +------------+------------+ +-------+
+ | ABNO Controller +---+ OAM |
+ +------------+------------+ |Handler|
+ | +---+---+
+ +-------+-------+ |
+ | PCE | |
+ +-------+-------+ |
+ | |
+ +----------------------+--------------------+-+
+ / Network \
+ +-------------------------------------------------+
+
+ Figure 16: The Make-before-Break Restoration Process
+
+
+
+
+King & Farrel Informational [Page 39]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+3.3.3. Make-before-Break for Path Test and Selection
+
+ In a more complicated use case, an LSP may be monitored for a number
+ of attributes, such as delay and jitter. When the LSP falls below a
+ threshold, the traffic may be moved to another LSP that offers the
+ desired (or at least a better) quality of service. To achieve this,
+ it is necessary to establish the new LSP and test it, and because the
+ traffic must not be interrupted, make-before-break must be used.
+
+ Moreover, it may be the case that no new LSP can provide the desired
+ attributes and that a number of LSPs need to be tested so that the
+ best can be selected. Furthermore, even when the original LSP is set
+ up, it could be desirable to test a number of LSPs before deciding
+ which should be used to carry the traffic.
+
+ Figure 17 shows the components that interact for this use case.
+ Because multiple LSPs might exist at once, a distinct action is
+ needed to coordinate which one carries the traffic, and this is the
+ job of the I2RS Client acting under the control of the ABNO
+ Controller.
+
+ The OAM Handler is responsible for initiating tests on the LSPs and
+ for reporting the results back to the ABNO Controller. The OAM
+ Handler can also check end-to-end connectivity test results across a
+ multi-domain network even when each domain runs a different
+ technology. For example, an end-to-end path might be achieved by
+ stitching together an MPLS segment, an Ethernet/VLAN segment, another
+ IP segment, etc.
+
+ Otherwise, the process is similar to that for reoptimization as
+ discussed in Section 3.3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 40]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +---------------------------------------------+
+ | OSS / NMS / Application Service Coordinator |
+ +----------------------+----------------------+
+ |
+ +------+ +------------+------------+ +-------+
+ |Policy+---+ ABNO Controller +----+ OAM |
+ |Agent | | +--+ |Handler|
+ +------+ +------------+------------+ | +---+---+
+ | | |
+ +-------+-------+ +--+---+ |
+ | PCE | | I2RS | |
+ +-------+-------+ |Client| |
+ | +--+---+ |
+ | | |
+ +-----------------------+---------------+-----+-+
+ / Network \
+ +---------------------------------------------------+
+
+ Figure 17: The Make-before-Break Path Test and Selection Process
+
+ The pseudocode that follows gives an indication of the interactions
+ between ABNO components.
+
+ OSS requests quality-assured service
+
+ :Label1
+
+ DoWhile not enough LSPs (ABNO Controller)
+ Instruct PCE to compute and provision the LSP (ABNO Controller)
+ Create the LSP (PCE)
+ EndDo
+
+ :Label2
+
+ DoFor each LSP (ABNO Controller)
+ Test LSP (OAM Handler)
+ Report results to ABNO Controller (OAM Handler)
+ EndDo
+
+ Evaluate results of all tests (ABNO Controller)
+ Select preferred LSP and instruct I2RS Client (ABNO Controller)
+ Put traffic on preferred LSP (I2RS Client)
+
+ DoWhile too many LSPs (ABNO Controller)
+ Instruct PCE to tear down unwanted LSP (ABNO Controller)
+ Tear down unwanted LSP (PCE)
+ EndDo
+
+
+
+
+King & Farrel Informational [Page 41]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ DoUntil trigger (OAM Handler, ABNO Controller, Policy Agent)
+ keep sending traffic (Network)
+ Test LSP (OAM Handler)
+ EndDo
+
+ If there is already a suitable LSP (ABNO Controller)
+ GoTo Label2
+ Else
+ GoTo Label1
+ EndIf
+
+3.4. Global Concurrent Optimization
+
+ Global Concurrent Optimization (GCO) is defined in [RFC5557] and
+ represents a key technology for maximizing network efficiency by
+ computing a set of traffic-engineered paths concurrently. A GCO path
+ computation request will simultaneously consider the entire topology
+ of the network, and the complete set of new LSPs together with their
+ respective constraints. Similarly, GCO may be applied to recompute
+ the paths of a set of existing LSPs.
+
+ GCO may be requested in a number of scenarios. These include:
+
+ o Routing of new services where the PCE should consider other
+ services or network topology.
+
+ o A reoptimization of existing services due to fragmented network
+ resources or suboptimized placement of sequentially computed
+ services.
+
+ o Recovery of connectivity for bulk services in the event of a
+ catastrophic network failure.
+
+ A service provider may also want to compute and deploy new bulk
+ services based on a predicted traffic matrix. The GCO functionality
+ and capability to perform concurrent computation provide a
+ significant network optimization advantage, thus utilizing network
+ resources optimally and avoiding blocking.
+
+ The following use case shows how the ABNO architecture and components
+ are used to achieve concurrent optimization across a set of services.
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 42]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+3.4.1. Use Case: GCO with MPLS LSPs
+
+ When considering the GCO path computation problem, we can split the
+ GCO objective functions into three optimization categories:
+
+ o Minimize aggregate Bandwidth Consumption (MBC).
+
+ o Minimize the load of the Most Loaded Link (MLL).
+
+ o Minimize Cumulative Cost of a set of paths (MCC).
+
+ This use case assumes that the GCO request will be offline and be
+ initiated from an NMS/OSS; that is, it may take significant time to
+ compute the service, and the paths reported in the response may want
+ to be verified by the user before being provisioned within the
+ network.
+
+ 1. Request Management
+
+ The NMS/OSS issues a request for new service connectivity for bulk
+ services. The ABNO Controller verifies that the NMS/OSS has
+ sufficient rights to make the service request and apply a GCO
+ attribute with a request to Minimize aggregate Bandwidth
+ Consumption (MBC), as shown in Figure 18.
+
+ +---------------------+
+ | NMS/OSS |
+ +----------+----------+
+ |
+ V
+ +--------+ +-----------+-------------+
+ | Policy +-->-+ ABNO Controller |
+ | Agent | | |
+ +--------+ +-------------------------+
+
+ Figure 18: NMS Request to ABNO Controller
+
+ 1a. Each service request has a source, destination, and bandwidth
+ request. These service requests are sent to the ABNO
+ Controller and categorized as GCO requests. The PCE uses the
+ appropriate policy for each request and consults the TED for
+ the packet layer.
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 43]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 2. Service Path Computation in the Packet Layer
+
+ To compute a set of services for the GCO application, PCEP
+ supports synchronization vector (SVEC) lists for synchronized
+ dependent path computations as defined in [RFC5440] and described
+ in [RFC6007].
+
+ 2a. The ABNO Controller sends the bulk service request to the
+ GCO-capable packet-layer PCE using PCEP messaging. The PCE
+ uses the appropriate policy for the request and consults the
+ TED for the packet layer, as shown in Figure 19.
+
+ +-----------------+
+ | ABNO Controller |
+ +----+------------+
+ |
+ V
+ +--------+ +--+-----------+ +--------+
+ | | | | | |
+ | Policy +-->--+ GCO-Capable +---+ Packet |
+ | Agent | | Packet-Layer | | TED |
+ | | | PCE | | |
+ +--------+ +--------------+ +--------+
+
+ Figure 19: Path Computation Request from GCO-Capable PCE
+
+ 2b. Upon receipt of the bulk (GCO) service requests, the PCE
+ applies the MBC objective function and computes the services
+ concurrently.
+
+ 2c. Once the requested GCO service path computation completes, the
+ PCE sends the resulting paths back to the ABNO Controller.
+ The response includes a fully computed explicit path for each
+ service (TE LSP).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 44]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ 3. The concurrently computed solution received from the PCE is sent
+ back to the NMS/OSS by the ABNO Controller as a PCEP response, as
+ shown in Figure 20. The NMS/OSS user can then check the candidate
+ paths and either provision the new services or save the solution
+ for deployment in the future.
+
+ +---------------------+
+ | NMS/OSS |
+ +----------+----------+
+ ^
+ |
+ +----------+----------+
+ | ABNO Controller |
+ | |
+ +---------------------+
+
+ Figure 20: ABNO Sends Solution to the NMS/OSS
+
+3.5. Adaptive Network Management (ANM)
+
+ The ABNO architecture provides the capability for reactive network
+ control of resources relying on classification, profiling, and
+ prediction based on current demands and resource utilization.
+ Server-layer transport network resources, such as Optical Transport
+ Network (OTN) time-slicing [G.709], or the fine granularity grid of
+ wavelengths with variable spectral bandwidth (flexi-grid) [G.694.1],
+ can be manipulated to meet current and projected demands in a model
+ called Elastic Optical Networks (EON) [EON].
+
+ EON provides spectrum-efficient and scalable transport by introducing
+ flexible granular traffic grooming in the optical frequency domain.
+ This is achieved using arbitrary contiguous concatenation of the
+ optical spectrum that allows the creation of custom-sized bandwidth.
+ This bandwidth is defined in slots of 12.5 GHz.
+
+ Adaptive Network Management (ANM) with EON allows appropriately sized
+ optical bandwidth to be allocated to an end-to-end optical path. In
+ flexi-grid, the allocation is performed according to the traffic
+ volume, optical modulation format, and associated reach, or following
+ user requests, and can be achieved in a highly spectrum-efficient and
+ scalable manner. Similarly, OTN provides for flexible and granular
+ provisioning of bandwidth on top of Wavelength Switched Optical
+ Networks (WSONs).
+
+ To efficiently use optical resources, a system is required that can
+ monitor network resources and decide the optimal network
+ configuration based on the status, bandwidth availability, and user
+ service. We call this ANM.
+
+
+
+King & Farrel Informational [Page 45]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+3.5.1. ANM Trigger
+
+ There are different reasons to trigger an adaptive network management
+ process; these include:
+
+ o Measurement: Traffic measurements can be used in order to cause
+ spectrum allocations that fit the traffic needs as efficiently as
+ possible. This function may be influenced by measuring the IP
+ router traffic flows, by examining traffic engineering or link
+ state databases, by usage thresholds for critical links in the
+ network, or by requests from external entities. Nowadays, network
+ operators have active monitoring probes in the network that store
+ their results in the OSS. The OSS or OAM Handler components
+ activate this measurement-based trigger, so the ABNO Controller
+ would not be directly involved in this case.
+
+ o Human: Operators may request ABNO to run an adaptive network
+ planning process via an NMS.
+
+ o Periodic: An adaptive network planning process can be run
+ periodically to find an optimum configuration.
+
+ An ABNO Controller would receive a request from an OSS or NMS to run
+ an adaptive network manager process.
+
+3.5.2. Processing Request and GCO Computation
+
+ Based on the human or periodic trigger requests described in the
+ previous section, the OSS or NMS will send a request to the ABNO
+ Controller to perform EON-based GCO. The ABNO Controller will select
+ a set of services to be reoptimized and choose an objective function
+ that will deliver the best use of network resources. In making these
+ choices, the ABNO Controller is guided by network-wide policy on the
+ use of resources, the definition of optimization, and the level of
+ perturbation to existing services that is tolerable.
+
+ This request for GCO is passed to the PCE, along the lines of the
+ description in Section 3.4. The PCE can then consider the end-to-end
+ paths and every channel's optimal spectrum assignment in order to
+ satisfy traffic demands and optimize the optical spectrum consumption
+ within the network.
+
+ The PCE will operate on the TED but is likely to also be stateful so
+ that it knows which LSPs correspond to which waveband allocations on
+ which links in the network. Once the PCE arrives at an answer, it
+ returns a set of potential paths to the ABNO Controller, which passes
+ them on to the NMS or OSS to supervise/select the subsequent path
+ setup/modification process.
+
+
+
+King & Farrel Informational [Page 46]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ This exchange is shown in Figure 21. Note that the figure does not
+ show the interactions used by the OSS/NMS for establishing or
+ modifying LSPs in the network.
+
+ +---------------------------+
+ | OSS or NMS |
+ +-----------+---+-----------+
+ | ^
+ V |
+ +------+ +----------+---+----------+
+ |Policy+->-+ ABNO Controller |
+ |Agent | | |
+ +------+ +----------+---+----------+
+ | ^
+ V |
+ +-----+---+----+
+ + PCE |
+ +--------------+
+
+ Figure 21: Adaptive Network Management with Human Intervention
+
+3.5.3. Automated Provisioning Process
+
+ Although most network operations are supervised by the operator,
+ there are some actions that may not require supervision, like a
+ simple modification of a modulation format in a Bit-rate Variable
+ Transponder (BVT) (to increase the optical spectrum efficiency or
+ reduce energy consumption). In this process, where human
+ intervention is not required, the PCE sends the Provisioning Manager
+ a new configuration to configure the network elements, as shown in
+ Figure 22.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 47]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +------------------------+
+ | OSS or NMS |
+ +-----------+------------+
+ |
+ V
+ +------+ +----------+------------+
+ |Policy+->-+ ABNO Controller |
+ |Agent | | |
+ +------+ +----------+------------+
+ |
+ V
+ +------+------+
+ + PCE |
+ +------+------+
+ |
+ V
+ +----------------------------------+
+ | Provisioning Manager |
+ +----------------------------------+
+
+ Figure 22: Adaptive Network Management without Human Intervention
+
+3.6. Pseudowire Operations and Management
+
+ Pseudowires in an MPLS network [RFC3985] operate as a form of layered
+ network over the connectivity provided by the MPLS network. The
+ pseudowires are carried by LSPs operating as transport tunnels, and
+ planning is necessary to determine how those tunnels are placed in
+ the network and which tunnels are used by any pseudowire.
+
+ This section considers four use cases: multi-segment pseudowires,
+ path-diverse pseudowires, path-diverse multi-segment pseudowires, and
+ pseudowire segment protection. Section 3.6.5 describes the
+ applicability of the ABNO architecture to these four use cases.
+
+3.6.1. Multi-Segment Pseudowires
+
+ [RFC5254] describes the architecture for multi-segment pseudowires.
+ An end-to-end service, as shown in Figure 23, can consist of a series
+ of stitched segments shown in the figure as AC, PW1, PW2, PW3, and
+ AC. Each pseudowire segment is stitched at a "stitching Provider
+ Edge" (S-PE): for example, PW1 is stitched to PW2 at S-PE1. Each
+ access circuit (AC) is stitched to a pseudowire segment at a
+ "terminating PE" (T-PE): for example, PW1 is stitched to the AC at
+ T-PE1.
+
+
+
+
+
+
+King & Farrel Informational [Page 48]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ Each pseudowire segment is carried across the MPLS network in an LSP
+ operating as a transport tunnel: for example, PW1 is carried in LSP1.
+ The LSPs between PE nodes may traverse different MPLS networks with
+ the PEs as border nodes, or the PEs may lie within the network such
+ that each LSP spans only part of the network.
+
+ ----- ----- ----- -----
+ --- |T-PE1| LSP1 |S-PE1| LSP2 |S-PE3| LSP3 |T-PE2| +---+
+ | | AC | |=======| |=======| |=======| | AC | |
+ |CE1|----|........PW1........|..PW2........|..PW3........|----|CE2|
+ | | | |=======| |=======| |=======| | | |
+ --- | | | | | | | | +---+
+ ----- ----- ----- -----
+
+ Figure 23: Multi-Segment Pseudowire
+
+ While the topology shown in Figure 23 is easy to navigate, the
+ reality of a deployed network can be considerably more complex. The
+ topology in Figure 24 shows a small mesh of PEs. The links between
+ the PEs are not physical links but represent the potential of MPLS
+ LSPs between the PEs.
+
+ When establishing the end-to-end service between Customer Edge nodes
+ (CEs) CE1 and CE2, some choice must be made about which PEs to use.
+ In other words, a path computation must be made to determine the
+ pseudowire segment "hops", and then the necessary LSP tunnels must be
+ established to carry the pseudowire segments that will be stitched
+ together.
+
+ Of course, each LSP may itself require a path computation decision to
+ route it through the MPLS network between PEs.
+
+ The choice of path for the multi-segment pseudowire will depend on
+ such issues as:
+
+ - MPLS connectivity
+
+ - MPLS bandwidth availability
+
+ - pseudowire stitching capability and capacity at PEs
+
+ - policy and confidentiality considerations for use of PEs
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 49]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ -----
+ |S-PE5|
+ /-----\
+ --- ----- -----/ \----- ----- ---
+ |CE1|----|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|----|CE2|
+ --- -----\ -----\ ----- /----- ---
+ \ | ------- | /
+ \ ----- \----- /
+ -----|S-PE2|-------|S-PE4|-----
+ ----- -----
+
+ Figure 24: Multi-Segment Pseudowire Network Topology
+
+3.6.2. Path-Diverse Pseudowires
+
+ The connectivity service provided by a pseudowire may need to be
+ resilient to failure. In many cases, this function is provided by
+ provisioning a pair of pseudowires carried by path-diverse LSPs
+ across the network, as shown in Figure 25 (the terminology is
+ inherited directly from [RFC3985]). Clearly, in this case, the
+ challenge is to keep the two LSPs (LSP1 and LSP2) disjoint within the
+ MPLS network. This problem is not different from the normal MPLS
+ path-diversity problem.
+
+ ------- -------
+ | PE1 | LSP1 | PE2 |
+ AC | |=======================| | AC
+ ----...................PW1...................----
+ --- - / | |=======================| | \ -----
+ | |/ | | | | \| |
+ | CE1 + | | MPLS Network | | + CE2 |
+ | |\ | | | | /| |
+ --- - \ | |=======================| | / -----
+ ----...................PW2...................----
+ AC | |=======================| | AC
+ | | LSP2 | |
+ ------- -------
+
+ Figure 25: Path-Diverse Pseudowires
+
+ The path-diverse pseudowire is developed in Figure 26 by the
+ "dual-homing" of each CE through more than one PE. The requirement
+ for LSP path diversity is exactly the same, but it is complicated by
+ the LSPs having distinct end points. In this case, the head-end
+ router (e.g., PE1) cannot be relied upon to maintain the path
+ diversity through the signaling protocol because it is aware of the
+ path of only one of the LSPs. Thus, some form of coordinated path
+ computation approach is needed.
+
+
+
+King & Farrel Informational [Page 50]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ ------- -------
+ | PE1 | LSP1 | PE2 |
+ AC | |=======================| | AC
+ ---...................PW1...................---
+ / | |=======================| | \
+ ----- / | | | | \ -----
+ | |/ ------- ------- \| |
+ | CE1 + MPLS Network + CE2 |
+ | |\ ------- ------- /| |
+ ----- \ | PE3 | | PE4 | / -----
+ \ | |=======================| | /
+ ---...................PW2...................---
+ AC | |=======================| | AC
+ | | LSP2 | |
+ ------- -------
+
+ Figure 26: Path-Diverse Pseudowires with Disjoint PEs
+
+3.6.3. Path-Diverse Multi-Segment Pseudowires
+
+ Figure 27 shows how the services in the previous two sections may be
+ combined to offer end-to-end diverse paths in a multi-segment
+ environment. To offer end-to-end resilience to failure, two entirely
+ diverse, end-to-end multi-segment pseudowires may be needed.
+
+ ----- -----
+ |S-PE5|--------------|T-PE4|
+ /-----\ ----- \
+ ----- -----/ \----- ----- \ ---
+ |T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|--|CE2|
+ --- / -----\ -----\ ----- /----- ---
+ |CE1|< ------- | ------- | /
+ --- \ ----- \----- \----- /
+ |T-PE3|-------|S-PE2|-------|S-PE4|-----
+ ----- ----- -----
+
+ Figure 27: Path-Diverse Multi-Segment Pseudowire Network Topology
+
+ Just as in any diverse-path computation, the selection of the first
+ path needs to be made with awareness of the fact that a second, fully
+ diverse path is also needed. If a sequential computation was applied
+ to the topology in Figure 27, the first path CE1,T-PE1,S-PE1,
+ S-PE3,T-PE2,CE2 would make it impossible to find a second path that
+ was fully diverse from the first.
+
+
+
+
+
+
+
+King & Farrel Informational [Page 51]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ But the problem is complicated by the multi-layer nature of the
+ network. It is not enough that the PEs are chosen to be diverse
+ because the LSP tunnels between them might share links within the
+ MPLS network. Thus, a multi-layer planning solution is needed to
+ achieve the desired level of service.
+
+3.6.4. Pseudowire Segment Protection
+
+ An alternative to the end-to-end pseudowire protection service
+ enabled by the mechanism described in Section 3.6.3 can be achieved
+ by protecting individual pseudowire segments or PEs. For example, in
+ Figure 27, the pseudowire between S-PE1 and S-PE5 may be protected by
+ a pair of stitched segments running between S-PE1 and S-PE5, and
+ between S-PE5 and S-PE3. This is shown in detail in Figure 28.
+
+ ------- ------- -------
+ | S-PE1 | LSP1 | S-PE5 | LSP3 | S-PE3 |
+ | |============| |============| |
+ | .........PW1..................PW3.......... | Outgoing
+ Incoming | : |============| |============| : | Segment
+ Segment | : | ------- | :..........
+ ...........: | | : |
+ | : | | : |
+ | : |=================================| : |
+ | .........PW2............................... |
+ | |=================================| |
+ | | LSP2 | |
+ ------- -------
+
+ Figure 28: Fragment of a Segment-Protected Multi-Segment Pseudowire
+
+ The determination of pseudowire protection segments requires
+ coordination and planning, and just as in Section 3.6.5, this
+ planning must be cognizant of the paths taken by LSPs through the
+ underlying MPLS networks.
+
+3.6.5. Applicability of ABNO to Pseudowires
+
+ The ABNO architecture lends itself well to the planning and control
+ of pseudowires in the use cases described above. The user or
+ application needs a single point at which it requests services: the
+ ABNO Controller. The ABNO Controller can ask a PCE to draw on the
+ topology of pseudowire stitching-capable PEs as well as additional
+ information regarding PE capabilities, such as load on PEs and
+ administrative policies, and the PCE can use a series of TEDs or
+ other PCEs for the underlying MPLS networks to determine the paths of
+ the LSP tunnels. At the time of this writing, PCEP does not support
+
+
+
+
+King & Farrel Informational [Page 52]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ path computation requests and responses concerning pseudowires, but
+ the concepts are very similar to existing uses and the necessary
+ extensions would be very small.
+
+ Once the paths have been computed, a number of different provisioning
+ systems can be used to instantiate the LSPs and provision the
+ pseudowires under the control of the Provisioning Manager. The ABNO
+ Controller will use the I2RS Client to instruct the network devices
+ about what traffic should be placed on which pseudowires and, in
+ conjunction with the OAM Handler, can ensure that failure events are
+ handled correctly, that service quality levels are appropriate, and
+ that service protection levels are maintained.
+
+ In many respects, the pseudowire network forms an overlay network
+ (with its own TED and provisioning mechanisms) carried by underlying
+ packet networks. Further client networks (the pseudowire payloads)
+ may be carried by the pseudowire network. Thus, the problem space
+ being addressed by ABNO in this case is a classic multi-layer
+ network.
+
+3.7. Cross-Stratum Optimization (CSO)
+
+ Considering the term "stratum" to broadly differentiate the layers of
+ most concern to the application and to the network in general, the
+ need for Cross-Stratum Optimization (CSO) arises when the application
+ stratum and network stratum need to be coordinated to achieve
+ operational efficiency as well as resource optimization in both
+ application and network strata.
+
+ Data center-based applications can provide a wide variety of services
+ such as video gaming, cloud computing, and grid applications. High-
+ bandwidth video applications are also emerging, such as remote
+ medical surgery, live concerts, and sporting events.
+
+ This use case for the ABNO architecture is mainly concerned with data
+ center applications that make substantial bandwidth demands either in
+ aggregate or individually. In addition, these applications may need
+ specific bounds on QoS-related parameters such as latency and jitter.
+
+3.7.1. Data Center Network Operation
+
+ Data centers come in a wide variety of sizes and configurations, but
+ all contain compute servers, storage, and application control. Data
+ centers offer application services to end-users, such as video
+ gaming, cloud computing, and others. Since the data centers used to
+ provide application services may be distributed around a network, the
+ decisions about the control and management of application services,
+ such as where to instantiate another service instance or to which
+
+
+
+King & Farrel Informational [Page 53]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ data center a new client is assigned, can have a significant impact
+ on the state of the network. Conversely, the capabilities and state
+ of the network can have a major impact on application performance.
+
+ These decisions are typically made by applications with very little
+ or no information concerning the underlying network. Hence, such
+ decisions may be suboptimal from the application's point of view or
+ considering network resource utilization and quality of service.
+
+ Cross-Stratum Optimization is the process of optimizing both the
+ application experience and the network utilization by coordinating
+ decisions in the application stratum and the network stratum.
+ Application resources can be roughly categorized into computing
+ resources (i.e., servers of various types and granularities, such as
+ Virtual Machines (VMs), memory, and storage) and content (e.g.,
+ video, audio, databases, and large data sets). By "network stratum"
+ we mean the IP layer and below (e.g., MPLS, Synchronous Digital
+ Hierarchy (SDH), OTN, WDM). The network stratum has resources that
+ include routers, switches, and links. We are particularly interested
+ in further unleashing the potential presented by MPLS and GMPLS
+ control planes at the lower network layers in response to the high
+ aggregate or individual demands from the application layer.
+
+ This use case demonstrates that the ABNO architecture can allow
+ cross-stratum application/network optimization for the data center
+ use case. Other forms of Cross-Stratum Optimization (for example,
+ for peer-to-peer applications) are out of scope.
+
+3.7.1.1. Virtual Machine Migration
+
+ A key enabler for data center cost savings, consolidation,
+ flexibility, and application scalability has been the technology of
+ compute virtualization provided through Virtual Machines (VMs). To
+ the software application, a VM looks like a dedicated processor with
+ dedicated memory and a dedicated operating system.
+
+ VMs not only offer a unit of compute power but also provide an
+ "application environment" that can be replicated, backed up, and
+ moved. Different VM configurations may be offered that are optimized
+ for different types of processing (e.g., memory intensive, throughput
+ intensive).
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 54]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ VMs may be moved between compute resources in a data center and could
+ be moved between data centers. VM migration serves to balance load
+ across data center resources and has several modes:
+
+ (i) scheduled vs. dynamic;
+
+ (ii) bulk vs. sequential;
+
+ (iii) point-to-point vs. point-to-multipoint
+
+ While VM migration may solve problems of load or planned maintenance
+ within a data center, it can also be effective to reduce network load
+ around the data center. But the act of migrating VMs, especially
+ between data centers, can impact the network and other services that
+ are offered.
+
+ For certain applications such as disaster recovery, bulk migration is
+ required on the fly, which may necessitate concurrent computation and
+ path setup dynamically.
+
+ Thus, application stratum operations must also take into account the
+ situation in the network stratum, even as the application stratum
+ actions may be driven by the status of the network stratum.
+
+3.7.1.2. Load Balancing
+
+ Application servers may be instantiated in many data centers located
+ in different parts of the network. When an end-user makes an
+ application request, a decision has to be made about which data
+ center should host the processing and storage required to meet the
+ request. One of the major drivers for operating multiple data
+ centers (rather than one very large data center) is so that the
+ application will run on a machine that is closer to the end-users and
+ thus improve the user experience by reducing network latency.
+ However, if the network is congested or the data center is
+ overloaded, this strategy can backfire.
+
+ Thus, the key factors to be considered in choosing the server on
+ which to instantiate a VM for an application include:
+
+ - The utilization of the servers in the data center
+
+ - The network load conditions within a data center
+
+ - The network load conditions between data centers
+
+ - The network conditions between the end-user and data center
+
+
+
+
+King & Farrel Informational [Page 55]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ Again, the choices made in the application stratum need to consider
+ the situation in the network stratum.
+
+3.7.2. Application of the ABNO Architecture
+
+ This section shows how the ABNO architecture is applicable to the
+ cross-stratum data center issues described in Section 3.7.1.
+
+ Figure 29 shows a diagram of an example data center-based
+ application. A carrier network provides access for an end-user
+ through PE4. Three data centers (DC1, DC2, and DC3) are accessed
+ through different parts of the network via PE1, PE2, and PE3.
+
+ The Application Service Coordinator receives information from the
+ end-user about the desired services and converts this information to
+ service requests that it passes to the ABNO Controller. The
+ end-users may already know which data center they wish to use, or the
+ Application Service Coordinator may be able to make this
+ determination; otherwise, the task of selecting the data center must
+ be performed by the ABNO Controller, and this may utilize a further
+ database (see Section 2.3.1.8) to contain information about server
+ loads and other data center parameters.
+
+ The ABNO Controller examines the network resources using information
+ gathered from the other ABNO components and uses those components to
+ configure the network to support the end-user's needs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 56]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +----------+ +---------------------------------+
+ | End-User |--->| Application Service Coordinator |
+ +----------+ +---------------------------------+
+ | |
+ | v
+ | +-----------------+
+ | | ABNO Controller |
+ | +-----------------+
+ | |
+ | v
+ | +---------------------+ +--------------+
+ | |Other ABNO Components| | o o o DC 1 |
+ | +---------------------+ | \|/ |
+ | | ------|---O |
+ | v | | |
+ | --------------------------|-- +--------------+
+ | / Carrier Network PE1 | \
+ | / .....................O \ +--------------+
+ | | . | | o o o DC 2 |
+ | | PE4 . PE2 | | \|/ |
+ ---------|----O........................O---|--|---O |
+ | . | | |
+ | . PE3 | +--------------+
+ \ .....................O /
+ \ | / +--------------+
+ --------------------------|-- | o o o DC 3 |
+ | | \|/ |
+ ------|---O |
+ | |
+ +--------------+
+
+ Figure 29: The ABNO Architecture in the Context of
+ Cross-Stratum Optimization for Data Centers
+
+3.7.2.1. Deployed Applications, Services, and Products
+
+ The ABNO Controller will need to utilize a number of components to
+ realize the CSO functions described in Section 3.7.1.
+
+ The ALTO Server provides information about topological proximity and
+ appropriate geographical location to servers with respect to the
+ underlying networks. This information can be used to optimize the
+ selection of peer location, which will help reduce the path of IP
+ traffic or can contain it within specific service providers'
+ networks. ALTO in conjunction with the ABNO Controller and the
+ Application Service Coordinator can address general problems such as
+ the selection of application servers based on resource availability
+ and usage of the underlying networks.
+
+
+
+King & Farrel Informational [Page 57]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ The ABNO Controller can also formulate a view of current network load
+ from the TED and from the OAM Handler (for example, by running
+ diagnostic tools that measure latency, jitter, and packet loss).
+ This view obviously influences not just how paths from the end-user
+ to the data center are provisioned but can also guide the selection
+ of which data center should provide the service and possibly even the
+ points of attachment to be used by the end-user and to reach the
+ chosen data center. A view of how the PCE can fit in with CSO is
+ provided in [CSO-PCE], on which the content of Figure 29 is based.
+
+ As already discussed, the combination of the ABNO Controller and the
+ Application Service Coordinator will need to be able to select (and
+ possibly migrate) the location of the VM that provides the service
+ for the end-user. Since a common technique used to direct the
+ end-user to the correct VM/server is to employ DNS redirection, an
+ important capability of the ABNO Controller will be the ability to
+ program the DNS servers accordingly.
+
+ Furthermore, as already noted in other sections of this document, the
+ ABNO Controller can coordinate the placement of traffic within the
+ network to achieve load balancing and to provide resilience to
+ failures. These features can be used in conjunction with the
+ functions discussed above, to ensure that the placement of new VMs,
+ the traffic that they generate, and the load caused by VM migration
+ can be carried by the network and do not disrupt existing services.
+
+3.8. ALTO Server
+
+ The ABNO architecture allows use cases with joint network and
+ application-layer optimization. In such a use case, an application
+ is presented with an abstract network topology containing only
+ information relevant to the application. The application computes
+ its application-layer routing according to its application objective.
+ The application may interact with the ABNO Controller to set up
+ explicit LSPs to support its application-layer routing.
+
+ The following steps are performed to illustrate such a use case.
+
+ 1. Application Request of Application-Layer Topology
+
+ Consider the network shown in Figure 30. The network consists of
+ five nodes and six links.
+
+ The application, which has end points hosted at N0, N1, and N2,
+ requests network topology so that it can compute its application-
+ layer routing, for example, to maximize the throughput of content
+ replication among end points at the three sites.
+
+
+
+
+King & Farrel Informational [Page 58]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +----+ L0 Wt=10 BW=50 +----+
+ | N0 |............................| N3 |
+ +----+ +----+
+ | \ L4 |
+ | \ Wt=7 |
+ | \ BW=40 |
+ | \ |
+ L1 | +----+ |
+ Wt=10 | | N4 | L2 |
+ BW=45 | +----+ Wt=12 |
+ | / BW=30 |
+ | / L5 |
+ | / Wt=10 |
+ | / BW=45 |
+ +----+ +----+
+ | N1 |............................| N2 |
+ +----+ L3 Wt=15 BW=35 +----+
+
+ Figure 30: Raw Network Topology
+
+ The request arrives at the ABNO Controller, which forwards the
+ request to the ALTO Server component. The ALTO Server consults
+ the Policy Agent, the TED, and the PCE to return an abstract,
+ application-layer topology.
+
+ For example, the policy may specify that the bandwidth exposed to
+ an application may not exceed 40 Mbps. The network has
+ precomputed that the route from N0 to N2 should use the path
+ N0->N3->N2, according to goals such as GCO (see Section 3.4). The
+ ALTO Server can then produce a reduced topology for the
+ application, such as the topology shown in Figure 31.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 59]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +----+
+ | N0 |............
+ +----+ \
+ | \ \
+ | \ \
+ | \ \
+ | | \ AL0M2
+ L1 | | AL4M5 \ Wt=22
+ Wt=10 | | Wt=17 \ BW=30
+ BW=40 | | BW=40 \
+ | | \
+ | / \
+ | / \
+ | / \
+ +----+ +----+
+ | N1 |........................| N2 |
+ +----+ L3 Wt=15 BW=35 +----+
+
+ Figure 31: Reduced Graph for a Particular Application
+
+ The ALTO Server uses the topology and existing routing to compute
+ an abstract network map consisting of three PIDs. The pair-wise
+ bandwidth as well as shared bottlenecks will be computed from the
+ internal network topology and reflected in cost maps.
+
+ 2. Application Computes Application Overlay
+
+ Using the abstract topology, the application computes an
+ application-layer routing. For concreteness, the application may
+ compute a spanning tree to maximize the total bandwidth from N0 to
+ N2. Figure 32 shows an example of application-layer routing,
+ using a route of N0->N1->N2 for 35 Mbps and N0->N2 for 30 Mbps,
+ for a total of 65 Mbps.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 60]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ +----+
+ | N0 |----------------------------------+
+ +----+ AL0M2 BW=30 |
+ | |
+ | |
+ | |
+ | |
+ | L1 |
+ | |
+ | BW=35 |
+ | |
+ | |
+ | |
+ V V
+ +----+ L3 BW=35 +----+
+ | N1 |...............................>| N2 |
+ +----+ +----+
+
+ Figure 32: Application-Layer Spanning Tree
+
+ 3. Application Path Set Up by the ABNO Controller
+
+ The application may submit its application routes to the ABNO
+ Controller to set up explicit LSPs to support its operation. The
+ ABNO Controller consults the ALTO maps to map the application-
+ layer routing back to internal network topology and then instructs
+ the Provisioning Manager to set up the paths. The ABNO Controller
+ may re-trigger GCO to reoptimize network traffic engineering.
+
+3.9. Other Potential Use Cases
+
+ This section serves as a placeholder for other potential use cases
+ that might get documented in future documents.
+
+3.9.1. Traffic Grooming and Regrooming
+
+ This use case could cover the following scenarios:
+
+ - Nested LSPs
+
+ - Packet Classification (IP flows into LSPs at edge routers)
+
+ - Bucket Stuffing
+
+ - IP Flows into ECMP Hash Bucket
+
+
+
+
+
+
+King & Farrel Informational [Page 61]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+3.9.2. Bandwidth Scheduling
+
+ Bandwidth scheduling consists of configuring LSPs based on a given
+ time schedule. This can be used to support maintenance or
+ operational schedules or to adjust network capacity based on traffic
+ pattern detection.
+
+ The ABNO framework provides the components to enable bandwidth
+ scheduling solutions.
+
+4. Survivability and Redundancy within the ABNO Architecture
+
+ The ABNO architecture described in this document is presented in
+ terms of functional units. Each unit could be implemented separately
+ or bundled with other units into single programs or products.
+ Furthermore, each implemented unit or bundle could be deployed on a
+ separate device (for example, a network server) or on a separate
+ virtual machine (for example, in a data center), or groups of
+ programs could be deployed on the same processor. From the point of
+ view of the architectural model, these implementation and deployment
+ choices are entirely unimportant.
+
+ Similarly, the realization of a functional component of the ABNO
+ architecture could be supported by more than one instance of an
+ implementation, or by different instances of different
+ implementations that provide the same or similar function. For
+ example, the PCE component might have multiple instantiations for
+ sharing the processing load of a large number of computation
+ requests, and different instances might have different algorithmic
+ capabilities so that one instance might serve parallel computation
+ requests for disjoint paths, while another instance might have the
+ capability to compute optimal point-to-multipoint paths.
+
+ This ability to have multiple instances of ABNO components also
+ enables resiliency within the model, since in the event of the
+ failure of one instance of one component (because of software
+ failure, hardware failure, or connectivity problems) other instances
+ can take over. In some circumstances, synchronization between
+ instances of components may be needed in order to facilitate seamless
+ resiliency.
+
+ How these features are achieved in an ABNO implementation or
+ deployment is outside the scope of this document.
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 62]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+5. Security Considerations
+
+ The ABNO architecture describes a network system, and security must
+ play an important part.
+
+ The first consideration is that the external protocols (those shown
+ as entering or leaving the big box in Figure 1) must be appropriately
+ secured. This security will include authentication and authorization
+ to control access to the different functions that the ABNO system can
+ perform, to enable different policies based on identity, and to
+ manage the control of the network devices.
+
+ Secondly, the internal protocols that are used between ABNO
+ components must also have appropriate security, particularly when the
+ components are implemented on separate network nodes.
+
+ Considering that the ABNO system contains a lot of data about the
+ network, the services carried by the network, and the services
+ delivered to customers, access to information held in the system must
+ be carefully managed. Since such access will be largely through the
+ external protocols, the policy-based controls enabled by
+ authentication will be powerful. But it should also be noted that
+ any data sent from the databases in the ABNO system can reveal
+ details of the network and should, therefore, be considered as a
+ candidate for encryption. Furthermore, since ABNO components can
+ access the information stored in the database, care is required to
+ ensure that all such components are genuine and to consider
+ encrypting data that flows between components when they are
+ implemented at remote nodes.
+
+ The conclusion is that all protocols used to realize the ABNO
+ architecture should have rich security features.
+
+6. Manageability Considerations
+
+ The whole of the ABNO architecture is essentially about managing the
+ network. In this respect, there is very little extra to say. ABNO
+ provides a mechanism to gather and collate information about the
+ network, reporting it to management applications, storing it for
+ future inspection, and triggering actions according to configured
+ policies.
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 63]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ The ABNO system will, itself, need monitoring and management. This
+ can be seen as falling into several categories:
+
+ - Management of external protocols
+
+ - Management of internal protocols
+
+ - Management and monitoring of ABNO components
+
+ - Configuration of policy to be applied across the ABNO system
+
+7. Informative References
+
+ [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
+ Ray, "North-Bound Distribution of Link-State and TE
+ Information using BGP", Work in Progress, draft-ietf-idr-
+ ls-distribution-10, January 2015.
+
+ [CSO-PCE] Dhody, D., Lee, Y., Contreras, LM., Gonzalez de Dios, O.,
+ and N. Ciulli, "Cross Stratum Optimization enabled Path
+ Computation", Work in Progress, draft-dhody-pce-cso-
+ enabled-path-computation-07, January 2015.
+
+ [EON] Gerstel, O., Jinno, M., Lord, A., and S.J.B. Yoo, "Elastic
+ optical networking: a new dawn for the optical layer?",
+ IEEE Communications Magazine, Volume 50, Issue 2,
+ ISSN 0163-6804, February 2012.
+
+ [Flood] Project Floodlight, "Floodlight REST API",
+ <http://www.projectfloodlight.org>.
+
+ [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
+ applications: DWDM frequency grid", February 2012.
+
+ [G.709] ITU-T Recommendation G.709, "Interface for the optical
+ transport network", February 2012.
+
+ [I2RS-Arch]
+ Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
+ Nadeau, "An Architecture for the Interface to the Routing
+ System", Work in Progress, draft-ietf-i2rs-
+ architecture-09, March 2015.
+
+ [I2RS-PS] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Interface
+ to the Routing System Problem Statement", Work in
+ Progress, draft-ietf-i2rs-problem-statement-06,
+ January 2015.
+
+
+
+
+King & Farrel Informational [Page 64]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ [ONF] Open Networking Foundation, "OpenFlow Switch Specification
+ Version 1.4.0 (Wire Protocol 0x05)", October 2013.
+
+ [PCE-Init-LSP]
+ Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
+ Extensions for PCE-initiated LSP Setup in a Stateful PCE
+ Model", Work in Progress, draft-ietf-pce-pce-initiated-
+ lsp-03, March 2015.
+
+ [RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+ Protocol", Work in Progress, draft-ietf-netconf-
+ restconf-04, January 2015.
+
+ [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
+ R., and A. Sastry, "The COPS (Common Open Policy Service)
+ Protocol", RFC 2748, January 2000,
+ <http://www.rfc-editor.org/info/rfc2748>.
+
+ [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
+ for Policy-based Admission Control", RFC 2753,
+ January 2000, <http://www.rfc-editor.org/info/rfc2753>.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001,
+ <http://www.rfc-editor.org/info/rfc3209>.
+
+ [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
+ "General Switch Management Protocol (GSMP) V3", RFC 3292,
+ June 2002, <http://www.rfc-editor.org/info/rfc3292>.
+
+ [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
+ "Message Processing and Dispatching for the Simple Network
+ Management Protocol (SNMP)", STD 62, RFC 3412,
+ December 2002, <http://www.rfc-editor.org/info/rfc3412>.
+
+ [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation Protocol-
+ Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+ January 2003, <http://www.rfc-editor.org/info/rfc3473>.
+
+ [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+ (TE) Extensions to OSPF Version 2", RFC 3630,
+ September 2003, <http://www.rfc-editor.org/info/rfc3630>.
+
+
+
+
+
+
+
+King & Farrel Informational [Page 65]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
+ "Forwarding and Control Element Separation (ForCES)
+ Framework", RFC 3746, April 2004,
+ <http://www.rfc-editor.org/info/rfc3746>.
+
+ [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
+ Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005,
+ <http://www.rfc-editor.org/info/rfc3985>.
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC 4655,
+ August 2006, <http://www.rfc-editor.org/info/rfc4655>.
+
+ [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+ "Label Switched Path Stitching with Generalized
+ Multiprotocol Label Switching Traffic Engineering (GMPLS
+ TE)", RFC 5150, February 2008,
+ <http://www.rfc-editor.org/info/rfc5150>.
+
+ [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
+ M., and D. Brungard, "Requirements for GMPLS-Based Multi-
+ Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
+ July 2008, <http://www.rfc-editor.org/info/rfc5212>.
+
+ [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
+ "Requirements for Multi-Segment Pseudowire Emulation Edge-
+ to-Edge (PWE3)", RFC 5254, October 2008,
+ <http://www.rfc-editor.org/info/rfc5254>.
+
+ [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
+ Notifications", RFC 5277, July 2008,
+ <http://www.rfc-editor.org/info/rfc5277>.
+
+ [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, October 2008,
+ <http://www.rfc-editor.org/info/rfc5305>.
+
+ [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
+ "Policy-Enabled Path Computation Framework", RFC 5394,
+ December 2008, <http://www.rfc-editor.org/info/rfc5394>.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009,
+ <http://www.rfc-editor.org/info/rfc5424>.
+
+ [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+ March 2009, <http://www.rfc-editor.org/info/rfc5440>.
+
+
+
+
+King & Farrel Informational [Page 66]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
+ "Preserving Topology Confidentiality in Inter-Domain Path
+ Computation Using a Path-Key-Based Mechanism", RFC 5520,
+ April 2009, <http://www.rfc-editor.org/info/rfc5520>.
+
+ [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
+ Computation Element Communication Protocol (PCEP)
+ Requirements and Protocol Extensions in Support of Global
+ Concurrent Optimization", RFC 5557, July 2009,
+ <http://www.rfc-editor.org/info/rfc5557>.
+
+ [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
+ "Framework for PCE-Based Inter-Layer MPLS and GMPLS
+ Traffic Engineering", RFC 5623, September 2009,
+ <http://www.rfc-editor.org/info/rfc5623>.
+
+ [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
+ Optimization (ALTO) Problem Statement", RFC 5693,
+ October 2009, <http://www.rfc-editor.org/info/rfc5693>.
+
+ [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
+ Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
+ J. Halpern, "Forwarding and Control Element Separation
+ (ForCES) Protocol Specification", RFC 5810, March 2010,
+ <http://www.rfc-editor.org/info/rfc5810>.
+
+ [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization
+ VECtor (SVEC) List for Synchronized Dependent Path
+ Computations", RFC 6007, September 2010,
+ <http://www.rfc-editor.org/info/rfc6007>.
+
+ [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+ the Network Configuration Protocol (NETCONF)", RFC 6020,
+ October 2010, <http://www.rfc-editor.org/info/rfc6020>.
+
+ [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
+ Dynamically Signaled Hierarchical Label Switched Paths",
+ RFC 6107, February 2011,
+ <http://www.rfc-editor.org/info/rfc6107>.
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, March 2011,
+ <http://www.rfc-editor.org/info/rfc6120>.
+
+ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+ and A. Bierman, Ed., "Network Configuration Protocol
+ (NETCONF)", RFC 6241, June 2011,
+ <http://www.rfc-editor.org/info/rfc6241>.
+
+
+
+King & Farrel Informational [Page 67]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
+ Distribution Network Interconnection (CDNI) Problem
+ Statement", RFC 6707, September 2012,
+ <http://www.rfc-editor.org/info/rfc6707>.
+
+ [RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the
+ Path Computation Element Architecture to the Determination
+ of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
+ November 2012, <http://www.rfc-editor.org/info/rfc6805>.
+
+ [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+ "Specification of the IP Flow Information Export (IPFIX)
+ Protocol for the Exchange of Flow Information", STD 77,
+ RFC 7011, September 2013,
+ <http://www.rfc-editor.org/info/rfc7011>.
+
+ [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
+ Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
+ "Application-Layer Traffic Optimization (ALTO) Protocol",
+ RFC 7285, September 2014,
+ <http://www.rfc-editor.org/info/rfc7285>.
+
+ [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
+ Connectivity Provisioning Profile (CPP)", RFC 7297,
+ July 2014, <http://www.rfc-editor.org/info/rfc7297>.
+
+ [Stateful-PCE]
+ Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
+ Extensions for Stateful PCE", Work in Progress,
+ draft-ietf-pce-stateful-pce-10, October 2014.
+
+ [TL1] Telcorida, "Operations Application Messages - Language For
+ Operations Application Messages", GR-831, November 1996.
+
+ [TMF-MTOSI]
+ TeleManagement Forum, "Multi-Technology Operations Systems
+ Interface (MTOSI)",
+ <https://www.tmforum.org/MTOSI/2319/home.html>.
+
+ [YANG-Rtg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
+ Management", Work in Progress, draft-ietf-netmod-routing-
+ cfg-17, March 2015.
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 68]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+Appendix A. Undefined Interfaces
+
+ This appendix provides a brief list of interfaces that are not yet
+ defined at the time of this writing. Interfaces where there is a
+ choice of existing protocols are not listed.
+
+ o An interface for adding additional information to the Traffic
+ Engineering Database is described in Section 2.3.2.3. No protocol
+ is currently identified for this interface, but candidates
+ include:
+
+ - The protocol developed or adopted to satisfy the requirements of
+ I2RS [I2RS-Arch]
+
+ - NETCONF [RFC6241]
+
+ o The protocol to be used by the Interface to the Routing System is
+ described in Section 2.3.2.8. The I2RS working group has
+ determined that this protocol will be based on a combination of
+ NETCONF [RFC6241] and RESTCONF [RESTCONF] with further additions
+ and modifications as deemed necessary to deliver the desired
+ function. The details of the protocol are still to be determined.
+
+ o As described in Section 2.3.2.10, the Virtual Network Topology
+ Manager needs an interface that can be used by a PCE or the ABNO
+ Controller to inform it that a client layer needs more virtual
+ topology. It is possible that the protocol identified for use
+ with I2RS will satisfy this requirement, or this could be achieved
+ using extensions to the PCEP Notify message (PCNtf).
+
+ o 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 as described in
+ Section 2.3.2.11.
+
+ - It is possible that the protocol selected or designed to satisfy
+ I2RS will address the requirement.
+
+ - A potential approach for this type of interface is described in
+ [RFC7297] for a simple use case.
+
+ o As noted in Section 2.3.2.14, there may be layer-independent data
+ models for offering common interfaces to control, configure, and
+ report OAM.
+
+
+
+
+
+
+
+King & Farrel Informational [Page 69]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+ o As noted in Section 3.6, the ABNO model could be applied to
+ placing multi-segment pseudowires in a network topology made up of
+ S-PEs and MPLS tunnels. The current definition of PCEP [RFC5440]
+ and associated extensions that are works in progress do not
+ include all of the details to request such paths, so some work
+ might be necessary, although the general concepts will be easily
+ reusable. Indeed, such work may be necessary for the wider
+ applicability of PCEs in many networking scenarios.
+
+Acknowledgements
+
+ Thanks for discussions and review are due to Ken Gray, Jan Medved,
+ Nitin Bahadur, Diego Caviglia, Joel Halpern, Brian Field, Ori
+ Gerstel, Daniele Ceccarelli, Cyril Margaria, Jonathan Hardwick, Nico
+ Wauters, Tom Taylor, Qin Wu, and Luis Contreras. Thanks to George
+ Swallow for suggesting the existence of the SRLG database. Tomonori
+ Takeda and Julien Meuric provided valuable comments as part of their
+ Routing Directorate reviews. Tina Tsou provided comments as part of
+ her Operational Directorate review.
+
+ This work received funding from the European Union's Seventh
+ Framework Programme for research, technological development, and
+ demonstration, through the PACE project under grant agreement
+ number 619712 and through the IDEALIST project under grant agreement
+ number 317999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+King & Farrel Informational [Page 70]
+
+RFC 7491 PCE-Based Architecture for ABNO March 2015
+
+
+Contributors
+
+ Quintin Zhao
+ Huawei Technologies
+ 125 Nagog Technology Park
+ Acton, MA 01719
+ United States
+ EMail: qzhao@huawei.com
+
+ Victor Lopez
+ Telefonica I+D
+ EMail: vlopez@tid.es
+
+ Ramon Casellas
+ CTTC
+ EMail: ramon.casellas@cttc.es
+
+ Yuji Kamite
+ NTT Communications Corporation
+ EMail: y.kamite@ntt.com
+
+ Yosuke Tanaka
+ NTT Communications Corporation
+ EMail: yosuke.tanaka@ntt.com
+
+ Young Lee
+ Huawei Technologies
+ EMail: leeyoung@huawei.com
+
+ Y. Richard Yang
+ Yale University
+ EMail: yry@cs.yale.edu
+
+Authors' Addresses
+
+ Daniel King
+ Old Dog Consulting
+
+ EMail: daniel@olddog.co.uk
+
+
+ Adrian Farrel
+ Juniper Networks
+
+ EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+King & Farrel Informational [Page 71]
+