Network Working Group                                    A. Farrel (Ed.)
Internet-Draft                                                  J. Drake
Intended status: Standards Track                        Juniper Networks
Expires: September 7, 2015 April 15, 2016
                                                                N. Bitar
                                                        Verizon Networks

                                                              G. Swallow
                                                     Cisco Systems, Inc.

                                                           D. Ceccarelli
                                                                Ericsson

                                                                X. Zhang
                                                                  Huawei
                                                           March 7,
                                                        October 15, 2015

     Problem Statement and Architecture for Information Exchange
         Between Interconnected Traffic Engineered Networks

       draft-ietf-teas-interconnected-te-info-exchange-02.txt

       draft-ietf-teas-interconnected-te-info-exchange-03.txt

Abstract

   In Traffic Engineered (TE) systems, it is sometimes desirable to
   establish an end-to-end TE path with a set of constraints (such as
   bandwidth) across one or more network from a source to a destination.
   TE information is the data relating to nodes and TE links that is
   used in the process of selecting a TE path.  TE information is
   usually only available within a network.  We call such a zone of
   visibility of TE information a domain. An example of a domain may be
   an IGP area or an Autonomous System.

   In order to determine the potential to establish a TE path through a
   series of connected networks, it is necessary to have available a
   certain amount of TE information about each 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.

   This document sets out the problem statement and architecture for the
   exchange of TE information between interconnected TE networks in
   support of end-to-end TE path establishment.  For reasons that are
   explained in the document, this work is limited to simple TE
   constraints and information that determine TE reachability.

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."

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction .................................................  5
   1.1.  Terminology ................................................  6
   1.1.1.  TE Paths and TE Connections ..............................  6
   1.1.2.  TE Metrics and TE Attributes .............................  6
   1.1.3.  TE Reachability ..........................................  6
   1.1.4.  Domain ...................................................  7
   1.1.5.  Aggregation ..............................................  7
   1.1.6.  Abstraction ..............................................  7
   1.1.7.  Abstract Link ............................................  7
   1.1.8.  Abstraction Layer Network ................................  8
   2.  Overview of Use Cases ........................................  8
   2.1.  Peer Networks ..............................................  8
   2.1.1.  Where is the Destination? ................................  9
   2.2.  Client-Server Networks ..................................... 10
   2.3.  Dual-Homing ................................................ 12
   2.4.  Requesting Connectivity .................................... 13
   2.4.1.  Discovering Server Network Information ................... 15
   3.  Problem Statement ............................................ 15
   3.1.  Use of Existing Protocol Mechanisms ........................ 16
   3.2.  Policy and Filters ......................................... 16
   3.3. 15
   3.2.  Confidentiality ............................................ 17
   3.4. 15
   3.3.  Information Overload ....................................... 17
   3.5.
   3.4.  Issues of Information Churn ................................ 18
   3.6. 17
   3.5.  Issues of Aggregation ...................................... 19
   3.7.  Virtual Network Topology ................................... 20 18
   4.  Existing Work ................................................ 21  Architecture ................................................. 19
   4.1.  Per-Domain Path Computation ................................ 21
   4.2.  Crankback .................................................. 22
   4.3.  Path Computation Element ................................... 23
   4.4.  GMPLS UNI and Overlay Networks ............................. 24
   4.5.  Layer One VPN .............................................. 25
   4.6.  VNT Manager and Link Advertisement ......................... 25
   4.7.  What Else is Needed and Why? ............................... 26
   5.  Architectural Concepts ....................................... 27
   5.1.  Basic Components ........................................... 27
   5.1.1.  Peer Interconnection ..................................... 27
   5.1.2.  Client-Server Interconnection ............................ 28
   5.2.  TE Reachability ............................................ 29
   5.3. 19
   4.2.  Abstraction not Aggregation ................................ 29
   5.3.1. 20
   4.2.1.  Abstract Links ........................................... 30
   5.3.2. 21
   4.2.2.  The Abstraction Layer Network ............................ 30
   5.3.3. 21
   4.2.3.  Abstraction in Client-Server Networks..................... 33
   5.3.4. 24
   4.2.4.  Abstraction in Peer Networks ............................. 39
   5.4. 29
   4.3.  Considerations for Dynamic Abstraction ..................... 41
   5.5. 32
   4.4.  Requirements for Advertising Links and Nodes ............... 42
   5.6. 32
   4.5.  Addressing Considerations .................................. 42
   6. 33
   5.  Building on Existing Protocols ............................... 43
   6.1. 33
   5.1.  BGP-LS ..................................................... 43
   6.2. 34
   5.2.  IGPs ....................................................... 43
   6.3. 34
   5.3.  RSVP-TE .................................................... 43
   6.4. 34
   5.4.  Notes on a Solution ........................................ 44
   7. 35
   6. Applicability to Optical Domains and Networks ................. 46
   8. 36
   7.  Modeling the User-to-Network Interface ....................... 50
   9. 40
   8.  Abstraction in L3VPN Multi-AS Environments ................... 51
   10. 42
   9.  Scoping Future Work ......................................... 53
   10.1. .......................................... 43
   9.1.  Not Solving the Internet .................................. 53
   10.2. ................................... 43
   9.2.  Working With "Related" Domains ............................ 53
   10.3. ............................. 43
   9.3.  Not Finding Optimal Paths in All Situations ............... 53
   10.4.  Not Breaking Existing Protocols ........................... 53
   10.5. ................ 44
   9.4.  Sanity and Scaling ........................................ 53
   11. ......................................... 44
   10.  Manageability Considerations ................................ 54
   11.1. 44
   10.1.  Managing the Abstraction Layer Network .................... 54
   11.2. 44
   10.2.  Managing Interactions of Client and Abstraction Layer Networks
                                                                      55
   11.3.
                                                                      45
   10.3.  Managing Interactions of Abstraction Layer and Server Networks
                                                                      56
   12.
                                                                      46
   11.  IANA Considerations ......................................... 56
   13. 47
   12.  Security Considerations ..................................... 57
   14. 47
   13.  Acknowledgements ............................................ 57
   15. 47
   14.  References .................................................. 58
   15.1. 48
   14.1.  Informative References .................................... 58 48
   Authors' Addresses ............................................... 62 52
   Contributors ..................................................... 63 52
   A.  Existing Work ................................................ 54
   A.1.  Per-Domain Path Computation ................................ 54
   A.2.  Crankback .................................................. 54
   A.3.  Path Computation Element ................................... 55
   A.4.  GMPLS UNI and Overlay Networks ............................. 57
   A.5.  Layer One VPN .............................................. 57
   A.6.  Policy and Link Advertisement .............................. 58
   B.  Additional Features .......................................... 59
   B.1.  Macro Shared Risk Link Groups .............................. 59
   B.2.  Mutual Exclusivity ......................................... 60

1.  Introduction

   Traffic Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS
   [RFC3945] offer a way to establish paths through a network in a
   controlled way that reserves network resources on specified links.
   TE paths are computed by examining the Traffic Engineering Database
   (TED) and selecting a sequence of links and nodes that are capable of
   meeting the requirements of the path to be established.  The TED is
   constructed from information distributed by the IGP running in the
   network, for example OSPF-TE [RFC3630] or ISIS-TE [RFC5305].

   It is sometimes desirable to establish an end-to-end TE path that
   crosses more than one network or administrative domain as described
   in [RFC4105] and [RFC4216].  In these cases, the availability of TE
   information is usually limited to within each network.  Such networks
   are often referred to as Domains [RFC4726] and we adopt that
   definition in this document: viz.

     For the purposes of this document, a domain is considered to be any
     collection of network elements within a common sphere of address
     management or path computational responsibility.  Examples of such
     domains include IGP areas and Autonomous Systems.

   In order to determine the potential to establish a TE path through a
   series of connected domains and to choose the appropriate domain
   connection points through which to route a path, it is necessary to
   have available a certain amount of TE information about each domain.
   This need not be the full set of TE information available within each
   domain, but does need to express the potential of providing TE
   connectivity.  This subset of TE information is called TE
   reachability information.  The TE reachability information can be
   exchanged between domains based on the information gathered from the
   local routing protocol, filtered by configured policy, or statically
   configured.

   This document sets out the problem statement and architecture for the
   exchange of TE information between interconnected TE domains in
   support of end-to-end TE path establishment.  The scope of this
   document is limited to the simple TE constraints and information
   (such as TE metrics, hop count, bandwidth, delay, shared risk)
   necessary to determine TE reachability: discussion of multiple
   additional constraints that might qualify the reachability can
   significantly complicate aggregation of information and the stability
   of the mechanism used to present potential connectivity as is
   explained in the body of this document.

   An Appendix to this document summarizes existing relevant existing
   work that is used to route TE paths across multiple domains.

1.1.  Terminology

   This section introduces some key terms that need to be understood to
   arrive at a common understanding of the problem space.  Some of the
   terms are defined in more detail in the sections that follow (in
   which case forward pointers are provided) and some terms are taken
   from definitions that already exist in other RFCs (in which case
   references are given, but no apology is made for repeating or
   summarizing the definitions here).

1.1.1.  TE Paths and TE Connections

   A TE connection is a Label Switched Path (LSP) through an MPLS-TE or
   GMPLS network that directs traffic along a particular path (the TE
   path) in order to provide a specific service such as bandwidth
   guarantee, separation of traffic, or resilience between a well-known
   pair of end points.

1.1.2.  TE Metrics and TE Attributes

   TE metrics and TE attributes are terms applied to parameters of links
   (and possibly nodes) in a network that is traversed by TE
   connections.  The TE metrics and TE attributes are used by path
   computation algorithms to select the TE paths that the TE connections
   traverse.  Provisioning a TE connection through a network may result
   in dynamic changes to the TE metrics and TE attributes of the links
   and nodes in the network.

   These terms are also sometimes used to describe the end-to-end
   characteristics of a TE connection and can be derived according to a
   formula from the metrics and attributes of the links and nodes that
   the TE connection traverses.  Thus, for example, the end-to-end delay
   for a TE connection is usually considered to be the sum of the delay
   on each link that the connection traverses.

1.1.3.  TE Reachability

   In an IP network, reachability is the ability to deliver a packet to
   a specific address or prefix.  That is, the existence of an IP path
   to that address or prefix.  TE reachability is the ability to reach a
   specific address along a TE path.  More specifically, it is the
   ability to establish a TE connection in an MPLS-TE or GMPLS sense.
   Thus we talk about TE reachability as the potential of providing TE
   connectivity.

   TE reachability may be unqualified (there is a TE path, but no
   information about available resources or other constraints is
   supplied) which is helpful especially in determining a path to a
   destination that lies in an unknown domain, or may be qualified by TE
   attributes and TE metrics such as hop count, available bandwidth,
   delay, shared risk, etc.

1.1.4.  Domain

   As defined in [RFC4726], a domain is any collection of network
   elements within a common sphere of address management or path
   computational responsibility.  Examples of such domains include
   Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).

1.1.5.  Aggregation

   The concept of aggregation is discussed in Section 3.6. 3.5.  In
   aggregation, multiple network resources from a domain are represented
   outside the domain as a single entity.  Thus multiple links and nodes
   forming a TE connection may be represented as a single link, or a
   collection of nodes and links (perhaps the whole domain) may be
   represented as a single node with its attachment links.

1.1.6.  Abstraction

   Section 5.3 4.2 introduces the concept of abstraction and distinguishes
   it from aggregation.  Abstraction may be viewed as "policy-based
   aggregation" where the policies are applied to overcome the issues
   with aggregation as identified in section Section 3 of this document.

   Abstraction is the process of applying policy to the available TE
   information within a domain, to produce selective information that
   represents the potential ability to connect across the domain.  Thus,
   abstraction does not necessarily offer all possible connectivity
   options, but presents a general view of potential connectivity
   according to the policies that determine how the domain's
   administrator wants to allow the domain resources to be used.

1.1.7.  Abstract Link

   An abstract link is the representation of the characteristics of a
   path between two nodes in a domain produced by abstraction.  The
   abstract link is advertised outside that domain as a TE link for use
   in signaling in other domains.  Thus, an abstract link represents
   the potential to connect between a pair of nodes.

   More details of abstract links are provided in Section 5.3.1. 4.2.1.

1.1.8.  Abstraction Layer Network

   The abstraction layer network is introduced in Section 5.3.2. 4.2.2.  It may
   be seen as a brokerage layer network between one or more server
   networks and one or more client network.  The abstraction layer
   network is the collection of abstract links that provide potential
   connectivity across the server network(s) and on which path
   computation can be performed to determine edge-to-edge paths that
   provide connectivity as links in the client network.

   In the simplest case, the abstraction layer network is just a set of
   edge-to-edge connections (i.e., abstract links), but to make the use
   of server resources more flexible, the abstract links might not all
   extend from edge to edge, but might offer connectivity between server
   nodes to form a more complex network.

2.  Overview of Use Cases

2.1.  Peer Networks

   The peer network use case can be most simply illustrated by the
   example in Figure 1.  A TE path is required between the source (Src)
   and destination (Dst), that are located in different domains.  There
   are two points of interconnection between the domains, and selecting
   the wrong point of interconnection can lead to a sub-optimal path, or
   even fail to make a path available.

   For example, when Domain A attempts  Note that peer networks are
   assumed to select have the same technology type: that is, the same
   "switching capability" to use the term from GMPLS [RFC3945].

   For example, when Domain A attempts to select a path, it may
   determine that adequate bandwidth is available from Src through both
   interconnection points x1 and x2.  It may pick the path through x1
   for local policy reasons: perhaps the TE metric is smaller.  However,
   if there is no connectivity in Domain Z from x1 to Dst, the path
   cannot be established.  Techniques such as crankback (see Section
   4.2)
   4.1) may be used to alleviate this situation, but do not lead to
   rapid setup or guaranteed optimality.  Furthermore RSVP signalling
   creates state in the network that is immediately removed by the
   crankback procedure. Frequent events of such a kind impact
   scalability in a non-deterministic manner.

     --------------      --------------
    | Domain A     | x1 |     Domain Z |
    |   -----      +----+       -----  |
    |  | Src |     +----+      | Dst | |
    |   -----      | x2 |       -----  |
     --------------      --------------

        Figure 1 : Peer Networks

   There are countless more complicated examples of the problem of peer
   networks.  Figure 2 shows the case where there is a simple mesh of
   domains.  Clearly, to find a TE path from Src to Dst, Domain A must
   not select a path leaving through interconnect x1 since Domain B has
   no connectivity to Domain Z.  Furthermore, in deciding whether to
   select interconnection x2 (through Domain C) or interconnection x3
   though Domain D, Domain A must be sensitive to the TE connectivity
   available through each of Domains C and D, as well the TE
   connectivity from each of interconnections x4 and x5 to Dst within
   Domain Z.  The problem may be further complicated when the source
   domain does not know in which domain the destination node is located,
   since the choice of a domain path clearly depends on the knowledge of
   the destination domain: this issue is obviously mitigated in IP
   networks by inter-domain routing [RFC4271].

                       --------------
                      |     Domain B |
                      |              |
                      |              |
                      /--------------
                     /
                    /
                   /x1
    --------------/                       --------------
   | Domain A     |                      |     Domain Z |
   |              |    --------------    |              |
   |  -----       | x2|     Domain C | x4|       -----  |
   | | Src |      +---+              +---+      | Dst | |
   |  -----       |   |              |   |       -----  |
   |              |    --------------    |              |
    --------------\                      /--------------
                   \x3                  /
                    \                  /
                     \                /x5
                      \--------------/
                      |     Domain D |
                      |              |
                      |              |
                       --------------

        Figure 2 : Peer Networks in a Mesh

   Of course, many network interconnection scenarios are going to be a
   combination of the situations expressed in these two examples.  There
   may be a mesh of domains, and the domains may have multiple points of
   interconnection.

2.1.1.  Where is the Destination?

   A variation of the problems expressed in Section 2.1 arises when the
   source domain (Domain A in both figures) does not know where the
   destination is located.  That is, when the domain in which the
   destination node is located is not known to the source domain.

   This is most easily seen in consideration of Figure 2 where the
   decision about which interconnection to select needs to be based on
   building a path toward the destination domain.  Yet this can only be
   achieved if it is known in which domain the destination node lies, or
   at least if there is some indication in which direction the
   destination lies.  This function is obviously provided in IP networks
   by inter-domain routing [RFC4271].

2.2.  Client-Server Networks

   Two major classes of use case relate to the client-server
   relationship between networks.  These use cases have sometimes been
   referred to as overlay networks.  In both cases, the client and
   server network may have the same switching capability, or may be
   built from nodes and links that have different technology types in
   the client and server networks.

   The first group of use case, cases, shown in Figure 3, occurs when domains
   belonging to one network are connected by a domain belonging to
   another network.  In this scenario, once connections (or tunnels) are connectivity is formed
   across the lower layer network, the domains of the upper layer
   network can be merged into a single domain by running IGP adjacencies
   over the tunnels,
   and by treating the tunnels server layer connectivity as links in the higher
   layer network.  The TE relationship between the domains (higher and
   lower layer) in this case is reduced to determining which tunnels what server layer
   connectivity to
   set up, establish, how to trigger them, it, how to route them, it in the
   server layer, and what resources and capacity to assign them. within the
   server layer.  As the demands in the higher layer network vary, these
   tunnels may need to be modified. the
   connectivity in the server layer may need to be modified.  Section
   2.4 explains in a little more detail how connectivity may be requested
   requested.

    --------------                         --------------
   | Domain A     |                       |     Domain Z |
   |              |                       |              |
   |  -----       |                       |       -----  |
   | | Src |      |                       |      | Dst | |
   |  -----       |                       |       -----  |
   |              |                       |              |
    --------------\                       /--------------
                   \x1                 x2/
                    \                   /
                     \                 /
                      \---------------/
                      | Server Domain |
                      |               |
                      |               |
                       ---------------

             Figure 3 : Client-Server Networks

   The second class of use case of client-server networking is for
   Virtual Private Networks (VPNs).  In this case, as opposed to the
   former one, it is assumed that the client network has a different
   address space than that of the server layer where non-overlapping IP
   addresses between the client and the server networks cannot be
   guaranteed.  A simple example is shown in Figure 4.  The VPN sites
   comprise a set of domains that are interconnected over a core domain,
   the provider network.

    --------------                         --------------
   | Domain A     |                       |     Domain Z |
   | (VPN site)   |                       |   (VPN site) |
   |              |                       |              |
   |  -----       |                       |       -----  |
   | | Src |      |                       |      | Dst | |
   |  -----       |                       |       -----  |
   |              |                       |              |
    --------------\                       /--------------
                   \x1                 x2/
                    \                   /
                     \                 /
                      \---------------/
                      |  Core Domain  |
                      |               |
                      |               |
                      /---------------\
                     /                 \
                    /                   \
                   /x3                 x4\
    --------------/                       \--------------
   | Domain B     |                       |     Domain C |
   | (VPN site)   |                       |   (VPN site) |
   |              |                       |              |
   |              |                       |              |
    --------------                         --------------

        Figure 4 : A Virtual Private Network

   Note that in the use cases shown in Figures 3 and 4 the client layer
   domains may (and, in fact, probably do) operate as a single connected
   network.

   Both use cases in this section become "more interesting" when
   combined with the use case in Section 2.1.  That is, when the
   connectivity between higher layer domains or VPN sites is provided
   by a sequence or mesh of lower layer domains.  Figure 5 shows how
   this might look in the case of a VPN.

    ------------                                   ------------
   | Domain A   |                                 |   Domain Z |
   | (VPN site) |                                 | (VPN site) |
   |  -----     |                                 |     -----  |
   | | Src |    |                                 |    | Dst | |
   |  -----     |                                 |     -----  |
   |            |                                 |            |
    ------------\                                 /------------
                 \x1                           x2/
                  \                             /
                   \                           /
                    \----------     ----------/
                    | Domain X |x5 | Domain Y |
                    | (core)   +---+ (core)   |
                    |          |   |          |
                    |          +---+          |
                    |          |x6 |          |
                    /----------     ----------\
                   /                           \
                  /                             \
                 /x3                           x4\
    ------------/                                 \------------
   | Domain B   |                                 |   Domain C |
   | (VPN site) |                                 | (VPN site) |
   |            |                                 |            |
    ------------                                   ------------

        Figure 5 : A VPN Supported Over Multiple Server Domains

2.3.  Dual-Homing

   A further complication may be added to the client-server relationship
   described in Section 2.2 by considering what happens when a client
   domain is attached to more than one server domain, or has two points
   of attachment to a server domain.  Figure 6 shows an example of this
   for a VPN.

                            ------------
                           | Domain A   |
                           | (VPN site) |
    ------------           |  -----     |
   | Domain B   |          | | Src |    |
   | (VPN site) |          |  -----     |
   |            |          |            |
    ------------\           -+--------+-
                 \x1         |        |
                  \        x2|        |x3
                   \         |        |              ------------
                    \--------+-      -+--------     |   Domain Z |
                    | Domain X | x8 | Domain Y | x4 | (VPN site) |
                    | (core)   +----+ (core)   +----+     -----  |
                    |          |    |          |    |    | Dst | |
                    |          +----+          +----+     -----  |
                    |          | x9 |          | x5 |            |
                    /----------      ----------\     ------------
                   /                            \
                  /                              \
                 /x6                            x7\
    ------------/                                  \------------
   | Domain C   |                                  |   Domain D |
   | (VPN site) |                                  | (VPN site) |
   |            |                                  |            |
    ------------                                    ------------

        Figure 6 : Dual-Homing in a Virtual Private Network

