tech-invite   World Map     

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

RFC 7491

 
 
 

A PCE-Based Architecture for Application-Based Network Operations

Part 2 of 4, p. 24 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 24 
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      Up      ToC       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       |
                                 +----------+----------+
                                            |
                                            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

Top      Up      ToC       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
      Controller.

Top      Up      ToC       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
      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.

Top      Up      ToC       Page 28 
      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

Top      Up      ToC       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      Up      ToC       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 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

Top      Up      ToC       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
      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.

Top      Up      ToC       Page 32 
                             +-----------------+
                             | 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

Top      Up      ToC       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
      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.

Top      Up      ToC       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      Up      ToC       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    |
                             +-------------+-------------+
                                           |
                                           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.

Top      Up      ToC       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      Up      ToC       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 |
                                  +-------+---------+
                                          |
                                          |
                                          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.

Top      Up      ToC       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
   network.

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

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

                 Figure 15: The Make-before-Break Process

3.3.2.  Make-before-Break for Restoration

   Make-before-break may also be used to repair a failed LSP where there
   is a desire to retain resources along some of the path, and where
   there is the potential for other LSPs to "steal" the resources if the

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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

      :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

Top      Up      ToC       Page 42 
      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.

Top      Up      ToC       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      Up      ToC       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 |
                               +----+------------+
                                    |
                                    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).

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       Page 48 
                         +------------------------+
                         |       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)

Next RFC Part