Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7491

A PCE-Based Architecture for Application-Based Network Operations

Pages: 71
Part 2 of 4 – Pages 24 to 48
First   Prev   Next

Top   ToC   RFC7491 - Page 24   prevText

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.
Top   ToC   RFC7491 - Page 25
          +--------------+ +-----------------+ +--------------+
          |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       |
                  +--------+    +-----------+-------------+
                  | 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
Top   ToC   RFC7491 - Page 26
      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
Top   ToC   RFC7491 - Page 27
   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

      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, 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 |
                              | Provisioning |
                              | Manager      |
               /                  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
          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
Top   ToC   RFC7491 - Page 28
      3c. Provisioning with an Active Parent PCE

          The Active PCE is described in Section, 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 |
                    +--+----------+         +--------------+
      +--------+    |             |         | 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
Top   ToC   RFC7491 - Page 29
          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.
Top   ToC   RFC7491 - Page 30
   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

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
Top   ToC   RFC7491 - Page 31
   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

                             |    Application Service    |
                             |        Coordinator        |
                   +------+   +------------+------------+
                   |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.
Top   ToC   RFC7491 - Page 32
                             | ABNO Controller |
                +--------+     +--+-----------+   +--------+
                | 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

                  +--------+     |      |     +--------------+
                  | Policy +-->--+ VNTM +--<--+ Packet-Layer |
                  | Agent  |     |      |     |      PCE     |
                  +--------+     +---+--+     +--------------+
                               +---------------+   +---------+
                               | 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
Top   ToC   RFC7491 - Page 33
      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

   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  |
                           +--+                    +--+
                           +--+                    +--+
                               \                  /
                                \                /
                                 +--+  +--+  +--+
                                 +--+  +--+  +--+

                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
Top   ToC   RFC7491 - Page 34
      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.
Top   ToC   RFC7491 - Page 35
   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    |
                   +------+   +------------+------------+
                   |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.
Top   ToC   RFC7491 - Page 36
          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.
Top   ToC   RFC7491 - Page 37
      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 |
                      +------+     +------+-------+
                      | 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.
Top   ToC   RFC7491 - Page 38
   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

   Once the new path has been set up and the network reports that it is
   being used correctly, the PCE tears down the old path and may report
   the reoptimization event to the ABNO Controller.

             | OSS / NMS / Application Service Coordinator |
                       |     ABNO Controller     |
               +------+     +-------+-------+     +-----+
               |Policy+-----+      PCE      +-----+ TED |
               |Agent |     +-------+-------+     +-----+
               +------+             |
            /                    Network                    \

                 Figure 15: The Make-before-Break Process

3.3.2. Make-before-Break for Restoration

Make-before-break may also be used to repair a failed LSP where there is a desire to retain resources along some of the path, and where there is the potential for other LSPs to "steal" the resources if the
Top   ToC   RFC7491 - Page 39
   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
Top   ToC   RFC7491 - Page 40

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.
Top   ToC   RFC7491 - Page 41
             | 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


      DoWhile not enough LSPs (ABNO Controller)
        Instruct PCE to compute and provision the LSP (ABNO Controller)
        Create the LSP (PCE)


      DoFor each LSP (ABNO Controller)
        Test LSP (OAM Handler)
        Report results to ABNO Controller (OAM Handler)

      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)
Top   ToC   RFC7491 - Page 42
      DoUntil trigger (OAM Handler, ABNO Controller, Policy Agent)
        keep sending traffic (Network)
        Test LSP (OAM Handler)

      If there is already a suitable LSP (ABNO Controller)
        GoTo Label2
        GoTo Label1

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.
Top   ToC   RFC7491 - Page 43

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.
Top   ToC   RFC7491 - Page 44
   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 |
                  +--------+     +--+-----------+   +--------+
                  |        |     |              |   |        |
                  | 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

      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).
Top   ToC   RFC7491 - Page 45
   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.
Top   ToC   RFC7491 - Page 46

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.
Top   ToC   RFC7491 - Page 47
   This exchange is shown in Figure 21.  Note that the figure does not
   show the interactions used by the OSS/NMS for establishing or
   modifying LSPs in the network.

                           |        OSS or NMS         |
                                       |   ^
                                       V   |
                 +------+   +----------+---+----------+
                 |Policy+->-+     ABNO Controller     |
                 |Agent |   |                         |
                 +------+   +----------+---+----------+
                                       |   ^
                                       V   |
                                 +      PCE     |

      Figure 21: Adaptive Network Management with Human Intervention

3.5.3. Automated Provisioning Process

Although most network operations are supervised by the operator, there are some actions that may not require supervision, like a simple modification of a modulation format in a Bit-rate Variable Transponder (BVT) (to increase the optical spectrum efficiency or reduce energy consumption). In this process, where human intervention is not required, the PCE sends the Provisioning Manager a new configuration to configure the network elements, as shown in Figure 22.
Top   ToC   RFC7491 - Page 48
                         |       OSS or NMS       |
               +------+   +----------+------------+
               |Policy+->-+     ABNO Controller   |
               |Agent |   |                       |
               +------+   +----------+------------+
                              +     PCE     |
                     |       Provisioning Manager       |

     Figure 22: Adaptive Network Management without Human Intervention

(page 48 continued on part 3)

Next Section