2.4.  Requesting Connectivity

   This relationship between domains can be entirely under the control
   of management processes, dynamically triggered by the client network,
   or some hybrid of these cases.  In the management case, the server
   network may be requested to establish a set of LSPs to provide client
   layer connectivity.  In the dynamic case, the client may make a
   request to the server network exerting a range of controls over the
   paths selected in the server network.  This range extends from no
   control (i.e., a simple request for connectivity), through a set of
   constraints (such as latency, path protection, etc.), up to and
   including full control of the path and resources used in the server
   network (i.e., the use of explicit paths with label subobjects).

   There are various models by which a server network can be requested
   to set up the connections that support a service provided to the
   client network.  These requests may come from management systems,
   directly from the client network control plane, or through some an
   intermediary broker such as the Virtual Network Topology Manager
   discussed in Section 4.6.
   (VNTM) [RFC5623].

   The trigger that causes the request to the server layer is also
   flexible.  It could be that the client layer discovers a pressing
   need for server layer resources (such as the desire to provision an
   end-to-end connection in the client layer, or severe congestion on
   a specific path), or it might be that a planning application has
   considered how best to optimize traffic in the client network or
   how to handle a predicted traffic demand.

   In all cases, the relationship between client and server networks is
   subject to policy so that server resources are under the
   administrative control of the operator or the server layer network
   and are only used to support a client layer network in ways that the
   server layer operator approves.

   As just noted, connectivity requests issued to a server network may
   include varying degrees of constraint upon the choice of path that
   the server network can implement.

   o Basic Provisioning is a simple request for connectivity.  The only
     constraints are the end points of the connection and the capacity
     (bandwidth) that the connection will support for the client layer.
     In the case of some server networks, even the bandwidth component
     of a basic provisioning request is superfluous because the server
     layer has no facility to vary bandwidth, but can offer connectivity
     only at a default capacity.

   o Basic Provisioning with Optimization is a service request that
     indicates one or more metrics that the server layer must optimize
     in its selection of a path.  Metrics may be hop count, path length,
     summed TE metric, jitter, delay, or any number of technology-
     specific constraints.

   o Basic Provisioning with Optimization and Constraints enhances the
     optimization process to apply absolute constraints to functions of
     the path metrics.  For example, a connection may be requested that
     optimizes for the shortest path, but in any case requests that the
     end-to-end delay be less than a certain value.  Equally,
     optimization my be expressed in terms of the impact on the network.
     For example, a service may be requested in order to leave maximal
     flexibility to satisfy future service requests.

   o Fate Diversity requests ask for the server layer to provide a path
     that does not use any network resources (usually links and nodes)
     that share fate (i.e., can fail as the result of a single event) as
     the resources used by another connection.  This allows the client
     layer to construct protection services over the server layer
     network, for example by establishing virtual links that are known to be
     fate diverse.  The connections that have diverse paths need not
     share end points.

   o Provisioning with Fate Sharing is the exact opposite of Fate
     Diversity.  In this case two or more connections are requested to
     to follow same path in the server network.  This may be requested,
     for example, to create a bundled or aggregated link in the client
     layer where each component of the client layer composite link is
     required to have the same server layer properties (metrics, delay,
     etc.) and the same failure characteristics.

   o Concurrent Provisioning enables the inter-related connections
     requests described in the previous two bullets to be enacted
     through a single, compound service request.

   o Service Resilience requests the server layer to provide
     connectivity for which the server layer takes responsibility to
     recover from faults.  The resilience may be achieved through the
     use of link-level protection, segment protection, end-to-end
     protection, or recovery mechanisms.

2.4.1.  Discovering Server Network Information

   Although the topology and resource availability information of a
   server network may be hidden from the client network, the service
   request interface may support features that report details about the
   services and potential services that the server network supports.

   o Reporting of path details, service parameters, and issues such as
     path diversity of LSPs that support deployed services allows the
     client network to understand to what extent its requests were
     satisfied.  This is particularly important when the requests were
     made as "best effort".

   o A server network may support requests of the form "if I was to ask
     you for this service, would you be able to provide it?"  That is,
     a service request that does everything except actually provision
     the service.

3.  Problem Statement

   The problem statement presented in this section is as much about the
   issues that may arise in any solution (and so have to be avoided)
   and the features that are desirable within a solution, as it is about
   the actual problem to be solved.

   The problem can be stated very simply and with reference to the use
   cases presented in the previous section.

     A mechanism is required that allows TE-path computation in one
     domain to make informed choices about the TE-capabilities and exit
     points from the domain when signaling an end-to-end TE path that
     will extend across multiple domains.

   Thus, the problem is one of information collection and presentation,
   not about signaling.  Indeed, the existing signaling mechanisms for
   TE LSP establishment are likely to prove adequate [RFC4726] with the
   possibility of minor extensions.

   An interesting annex to the problem is how the path is made available
   for use.  For example, in the case of a client-server network, the
   path established in the server network needs to be made available as
   a TE link to provide connectivity in the client network.

3.1.  Use of Existing Protocol Mechanisms  Similarly, TE information may
   currently be distributed in a domain by TE extensions to one of the
   two IGPs as described in OSPF-TE [RFC3630] and ISIS-TE [RFC5305]. [RFC5305],
   and TE information may be exported from a domain (for example,
   northbound) using link state extensions to BGP
   [I-D.ietf-idr-ls-distribution].

   It is desirable that a solution [I-D.ietf-idr-ls-
   distribution].

   An interesting annex to the problem described is how the path is made available
   for use.  For example, in this
   document does not require the implementation case of a new, network-wide
   protocol.  Instead, it would be advantageous to make use of an
   existing protocol that is commonly implemented on network nodes and
   is currently deployed, or to use existing computational elements such
   as Path Computation Elements (PCEs).  This has many benefits client-server network, the
   path established in the server network stability, time to deployment, and operator training.

   It is recognized, however, that existing protocols are unlikely to be
   immediately suitable needs to this problem space without some protocol
   extensions.  Extending protocols must be done with care and with
   consideration for the stability of existing deployments. In extreme
   cases, made available as
   a new protocol can be preferable TE link to a messy hack of an
   existing protocol.

3.2. provide connectivity in the client network.

3.1.  Policy and Filters

   A solution must be amenable to the application of policy and filters.
   That is, the operator of a domain that is sharing information with
   another domain must be able to apply controls to what information is
   shared.  Furthermore, the operator of a domain that has information
   shared with it must be able to apply policies and filters to the
   received information.

   Additionally, the path computation within a domain must be able to
   weight the information received from other domains according to local
   policy such that the resultant computed path meets the local
   operator's needs and policies rather than those of the operators of
   other domains.

3.3.

3.2.  Confidentiality

   A feature of the policy described in Section 3.3 3.1 is that an operator
   of a domain may desire to keep confidential the details about its
   internal network topology and loading.  This information could be
   construed as commercially sensitive.

   Although it is possible that TE information exchange will take place
   only between parties that have significant trust, there are also use
   cases (such as the VPN supported over multiple server domains
   described in Section 2.4) where information will be shared between
   domains that have a commercial relationship, but a low level of
   trust.

   Thus, it must be possible for a domain to limit the information share
   to just that which the computing domain needs to know with the
   understanding that less information that is made available the more
   likely it is that the result will be a less optimal path and/or more
   crankback events.

3.4.

3.3.  Information Overload

   One reason that networks are partitioned into separate domains is to
   reduce the set of information that any one router has to handle.
   This also applies to the volume of information that routing protocols
   have to distribute.

   Over the years routers have become more sophisticated with greater
   processing capabilities and more storage, the control channels on
   which routing messages are exchanged have become higher capacity, and
   the routing protocols (and their implementations) have become more
   robust.  Thus, some of the arguments in favor of dividing a network
   into domains may have been reduced.  Conversely, however, the size of
   networks continues to grow dramatically with a consequent increase in
   the total amount of routing-related information available.
   Additionally, in this case, the problem space spans two or more
   networks.

   Any solution to the problems voiced in this document must be aware of
   the issues of information overload.  If the solution was to simply
   share all TE information between all domains in the network, the
   effect from the point of view of the information load would be to
   create one single flat network domain.  Thus the solution must
   deliver enough information to make the computation practical (i.e.,
   to solve the problem), but not so much as to overload the receiving
   domain.  Furthermore, the solution cannot simply rely on the policies
   and filters described in Section 3.2 3.1 because such filters might not
   always be enabled.

3.5.

3.4.  Issues of Information Churn

   As LSPs are set up and torn down, the available TE resources on links
   in the network change.  In order to reliably compute a TE path
   through a network, the computation point must have an up-to-date view
   of the available TE resources.  However, collecting this information
   may result in considerable load on the distribution protocol and
   churn in the stored information.  In order to deal with this problem
   even in a single domain, updates are sent at periodic intervals or
   whenever there is a significant change in resources, whichever
   happens first.

   Consider, for example, that a TE LSP may traverse ten links in a
   network.  When the LSP is set up or torn down, the resources
   available on each link will change resulting in a new advertisement
   of the link's capabilities and capacity.  If the arrival rate of new
   LSPs is relatively fast, and the hold times relatively short, the
   network may be in a constant state of flux.  Note that the
   problem here is not limited to churn within a single domain, since
   the information shared between domains will also be changing.
   Furthermore, the information that one domain needs to share with
   another may change as the result of LSPs that are contained within or
   cross the first domain but which are of no direct relevance to the
   domain receiving the TE information.

   In packet networks, where the capacity of an LSP is often a small
   fraction of the resources available on any link, this issue is
   partially addressed by the advertising routers.  They can apply a
   threshold so that they do not bother to update the advertisement of
   available resources on a link if the change is less than a configured
   percentage of the total (or alternatively, the remaining) resources.
   The updated information in that case will be disseminated based on an
   update interval rather than a resource change event.

   In non-packet networks, where link resources are physical switching
   resources (such as timeslots or wavelengths) the capacity of an LSP
   may more frequently be a significant percentage of the available link
   resources.  Furthermore, in some switching environments, it is
   necessary to achieve end-to-end resource continuity (such as using
   the same wavelength on the whole length of an LSP), so it is far more
   desirable to keep the TE information held at the computation points
   up-to-date.  Fortunately, non-packet networks tend to be quite a bit
   smaller than packet networks, the arrival rates of non-packet LSPs
   are much lower, and the hold times considerably longer.  Thus the
   information churn may be sustainable.

3.6.

3.5.  Issues of Aggregation

   One possible solution to the issues raised in other sub-sections of
   this section is to aggregate the TE information shared between
   domains.  Two aggregation mechanisms are often considered:

   - Virtual node model.  In this view, the domain is aggregated as if
     it was a single node (or router / switch).  Its links to other
     domains are presented as real TE links, but the model assumes that
     any LSP entering the virtual node through a link can be routed to
     leave the virtual node through any other link (although recent work
     on "limited cross-connect switches" may help with this problem
     [I-D.ietf-ccamp-general-constraint-encode]).
     [RFC7579]).

   - Virtual link model.  In this model, the domain is reduced to a set
     of edge-to-edge TE links.  Thus, when computing a path for an LSP
     that crosses the domain, a computation point can see which domain
     entry points can be connected to which other and with what TE
     attributes.

   It is of the nature of aggregation that information is removed from
   the system.  This can cause inaccuracies and failed path computation.
   For example, in the virtual node model there might not actually be a
   TE path available between a pair of domain entry points, but the
   model lacks the sophistication to represent this "limited cross-
   connect capability" within the virtual node.  On the other hand, in
   the virtual link model it may prove very hard to aggregate multiple
   link characteristics: for example, there may be one path available
   with high bandwidth, and another with low delay, but this does not
   mean that the connectivity should be assumed or advertised as having
   both high bandwidth and low delay.

   The trick to this multidimensional problem, therefore, is to
   aggregate in a way that retains as much useful information as
   possible while removing the data that is not needed.  An important
   part of this trick is a clear understanding of what information is
   actually needed.

   It should also be noted in the context of Section 3.5 3.4 that changes in
   the information within a domain may have a bearing on what aggregated
   data is shared with another domain.  Thus, while the data shared in
   reduced, the aggregation algorithm (operating on the routers
   responsible for sharing information) may be heavily exercised.

3.7.  Virtual Network Topology

   The terms "virtual topology" and "virtual network topology" have
   become overloaded

4.  Architecture

4.1.  TE Reachability

   As described in Section 1.1, TE reachability is the ability to reach
   a relatively short time.  We draw on [RFC5212]
   and [RFC5623] for inspiration to provide a definition for use in this
   document.  Our definition is based on the fact that specific address along a topology at the
   and [RFC5623] for inspiration TE path.  The knowledge of TE reachability
   enables an end-to-end TE path to provide be computed.

   In a definition for use in this
   document.  Our definition single network, TE reachability is based on derived from the fact Traffic
   Engineering Database (TED) that a topology at the
   client network layer is constructed of nodes and links.  Typically, the nodes are routers collection of all TE
   information about all TE links in the client layer, and network.  The TED is usually
   built from the links are data
   links.  However, a layered network provides connectivity through exchanged by the
   lower layer as LSPs, and these LSPs IGP, although it can provide links in the client
   layer.  Furthermore, those LSPs may have been established in advance,
   or might be LSPs that could
   supplemented by configuration and inventory details especially in
   transport networks.

   In multi-network scenarios, TE reachability information can be set up if required.  This leads
   described as "You can get from node X to node Y with the
   definition:

     A Virtual Network Topology (VNT) is made up following
   TE attributes."  For transit cases, nodes X and Y will be edge nodes
   of links in the transit network, but it is also important to consider the
   information about the TE connectivity between an edge node and a network
     layer.  Those links
   specific destination node.  TE reachability may be realized as direct data links or qualified by TE
   attributes such as
     multi-hop connections (LSPs) in a lower network layer.  Those
     underlying LSPs may TE metrics, hop count, available bandwidth, delay,
   shared risk, etc.

   TE reachability information can be established exchanged between networks so that
   nodes in advance one network can determine whether they can establish TE
   paths across or created on demand.

   The creation and management of into another network.  Such exchanges are subject to
   a VNT requires interaction with
   management range of policies imposed by the advertiser (for security and policy.  Activity
   administrative control) and by the receiver (for scalability and
   stability).

4.2.  Abstraction not Aggregation

   Aggregation is needed in both the client process of synthesizing from available
   information.  Thus, the virtual node and
   server layer:

   - In virtual link models
   described in Section 3.5 rely on processing the server layer, LSPs need information available
   within a network to be set up either in advance in
     response produce the aggregate representations of links
   and nodes that are presented to management instructions or the consumer.  As described in answer to
   Section 3, dynamic
     requests aggregation is subject to policy considerations.

   - a number of pitfalls.

   In order to distinguish the server layer, evaluation architecture described in this document
   from the previous work on aggregation, we use the term "abstraction"
   in this document.  The process of abstraction is one of applying
   policy to the available TE resources can lead information within a domain, to the announcement of potential connectivity (i.e., LSPs produce
   selective information that
     could be set up on demand).

   - In represents the client layer, connectivity (lower layer LSPs or potential
     LSPs) needs ability to be announced in
   connect across the IGP as domain.

   Abstraction does not offer all possible connectivity options (refer
   to Section 3.5), but does present a normal TE link.  Such
     links may or general view of potential
   connectivity.  Abstraction may have a dynamic element, but is not be made available to IP routing: but, they are
     never made available
   intended to IP routing until fully instantiated.

   - In keep pace with the client layer, requests to establish lower layer LSPs need to
     be made either changes in TE attribute availability
   within the network.

   Thus, when links supported by potential LSPs are about relying on an abstraction to
     be used (i.e., when compute an end-to-end path,
   the process might not deliver a higher layer LSP usable path.  That is, there is signalled to cross the
     link, the setup of no
   actual guarantee that the lower layer LSP is triggered), abstractions are current or when the
     client layer determines feasible.

   While abstraction uses available TE information, it needs more connectivity or capacity.

   It is a fundamental of subject to
   policy and management choices.  Thus, not all potential connectivity
   will be advertised to each client.  The filters may depend on
   commercial relationships, the risk of disclosing confidential
   information, and concerns about what use is made of a VNT the connectivity
   that there is offered.

4.2.1.  Abstract Links

   An abstract link is a policy point
   at the lower-layer node responsible for the instantiation measure of a lower-
   layer LSP.  At the moment that the setup of potential to connect a lower-layer LSP pair of
   points with certain TE parameters.   That is, it is
   triggered, whether from a client-layer management tool or from
   signaling path and its
   characteristics in the client layer, the server layer must network.  An abstract link represents
   the possibility of setting up an LSP, and LSPs may be able to apply
   policy to determine whether to actually set up over the LSP.  Thus, fears
   that
   abstract link.

   When looking at a micro-flow network such as that in Figure 7, the client layer might cause link from CN1
   to CN4 may be an abstract link.  It is easy to advertise it as a link
   by abstracting the activation of
   100G optical resources TE information in the server layer can be completely
   controlled by the policy of the server layer network's operator (and
   could even be network subject to commercial terms).

   These activities require an architecture and protocol elements as
   well as management components and policy elements.

4.  Existing Work

   This section briefly summarizes relevant existing work that is used
   to route TE paths across multiple domains.

4.1.  Per-Domain Path Computation
   policy.

   The per-domain mechanism of path establishment is described in
   [RFC5152] and its applicability is discussed in [RFC4726].  In
   summary, this mechanism assumes that each domain entry point is
   responsible for computing (i.e., the path across abstract link) represents the domain, but that
   details possibility of the path in the next domain are left
   establishing an LSP from client edge to client edge across the next domain
   entry point.  The computation may be performed directly by the entry
   point or may be delegated to server
   network.  There is not necessarily a computation server.

   This basic mode of operation can run into many of the issues
   described alongside the use cases in Section 2.  However, in practice
   it can one-to-one relationship between
   abstract link and LSP because more than one LSP could be used effectively with a little operational guidance.

   For example, RSVP-TE [RFC3209] includes the concept of a "loose hop"
   in set up over
   the explicit path that is signaled.  This allows path.

   Since the original
   request for an LSP to list client nodes do not have visibility into the domains or even domain entry points to
   include core network,
   they must rely on abstraction information delivered to them by the path.  Thus, in
   core network.  That is, the example in Figure 1, core network will report on the source
   can be told to use potential
   for connectivity.

4.2.2.  The Abstraction Layer Network

   Figure 7 introduces the interconnection x2.  Then abstraction layer network.  This construct
   separates the source computes client layer resources (nodes C1, C2, C3, and C4, and
   the path from itself to x2, corresponding links), and initiates the signaling.  When server layer resources (nodes CN1,
   CN2, CN3, and CN4 and the
   signaling message reaches Domain Z, corresponding links).  Additionally, the entry point to
   architecture introduces an intermediary layer called the domain
   computes abstraction
   layer.  The abstraction layer contains the remaining path to client layer edge nodes
   (C2 and C3), the destination server layer edge nodes (CN1 and continues CN4), the
   signaling.

   Another alternative suggested in [RFC5152] client-
   server links (C2-CN1 and CN4-C3) and the abstract link CN1-CN4.

   The client layer network is able to make TE routing
   attempt to follow inter-domain IP routing.  Thus,  in operate as normal.  Connectivity
   across the example
   shown network can either be found or not found based on links
   that appear in Figure 2, the source would examine client layer TED.  If connectivity cannot be
   found, end-to-end LSPs cannot be set up.  This failure may be
   reported but no dynamic action is taken by the BGP routing
   information to determine client layer.

   The server network layer also operates as normal.  LSPs across the correct interconnection point for
   forwarding IP packets, and would use that
   server layer between client edges are set up in response to compute and then signal
   a path for Domain A.  Each domain
   management commands or in turn would apply response to signaling requests.

   The abstraction layer consists of the same
   approach so that physical links between the path is progressively computed
   two networks, and signaled
   domain by domain.

   Although also the per-domain approach has many issues and drawbacks in
   terms of achieving optimal (or, indeed, any) paths, it has been abstract links.  The abstract links are
   created by the
   mainstay of inter-domain LSP set-up server network according to date.

4.2.  Crankback

   Crankback addresses one of local policy and represent
   the main issues with per-domain path
   computation: what happens when an initial path is selected potential connectivity that
   cannot could be completed toward created across the destination?  For example, what
   happens if, in Figure 2, server
   network and which the source attempts server network is willing to route make available for
   use by the path
   through interconnection x2, but Domain C does not have client network.  Thus, in this example, the right TE
   resources or connectivity to route diameter of
   the path further?

   Crankback for MPLS-TE and GMPLS networks is described in [RFC4920]
   and abstraction layer network is based on a concept similar to the Acceptable Label Set
   mechanism described for GMPLS signaling only three hops, but an instance of
   an IGP could easily be run so that all nodes participating in [RFC3473].  When a node
   (i.e., a domain entry point) is unable to compute a path further
   across the domain, it returns an error message
   abstraction layer (and in particular the signaling
   protocol that states where client network edge nodes)
   can see the blockage occurred (link identifier,
   node identifier, domain identifier, etc.) and gives some clues about
   what caused TE connectivity in the blockage (bad choice of label, insufficient bandwidth
   available, etc.).  This information allows a previous computation
   point to select an alternative path, or to aggregate crankback
   information and return layer.

    --    --                                  --    --
   |C1|--|C2|                                |C3|--|C4|   Client Network
    --   |  |                                |  |   --
         |  |                                |  |  . . . . . . . . . . .
         |  |                                |  |
         |  |                                |  |
         |  |    ---                  ---    |  |          Abstraction
         |  |---|CN1|================|CN4|---|  |         Layer Network
          --    |   |                |   |    --
                |   |                |   |   . . . . . . . . . . . . . .
                |   |                |   |
                |   |                |   |
                |   |   ---    ---   |   |                Server Network
                |   |--|CN2|--|CN3|--|   |
                 ---    ---    ---    ---

    Key
    --- Direct connection between two nodes
    === Abstract link

      Figure 7 : Architecture for Abstraction Layer Network

   When the client layer needs additional connectivity it upstream to can make a previous computation point.

   Crankback is
   request to the abstraction layer network.  For example, the operator
   of the client network may want to create a very powerful mechanism link from C2 to C3.  The
   abstraction layer can see the potential path C2-CN1-CN4-C3 and can be used to find
   set up an
   end-to-end path in a multi-domain LSP C2-CN1-CN4-C3 across the server network if one exists.

   On and make the other hand, crankback can be quite resource-intensive
   LSP available as
   signaling messages and path setup attempts may "wander around" a link in the
   network attempting client network.

   Sections 4.2.3 and 4.2.4 show how this model is used to find satisfy the correct path for a long time.  Since
   RSVP-TE signaling ties up networks resources
   requirements for partially
   established LSPs, since network conditions may be connectivity in flux, client-server networks and most
   particularly since LSP setup within well-known time limits is highly
   desirable, crankback is not in peer
   networks.

4.2.2.1.  Nodes in the Abstraction Layer Network

   Figure 7 shows a popular mechanism.

   Furthermore, even if crankback can always find an end-to-end path, it
   does not guarantee to find very simplified network diagram and the optimal path. (Note reader would
   be forgiven for thinking that there have
   been some academic proposals to use signaling-like techniques to
   explore the whole only client network in order to find optimal paths, but these
   tend to place even greater burdens on edge nodes and
   server network processing.)

