RFC 7491
A PCE-Based Architecture for Application-Based Network Operations
Pages: 71
Informational
Informational
Part 2 of 4 – Pages 24 to 48
3. ABNO Use Cases
This section provides a number of examples of how the ABNO architecture can be applied to provide application-driven and NMS/OSS-driven network operations. The purpose of these examples is to give some concrete material to demonstrate the architecture so that it may be more easily comprehended, and to illustrate that the application of the architecture is achieved by "profiling" and by selecting only the relevant components and interfaces. Similarly, it is not the intention that this section contain a complete list of all possible applications of ABNO. The examples are intended to broadly cover a number of applications that are commonly discussed, but this does not preclude other use cases. The descriptions in this section are not fully detailed applicability statements for ABNO. It is anticipated that such applicability statements, for the use cases described and for other use cases, could be suitable material for separate documents.3.1. Inter-AS Connectivity
The following use case describes how the ABNO framework can be used to set up an end-to-end MPLS service across multiple Autonomous Systems (ASes). Consider the simple network topology shown in Figure 2. The three ASes (ASa, ASb, and ASc) are connected at AS Border Routers (ASBRs) a1, a2, b1 through b4, c1, and c2. A source node (s) located in ASa is to be connected to a destination node (d) located in ASc. The optimal path for the LSP from s to d must be computed, and then the network must be triggered to set up the LSP.
+--------------+ +-----------------+ +--------------+ |ASa | | ASb | | ASc | | +--+ | | +--+ +--+ | | +--+ | | |a1|-|-|-|b1| |b3|-|-|-|c1| | | +-+ +--+ | | +--+ +--+ | | +--+ +-+ | | |s| | | | | |d| | | +-+ +--+ | | +--+ +--+ | | +--+ +-+ | | |a2|-|-|-|b2| |b4|-|-|-|c2| | | +--+ | | +--+ +--+ | | +--+ | | | | | | | +--------------+ +-----------------+ +--------------+ Figure 2: Inter-AS Domain Topology with Hierarchical PCE (Parent PCE) The following steps are performed to deliver the service within the ABNO architecture: 1. Request Management As shown in Figure 3, the NMS/OSS issues a request to the ABNO Controller for a path between s and d. The ABNO Controller verifies that the NMS/OSS has sufficient rights to make the service request. +---------------------+ | NMS/OSS | +----------+----------+ | V +--------+ +-----------+-------------+ | Policy +-->-+ ABNO Controller | | Agent | | | +--------+ +-------------------------+ Figure 3: ABNO Request Management 2. Service Path Computation with Hierarchical PCE The ABNO Controller needs to determine an end-to-end path for the LSP. Since the ASes will want to maintain a degree of confidentiality about their internal resources and topology, they will not share a TED and each will have its own PCE. In such a situation, the Hierarchical PCE (H-PCE) architecture described in [RFC6805] is applicable. As shown in Figure 4, the ABNO Controller sends a request to the parent PCE for an end-to-end path. As described in [RFC6805], the parent PCE consults its TED, which shows the connectivity between
ASes. This helps it understand that the end-to-end path must
cross each of ASa, ASb, and ASc, so it sends individual path
computation requests to each of PCEs a, b, and c to determine the
best options for crossing the ASes.
Each child PCE applies policy to the requests it receives to
determine whether the request is to be allowed and to select the
types of network resources that can be used in the computation
result. For confidentiality reasons, each child PCE may supply
its computation responses using a path key [RFC5520] to hide the
details of the path segment it has computed.
+-----------------+
| ABNO Controller |
+----+-------+----+
| A
V |
+--+-------+--+ +--------+
+--------+ | | | |
| Policy +-->-+ Parent PCE +---+ AS TED |
| Agent | | | | |
+--------+ +-+----+----+-+ +--------+
/ | \
/ | \
+-----+-+ +---+---+ +-+-----+
| | | | | |
| PCE a | | PCE b | | PCE c |
| | | | | |
+---+---+ +---+---+ +---+---+
| | |
+--+--+ +--+--+ +--+--+
| TEDa| | TEDb| | TEDc|
+-----+ +-----+ +-----+
Figure 4: Path Computation Request with Hierarchical PCE
The parent PCE collates the responses from the children and
applies its own policy to stitch them together into the best
end-to-end path, which it returns as a response to the ABNO
Controller.
3. Provisioning the End-to-End LSP
There are several options for how the end-to-end LSP gets
provisioned in the ABNO architecture. Some of these are described
below.
3a. Provisioning from the ABNO Controller with a Control Plane
Figure 5 shows how the ABNO Controller makes a request through
the Provisioning Manager to establish the end-to-end LSP. As
described in Section 2.3.2.6, these interactions can use the
NETCONF protocol [RFC6241] or the extensions to PCEP described
in [PCE-Init-LSP]. In either case, the provisioning request
is sent to the head-end Label Switching Router (LSR), and that
LSR signals in the control plane (using a protocol such as
RSVP-TE [RFC3209]) to cause the LSP to be established.
+-----------------+
| ABNO Controller |
+--------+--------+
|
V
+------+-------+
| Provisioning |
| Manager |
+------+-------+
|
V
+--------------------+------------------------+
/ Network \
+-------------------------------------------------+
Figure 5: Provisioning the End-to-End LSP
3b. Provisioning through Programming Network Resources
Another option is that the LSP is provisioned hop by hop from
the Provisioning Manager using a mechanism such as ForCES
[RFC5810] or OpenFlow [ONF] as described in Section 2.3.2.6.
In this case, the picture is the same as that shown in
Figure 5. The interaction between the ABNO Controller and the
Provisioning Manager will be PCEP or NETCONF as described in
option 3a, and the Provisioning Manager will be responsible
for fanning out the requests to the individual network
elements.
3c. Provisioning with an Active Parent PCE
The Active PCE is described in Section 2.3.1.7, based on the
concepts expressed in [PCE-Init-LSP]. In this approach, the
process described in option 3a is modified such that the PCE
issues a direct PCEP command to the network, without a
response being first returned to the ABNO Controller.
This situation is shown in Figure 6 and could be modified so
that the Provisioning Manager still programs the individual
network elements as described in option 3b.
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--+----------+ +--------------+
+--------+ | | | Provisioning |
| Policy +-->-+ Parent PCE +---->----+ Manager |
| Agent | | | | |
+--------+ +-+----+----+-+ +-----+--------+
/ | \ |
/ | \ |
+-----+-+ +---+---+ +-+-----+ V
| | | | | | |
| PCE a | | PCE b | | PCE c | |
| | | | | | |
+-------+ +-------+ +-------+ |
|
+--------------------------------+------------+
/ Network \
+-------------------------------------------------+
Figure 6: LSP Provisioning with an Active PCE
3d. Provisioning with Active Child PCEs and Segment Stitching
A mixture of the approaches described in options 3b and 3c can
result in a combination of mechanisms to program the network
to provide the end-to-end LSP. Figure 7 shows how each child
PCE can be an Active PCE responsible for setting up an edge-
to-edge LSP segment across one of the ASes. The ABNO
Controller then uses the Provisioning Manager to program the
inter-AS connections using ForCES or OpenFlow, and the LSP
segments are stitched together following the ideas described
in [RFC5150]. Philosophers may debate whether the parent PCE
in this model is active (instructing the children to provision
LSP segments) or passive (requesting path segments that the
children provision).
+-----------------+
| ABNO Controller +-------->--------+
+----+-------+----+ |
| A |
V | |
+--+-------+--+ |
+--------+ | | |
| Policy +-->-+ Parent PCE | |
| Agent | | | |
+--------+ ++-----+-----++ |
/ | \ |
/ | \ |
+---+-+ +--+--+ +-+---+ |
| | | | | | |
|PCE a| |PCE b| |PCE c| |
| | | | | | V
+--+--+ +--+--+ +---+-+ |
| | | |
V V V |
+----------+-+ +------------+ +-+----------+ |
|Provisioning| |Provisioning| |Provisioning| |
|Manager | |Manager | |Manager | |
+-+----------+ +-----+------+ +-----+------+ |
| | | |
V V V |
+--+-----+ +----+---+ +--+-----+ |
/ AS a \=====/ AS b \=====/ AS c \ |
+------------+ A +------------+ A +------------+ |
| | |
+-----+----------------+-----+ |
| Provisioning Manager +----<-------+
+----------------------------+
Figure 7: LSP Provisioning with Active Child PCEs and Stitching
4. Verification of Service
The ABNO Controller will need to ascertain that the end-to-end LSP
has been set up as requested. In the case of a control plane
being used to establish the LSP, the head-end LSR may send a
notification (perhaps using PCEP) to report successful setup, but
to be sure that the LSP is up, the ABNO Controller will request
the OAM Handler to perform Continuity Check OAM in the data plane
and report back that the LSP is ready to carry traffic.
5. Notification of Service Fulfillment
Finally, when the ABNO Controller is satisfied that the requested
service is ready to carry traffic, it will notify the NMS/OSS.
The delivery of the service may be further checked through
auditing the network, as described in Section 2.3.2.7.
3.2. Multi-Layer Networking
Networks are typically constructed using multiple layers. These
layers represent separations of administrative regions or of
technologies and may also represent a distinction between client and
server networking roles.
It is preferable to coordinate network resource control and
utilization (i.e., consideration and control of multiple layers),
rather than controlling and optimizing resources at each layer
independently. This facilitates network efficiency and network
automation and may be defined as inter-layer traffic engineering.
The PCE architecture supports inter-layer traffic engineering
[RFC5623] and, in combination with the ABNO architecture, provides a
suite of capabilities for network resource coordination across
multiple layers.
The following use case demonstrates ABNO used to coordinate
allocation of server-layer network resources to create virtual
topology in a client-layer network in order to satisfy a request for
end-to-end client-layer connectivity. Consider the simple multi-
layer network in Figure 8.
+--+ +--+ +--+ +--+ +--+ +--+
|P1|---|P2|---|P3| |P4|---|P5|---|P6|
+--+ +--+ +--+ +--+ +--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
Figure 8: Multi-Layer Network
There are six packet-layer routers (P1 through P6) and three optical-
layer lambda switches (L1 through L3). There is connectivity in the
packet layer between routers P1, P2, and P3, and also between routers
P4, P5, and P6, but there is no packet-layer connectivity between
these two islands of routers, perhaps because of a network failure or
perhaps because all existing bandwidth between the islands has
already been used up. However, there is connectivity in the optical
layer between switches L1, L2, and L3, and the optical network is
connected out to routers P3 and P4 (they have optical line cards).
In this example, a packet-layer connection (an MPLS LSP) is desired
between P1 and P6.
In the ABNO architecture, the following steps are performed to
deliver the service.
1. Request Management
As shown in Figure 9, the Application Service Coordinator issues a
request for connectivity from P1 to P6 in the packet-layer
network. That is, the Application Service Coordinator requests an
MPLS LSP with a specific bandwidth to carry traffic for its
application. The ABNO Controller verifies that the Application
Service Coordinator has sufficient rights to make the service
request.
+---------------------------+
| Application Service |
| Coordinator |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
Figure 9: Application Service Coordinator Request Management
2. Service Path Computation in the Packet Layer
The ABNO Controller sends a path computation request to the
packet-layer PCE to compute a suitable path for the requested LSP,
as shown in Figure 10. The PCE uses the appropriate policy for
the request and consults the TED for the packet layer. It
determines that no path is immediately available.
+-----------------+ | ABNO Controller | +----+------------+ | V +--------+ +--+-----------+ +--------+ | Policy +-->--+ Packet-Layer +---+ Packet | | Agent | | PCE | | TED | +--------+ +--------------+ +--------+ Figure 10: Path Computation Request 3. Invocation of VNTM and Path Computation in the Optical Layer After the path computation failure in step 2, instead of notifying the ABNO Controller of the failure, the PCE invokes the VNTM to see whether it can create the necessary link in the virtual network topology to bridge the gap. As shown in Figure 11, the packet-layer PCE reports the connectivity problem to the VNTM, and the VNTM consults policy to determine what it is allowed to do. Assuming that the policy allows it, the VNTM asks the optical-layer PCE to find a path across the optical network that could be provisioned to provide a virtual link for the packet layer. In addressing this request, the optical-layer PCE consults a TED for the optical-layer network. +------+ +--------+ | | +--------------+ | Policy +-->--+ VNTM +--<--+ Packet-Layer | | Agent | | | | PCE | +--------+ +---+--+ +--------------+ | V +---------------+ +---------+ | Optical-Layer +---+ Optical | | PCE | | TED | +---------------+ +---------+ Figure 11: Invocation of VNTM and Optical-Layer Path Computation 4. Provisioning in the Optical Layer Once a path has been found across the optical-layer network, it needs to be provisioned. The options follow those in step 3 of Section 3.1. That is, provisioning can be initiated by the optical-layer PCE or by its user, the VNTM. The command can be
sent to the head end of the optical LSP (P3) so that the control
plane (for example, GMPLS RSVP-TE [RFC3473]) can be used to
provision the LSP. Alternatively, the network resources can be
provisioned directly, using any of the mechanisms described in
Section 2.3.2.6.
5. Creation of Virtual Topology in the Packet Layer
Once the LSP has been set up in the optical layer, it can be made
available in the packet layer as a virtual link. If the GMPLS
signaling used the mechanisms described in [RFC6107], this process
can be automated within the control plane; otherwise, it may
require a specific instruction to the head-end router of the
optical LSP (for example, through I2RS).
Once the virtual link is created as shown in Figure 12, it is
advertised in the IGP for the packet-layer network, and the link
will appear in the TED for the packet-layer network.
+--------+
| Packet |
| TED |
+------+-+
A
|
+--+ +--+
|P3|....................|P4|
+--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
Figure 12: Advertisement of a New Virtual Link
6. Path Computation Completion and Provisioning in the Packet Layer
Now there are sufficient resources in the packet-layer network.
The PCE for the packet layer can complete its work, and the MPLS
LSP can be provisioned as described in Section 3.1.
7. Verification and Notification of Service Fulfillment
As discussed in Section 3.1, the ABNO Controller will need to
verify that the end-to-end LSP has been correctly established
before reporting service fulfillment to the Application Service
Coordinator.
Furthermore, it is highly likely that service verification will be
necessary before the optical-layer LSP can be put into service as
a virtual link. Thus, the VNTM will need to coordinate with the
OAM Handler to ensure that the LSP is ready for use.
3.2.1. Data Center Interconnection across Multi-Layer Networks
In order to support new and emerging cloud-based applications, such
as real-time data backup, virtual machine migration, server
clustering, or load reorganization, the dynamic provisioning and
allocation of IT resources and the interconnection of multiple,
remote Data Centers (DCs) is a growing requirement.
These operations require traffic being delivered between data
centers, and, typically, the connections providing such inter-DC
connectivity are provisioned using static circuits or dedicated
leased lines, leading to an inefficiency in terms of resource
utilization. Moreover, a basic requirement is that such a group of
remote DCs can be operated logically as one.
In such environments, the data plane technology is operator and
provider dependent. Their customers may rent lambda switch capable
(LSC), packet switch capable (PSC), or time division multiplexing
(TDM) services, and the application and usage of the ABNO
architecture and Controller enable the required dynamic end-to-end
network service provisioning, regardless of underlying service and
transport layers.
Consequently, the interconnection of DCs may involve the operation,
control, and management of heterogeneous environments: each DC site
and the metro-core network segment used to interconnect them, with
regard to not only the underlying data plane technology but also the
control plane. For example, each DC site or domain could be
controlled locally in a centralized way (e.g., via OpenFlow [ONF]),
whereas the metro-core transport infrastructure is controlled by
GMPLS. Although OpenFlow is specially adapted to single-domain
intra-DC networks (packet-level control, lots of routing exceptions),
a standardized GMPLS-based architecture would enable dynamic optical
resource allocation and restoration in multi-domain (e.g., multi-
vendor) core networks interconnecting distributed data centers.
The application of an ABNO architecture and related procedures would
involve the following aspects:
1. Request from the Application Service Coordinator or NMS
As shown in Figure 13, the ABNO Controller receives a request from
the Application Service Coordinator or from the NMS, in order to
create a new end-to-end connection between two end points. The
actual addressing of these end points is discussed in the next
section. The ABNO Controller asks the PCE for a path between
these two end points, after considering any applicable policy as
defined by the Policy Agent (see Figure 1).
+---------------------------+
| Application Service |
| Coordinator or NMS |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
Figure 13: Application Service Coordinator Request Management
2. Address Mapping
In order to compute an end-to-end path, the PCE needs to have a
unified view of the overall topology, which means that it has to
consider and identify the actual end points with regard to the
client network addresses. The ABNO Controller and/or the PCE may
need to translate or map addresses from different address spaces.
Depending on how the topology information is disseminated and
gathered, there are two possible scenarios:
2a. The Application Layer Knows the Client Network Layer
Entities belonging to the application layer may have an
interface with the TED or with an ALTO Server allowing those
entities to map the high-level end points to network
addresses. The mechanism used to enable this address
correlation is out of scope for this document but relies on
direct interfaces to other ABNO components in addition to the
interface to the ABNO Controller.
In this scenario, the request from the NMS or Application
Service Coordinator contains addresses in the client-layer
network. Therefore, when the ABNO Controller requests the PCE
to compute a path between two end points, the PCE is able to
use the supplied addresses, compute the path, and continue the
workflow in communication with the Provisioning Manager.
2b. The Application Layer Does Not Know the Client Network Layer
In this case, when the ABNO Controller receives a request from
the NMS or Application Service Coordinator, the request
contains only identifiers from the application-layer address
space. In order for the PCE to compute an end-to-end path,
these identifiers must be converted to addresses in the
client-layer network. This translation can be performed by
the ABNO Controller, which can access the TED and ALTO
databases allowing the path computation request that it sends
to the PCE to simply be contained within one network and TED.
Alternatively, the computation request could use the
application-layer identifiers, leaving the job of address
mapping to the PCE.
Note that in order to avoid any confusion both approaches in
this scenario require clear identification of the address
spaces that are in use.
3. Provisioning Process
Once the path has been obtained, the Provisioning Manager receives
a high-level provisioning request to provision the service.
Since, in the considered use case, the network elements are not
necessarily configured using the same protocol, the end-to-end
path is split into segments, and the ABNO Controller coordinates
or orchestrates the establishment by adapting and/or translating
the abstract provisioning request to concrete segment requests by
means of a VNTM or PCE that issues the corresponding commands or
instructions. The provisioning may involve configuring the data
plane elements directly or delegating the establishment of the
underlying connection to a dedicated control plane instance
responsible for that segment.
The Provisioning Manager could use a number of mechanisms to
program the network elements, as shown in Figure 14. It learns
which technology is used for the actual provisioning at each
segment by either manual configuration or discovery.
+-----------------+
| ABNO Controller |
+-------+---------+
|
|
V
+------+ +------+-------+
| VNTM +--<--+ PCE |
+---+--+ +------+-------+
| |
V V
+-----+---------------+------------+
| Provisioning Manager |
+----------------------------------+
| | | | |
V | V | V
OpenFlow V ForCES V PCEP
NETCONF SNMP
Figure 14: Provisioning Process
4. Verification and Notification of Service Fulfillment
Once the end-to-end connectivity service has been provisioned, and
after the verification of the correct operation of the service,
the ABNO Controller needs to notify the Application Service
Coordinator or NMS.
3.3. Make-before-Break
A number of different services depend on the establishment of a new
LSP so that traffic supported by an existing LSP can be switched with
little or no disruption. This section describes those use cases,
presents a generic model for make-before-break within the ABNO
architecture, and shows how each use case can be supported by using
elements of the generic model.
3.3.1. Make-before-Break for Reoptimization
Make-before-break is a mechanism supported in RSVP-TE signaling where
a new LSP is set up before the LSP it replaces is torn down
[RFC3209]. This process has several benefits in situations such as
reoptimization of in-service LSPs.
The process is simple, and the example shown in Figure 15 utilizes a Stateful PCE [Stateful-PCE] to monitor the network and take reoptimization actions when necessary. In this process, a service request is made to the ABNO Controller by a requester such as the OSS. The service request indicates that the LSP should be reoptimized under specific conditions according to policy. This allows the ABNO Controller to manage the sequence and prioritization of reoptimizing multiple LSPs using elements of Global Concurrent Optimization (GCO) as described in Section 3.4, and applying policies across the network so that, for instance, LSPs for delay-sensitive services are reoptimized first. The ABNO Controller commissions the PCE to compute and set up the initial path. Over time, the PCE monitors the changes in the network as reflected in the TED, and according to the configured policy may compute and set up a replacement path, using make-before-break within the network. Once the new path has been set up and the network reports that it is being used correctly, the PCE tears down the old path and may report the reoptimization event to the ABNO Controller. +---------------------------------------------+ | OSS / NMS / Application Service Coordinator | +----------------------+----------------------+ | +------------+------------+ | ABNO Controller | +------------+------------+ | +------+ +-------+-------+ +-----+ |Policy+-----+ PCE +-----+ TED | |Agent | +-------+-------+ +-----+ +------+ | | +----------------------+----------------------+ / Network \ +-------------------------------------------------+ Figure 15: The Make-before-Break Process3.3.2. Make-before-Break for Restoration
Make-before-break may also be used to repair a failed LSP where there is a desire to retain resources along some of the path, and where there is the potential for other LSPs to "steal" the resources if the
failed LSP is torn down first. Unlike the example in Section 3.3.1, this case addresses a situation where the service is interrupted, but this interruption arises from the break in service introduced by the network failure. Obviously, in the case of a point-to-multipoint LSP, the failure might only affect part of the tree and the disruption will only be to a subset of the destination leaves so that a make-before-break restoration approach will not cause disruption to the leaves that were not affected by the original failure. Figure 16 shows the components that interact for this use case. A service request is made to the ABNO Controller by a requester such as the OSS. The service request indicates that the LSP may be restored after failure and should attempt to reuse as much of the original path as possible. The ABNO Controller commissions the PCE to compute and set up the initial path. The ABNO Controller also requests the OAM Handler to initiate OAM on the LSP and to monitor the results. At some point, the network reports a fault to the OAM Handler, which notifies the ABNO Controller. The ABNO Controller commissions the PCE to compute a new path, reusing as much of the original path as possible, and the PCE sets up the new LSP. Once the new path has been set up and the network reports that it is being used correctly, the ABNO Controller instructs the PCE to tear down the old path. +---------------------------------------------+ | OSS / NMS / Application Service Coordinator | +----------------------+----------------------+ | +------------+------------+ +-------+ | ABNO Controller +---+ OAM | +------------+------------+ |Handler| | +---+---+ +-------+-------+ | | PCE | | +-------+-------+ | | | +----------------------+--------------------+-+ / Network \ +-------------------------------------------------+ Figure 16: The Make-before-Break Restoration Process
3.3.3. Make-before-Break for Path Test and Selection
In a more complicated use case, an LSP may be monitored for a number of attributes, such as delay and jitter. When the LSP falls below a threshold, the traffic may be moved to another LSP that offers the desired (or at least a better) quality of service. To achieve this, it is necessary to establish the new LSP and test it, and because the traffic must not be interrupted, make-before-break must be used. Moreover, it may be the case that no new LSP can provide the desired attributes and that a number of LSPs need to be tested so that the best can be selected. Furthermore, even when the original LSP is set up, it could be desirable to test a number of LSPs before deciding which should be used to carry the traffic. Figure 17 shows the components that interact for this use case. Because multiple LSPs might exist at once, a distinct action is needed to coordinate which one carries the traffic, and this is the job of the I2RS Client acting under the control of the ABNO Controller. The OAM Handler is responsible for initiating tests on the LSPs and for reporting the results back to the ABNO Controller. The OAM Handler can also check end-to-end connectivity test results across a multi-domain network even when each domain runs a different technology. For example, an end-to-end path might be achieved by stitching together an MPLS segment, an Ethernet/VLAN segment, another IP segment, etc. Otherwise, the process is similar to that for reoptimization as discussed in Section 3.3.1.
+---------------------------------------------+ | OSS / NMS / Application Service Coordinator | +----------------------+----------------------+ | +------+ +------------+------------+ +-------+ |Policy+---+ ABNO Controller +----+ OAM | |Agent | | +--+ |Handler| +------+ +------------+------------+ | +---+---+ | | | +-------+-------+ +--+---+ | | PCE | | I2RS | | +-------+-------+ |Client| | | +--+---+ | | | | +-----------------------+---------------+-----+-+ / Network \ +---------------------------------------------------+ Figure 17: The Make-before-Break Path Test and Selection Process The pseudocode that follows gives an indication of the interactions between ABNO components. OSS requests quality-assured service :Label1 DoWhile not enough LSPs (ABNO Controller) Instruct PCE to compute and provision the LSP (ABNO Controller) Create the LSP (PCE) EndDo :Label2 DoFor each LSP (ABNO Controller) Test LSP (OAM Handler) Report results to ABNO Controller (OAM Handler) EndDo Evaluate results of all tests (ABNO Controller) Select preferred LSP and instruct I2RS Client (ABNO Controller) Put traffic on preferred LSP (I2RS Client) DoWhile too many LSPs (ABNO Controller) Instruct PCE to tear down unwanted LSP (ABNO Controller) Tear down unwanted LSP (PCE) EndDo
DoUntil trigger (OAM Handler, ABNO Controller, Policy Agent)
keep sending traffic (Network)
Test LSP (OAM Handler)
EndDo
If there is already a suitable LSP (ABNO Controller)
GoTo Label2
Else
GoTo Label1
EndIf
3.4. Global Concurrent Optimization
Global Concurrent Optimization (GCO) is defined in [RFC5557] and
represents a key technology for maximizing network efficiency by
computing a set of traffic-engineered paths concurrently. A GCO path
computation request will simultaneously consider the entire topology
of the network, and the complete set of new LSPs together with their
respective constraints. Similarly, GCO may be applied to recompute
the paths of a set of existing LSPs.
GCO may be requested in a number of scenarios. These include:
o Routing of new services where the PCE should consider other
services or network topology.
o A reoptimization of existing services due to fragmented network
resources or suboptimized placement of sequentially computed
services.
o Recovery of connectivity for bulk services in the event of a
catastrophic network failure.
A service provider may also want to compute and deploy new bulk
services based on a predicted traffic matrix. The GCO functionality
and capability to perform concurrent computation provide a
significant network optimization advantage, thus utilizing network
resources optimally and avoiding blocking.
The following use case shows how the ABNO architecture and components
are used to achieve concurrent optimization across a set of services.
3.4.1. Use Case: GCO with MPLS LSPs
When considering the GCO path computation problem, we can split the GCO objective functions into three optimization categories: o Minimize aggregate Bandwidth Consumption (MBC). o Minimize the load of the Most Loaded Link (MLL). o Minimize Cumulative Cost of a set of paths (MCC). This use case assumes that the GCO request will be offline and be initiated from an NMS/OSS; that is, it may take significant time to compute the service, and the paths reported in the response may want to be verified by the user before being provisioned within the network. 1. Request Management The NMS/OSS issues a request for new service connectivity for bulk services. The ABNO Controller verifies that the NMS/OSS has sufficient rights to make the service request and apply a GCO attribute with a request to Minimize aggregate Bandwidth Consumption (MBC), as shown in Figure 18. +---------------------+ | NMS/OSS | +----------+----------+ | V +--------+ +-----------+-------------+ | Policy +-->-+ ABNO Controller | | Agent | | | +--------+ +-------------------------+ Figure 18: NMS Request to ABNO Controller 1a. Each service request has a source, destination, and bandwidth request. These service requests are sent to the ABNO Controller and categorized as GCO requests. The PCE uses the appropriate policy for each request and consults the TED for the packet layer.
2. Service Path Computation in the Packet Layer
To compute a set of services for the GCO application, PCEP
supports synchronization vector (SVEC) lists for synchronized
dependent path computations as defined in [RFC5440] and described
in [RFC6007].
2a. The ABNO Controller sends the bulk service request to the
GCO-capable packet-layer PCE using PCEP messaging. The PCE
uses the appropriate policy for the request and consults the
TED for the packet layer, as shown in Figure 19.
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| | | | | |
| Policy +-->--+ GCO-Capable +---+ Packet |
| Agent | | Packet-Layer | | TED |
| | | PCE | | |
+--------+ +--------------+ +--------+
Figure 19: Path Computation Request from GCO-Capable PCE
2b. Upon receipt of the bulk (GCO) service requests, the PCE
applies the MBC objective function and computes the services
concurrently.
2c. Once the requested GCO service path computation completes, the
PCE sends the resulting paths back to the ABNO Controller.
The response includes a fully computed explicit path for each
service (TE LSP).
3. The concurrently computed solution received from the PCE is sent
back to the NMS/OSS by the ABNO Controller as a PCEP response, as
shown in Figure 20. The NMS/OSS user can then check the candidate
paths and either provision the new services or save the solution
for deployment in the future.
+---------------------+
| NMS/OSS |
+----------+----------+
^
|
+----------+----------+
| ABNO Controller |
| |
+---------------------+
Figure 20: ABNO Sends Solution to the NMS/OSS
3.5. Adaptive Network Management (ANM)
The ABNO architecture provides the capability for reactive network
control of resources relying on classification, profiling, and
prediction based on current demands and resource utilization.
Server-layer transport network resources, such as Optical Transport
Network (OTN) time-slicing [G.709], or the fine granularity grid of
wavelengths with variable spectral bandwidth (flexi-grid) [G.694.1],
can be manipulated to meet current and projected demands in a model
called Elastic Optical Networks (EON) [EON].
EON provides spectrum-efficient and scalable transport by introducing
flexible granular traffic grooming in the optical frequency domain.
This is achieved using arbitrary contiguous concatenation of the
optical spectrum that allows the creation of custom-sized bandwidth.
This bandwidth is defined in slots of 12.5 GHz.
Adaptive Network Management (ANM) with EON allows appropriately sized
optical bandwidth to be allocated to an end-to-end optical path. In
flexi-grid, the allocation is performed according to the traffic
volume, optical modulation format, and associated reach, or following
user requests, and can be achieved in a highly spectrum-efficient and
scalable manner. Similarly, OTN provides for flexible and granular
provisioning of bandwidth on top of Wavelength Switched Optical
Networks (WSONs).
To efficiently use optical resources, a system is required that can
monitor network resources and decide the optimal network
configuration based on the status, bandwidth availability, and user
service. We call this ANM.
3.5.1. ANM Trigger
There are different reasons to trigger an adaptive network management process; these include: o Measurement: Traffic measurements can be used in order to cause spectrum allocations that fit the traffic needs as efficiently as possible. This function may be influenced by measuring the IP router traffic flows, by examining traffic engineering or link state databases, by usage thresholds for critical links in the network, or by requests from external entities. Nowadays, network operators have active monitoring probes in the network that store their results in the OSS. The OSS or OAM Handler components activate this measurement-based trigger, so the ABNO Controller would not be directly involved in this case. o Human: Operators may request ABNO to run an adaptive network planning process via an NMS. o Periodic: An adaptive network planning process can be run periodically to find an optimum configuration. An ABNO Controller would receive a request from an OSS or NMS to run an adaptive network manager process.3.5.2. Processing Request and GCO Computation
Based on the human or periodic trigger requests described in the previous section, the OSS or NMS will send a request to the ABNO Controller to perform EON-based GCO. The ABNO Controller will select a set of services to be reoptimized and choose an objective function that will deliver the best use of network resources. In making these choices, the ABNO Controller is guided by network-wide policy on the use of resources, the definition of optimization, and the level of perturbation to existing services that is tolerable. This request for GCO is passed to the PCE, along the lines of the description in Section 3.4. The PCE can then consider the end-to-end paths and every channel's optimal spectrum assignment in order to satisfy traffic demands and optimize the optical spectrum consumption within the network. The PCE will operate on the TED but is likely to also be stateful so that it knows which LSPs correspond to which waveband allocations on which links in the network. Once the PCE arrives at an answer, it returns a set of potential paths to the ABNO Controller, which passes them on to the NMS or OSS to supervise/select the subsequent path setup/modification process.
This exchange is shown in Figure 21. Note that the figure does not show the interactions used by the OSS/NMS for establishing or modifying LSPs in the network. +---------------------------+ | OSS or NMS | +-----------+---+-----------+ | ^ V | +------+ +----------+---+----------+ |Policy+->-+ ABNO Controller | |Agent | | | +------+ +----------+---+----------+ | ^ V | +-----+---+----+ + PCE | +--------------+ Figure 21: Adaptive Network Management with Human Intervention3.5.3. Automated Provisioning Process
Although most network operations are supervised by the operator, there are some actions that may not require supervision, like a simple modification of a modulation format in a Bit-rate Variable Transponder (BVT) (to increase the optical spectrum efficiency or reduce energy consumption). In this process, where human intervention is not required, the PCE sends the Provisioning Manager a new configuration to configure the network elements, as shown in Figure 22.
+------------------------+ | OSS or NMS | +-----------+------------+ | V +------+ +----------+------------+ |Policy+->-+ ABNO Controller | |Agent | | | +------+ +----------+------------+ | V +------+------+ + PCE | +------+------+ | V +----------------------------------+ | Provisioning Manager | +----------------------------------+ Figure 22: Adaptive Network Management without Human Intervention
(page 48 continued on part 3)