[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05                                             
CCAMP Working Group                                        D. Ceccarelli
Internet-Draft                                                  Ericsson
Intended status: Informational                       O. Gonzalez de Dios
Expires: January 12, 2014                                 Telefonica I+D
                                                                F. Zhang
                                                                X. Zhang
                                                     Huawei Technologies
                                                           July 11, 2013


     Use cases for operating networks in the overlay model context
              draft-ceccadedios-ccamp-overlay-use-cases-01

Abstract

   This document defines a set of use cases for operating networks in
   the overlay model context through the Generalized Multiprotocol Label
   Switching (GMPLS) overlay interfaces.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Ceccarelli, et al.      Expires January 12, 2014                [Page 1]


Internet-Draft           Overlay model use cases               July 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Variants of UNI interface  . . . . . . . . . . . . . . . . . .  6
     3.1.  UNI  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  UNI example  . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  ONI  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.1.  Routing info over the ONI  . . . . . . . . . . . . . .  9
   4.  Hybrid Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Adding the PCEP to the UNI . . . . . . . . . . . . . . . . . . 11
     5.1.  Edge-node to core-node PCEP interface  . . . . . . . . . . 11
     5.2.  PCEP and colored UNI . . . . . . . . . . . . . . . . . . . 13
     5.3.  Using PCEP to obtain TE reachability info  . . . . . . . . 13
   6.  Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Use case P1 - Local Trigger  . . . . . . . . . . . . . . . 14
     6.2.  Use case P2 - Remote Signaling . . . . . . . . . . . . . . 14
     6.3.  Use case P3 - Provisioning with requirements over the
           UNI  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.4.  Use case P4 - Provisioning with requirements and
           collection request over the UNI  . . . . . . . . . . . . . 17
     6.5.  Use case P5 - Advertisement of collected metrics in
           the client layer . . . . . . . . . . . . . . . . . . . . . 17
     6.6.  Use case P6 - Provisioning with requirements over the
           ONI  . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.7.  Use case P7 - Dual homing  . . . . . . . . . . . . . . . . 18
   7.  Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1.  Use case R1 - Segment Recovery - Single homing . . . . . . 19
     7.2.  Use case R2 - Local recovery - Dual Homing - Single
           overlay node . . . . . . . . . . . . . . . . . . . . . . . 20
     7.3.  Use case R3 -End to end Recovery - Dual homing -
           Double overlay node  . . . . . . . . . . . . . . . . . . . 20
     7.4.  Use case R4 - Combination of client protection and
           server restoration . . . . . . . . . . . . . . . . . . . . 21
   8.  Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Use case O1 -  . . . . . . . . . . . . . . . . . . . . . . 23
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   13. References to be added . . . . . . . . . . . . . . . . . . . . 24
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     14.2. Informative References . . . . . . . . . . . . . . . . . . 24



Ceccarelli, et al.      Expires January 12, 2014                [Page 2]


Internet-Draft           Overlay model use cases               July 2013


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24


















































Ceccarelli, et al.      Expires January 12, 2014                [Page 3]


Internet-Draft           Overlay model use cases               July 2013


1.  Introduction

   The GMPLS overlay model [RFC 4208] specifies a client-server
   relationship between networks where client and server layers are
   managed as separate domains because of trustiness, scalability and
   operational issue.  By means of procedures from the GMPLS protocol
   suite it is possible to build a topology in the client (overlay)
   network from Traffic Engineering paths in the server network.  In
   this context, the UNI (User to Network Interface) is the demarcation
   point between networks.  It is a boundary where policies,
   administrative and confidentiality issues apply that limit the
   exchange of information.

   This GMPLS overlay model supports a wide variety of network
   scenarios.  The packet over optical scenario is probably the most
   popular example where the overlay model applies.

   In order to exploit the full potential of client/server network
   interworking in the overlay model, it may be desirable to know in
   advance whether is it feasible or not to connect two client network
   nodes [INTERCON-TE].  This requires to have a certain amount of TE
   information of the server network in the client network.  This need
   not be the full set of TE information available within each network,
   but does need to express the potential of providing TE connectivity.
   This subset of TE information is called TE reachability information.

   Reachability can be classified according to the available
   information:

      - Non-qualified reachability: The most basic form of TE
      reachability is just the information of whether is it physically
      feasible to connect two nodes.  Thus, Non-qualified reachability
      is the ability to be able to connect one end point to another.

      - Qualified reachability: In addition to knowing of whether is it
      physically feasible to connect two nodes, the qualified
      reachability information indicates metrics of the potential
      connection.  This metric can be a cost, a service metric (delay),
      bandwidth, etc.

      - Reachability with associated Potential Virtual Link: In this
      case, the client node, in addition to have the information of the
      feasibility of reaching a given destination, it has the
      information of a possible path, that can be established at any
      time through UNI signalling.  This possible path may have been
      pre-computed in advance and may contain the explicit path (e.g.
      ERO).  Thus, client layer topology could be richened with this
      potential virtual TE link information.



Ceccarelli, et al.      Expires January 12, 2014                [Page 4]


Internet-Draft           Overlay model use cases               July 2013


   Current standard GMPLS UNI [RFC 4208] is focused on signaling and
   extensions to the GMPLS UNI [RFC4208] are being proposed to gather a
   tighter integration between the client packet layer and the server
   optical one.  Also, new elements, like the Path Computation element
   (PCE), have become more popular and may also play a role in the
   overlay context.  In order to understand what are the requirements
   that need to be fulfilled, it is necessary to understand current use
   cases, that is, what are the network operators expecting the UNI to
   do.

   The first group of uses cases of the overlay model is related to the
   automatic provisioning, by which the client (overlay) network is able
   to set-up a connection through the server network.  The second group
   of use cases is related to the enhancement of the recovery mechanism
   by a higher coordination of overlay and server networks.

   Summing up, the goal of this document is to overview the network
   scenarios where the overlay model applies and analyze the most
   interesting aspects of the use cases that fall under the above
   definitions, with particular focus on signaling, exchange of info,
   operations, path computation and L1VPN aspects.


2.  Terminology

   The following terms are used within the document:

      - Edge node [RFC4208]: node of the client domain belonging to the
      overlay network, i.e. nodes with at least one interface connected
      to the server domain.

      - Core node [RFC4208]: node of the server domain.

      - Access link: link between core node and edge node.  It is the
      link where the UNI is usually implemented.

      - Remote node: node in the client domain which has no direct
      access to the server domain but can reach it through an edge node
      in its same administrative domain.

      - Local trigger: LSP setup request issued to an edge node.  It
      triggers the setup of a client layer FA through the server domain
      via a UNI interface.

      - Remote trigger: LSP setup request issued to a remote node.  It
      triggers the setup of a client layer LSP which, upon reaching an
      edge node, will use an FA through the server domain dynamically
      provided via an UNI interface.



Ceccarelli, et al.      Expires January 12, 2014                [Page 5]


Internet-Draft           Overlay model use cases               July 2013


3.  Variants of UNI interface

   [RFC4208] defines the GMPLS UNI as an overlay interface allowing for
   the exchange of both routing and signaling messages between a client
   and a server domain.  At that time only signaling extensions and
   procedures for the UNI interface were defined but since them a lot of
   RSVP-TE extensions have been defined (e.g.  [LSP-DIV][TE-REC]).

   In this section a tassonomy of different variants of UNI interfaces
   is provided.

3.1.  UNI

   GMPLS UNI defined in [RFC4208] allows the exchange of RSVP-TE Path
   messages between edge and core nodes including the Explicit Route
   Object (ERO) or Record Route Object (RRO).  This allows for the
   explicit indication of the path (or part of it) to choose in the
   server domain or the recording of the nodes and links chosen
   respectively.

   Subsequently new requirements have been added to the exchange of
   messages between edge and core nodes.  In the message flow from edge
   to core nodes it is desirable to define a number of path computation
   constraints that the server domain needs to consider when providing a
   path that will be used as connection between two edge nodes.  An
   example of path computation constraints consists of: SRLG diversity,
   max latency, max number of hops, etc.  Encoding extensions for adding
   constraints to the server domain path computation are defined in
   [UNI-PLUS] and [LSP-DIV].

   Similarly it is desirable that the core nodes are able to provide the
   edge nodes with the parameters qualifying the path provided.  Such
   set of parameters is the same identified above and encoding
   extensions for its collection are defined in [TE-REC] and [SRLG-
   COLL].

   RSVP-TE extensions are obviously inherited by the UNI interface,
   which has significantly been augmented with respect to the RFC4208
   version.

   In the overlay model applied to the packet-opto environment the UNI
   can be implemented over grey or colored interfaces.  In the former
   case the transponder is placed on the RROADM and the traffic from the
   router to the RROADM has no G.709 framing, while in the latter the
   transponder is moved on the router and the traffic injected into the
   WDM domain is G.709 framed and managed as an alien lambda.  From a
   procedure point of view there is no difference between the grey and
   the colored UNI, what is different is the type of information that



Ceccarelli, et al.      Expires January 12, 2014                [Page 6]


Internet-Draft           Overlay model use cases               July 2013


   the WDM PCE need to be provided with in orded to compute a path in
   the WDM domain but check its feasibility from router to router.

   For applicability considerations regarding the GMPLS UNI please refer
   to [UNI-APP]

3.1.1.  UNI example

   This section provides an example of how SRLGs, latency and other
   types of parameters can be used in the edge node to core node
   direction as path computation constraints and in the reverse
   direction from core node to edge node as path qualifiers.  The
   example is applied to a packet-opto environment.

   In the reference network below, suppose that router 1 wants RROADM A
   to provide a path between A and G with max unidirectional latency
   20ms and SRLG different from (37;52).  Such parameters are passed to
   A via the RSVP-TE Path message.


                       PATH (max latency 20, SRLG !(37;52))
         +---+ ----> /-\       /-\            /-\          +---+
         | 1 |******( A )-----( B )----------( C )*********| 3 |
         +---+       \-/       \-/\           \-/          +---+
                      | \     / |  \         /   \
                      |  \   /  |   \       /     \
                      |   \ /   |    \     /       \
                      |    \    |     \   /         \
                      |   / \   |      \ /           \
         +---+       /-\ /    \/-\     /-\           /-\      +---+
         | 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
         +---+       \-/       \-/     \-/           \-/      +---+


                  Figure 1: Path computation constraints

   Node A performs a constrained path computation in the optical domain
   (A-B-C-G) and provides 1 (via the RSVP-TE RESV message) with the
   parameters qualifying the provided path e.g. max latency 12ms and
   SRLG (11,55).











Ceccarelli, et al.      Expires January 12, 2014                [Page 7]


Internet-Draft           Overlay model use cases               July 2013


                       RESV (latency 12, SRLG (11;55)
         +---+ <---- /-\       /-\            /-\          +---+
         | 1 |******( A )=====( B )==========( C )*********| 3 |
         +---+       \-/       \-/\           \-/          +---+
                      | \     / |  \         /   =
                      |  \   /  |   \       /     =
                      |   \ /   |    \     /       =
                      |    \    |     \   /         =
                      |   / \   |      \ /           =
         +---+       /-\ /    \/-\     /-\           /-\      +---+
         | 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
         +---+       \-/       \-/     \-/           \-/      +---+


                      Figure 2: Real network topology

3.2.  ONI

   A different variant of GMPLS UNI interface can be implemented within
   the overlay model context.  It foresees adding some TE (Traffic
   Engineering) topological information exchange between edge and core
   nodes.  We use the term ONI (Overlay Network Interface) to identify
   this variant of UNI interface with such capabilities.

   The ONI foresees the definition of a virtual topology in the server
   layer (arbitrarily configured by the network operator) which is
   exported by each core border node to its peering edge node by means
   of a routing protocol (e.g.  OSPF-TE, BGP-LS).  Such virtual topology
   comprises a mix of potential virtual TE-links [RFC4847] and virtual
   nodes.

   A virtual TE-link, as defined in RFC4847, is a provider network
   Traffic Engineering (TE) link advertised to customers in routing
   information for purposes that include path computation.  We introduce
   the term potential virtual TE-link to indicate those virtual TE-links
   whose resources are not necessarily reserved or committed in the
   server layer network.

   A potential virtual TE link is advertised via the ONI as a real TE
   link and hence contributes to augmenting the client layer topology.
   Moreover it does not require the allocation of resources in the
   server layer until it is really used thus allowing the mutually
   exclusive sharing of server layer network resources with other
   potential Virtual TE Links.

   On the other side a virtual node is a collection of zero or more
   provider network domain nodes that are collectively represented to
   the clients as a single node that exists in the customer layer



Ceccarelli, et al.      Expires January 12, 2014                [Page 8]


Internet-Draft           Overlay model use cases               July 2013


   network and is capable of terminating of access, inter-domain and
   virtual links. (a virtual node can correspond 1:1 to a physical node,
   to a part of it or to a set of nodes).

   As per the UNI, we define two variations of ONI for the packet-opto
   scenario, namely the ONI when we refer to grey interfaces (i.e.
   transponder on the RROADM) and ONI++ when referring to colored
   interfaces (i.e. transponder on the router).

3.2.1.  Routing info over the ONI

   The following reference network in an IPoWDM environment is used to
   depict what kind of information needs to be advertised to the edge
   nodes in order to augment the client layer topology.



         +---+       /-\       /-\            /-\          +---+
         | 1 |******( A )-----( B )----------( C )*********| 3 |
         +---+       \-/       \-/\           \-/          +---+
                      | \     / |  \         /   \
                      |  \   /  |   \       /     \
                      |   \ /   |    \     /       \
                      |    \    |     \   /         \
                      |   / \   |      \ /           \
         +---+       /-\ /    \/-\     /-\           /-\      +---+
         | 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
         +---+       \-/       \-/     \-/           \-/      +---+


                      Figure 3: Real network topology

   Where:



         +---+
         | 1 | = Edge node       ********* = Access Link (UNI link)
         +---+

          /-\
         ( A ) = Core node       --------- = Core domain real link
          \-/


   Suppose that the network operator decides to let client network see
   two potential virtual TE-links, one between A and C and the other
   between D and G. Figure below show the potential virtual TE-links on



Ceccarelli, et al.      Expires January 12, 2014                [Page 9]


Internet-Draft           Overlay model use cases               July 2013


   the left and corresponding real topology on the right.



   +-+   /-\             /-\   +-+ | +-+   /-\     /-\     /-\   +-+
   |1|**( A )+++++++++++( C )**|3| | |1|**( A )+++( B )+++( C )**|3|
   +-+   \-/             \-/   +-+ | +-+   \-/     \-/#####\-/   +-+
                                   |               #          #
                                   |              #           #
                                   |             #            #
                                   |            #             #
                                   |           #              #
   +-+   /-\             /-\   +-+ | +-+   /-\     /-\     /-\   +-+
   |2|**( D )###########( F )**|4| | |2|**( D )   ( E )   ( F )**|4|
   +-+   \-/             \-/   +-+ | +-+   \-/     \-/     \-/   +-+
   +++ = Pot. Virt. TE-link 1      | +++ = Real path of Pot.V.TE-link 1
   ### = Pot. Virt. TE-link 2      | ### = Real path of Pot.V.TE-link 2


                    Figure 4: Virtual network topology

   From the above figure it is possible to see that the edge nodes, in
   order to be able to compute a path, need to know the following:

      - Access links: availability and TE parameters

      - Potential virtual TE-links: availability, TE parameters,
      diversity, constraints (e.g. latency, packet loss)

      - Virtual nodes: (in figure above a 1 to 1 relationship between
      real and virtual nodes is assumed) availability, connectivity
      matrix, TE parameters, diversity, constraints (in those cases
      where a virtual node is composed of 2 or more real nodes)

   More details on potential virtual TE links diversity can be found at
   [MELG].


4.  Hybrid Nodes

   The overlay model and interfaces can be applied also to hybrid nodes
   [RFC5212], where it is possible to have different control plane
   instances in the client and server domain and keep on exploiting the
   advantages of managing the domains separately without loosing the
   capability of making them tightly interwork.






Ceccarelli, et al.      Expires January 12, 2014               [Page 10]


Internet-Draft           Overlay model use cases               July 2013


5.  Adding the PCEP to the UNI

   In the GMPLS overlay model, the edge nodes do not participate in the
   routing instance of the core network.  This means that the overlay
   network is not aware of the details (topology and TE information) of
   the core network.  Thus, it is generally assumed that, in the case of
   a UNI request, the routing is performed in the core network.

   The operator is able to include a set of constraints that have impact
   on the routing that will be performed in the core network in two
   different ways.  One is to enrich RSVP-TE to include such constraints
   (please see above), and the other one is use the well-defined PCEP
   protocol.

   The main advantage of using the PCEP interface is that the semantics
   for the different queries are well defined.  Moreover, in case
   confidentiality and trustiness is an issue, the Path Key mechanism
   can be used in the answers to hide the details of the path.
   Different possible scenarios are shown bellow.

5.1.  Edge-node to core-node PCEP interface

   The first scenario foresees the provisioning of a PCEP interface from
   the core nodes to the edge nodes.  Such interface is reachable from
   the same interfaces used for the exchange of UNI signaling messages.
   The path computation in the server domain can be centralized or
   distributed.  In the former scenario the core node acts as a proxy
   between the PCC on the edge node and the PCE as shown in figure
   below.






















Ceccarelli, et al.      Expires January 12, 2014               [Page 11]


Internet-Draft           Overlay model use cases               July 2013


                                +------+
                       PCEP     |Server|
                  +------------>|Domain|
                  |             |PCE   |
   +---+ PCEP +-----+           +------+
   |PCC|----->|Proxy|
   +---+      |-----|      /-\        /-\     +---+
   |EN |******| CN  |-----(CN )------(CN )****|EN |
   +---+       \ - /       \-/        \-/     +---+
                 |          |          |
                 |          |          |
                 |          |          |
                             |          |          |
    +---+       /-\        /-\        /-\      +---+
    |EN |******(CN )------(CN )------(CN )*****|EN |
    +---+       \-/        \-/        \-/      +---+


                     Figure 5: PCEP proxy on core node

   On the other hand, when the path computation in the server domain is
   performed in a distributed way, the PCEP interface can be exported by
   the core nodes so to allow the edge node issue path computation
   queries.  See figure below.



   +---+ PCEP +-----+
   |PCC|----->| PCE |
   +---+      |-----|      /-\        /-\     +---+
   |EN |******| CN  |-----(CN )------(CN )****|EN |
   +---+       \ - /       \-/        \-/     +---+
                 |          |          |
                 |          |          |
                 |          |          |
                             |          |          |
    +---+       /-\        /-\        /-\      +---+
    |EN |******(CN )------(CN )------(CN )*****|EN |
    +---+       \-/        \-/        \-/      +---+


                Figure 6: PCEP interface between EN and CN

   In those cases where the addressing space is common between the
   client and the server layer, and hence with the PCE, it is also
   possible to have the PCC on the client layer directly speaking with
   the server domain PCE as shown in figure below.




Ceccarelli, et al.      Expires January 12, 2014               [Page 12]


Internet-Draft           Overlay model use cases               July 2013


                                +------+
                       PCEP     |Server|
     +------------------------->|Domain|
     |                          |PCE   |
   +---+                        +------+
   |PCC|
   +---+       /-\         /-\        /-\     +---+
   |EN |******(CN)--------(CN )------(CN )****|EN |
   +---+       \-/         \-/        \-/     +---+
                 |          |          |
                 |          |          |
                 |          |          |
                             |          |          |
    +---+       /-\        /-\        /-\      +---+
    |EN |******(CN )------(CN )------(CN )*****|EN |
    +---+       \-/        \-/        \-/      +---+


                  Figure 7: PCE and PCC direct connection

5.2.  PCEP and colored UNI

   TBD

5.3.  Using PCEP to obtain TE reachability info

   Although the overlay network does not participate in the routing
   instance of the server network, RFC 4208 allows TE reachability to be
   exchanged between both overlay and server networks.  TE
   reachability,as defined in [INTERCON-TE], is the ability to reach a
   specific address along a TE path.  In the overlay context, TE
   reachibilty indicates if it is possible to reach from one node of the
   overlay network to another one through the server network.  Also, TE
   reachability can indicate some TE metrics of the possible paths
   metrics, hop count, available bandwidth, delay, shared risk.

   The PCEP interface can be used at the UNI border to query from
   overlay network to server network about the possible paths between
   nodes.  The answers do not need to include a full detailed ERO, but
   just a collection of the desired metrics and, either a path key, or
   an ERO with just the end-points.


6.  Provisioning

   Two different use cases can be identified for path provisioning
   depending on where the setup trigger is issued.  They will be called
   Local and Remote Trigger in the following.  Further details regarding



Ceccarelli, et al.      Expires January 12, 2014               [Page 13]


Internet-Draft           Overlay model use cases               July 2013


   different provisioning models over the UNI can be found in [UNI-APP].
   What described below is in addition to the simple provisioning use
   case without constraints defined in [RFC4208].

6.1.  Use case P1 - Local Trigger

   Local Trigger is the use case defined in RFC4208, where a setup
   trigger is issued to one of the edge nodes belonging to the overlay
   network, i.e. directly connected to the UNI.


               1.Trigger (with constraints)
                  |            2. Setup
                  V           ------------>
   +--+   +--+   +--+     /-\       /-\     /-\      +--+   +--+   +--+
   |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7|
   +--+   +--+   +--+     \-/       \-/\    \-/      +--+   +--+   +--+
     \            /        | \     / |  \    |         \           /
      \          /         |  \   /  |   \   |          \         /
       \        /          |   \ /   |    \  |           \       /
        \ +--+ /           |    \    |     \ |            \ +--+/
          |R4|             |   / \   |      \|              |R8|
          +--+            /-\ /    \/-\     /-\             +--+
     3.Advertisement     ( D )-----( E )---( F )      3.Advertisement
                          \-/       \-/     \-/
        *** = overlay interfaces


                          Figure 8: Local trigger

   As it is possible to see in the figure above, a trigger is issued on
   R3 (edge node) for starting the setup request procedure over the UNI
   interface (R3-A).  Such trigger might include an arbitrary set of
   constraints for the path computation in the optical domain.  Once the
   optical LSP is setup and an adjacency in the packet layer between R3
   and R5 is created, it is advertised in the rest of the packet layer
   and used by the signaling protocol (e.g.  LDP) for setting up end-to-
   end (e.g. from R1 to R7) packet LSPs.

6.2.  Use case P2 - Remote Signaling

   A second use case consists on the utilization of a connection
   oriented (e.g.  RSVP-TE) signaling protocol in the packet domain that
   allows issuing the setup trigger directly on the end nodes of the
   packet domain and using the RSVP-TE message for triggering the setup
   of the LSP in the optical domain.





Ceccarelli, et al.      Expires January 12, 2014               [Page 14]


Internet-Draft           Overlay model use cases               July 2013


    1.Trigger (with constraints)
    |       2. Setup
    V ------------->                                  |------------>|
                    |------>----------------->------->|
                    |<-----<-----------------<--------|
   <--------------------------------------------------|-------------|
   +--+   +--+   +--+     /-\       /-\     /-\      +--+   +--+   +--+
   |R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7|
   +--+   +--+   +--+     \-/       \-/\    \-/      +--+   +--+   +--+
     \            /        | \     / |  \    |         \           /
      \          /         |  \   /  |   \   |          \         /
       \        /          |   \ /   |    \  |           \       /
        \ +--+ /           |    \    |     \ |            \ +--+/
          |R4|             |   / \   |      \|              |R8|
          +--+            /-\ /    \/-\     /-\             +--+
                         ( D )-----( E )---( F )
                          \-/       \-/     \-/


                          Figure 9: Local trigger

   The utilization of the remote trigger allows for a strict control of
   the resources that will be used for the setup of the end to end path.
   In particular, two further approaches are possible when using the
   remote trigger: RSVP-TE or BGP approach.  In the case of RSVP-TE it
   is possible to exploit the capabilities of the protocol of signaling
   LSPs across multiple domains and indicate in the ERO (explicit route
   object) the resources that need to be included in the path.  It is
   possible to indicate a strict ERO (i.e. all the indicated resources
   and only those ones must be used) or a loose ERO (i.e. at least the
   indicated resources must be used but the PCEs of the different
   domains decide autonomously how to fill the gaps in the ERO.

6.3.  Use case P3 - Provisioning with requirements over the UNI

   This use case applies to both the local and remote trigger scenarios
   and describes how it is possible for the client layer to ask for a
   connection in the server layer with some constraints.  An example of
   the constraints that can be applied to the path computation in the
   server layer consists of the following criteria:

      + Diversity: it is possible to indicate the resources must or
      should be avoided during the path computation by means of the
      Exclude Router Object (XRO) [RFC4874], the Explicit Exclusion
      Route Subobject (EXRS) [RFC4874] and the LSP subobject [LSP-DIV].
      Such resources consists on:





Ceccarelli, et al.      Expires January 12, 2014               [Page 15]


Internet-Draft           Overlay model use cases               July 2013


         -IPv4 prefix [RFC4874]

         -IPv6 prefix [RFC4874]

         -Unnumbered Interface ID [RFC4874]

         -Autonomous system number [RFC4874]

         -SRLG [RFC4874]

         -IPv4 P2P subobject [LSP-DIV]

         -IPv6 P2P subobject [LSP-DIV]

      + Latency: max delay introduced by the server layer LSP [OF-TEMB]

      + Latency variation: max latency variation allowed for the server
      layer LSP [OF-TEMB]

      + Cost: max cost allowed for the server layer LSP [OF-TEMB]

   The overlay Edge Node can include into the RSVP-TE Path message an
   arbitrary number of path computation constraints for the provisioning
   of the LSP in the server domain.  In figure below and example is
   shown using as path computation constraints: (i) max latency should
   be 20ms and (ii) SRLG must be different from (A;B).


                       PATH (max latency 20-SHOULD, SRLG !(A;B)-MUST)
         +---+ ----> /-\       /-\            /-\          +---+
         | 1 |******( A )-----( B )----------( C )*********| 3 |
         +---+       \-/       \-/\           \-/          +---+
                      | \     / |  \         /   \
                      |  \   /  |   \       /     \
                      |   \ /   |    \     /       \
                      |    \    |     \   /         \
                      |   / \   |      \ /           \
         +---+       /-\ /    \/-\     /-\           /-\      +---+
         | 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
         +---+       \-/       \-/     \-/           \-/      +---+


          Figure 10: Use Case P3 - provisioning with requirements

   If the path computation in the server domain is able to provide an
   LSP meeting the requirements (at least the must ones) such LSP is
   established and a RESV message is returned to the Edge node,
   otherwise an error message (PattErr) is returned.



Ceccarelli, et al.      Expires January 12, 2014               [Page 16]


Internet-Draft           Overlay model use cases               July 2013


6.4.  Use case P4 - Provisioning with requirements and collection
      request over the UNI

   This use case is an extension of Use case P3.  In addition to the
   path request with path computation constraints, the client layer is
   also allowed to request for the collection in the server domain of
   the effective values of the parameters indicated as path computation
   constraints.  The collection of such parameters is indicated via
   dedicated flags in the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES in
   the Path Message.  Flags defined are:

      - Cost collection flag [TE-REC]

      - Latency collection flag [TE-REC]

      - Latency Variation collection flag [TE-REC]

      - SRLG collection flag [SRLG-COLL]

   In the scenario depicted in figure Figure 10 a request with
   constraints on max latency and SRLG diversity might be issued
   together with the request of collecting e.g. the effective SRLGs of
   the provided path.  Collected parameters are returned to the overlay
   edge node via the Record Route Object (RRO) in the RESV message.

6.5.  Use case P5 - Advertisement of collected metrics in the client
      layer

   In the case of local trigger, that is when a forwarding adjacency
   (FA) is created between two nodes in the client domain by means of an
   LPS in the server domain, it is desirable to advertise the
   characteristics of such FA in the client domain so that an informed
   path computation in the client layer can be performed.

   Interior Gateway Protocol (IGP) extensions for the advertisement of
   the TE metrics characterizing such forwarding adjacencies have been
   defined for IS-IS [ISIS-TEMET] and OSPF-TE [OSPF-TEMET].

   It is also possible to perform such advertisement by means of BGP-LS,
   where the collected data are sent to the route reflector and then
   forwarded to all the BGP speakers in the different client domains.

6.6.  Use case P6 - Provisioning with requirements over the ONI

   In the case of ONI/ONI++ each overlay edge node is provided with the
   overlay topology of the server domain as indicated in section
   Section 3.2.  When a trigger is receiver by the edge node (local or
   remote), it is able to choose among the different available paths



Ceccarelli, et al.      Expires January 12, 2014               [Page 17]


Internet-Draft           Overlay model use cases               July 2013


   depending on which one meets the constraints included into the
   trigger.  When a path is selected, the signaling procedure occurs
   accordingly with a standard RSVP-TE signaling procedure including a
   strict (or loose) ERO.  For more details please see [ENNI].

6.7.  Use case P7 - Dual homing

   A quite common case is the need for provisioning two (or more)
   optical paths with different ingress and egress nodes (i.e. different
   CNs) with diversity constraints.  This is needed to provide two
   totally disjoint paths in the client layer without any kind of single
   point of failure (e.g. a single UNI link or a single edge node) in
   order to create protection schemes in the packet layer like e.g. 1+1
   protection.

   In this case some sort of info exchange in the client domain is
   needed and can be provided in two ways:

      - Coordination between 1 and 3

      - Coordination between 2-1 and 2-3 [UNI EXT]

   In both cases node 1 is supposed to ask the optical domain to provide
   a path (e.g. restorable [RFC4873]) and collect its SRLGs, then pass
   such SRLGs info to node 3 (directly or via 2).  Hence node 3 will ask
   the optical domain to provide a path (e.g. restorable) avoiding the
   given SRLGs.

                              SRLG:27
         +---+       /-\SRLG:21/-\  SRLG:36 /-\          +---+
       ++| 1 |++++++( A )+++++( B )++++++++( C )+++++++++| 4 |++
       + +---+       \-/       \-/\       / \-/\         +---+ +
       +    |         | \     /    \     /      \              +
    +---+   |SRLG:(21,|  \/-\/      \/-\/        \           +---+
    | 2 |   |27,36)   |  ( D )------( E )         \          | 5 |
    +---+   |         |   \-/        \-/           \         +---+
      #     V         |   /  \         \            \           #
      #  +---+       /-\ /    \/-\     /-\          /-\   +---+ #
      ###| 3 |######( F )#####( G )###( H )########( H )##| 6 |##
         +---+   P   \-/  P    \-/  P  \-/     P    \-/   +---+

             +++ = working path       ### = protection path


                   Figure 11: Use Case P7 - Dual homing

   As per previous use cases it is possible to either provide the path
   between 1 and 4, collect the SRLGs, provide the path between 3 and 6



Ceccarelli, et al.      Expires January 12, 2014               [Page 18]


Internet-Draft           Overlay model use cases               July 2013


   with SRLG diversity constraints and than let the packet domain use
   those two packet layer adjacencies or have 2 asking 1 and 3 to
   respectively set up 1-4 and 3-6.

   Whenever one of the paths is restored in the optical domain (e.g.
   B-C fails and the path is restored using A-B-E-C), an SRLG collection
   procedure (by 1) and exchange (to F) is needed so that a possible
   restoration of the protection path would avoid the new SRLGs of
   working path.  Please see use case R4.


7.  Recovery

7.1.  Use case R1 - Segment Recovery - Single homing

   This is one of the simplest recovery scenarios, where each overlay
   node has a single UNI interface available on the overlay nodes and
   hence only the server layer is in charge of restoring or protecting
   the traffic within its domains boundaries.  As it is possible to see
   in figure below the client layer is able to recover from failures
   within the server domain.


   +--+   +--+   +--+     /-\       /-\     /-\      +--+   +--+   +--+
   |R1|---|R2|---|R3|****( A )--X--( B )---( C )*****|R5|---|R6|---|R7|
   +--+   +--+   +--+     \-/       \-/\    \-/      +--+   +--+   +--+
                           | \     / |  \    |
                           |  \   /  |   \   |
                           |   \ /   |    \  |
                           |    \    |     \ |
                           |   / \   |      \|
                          /-\ /    \/-\     /-\
                         ( D )-----( E )---( F )
                          \-/       \-/     \-/


         Figure 12: Use case R1 - Segment Recovery - Single homing

   This kind of scenario is extremely cheap in terms of resource
   utilization but has some limitations due to a high number of single
   points of failures which, in case of unavailability, prevent any type
   of recovery attempt.  The single points of failure are: the overlay
   nodes (R3 and R5), the UNI links (R3-A and C-R5) and the server
   domain border nodes (A and C).  In the following sections higher
   degrees of reliability are provided.






Ceccarelli, et al.      Expires January 12, 2014               [Page 19]


Internet-Draft           Overlay model use cases               July 2013


7.2.  Use case R2 - Local recovery - Dual Homing - Single overlay node

   In this use case it is possible to combine local recovery in the
   overlay nodes (e.g.  Fast Rerouting) with restoration or protection
   in the optical domain so to be able to react to failures not only in
   the client domain but also affecting the server layer border nodes (A
   and C) and the UNI links (R3-A and R5-C).  The number of single
   points of failure is hence significantly reduced to just the overlay
   nodes (R3 and R5).


   +--+   +--+   +--+     /-\       /-\     /-\      +--+   +--+   +--+
   |R1|---|R2|---|R3|****( A )--X--( B )---( C )**X**|R5|---|R6|---|R7|
   +--+   +--+   +--+     \-/       \-/\    \-/      +--+   +--+   +--+
                   *       | \     / |  \    |      *
                    *      |  \   /  |   \   |     *
                     *     |   \ /   |    \  |    *
                      *    |    \    |     \ |   *
                       *   |   / \   |      \|  *
                        * /-\ /    \/-\     /-\*
                         ( D )-----( E )---( F )
                          \-/       \-/     \-/


      Figure 13: Use case R2 - Local recovery - Dual Homing - Single
                               overlay node

7.3.  Use case R3 -End to end Recovery - Dual homing - Double overlay
      node

   This use case focuses on recovery just in the client layer, no
   recovery is requested to the server layer but just the provisioning
   of LSPs with requirements (in this case diversity).

   The provisioning of the working path occurs like the provisioning of
   LSP over the UNI with remote trigger and with the collection of SRLGs
   enabled.  Once that the optical LSP supporting the working client LSP
   is setup (A-B-C), the SRLGs in the optical domain are collected and
   passed to the overlay node (R3) which forwards them to the ingress
   node (R1) in the reverse path of the signaling process of the working
   LSP (i.e.  RSVP-TE Resv Message).

   Once that R1 is provided with the SRLGs in the optical domains, it is
   able to issue the signaling of the protection LSP indicating in a
   loose ERO R5 and R7 as loose hops and the SRLG diversity in the ERO
   expansions between them.  This will lead in the provisioning of a
   path in the photonic domain diverse from the previous one (S2-S4-S6)
   and hence two total diverse end to end paths.  In this case the



Ceccarelli, et al.      Expires January 12, 2014               [Page 20]


Internet-Draft           Overlay model use cases               July 2013


   network will be able to recover to a single failure in any part of
   the network without any single point of failure.


   +--+   +--+   +--+     /-\       /-\     /-\      +--+   +--+   +--+
   |R1|---|R2|---|R3|****( A )--X--( B )---( C )**X**|R6|---|R7|---|R8|
   +--+   +--+   +--+     \-/       \-/\    \-/      +--+   +--+   +--+
       \                   | \     / |  \    |                     /
        \                  |  \   /  |   \   |                    /
         \                 |   \ /   |    \  |                   /
          \                |    \    |     \ |                  /
           \               |   / \   |      \|                 /
          +--+   +--+     /-\ /    \/-\     /-\      +--+   +---+
          |R4|---|R5|****( D )-----( E )---( F )**X**|R9|---|R10|
          +--+   +--+     \-/       \-/     \-/      +--+   +---+


    Figure 14: Use case R3 -End to end Recovery - Dual homing - Double
                               overlay node

7.4.  Use case R4 - Combination of client protection and server
      restoration

   This is the most interesting use case when the overlay model is
   applied to the packet/opto scenario.  The packet protection and
   optical restoration allows for a fast recovery of the traffic upon a
   failure in the network, while the restoration in the optical domain
   allows for always providing the packet layer with two available path
   against an arbitrarily high number of failure in the optical network
   (the number of failures depend on the meshing degree of the photonic
   network).

   Moreover the exchange of SRLGs over the UNI interface (please see
   Provisioning use cases) makes sure that the optical path used for the
   working branch of the packet protection and the optical path used for
   the protection branch of the packet protection do not share any
   resource and hence that a single failure in the optical domain does
   not cause any traffic hit; i.e. traffic can be recovered with packet
   protection time (tens of ms) instead of photonics restoration time
   (tens of s).

   The SRLG collecgion procedure is pretty simple during the
   provisioning phase, but more complicated when one of the paths fail
   and is restored.

   In figure below an example is considered where a protection is
   provided in the client layer where the working path is setup along
   path (2-1-A-C-4-5) and its protection path along (2-3-F-H-G-6-5).



Ceccarelli, et al.      Expires January 12, 2014               [Page 21]


Internet-Draft           Overlay model use cases               July 2013


   After the setup of the optical path between A and C (A-B-C), the
   SRLGs of such path are collected and the overlay edge node 3 can ask
   F for the setup of a path between F and H avoiding such SRLGs.  This
   ensures that a single failure in the optical domain will not affect
   both the W and P.


         +---+       /-\       /-\          /-\          +---+
       ++| 1 |++++++( A )+++++( B )++++++++( C )+++++++++| 4 |++
       + +---+       \-/       \-/\       / \-/\         +---+ +
       +              | \     /    \     /      \              +
    +---+             |  \/-\/      \/-\/        \           +---+
    | 2 |             |  ( D )------( E )         \          | 5 |
    +---+             |   \-/        \-/           \         +---+
      #               |   /  \         \            \           #
      #  +---+       /-\ /    \/-\     /-\          /-\   +---+ #
      ###| 3 |######( F )#####( G )###( H )########( H )##| 6 |##
         +---+       \-/       \-/     \-/          \-/   +---+

             +++ = working path       ### = protection path


         Figure 15: Use Case R4 - Setup of paths in full diversity

   In order to guarantee that different SRLGs will always be used for W
   and P it is necessary to perform two different steps after the
   provisioning of the two LSPs:

      1.  Each ingress node of the server domain paths (namely A and F)
      must be informed that in case of restoration the path computation
      must avoid the *actual* SRLG of the other path

      2.  Every time that either of the server domain paths is restored,
      the collection of SRLGs must be performed and communicated to the
      ingress node of the other LSP.
















Ceccarelli, et al.      Expires January 12, 2014               [Page 22]


Internet-Draft           Overlay model use cases               July 2013


         +---+       /-\       /-\          /-\          +---+
       ++| 1 |++++++( A )+++++( B )--- X --( C )+++++++++| 4 |++
       + +---+       \-/       \-/+       + \-/\         +---+ +
       +              | \     /    +     +      \              +
    +---+             |  \/-\/      +/-\+        \           +---+
    | 2 |             |  ( D )------( E )         \          | 5 |
    +---+             |   \-/        \-/           \         +---+
      #               |   #  #         \            \           #
      #  +---+       /-\ #    #/-\     /-\          /-\   +---+ #
      ###| 3 |######( F )- X -( G )###( H )########( H )##| 6 |##
         +---+       \-/       \-/     \-/          \-/   +---+

             +++ = working path       ### = protection path


   Figure 16: Use Case R4 - Restoration of paths keeping full diversity

   In the example above a failure affecting W (link B-C) and a failure
   affecting P (link F-G) occur, but the server network is able to
   provide alternate paths for both of them and still provide the same
   level of fault resiliency to the client network.


8.  Optimization

8.1.  Use case O1 -

   TBD


9.  Security Considerations

   TBD


10.  IANA Considerations

   TBD


11.  Contributors

      Diego Caviglia

      Email: diego.caviglia@ericsson.com






Ceccarelli, et al.      Expires January 12, 2014               [Page 23]


Internet-Draft           Overlay model use cases               July 2013


      Francesco Fondelli

      Email: francesco.fondelli@ericsson.com


12.  Acknowledgements

   The authors would like to thank Manuela Scarella and Enrico Dutti for
   the comments and review.


13.  References to be added

  [EDITOR NOTE] : section to be fixed
  [LSP-DIV] - http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-01
  [TE-REC] - http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-01
  [OF-TEMB] - http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-02
  [SRLG-COLL] - http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-02
  [MELG] - http://tools.ietf.org/html/draft-beeram-ccamp-melg-00
  [UNI-APP] - http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-03
  [ENNI] - http://datatracker.ietf.org/doc/draft-beeram-ccamp-gmpls-enni/
  [ISIS-TEMET] - http://tools.ietf.org/html/draft-previdi-isis-te-metric-extensions-03
  [OSPF-TEMET] - http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-04
  [INTERCON-TE] - http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-00
  [UNI EXT] - http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-01


14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

14.2.  Informative References


Authors' Addresses

   Daniele Ceccarelli
   Ericsson
   Via E. Melen 77
   Genova - Erzelli
   Italy

   Email: daniele.ceccarelli@ericsson.com





Ceccarelli, et al.      Expires January 12, 2014               [Page 24]


Internet-Draft           Overlay model use cases               July 2013


   Oscar Gonzalez de Dios
   Telefonica I+D
   Don Ramon de la Cruz 82-84
   Madrid  28045
   Spain

   Email: ogondio@tid.es


   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28972912

   Email: zhangfatai@huawei.com


   Xian Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28972913

   Email: zhang.xian@huawei.com


























Ceccarelli, et al.      Expires January 12, 2014               [Page 25]