4.3.  Path Computation Element

   The Path Computation Element (PCE) is introduced in [RFC4655].  It is
   an abstract functional entity that computes paths.  Thus, edge nodes may appear in the
   example of per-domain path computation (Section 4.1) the source node
   and each domain entry point abstraction layer
   network.  But this is a PCE.  On not the case: other hand, nodes from the PCE can
   also server
   network may be realized present.  This allows the abstraction layer network
   to be more complex than a full mesh with access spokes.

   Thus, as shown in Figure 8, a separate transit node in the server network element (a server) to which
   computation requests
   (here the node is CN3) can be sent using the Path Computation Element
   Communication Protocol (PCEP) [RFC5440].

   Each PCE has responsibility for computations within exposed as a domain, and has
   visibility of node in the attributes within that domain.  This immediately
   enables per-domain path computation abstraction
   layer network with the opportunity abstract links connecting it to off-load
   complex, CPU-intensive, or memory-intensive computation functions
   from routers other nodes in
   the abstraction layer network.  But  Of course, in the use of PCE network shown in this way does not
   solve
   Figure 8, there is little if any of the problems articulated value in Sections 4.1 and 4.2.

   Two significant mechanisms for cooperation between PCEs have been
   described.  These mechanisms are intended exposing CN3, but if it
   had other abstract links to specifically address the
   problems of computing optimal end-to-end paths other nodes in multi-domain
   environments.

   - The Backward-Recursive PCE-Based Computation (BRPC) mechanism
     [RFC5441] involves cooperation between the set of PCEs along the
     inter-domain path.  Each one computes the possible paths from
     domain entry point (or source node) abstraction layer
   network and/or direct connections to domain exit point (or
     destination node) and shares client network nodes, then the information
   resulting network would be richer.

    --    --                                     --    --     Client
   |C1|--|C2|                                   |C3|--|C4|    Network
    --   |  |                                   |  |   --
         |  |                                   |  |  . . . . . . . . .
         |  |                                   |  |
         |  |                                   |  |
         |  |   ---          ---          ---   |  |       Abstraction
         |  |--|CN1|========|CN3|========|CN5|--|  |      Layer Network
          --   |   |        |   |        |   |   --
               |   |        |   |        |   |  . . . . . . . . . . . .
               |   |        |   |        |   |
               |   |        |   |        |   |                 Server
               |   |   ---  |   |  ---   |   |                 Network
               |   |--|CN2|-|   |-|CN4|--|   |
                ---    ---   ---   ---    ---

      Figure 8 : Abstraction Layer Network with its upstream
     neighbor PCE which is able to build a tree of possible paths
     rooted at Additional Node

   It should be noted that the destination.  The PCE nodes included in the source domain can
     select abstraction layer
   network in this way are not "abstract nodes" in the optimal path.

     BRPC is sometimes described as "crankback at computation time". It
     is capable sense of determining the optimal path in a multi-domain
     network, but depends on knowing
   virtual node described in Section 3.5.  While it is the domain case that contains
   the
     destination node.  Furthermore, policy point responsible for advertising server network resources
   into the mechanism can become quite
     complicated and involve a lot of data abstraction layer network could choose to advertise abstract
   nodes in a mesh place of interconnected
     domains.  Thus, BRPC real physical nodes, it is most often proposed for a simple mesh of
     domains and specifically for a path believed that will cross a known
     sequence doing so
   would introduce significant complexity in terms of:

   - Coordination between all of domains, but where there may be a choice the external interfaces of domain
     interconnections.  In this way, BRPC would only be applied the abstract
     node

   - Management of changes in the server network that lead to
     Figure 2 if a decision had been made (externally) limited
     capabilities to traverse
     Domain C rather than Domain D (notwithstanding that it could
     functionally reach (cross-connect) across the Abstract Node.  It
     may be used to make noted that choice itself), but BRPC recent work on limited cross-connect capabilities
     such as exist in asymmetrical switches could be used very effectively to select between interconnections x1 and x2 represent
     the limitations in an abstract node [RFC7579], [RFC7580].

4.2.3.  Abstraction in Client-Server Networks

   Figure 1.

   - Hierarchical PCE (H-PCE) [RFC6805] offers a parent PCE that is
     responsible for navigating a path across 9 shows the domain mesh and basic architectural concepts for
     coordinating intra-domain computations by the child PCEs
     responsible for each domain.  This approach makes computing an end-
     to-end path across a mesh of domains far more tractable.  However,
     it still leaves unanswered the issue of determining the location of
     the destination (i.e., discovering the destination domain) as
     described in Section 2.1.1.  Furthermore, it raises the question of
     who operates the parent PCE especially in networks where the
     domains client-server
   network.  The client network nodes are under different administrative C1, C2, CE1, CE2, C3, and commercial control.

   It should also be noted that [RFC5623] discusses how PCE is used in a
   multi-layer network with coordination between PCEs operating at each C4.
   The core network layer.  Further issues nodes are CN1, CN2, CN3, and considerations of the use of PCE
   can be found in [RFC7399].

4.4.  GMPLS UNI CN4.  The interfaces
   CE1-CN1 and Overlay Networks

   [RFC4208] defines CE2-CN2 are the GMPLS User-to-Network Interface (UNI) to
   present a routing boundary interfaces between an overlay network and the client and core
   network, i.e. the client-server interface.  In
   networks.

   The technologies (switching capabilities) of the client network,
   the nodes connected directly to and server
   networks may be the core network same or different.  If they are known as edge
   nodes, while the nodes in different, the
   client layer traffic must be tunneled over a server network layer LSP.  If
   they are called core nodes.

   In the overlay model defined by [RFC4208] the core nodes act as a
   closed system and the edge nodes do not participate in same, the routing
   protocol instance that runs among client LSP may be routed over the core nodes.  Thus server layer
   links, tunneled over a server layer LSP, or constructed from the UNI
   allows access to and limited control of the core nodes by edge nodes
   that are unaware of the topology
   concatenation (stitching) of the core nodes.  This respects
   the operational client layer and server layer boundaries while scaling the network.

   [RFC4208] does not define any routing protocol extension for the
   interaction LSP
   segments.

                     :                            :
     Client Network  :        Core Network        :  Client Network
                     :                            :
    --    --    ---                                  ---    --    --
   |C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|
    --    --   |   |    ---                  ---    |   |   --    --
               |   |===|CN1|================|CN4|===|   |
               |   |---|   |                |   |---|   |
                ---    |   |   ---    ---   |   |    ---
                       |   |--|CN2|--|CN3|--|   |
                        ---    ---    ---    ---

    Key
    --- Direct connection between core and edge two nodes but allows
    ... CE-to-CE LSP tunnel
    === Potential path across the core (abstract link)

              Figure 9 : Architecture for Client-Server Network

   The objective is to be able to support an end-to-end connection,
   C1-to-C4, in the exchange
   of reachability information between them.  In terms of client network.  This connection may support TE or
   normal IP forwarding.  To achieve this, CE1 is to be connected to CE2
   by a VPN, link in the client layer.  This enables the client network to
   view itself as connected and to select an end-to-end path.

   As shown in the figure, three abstraction layer links are formed:
   CE1-CN1, CN1-CN2, and CN2-CE2.  A three-hop LSP is then established
   from CE1 to CE2 that can be considered presented as the customer network comprised
   of a number link in the client layer.

   The practicalities of disjoint sites, and how the edge nodes match CE1-CE2 LSP is carried across the VPN CE
   nodes.  Similarly, core
   LSP may depend on the provider network switching and signaling options available in
   the VPN model is
   equivalent to the server network.

   [RFC4208] is, therefore, a signaling-only solution that allows edge
   nodes to request connectivity cross the core network, and leaves network.  The LSP may be tunneled down the core network to select the paths and set up LSP using
   the core LSPs.  This
   solution is supplemented by a number mechanisms of signaling extensions such as
   [RFC4874], [RFC5553], [I-D.ietf-ccamp-xro-lsp-subobject],
   [I-D.ietf-ccamp-rsvp-te-srlg-collect], and
   [I-D.ietf-ccamp-te-metric-recording] to give the edge node more
   control over the a hierarchical LSP that [RFC4206], or the core network will set up by exchanging
   information about core LSPs that have been established LSP segments
   CE1-CN1 and by
   allowing the edge nodes CN2-CE2 may be stitched to supply additional constraints on the core
   LSPs that are to be set up.

   Nevertheless, LSP as described in this UNI/overlay model, the edge node
   [RFC5150].

   Section 4.2.2 has limited
   information already introduced the concept of precisely what LSPs could be set up across the core,
   and what TE services (such as diverse routes for end-to-end
   protection, end-to-end bandwidth, etc.) can abstraction
   layer network through an example of a simple layered network.  But it
   may be supported.

4.5.  Layer One VPN

   A Layer One VPN (L1VPN) is helpful to expand on the example using a service offered by slightly more complex
   network.

   Figure 10 shows a core layer 1 multi-layer network comprising client nodes
   (labeled as Cn for n= 0 to provide layer 1 connectivity (TDM, LSC) between two or
   more customer networks in an overlay service model [RFC4847].

   As in the UNI case, the customer edge has some control over the
   establishment 9) and type of the connectivity.  In the L1VPN context
   three different service models have been defined classified by the
   semantics of information exchanged over the customer interface:
   Management Based, Signaling Based (a.k.a. basic), and Signaling and
   Routing service model (a.k.a. enhanced).

   In the management based model, all edge-to-edge connections are set
   up using configuration and management tools.  This is not a dynamic
   control plane solution and need not concern us here.

   In the signaling based service model [RFC5251] the CE-PE interface
   allows only server nodes (labeled as Sn for signaling message exchange, and
   n = 1 to 9).

                                             --     --
                                            |C3|---|C4|
                                            /--     --\
            --     --     --     --      --/           \--
           |C1|---|C2|---|S1|---|S2|----|S3|           |C5|
            --    /--     --\    --\     --\           /--
                 /           \--    \--     \--     --/    --
                /            |S4|   |S5|----|S6|---|C6|---|C7|
               /             /--     --\    /--    /--     --
            --/    --     --/    --     \--/    --/
           |C8|---|C9|---|S7|---|S8|----|S9|---|C0|
            --     --     --     --      --     --

               Figure 10 : An example Multi-Layer Network

   If the provider network
   does not export any routing information about the core network.  VPN
   membership is known a priori (presumably through configuration) or in Figure 10 is
   discovered using a routing protocol [RFC5195], [RFC5252], [RFC5523], operated as is the relationship between CE nodes separate client and ports on server
   networks then the PE.  This
   service model is much in line with GMPLS UNI client layer topology will appear as defined shown in [RFC4208].

   In
   Figure 11.  As can be clearly seen, the enhanced model network is partitioned and
   there is no way to set up an additional limited exchange of
   routing information over the CE-PE interface between LSP from a node on the provider
   network and left hand side
   (say C1) to a node on the customer network.  The enhanced model considers four
   different types of service models, namely: Overlay Extension, Virtual
   Node, Virtual Link and Per-VPN service models.  All of these
   represent particular cases of right hand side (say C7).

                                 --     --
                                |C3|---|C4|
                                 --     --\
                 --     --                 \--
                |C1|---|C2|                |C5|
                 --    /--                 /--
                      /                 --/    --
                     /                 |C6|---|C7|
                    /                  /--     --
                 --/    --          --/
                |C8|---|C9|        |C0|
                 --     --          --

      Figure 11 : Client Layer Topology Showing Partitioned Network

   For reference, Figure 12 shows the TE information aggregation and
   representation.

4.6.  VNT Manager and Link Advertisement

   As discussed in Section 3.7, operation of a VNT requires policy and
   management input.  In order to handle this, [RFC5623] introduces corresponding server layer
   topology.

                       --     --     --
                      |S1|---|S2|----|S3|
                       --\    --\     --\
                          \--    \--     \--
                          |S4|   |S5|----|S6|
                          /--     --\    /--
                       --/    --     \--/
                      |S7|---|S8|----|S9|
                       --     --      --

                 Figure 12 : Server Layer Topology

   Operating on the
   concept of TED for the Virtual Network Topology Manager (VNTM).  This is server layer, a
   functional management entity or a
   software component that applies may apply policy to requests from and consider what abstract links
   it might offer for use by the client
   networks (or agents layer.  To do this it obviously
   needs to be aware of the client network, such as a PCE) for connections between the
   establishment layers (there is no
   point in offering an abstract link S2-S8 since this could not be of
   any use in this example).

   In our example, after consideration of which LSPs could be set up in
   the server network to provide connectivity
   in layer, four abstract links are offered: S1-S3, S3-S6,
   S1-S9, and S7-S9.  These abstract links are shown as double lines on
   the client network.

   The VNTM would, in fact, form part resulting topology of the provisioning path for all
   server abstraction layer network LSPs whether they are set up ahead in Figure 13.
   As can be seen, two of client network
   demand or triggered by end-to-end client network LSP signaling.

   An important companion to this function is determining how the LSP
   set up across the server network is made available as links must share part of a TE link in
   the client network.  Obviously, if the LSP is established path (S1-S9
   must share with either S1-S3 or with S7-S9).  This could be achieved
   using
   management intervention, distinct resources (for example, separate lambdas) where the subsequent client network TE link can
   paths are common, but it could also be configured manually.  However, if done using resource sharing.

   That would mean that when both paths S1-S3 and S7-S9 carry client-
   edge to client-edge LSPs the LSP is signaled
   dynamically there is need for resources on the end points path S1-S9 are used and
   might be depleted to exchange the link
   properties point that they should advertise within the client network, path is resource constrained
   and
   in the case of a server network that supports more than one client,
   it will cannot be necessary to indicate which client or clients can use the
   link.  This capability it provided used.

                                            --
                                           |C3|
                                           /--
                   --     --            --/
                  |C2|---|S1|==========|S3|
                   --     --\\          --\\
                             \\            \\
                              \\            \\--     --
                               \\            |S6|---|C6|
                                \\            --     --
                   --     --     \\--     --
                  |C9|---|S7|=====|S9|---|C0|
                   --     --       --     --

          Figure 13 : Abstraction Layer Network with Abstract Links

   The separate IGP instance running in [RFC6107].

   Note that a potential server the abstraction layer network LSP
   means that this topology is advertised visible at the edge nodes (C2, C3, C6,
   C9, and C0) as well as at a TE
   link in PCE if one is present.

   Now the client network might layer is able to be determined dynamically by
   the edge nodes.  In this case there will need make requests to be some effort the abstraction
   layer network to
   ensure provide connectivity.  In our example, it requests
   that both ends of the link have the same view of the available
   TE resources, or else the advertised link will be asymmetrical.

4.7.  What Else C2 is Needed connected to C3 and Why?

   As can be seen from Sections 4.1 through 4.6, a lot of effort has
   focused on client-server networks as described in Figure 3.  Far less
   consideration has been given that C2 is connected to network peering or the combination of C0.  This
   results in several actions:

   1. The management component for the two use cases.

   Various work has been suggested abstraction layer network asks
      its PCE to extend the definition of the UNI
   such that routing information can be passed across compute the interface.
   However, this approach seems paths necessary to break the architectural concept of
   network separation that make the UNI facilitates.

   Other approaches are working toward a flattening of connections.
      This yields C2-S1-S3-C3 and C2-S1-S9-C0.

   2. The management component for the abstraction layer network with
   complete visibility into
      instructs C2 to start the server networks being made available signaling process for the new LSPs in
      the client network. These approaches, while functional, ignore abstraction layer.

   3. C2 signals the
   main reasons LSPs for introducing network separation in setup using the explicit routes
      C2-S1-S3-C3 and C2-S1-S9-C0.

   4. When the signaling messages reach S1 (in our example, both LSPs
      traverse S1) the first place.

   The remainder of this document introduces a new approach based on
   network abstraction that allows a server layer network to use its own
   knowledge of its resources and topology combined with its own
   policies to determine what edge-to-edge connectivity capabilities it
   will inform the client networks about.

5.  Architectural Concepts

5.1.  Basic Components

   This section revisits the use cases from Section 2 to present the
   basic architectural components that provide connectivity in the
   peer and client-server cases.  These component models can then be
   used in later sections to enable discussion of may support them by a solution
   architecture.

5.1.1.  Peer Interconnection

   Figure 7 shows
      number of means including establishing server layer LSPs as
      tunnels depending on the basic architectural concepts for connecting across
   peer networks.  Nodes from four networks are shown: A1 and A2 come
   from one network; B1, B2, and B3 from another network; etc.  The
   interfaces mismatch of technologies between the networks (sometimes known as External Network-
   to-Network Interfaces - ENNIs) are A2-B1, B3-C1,
      client and C3-D1.

   The objective is to server networks.  For example, S1-S2-S3 and S1-S2-S5-S9
      might be able to support traversed via an end-to-end connection A1-
   to-D2.  This connection is for TE connectivity.

   As shown in LSP tunnel, using LSPs stitched
      together, or simply by routing the figure, client layer LSP tunnels that span through the transit networks
      server network.  If server layer LSPs are used needed to achieve the required connectivity.  These transit LSPs
   form the key building blocks of the end-to-end connectivity.

   The transit tunnels they can be used as hierarchical
      signaled at this point.

   5. Once any server layer LSPs [RFC4206] that are needed have been established,
      S1 can continue to
   carry signal the end-to-end LSP, or can become stitching segments [RFC5150]
   of client-edge to client-edge LSP
      across the end-to-end LSP.  The transit abstraction layer either using the server layer LSPs as
      tunnels B1-B3 and C-C3 can be or as an abstract link as discussed in Section 5.3.

               :                  :                  :
    Network A  :    Network B     :    Network C     :  Network D
               :                  :                  :
     --    --     --    --    --     --    --    --     --    --
    |A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2| stitching segments, or simply routing through the
      server layer network.

                                   --   --    |  |
                                  |C3|-|C4|
                                  /--   --\
                                 /         \--
                       --   |  |   |  |     --/          |C5|
                      |C1|---|C2|          /--
                       --   |  |    /--\       --/    --
                            /    \     |C6|---|C7|
                           /      \    /--     --
                 |  |========|  |   |  |========|  |
                          /        \--/
                       --/    --   |C0|
                      |C8|---|C9|   --
                       --     --

    Key
    --- Direct connection between two nodes
    === LSP tunnel across transit network

      Figure 7 14 : Architecture for Peering

5.1.2.  Client-Server Interconnection

   Figure 8 shows Connected Client Layer Network with Additional Links

   6. Finally, once the client-edge to client-edge LSPs have been set
      up, the basic architectural concepts for a client-server
   network.  The client network nodes are C1, C2, CE1, CE2, C3, and C4.
   The core network nodes are CN1, CN2, CN3, and CN4.  The interfaces
   CE1-CN1 layer can be informed and CE2-CN2 are the interfaces between can start to advertise
      the client new TE links C2-C3 and core
   networks. C2-C0.  The objective resulting client layer
      topology is to be able to support an end-to-end connection,
   C1-to-C4, shown in Figure 14.

   7. Now the client network.  This connection layer can compute an end-to-end path from C1 to C7.

4.2.3.1  A Server with Multiple Clients

   A single server network may support TE or
   normal IP forwarding.  To achieve this, CE1 multiple client networks.  This
   is to be connected to CE2 not an uncommon state of affairs for example when the server
   network provides connectivity for multiple customers.

   In this case, the abstraction provided by a link in the client server layer that is supported by may vary
   considerably according to the policies and commercial relationships
   with each customer.  This variance would lead to a core separate
   abstraction layer network
   LSP.

   As shown in maintained to support each client network.

   On the figure, two LSPs other hand, it may be that multiple clients are used subject to achieve the required
   connectivity.  One LSP is set up across the core from CN1 to CN2.
   This core LSP then supports a three-hop LSP from CE1 to CE2 with its
   middle hop being
   same policies and the core LSP.  It is abstraction can be identical.  In this LSP that is presented as case, a
   link in
   single abstraction layer network can support more than one client.

   The choices here are made as an operational issue by the client server layer
   network.

4.2.3.2  A Client with Multiple Servers

   A single client network may be supported by multiple server networks.
   The practicalities server networks may provide connectivity between different parts
   of how the CE1-CE2 LSP is carried across the core
   LSP client network or may depend on provide parallel (redundant)
   connectivity for the switching client network.

   In this case the abstraction layer network should contain the
   abstract links from all server networks so that it can make suitable
   computations and signaling options available create the correct TE links in the core client network.  The LSP may be tunneled down the core LSP using
   the mechanisms of a hierarchical LSP [RFC4206], or
   That is, the LSP segments
   CE1-CN1 relationship between client network and CN2-CE2 may abstraction
   layer network should be stitched to the core LSP as described one-to-one.

