RFC 7491
A PCE-Based Architecture for Application-Based Network Operations
RFC 7491 ✨ A PCE-Based Architecture for Application-Based Network Operations
Okay bestie, let's get into it 💖 This is RFC 7491, titled A PCE-Based Architecture for Application-Based Network Operations. It's an Informational document, not a Standards Track spec, so it's a "here's how this works" guide and not a rulebook 🦋. It was published in March 2015 and has ISSN 2070-1721. The authors are D. King from Old Dog Consulting and A. Farrel from Juniper Networks 🎀. The original title block doesn't list any RFCs that it obsoletes or updates, so it doesn't replace or patch anything else 🌸.
Abstract 🌈
Okay so, content distribution, distributed databases, and inter-data center connectivity all need networks to do new stuff. They want on-demand, application-specific reservations of connectivity, reliability, and resources like bandwidth 🔥. This works across apps like point-to-point links, network virtualization, and mobile back-haul, and across tech from packet (IP/MPLS) all the way down to optical 💅. When an environment is built to meet these needs, it's said to have Application-Based Network Operations (ABNO). ABNO is lowkey iconic because it's mostly a toolbox of components that already exist, with a few new bits added on top 🧰✨.
This document lays out an architecture and framework for ABNO and shows how those pieces click together 🧩. It's basically a cookbook of existing tech that can satisfy the architecture and meet what the apps need 🍓.
Status of This Memo 🫶
This document is not an Internet Standards Track specification. It's published just for information 💜.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is eligible for any level of Internet Standard. See Section 2 of RFC 5741 for the details 📚.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7491. 🔗
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), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🎀.
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 ................................................711. Introduction ✨
Networks today mix lots of technologies so the infrastructure can deliver all kinds of services for the different needs of apps 🌸. More and more, the network needs to respond to service requests that come straight from the application layer 💅. That's different from the old model, where services showed up because a human sent management commands 🙈.
These app-driven requests and the services they set up add new requirements to how networks run 🔥. They need on-demand, app-specific reservations of connectivity, reliability, and resources like bandwidth. That works across apps such as point-to-point connectivity, network virtualization, or mobile back-haul, and across tech from packet (IP/MPLS) down to optical 🦋. An environment built for this kind of app-aware requirement is said to have Application-Based Network Operations (ABNO) 👑.
The Path Computation Element (PCE) [RFC4655] was built to handle path computation for GMPLS- and MPLS-controlled networks 🧚. PCEs can be stretched further to handle path computation and policy enforcement for ABNO platforms and services 💜.
ABNO can offer these kinds of service to apps by coordinating the components that run and manage the network 🫶:
- Optimizing traffic flows between apps to build an overlay network for things like file sharing, data caching or mirroring, media streaming, or real-time communications. This is described as Application-Layer Traffic Optimization (ALTO) [RFC5693] 🌈.
- Remote control of network components, so network resources can be programmed in a coordinated way. Techniques for this include Forwarding and Control Element Separation (ForCES) [RFC3746], OpenFlow [ONF], and the Interface to the Routing System (I2RS) [I2RS-Arch]. It can also happen through the control plane, coordinated over the PCE Communication Protocol (PCEP) [PCE-Init-LSP] ⚡.
- Interconnecting Content Delivery Networks (CDNi) [RFC6707] by setting up and resizing connections between content distribution networks. ABNO can coordinate inter-data center connections in the same way 🍓.
- Coordinating network resources to automate provisioning, and to make traffic grooming and regrooming, bandwidth scheduling, and Global Concurrent Optimization possible using PCEP [RFC5557] 🎀.
- Planning Virtual Private Network (VPN) deployments for new VPN customers, and making inter-data center connectivity easier 💅.
This document outlines the architecture and use cases for ABNO. It shows how the ABNO architecture can coordinate requests from control systems and apps to compute paths, enforce policies, and manage network resources, all for the benefit of the apps using the network ✨. Looking at the use cases shows that ABNO is a toolkit of many existing components and protocols, which is why this document reads like a cookbook 🧁. ABNO works alongside existing Network Management System (NMS) and Operations Support System (OSS) deployments, and also with newer programmable networks such as Software-Defined Networking (SDN) 🌸.
1.1. Scope 🔍
This document describes a toolkit. It shows how existing functional components, which are described in a bunch of separate documents, can be brought together in one architecture to provide the functions ABNO needs 🧩.
In lots of cases, existing protocols are already good enough, or almost good enough, to meet the requirements for the interfaces between components. In those cases, the protocols are called out as good candidates for use in an ABNO implementation 💖.
In other cases, more work is clearly needed. For those, the document points to ongoing work that might help. If the authors can't find any current work, Appendix A gives a short description of the missing interface protocol 📚.
So this document can be read as an applicability statement for existing protocols, plus guidance for developers building new protocols or protocol extensions 🦋.
2. Application-Based Network Operations (ABNO) 👑
2.1. Assumptions 💭
The main assumption behind this document is that existing technologies should be used wherever they're good enough for the job 🫶. And when an existing technology is almost enough, the idea is that it's better to make minor extensions than to invent a whole new technology 🌈.
Quick note: this document describes an architecture. Functional components are architectural concepts with distinct, clear responsibilities 🎀. Pairs of functional components talk to each other over functional interfaces, which are also architectural concepts 🔥.
2.2. Implementation of the Architecture
okay bestie, big disclaimer incoming 🫶 this document describes a functional architecture, NOT a software design. so it is not trying to boss implementations around 💅 what it does do is split ABNO into functional components with clear interfaces between them, which lets implementers pick which features to include ✨ and lets different functions run in different processes or even on different 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, so 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. 🦋
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 server 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. In other words, the function of a functional component could be partitioned across multiple software components, with each one 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 the capability to support different classes of application or application service. 👑
The purpose of this architecture description is to facilitate different implementations while offering interoperability between implementations of key components, and easy interaction with the applications and with the network devices. that's the whole vibe 💖
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's 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. so don't read it as a complete list 🙈
+----------------------------------------------------------------+
| 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 Architecture2.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. 🔗
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. They 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 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 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 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 shown as the Application Service Coordinator. ✨ 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. 💌
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. 🚪 It 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 main character of this whole architecture 👑
The use cases in Section 3 give 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 means 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]. It 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 to coordinate setting or gathering state to and from those routers. 🤝
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. 🩺 It's giving reliability!! 💖
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) 🧠
okay so the PCE was introduced in [RFC4655] 💅 It's a functional component that services requests to compute paths across a network graph. The main flex is that 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 works on a view of the network topology that's stored in the Traffic Engineering Database (TED) 🗺️ A more sophisticated computation can be provided by a Stateful PCE. It levels up the TED with a database (the LSP-DB -- see Section 2.3.1.8.2) that holds information about the LSPs that are provisioned and operational within the network, as described in [RFC4655] and [Stateful-PCE] 💜
Then there's the Active PCE, which adds more functionality. It lets a functional component that includes a Stateful PCE 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 it may be channeled through the Provisioning Manager.
Coordination between multiple PCEs that operate on different TEDs can prove useful for path computation in multi-domain or multi-layer networks 🌈 In this case, a domain might be an Autonomous System (AS), which enables inter-AS path computation.
Since the PCE is a key component of the ABNO architecture, you'll get a better sense of its role by checking out the use cases described in Section 3 🦋
2.3.1.8. Databases 🗄️
The ABNO architecture includes a number of databases that store information for the system to use. The two main ones are the TED and the LSP Database (LSP-DB). There may be a bunch of other databases too, holding information about topology (ALTO Server), policy (Policy Agent), services (ABNO Controller), etc. 🍓
The text that follows highlights specific key components that consume the databases. Just so you know, any of the ABNO components can inspect the databases 👀 Updates to the databases should be handled with some care, though, because letting multiple components write to one database can cause a bunch 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. It 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 main use of the TED in the ABNO architecture is to provide the raw data that the Path Computation Element operates on. The TED can also be inspected by users at the NMS/OSS to check the current status of the network, and it 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 info 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 built from information gathered from the network by polling or reading the state of LSPs that have already been set up 🫶
The main use of the LSP-DB in the ABNO architecture is to level up the planning and optimization of LSPs 📈 New LSPs can be established to be path-disjoint from other LSPs, so they can offer protected services. LSPs can be rerouted to put them on more optimal paths, or to free up network resources for other LSPs. LSPs can be rapidly repaired when a network failure is reported. LSPs can also be moved onto other paths 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. This assigns 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 🔗
This information is super useful, but it can also be supplemented by more detailed info kept in a separate database. That database is indexed using the SRLG identifier from the TED. It can interpret SRLG information provided by other networks (such as server networks), provide failure probabilities associated with each SRLG, offer prioritization when SRLG-disjoint paths cannot be found, and correlate SRLGs between different server networks or between different peer networks 🎀
2.3.1.8.4. Other Databases 📚
There may be other databases built within the ABNO system that get referenced when operating the network. These could include information about, for example, traffic flows and demands, predicted or scheduled traffic demands, link and node failure and repair history, and 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. In many networks, it's quite likely that this inventory lives in a separate database (the Inventory Database) that includes details like 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. The info is a simplified view, but it's useful for steering application-layer traffic 🦋 ALTO services let service providers share information about network locations and the costs of paths between them. The criteria for choosing between two locations may depend on things like maximum bandwidth, minimum cross-domain traffic, lower cost to the user, etc. 💖
The ALTO Server generates ALTO views to share info with the Application Service Coordinator, so 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 for the Application Service Coordinator. That view has 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 network region can be a single domain or multiple networks. It's 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 available in the upper-layer network. It's 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 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 ✨
Creating a virtual topology for a network is not a simple task 😭 Decisions must be made about which nodes in the upper layer it's 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. On top of that, 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, creating 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 with 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 mean instructions to the control plane running in the networks, or it may involve programming 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 on 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 📝
As noted at the top of Section 2.3, it's 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. So some of the interfaces described below might not be visible as specific relationships in Figure 1, but they can still exist 🦋
2.3.2.1. Configuration and Programmatic Interfaces
okay so the network devices can be configured or programmed straight from the NMS/OSS 💻✨ there are already a bunch of protocols that do this, like:
- 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 built so apps could talk to each other 🫶 it gives network-level management so you can discover, configure, and activate resources. at first, the MTOSI info model could only handle connection-oriented networks and resources, but later releases added support for connectionless networks 🦋 from the NMS point of view, it's a north-bound interface and it runs on SOAP web services. it's giving old-school but it works 💅
from the ABNO perspective, network configuration is just a pass-through function. you can see it on the left-hand side of Figure 1 ✨
2.3.2.2. TED Construction from the Networks
so like we said in Section 2.3.1.8, the TED shows the capabilities and state of the network for the ABNO system, and the PCE especially 👑
the TED can be built by joining the IGP-TE protocols that the networks run (for example, OSPF-TE [RFC3630] and IS-IS TE [RFC5305]). or, the TED can be fed using link-state distribution extensions to BGP [BGP-LS] 🌸
the ABNO system can keep one TED that's unified across multiple networks, or it can keep a separate TED for each network. your choice, bestie 🎀
also, an ALTO Server [RFC5693] can give an abstracted topology from a network, and that can be used to build an application-level TED. then a PCE can use it to compute paths between servers and application-layer entities for application services 🧚
2.3.2.3. TED Enhancement
the TED can get extra info from the NMS/OSS inventory 📦 this adds stuff that usually isn't shared around inside the network, like node types and capabilities, or what the optical links are actually like. it's an upgrade to the data you already collected in Section 2.3.2.2 🔥
no protocol has been picked for this interface yet, but the protocol that gets built (or adopted) for the Interface to the Routing System (I2RS) [I2RS-Arch] requirements might be a good pick, because it needs to be able to distribute bulk routing state info in a well-defined encoding language 💜 another maybe-candidate is NETCONF [RFC6241] carrying data encoded with YANG [RFC6020].
ngl, in general, any combo of protocol and encoding that works for showing the TED (see Section 2.3.2.4) will probably work (or could be made to work) for getting write-access to the TED, which is what this section is about 🙈
2.3.2.4. TED Presentation
the TED can be shown north-bound from the ABNO system to an NMS/OSS or to the Application Service Coordinator. this lets users and apps see the network topology and how the network resources are doing. it also helps with planning and provisioning application services 🌈
there are a few protocols you can use to export the TED north-bound:
- The ALTO protocol [RFC7285] was designed to distribute the abstracted topology an ALTO Server uses, so it might be super useful for exporting the TED 💖 the ALTO Server gives the cost between EPs or between PIDs, so the application layer can pick the most suitable connection for the info exchange between its end points ✨
- The same protocol used to export topology info from the network can also export the topology from the TED [BGP-LS] 🦋
- I2RS [I2RS-Arch] is going to need a protocol that can handle bulk routing info exchanges, and that would fit for exporting the TED. in that case, it would make sense to have a standardized representation of the TED in a formal data modeling language like YANG [RFC6020], so an existing protocol like NETCONF [RFC6241] or the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] could be used 🫶
note that exporting from the TED can be a full dump of the content (in a suitable abstraction language, like we said above), or it can be an aggregated or filtered set of data based on policies or specific requirements 🍓 so the relationships in Figure 1 might be a little simplistic, because the ABNO Controller may also be involved in preparing and presenting the TED info 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 helps the network set up LSPs in response to simple connectivity requests, and it lets the network reoptimize or repair LSPs. main character energy for the network honestly 👑
2.3.2.6. Provisioning Manager Control of Networks
as described in Section 2.3.1.11, the Provisioning Manager makes requests to provision resources in the network, or it channels them along 📡 these operations can happen 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 that get programmed with help from a control plane 🔥
a bunch of protocols already exist to provision network resources, like so:
o Program/configure specific network resources
- ForCES [RFC5810] defines a protocol for separating 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 lets one or more external switch controllers (like the Provisioning Manager) set up and maintain the state of a label switch, such as an MPLS switch 🌸
- OpenFlow [ONF] is a communications protocol that gives an OpenFlow Controller (like 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. these have ranged from non-standard command line interfaces (CLIs) to standards-based options like Transaction Language 1 (TL1) [TL1] and SNMP [RFC3412]. they aren't designed for rapid network operation and they aren't easily programmatic 🙈 they're not proposed for use by the Provisioning Manager as part of the ABNO architecture, so we're leaving them out 💀
- NETCONF [RFC6241] is a more active configuration protocol that may be suitable for bulk programming of network resources 🎀 using it that way depends 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 needed to implement MTOSI 🧚 the CCV then gives middleware abstraction together with the Web Services Description Language (WSDL), so MTOSIs can be bound to different middleware technologies as needed 💜
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 like CLIs, TL1 [TL1], or SNMP [RFC3412]. configuration at this granularity isn't as time-critical as programming individual network resources, because the main job of programming end-to-end connectivity is handed off to the control plane 🌈 still, these mechanisms are unsuitable for programmatic control of the network, so they're not proposed for use by the Provisioning Manager as part of the ABNO architecture 💅
- As noted above, NETCONF [RFC6241] is a more active configuration protocol. this may be especially 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 really well, because the protocol elements needed are exactly the same as the ones 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, be aware 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 keep the twin jobs of computing and requesting paths separate from the provisioning mechanisms in place with any given network 🎀
note that I2RS does not provide a mechanism for controlling network resources at this level, because it's designed to control routing state in routers, not forwarding state in the data plane 🙈
2.3.2.7. Auditing the Network
once resources have been provisioned or connections have been established in the network, it's important that the ABNO system can figure out the state of the network 🔍 similarly, when provisioned resources get modified or taken out of service, the ABNO system needs to understand those changes too. 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 later 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 we talked about in Section 2.3.1.5, the Interface to the Routing System (I2RS) gives you a programmatic way to access (for read and write) the routing state and policy info on routers in the network 🌈 the I2RS Client sends requests to routers in the network to establish or retrieve routing state. those requests use the I2RS protocol, which is going to be based on a combo of NETCONF [RFC6241] and RESTCONF [RESTCONF], with some extra features added on top ✨
2.3.2.9. ABNO Controller Interface to PCE
the ABNO Controller needs to be able to consult the PCE to figure out what services can be provisioned in the network 🫶 there's no reason this interface can't be based on standard PCEP as defined in [RFC5440] 💅
2.3.2.10. VNTM Interface to and from PCE ✨
okay so there are literally two conversations happening between the Virtual Network Topology Manager (VNTM) and the PCE 💅
The first one is for when VNTM wants to figure out which LSPs can even get set up in a network. For that, it uses the standard PCEP interface [RFC5440] to make path computation requests 🦋
The second one is the plot twist 😭. A PCE might find that it cannot compute a requested path, or it might notice (according to some configured policy) that a network is low on resources, like the capacity on some key link is nearly used up. In that case, the PCE may notify the VNTM, and the VNTM may (again, according to policy) go build more virtual topology. This second interface is not currently specified, although the protocol selected or designed to satisfy I2RS might have suitable features (see Section 2.3.2.8). Alternatively, the PCEP Notify message (PCNtf) [RFC5440] could be extended. The options are giving 🤩
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. It also needs to be able to report when service requests finish asynchronously and to convey changes in the status of services 🫶
This interface will also need strong capabilities for security, authentication, and policy. Main character energy, no notes 🔥
This interface is not currently specified. It needs to be a transactional interface that supports the specification of abstract services with enough flexibility for easy extension, while also being concise and easily parsable. Think clean and cute but still powerful 🧚
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 for making requests to the SDN Controller (such as the Floodlight REST API [Flood]). Alternatively, since the Provisioning Manager may also receive instructions from a Stateful PCE, using PCEP extensions might be appropriate in some cases [PCE-Init-LSP] ✨
2.3.2.13. Policy Interfaces 💜
As described in Section 2.3.1.4 and throughout this document, policy is a critical component of the ABNO architecture. Policy is literally the gatekeeper 💅 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 pretty sad 💀
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 has to 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.
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]. 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 gives a bunch of examples of how the ABNO architecture can be applied to provide application-driven and NMS/OSS-driven network operations. The point of these examples is to give some concrete material to demonstrate the architecture so that it's easier to understand, and to show that applying the architecture is done by "profiling" and by selecting only the relevant components and interfaces 🧚
It's also not the intention for this section to be a complete list of every possible ABNO application. The examples broadly cover a number of applications that are commonly discussed, but that doesn't rule out other use cases 💖
The descriptions in this section are not fully detailed applicability statements for ABNO. It's 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). Check out the simple network topology in Figure 2. The three ASes (ASa, ASb, and ASc) connect at AS Border Routers (ASBRs) a1, a2, b1 through b4, c1, and c2. A source node (s) in ASa needs to be connected to a destination node (d) 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 🔥
+--------------+ +-----------------+ +--------------+
|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 sends 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 Management2. 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 keep some confidentiality about their internal resources and topology, they will not share a TED, and each will have its own PCE. In a situation like this, 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 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 find the best options for crossing the ASes 🗺️
Each child PCE applies policy to the requests it receives, to decide whether the request is 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 PCEThe 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 🧵✨
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 🫶
Okay so, the whole end-to-end LSP setup gets drawn out in one picture, and honestly it's giving ✨
+-----------------+
| ABNO Controller |
+--------+--------+
|
V
+------+-------+
| Provisioning |
| Manager |
+------+-------+
|
V
+--------------------+------------------------+
/ Network \
+-------------------------------------------------+Figure 5: Provisioning the End-to-End LSP
3b. Provisioning through Programming Network Resources
Bestie, another option is that the LSP gets provisioned hop by hop from the Provisioning Manager 💅 using a mechanism like ForCES [RFC5810] or OpenFlow [ONF], as described in Section 2.3.2.6. The picture here is the same as Figure 5 🦋 The ABNO Controller and the Provisioning Manager talk to each other over PCEP or NETCONF, as described in option 3a, and the Provisioning Manager is the one fanning the requests out to the individual network elements 🫶
3c. Provisioning with an Active Parent PCE
The Active PCE is described in Section 2.3.1.7, based on the concepts in [PCE-Init-LSP] 🧚 In this approach, the process from option 3a gets modified so the PCE issues a direct PCEP command to the network, without a response being sent back to the ABNO Controller first 😭
This situation is shown in Figure 6, and it could be tweaked so the Provisioning Manager still programs the individual network elements the way option 3b does 🌸
+-----------------+
| 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
Mixing the approaches from options 3b and 3c can give you a combo of mechanisms to program the network so the end-to-end LSP happens 💖 Figure 7 shows how each child PCE can be an Active PCE in charge of 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 with ForCES or OpenFlow, and the LSP segments get stitched together following the ideas in [RFC5150] 🔥 Philosophers may debate whether the parent PCE in this model is active (telling the children to provision LSP segments) or passive (requesting path segments that the children provision). Not me debating this at 2am 💀
+-----------------+
| 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 needs to check that the end-to-end LSP got set up the way it was requested 🔍 If a control plane is being used to establish the LSP, the head-end LSR may send a notification (maybe using PCEP) to report a successful setup. But to be sure the LSP is actually up, the ABNO Controller will ask the OAM Handler to run Continuity Check OAM in the data plane, and then report back that the LSP is ready to carry traffic 🦋
5. Notification of Service Fulfillment 🎀
Finally, once 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 can be checked further by auditing the network, as described in Section 2.3.2.7 👑
3.2. Multi-Layer Networking ✨
Okay so networks are usually built in layers 🧁. These layers can be separate administrative regions or different technologies, and they can also be a client vs. server thing 🎀
It's way better to coordinate resource control and utilization across layers (so you're looking at all the layers together) than to control and optimize each layer on its own. This makes the network more efficient and easier to automate, and it can be called inter-layer traffic engineering 💖
The PCE architecture supports inter-layer traffic engineering [RFC5623], and together with the ABNO architecture it gives you a whole suite of tools for coordinating network resources across multiple layers 💅
The use case below shows ABNO coordinating server-layer resources to create a virtual topology in a client-layer network, so that a request for end-to-end client-layer connectivity can be satisfied 🦋. Let's look at 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's connectivity in the packet layer between routers P1, P2, and P3, and also between routers P4, P5, and P6, but there's no packet-layer connectivity between these two islands of routers. That might be because of a network failure, or because all the existing bandwidth between the islands has 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. Basically, 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 so it can 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. Then it determines that no path is immediately available 😭.
+-----------------+
| 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, the PCE doesn't just tell the ABNO Controller it failed. Instead, it 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 means provisioning can be initiated by the optical-layer PCE or by its user, the VNTM. The command can be 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's 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 🫶.
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. So the VNTM will need to coordinate with the OAM Handler to make sure the LSP is ready for use 🔥.
3.2.1. Data Center Interconnection across Multi-Layer Networks
okay so bestie, new cloud apps are literally everywhere 🌸 real-time data backup, virtual machine migration, server clustering, load reorganization... and they all need IT resources that can be spun up and allocated dynamically ✨ which means the interconnection of multiple, remote Data Centers (DCs) is becoming a must-have 💅
here's the tea 🫖 those inter-DC links usually run on static circuits or dedicated leased lines, and ngl that's so inefficient for resource use 😭 on top of that, a basic requirement is that a group of remote DCs can be operated logically as one big DC. main character energy 👑
the data plane tech is different depending on the operator and provider. their customers might rent lambda switch capable (LSC), packet switch capable (PSC), or time division multiplexing (TDM) services 🦋 and the ABNO architecture and Controller are what make dynamic end-to-end network service provisioning possible, no matter which service and transport layers are underneath 🫶
so the interconnection of DCs can get messy 💀 you've got heterogeneous environments to deal with: each DC site, plus the metro-core network segment that links them, and they differ not just in data plane technology but also in control plane. for example, each DC site or domain could be controlled locally in a centralized way (e.g., via OpenFlow [ONF]), while the metro-core transport infrastructure is controlled by GMPLS. OpenFlow is especially adapted to single-domain intra-DC networks (packet-level control, lots of routing exceptions) 🌈 but 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 🧚
applying an ABNO architecture and related procedures involves the following aspects:
- Request from the Application Service Coordinator or NMS
As shown in Figure 13, the ABNO Controller gets a request from the Application Service Coordinator or from the NMS to create a new end-to-end connection between two end points 💖 how those end points get addressed is covered 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
- Address Mapping
so to compute an end-to-end path, the PCE needs a unified view of the whole topology 🔥 which means it has to look at the actual end points in terms of their client network addresses. the ABNO Controller and/or the PCE may need to translate or map addresses from different address spaces. depending on how topology info gets disseminated and gathered, there are two possible scenarios:
2a. The Application Layer Knows the Client Network Layer
entities in the application layer may have an interface with the TED or with an ALTO Server, which lets them map the high-level end points to network addresses 🎀 how that address correlation works is out of scope for this document, but it relies on direct interfaces to other ABNO components as well as the interface to the ABNO Controller.
in this scenario, the request from the NMS or Application Service Coordinator already contains addresses in the client-layer network. so when the ABNO Controller asks the PCE to compute a path between two end points, the PCE can just 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
here, when the ABNO Controller gets a request from the NMS or Application Service Coordinator, the request only contains identifiers from the application-layer address space 🙈 for the PCE to compute an end-to-end path, those identifiers have to be converted to addresses in the client-layer network. the ABNO Controller can do this translation, since it can access the TED and ALTO databases, which lets the path computation request it sends to the PCE simply be contained within one network and TED. or, the computation request could use the application-layer identifiers and leave the address mapping to the PCE 🧠
note that to avoid any confusion, both approaches in this scenario require clear identification of the address spaces in use 🫶
- Provisioning Process
once the path has been obtained, the Provisioning Manager receives a high-level provisioning request to provision the service ✨ since, in this use case, the network elements aren't necessarily configured using the same protocol, the end-to-end path gets split into segments. the ABNO Controller coordinates or orchestrates the establishment by adapting and/or translating the abstract provisioning request into 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 🦋
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, either through manual configuration or discovery 🔍
+-----------------+
| ABNO Controller |
+-------+---------+
|
|
V
+------+ +------+-------+
| VNTM +--<--+ PCE |
+---+--+ +------+-------+
| |
V V
+-----+---------------+------------+
| Provisioning Manager |
+----------------------------------+
| | | | |
V | V | V
OpenFlow V ForCES V PCEP
NETCONF SNMPFigure 14: Provisioning Process
- Verification and Notification of Service Fulfillment
once the end-to-end connectivity service is provisioned, and after the correct operation of the service has been verified 🥳 the ABNO Controller needs to notify the Application Service Coordinator or NMS.
3.3. Make-before-Break
a bunch of different services depend on setting up a new LSP so that traffic on an existing LSP can be switched over 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 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 like reoptimization of in-service LSPs, so it's lowkey a big deal 🔥
the process is simple 💅 the example in Figure 15 uses a Stateful PCE [Stateful-PCE] to monitor the network and take reoptimization actions when needed. 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 lets the ABNO Controller 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 get 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. according to the configured policy, it 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's 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 ✨
okay so bestie, this one is about repairing an LSP that broke 🥺 Make-before-break can also be used here when you want to hang onto resources along part of the path, and there's a real risk that other LSPs will "steal" those resources if the broken one gets torn down first 😱 Unlike the one in Section 3.3.1, the service does get interrupted here, but that interruption comes from the network failure itself, not from the switchover 💔 And if it's a point-to-multipoint LSP, the failure might only hit part of the tree. So a make-before-break restoration won't disrupt the leaves that weren't affected by the original failure 🌳✨
Figure 16 shows which components are in the mix for this use case 🦋 A requester, like the OSS, sends a service request to the ABNO Controller. That request says the LSP may be restored after a failure and should try to reuse as much of the original path as possible 💅
The ABNO Controller tells the PCE to compute and set up the initial path 🧚 It also asks the OAM Handler to kick off OAM on the LSP and keep an eye on the results 👀
At some point the network reports a fault to the OAM Handler, which then lets the ABNO Controller know 🚨
The ABNO Controller tells the PCE to compute a new path that reuses as much of the original as possible, and the PCE sets up the new LSP 🎀
Once the new path is up and the network says it's being used correctly, the ABNO Controller tells 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 Process3.3.3. Make-before-Break for Path Test and Selection 🔥
this one's a bit more complicated, not gonna lie 😭 An LSP might be monitored for stuff like delay and jitter. When it dips below a threshold, the traffic can move to another LSP that offers the desired (or at least a better) quality of service ✨ To pull that off, you have to set up the new LSP and test it first, and since the traffic can't get interrupted, make-before-break is a MUST here 💜
It might also be that no new LSP can give you the attributes you want, so you need to test a bunch of LSPs and pick the best one 🍓 Even when the original LSP is already up, it could be worth testing a few before deciding which one should carry the traffic 👑
Figure 17 shows the components for this use case 🌈 Since several LSPs might exist at the same time, you need a distinct action to coordinate which one carries the traffic. That's the job of the I2RS Client, acting under the control of the ABNO Controller 💅
The OAM Handler is in charge of starting the tests on the LSPs and reporting the results back to the ABNO Controller 🧚 It 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 could be built by stitching together an MPLS segment, an Ethernet/VLAN segment, another IP segment, and so on 🌸
Otherwise, the process is basically the same as reoptimization, which we covered in Section 3.3.1 🫶
+---------------------------------------------+
| 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 ProcessThe 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
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
EndIf3.4. Global Concurrent Optimization 🌟
Global Concurrent Optimization (GCO) is defined in [RFC5557] and is a key technology for maximizing network efficiency by computing a set of traffic-engineered paths concurrently 💖 A GCO path computation request looks at the entire topology of the network and the complete set of new LSPs, along with their respective constraints, all at once. GCO can also be applied to recompute the paths of a set of existing LSPs 🫧
GCO may be requested in a number of scenarios. These include:
- Routing of new services where the PCE should consider other services or network topology. 🌷
- A reoptimization of existing services due to fragmented network resources or suboptimized placement of sequentially computed services. 🍭
- 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 📊 GCO's concurrent computation gives a big network optimization advantage, so network resources get used optimally and blocking gets avoided ✨🎀
The following use case shows how the ABNO architecture and components are used to achieve concurrent optimization across a set of services 🦋
3.4.1. Use Case: GCO with MPLS LSPs 🎀
okay so when we're thinking about the GCO path computation problem 💅, the GCO objective functions split into three optimization categories:
- Minimize aggregate Bandwidth Consumption (MBC).
- Minimize the load of the Most Loaded Link (MLL).
- Minimize Cumulative Cost of a set of paths (MCC).
this use case assumes the GCO request is offline and starts from an NMS/OSS 🧚. so yes, it can take a while to compute, and the paths that come back might get checked by the user before anything is provisioned in the network. no rushing, bestie 🫶
1. Request Management
the NMS/OSS sends a request for new service connectivity for bulk services ✨. the ABNO Controller checks that the NMS/OSS has enough rights to make the request, then applies a GCO attribute asking 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, a destination, and a bandwidth request 🍓. these get sent to the ABNO Controller and categorized as GCO requests. the PCE uses the right policy for each request and checks the TED for the packet layer, which is giving organized 📋.
2. Service Path Computation in the Packet Layer
so for the GCO app to compute a set of services, 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. once the bulk (GCO) service requests come in, the PCE applies the MBC objective function and computes the services concurrently 🔥.
2c. when the GCO service path computation is done, the PCE sends the resulting paths back to the ABNO Controller. the response includes a fully computed explicit path for each service (TE LSP) 👑.
3. the concurrently computed solution the PCE sent back goes from the ABNO Controller to the NMS/OSS as a PCEP response, as shown in Figure 20 🦋. the NMS/OSS user can then look at the candidate paths and either provision the new services or save the solution for later deployment 💅.
+---------------------+
| NMS/OSS |
+----------+----------+
^
|
+----------+----------+
| ABNO Controller |
| |
+---------------------+Figure 20: ABNO Sends Solution to the NMS/OSS
3.5. Adaptive Network Management (ANM) 🌈
the ABNO architecture gives you reactive network control of resources 🧠. it relies on classification, profiling, and prediction based on current demands and resource utilization. server-layer transport network resources, like 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. this is called Elastic Optical Networks (EON) [EON] ✨.
EON is spectrum-efficient and scalable transport 💖. it adds flexible, granular traffic grooming in the optical frequency domain. this happens through arbitrary contiguous concatenation of the optical spectrum, which lets you create custom-sized bandwidth. that bandwidth is defined in slots of 12.5 GHz 🎀.
Adaptive Network Management (ANM) with EON lets you allocate appropriately sized optical bandwidth to an end-to-end optical path 🧚. in flexi-grid, the allocation follows the traffic volume, the optical modulation format, and the associated reach, or user requests, and it can be done in a highly spectrum-efficient and scalable way 💜. OTN does something similar, providing flexible and granular bandwidth provisioning on top of Wavelength Switched Optical Networks (WSONs) 🦋.
to use optical resources efficiently, you need a system that can monitor network resources and decide the optimal network configuration based on status, bandwidth availability, and user service. we call this ANM 💅.
3.5.1. ANM Trigger
there are different reasons to trigger an adaptive network management process 🍓. these include:
- Measurement: traffic measurements can drive spectrum allocations that fit the traffic needs as efficiently as possible. this can be influenced by measuring 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 isn't directly involved in this case 🙈.
- Human: operators may request ABNO to run an adaptive network planning process via an NMS 🫶.
- Periodic: an adaptive network planning process can 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 from the previous section, the OSS or NMS sends a request to the ABNO Controller to perform EON-based GCO 🌸. the ABNO Controller selects a set of services to be reoptimized and chooses an objective function that delivers the best use of network resources ✨. when making those 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 gets passed to the PCE, like we described in Section 3.4 🧚. the PCE can then consider the end-to-end paths and every channel's optimal spectrum assignment, so it can satisfy traffic demands and optimize optical spectrum consumption in the network 🔥.
the PCE operates on the TED but is likely to be stateful too, so it knows which LSPs correspond to which waveband allocations on which links 🧠. once the PCE has an answer, it returns a set of potential paths to the ABNO Controller, which passes them on to the NMS or OSS to supervise or select the next path setup or modification process 💅.
this exchange is shown in Figure 21 🦋. the figure doesn't show the interactions the OSS/NMS uses to establish or modify LSPs in the network, so keep that in mind 🙈.
+---------------------------+
| OSS or NMS |
+-----------+---+-----------+
| ^
V |
+------+ +----------+---+----------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+---+----------+
| ^
V |
+-----+---+----+
+ PCE |
+--------------+Figure 21: Adaptive Network Management with Human Intervention
3.5.3. Automated Provisioning Process
most network operations are supervised by the operator, but some actions don't need supervision 🌈. one example is a simple modification of a modulation format in a Bit-rate Variable Transponder (BVT), which can increase optical spectrum efficiency or reduce energy consumption ⚡. in this process, where human intervention isn't required, the PCE sends the Provisioning Manager a new configuration to set up the network elements, as shown in Figure 22 💜.
+------------------------+
| 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] work as a layered network sitting on top of the connectivity the MPLS network provides 🧚. the pseudowires are carried by LSPs acting as transport tunnels, and planning is needed to work out how those tunnels get placed in the network and which tunnels each pseudowire uses 💅.
this section looks at four use cases: multi-segment pseudowires, path-diverse pseudowires, path-diverse multi-segment pseudowires, and pseudowire segment protection ✨. Section 3.6.5 describes how the ABNO architecture applies to these four use cases 🫶.
3.6.1. Multi-Segment Pseudowires ✨
okay so [RFC5254] is the one that lays out the architecture for multi-segment pseudowires 🦋 An end-to-end service (see Figure 23) can be a bunch of stitched segments, which the figure labels AC, PW1, PW2, PW3, and AC. Each pseudowire segment gets stitched together at a "stitching Provider Edge" (S-PE). So PW1 is stitched to PW2 at S-PE1 💖 Each access circuit (AC) gets stitched to a pseudowire segment at a "terminating PE" (T-PE). For example, PW1 meets the AC at T-PE1 🎀
Each pseudowire segment rides across the MPLS network inside an LSP that's acting as a transport tunnel. So PW1 is carried in LSP1 🌸 The LSPs between PE nodes can cross different MPLS networks with the PEs sitting on the borders, or the PEs can live inside one network so each LSP only covers part of it. Both are giving main character energy ✨
----- ----- ----- -----
--- |T-PE1| LSP1 |S-PE1| LSP2 |S-PE3| LSP3 |T-PE2| +---+
| | AC | |=======| |=======| |=======| | AC | |
|CE1|----|........PW1........|..PW2........|..PW3........|----|CE2|
| | | |=======| |=======| |=======| | | |
--- | | | | | | | | +---+
----- ----- ----- -----
Figure 23: Multi-Segment PseudowireOkay now the real world is way messier than that clean little diagram 😭 Figure 24 shows a small mesh of PEs. The links between the PEs aren't physical cables. They just stand for the possible MPLS LSPs between the PEs 🧚
When you set up the end-to-end service between Customer Edge nodes (CEs) CE1 and CE2, you have to pick which PEs to use. In other words, you need a path computation to figure out the pseudowire segment "hops." Then the LSP tunnels that carry those stitched segments have to be set up 🔥
And of course, each LSP might need its own path computation to route it through the MPLS network between PEs. Layers on layers 💀
The path for the multi-segment pseudowire depends on things like:
- MPLS connectivity
- MPLS bandwidth availability
- pseudowire stitching capability and capacity at PEs
- policy and confidentiality considerations for use of PEs
-----
|S-PE5|
/-----\
--- ----- -----/ \----- ----- ---
|CE1|----|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|----|CE2|
--- -----\ -----\ ----- /----- ---
\ | ------- | /
\ ----- \----- /
-----|S-PE2|-------|S-PE4|-----
----- -----
Figure 24: Multi-Segment Pseudowire Network Topology3.6.2. Path-Diverse Pseudowires 🌈
Pseudowire connectivity may need to survive failures, and honestly that's the whole point 🫶 Usually this gets handled by provisioning a pair of pseudowires that ride on path-diverse LSPs across the network (see Figure 25). The terminology comes straight from [RFC3985] 💅 In this setup, the tricky part is keeping the two LSPs (LSP1 and LSP2) disjoint inside the MPLS network. Honestly this is the same old MPLS path-diversity problem, nothing new 😌
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
----...................PW1...................----
--- - / | |=======================| | \ -----
| |/ | | | | \| |
| CE1 + | | MPLS Network | | + CE2 |
| |\ | | | | /| |
--- - \ | |=======================| | / -----
----...................PW2...................----
AC | |=======================| | AC
| | LSP2 | |
------- -------
Figure 25: Path-Diverse PseudowiresNow the plot thickens 👀 Figure 26 builds on that by "dual-homing" each CE through more than one PE. The LSP path diversity requirement is exactly the same, but it gets harder because the LSPs have different end points. Here, the head-end router (e.g., PE1) can't be counted on to keep the paths diverse through the signaling protocol, since it only knows the path of one of the LSPs. So some kind of coordinated path computation approach is needed 🔥
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
---...................PW1...................---
/ | |=======================| | \
----- / | | | | \ -----
| |/ ------- ------- \| |
| CE1 + MPLS Network + CE2 |
| |\ ------- ------- /| |
----- \ | PE3 | | PE4 | / -----
\ | |=======================| | /
---...................PW2...................---
AC | |=======================| | AC
| | LSP2 | |
------- -------
Figure 26: Path-Diverse Pseudowires with Disjoint PEs3.6.3. Path-Diverse Multi-Segment Pseudowires 💜
Figure 27 shows how the two services from the last sections can team up to give end-to-end diverse paths in a multi-segment setup 🧚 To get end-to-end resilience to failure, you may need two totally diverse, end-to-end multi-segment pseudowires 🫶
----- -----
|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 TopologyJust like with any diverse-path computation, you have to think about the second fully diverse path while you're picking the first one 🧠 If you did a sequential computation on the topology in Figure 27, picking the first path CE1,T-PE1,S-PE1, S-PE3,T-PE2,CE2 would make it impossible to find a second path that's fully diverse from it 💀
It gets more complicated because of the multi-layer nature of the network 😩 Choosing diverse PEs isn't enough, since the LSP tunnels between them might still share links inside the MPLS network. So you need a multi-layer planning solution to hit the level of service you want ✨
3.6.4. Pseudowire Segment Protection 🛡️
Instead of protecting the whole end-to-end pseudowire (the protection service from Section 3.6.3), you can protect individual pseudowire segments or PEs. For example, in Figure 27, the pseudowire between S-PE1 and S-PE5 can be protected by a pair of stitched segments, one running between S-PE1 and S-PE5 and the other between S-PE5 and S-PE3. Figure 28 shows the details 🌸
------- ------- -------
| 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 PseudowireFiguring out pseudowire protection segments takes coordination and planning. And just like in Section 3.6.5, that planning has to keep an eye on the paths LSPs take through the underlying MPLS networks 🫶
3.6.5. Applicability of ABNO to Pseudowires 🦋
ABNO is honestly a perfect fit for planning and controlling pseudowires in the use cases above 💖 The user or application gets one single spot to request services: the ABNO Controller. The ABNO Controller can ask a PCE to look at the topology of pseudowire stitching-capable PEs, plus extra info about PE capabilities like load on PEs and administrative policies. The PCE can then use a series of TEDs, or other PCEs for the underlying MPLS networks, to work out the paths of the LSP tunnels 🧚 At the time of writing, PCEP doesn't support path computation requests and responses for pseudowires. But the concepts are super similar to what already exists, so the extensions needed would be very small ✨
Once the paths are computed, a bunch of different provisioning systems can set up the LSPs and provision the pseudowires under the control of the Provisioning Manager 🎀 The ABNO Controller uses the I2RS Client to tell the network devices what traffic should go on which pseudowires. Together with the OAM Handler, it can make sure failure events get handled correctly, service quality levels look right, and service protection levels stay maintained 💅
In a lot of ways, the pseudowire network is an overlay network (with its own TED and provisioning mechanisms) carried by underlying packet networks. More client networks (the pseudowire payloads) can ride on top of the pseudowire network. So the problem ABNO is tackling here is a classic multi-layer network 🌈
3.7. Cross-Stratum Optimization (CSO) ✨
okay so "stratum" is basically our word for the different layers that matter, like the stuff the app cares about and the stuff the network cares about. Cross-Stratum Optimization (CSO) shows up when the application stratum and the network stratum need to work together, so you get better operational efficiency and better resource use on both sides. it's giving teamwork 🫶
Data center apps are everywhere 💻 video gaming, cloud computing, grid applications, you name it. High-bandwidth video is blowing up too, like remote medical surgery, live concerts, and sporting events. the big vibe here 🔥
This ABNO use case is mostly about data center apps that eat a lot of bandwidth, either all together or one at a time. These apps may also need specific limits on QoS stuff like latency and jitter, so the network has to be on its A-game 💅
3.7.1. Data Center Network Operation 🏢
Data centers come in every size and shape, but they all have compute servers, storage, and application control. They offer app services to end-users, like video gaming, cloud computing, and more. Because those data centers can be spread all over a network, the choices about running app services (like where to spin up another service instance, or which data center a new client gets assigned to) can seriously change what's happening in the network. And honestly, the network's capabilities and state can totally change how well the app performs too. it's a two-way street 👑
These choices usually get made by apps that know very little, or nothing at all, about the network underneath. So those choices can end up suboptimal, either from the app's point of view or when you think about network resource use and quality of service. not ideal bestie 💀
Cross-Stratum Optimization is all about making both the app experience and the network use better by coordinating decisions in the application stratum and the network stratum together 🦋 App resources can be roughly sorted into computing resources (servers of various types and granularities, like Virtual Machines (VMs), memory, and storage) and content (like video, audio, databases, and large data sets). When we say "network stratum," we mean the IP layer and everything below it (for example MPLS, Synchronous Digital Hierarchy (SDH), OTN, and WDM). The network stratum has resources like routers, switches, and links. We're especially hyped about unleashing what MPLS and GMPLS control planes can do at the lower network layers, so they respond to the big aggregate or individual demands coming from the application layer 🚀
This use case shows 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, so we're not going there today 🙈
3.7.1.1. Virtual Machine Migration 🌸
Compute virtualization, delivered through Virtual Machines (VMs), has been a huge key for data center cost savings, consolidation, flexibility, and application scalability. From the software application's point of view, a VM looks like a dedicated processor with dedicated memory and a dedicated operating system. it's literally so iconic 😭
VMs are more than just compute power. They also give you an "application environment" that can be replicated, backed up, and moved around. Different VM configurations may be offered, each optimized for different kinds of processing (for example, memory intensive or throughput intensive) 💜
VMs may be moved between compute resources inside a data center, and they could also be moved between data centers. VM migration helps balance load across data center resources, and it comes in several modes:
(i) scheduled vs. dynamic;
(ii) bulk vs. sequential;
(iii) point-to-point vs. point-to-multipointVM migration can solve problems of load or planned maintenance inside a single data center. It can also be useful for reducing network load around the data center. But migrating VMs, especially between data centers, can impact the network and any other services being offered, so it's not a free move 🧚
For certain applications, like disaster recovery, bulk migration is required on the fly. That may mean concurrent computation and path setup have to happen dynamically 🔥
So the application stratum has to take the network stratum's situation into account too, even though the application stratum's actions may be driven by what's going on in the network stratum. it's a loop, periodt 🔁
3.7.1.2. Load Balancing ⚖️
Application servers may be instantiated in many data centers in different parts of the network. When an end-user makes an application request, someone has to decide which data center hosts the processing and storage needed to meet that request. One of the biggest reasons to run multiple data centers (instead of one super huge one) is that the app can run on a machine closer to the end-users, which improves the user experience by cutting network latency. But if the network is congested or the data center is overloaded, that plan can totally backfire 💀
So the key factors when picking the server 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
Again, the choices the application stratum makes need to consider the situation in the network stratum. main character energy for the network, honestly 👑
3.7.2. Application of the ABNO Architecture 🧩
This section shows how the ABNO architecture applies to the cross-stratum data center issues from Section 3.7.1 ✨
Figure 29 shows a diagram of an example data center-based application. A carrier network gives an end-user access through PE4. Three data centers (DC1, DC2, and DC3) are reached through different parts of the network via PE1, PE2, and PE3 🗺️
+----------+ +---------------------------------+
| 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 CentersThe Application Service Coordinator takes in info from the end-user about the services they want, then turns that into service requests and passes them to the ABNO Controller. The end-users might already know which data center they want, or the Application Service Coordinator might be able to figure that out. If neither happens, the ABNO Controller has to do the data center selection itself, and it may use a further database (see Section 2.3.1.8) that holds information about server loads and other data center parameters 🧠
The ABNO Controller looks at the network resources using information gathered from the other ABNO components, then uses those components to configure the network so it supports the end-user's needs 💖
3.7.2.1. Deployed Applications, Services, and Products 📦
The ABNO Controller will need to use a bunch of components to realize the CSO functions described in Section 3.7.1 🫶
The ALTO Server gives info about topological proximity and appropriate geographical location for servers, relative to the underlying networks. That info can be used to optimize the selection of peer location, which helps reduce the path of IP traffic or keep it inside specific service providers' networks. ALTO, working with the ABNO Controller and the Application Service Coordinator, can tackle general problems like picking application servers based on resource availability and the usage of the underlying networks 🦋
The ABNO Controller can also build 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). Honestly, this view shapes more than just how paths from the end-user to the data center get provisioned. It can also guide which data center should provide the service, and possibly even which points of attachment the end-user and the chosen data center should use. A view of how the PCE can fit in with CSO is provided in [CSO-PCE], which the content of Figure 29 is based on 🎀
As already discussed, the ABNO Controller and the Application Service Coordinator together will need to be able to select (and possibly migrate) the location of the VM that provides the service for the end-user. A common trick for steering the end-user to the right VM/server is DNS redirection, so an important capability of the ABNO Controller will be the ability to program the DNS servers accordingly 🌈
And as noted in other sections of this document, the ABNO Controller can coordinate where traffic gets placed in the network to achieve load balancing and to provide resilience to failures. These features can be used together with the functions above, so the placement of new VMs, the traffic they generate, and the load caused by VM migration can all be carried by the network without disrupting existing services 💅✨
3.8. ALTO Server ✨
okay so the ABNO architecture lets you do joint network and application-layer optimization 🧚 the app gets shown an abstract network topology with only the stuff it actually cares about, then it works out its own application-layer routing based on its own application objective. and if it wants, it can talk to the ABNO Controller to set up explicit LSPs that back up that app-layer routing 💜
let's walk through how this plays out, bestie 🫶
1. Application Request of Application-Layer Topology 🌸
so picture the network in Figure 30. it's got five nodes and six links, and it's giving busy 💅
+----+ 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 application has endpoints hosted at N0, N1, and N2. it asks for network topology so it can compute its app-layer routing, like if it wants to max out the throughput of content replication between endpoints across those three sites. main character energy ✨
the request lands at the ABNO Controller, which passes it along to the ALTO Server. the ALTO Server checks in with the Policy Agent, the TED, and the PCE, and then hands back an abstract, app-layer topology 🎀
for example, the policy might say the bandwidth exposed to the app may not exceed 40 Mbps. and the network has already figured out that the route from N0 to N2 should go N0->N3->N2, based on goals like GCO (see Section 3.4) 🍓 so the ALTO Server can make a reduced topology for the app, like the one in Figure 31 👑
+----+
| 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 the existing routing to build an abstract network map with three PIDs. the pair-wise bandwidth and shared bottlenecks get worked out from the internal topology and then show up in the cost maps. so cute, right? 🥹
2. Application Computes Application Overlay 💖
now the app takes that abstract topology and figures out its own app-layer routing. just for concreteness, it might compute a spanning tree to maximize the total bandwidth from N0 to N2. Figure 32 shows one example: N0->N1->N2 carrying 35 Mbps, plus N0->N2 carrying 30 Mbps, for a grand total of 65 Mbps 🔥
+----+
| 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 app can send its app routes to the ABNO Controller so it can set up explicit LSPs to support what it's doing. the ABNO Controller then consults the ALTO maps to map the app-layer routing back onto the internal network topology, and after that it tells the Provisioning Manager to set up the paths 🫶 the ABNO Controller may also re-trigger GCO to reoptimize network traffic engineering. such a glow-up 🌸
3.9. Other Potential Use Cases 🦋
this section is basically a placeholder 🧚 it's holding the spot for other potential use cases that might get documented in future documents 💜
3.9.1. Traffic Grooming and Regrooming 🍓
this use case could cover stuff like:
- Nested LSPs
- Packet Classification (IP flows into LSPs at edge routers)
- Bucket Stuffing
- IP Flows into ECMP Hash Bucket
3.9.2. Bandwidth Scheduling ⭐
bandwidth scheduling is all about configuring LSPs based on a given time schedule 🗓️ it can support maintenance or operational schedules, or adjust network capacity based on traffic pattern detection. the ABNO framework gives you the components to enable bandwidth scheduling solutions 💅
4. Survivability and Redundancy within the ABNO Architecture ✨
the ABNO architecture in this document is described in terms of functional units 🧩 each unit could be implemented on its own, or bundled with other units into single programs or products. and each implemented unit or bundle could be deployed on a separate device (like a network server) or on a separate virtual machine (like in a data center). groups of programs could also end up on the same processor 💜 from the point of view of the architectural model, none of these implementation and deployment choices are important, honestly 🙈
same energy with the functional components: the realization of one could be backed 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 to share the processing load of a big pile of computation requests. different instances might have different algorithmic capabilities, so one instance could serve parallel computation requests for disjoint paths while another could compute optimal point-to-multipoint paths 🔥
having multiple instances also makes the model resilient 🛡️ if one instance fails (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 so the resiliency is seamless 🫶
how these features get achieved in an ABNO implementation or deployment is outside the scope of this document 🌸
5. Security Considerations 💀
okay bestie, security is a BIG deal here 😭 the ABNO architecture describes a network system, so security has to play an important part.
first up: the external protocols (the ones shown entering or leaving the big box in Figure 1) must be appropriately secured 🔐 that includes authentication and authorization, to control access to the different functions the ABNO system can perform, to enable different policies based on identity, and to manage control of the network devices.
second: the internal protocols used between ABNO components must also have appropriate security. this is especially true when the components are implemented on separate network nodes 🚨
next, the ABNO system holds a LOT of data about the network, the services carried by the network, and the services delivered to customers. so access to information in the system must be carefully managed 👑 since most of that access goes through the external protocols, the policy-based controls enabled by authentication will be powerful. but also, any data sent from the databases in the ABNO system can reveal details of the network, so it should be considered as a candidate for encryption 🔒 and since ABNO components can access the information stored in the database, you need to make sure all such components are genuine. when components are implemented at remote nodes, also consider encrypting the data that flows between them 😤
the conclusion? all protocols used to realize the ABNO architecture should have rich security features 🔥💅
6. Manageability Considerations 🌈
the whole ABNO architecture is essentially about managing the network, so there's honestly very little extra to say here 🧚 ABNO provides a mechanism to gather and collate information about the network, report it to management applications, store it for future inspection, and trigger actions according to configured policies 💜
the ABNO system will also need its own monitoring and management. this falls 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 ✨
Okay bestie, this is the reading list 📚💅 Every one of these is cited in the doc, and I've kept each title, author list, and date exactly as written so you can look them up yourself 🫶
- [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.
- [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>. - [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>. - [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>. - [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. 🌈 That's the whole list, bestie! 🫶
Appendix A. Undefined Interfaces ✨
okay so this appendix is a quick rundown of the interfaces that aren't defined yet as of writing 🧚 interfaces where you can pick from existing protocols aren't on the list, bestie, so don't go looking for them here 💅
- An interface for adding extra info to the Traffic Engineering Database is covered in Section 2.3.2.3 💜 no protocol is pinned down for it yet, but the candidates are:
- The protocol developed or adopted to meet the requirements of I2RS [I2RS-Arch]
- NETCONF [RFC6241]
- The protocol for the Interface to the Routing System is covered in Section 2.3.2.8 🌸 the I2RS working group decided it'll be built on a mix of NETCONF [RFC6241] and RESTCONF [RESTCONF], with extra additions and changes as needed to get the job done. the details are still TBD 👀
- As described in Section 2.3.2.10, the Virtual Network Topology Manager needs an interface so a PCE or the ABNO Controller can tell it that a client layer needs more virtual topology 🦋 the I2RS protocol might cover this, or it could be done by extending the PCEP Notify message (PCNtf) ✨
- The north-bound interface from the ABNO Controller is what the NMS, OSS, and Application Service Coordinator use to ask for network services that support applications, as described in Section 2.3.2.11 🎀
- the protocol picked or designed for I2RS might handle this, no cap 🔥
- [RFC7297] describes a potential approach for this kind of interface, for a simple use case 💖
- As noted in Section 2.3.2.14, there may be layer-independent data models that offer common interfaces to control, configure, and report OAM 🍓
- As noted in Section 3.6, the ABNO model could be used to place multi-segment pseudowires on a topology made of S-PEs and MPLS tunnels 🌈 the current PCEP definition [RFC5440] and its work-in-progress extensions don't have all the details needed to request those paths, so some work might be needed. the general ideas should be easy to reuse though, and honestly, that work might be needed for PCEs to be useful in lots of other networking scenarios too 😭
Acknowledgements 💖
okay bestie, big thank-yous to the people who chatted about this and reviewed it: 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 🫶 also a shoutout to George Swallow for suggesting the SRLG database could exist ✨ Tomonori Takeda and Julien Meuric left super valuable comments during their Routing Directorate reviews 👑 and Tina Tsou gave feedback during her Operational Directorate review 🌸
this work got funded by the European Union's Seventh Framework Programme for research, technological development, and demonstration 💜 that covered the PACE project, under grant agreement number 619712, and the IDEALIST project, under grant agreement number 317999 🧚
Contributors 🎀
here are the lovely people who contributed 🫶
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
United States
EMail: qzhao@huawei.comVictor Lopez
Telefonica I+D
EMail: vlopez@tid.esRamon Casellas
CTTC
EMail: ramon.casellas@cttc.esYuji Kamite
NTT Communications Corporation
EMail: y.kamite@ntt.comYosuke Tanaka
NTT Communications Corporation
EMail: yosuke.tanaka@ntt.comYoung Lee
Huawei Technologies
EMail: leeyoung@huawei.comY. Richard Yang
Yale University
EMail: yry@cs.yale.eduAuthors' Addresses 🦋
and finally, the authors you can reach out to 💅
Daniel King
Old Dog Consulting
EMail: daniel@olddog.co.ukAdrian Farrel
Juniper Networks
EMail: adrian@olddog.co.uk📦 where this page comes from
- ietf: rfc7491 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms