tech-invite   World Map     

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

RFC 7926

BCP 206
Pages: 67
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: TEAS

Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks

Part 1 of 3, p. 1 to 21
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                    A. Farrel, Ed.
Request for Comments: 7926                                      J. Drake
BCP: 206                                                Juniper Networks
Category: Best Current Practice                                 N. Bitar
ISSN: 2070-1721                                                    Nokia
                                                              G. Swallow
                                                     Cisco Systems, Inc.
                                                           D. Ceccarelli
                                                                Ericsson
                                                                X. Zhang
                                                                  Huawei
                                                               July 2016


      Problem Statement and Architecture for Information Exchange
           between Interconnected Traffic-Engineered Networks

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 networks 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 for the exchange of TE
   information between interconnected TE networks in support of end-to-
   end TE path establishment and describes the best current practice
   architecture to meet this problem statement.  For reasons that are
   explained in this document, this work is limited to simple TE
   constraints and information that determine TE reachability.

[Page 2] 
Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7926.

Copyright Notice

   Copyright (c) 2016 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.

Top       Page 3 
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 .....................................7
           1.1.4. Domain ..............................................7
           1.1.5. Server Network ......................................7
           1.1.6. Client Network ......................................7
           1.1.7. Aggregation .........................................7
           1.1.8. Abstraction .........................................8
           1.1.9. Abstract Link .......................................8
           1.1.10. Abstract Node or Virtual Node ......................8
           1.1.11. Abstraction Layer Network ..........................9
   2. Overview of Use Cases ...........................................9
      2.1. Peer Networks ..............................................9
      2.2. Client-Server Networks ....................................11
      2.3. Dual-Homing ...............................................15
      2.4. Requesting Connectivity ...................................15
           2.4.1. Discovering Server Network Information .............17
   3. Problem Statement ..............................................18
      3.1. Policy and Filters ........................................18
      3.2. Confidentiality ...........................................19
      3.3. Information Overload ......................................19
      3.4. Issues of Information Churn ...............................20
      3.5. Issues of Aggregation .....................................21
   4. Architecture ...................................................22
      4.1. TE Reachability ...........................................22
      4.2. Abstraction, Not Aggregation ..............................22
           4.2.1. Abstract Links .....................................23
           4.2.2. The Abstraction Layer Network ......................23
           4.2.3. Abstraction in Client-Server Networks ..............26
           4.2.4. Abstraction in Peer Networks .......................32
      4.3. Considerations for Dynamic Abstraction ....................34
      4.4. Requirements for Advertising Links and Nodes ..............35
      4.5. Addressing Considerations .................................36
   5. Building on Existing Protocols .................................36
      5.1. BGP-LS ....................................................37
      5.2. IGPs ......................................................37
      5.3. RSVP-TE ...................................................37
      5.4. Notes on a Solution .......................................37
   6. Application of the Architecture to Optical Domains and
      Networks .......................................................39

Top      ToC       Page 4 
   7. Application of the Architecture to the User-Network Interface ..44
   8. Application of the Architecture to L3VPN Multi-AS Environments .46
   9. Scoping Future Work ............................................47
      9.1. Limiting Scope to Only Part of the Internet ...............47
      9.2. Working with "Related" Domains ............................47
      9.3. Not Finding Optimal Paths in All Situations ...............48
      9.4. Sanity and Scaling ........................................48
   10. Manageability Considerations ..................................48
      10.1. Managing the Abstraction Layer Network ...................49
      10.2. Managing Interactions of Abstraction Layer and
            Client Networks ..........................................49
      10.3. Managing Interactions of Abstraction Layer and
            Server Networks ..........................................50
   11. Security Considerations .......................................51
   12. Informative References ........................................52
   Appendix A. Existing Work .........................................58
      A.1. Per-Domain Path Computation ...............................58
      A.2. Crankback .................................................59
      A.3. Path Computation Element ..................................59
      A.4. GMPLS UNI and Overlay Networks ............................61
      A.5. Layer 1 VPN ...............................................62
      A.6. Policy and Link Advertisement .............................62
   Appendix B. Additional Features ...................................63
      B.1. Macro Shared Risk Link Groups .............................63
      B.2. Mutual Exclusivity ........................................64
   Acknowledgements ..................................................65
   Contributors ......................................................66
   Authors' Addresses ................................................67

Top      ToC       Page 5 
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 Interior Gateway
   Protocol (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 (ASes).

   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 for the exchange of TE
   information between interconnected TE networks in support of end-to-
   end TE path establishment and describes the best current practice
   architecture to meet this problem statement.  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.

Top      ToC       Page 6 
   Appendix A summarizes 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.  A TE metric is a quantifiable value (including measured
   characteristics) describing some property of a link or node that can
   be used as part of TE routing or planning, while a TE attribute is a
   wider term (i.e., including the concept of a TE metric) that refers
   to any property or characteristic of a link or node that can be used
   as part of TE routing or planning.  Thus, the delay introduced by
   transmission of a packet on a link is an example of a TE metric,
   while the geographic location of a router is an example of a more
   general attribute.

   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 TE metrics and TE 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.

Top      ToC       Page 7 
1.1.3.  TE Reachability

   In an IP network, reachability is the ability to deliver a packet to
   a specific address or prefix, i.e., 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); this is helpful especially in determining a path to a
   destination that lies in an unknown domain or that may be qualified
   by TE attributes and TE metrics such as hop count, available
   bandwidth, delay, and shared risk.

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 IGP
   areas and ASes.

1.1.5.  Server Network

   A Server Network is a network that provides connectivity for another
   network (the Client Network) in a client-server relationship.  A
   Server Network is sometimes referred to as an underlay network.

1.1.6.  Client Network

   A Client Network is a network that uses the connectivity provided by
   a Server Network.  A Client Network is sometimes referred to as an
   overlay network.

1.1.7.  Aggregation

   The concept of aggregation is discussed in Section 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.

Top      ToC       Page 8 
1.1.8.  Abstraction

   Section 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 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 it 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.9.  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 regarding abstract links are provided in Section 4.2.1.

1.1.10.  Abstract Node or Virtual Node

   An abstract node was defined in [RFC3209] as a group of nodes whose
   internal topology is opaque to an ingress node of the LSP.  More
   generally, an abstract node is the representation as a single node in
   a TE topology of some or all of the resources of one or more nodes
   and the links that connect them.  An abstract node may be advertised
   outside the domain as a TE node for use in path computation and
   signaling in other domains.

   The term "virtual node" has typically been applied to the aggregation
   of a domain (that is, a collection of nodes and links that operate as
   a single administrative entity for TE purposes) into a single entity
   that is treated as a node for the purposes of end-to-end traffic
   engineering.  Virtual nodes are often considered a way to present
   islands of single-vendor equipment in an optical network.

   Sections 3.5 and 4.2.2.1 provide more information about the uses and
   issues of abstract nodes and virtual nodes.

Top      ToC       Page 9 
1.1.11.  Abstraction Layer Network

   The abstraction layer network is introduced in Section 4.2.2.  It may
   be seen as a brokerage-layer network between one or more server
   networks and one or more client networks.  The abstraction layer
   network is the collection of abstract links that provide potential
   connectivity across the server networks 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 network resources more flexible, the abstract links might
   not all extend from edge to edge but might offer connectivity between
   server network 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), which 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 suboptimal path or
   even fail to make a path available.  Note that peer networks are
   assumed to have the same technology type -- that is, the same
   "switching capability", to use the term from GMPLS [RFC3945].

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

                          Figure 1: Peer Networks

   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 may be used to
   alleviate this situation, but such techniques do not lead to rapid
   setup or guaranteed optimality.  Furthermore, RSVP signaling creates
   state in the network that is immediately removed by the crankback

Top      ToC       Page 10 
   procedure.  Frequent events of this kind will impact scalability in a
   non-deterministic manner.  More details regarding crankback can be
   found in Appendix A.2.

   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 through Domain D, Domain A must be sensitive to
   the TE connectivity available through each of Domains C and D,
   as well as 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].

   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.

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

                     Figure 2: Peer Networks in a Mesh

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 of these classes of
   use case, the client and server networks may have the same switching
   capability, or they may be built from nodes and links that have
   different technology types in the client and server networks.

   The first group of use 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 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
   and by treating the server-network-layer connectivity as links in the
   higher-layer network.  The TE relationship between the domains
   (higher and lower layers) in this case is reduced to determining what
   server network connectivity to establish, how to trigger it, how to
   route it in the server network, and what resources and capacity to
   assign within the server network layer.  As the demands in the

Top      ToC       Page 12 
   higher-layer (client) network vary, the connectivity in the server
   network may need to be modified.  Section 2.4 explains in a little
   more detail how connectivity may be requested.

       ----------------                          ----------------
      | Client Network |                        | Client Network |
      |   Domain A     |                        |   Domain B     |
      |                |                        |                |
      |  -----         |                        |         -----  |
      | | Src |        |                        |        | Dst | |
      |  -----         |                        |         -----  |
      |                |                        |                |
       ----------------\                        /----------------
                        \x1                  x2/
                         \                    /
                          \                  /
                           \----------------/
                           | Server Network |
                           |     Domain     |
                           |                |
                            ----------------

                     Figure 3: Client-Server Networks

   The second class of use case relating to 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 network, 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
   (i.e., the provider network) that is the server network in our model.

Top      ToC       Page 13 
   Note that in the use cases shown in Figures 3 and 4 the client
   network domains may (and, in fact, probably do) operate as a single
   connected 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

Top      ToC       Page 14 
   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

Top      ToC       Page 15 
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
   network domain is attached to more than one domain in the server
   network or has two points of attachment to a server network domain.
   Figure 6 shows an example of this for a VPN.

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

            Figure 6: Dual-Homing in a Virtual Private Network

2.4.  Requesting Connectivity

   The 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 asked to establish a set of LSPs to provide client
   network connectivity.  In the dynamic case, the client network 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

Top      ToC       Page 16 
   set of constraints (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 asked 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 an intermediary
   broker such as the Virtual Network Topology Manager (VNTM) [RFC5623].

   The trigger that causes the request to the server network is also
   flexible.  It could be that the client network discovers a pressing
   need for server network resources (such as the desire to provision an
   end-to-end connection in the client network 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 network resources are under the
   administrative control of the operator or the server network and are
   only used to support a client network in ways that the server network
   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 network.  In the case of some server networks, even the
      bandwidth component of a basic provisioning request is superfluous
      because the server network has no facility to vary bandwidth and
      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 network 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.

Top      ToC       Page 17 
      Equally, optimization may 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 the server network 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 network to construct protection services over the server
      network -- for example, by establishing 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 follow the same path in the server network.  This may
      be requested, for example, to create a bundled or aggregated link
      in the client network where each component of the client-layer
      composite link is required to have the same server network
      properties (metrics, delay, etc.) and the same failure
      characteristics.

   o  "Concurrent provisioning" enables the interrelated connection
      requests described in the previous two bullets to be enacted
      through a single, compound service request.

   o  "Service resilience" requests that the server network provide
      connectivity for which the server network 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".

Top      ToC       Page 18 
   o  A server network may support requests of the form "If I were 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.  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], and
   TE information may be exported from a domain (for example,
   northbound) using link-state extensions to BGP [RFC7752].

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

Top      ToC       Page 19 
3.2.  Confidentiality

   A feature of the policy described in Section 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 network domains
   described in Section 2.2) 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 shared
   information to only that which the computing domain needs to know,
   with the understanding that the 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.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.1 because such filters might not
   always be enabled.

Top      ToC       Page 20 
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 that 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 are considerably longer.  Thus,
   the information churn may be sustainable.

Top      ToC       Page 21 
3.5.  Issues of Aggregation

   One possible solution to the issues raised in other subsections 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 [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 others, and with what TE
      attributes.

   Part of the nature of aggregation is 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.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 is
   reduced, the aggregation algorithm (operating on the routers
   responsible for sharing information) may be heavily exercised.


Next Section