4.2.4.  Abstraction in
   [RFC5150].

                     :                            :
     Client Network  :        Core Network        :  Client Network
                     : Peer Networks

   Figure 15 shows the basic architectural concepts for connecting
   across peer networks.  Nodes from four networks are shown: A1 and A2
   come from one network; B1, B2, and B3 from another network; etc.  The
   interfaces between the networks (sometimes known as External Network-
   to-Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1.

   The objective is to be able to support an end-to-end connection A1-
   to-D2.  This connection is for TE connectivity.

   As shown in the figure, abstract links that span the transit networks
   are used to achieve the required connectivity.  These links form the
   key building blocks of the end-to-end connectivity.  An end-to-end
   LSP uses these links as part of its path.  If the stitching
   capabilities of the networks are homogeneous then the end-to-end LSP

               :                  :                  :
    Network A  :    Network B     :    Network C     :  Network D
               :                  :                  :
     --    --    ---                                  ---     --    --
   |C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|    --     --    --    --     --    --
    |A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2|
     --    --    |  |    ---                  ---   --   |  |   --    --   |   |---|CN1|================|CN4|---|  |
                ---   --   |  |   ---    ---    --    --
                 |  |========|  |    ---   |   |--|CN2|--|CN3|--|  |========|  |
                        ---    ---    ---    ---
                  --          --     --          --

    Key
    --- Direct connection between two nodes
    ... CE-to-CE LSP tunnel
    === LSP tunnel Abstract link across the core transit network

                Figure 8 15 : Architecture for Client-Server Network

5.2.  TE Reachability

   As described in Section 1.1, TE reachability is Peering

   may simply traverse the ability to reach path defined by the abstract links across the
   various peer networks or may utilize stitching of LSP segments that
   each traverse a specific address network along a TE path.  The knowledge the path of TE reachability
   enables an end-to-end TE path to be computed.

   In a single network, TE reachability is derived from abstract link.  If the Traffic
   Engineering Database (TED) that is
   network switching technologies support or necessitate the collection use of all TE
   information about all TE links in the network.  The TED is usually
   built from the data exchanged by LSP
   hierarchies, the IGP, although it can be
   supplemented by configuration and inventory details especially in
   transport networks.

   In multi-network scenarios, TE reachability information can end-to-end LSP may be
   described as "You can get from node X to node Y with tunneled across each network
   using hierarchical LSPs that each each traverse a network along the following
   TE attributes."  For transit cases, nodes X and Y will be edge nodes
   path of the transit network, but it is also important to consider the
   information about the TE connectivity between an edge node and a
   specific destination node.

   TE reachability abstract link.

   Peer networks exist in many situations in the Internet.  Packet
   networks may be unqualified (there is a TE path), peer as IGP areas (levels) or may be
   qualified by TE attributes such as TE metrics, hop count, available
   bandwidth, delay, shared risk, etc.

   TE reachability information can be exchanged between ASes.  Transport
   networks so that
   nodes in one network can determine whether they can establish TE
   paths across or into another network.  Such exchanges are subject (such as optical networks) may peer to provide
   concatenations of optical paths through single vendor environments
   (see Section 6).  Figure 16 shows a range simple example of policies imposed by the advertiser (for security and
   administrative control) and by the receiver (for scalability three peer
   networks (A, B, and
   stability).

5.3.  Abstraction not Aggregation

   Aggregation is the process C) each comprising a few nodes.

            Network A    :     Network B      :   Network C
                         :                    :
      --     --      --  :  --     --     --  :  --     --
     |A1|---|A2|----|A3|---|B1|---|B2----|B3|---|C1|---|C2|
      --     --\    /--  :  --    /--\    --  :  --     --
                \--/     :       /    \       :
                |A4|     :      /      \      :
                 --\     :     /        \     :
              --    \--  :  --/          \--  :  --     --
             |A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
              --     --  :  --            --  :  --     --
                         :                    :
                         :                    :

       Figure 16 : A Network Comprising Three Peer Networks

   As discussed in Section 2, peered networks do not share visibility of synthesizing from available
   information.  Thus, the virtual node
   their topologies or TE capabilities for scaling and virtual link models
   described confidentiality
   reasons.  That means, in Section 3.6 rely on processing the information available
   within our example, that computing a network path from A1
   to produce C4 can be impossible without the aggregate representations aid of cooperating PCEs or some
   form of crankback.

   But it is possible to produce abstract links for reachability across
   transit peer networks and nodes that are presented to create an abstraction layer network.
   That network can be enhanced with specific reachability information
   if a destination network is partitioned as is the consumer.  As described case with Network C
   in
   Section 3, dynamic aggregation is subject Figure 16.

   Suppose Network B decides to a number of pitfalls.

   In order offer three abstract links B1-B3, B4-B3,
   and B4-B6.  The abstraction layer network could then be constructed
   to distinguish the architecture described in this document
   from the previous work on aggregation, we use look like the term "abstraction" network in this document.  The process of abstraction is one of applying
   policy to Figure 17.

                     --     --      --      --
                    |A3|---|B1|====|B3|----|C1|
                     --     --    //--      --
                                 //
                                //
                               //
                     --     --//     --     --
                    |A6|---|B4|=====|B6|---|C3|
                     --     --       --     --

     Figure 17 : Abstraction Layer Network for the available TE information within Peer Network Example

   Using a domain, process similar to produce
   selective information that represents the potential ability to
   connect across the domain.

   Abstraction does not offer all possible connectivity options (refer
   to Section 3.6), but does present a general view of potential
   connectivity.  Abstraction may have a dynamic element, but is not
   intended to keep pace with the changes described in TE attribute availability
   within the network.

   Thus, when relying on an abstraction to compute an end-to-end path,
   the process might not deliver a usable path.  That is, there is no
   actual guarantee that the abstractions are current or feasible.

   While abstraction uses available TE information, it is subject Section 4.2.3, Network A
   can request connectivity to
   policy Network C and management choices.  Thus, not all potential connectivity
   will abstract links can be
   advertised to each client.  The filters may depend on
   commercial relationships, that connect the risk of disclosing confidential
   information, and concerns about what use is made edges of the connectivity two networks and that can be
   used to carry LSPs that traverse both networks.  Furthermore, if
   Network C is offered.

5.3.1.  Abstract Links

   An abstract link is a measure of the potential partitioned, reachability information can be exchanged
   to connect a pair of
   points with certain TE parameters.  An allow Network A to select the correct abstract link may be realized
   by an existing LSP, or may represent the possibility of setting up an
   LSP.

   When looking at a network such as that shown in
   Figure 8, the link from CN1
   to CN4 may be an abstract link.  If the LSP has already been set up,
   it is easy 18.

                    Network A       :      Network C
                                    :
              --     --      --     :     --       --
             |A1|---|A2|----|A3|=========|C1|.....|C2|
              --     --\    /--     :     --       --
                        \--/        :
                        |A4|        :
                         --\        :
                      --    \--     :     --       --
                     |A5|---|A6|=========|C3|.....|C4|
                      --     --     :     --       --

     Figure 18 : Tunnel Connections to advertise it as a link Network C with known TE attributes: policy
   will have been applied in the server network to decide what LSP to
   set up.  If the LSP has not yet been established, the potential for
   an LSP Reachability

   Peer networking cases can be abstracted from the TE information made far more complex by dual homing
   between network peering nodes (for example, A3 might connect to B1
   and B4 in Figure 17) and by the core network
   subject networks themselves being arranged in
   a mesh (for example, A6 might connect to policy, B4 and C1 in Figure 17).

   These additional complexities can be handled gracefully by the resultant potential LSP
   abstraction layer network model.

   Further examples of abstraction in peer networks can be advertised.

   Since found in
   Sections 6 and 8.

4.3.  Considerations for Dynamic Abstraction

   It is possible to consider a highly dynamic system where the client nodes do not have visibility server
   network adaptively suggests new abstract links into the core network,
   they must rely on abstraction information delivered
   layer, and where the abstraction layer proactively deploys new
   client-edge to them by client-edge LSPs to provide new links in the
   core client
   network.  That  Such fluidity is, however, to be treated with caution
   especially in the core network will report on the potential
   for connectivity.

5.3.2.  The Abstraction Layer Network

   Figure 9 introduces the abstraction layer network.  This construct
   separates the client case of client-server networks of differing
   technologies where hierarchical server layer resources (nodes C1, C2, C3, and C4, and LSPs are used because of
   the corresponding links), and longer turn-up times of connections in some server networks,
   because the server layer networks are likely to be sparsely connected and
   expensive physical resources (nodes CN1,
   CN2, CN3, will only be deployed where there is
   believed to be a need for them.  More significantly, the complex
   commercial, policy, and CN4 administrative relationships that may exist
   between client and server network operators mean that stability is
   more likely to be the corresponding links).  Additionally, the desired operational practice.

   Thus, proposals for fully automated multi-layer networks based on
   this architecture introduces an intermediary layer called the abstraction
   layer.  The abstraction layer contains the client layer edge nodes
   (C2 may be regarded as forward-looking topics for
   research both in terms of network stability and C3), the with regard to
   ecomonic impact.

   However, some elements of automation should not be discarded.  A
   server layer edge nodes (CN1 and CN4), network may automatically apply policy to determine the client-
   server best
   set of abstract links (C2-CN1 to offer and CN4-C3) the most suitable way for the
   server network to support them.  And a client network may dynamically
   observe congestion, lack of connectivity, or predicted changes in
   traffic demand, and may use this information to request additional
   links from the abstract link CN1-CN4.

    --    --                                  --    --
   |C1|--|C2|                                |C3|--|C4|   Client Network
    --   |  |                                |  |   --
         |  |                                |  |  . . . . . . . . . . .
         |  |                                |  |
         |  |                                |  |
         |  |    ---                  ---    |  |          Abstraction
         |  |---|CN1|================|CN4|---|  |         Layer Network
          --    |   |                |   |    --
                |   |                |   |   . . . . . . . . . . . . . .
                |   |                |   |
                |   |                |   |
                |   |   ---    ---   |   |                Server Network
                |   |--|CN2|--|CN3|--|   |
                 ---    ---    ---    ---

    Key
    --- Direct connection between two nodes
    === Abstract link

      Figure 9 : Architecture for Abstraction Layer Network

   The client layer network is abstraction layer.  And, once policies have been
   configured, the whole system should be able to operate as normal.  Connectivity
   across the network can either be found or autonomous of
   operator control (which is not found based on links to say that appear in the client layer TED.  If connectivity cannot be
   found, end-to-end LSPs cannot be set up.  This failure may be
   reported but no dynamic action is taken by the client layer.

   The server network layer also operates as normal.  LSPs across operator will not have
   the
   server layer are set up in response to management commands or option of exerting control at every step in
   response to signaling requests. the process).

4.4.  Requirements for Advertising Links and Nodes

   The abstraction layer consists of the physical links between the
   two networks, and also the abstract links. network is "just another network layer".  The abstract
   links are
   created by and nodes in the server network according need to local policy and represent
   the potential connectivity that could be created across advertised along with their
   associated TE information (metrics, bandwidth, etc.) so that the server
   network
   topology is disseminated and which so that routing decisions can be made.

   This requires a routing protocol running between the server network is willing to make available for
   use by nodes in the client
   abstraction layer network.  Thus, in  Note that this example, routing information
   exchange could be piggy-backed on an existing routing protocol
   instance, or use a new instance (or even a new protocol).  Clearly,
   the diameter information exchanged is only that which has been created as
   part of the abstraction layer function according to policy.

   It should be noted that in many cases the abstract represents the
   potential for connectivity across the server network is only three hops, but an instance of
   an IGP could easily be run so that all nodes participating no such
   connectivity exists.  In this case we may ponder how the routing
   protocol in the abstraction layer (and in particular will advertise topology information
   for and over a link that has no underlying connectivity.  In other
   words, there must be a communication channel between the client network edge nodes)
   can see abstract
   layer nodes so that the TE routing protocol messages can flow.  The
   answer is that control plane connectivity already exists in the layer.

   When
   server network and on the client layer needs additional connectivity it client-server edge links, and this can make a
   request be
   used to carry the routing protocol messages for the abstraction layer
   network.  For example,  The same consideration applies to the operator
   of advertisement, in the
   client network may want to create a link from C2 to C3.  The
   abstraction layer can see of the potential path C2-CN1-CN4-C3, and asks connectivity that the server layer to realize the abstract link CN1-CN4.  The server abstraction
   layer provisions the LSP CN1-CN2-CN3-CN4 and makes the LSP available
   as a hierarchical LSP network can provide although it may be more normal to turn the abstract link into establish
   that connectivity before advertising a link that can
   be used in the client network.

4.5.  Addressing Considerations

   The abstraction layer can then set up
   an LSP C2-CN1-CN4-C3 using stitching or tunneling, and make the LSP
   available as a virtual link network layers in the client network.

   Sections 5.3.3 and 5.3.4 show how this model is used architecture should be able to satisfy the
   requirements for connectivity in client-server networks operate
   with separate address spaces and these may overlap without any
   technical issues.  That is, one address may mean one thing in peer
   networks.

5.3.2.1.  Nodes in the Abstraction Layer Network

   Figure 9 shows a very simplified network diagram and the reader would
   be forgiven for thinking that only
   client network edge nodes and
   server network edge nodes network, yet the same address may appear have a different meaning in
   the abstraction layer network or the server network.  But  In other words
   there is complete address separation between networks.

   However, this will require some care both because human operators may
   well become confused, and because mapping between address spaces is not
   needed at the case: other nodes from interfaces between the network layers.  That mapping
   requires configuration so that, for example, when the server network may be present.  This allows
   announces an abstract link from A to B, the abstraction layer network
   to be more complex than a full mesh with access spokes.

   Thus, as shown in Figure 10, a transit node in the
   must recognize that A and B are server network
   (here the node is CN3) can be exposed as a node addresses and must map
   them to abstraction layer addresses (say P and Q) before including
   the link in its own topology.  And similarly, when the abstraction
   layer network with abstract links connecting informs the client network that a new link is available
   from S to T, it must map those addresses from its own address space
   to other nodes in that of the abstraction layer client network.  Of course,

   This form of address mapping will become particularly important in the
   cases where one abstraction layer network shown is constructed from
   connectivity in
   Figure 10, there multiple server layer networks, or where one
   abstraction layer network provides connectivity for multiple client
   networks.

5.  Building on Existing Protocols

   This section is little if not intended to prejudge a solutions framework or any value
   applicability work.  It does, however, very briefly serve to note the
   existence of protocols that could be examined for applicability to
   serve in exposing CN3, but if realizing the model described in this document.

   The general principle of protocol re-use is preferred over the
   invention of new protocols or additional protocol extensions, and it
   had other abstract links
   would be advantageous to other make use of an existing protocol that is
   commonly implemented on network nodes and is currently deployed, or
   to use existing computational elements such as Path Computation
   Elements (PCEs).  This has many benefits in the abstraction layer network and/or direct connections stability, time
   to deployment, and operator training.

   It is recognized, however, that existing protocols are unlikely to client network nodes, then the
   resulting network would be richer.

    --    --                                     --    --     Client
   |C1|--|C2|                                   |C3|--|C4|    Network
    --   |  |                                   |  |   --
         |  |                                   |  |  . . . . . . . . .
         |  |                                   |  |
         |  |                                   |  |
         |  |   ---          ---          ---   |  |       Abstraction
         |  |--|CN1|========|CN3|========|CN5|--|  |      Layer Network
          --   |   |        |   |        |   |   --
               |   |        |   |        |   |  . . . . . . . . . . . .
               |   |        |   |        |   |
               |   |        |   |        |   |                 Server
               |   |   ---  |   |  ---   |   |                 Network
               |   |--|CN2|-|   |-|CN4|--|   |
                ---    ---   ---   ---    ---

      Figure 10 : Abstraction Layer Network with Additional Node

   It should be noted that the nodes included in the abstraction layer
   network in
   immediately suitable to this way are not "abstract nodes" in problem space without some protocol
   extensions.  Extending protocols must be done with care and with
   consideration for the sense stability of existing deployments. In extreme
   cases, a
   virtual node new protocol can be preferable to a messy hack of an
   existing protocol.

5.1.  BGP-LS

   BGP-LS is a set of extensions to BGP described in Section 3.6.  While it
   [I-D.ietf-idr-ls-distribution].  It's purpose is the case that
   the policy point responsible to announce topology
   information from one network to a "north-bound" consumer.
   Application of BGP-LS to date has focused on a mechanism to build a
   TED for advertising a PCE.  However, BGP's mechanisms would also serve well to
   advertise abstract links from a server network resources into the abstraction
   layer network could choose network, or to advertise abstract
   nodes in place of real physical nodes, it is believed that doing so
   would introduce significant complexity in terms of:

   - Coordination between all of potential connectivity from the external interfaces of
   abstraction layer network to the abstract
     node

   - Management client network.

5.2.  IGPs

   Both OSPF and IS-IS have been extended through a number of changes RFCs to
   advertise TE information.  Additionally, both protocols are capable
   of running in the server network a multi-instance mode either as ships that lead to limited
     capabilities to reach (cross-connect) across pass in the Abstract Node.  It
     may be noted that recent work
   night (i.e., completely separate instances using different address)
   or as dual instances on limited cross-connect capabilities
     such the same address space.  This means that
   either IGP could probably be used as exist the routing protocol in asymmetrical switches could the
   abstraction layer network.

5.3.  RSVP-TE

   RSVP-TE signaling can be used to represent set up all traffic engineered LSPs
   demanded by this model without the limitations in an abstract node
     [I-D.ietf-ccamp-general-constraint-encode],
     [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te].

5.3.3.  Abstraction need for any protocol extensions.

   If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can
   be used to carry LSPs over the server layer network, again without
   needing any protocol extensions.

   Furthermore, the procedures in Client-Server Networks

   Section 5.3.2 has already introduced [RFC6107] allow the concept dynamic signaling
   of the abstraction
   layer network through an example purpose of a simple layered network.  But any LSP that is established.  This means that
   when an LSP tunnel is set up, the two ends can coordinate into which
   routing protocol instance it
   may should be helpful to expand advertised, and can also agree
   on the example using a slightly more complex
   network.

   Figure 11 shows a multi-layer network comprising client nodes
   (labeled as Cn for n= 0 addressing to 9) and server nodes (labeled as Sn for
   n = 1 be said to 9).

                                             --     --
                                            |C3|---|C4|
                                            /--     --\
            --     --     --     --      --/           \--
           |C1|---|C2|---|S1|---|S2|----|S3|           |C5|
            --    /--     --\    --\     --\           /--
                 /           \--    \--     \--     --/    --
                /            |S4|   |S5|----|S6|---|C6|---|C7|
               /             /--     --\    /--    /--     --
            --/    --     --/    --     \--/    --/
           |C8|---|C9|---|S7|---|S8|----|S9|---|C0|
            --     --     --     --      --     --

               Figure 11 : An example Multi-Layer Network

   If identify the network in Figure 11 link that will be
   created.

5.4.  Notes on a Solution

   This section is not intended to be prescriptive or dictate the
   protocol solutions that may be used to satisfy the architecture
   described in this document, but it does show how the existing
   protocols listed in the previous sections can be combined to provide
   a solution with only minor modifications.

   A server network can be operated as separate client using GMPLS routing and server
   networks then signaling
   protocols.  Using information gathered from the client layer topology will appear as shown in
   Figure 12.  As routing protocol, a
   TED can be clearly seen, constructed containing resource availability information
   and Shared Risk Link Group (SRLG) details.  A policy-based process
   can then determine which nodes and abstract links it wishes to
   advertise to form the abstract layer network.

   The server network is partitioned can now use BGP-LS to advertise a topology of
   links and
   there is no way nodes to set up an LSP form the abstraction layer network.  This
   information would most likely be advertised from a node on single point of
   control that made all of the left hand side
   (say C1) to a node on the right hand side (say C7).

                                 --     --
                                |C3|---|C4|
                                 --     --\
                 --     --                 \--
                |C1|---|C2|                |C5|
                 --    /--                 /--
                      /                 --/    --
                     /                 |C6|---|C7|
                    /                  /--     --
                 --/    --          --/
                |C8|---|C9|        |C0|
                 --     --          --

      Figure 12 : Client Layer Topology Showing Partitioned Network

   For reference, Figure 13 shows the corresponding server layer
   topology.

                       --     --     --
                      |S1|---|S2|----|S3|
                       --\    --\     --\
                          \--    \--     \--
                          |S4|   |S5|----|S6|
                          /--     --\    /--
                       --/    --     \--/
                      |S7|---|S8|----|S9|
                       --     --      --

                 Figure 13 : Server Layer Topology

   Operating on the TED for abstraction decisions, but the function
   could be distributed to multiple server layer, a management entity or a
   software component may apply policy and consider what abstract links
   it might offer for use network edge nodes.  The
   information can be advertised by BGP-LS to multiple points within the
   abstraction layer (such as all client layer.  To do this it obviously
   needs network edge nodes) or to be aware of the connections between the layers (there a
   single controller.

   Multiple server networks may advertise information that is no
   point in offering used to
   construct an abstract link S2-S8 since this could not be of
   any use abstraction layer network, and one server network may
   advertise different information in this example).

   In our example, after consideration different instances of which LSPs could be set up BGP-LS to
   form different abstraction layer networks.  Furthermore, in the server layer, four abstract links are offered: S1-S3, S3-S6,
   S1-S9, and S7-S9.  These abstract links are shown as double lines on
   the resulting topology case
   of one controller constructing multiple abstraction layer networks,
   BGP-LS uses the route target mechanism defined in [RFC4364] to
   distinguish the different applications (effectively abstraction layer
   network in Figure 14.
   As can VPNs) of the exported information.

   Extensions may be seen, two made to BGP-LS to allow advertisement of Macro
   Shared Risk Link Groups (MSRLGs) per Appendix B, mutually exclusive
   links, and to indicate whether the abstract link has been pre-
   established or not.  Such extensions are valid options, but do not
   form a core component of this architecture.

   The abstraction layer network may operate under central control or
   use a distributed control plane.  Since the links must share part and nodes may be a
   mix of physical and abstract links, and since the nodes may have
   diverse cross-connect capabilities, it is most likely that a path (S1-S9
   must share with either S1-S3 or with S7-S9).  This could GMPLS
   routing protocol will be achieved
   using distinct resources (for example, separate lambdas) where beneficial for collecting and correlating
   the
   paths routing information and for distributing updates.  No special
   additional features are common, needed beyond adding those extra parameters
   just described for BGP-LS, but it could also should be done using resource sharing.

   That would mean noted that when both S1-S3 and S7-S9 are realized as links
   carrying the control
   plane of the abstraction layer LSPs, network must run in an out of band
   control network because the link S1-S9 can no longer be
   used.

                                            --
                                           |C3|
                                           /--
                   --     --            --/
                  |C2|---|S1|==========|S3|
                   --     --\\          --\\
                             \\            \\
                              \\            \\--     --
                               \\            |S6|---|C6|
                                \\            --     --
                   --     --     \\--     --
                  |C9|---|S7|=====|S9|---|C0|
                   --     --       --     --

          Figure 14 : Abstraction Layer Network with Abstract Links

   The separate IGP instance running data-bearing links might not yet have
   been established via connections in the server layer network.

   The abstraction layer network
   means that this topology is visible at the edge nodes (C2, C3, C6,
   C9, and C0) as well as at a PCE if one is present.

   Now the client layer is also able to make requests determine potential
   connectivity from client network edge to the abstraction
   layer client network edge.  It
   will determine which client network links to provide connectivity.  In our example, it requests
   that C2 is connected create according to C3
   policy and that C2 is connected to C0.  This
   results in several actions:

   1. The management component for the abstraction layer network asks
      its PCE to compute the paths necessary subject to make requests from the connections.
      This yields C2-S1-S3-C3 client network, and C2-S1-S9-C0.

   2. The management component will
   take four steps:

   - First it will compute a path for across the abstraction layer network
      instructs C2 to start the signaling process for
     network.
   - Then, if the new LSPs in support of the abstraction layer.

   3. C2 signals abstract links requires the use of
     server layer LSPs for setup using the explicit routes
      C2-S1-S3-C3 tunneling or stitching, and C2-S1-S9-C0.

   4. When the signaling messages reach S1 (in our example, both if those LSPs
      traverse S1) are
     not already established, it will ask the server layer to set them
     up.
   - Then, it will signal the client-edge to client-edge LSP.
   - Finally, the abstraction layer network may find that will inform the
      necessary underlying LSPs (S1-S2-S3 and S1-S2-S5-S9) have not
      been established since it is not a requirement that an abstract
      link client
     network of the existence of the new client network link.

   This last step can be backed up achieved either by a real LSP.  In this case, S1 computes coordination of the
      paths end
   points of the underlying LSPs and signals them.

   5. Once that span the serve abstraction layer LSPs have been established, S1 can continue
      to signal the abstraction layer LSPs either (these points are
   client network edge nodes) using the server layer
      LSPs mechanisms such as tunnels those described
   in [RFC6107], or as stitching segments.

                                   --   --
                                  |C3|-|C4|
                                  /--   --\
                                 /         \--
                       --     --/          |C5|
                      |C1|---|C2|          /--
                       --    /--\       --/    --
                            /    \     |C6|---|C7|
                           /      \    /--     --
                          /        \--/
                       --/    --   |C0|
                      |C8|---|C9|   --
                       --     --

      Figure 15 : Connected Client Layer Network with Additional Links

   6. Finally, once using BGP-LS from a central controller.

   Once the abstraction layer LSPs have been set up, client network edge nodes are aware of a new link, they will
   automatically advertise it using their routing protocol and it will
   become available for use by traffic in the client layer can be informed network.

   Sections 6, 7, and can start to advertise 8 discuss the
      new TE links C2-C3 applicability of this architecture
   to different network types and C2-C0.  The resulting client layer topology problem spaces, while Section 9 gives
   some advice about scoping future work.  Section 9 on manageability
   considerations is shown particularly relevant in Figure 15.

   7. Now the client layer can compute an end-to-end path from C1 context of this
   section because it contains a discussion of the policies and
   mechanisms for indicating connectivity and link availability between
   network layers in this architecture.

6. Applicability to C7.

5.3.3.1  Macro Shared Risk Link Groups

   Network links often share fate with one or more other links.  That
   is, Optical Domains and Networks

   Many optical networks are arranged a scenario that may cause set of small domains. Each
   domain is a links to fail could cause one or more
   other links to fail.  This may occur, for example, if the links are
   supported by cluster of nodes, usually from the same fiber bundle, or if some links are routed down equipment vendor
   and with the same duct or in a common piece of infrastructure such properties.  The domain may be constructed as a
   bridge.  A common way to identify the links that may share fate is to
   label them
   mesh or a ring, or maybe as belonging an interconnected set of rings.

   The network operator seeks to provide end-to-end connectivity across
   a Shared Risk Link Group (SRLG) [RFC4202].

   TE links created network constructed from LSPs in lower layers may also share fate, multiple domains, and
   it can be hard for so (of course) the
   domains are interconnected.  In a client network to know about this problem
   because it does not know under management control
   such as through an Operations Support System (OSS), each domain is
   under the topology operational control of the server network or the a Network Management System (NMS).

   In this way, an end-to-end path of may be commissioned by the server layer LSPs that are used to create OSS
   instructing each NMS, and the links in NMSes setting up the client network.

   For example, looking at path fragments
   across the example used domains.

   However, in Section 5.3.3 and
   considering the two abstract links S1-S3 and S1-S9 a system that uses a control plane, there is no way a need for
   integration between the client layer to know whether the links C2-C0 and C2-C3 share
   fate.  Clearly, if the client layer uses these links to provide domains.

   Consider a
   link-diverse end-to-end protection scheme, it needs to know that the
   links actually share a piece of network infrastructure (the server
   layer link S1-S2).

   Per [RFC4202], an SRLG represents a shared physical network resource
   upon which the normal functioning of a link depends.  Multiple SRLGs
   can be identified and advertised for every TE link simple domain, D1, as shown in a network.
   However, Figure 19.  In this can produce a scalability problem case,
   the nodes A through F are arranged in a mutli-layer
   network topological ring. Suppose
   that equates to advertising there is a control plane in use in the client layer the server
   layer route of each TE link.

   Macro SRLGs (MSRLGs) address this scaling problem domain, and are a form of
   abstraction performed at the same time that OSPF is
   used as the abstract links are
   derived.  In this way, only the links TE routing protocol.

             -----------------
            |              D1 |
            |      B---C      |
            |     /     \     |
            |    /       \    |
            |   A         D   |
            |    \       /    |
            |     \     /     |
            |      F---E      |
            |                 |
             -----------------

       Figure 19 : A Simple Optical Domain

   Now consider that actually links in the
   server layer need to be advertised rather than every link that
   potentially shares resources.  This saving operator's network is possible because the
   abstract links are formulated on behalf of the server layer by built from a
   central management agency that is aware of all mesh of the link
   abstractions being offered.

   It may be noted that a less optimal alternative path for the abstract
   link S1-S9 exists such
   domains, D1 through D7, as shown in the server layer (S1-S4-S7-S8-S9). Figure 20.  It is would
   be possible for the client layer request for connectivity C2-C0 that

           ------     ------     ------     ------
          |      |   |      |   |      |   |      |
          |  D1  |---|  D2  |---|  D3  |---|  D4  |
          |      |   |      |   |      |   |      |
           ------\    ------\    ------\    ------
                  \    |     \     |    \     |
                   \------    \------    \------
                   |      |   |      |   |      |
                   |  D5  |---|  D6  |---|  D7  |
                   |      |   |      |   |      |
                    ------     ------     ------

       Figure 20 : A Simple Optical Domain

   these domains share a single, common instance of OSPF in which case
   there is nothing further to
   ask say because that OSPF instance will
   distribute sufficient information to build a single TED spanning the
   whole network, and an end-to-end path be maximally disjoint from the path C2-C3.  While
   nothing can be done about computed.  A more likely
   scenario is that each domain is running its own OSPF instance.  In
   this case, each is able to handle the shared link C2-S1, peculiarities (or rather,
   advanced functions) of each vendor's equipment capabilities.

   The question now is how to combine the abstraction
   layer could request that multiple sets of information
   distributed by the server layer instantiate different OSPF instances.  Three possible models
   suggest themselves based on pre-existing routing practices.

   o In the link S1-S9
   to first model (the Area-Based model) each domain is treated as
     a separate OSPF area.  The end-to-end path will be diverse from the link S1-S3, specified to
     traverse multiple areas, and this request could each area will be honored
   if left to determine
     the server layer policy allows.

5.3.3.2  Mutual Exclusivity

   As noted path across the nodes in the discussion area.  The feasibility of Figure 14, it is possible that some
   abstraction layer links can not be realized and/or used at the same
   time.  This arises when an end-
     to-end path (and, thus, the potentiality selection of the links is indicated by
   the server layer, but the realization sequence of the links by LSPs in the
   server layer network would actually compete for server layer
   resources.  In Figure 14 this arose when both link S1-S3 areas and link
   S7-S9 were realized as links carrying abstraction layer LSPs: in that
   case the link S1-S9 could no longer be used.

   Such a situation need not
     their interconnections) can be an issue when abstraction layer LSPs are
   set up one by one because the derived using hierarchical PCE.

     This approach, however, fits poorly with established use of one abstraction layer link and
   th corresponding use the
     OSPF area: in this form of server layer resources will cause optical network, the server
   layer interconnection
     points between domains are likely to withdraw be links; and the availability mesh of the other abstraction layer
   links,
     domains is far more interconnected and these will become unavailable for further abstraction
   layer path computations.

   Furthermore, in deployments where abstraction layer links unstructured than we are only
   presented as available after server layer LSPs have been established
     used to support them, the problem is unlikely exist.

   However, when seeing in the server layer is constrained, but chooses normal area-based routing paradigm.

     Furthermore, while hierarchical PCE may be able to
   advertise the potential solve this type
     of multiple abstraction layer links even
   though they compete for resources, and when multiple abstraction
   layer LSPs are computed simultaneously (perhaps to provide protection
   services, there network, the effort involved may be contention considerable for server layer resources.  In the
   case that protected abstraction layer LSPs are being established,
   this situation would more than a
     small collection of domains.

   o Another approach (the AS-Based model) treats each domain as a
     separate Autonomous System (AS).  The end-to-end path will be avoided through
     specified to traverse multiple ASes, and each AS will be left to
     determine the use path across the AS.

     This model sits more comfortably with the established routing
     paradigm, but causes a massive escalation of SRLGs and/or
   MSRLGs since ASes in the two abstraction layer links that compete for server
   layer resources must also fate share across those resources.  But global
     Internet.  It would, in practice, require that the case where operator used
     private AS numbers [RFC6996] of which there are plenty.

     Then, as suggested in the multiple abstraction layer LSPs do not care about
   fate sharing, it may Area-Based model, hierarchical PCE
     could be necessary used to flag the mutually exclusive
   links in determine the abstraction layer TED so that feasibility of an end-to-end path computation can avoid
   accidentally attempting
     and to utilize two of a set derive the sequence of such links at domains and the
   same time.

5.3.3.3  A Server with Multiple Clients

   A single server network may support multiple client networks.  This
   is not an uncommon state points of affairs for example when
     interconnection to use.  But, just as in that other model, the server
   network provides connectivity for multiple customers.

   In
     scalability of this case, the abstraction provided by the server layer may vary
   considerably according to model using a hierarchical PCE must be
     questioned given the policies sheer number of ASes and commercial relationships
   with each customer.  This variance would lead to a separate
   abstraction layer network maintained to support each client network.

   On their
     interconnectivity.

     Furthermore, determining the other hand, it may be that multiple clients are subject to mesh of domains (i.e., the
   same policies and inter-AS
     connections) conventionally requires the abstraction can be identical.  In this case, a
   single abstraction layer network can support more than one client.

   The choices here are made use of BGP as an operational issue by inter-
     domain routing protocol.  However, not only is BGP not normally
     available on optical equipment, but this approach indicates that
     the server layer
   network.

5.3.3.4  A Client with Multiple Servers

   A single client network may be supported by multiple server networks.
   The server networks may provide connectivity between different parts TE properties of the client network or may provide parallel (redundant)
   connectivity inter-domain links would need to be
     distributed and updated using BGP: something for which it is not
     well suited.

   o The third approach (the ASON model) follows the client network. architectural
     model set out by the ITU-T [G.8080] and uses the routing protocol
     extensions described in [RFC6827].  In this case the abstraction layer network should contain model the
   abstract links from all server networks so that it can make suitable
   computations concept of
     "levels" is introduced to OSPF.  Referring back to Figure 20, each
     OSPF instance running in a domain would be construed as a "lower
     level" OSPF instance and create would leak routes into a "higher level"
     instance of the correct TE links in protocol that runs across the client whole network.
   That is,

     This approach handles the relationship between client network and abstraction
   layer awkwardness of representing the domains
     as areas or ASes by simply considering them as domains running
     distinct instances of OSPF.  Routing advertisements flow "upward"
     from the domains to the high level OSPF instance giving it a full
     view of the whole network should be one-to-one.

   Note that SRLGs and MSRLGs may allowing end-to-end paths to be very hard
     computed.  Routing advertisements may also flow "downward" from the
     network-wide OSPF instance to describe in any one domain so that it has
     visibility of the case connectivity of multiple server layer networks because the abstraction points will
   not know whether whole network.

     While architecturally satisfying, this model suffers from having to
     handle the resources in different characteristics of different equipment
     vendors.  The advertisements coming from each low level domain
     would be meaningless when distributed into the various server layers share
   physical locations.

5.3.4.  Abstraction in Peer Networks

   Peer networks exist in many situations in other domains, and
     the Internet.  Packet
   networks may peer as IGP areas (levels) or as ASes.  Transport
   networks (such as optical networks) may peer high level domain would need to provide
   concatenations be kept up-to-date with the
     semantics of optical paths through single vendor environments
   (see Section 7).  Figure 16 shows each new release of each vendor's equipment.
     Additionally, the scaling issues associated with a simple example well-meshed
     network of three peer
   networks (A, B, domains each with many entry and exit points and C) each comprising a few nodes.

            Network A    :     Network B      :   Network C
                         :                    :
      --     --      --  :  --     --     --  :  --     --
     |A1|---|A2|----|A3|---|B1|---|B2----|B3|---|C1|---|C2|
      --     --\    /--  :  --    /--\    --  :  --     --
                \--/     :       /    \       :
                |A4|     :      /      \      :
                 --\     :     /        \     :
              --    \--  :  --/          \--  :  --     --
             |A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
              --     --  :  --            --  :  --     --
                         :                    :
                         :                    :

       Figure 16 : A Network Comprising Three Peer Networks

   As discussed
     with network resources that are continually being updated reduces
     to the same problem as noted in Section 2, peered networks do the virtual link model.
     Furthermore, in the event that the domains are under control of
     different administrations, the domains would not share visibility want to distribute
     the details of their topologies or TE capabilities for scaling and confidentiality
   reasons.  That means, in our example, that computing a path from A1 TE resources.

   Practically, this third model turns out to C4 can be impossible without the aid of cooperating PCEs or some
   form of crankback.

   But it is possible very close to produce abstract links for the reachability
   across transit peer networks and instantiate an abstraction layer
   network.  That network
   methodology described in this document.  As noted in Section 6.1 of
   [RFC6827], there are policy rules that can be enhanced with specific reachability applied to define
   exactly what information if a destination network is partitioned as is the case
   with Network C in Figure 16.

   Suppose Network B decides exported from or imported to offer three abstract links B1-B3, B4-B3,
   and B4-B6. a low level
   OSPF instance.  The abstraction layer network could then document even notes that some forms of
   aggregation may be constructed appropriate.  Thus, we can apply the following
   simplifications to look like the network mechanisms defined in Figure 17.

                     --     --      --      --
                    |A3|---|B1|====|B3|----|C1|
                     --     --    //--      --
                                 //
                                //
                               //
                     --     --//     --     --
                    |A6|---|B4|=====|B6|---|C3|
                     --     --       --     --

     Figure 17 : Abstraction Layer Network for the Peer Network Example

   Using a process similar RFC 6827:

   - Zero information is imported to that described low level domains.

   - Low level domains export only abstracted links as defined in Section 5.3.3, Network A
   can request connectivity this
     document and according to Network C local abstraction policy and the abstract with
     appropriate removal of vendor-specific information.

   - There is no need to formally define routing levels within OSPF.

   - Export of abstracted links can be
   instantiated as tunnels across from the transit network, and edge-to-edge
   LSPs domains to the network-wide
     routing instance (the abstraction routing layer) can take place
     through any mechanism including BGP-LS or direct interaction
     between OSPF implementations.

   With these simplifications, it can be set up to join seen that the two networks.  Furthermore, if Network
   C is partitioned, reachability information framework defined
   in this document can be exchanged to allow
   Network A to select constructed from the correct edge-to-edge LSP architecture discussed
   in RFC 6827, but without needing any of the protocol extensions that
   that document defines.  Thus, using the terminology and concepts
   already established, the problem may solved as shown in Figure
   18.

                    Network A       :      Network C
                                    :
              --     --      --     :     --       --
             |A1|---|A2|----|A3|=========|C1|.....|C2|
              --     --\    /--     :     --       --
                        \--/        :
                        |A4|        :
                         --\        :
                      --    \--     : 21.
   The abstraction layer network is constructed from the inter-domain
   links, the domain border nodes, and the abstracted (cross-domain)
   links.

                                                       Abstraction Layer
      --             --
                     |A5|---|A6|=========|C3|.....|C4|    --             --     :    --             --
     |  |===========|  |--|  |===========|  |--|  |===========|  |
     |  |           |  |  |  |           |  |  |  |           |  |
   ..|  |...........|  |..|  |...........|  |..|  |...........|  |......
     |  |           |  |  |  |           |  |  |  |           |  |
     |  |  --   --  |  |  |  |  --   --  |  |  |  |  --   --  |  |
     |  |_|  |_|  |_|  |  |  |_|  |_|  |_|  |  |  |_|  |_|  |_|  |
     |  | |  | |  | |  |  |  | |  | |  | |  |  |  | |  | |  | |  |
      --   --   --   --    --   --   --   --    --   --   --   --
          Domain 1             Domain 2             Domain 3
     Key                                                   Optical Layer
       ...  Layer separation
       ---  Physical link
       ===  Abstract link

         Figure 18 : Tunnel Connections to Network C with TE Reachability

   Peer networking cases can be made far more complex by dual homing
   between network peering nodes (for example, A3 might connect to B1
   and B4 in Figure 17) and by 21 : The Optical Network Implemented Through the networks themselves being arranged
                       Abstraction Layer Network

7.  Modeling the User-to-Network Interface

   The User-to-Network Interface (UNI) is an important architectural
   concept in
   a mesh (for example, A6 might connect to B4 many implementations and C1 in Figure 17).

   These additional complexities can be handled gracefully by the
   abstraction layer network model.

   Further examples deployments of abstraction in peer client-server
   networks especially those where the client and server network have
   different technologies.  The UNI can be found seen described in
   Sections 7 [G.8080],
   and 9.

5.4.  Considerations for Dynamic Abstraction

   It is possible the GMPLS approach to consider a highly dynamic system where the server
   network adaptively suggests new abstract links into the abstraction
   layer, and where the abstraction layer proactively deploys new LSPs
   to provide new connections UNI is documented in [RFC4208].  Other
   GMPLS-related documents describe the client network.  Such fluidity is,
   however, to be treated with caution because of the longer turn-up
   times application of connections in server networks, because the server networks
   are likely to be sparsely connected and expensive physical resources
   will only be deployed where there is believed GMPLS to be a need specific
   UNI scenarios: for them,
   and because example, [RFC6005] describes how GMPLS can support
   a UNI that provides access to Ethernet services.

   Figure 1 of [RFC6005] is reproduced here as Figure 22.  It shows the complex commercial or administrative relationships
   Ethernet UNI reference model, and that may exist figure can serve as an example
   for all similar UNIs.  In this case, the UNI is an interface between
   client network edge nodes and the server network.  It should be noted
   that neither the client network operators.

   Thus, proposals for fully automated multi-layer networks based on
   this architecture may nor the server network need be regarded as forward-looking topics for
   research both in terms of an
   Ethernet switching network.

   There are three network stability layers in this model: the client network, the
   "Ethernet service network", and with regard to
   eccomonic impact.

   However, some elements of automation should not be discarded.  A the server network.  The so-called
   Ethernet service network may automatically apply policy to determine the best
   set consists of abstract links to offer comprising the UNI links
   and the most suitable tunnels across the server network
   LSPs to realize those links.  And a network, and nodes comprising the
   client network may dynamically
   observe congestion, lack of connectivity, or predicted changes in
   traffic demand, edge nodes and may use this information to request additional
   links from the abstraction layer.  And, once policies have been
   configured, the whole system should be able to operate autonomous of
   operator control (which is not to say that the operator will not have
   the option of exerting control at every step in various server nodes.  That is, the process).

   But it
   Ethernet service network is important, in this discussion, equivalent to rule out most processes
   of dynamic abstraction.  As the available resources in the server
   layer fluctuate because of newly provisioned server abstraction layer LSPs or due
   to failed resources, it would significantly destabilize the system to
   continually update the advertised abstract links.  Thus, and
   notwithstanding the discussion of mutually exclusive links in Section
   5.3.3.2, a server network will mainly plan and advertise abstract
   links that are stable in the event of establishment of other abstract
   links.

   As an example of this last point, consider two abstract links that
   can be realized by a pair of server network LSPs that share a single
   server
   network link at some point in their paths.  Those abstract
   links could be advertised each with the full capacity of the server
   network link.  But if this were done, then the establishment of one
   abstract link would immediately preclude the other causing some small
   degree of flap in the abstraction layer network topology.  A server
   network might instead choose to split UNI links being the shared resources physical links between the two
   client and server network LSPs networks, and so make the abstraction layer network
   stable.  This ability is, of course, highly dependent on the network
   technology in client edge nodes taking the server network.

5.5.  Requirements for Advertising Links and Nodes

   The abstraction layer network is "just another network layer".  The
   links

        Client                                            Client
        Network       +----------+    +-----------+       Network
   -------------+     |          |    |           |     +-------------
         +----+ |     |  +-----+ |    |  +-----+  |     | +----+
   ------+    | |     |  |     | |    |  |     |  |     | |    +------
   ------+ EN +-+-----+--+ CN  +-+----+--+  CN +--+-----+-+ EN +------
         |    | |  +--+--|     +-+-+  |  |     +--+-----+-+    |
         +----+ |  |  |  +--+--+ | |  |  +--+--+  |     | +----+
                |  |  |     |    | |  |     |     |     |
   -------------+  |  |     |    | |  |     |     |     +-------------
                   |  |     |    | |  |     |     |
   -------------+  |  |     |    | |  |     |     |     +-------------
                |  |  |  +--+--+ | |  |  +--+--+  |     |
         +----+ |  |  |  |     | | +--+--+     |  |     | +----+
   ------+    +-+--+  |  | CN  +-+----+--+ CN  |  |     | |    +------
   ------+ EN +-+-----+--+     | |    |  |     +--+-----+-+ EN +------
         |    | |     |  +-----+ |    |  +-----+  |     | |    |
         +----+ |     |          |    |           |     | +----+
                |     +----------+    |-----------+     |
   -------------+           Server Network(s)           +-------------
        Client    UNI                               UNI   Client
        Network <----->                           <-----> Network
                          Scope of This Document

                        Legend:   EN  -  Client Edge Node
                                  CN  -  Server Node

                  Figure 22 : Ethernet UNI Reference Model

   role of UNI Client-side (UNI-C) and the server edge nodes in acting as
   the network need to be advertised along with their
   associated TE information (metrics, bandwidth, etc.) so UNI Network-side (UNI-N) nodes.

   An issue that the
   topology is disseminated and so that routing decisions can be made.

   This requires often raised concerns how a routing protocol running between dual-homed client edge
   node (such as that shown at the nodes in bottom left-hand corner of Figure 22)
   can make determinations about how they connect across the
   abstraction layer network.  Note that this routing information
   exchange could UNI.  This
   can be piggy-backed on an existing routing protocol
   instance, or use a new instance (or even a new protocol).  Clearly, particularly important when reachability across the information exchanged server
   network is only that which has been created as
   part of the abstraction function according limited or when two diverse paths are desired (for
   example, to policy.

   It should be noted that provide protection).  However, in some cases abstract link enablement is on-
   demand and all that is advertised the model described in
   this network, the topology for edge node (the UNI-C) is part of the abstraction
   layer network is the potential for an abstract link to be set up.  In
   this case we may ponder how the routing protocol will advertise and can see sufficient topology information over a link that is not yet established.  In
   other words, there must be a communication channel between the
   participating nodes so that to make
   these decisions.  If the routing protocol messages can flow.
   The answer is that control plane connectivity exists approach introduced in the server
   network and on the client-server edge links, and this can be document is used
   to
   carry the routing protocol messages for model the abstraction layer
   network.  The same consideration applies UNI as described in this section, there is no need to
   enhance the advertisement, in signaling protocols at the
   client network of GMPLS UNI nor to add routing
   exchanges at the potential connectivity UNI.

8.  Abstraction in L3VPN Multi-AS Environments

   Serving layer-3 VPNs (L3PVNs) across a multi-AS or multi-operator
   environment currently provides a significant planning challenge.
   Figure 6 shows the general case of the problem that needs to be
   solved.  This section shows how the abstraction layer network can provide.

5.6.  Addressing Considerations

   The network layers in this architecture should be able to operate
   with separate address spaces and these may overlap without any
   technical issues.  That is, one
   address may mean one thing in this problem.

   In the VPN architecture, the CE nodes are the client network, yet network edge
   nodes, and the same address may have a different meaning in PE nodes are the server network edge nodes.  The
   abstraction layer network or the server network.  In other words
   there is complete address separation between networks.

   However, this will require some care both because human operators may
   well become confused, and because mapping between address spaces is
   needed at made up of the interfaces between CE nodes, the network layers.  That mapping
   requires configuration so that, for example, when CE-PE
   links, the PE nodes, and PE-PE tunnels that are the server network
   announces an abstract link from A to B, links.

   In the multi-AS or multi-operator case, the abstraction layer network
   must recognize that A and B are
   also includes the PEs (maybe ASBRs) at the edges of the multiple
   server network addresses networks, and must map
   them the PE-PE (maybe inter-AS) links.  This gives
   rise to abstraction layer addresses (say P and Q) before including the link architecture shown in its own topology.  And similarly, when Figure 23.

   The policy for adding abstract links to the abstraction layer network informs
   will be driven substantially by the client network that needs of the VPN.  Thus, when a
   new link VPN site is available
   from S to T, it must map those addresses from its own address space
   to that added and the existing abstraction layer network
   cannot support the required connectivity, a new abstract link will be
   created out of the client underlying network.

   This form of address mapping will become particularly

   It is important in
   cases where one to note that each VPN instance can have a separate
   abstraction layer network.  This means that the server network is constructed
   resources can be partitioned and that traffic can be kept separate.
   This can be achieved even when VPN sites from
   connectivity in different VPNs connect
   at the same PE.  Alternatively, multiple server layer networks, or where one VPNs can share the same
   abstraction layer network provides connectivity for multiple client
   networks.

6.  Building on Existing Protocols

   This section is not intended to prejudge a solutions framework or any
   applicability work.  It does, however, very briefly serve to note the
   existence of protocols if that could be examined is operationally preferable.

   Lastly, just as for applicability to
   serve in realizing the model described UNI discussed in this document.

   The general principle of protocol re-use is preferred over Section 7, the
   invention issue of new protocols or additional protocol extensions as
   mentioned in Section 3.1.

6.1.  BGP-LS

   BGP-LS is a set
   dual-homing of extensions to BGP described in
   [I-D.ietf-idr-ls-distribution].  It's purpose VPN sites is to announce topology
   information from one network to a "north-bound" consumer.
   Application function of BGP-LS to date has focused on a mechanism to build a
   TED for the abstraction layer
   network and so is just a PCE.  However, BGP's mechanisms would also serve well to
   advertise abstract links from normal routing problem in that network.

   ...........                                     .............
    VPN Site :                                     : VPN Site
    --   --  :                                     :  --   --
   |C1|-|CE| :                                     : |CE|-|C2|
    --  |  | :                                     : |  |  --
        |  | :                                     : |  |
        |  | :                                     : |  |
        |  | :                                     : |  |
        |  | :   --           --     --       --   : |  |
        |  |----|PE|=========|PE|---|PE|=====|PE|----|  |
         --  :  |  |         |  |   |  |     |  |  :  --
   ...........  |  |         |  |   |  |     |  |  ............
                |  |         |  |   |  |     |  |
                |  |         |  |   |  |     |  |
                |  |         |  |   |  |     |  |
                |  |  -   -  |  |   |  |  -  |  |
                |  |-|P|-|P|-|  |   |  |-|P|-|  |
                 --   -   -   --     --   -   --

      Figure 23 : The Abstraction Layer Network for a server network into the abstraction
   layer network, or to advertise potential connectivity from the
   abstraction layer network Multi-AS VPN

9.  Scoping Future Work

   The section is provided to help guide the client network.

6.2.  IGPs

   Both OSPF work on this problem and IS-IS have been extended through a number of RFCs to
   advertise TE information.  Additionally, both protocols
   ensure that oceans are capable not knowingly boiled.

9.1.  Not Solving the Internet

   The scope of running in a multi-instance mode either as ships that pass the use cases and problem statement in this document is
   limited to "some small set of interconnected domains."  In
   particular, it is not the
   night (i.e., completely separate instances using different address)
   or as dual instances on objective of this work to turn the same address space.  This means that
   either IGP could probably be used as whole
   Internet into one large, interconnected TE network.

9.2.  Working With "Related" Domains

   Subsequent to Section 9.1, the routing protocol in intention of this work is to solve
   the
   abstraction layer network.

6.3.  RSVP-TE

   RSVP-TE signaling can TE interconnectivity for only "related" domains.  Such domains
   may be used under common administrative operation (such as IGP areas
   within a single AS, or ASes belonging to set up traffic engineered LSPs a single operator), or may
   have a direct commercial arrangement for the sharing of TE
   information to
   serve as hierarchical LSPs provide specific services.  Thus, in the core network providing abstract
   links both cases, there
   is a strong opportunity for the abstraction layer network as application of policy.

9.3.  Not Finding Optimal Paths in All Situations

  As has been well described in [RFC4206].
   Similarly, the CE-to-CE LSP tunnel across the this document, abstraction layer
   network can be established using RSVP-TE without any protocol
   extensions.

   Furthermore, the procedures in [RFC6107] allow the dynamic signaling
   of the purpose necessarily
  involves compromises and removal of any LSP that is established.  This information.  That means that
   when an LSP tunnel is set up, the two ends can coordinate into which
   routing protocol instance it should be advertised, and can also agree
   on the addressing to be said
  is not possible to identify the link guarantee that will be
   created.

6.4.  Notes on a Solution an end-to-end path over
  interconnected TE domains follows the absolute optimal (by any measure
  of optimality) path.  This section is taken as understood, and future work
  should not intended attempt to achieve such paths which can only be proscriptive or dictate the
   protocol solutions that may be used to satisfy found by a
  full examination of all network information across all connected
  networks.

9.4.  Sanity and Scaling

   All of the architecture above points play into a final observation.  This work is
   intended to bite off a small problem for some relatively simple use
   cases as described in Section 2.  It is not intended that this document, but it does show how the existing
   protocols listed in the previous sections can work
   will be combined immediately (or even soon) extended to provide
   a cover many large
   interconnected domains.  Obviously the solution with only minor modifications.

   A server network can should as far as
   possible be operated using GMPLS routing designed to be extensible and signaling
   protocols.  Using information gathered from the routing protocol, scalable, however, it is
   also reasonable to make trade-offs in favor of utility and
   simplicity.

10.  Manageability Considerations

   Manageability should not be a
   TED significant additional burden.  Each
   layer in the network model can and should be constructed containing resource availability information managed independently.

   That is, each client network will run its own management systems and SRLG details.  A policy-based process can then determine which
   tools to manage the nodes and abstract links it wishes to advertise to form in the client network: each
   client network link that uses an abstract
   layer network.

   The link will still be
   available for management in the client network as any other link.

   Similarly, each server network can now use BGP-LS to advertise a topology of
   links will run its own management systems
   and nodes tools to form manage the abstraction layer network.  This
   information would most likely be advertised from a single point of
   control nodes and links in that made all of network just as
   normal.

   Three issues remain for consideration:

   - How is the abstraction decisions, but layer network managed?
   - How is the function
   could be distributed to multiple server interface between the client network edge nodes.  The
   information can be advertised by BGP-LS to multiple points within and the abstraction
     layer (such as all client network edge nodes) or to a
   single controller.

   Multiple server networks may advertise information that managed?
   - How is used to
   construct an the interface between the abstraction layer network, network and one the
     server network may
   advertise different information in different instances managed?

10.1.  Managing the Abstraction Layer Network

   Management of BGP-LS to
   form different the abstraction layer networks.  Furthermore, in network differs from the case client
   and server networks because not all of one controller constructing multiple abstraction layer networks,
   BGP-LS uses the route target mechanism defined links that are visible in [RFC4364]
   the TED are real links.  That is, it is not possible to
   distinguish run OAM on
   the different applications (effectively abstraction layer
   network VPNs) links that constitute the potential of a link.

   Other than that, however, the exported information.

   Extensions may management should be made to BGP-LS to allow advertisement of MSLRGs,
   mutually exclusive links, essentially the
   same.  Routing and to indicate whether signaling protocols can be run in the abstract link
   has been pre-established or not.

   The abstraction
   layer network may operate under central control or
   use a distributed control plane.  Since the (using out of band channels for links that have not yet been
   established), and nodes may be a
   mix of physical centralized TED can be constructed and abstract links, and since used to
   examine the nodes may have
   diverse cross-connect capabilities, it is most likely that a GMPLS
   routing protocol will be beneficial for collecting availability and correlating status of the routing information links and for distributing updates.  No special
   additional features are needed beyond adding those extra parameters
   just described for BGP-LS, but it should be noted nodes in the
   network.

   Note that different deployment models will place the control
   plane "ownership" of
   the abstraction layer network must run in an out of band
   control network because differently.  In some case the data-bearing links might not yet have
   been established via connections in the server layer network.

   The
   abstraction layer network is also able to determine potential
   connectivity from client network edge to client network edge.  It will determine which client network links to create according to
   policy and subject to requests from be constructed by the client network, operator of the
   server layer and will
   take four steps:

   - First it will compute run by that operator as a path service for one or more
   client networks.  In other cases, one or more server networks will
   present the potential of links to an abstraction layer LSP that
     will realize network run
   by the link for operator of the client network.
   - First  And it will request the server layer network to realize any
     abstraction layer links that the LSP traverses and is feasible that are not
     yet enabled.
   - Then, once those links have been realized, it will signal the
     abstraction layer LSP.
   - Finally, a
   business model could be built where a third-party operator manages
   the abstraction layer network will inform network, constructing it from the connectivity
   available in multiple server networks, and facilitating connectivity
   for multiple client
     network of the existence networks.

10.2.  Managing Interactions of Client and Abstraction Layer Networks

   The interaction between the new client network link.

   This last step can be achieved either by coordination of the end
   points of and the abstraction layer LSP (these points are client
   network
   edge nodes) using mechanisms such as those described in [RFC6107], is a management task.  It might be automated (software
   driven) or using BGP-LS from it might require manual intervention.

   This is a central controller.

   Once the two-way interaction:

   - The client network edge nodes are aware of a new link, they will
   automatically advertise it their routing protocol and it will become
   available can express the need for use by traffic in additional
     connectivity.  For example, the client network.

   Sections 7, 8, layer may try and 9 discuss the applicability of this architecture fail to different
     find a path across the client network types and problem spaces, while Section 10 gives
   some advice about scoping future work.  Section 11 on manageability
   considerations may request additional,
     specific connectivity (this is particularly relevant in similar to the context of this
   section because it contains situation with
     Virtual Network Topology Manager (VNTM) [RFC5623]).  Alternatively,
     a discussion of the policies more proactive client layer management system may monitor traffic
     demands (current and
   mechanisms for indicating connectivity predicted), network usage, and link availability between network layers in this architecture.

7. Applicability to Optical Domains "hot
     spots" and Networks

   Many optical networks are arranged a set of small domains. Each
   domain is a cluster of nodes, usually from the same equipment vendor may request changes in connectivity by both releasing
     unused links and with the same properties.  The domain may be constructed as a
   mesh or a ring, or maybe as an interconnected set of rings. by requesting new links.

   - The abstraction layer network operator seeks can make links available to provide end-to-end connectivity across
   a the
     client network constructed or can withdraw them.  These actions can be in
     response to requests from multiple domains, and so (of course) the
   domains are interconnected.  In a network under management control
   such as through an Operations Support System (OSS), each domain is
   under client layer, or can be driven by
     processes within the operational control abstraction layer (perhaps reorganizing the
     use of a Network Management System (NMS). server layer resources).  In any case, the presentation of
     new links to the client layer is heavily subject to policy since
     this way, an end-to-end path may be commissioned by is both operationally key to the OSS
   instructing each NMS, success of this architecture
     and the NMSes setting up the path fragments
   across central plank of the domains.

   However, commercial model described in a system that uses a control plane, there is a need for
   integration between this
     document.  Such policies belong to the domains.

   Consider operator of the abstraction
     layer network and are expected to be fully configurable.

     Once the abstraction layer network has decided to make a simple domain, D1, as shown in Figure 19.  In this case, link
     available to the nodes A through F client network it will install it at the link end
     points (which are arranged nodes in a topological ring. Suppose the client network) such that there is a control plane in use in this domain, it appears
     and that OSPF is
   used can be advertised as a link in the TE routing protocol.

             -----------------
            |              D1 |
            |      B---C      |
            |     /     \     |
            |    /       \    |
            |   A         D   |
            |    \       /    |
            |     \     /     |
            |      F---E      |
            |                 |
             -----------------

       Figure 19 : A Simple Optical Domain

   Now consider client network.

   In all cases, it is important that the operator's network is built from a mesh operators of such
   domains, D1 through D7, as shown both networks are
   able to track the requests and responses, and the operator of the
   client network should be able to see which links in Figure 20.  It is possible that
   these domains share a single, common instance network are
   "real" physical links, and which are presented by the abstraction
   layer network.

10.3.  Managing Interactions of OSPF Abstraction Layer and Server Networks

   The interactions between the abstraction layer network and the server
   network a similar to those described in which case Section 10.2, but there is nothing further to say because that OSPF instance will
   distribute sufficient information to build a single TED spanning
   difference in that the
   whole network, and an end-to-end path can be computed.  A server layer is more likely
   scenario is that each domain is running its own OSPF instance.  In
   this case, each to offer up
   connectivity, and the abstraction layer network is able less likely to handle ask
   for it.

   That is, the peculiarities (or rather,
   advanced functions) server network will, according to policy that may
   include commercial relationships, offer the abstraction layer network
   a set of each vendor's equipment capabilities.

           ------     ------     ------     ------
          |      |   |      |   |      |   |      |
          |  D1  |---|  D2  |---|  D3  |---|  D4  |
          |      |   |      |   |      |   |      |
           ------\    ------\    ------\    ------
                  \    |     \     |    \     |
                   \------    \------    \------
                   |      |   |      |   |      |
                   |  D5  |---|  D6  |---|  D7  |
                   |      |   |      |   |      |
                    ------     ------     ------

       Figure 20 : A Simple Optical Domain

   The question now is potential connectivity that the abstraction layer network
   can treat as links.  This server network policy will include:
   - how much connectivity to combine offer
   - what level of server layer redundancy to include
   - how to support the multiple sets use of information
   distributed by the different OSPF instances.  Three possible models
   suggest themselves based on pre-existing routing practices.

   o In abstraction links,

   This process of offering links from the first model (the Area-Based model) each domain is treated as server network may include a separate OSPF area.  The end-to-end path will be specified
   mechanism to
     traverse multiple areas, indicate which links have been pre-established in the
   server network, and each area will be left can include other properties such as:
   - link-level protection ([RFC4202])
   - SRLG and MSRLG (see Appendix A)
   - mutual exclusivity (see Appendix B).

   The abstraction layer network needs a mechanism to determine tell the path across server
   This mechanism could also include the nodes in ability to request additional
   connectivity from the area.  The feasibility server layer, although it seems most likely
   that the server layer will already have presented as much
   connectivity as it is physically capable of an end-
     to-end path (and, thus, subject to the selection
   constraints of policy.

   Finally, the sequence of areas and
     their interconnections) can be derived using hierarchical PCE.

     This approach, however, fits poorly with established use server layer will need to confirm the establishment of
   connectivity, withdraw links if they are no longer feasible, and
   report failures.

   Again, it is important that the
     OSPF area: in this form operators of optical network, the interconnection
     points between domains both networks are likely able
   to be links; track the requests and responses, and the mesh operator of
     domains is far more interconnected and unstructured than we are
     used to seeing in the normal area-based routing paradigm.

     Furthermore, while hierarchical PCE may server
   network should be able to solve see which links are in use.

11.  IANA Considerations

   This document makes no requests for IANA action.  The RFC Editor may
   safely remove this type section.

12.  Security Considerations

   Security of network, signaling and routing protocols is usually administered
   and achieved within the effort involved may be considerable boundaries of a domain.  Thus, and for more than
   example, a
     small collection of domains.

   o Another approach (the AS-Based model) treats each domain as with a
     separate Autonomous System (AS).  The end-to-end path will be
     specified to traverse multiple ASes, GMPLS control plane [RFC3945] would apply
   the security mechanisms and each AS will be left considerations that are appropriate to
     determine the path across the AS.

     This model sits more comfortably with
   GMPLS [RFC5920].  Furthermore, domain-based security relies strongly
   on ensuring that control plane messages are not allowed to enter the established routing
     paradigm, but causes a massive escalation of ASes in
   domain from outside.  Thus, the global
     Internet.  It would, mechanisms in practice, require that the operator used
     private AS numbers [RFC6996] this document for
   inter-domain exchange of which there are plenty.

     Then, as suggested in control plane messages and information
   naturally raise additional questions of security.

   In this context, additional security considerations arising from this
   document relate to the Area-Based model, hierarchical PCE
     could be used exchange of control plane information between
   domains.  Messages are passed between domains using control plane
   protocols operating between peers that have predictable relationships
   (for example, UNI-C to determine UNI-N, between BGP-LS speakers, or between
   peer domains).  Thus, the feasibility security that needs to be given additional
   attention for inter-domain TE concentrates on authentication of an end-to-end path
   peers, assertion that messages have not been tampered with, and to derive a
   lesser extent protecting the sequence content of domains the messages from inspection
   since that might give away sensitive information about the networks.
   The protocols described in Appendix A and which are likely to provide
   the points of
     interconnection foundation to use.  But, just solutions to this architecture already include
   such protection and further can be run over protected transports
   such as in IPsec [RFC6701], TLS [RFC5246], and the TCP Authentication
   Option (TCP-AO) [RFC5925].

   It is worth noting that other model, the
     scalability control plane of the hierarchical PCE approach must abstraction layer
   network is likely to be questioned.

     Furthermore, determining the mesh out of domains (i.e., band.  That is, control plane messages
   will be exchanged over network links that are not the inter-AS
     connections) conventionally requires links to which
   they apply.  This models the use facilities of BGP as an inter-
     domain routing protocol.  However, not only is BGP GMPLS (but not normally
     available on optical equipment, but this approach indicates that
     the TE properties of MPLS-TE)
   and the inter-domain links would need to security mechanisms can be
     distributed and updated using BGP: something for which it is not
     well suited.

   o The third approach (the ASON model) follows the architectural
     model set out by the ITU-T [G.8080] and uses applied to the routing protocol
     extensions described protocols operating
   in [RFC6827].  In this model the concept out of
     "levels" is introduced to OSPF.  Referring back band network.

13.  Acknowledgements

   Thanks to Figure 20, each
     OSPF instance running Igor Bryskin for useful discussions in a domain would be construed as a "lower
     level" OSPF instance and would leak routes into a "higher level"
     instance of the protocol that runs across the whole network.

     This approach handles the awkwardness of representing the domains
     as areas or ASes by simply considering them as domains running
     distinct instances early stages of OSPF.  Routing advertisements flow "upward"
     from the domains
   this work.

   Thanks to Gert Grammel for discussions on the high level OSPF instance giving it a full
     view extent of the whole network aggregation
   in abstract nodes and allowing end-to-end paths links.

   Thanks to be
     computed.  Routing advertisements may also flow "downward" from the
     network-wide OSPF instance Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam
   Somasundaram, and Hannes Gredler for review and input.

   Particular thanks to any one domain so Vishnu Pavan Beeram for detailed discussions and
   white-board scribbling that it has
     visibility of the connectivity made many of the whole network.

     While architecturally satisfying, ideas in this model suffers from having document
   come to
     handle the different characteristics of different equipment
     vendors.  The advertisements coming life.

   Text in Section 4.2.3 is freely adapted from each low level domain
     would be meaningless when distributed into the other domains, and the high level domain would need to be kept up-to-date with the
     semantics of each new release of each vendor's equipment.
     Additionally, the scaling issues associated with a well-meshed
     network work of domains each with many entry and exit points Igor
   Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel,
   Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria,
   Oscar Gonzalez de Dios, and each
     with network resources that are continually being updated reduces
     to the same problem as noted in the virtual link model.
     Furthermore, Daniele Ceccarelli in
   [I-D.beeram-ccamp-gmpls-enni] for which the event that the domains are under control of
     different administrations, the domains would not want to distribute
     the details authors of their topologies and TE resources.

   Practically, this third model turns out to be very close to the
   methodology described in this document.  As noted in Section 7.1 of
   [RFC6827], there are policy rules that can be applied to define
   exactly what information is exported from or imported to a low level
   OSPF instance.  The document even notes that some forms of
   aggregation may be appropriate.  Thus, we can apply
   express their thanks.

14.  References

14.1.  Informative References

   [G.8080]  ITU-T, "Architecture for the following
   simplifications to automatically switched optical
             network (ASON)", Recommendation G.8080.

   [I-D.beeram-ccamp-gmpls-enni]
             Bryskin, I., Beeram, V. P.,  Drake, J. et al., "Generalized
             Multiprotocol Label Switching (GMPLS) External Network
             Network Interface (E-NNI): Virtual Link Enhancements for
             the mechanisms defined in RFC 6827:

   - Zero information is imported to low level domains.

   - Low level domains export only abstracted links as defined Overlay Model", draft-beeram-ccamp-gmpls-enni, work in this
     document
             progress.

   [I-D.ietf-ccamp-rsvp-te-srlg-collect]
             Zhang, F. (Ed.) and according to local abstraction policy O. Gonzalez de Dios (Ed.), "RSVP-TE
             Extensions for Collecting SRLG Information", draft-ietf-
             ccamp-rsvp-te-srlg-collect, work in progress.

   [I-D.ietf-idr-ls-distribution]
             Gredler, H., Medved, J., Previdi, S., Farrel, A., and with
     appropriate removal Ray,
             S., "North-Bound Distribution of vendor-specific information.

   - There is no need Link-State and TE
             Information using BGP", draft-ietf-idr-ls-distribution,
             work in progress.

   [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
             McManus, J., "Requirements for Traffic Engineering Over
             MPLS", RFC 2702, September 1999.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to formally define routing levels within OSPF.

   - Export of abstracted links from the domains RSVP for LSP
             Tunnels", RFC 3209, December 2001.

   [RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RC 3473, January 2003.

   [RFC3630] Katz, D., Kompella, and K., Yeung, D., "Traffic Engineering
             (TE) Extensions to the network-wide
     routing instance (the abstraction routing layer) can take place
     through any mechanism including BGP-LS or direct interaction
     between OSPF implementations.

   With these simplifications, it can be seen that the framework defined
   in this document can be constructed from the architecture discussed
   in Version 2", RFC 6827, but without needing any of the protocol extensions that
   that document defines.  Thus, using the terminology 3630, September
             2003.

   [RFC3945] Mannie, E., (Ed.), "Generalized Multi-Protocol Label
             Switching (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4105] Le Roux, J.-L., Vasseur, J.-P., and concepts
   already established, the problem may solved as shown Boyle, J.,
             "Requirements for Inter-Area MPLS Traffic Engineering",
             RFC 4105, June 2005.

   [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Figure 21.
   The abstraction layer network is constructed from the inter-domain
   links, the domain border nodes, and the abstracted (cross-domain)
   links.

                                                       Abstraction Layer
      --             --    --             --    --             --
     |  |===========|  |--|  |===========|  |--|  |===========|  |
     |  |           |  |  |  |           |  |  |  |           |  |
   ..|  |...........|  |..|  |...........|  |..|  |...........|  |......
     |  |           |  |  |  |           |  |  |  |           |  |
     |  |  --   --  |  |  |  |  --   --  |  |  |  |  --   --  |  |
     |  |_|  |_|  |_|  |  |  |_|  |_|  |_|  |  |  |_|  |_|  |_|  |
     |  | |  | |  | |  |  |  | |  | |  | |  |  |  | |  | |  | |  |
      --   --   --   --    --   --   --   --    --   --   --   --
          Domain 1             Domain 2             Domain 3
     Key                                                   Optical Layer
       ...  Layer separation
       ---  Physical link
       ===  Abstract link

         Figure 21 : The Optical Network Implemented Through the
                       Abstraction Layer Network

8.  Modeling the User-to-Network Interface

   The User-to-Network Interface (UNI) is an important architectural
   concept in many implementations and deployments Support
             of client-server
   networks especially those where the client Generalized Multi-Protocol Label Switching (GMPLS)",
             RFC 4202, October 2005.

   [RFC4206] Kompella, K. and server network have
   different technologies.  The UNI can be seen described in [G.8080], Y. Rekhter, "Label Switched Paths (LSP)
             Hierarchy with Generalized Multi-Protocol Label Switching
             (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
             "User-Network Interface (UNI): Resource ReserVation
             Protocol-Traffic Engineering (RSVP-TE) Support for the GMPLS approach to the UNI is documented in [RFC4208].  Other
   GMPLS-related documents describe the application of GMPLS to specific
   UNI scenarios: for example, [RFC6005] describes how GMPLS can support
   a UNI that provides access to Ethernet services.

   Figure 1 of [RFC6005] is reproduced here as Figure 22.  It shows the
   Ethernet UNI reference model,
             Overlay Model", RFC 4208, October 2005.

   [RFC4216] Zhang, R., and that figure can serve as an example
   for all similar UNIs.  In this case, the UNI is an interface between
   client network edge nodes Vasseur, J.-P., "MPLS Inter-Autonomous
             System (AS) Traffic Engineering (TE) Requirements",
             RFC 4216, November 2005.

   [RFC4271] Rekhter, Y., Li, T., and the server network.  It should be noted
   that neither the client network nor the server network need be an
   Ethernet switching network.

   There are three network layers in this model: the client network, the
   "Ethernet service network", Hares, S., "A Border Gateway
             Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4364] Rosen, E. and the server network.  The so-called
   Ethernet service network consists of links comprising the UNI links Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC 4364, February 2006.

   [RFC4655] Farrel, A., Vasseur, J., and the tunnels across the server network, J. Ash, "A Path Computation
             Element (PCE)-Based Architecture",  RFC 4655, August 2006.

   [RFC4726] Farrel, A., Vasseur, J.-P., and nodes comprising the
   client network edge nodes Ayyangar, A., "A Framework
             for Inter-Domain Multiprotocol Label Switching Traffic
             Engineering", RFC 4726, November 2006.

   [RFC4847] T. Takeda (Ed.), "Framework and various server nodes.  That is, the
   Ethernet service network is equivalent to the abstraction layer
   network with the UNI links being the physical links between the
   client and server networks, and the client edge nodes taking the
   role of UNI Client-side (UNI-C) Requirements for Layer 1
             Virtual Private Networks," RFC 4847, April 2007.

   [RFC4874] Lee, CY., Farrel, A., and the server edge nodes acting as
   the UNI Network-side (UNI-N) nodes.

        Client                                            Client
        Network       +----------+    +-----------+       Network
   -------------+     |          |    |           |     +-------------
         +----+ |     |  +-----+ |    |  +-----+  |     | +----+
   ------+    | |     |  |     | |    |  |     |  |     | |    +------
   ------+ EN +-+-----+--+ CN  +-+----+--+  CN +--+-----+-+ EN +------
         |    | |  +--+--|     +-+-+  |  |     +--+-----+-+    |
         +----+ |  |  |  +--+--+ | |  |  +--+--+  |     | +----+
                |  |  |     |    | |  |     |     |     |
   -------------+  |  |     |    | |  |     |     |     +-------------
                   |  |     |    | |  |     |     |
   -------------+  |  |     |    | |  |     |     |     +-------------
                |  |  |  +--+--+ | |  |  +--+--+  |     |
         +----+ |  |  |  |     | | +--+--+     |  |     | +----+
   ------+    +-+--+  |  | CN  +-+----+--+ CN  |  |     | |    +------
   ------+ EN +-+-----+--+     | |    |  |     +--+-----+-+ EN +------
         |    | |     |  +-----+ |    |  +-----+  |     | |    |
         +----+ |     |          |    |           |     | +----+
                |     +----------+    |-----------+     |
   -------------+           Server Network(s)           +-------------
        Client    UNI                               UNI   Client
        Network <----->                           <-----> Network
                          Scope of This Document

                        Legend:   EN  -  Client Edge Node
                                  CN S. De Cnodder, "Exclude Routes -  Server Node

                  Figure 22 : Ethernet UNI Reference Model

   An issue that is often raised concerns how a dual-homed client edge
   node (such as that shown at the bottom left-hand corner of Figure 22)
   can make determinations about how they connect across the UNI.  This
   can be particularly important when reachability across the server
   network is limited or when two diverse paths are desired (for
   example,
             Extension to provide protection).  However, in the model described in
   this network, the edge node (the UNI-C) is part of the abstraction
   layer network Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE)", RFC 4874, April 2007.

   [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and can see sufficient topology information to make
   these decisions.  If the approach introduced in this document is used
   to model the UNI as described in this section, there is no need to
   enhance the signaling protocols at the GMPLS UNI nor to add routing
   exchanges at the UNI.

9.  Abstraction in L3VPN Multi-AS Environments

   Serving layer-3 VPNs (L3PVNs) across a multi-AS or multi-operator
   environment currently provides a significant planning challenge.
   Figure 6 shows the general case of the problem that needs to be
   solved.  This section shows how the abstraction layer network can
   address this problem.

   In the VPN architecture, the CE nodes are the client network edge
   nodes,
             Ash, G., "Crankback Signaling Extensions for MPLS and the PE nodes are the server network edge nodes.  The
   abstraction layer network is made up of the CE nodes, the CE-PE
   links, the PE nodes, GMPLS
             RSVP-TE", RFC 4920, July 2007.

   [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and PE-PE tunnels that are the abstract links.

   In the multi-AS or multi-operator case, the abstraction layer network
   also includes the PEs (maybe ASBRs) at the edges of the multiple
   server networks, A. Farrel,
             "Label Switched Path Stitching with Generalized
             Multiprotocol Label Switching Traffic Engineering (GMPLS
             TE)", RFC 5150, February 2008.

   [RFC5152] Vasseur, JP., Ayyangar, A., and the PE-PE (maybe inter-AS) links.  This gives
   rise to the architecture shown in Figure 23.

   ...........                                     .............
    VPN Site :                                     : VPN Site
    --   --  :                                     :  --   --
   |C1|-|CE| :                                     : |CE|-|C2|
    --  |  | :                                     : |  |  --
        |  | :                                     : |  |
        |  | :                                     : |  |
        |  | :                                     : |  |
        |  | :   --           --     --       --   : |  |
        |  |----|PE|=========|PE|---|PE|=====|PE|----|  |
         --  :  |  |         |  |   |  |     |  |  :  --
   ...........  |  |         |  |   |  |     |  |  ............
                |  |         |  |   |  |     |  |
                |  |         |  |   |  |     |  |
                |  |         |  |   |  |     |  |
                |  |  -   -  |  |   |  |  -  |  |
                |  |-|P|-|P|-|  |   |  |-|P|-|  |
                 --   -   -   --     --   -   --

      Figure 23 : The Abstraction Layer Network Zhang, R., "A Per-Domain
             Path Computation Method for Establishing Inter-Domain
             Traffic Engineering (TE) Label Switched Paths (LSPs)",
             RFC 5152, February 2008.

   [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
             Auto-Discovery for a Multi-AS Layer-1 VPNs", RFC 5195, June 2008.

   [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5251] Fedyk, D., Rekhter, Y., Papadimitriou, D., Rabbat, R., and
             L. Berger, "Layer 1 VPN

   The policy Basic Mode", RFC 5251, July 2008.

   [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-
             Discovery", RFC 5252, July 2008.

   [RFC5305] Li, T., and Smit, H., "IS-IS Extensions for adding abstract links Traffic
             Engineering", RFC 5305, October 2008.

   [RFC5440] Vasseur, JP. and Le Roux, JL., "Path Computation Element
             (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

   [RFC5441] Vasseur, JP., Zhang, R., Bitar, N, and Le Roux, JL., "A
             Backward-Recursive PCE-Based Computation (BRPC) Procedure
             to the abstraction layer network
   will be driven substantially by the needs of the VPN.  Thus, when a
   new Compute Shortest Constrained Inter-Domain Traffic
             Engineering Label Switched Paths", RFC 5441, April 2009.

   [RFC5523] L. Berger, "OSPFv3-Based Layer 1 VPN site is added Auto-Discovery", RFC
             5523, April 2009.

   [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
             Reservation Protocol (RSVP) Extensions for Path Key
             Support", RFC 5553, May 2009.

   [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
             "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic
             Engineering", RFC 5623, September 2009.

   [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS
             Networks", RFC 5920, July 2010.

   [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
             Authentication Option", RFC 5925, June 2010.

   [RFC6005] Nerger, L., and the existing abstraction layer network
   cannot support the required connectivity, a new abstract link will be
   created out of the underlying network.

   It is important to note that each VPN instance can have a separate
   abstraction layer network.  This means that the server network
   resources can be partitioned D. Fedyk, "Generalized MPLS (GMPLS) Support
             for Metro Ethernet Forum and that traffic can be kept separate.
   This can be achieved even when VPN sites from different VPNs connect
   at the same PE.  Alternatively, multiple VPNs can share the same
   abstraction layer network if that is operationally preferable.

   Lastly, just as G.8011 User Network Interface
             (UNI)", RFC 6005, October 2010.

   [RFC6107] Shiomoto, K., and A. Farrel, "Procedures for the UNI discussed in Section 8, the issue of
   dual-homing of VPN sites is a function of the abstraction layer
   network Dynamically
             Signaled Hierarchical Label Switched Paths", RFC 6107,
             February 2011.

   [RFC6701] Frankel, S. and so is just a normal routing problem in that network.

10.  Scoping Future Work

   The section is provided to help guide the work on this problem S. Krishnan, "IP Security (IPsec) and to
   ensure that oceans are not knowingly boiled.

10.1.  Not Solving the
             Internet

   The scope of the use cases Key Exchange (IKE) Document Roadmap", RFC 6701,
             February 2011.

   [RFC6805] King, D., and problem statement in this document is
   limited to "some small set of interconnected domains."  In
   particular, it is not the objective A. Farrel, "The Application of this work to turn the whole
   Internet into one large, interconnected TE network.

10.2.  Working With "Related" Domains

   Subsequent Path
             Computation Element Architecture to Section 10.1, the intention Determination of this work is to solve a
             Sequence of Domains in MPLS and GMPLS", RFC 6805, November
             2012.

   [RFC6827] Malis, A., Lindem, A., and D. Papadimitriou, "Automatically
             Switched Optical Network (ASON) Routing for OSPFv2
             Protocols", RFC 6827, January 2013.

   [RFC6996] J. Mitchell, "Autonomous System (AS) Reservation for
             Private Use", BCP 6, RFC 6996, July 2013.

   [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the TE interconnectivity Path
             Computation Element Architecture", RFC 7399, October 2014.

   [RFC7579] Bernstein, G., Lee, Y.,et al., "General Network Element
             Constraint Encoding for only "related" domains.  Such domains
   may be under common administrative operation (such as IGP areas
   within a single AS, or ASes belonging GMPLS-Controlled Networks", RFC
             7579, June 2015.

   [RFC7580] Zhang, F., Lee, Y,. Han, J, Bernstein, G., and Xu, Y.,
             "OSPF-TE Extensions for General Network Element
             Constraints", RFC 7580, June 2015.

Authors' Addresses

   Adrian Farrel
   Juniper Networks
   EMail: adrian@olddog.co.uk

   John Drake
   Juniper Networks
   EMail: jdrake@juniper.net

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   EMail: nabil.bitar@verizon.com

   George Swallow
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA 01719
   EMail: swallow@cisco.com

   Xian Zhang
   Huawei Technologies
   Email: zhang.xian@huawei.com

   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy
   EMail: daniele.ceccarelli@ericsson.com

Contributors

   Gert Grammel
   Juniper Networks
   Email: ggrammel@juniper.net

   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net

   Oscar Gonzalez de Dios
   Email: ogondio@tid.es

   Fatai Zhang
   Email: zhangfatai@huawei.com
   Zafar Ali
   Email: zali@cisco.com

   Rajan Rao
   Email: rrao@infinera.com

   Sergio Belotti
   Email: sergio.belotti@alcatel-lucent.com

   Diego Caviglia
   Email: diego.caviglia@ericsson.com

   Jeff Tantsura
   Email: jeff.tantsura@ericsson.com

   Khuzema Pithewan
   Email: kpithewan@infinera.com

   Cyril Margaria
   Email: cyril.margaria@googlemail.com

   Victor Lopez
   Email: vlopez@tid.es

Appendix A.  Existing Work

   This appendix briefly summarizes relevant existing work that is used
   to a single operator), or may
   have a direct commercial arrangement for the sharing of route TE
   information to provide specific services.  Thus, in both cases, there
   is a strong opportunity for the application paths across multiple domains.

A.1.  Per-Domain Path Computation

   The per-domain mechanism of policy.

10.3.  Not Finding Optimal Paths in All Situations

  As has been well path establishment is described in this document, abstraction necessarily
  involves compromises
   [RFC5152] and removal of information.  That means that it its applicability is not possible to guarantee discussed in [RFC4726].  In
   summary, this mechanism assumes that an end-to-end each domain entry point is
   responsible for computing the path over
  interconnected TE domains follows across the absolute optimal (by any measure domain, but that
   details of optimality) path.  This is taken as understood, and future work
  should not attempt the path in the next domain are left to achieve such paths which can only the next domain
   entry point.  The computation may be found performed directly by the entry
   point or may be delegated to a
  full examination computation server.

   This basic mode of all network information across all connected
  networks.

10.4.  Not Breaking Existing Protocols

   It is a clear objective operation can run into many of this work to not break existing protocols.
   The Internet relies on the stability of a few key routing protocols,
   and so it is critical that any new work must not make these protocols
   brittle or unstable.

10.5.  Sanity and Scaling

   All of issues
   described alongside the above points play into use cases in Section 2.  However, in practice
   it can be used effectively with a final observation.  This work is
   intended to bite off little operational guidance.

   For example, RSVP-TE [RFC3209] includes the concept of a small problem for some relatively simple use
   cases as described "loose hop"
   in Section 2.  It is not intended the explicit path that this work
   will be immediately (or is signaled.  This allows the original
   request for an LSP to list the domains or even soon) extended domain entry points to cover many large
   interconnected domains.  Obviously
   include on the solution should as far as
   possible path.  Thus, in the example in Figure 1, the source
   can be designed told to be extensible use the interconnection x2.  Then the source computes
   the path from itself to x2, and scalable, however, it initiates the signaling.  When the
   signaling message reaches Domain Z, the entry point to the domain
   computes the remaining path to the destination and continues the
   signaling.

   Another alternative suggested in [RFC5152] is
   also reasonable to make trade-offs TE routing
   attempt to follow inter-domain IP routing.  Thus,  in favor of utility the example
   shown in Figure 2, the source would examine the BGP routing
   information to determine the correct interconnection point for
   forwarding IP packets, and
   simplicity.

11.  Manageability Considerations

   Manageability should not be would use that to compute and then signal
   a significant additional burden. path for Domain A.  Each
   layer domain in turn would apply the network model can and should be managed independently.

   That is, each client network will run its own management systems same
   approach so that the path is progressively computed and
   tools to manage signaled
   domain by domain.

   Although the nodes per-domain approach has many issues and links drawbacks in
   terms of achieving optimal (or, indeed, any) paths, it has been the client network: each
   client network link that is realized by mans
   mainstay of inter-domain LSP set-up to date.

A.2.  Crankback

   Crankback addresses one of the main issues with per-domain path
   computation: what happens when an abstract link will
   still initial path is selected that
   cannot be available for management completed toward the destination?  For example, what
   happens if, in Figure 2, the client network as any other
   link.

   Similarly, each server network will run its own management systems
   and tools source attempts to manage the nodes and links in that network just as
   normal.

   Three issues remain for consideration:

   - How is route the abstraction layer network managed?
   - How is path
   through interconnection x2, but Domain C does not have the interface between right TE
   resources or connectivity to route the client network path further?

   Crankback for MPLS-TE and the abstraction
     layer network managed?
   - How GMPLS networks is the interface between the abstraction layer network described in [RFC4920]
   and is based on a concept similar to the
     server network managed?

11.1.  Managing Acceptable Label Set
   mechanism described for GMPLS signaling in [RFC3473].  When a node
   (i.e., a domain entry point) is unable to compute a path further
   across the Abstraction Layer Network

   Management of domain, it returns an error message in the abstraction layer network differs from signaling
   protocol that states where the client blockage occurred (link identifier,
   node identifier, domain identifier, etc.) and server networks because not all of the links that are visible in gives some clues about
   what caused the TED have been realized.  That is, blockage (bad choice of label, insufficient bandwidth
   available, etc.).  This information allows a previous computation
   point to select an alternative path, or to aggregate crankback
   information and return it is not possible upstream to run OAM
   on the links that constitute the potential of a link that could previous computation point.

   Crankback is a very powerful mechanism and can be
   realized by used to find an LSP
   end-to-end path in a multi-domain network if one exists.

   On the server network, but that have not yet been
   established.

   Other than that, however, the management should be essentially the
   same.  Routing and signaling protocols other hand, crankback can be run quite resource-intensive as
   signaling messages and path setup attempts may "wander around" in the abstraction
   layer (using out of band channels
   network attempting to find the correct path for links that have not yet been
   established), and a centralized TED can long time.  Since
   RSVP-TE signaling ties up networks resources for partially
   established LSPs, since network conditions may be constructed in flux, and used most
   particularly since LSP setup within well-known time limits is highly
   desirable, crankback is not a popular mechanism.

   Furthermore, even if crankback can always find an end-to-end path, it
   does not guarantee to
   examine the availability and status of the links and nodes in find the
   network.

   Note optimal path. (Note that different deployment models will place the "ownership" of
   th abstraction layer network differently.  In there have
   been some case the academic proposals to use signaling-like techniques to
   explore the
   abstraction layer whole network will be constructed by in order to find optimal paths, but these
   tend to place even greater burdens on network processing.)

A.3.  Path Computation Element

   The Path Computation Element (PCE) is introduced in [RFC4655].  It is
   an abstract functional entity that computes paths.  Thus, in the operator
   example of per-domain path computation (see A.1) the
   server layer source node and run by that operator as
   each domain entry point is a service for one or more
   client networks.  In PCE.  On the other cases, one or more server networks will
   present hand, the potential of links to an abstraction layer PCE can
   also be realized as a separate network run
   by element (a server) to which
   computation requests can be sent using the operator Path Computation Element
   Communication Protocol (PCEP) [RFC5440].

   Each PCE has responsibility for computations within a domain, and has
   visibility of the client network.  And it is feasible attributes within that a
   business model could be built where a third-party operator manages domain.  This immediately
   enables per-domain path computation with the abstraction layer network, constructing it opportunity to off-load
   complex, CPU-intensive, or memory-intensive computation functions
   from routers in the connectivity
   available network.  But the use of PCE in multiple server networks, this way does not
   solve any of the problems articulated in A.1 and facilitating connectivity A.2.

   Two significant mechanisms for multiple client networks.

11.2.  Managing Interactions cooperation between PCEs have been
   described.  These mechanisms are intended to specifically address the
   problems of Client and Abstraction Layer Networks computing optimal end-to-end paths in multi-domain
   environments.

   - The interaction Backward-Recursive PCE-Based Computation (BRPC) mechanism
     [RFC5441] involves cooperation between the client network and th abstraction layer
   network is a management task.  It might be automated (software
   driven) or it might require manual intervention.

   This set of PCEs along the
     inter-domain path.  Each one computes the possible paths from
     domain entry point (or source node) to domain exit point (or
     destination node) and shares the information with its upstream
     neighbor PCE which is able to build a two-way interaction:

   - tree of possible paths
     rooted at the destination.  The client network PCE in the source domain can express
     select the need for additional
     connectivity.  For example, optimal path.

     BRPC is sometimes described as "crankback at computation time". It
     is capable of determining the client layer may try and fail to
     find a optimal path across in a multi-domain
     network, but depends on knowing the client network domain that contains the
     destination node.  Furthermore, the mechanism can become quite
     complicated and may request additional,
     specific connectivity (this involve a lot of data in a mesh of interconnected
     domains.  Thus, BRPC is similar to the situation with
     Virtual Network Topology Manager (VNTM) [RFC5623]).  Alternatively, most often proposed for a more proactive client layer management system may monitor traffic
     demands (current and predicted), network usage, and network "hot
     spots" simple mesh of
     domains and specifically for a path that will cross a known
     sequence of domains, but where there may request changes in connectivity by both releasing
     unused links and by requesting new links.

   - The abstraction layer network can make links available to the
     client network or can withdraw them.  These actions can be in
     response to requests from the client layer, or can be driven by
     processes within the abstraction layer (perhaps reorganizing the
     use a choice of server layer resources). domain
     interconnections.  In any case, the presentation of
     new links this way, BRPC would only be applied to
     Figure 2 if a decision had been made (externally) to traverse
     Domain C rather than Domain D (notwithstanding that it could
     functionally be used to the client layer is heavily subject make that choice itself), but BRPC could be
     used very effectively to policy since
     this select between interconnections x1 and x2
     in Figure 1.

   - Hierarchical PCE (H-PCE) [RFC6805] offers a parent PCE that is both operationally key to
     responsible for navigating a path across the success of this architecture domain mesh and for
     coordinating intra-domain computations by the central plank child PCEs
     responsible for each domain.  This approach makes computing an end-
     to-end path across a mesh of domains far more tractable.  However,
     it still leaves unanswered the commercial model described in this
     document.  Such policies belong to the operator issue of determining the abstraction
     layer network and are expected to be fully configurable.

     Once the abstraction layer network has decided to make a link
     available to the client network it will install it at location of
     the link end
     points (which are nodes in destination (i.e., discovering the client network) such that it appears
     and can be advertised destination domain) as a link
     described in the client network.

   In all cases, Section 2.1.1.  Furthermore, it is important that raises the operators question of both
     who operates the parent PCE especially in networks are
   able to track where the requests and responses,
     domains are under different administrative and the operator of the
   client network commercial control.

   It should also be able to see which links in noted that [RFC5623] discusses how PCE is used in a
   multi-layer network are
   "real" physical links, with coordination between PCEs operating at each
   network layer.  Further issues and which are presented by the abstraction
   layer network.

11.3.  Managing Interactions considerations of Abstraction Layer the use of PCE
   can be found in [RFC7399].

A.4.  GMPLS UNI and Server Overlay Networks

   The interactions between

   [RFC4208] defines the abstraction layer GMPLS User-to-Network Interface (UNI) to
   present a routing boundary between an overlay network and the server
   network a similar to those described in Section 11.2, but there is a
   difference in that core
   network, i.e. the server layer is more likely to offer up
   connectivity, and client-server interface.  In the abstraction layer network is less likely to ask
   for it.

   That is, client network,
   the server network will, according nodes connected directly to policy that may
   include commercial relationships, offer the abstraction layer network
   a set of potential connectivity that the abstraction layer core network
   can treat are known as links.  This edge
   nodes, while the nodes in the server network policy will include:
   - how much connectivity to offer
   - what level of server layer redundancy to include
   - whether to realize are called core nodes.

   In the connectivity when it is offered, or to wait
     until overlay model defined by [RFC4208] the abstraction layer network asks to use core nodes act as a link.

   This process of offering links from
   closed system and the server network may include a
   mechanism to indicate which links have been pre-established edge nodes do not participate in the
   server network, and can include other properties such as:
   - link-level protection ([RFC4202])
   - SRLG and MSRLG (Section 5.3.3.1)
   - mutual exclusivity (Section 5.3.3.2).

   The abstraction layer network needs a mechanism to request routing
   protocol instance that a
   link is realized if it hasn't already been established as an LSP in runs among the server network.  This mechanism could also include core nodes.  Thus the ability UNI
   allows access to request additional connectivity from and limited control of the server layer, although
   it seems most likely core nodes by edge nodes
   that the server layer will already have
   presented as much connectivity as it is physically capable are unaware of
   subject to the constraints topology of policy.

   Finally, the server layer will need to confirm core nodes.  This respects
   the establishment of
   connectivity, withdraw links if they are no longer feasible, operational and
   report failures.

   Again, it is important that layer boundaries while scaling the operators of both networks are able
   to track network.

   [RFC4208] does not define any routing protocol extension for the requests and responses,
   interaction between core and edge nodes but allows for the operator exchange
   of reachability information between them.  In terms of a VPN, the server
   client network should can be able to see which links are in use.

12.  IANA Considerations

   This document makes no requests for IANA action.  The RFC Editor may
   safely remove this section.

13.  Security Considerations

   Security of signaling and routing protocols is usually administered
   and achieved within considered as the boundaries customer network comprised
   of a domain.  Thus, number of disjoint sites, and for
   example, a domain with a GMPLS control plane [RFC3945] would apply the security mechanisms and considerations that are appropriate to
   GMPLS [RFC5920].  Furthermore, domain-based security relies strongly
   on ensuring that control plane messages are not allowed to enter edge nodes match the
   domain from outside.  Thus, VPN CE
   nodes.  Similarly, the mechanisms provider network in this document for
   inter-domain exchange of control plane messages and information
   naturally raise additional questions of security.

   In this context, additional security considerations arising from this
   document relate the VPN model is
   equivalent to the exchange of control plane information between
   domains.  Messages are passed between domains using control plane
   protocols operating between peers server network.

   [RFC4208] is, therefore, a signaling-only solution that have predictable relationships
   (for example, UNI-C allows edge
   nodes to UNI-N, between BGP-LS speakers, or between
   peer domains).  Thus, request connectivity cross the security that needs core network, and leaves the
   core network to be given additional
   attention select the paths for inter-domain TE concentrates on authentication the LSPs as they traverse the
   core (setting up hierarchical LSPs if necessitated by the
   technology).  This solution is supplemented by a number of
   peers, assertion that messages have not been tampered with, signaling
   extensions such as [RFC4874], [RFC5553], [I-D.ietf-ccamp-xro-lsp-
   subobject], [I-D.ietf-ccamp-rsvp-te-srlg-collect], and [I-D.ietf-
   ccamp-te-metric-recording] to a
   lesser extent protecting the content of the messages from inspection
   since that might give away sensitive information about the networks.
   The protocols described in Section 6 edge node more control over
   path within the core network and which are likely to provide by allowing the foundation to solutions edge nodes to supply
   additional constraints on the path used in the core network.
   Nevertheless, in this architecture already include
   such protection UNI/overlay model, the edge node has limited
   information of precisely what LSPs could be set up across the core,
   and further what TE services (such as diverse routes for end-to-end
   protection, end-to-end bandwidth, etc.) can be run over protected transports
   such as IPsec [RFC6701], TLS [RFC5246], and the TCP Authentication
   Option (TCP-AO) [RFC5925].

   It supported.

A.5.  Layer One VPN

   A Layer One VPN (L1VPN) is worth noting that a service offered by a core layer 1
   network to provide layer 1 connectivity (TDM, LSC) between two or
   more customer networks in an overlay service model [RFC4847].

   As in the control plane of UNI case, the abstraction layer
   network is likely to be out of band.  That is, customer edge has some control plane messages
   will be exchanged over network links that are not the links to which
   they apply.  This models the facilities of GMPLS (but not of MPLS-TE)
   establishment and type of the security mechanisms can be applied to the protocols operating
   in connectivity.  In the out of band network.

14.  Acknowledgements

   Thanks to Igor Bryskin for useful discussions in L1VPN context
   three different service models have been defined classified by the early stages
   semantics of
   this work.

   Thanks to Gert Grammel for discussions on information exchanged over the extent of aggregation
   in abstract nodes and links.

   Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam
   Somasundaram, and Hannes Gredler for review customer interface:

   Management Based, Signaling Based (a.k.a. basic), and input.

   Particular thanks to Vishnu Pavan Beeram for detailed discussions Signaling and
   white-board scribbling that made many of
   Routing service model (a.k.a. enhanced).

   In the ideas in this document
   come to life.

   Text in Section 5.3.3 management based model, all edge-to-edge connections are set
   up using configuration and management tools.  This is freely adapted from the work of Igor
   Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel,
   Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria,
   Oscar Gonzalez de Dios, not a dynamic
   control plane solution and Daniele Ceccarelli in
   [I-D.beeram-ccamp-gmpls-enni] for which need not concern us here.

   In the authors of this document
   express their thanks.

15.  References

15.1.  Informative References

   [G.8080]  ITU-T, "Architecture signaling based service model [RFC5251] the CE-PE interface
   allows only for signaling message exchange, and the automatically switched optical provider network (ASON)", Recommendation G.8080.

   [I-D.beeram-ccamp-gmpls-enni]
             Bryskin, I., Beeram, V. P.,  Drake, J. et al., "Generalized
             Multiprotocol Label Switching (GMPLS) External Network
             Network Interface (E-NNI): Virtual Link Enhancements for
   does not export any routing information about the Overlay Model", draft-beeram-ccamp-gmpls-enni, work in
             progress.

   [I-D.ietf-ccamp-general-constraint-encode]
             Bernstein, G., Lee, Y., Li, D., and Imajuku, W., "General
             Network Element Constraint Encoding for GMPLS Controlled
             Networks", draft-ietf-ccamp-general-constraint-encode, work
             in progress.

   [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
             Zhang, F., Lee, Y,. Han, J, Bernstein, G., core network.  VPN
   membership is known a priori (presumably through configuration) or is
   discovered using a routing protocol [RFC5195], [RFC5252], [RFC5523],
   as is the relationship between CE nodes and Xu, Y.,
             "OSPF-TE Extensions for General Network Element
             Constraints", draft-ietf-ccamp-gmpls-general-constraints-
             ospf-te, work ports on the PE.  This
   service model is much in progress.

   [I-D.ietf-ccamp-rsvp-te-srlg-collect]
             Zhang, F. (Ed.) and O. Gonzalez de Dios (Ed.), "RSVP-TE
             Extensions for Collecting SRLG Information", draft-ietf-
             ccamp-rsvp-te-srlg-collect, work line with GMPLS UNI as defined in progress.

   [I-D.ietf-ccamp-te-metric-recording]
             Z. Ali, et al., "Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) extension for recording TE Metric [RFC4208].

   In the enhanced model there is an additional limited exchange of
             a Label Switched Path," draft-ali-ccamp-te-metric-
             recording, work in progress.

   [I-D.ietf-ccamp-xro-lsp-subobject]
             Z. Ali, et al., "Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) LSP Route Diversity using Exclude
             Routes," draft-ali-ccamp-xro-lsp-subobject, work in
             progress.

   [I-D.ietf-idr-ls-distribution]
             Gredler, H., Medved, J., Previdi, S., Farrel, A.,
   routing information over the CE-PE interface between the provider
   network and Ray,
             S., "North-Bound Distribution the customer network.  The enhanced model considers four
   different types of Link-State service models, namely: Overlay Extension, Virtual
   Node, Virtual Link and TE
             Information using BGP", draft-ietf-idr-ls-distribution,
             work in progress.

   [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., Per-VPN service models.  All of these
   represent particular cases of the TE information aggregation and
             McManus, J., "Requirements for Traffic Engineering Over
             MPLS", RFC 2702, September 1999.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
   representation.

A.6.  Policy and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.

   [RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RC 3473, January 2003.

   [RFC3630] Katz, D., Kompella, Link Advertisement

   Inter-domain networking relies on policy and K., Yeung, D., "Traffic Engineering
             (TE) Extensions management input to OSPF Version 2", RFC 3630, September
             2003.

   [RFC3945] Mannie, E., (Ed.), "Generalized Multi-Protocol Label
             Switching (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4105] Le Roux, J.-L., Vasseur, J.-P., and Boyle, J.,
             "Requirements
   coordinate the allocation of resources under different administrative
   control.  [RFC5623] introduces a functional component called the
   Virtual Network Topology Manager (VNTM) for Inter-Area MPLS Traffic Engineering",
             RFC 4105, June 2005.

   [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions this purpose.

   An important companion to this function is determining how
   connectivity across the abstraction layer network is made available
   as a TE link in Support
             of Generalized Multi-Protocol Label Switching (GMPLS)",
             RFC 4202, October 2005.

   [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
             Hierarchy with Generalized Multi-Protocol Label Switching
             (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
             "User-Network Interface (UNI): Resource ReserVation
             Protocol-Traffic Engineering (RSVP-TE) Support the client network.  Obviously, if the connectivity
   is established using management intervention, the consequent client
   network TE link can also be configured manually.  However, if
   connectivity from client edge to client edge is achieved using
   dynamic signalling then there is need for the
             Overlay Model", RFC 4208, October 2005.

   [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-Autonomous
             System (AS) Traffic Engineering (TE) Requirements",
             RFC 4216, November 2005.

   [RFC4271] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway
             Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC 4364, February 2006.

   [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture",  RFC 4655, August 2006.

   [RFC4726] Farrel, A., Vasseur, J.-P., end points to exchange
   the link properties that they should advertise within the client
   network, and Ayyangar, A., "A Framework in the case of support for Inter-Domain Multiprotocol Label Switching Traffic
             Engineering", RFC 4726, November 2006.

   [RFC4847] T. Takeda (Ed.), "Framework more than one client network,
   it will be necessary to indicate which client or clients can use the
   link.  This capability it provided in [RFC6107].

Appendix B.  Additional Features

   This Appendix describes additional features that may be desirable and Requirements
   that can be achieved within this architecture.

B.1.  Macro Shared Risk Link Groups

   Network links often share fate with one or more other links.  That
   is, a scenario that may cause a link to fail could cause one or more
   other links to fail.  This may occur, for Layer 1
             Virtual Private Networks," RFC 4847, April 2007.

   [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
             Extension example, if the links are
   supported by the same fiber bundle, or if some links are routed down
   the same duct or in a common piece of infrastructure such as a
   bridge.  A common way to Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE)", RFC 4874, April 2007.

   [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., identify the links that may share fate is to
   label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202].

   TE links created from LSPs in lower layers may also share fate, and
             Ash, G., "Crankback Signaling Extensions
   it can be hard for MPLS and GMPLS
             RSVP-TE", RFC 4920, July 2007.

   [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., a client network to know about this problem
   because it does not know the topology of the server network or the
   path of the server layer LSPs that are used to create the links in
   the client network.

   For example, looking at the example used in Section 4.2.3 and A. Farrel,
             "Label Switched Path Stitching with Generalized
             Multiprotocol Label Switching Traffic Engineering (GMPLS
             TE)", RFC 5150, February 2008.

   [RFC5152] Vasseur, JP., Ayyangar, A.,
   considering the two abstract links S1-S3 and Zhang, R., "A Per-Domain
             Path Computation Method S1-S9 there is no way
   for Establishing Inter-Domain
             Traffic Engineering (TE) Label Switched Paths (LSPs)",
             RFC 5152, February 2008.

   [RFC5195] Ould-Brahim, H., Fedyk, D., the client layer to know whether the links C2-C0 and C2-C3 share
   fate.  Clearly, if the client layer uses these links to provide a
   link-diverse end-to-end protection scheme, it needs to know that the
   links actually share a piece of network infrastructure (the server
   layer link S1-S2).

   Per [RFC4202], an SRLG represents a shared physical network resource
   upon which the normal functioning of a link depends.  Multiple SRLGs
   can be identified and Y. Rekhter, "BGP-Based
             Auto-Discovery advertised for Layer-1 VPNs", RFC 5195, June 2008.

   [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
             M., every TE link in a network.
   However, this can produce a scalability problem in a mutli-layer
   network that equates to advertising in the client layer the server
   layer route of each TE link.

   Macro SRLGs (MSRLGs) address this scaling problem and D. Brungard, "Requirements are a form of
   abstraction performed at the same time that the abstract links are
   derived.  In this way, links that actually share resources in the
   server layer are advertised as having the same MSRLG, rather than
   advertising each SRLG for GMPLS-Based Multi-
             Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July
             2008.

   [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5251] Fedyk, D., Rekhter, Y., Papadimitriou, D., Rabbat, R., and
             L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.

   [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-
             Discovery", RFC 5252, July 2008.

   [RFC5305] Li, T., and Smit, H., "IS-IS Extensions each resource on each path in the server
   layer.  This saving is possible because the abstract links are
   formulated on behalf of the server layer by a central management
   agency that is aware of all of the link abstractions being offered.

   It may be noted that a less optimal alternative path for the abstract
   link S1-S9 exists in the server layer (S1-S4-S7-S8-S9).  It would be
   possible for the client layer request for Traffic
             Engineering", RFC 5305, October 2008.

   [RFC5440] Vasseur, JP. and Le Roux, JL., "Path Computation Element
             (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

   [RFC5441] Vasseur, JP., Zhang, R., Bitar, N, and Le Roux, JL., "A
             Backward-Recursive PCE-Based Computation (BRPC) Procedure connectivity C2-C0 to Compute Shortest Constrained Inter-Domain Traffic
             Engineering Label Switched Paths", RFC 5441, April 2009.

   [RFC5523] L. Berger, "OSPFv3-Based Layer 1 VPN Auto-Discovery", RFC
             5523, April 2009.

   [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
             Reservation Protocol (RSVP) Extensions for Path Key
             Support", RFC 5553, May 2009.

   [RFC5623] Oki, E., Takeda, T., Le Roux, JL., ask
   that the path be maximally disjoint from the path C2-C3.  While
   nothing can be done about the shared link C2-S1, the abstraction
   layer could request to use the link S1-S9 in a way that is diverse
   from use of the link S1-S3, and A. Farrel,
             "Framework for PCE-Based Inter-Layer MPLS this request could be honored if the
   server layer policy allows.

   Note that SRLGs and GMPLS Traffic
             Engineering", RFC 5623, September 2009.

   [RFC5920] L. Fang, Ed., "Security Framework MSRLGs may be very hard to describe in the case
   of multiple server layer networks because the abstraction points will
   not know whether the resources in the various server layers share
   physical locations.

B.2.  Mutual Exclusivity

   As noted in the discussion of Figure 13, it is possible that some
   abstraction layer links can not be used at the same time.  This
   arises when the potentiality of the links is indicated by the server
   layer, but the use the links would actually compete for MPLS server layer
   resources.  In Figure 13 this arose when both link S1-S3 and GMPLS
             Networks", RFC 5920, July 2010.

   [RFC5925] Touch, J., Mankin, A., link
   S7-S9 were used to carry LSPs: in that case the link S1-S9 could no
   longer be used.

   Such a situation need not be an issue when client-edge to client-edge
   LSPs are set up one by one because the use of one abstraction layer
   link and R. Bonica, "The TCP
             Authentication Option", RFC 5925, June 2010.

   [RFC6005] Nerger, L., the corresponding use of server layer resources will cause
   the server layer to withdraw the availability of the other
   abstraction layer links, and D. Fedyk, "Generalized MPLS (GMPLS) Support these will become unavailable for Metro Ethernet Forum and G.8011 User Network Interface
             (UNI)", RFC 6005, October 2010.

   [RFC6107] Shiomoto, K., and A. Farrel, "Procedures
   further abstraction layer path computations.

   Furthermore, in deployments where abstraction layer links are only
   presented as available after server layer LSPs have been established
   to support them, the problem is unlikely exist.

   However, when the server layer is constrained, but chooses to
   advertise the potential of multiple abstraction layer links even
   though they compete for Dynamically
             Signaled Hierarchical Label Switched Paths", RFC 6107,
             February 2011.

   [RFC6701] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
             Internet Key Exchange (IKE) Document Roadmap", RFC 6701,
             February 2011.

   [RFC6805] King, D., resources, and A. Farrel, "The Application when multiple client-edge to
   client-edge LSPs are computed simultaneously (perhaps to provide
   protection services) there may be contention for server layer
   resources.  In the case that protected abstraction layer LSPs are
   being established, this situation would be avoided through the use of
   SRLGs and/or MSRLGs since the Path
             Computation Element Architecture two abstraction layer links that
   compete for server layer resources must also fate share across those
   resources.  But in the case where the multiple client-edge to client-
   edge LSPs do not care about fate sharing, it may be necessary to flag
   the Determination mutually exclusive links in the abstraction layer TED so that
   path computation can avoid accidentally attempting to utilize two of
   a
             Sequence set of Domains in MPLS and GMPLS", RFC 6805, November
             2012.

   [RFC6827] Malis, A., Lindem, A., and D. Papadimitriou, "Automatically
             Switched Optical Network (ASON) Routing for OSPFv2
             Protocols", RFC 6827, January 2013.

   [RFC6996] J. Mitchell, "Autonomous System (AS) Reservation for
             Private Use", BCP 6, RFC 6996, July 2013.

   [RFC7399] Farrel, A. and D. King, "Unanswered Questions in such links at the Path
             Computation Element Architecture", RFC 7399, October 2014.

Authors' Addresses

   Adrian Farrel
   Juniper Networks
   EMail: adrian@olddog.co.uk

   John Drake
   Juniper Networks
   EMail: jdrake@juniper.net

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   EMail: nabil.bitar@verizon.com

   George Swallow
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA 01719
   EMail: swallow@cisco.com

   Xian Zhang
   Huawei Technologies
   Email: zhang.xian@huawei.com

   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy
   EMail: daniele.ceccarelli@ericsson.com

Contributors

   Gert Grammel
   Juniper Networks
   Email: ggrammel@juniper.net

   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net

   Oscar Gonzalez de Dios
   Email: ogondio@tid.es

   Fatai Zhang
   Email: zhangfatai@huawei.com

   Zafar Ali
   Email: zali@cisco.com

   Rajan Rao
   Email: rrao@infinera.com

   Sergio Belotti
   Email: sergio.belotti@alcatel-lucent.com

   Diego Caviglia
   Email: diego.caviglia@ericsson.com

   Jeff Tantsura
   Email: jeff.tantsura@ericsson.com

   Khuzema Pithewan
   Email: kpithewan@infinera.com

   Cyril Margaria
   Email: cyril.margaria@googlemail.com

   Victor Lopez
   Email: vlopez@tid.es same time.