From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7926.txt | 3755 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3755 insertions(+) create mode 100644 doc/rfc/rfc7926.txt (limited to 'doc/rfc/rfc7926.txt') diff --git a/doc/rfc/rfc7926.txt b/doc/rfc/rfc7926.txt new file mode 100644 index 0000000..89e9588 --- /dev/null +++ b/doc/rfc/rfc7926.txt @@ -0,0 +1,3755 @@ + + + + + + +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. + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 1] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 2] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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 + + + + + + + +Farrel, et al. Best Current Practice [Page 3] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 4] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + +Farrel, et al. Best Current Practice [Page 5] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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. + + + + +Farrel, et al. Best Current Practice [Page 6] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + + + + +Farrel, et al. Best Current Practice [Page 7] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + + + + +Farrel, et al. Best Current Practice [Page 8] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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 + + + + +Farrel, et al. Best Current Practice [Page 9] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 10] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + -------------- + | 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 + + + + + +Farrel, et al. Best Current Practice [Page 11] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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. + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 12] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 13] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 14] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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 + + + + +Farrel, et al. Best Current Practice [Page 15] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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. + + + + +Farrel, et al. Best Current Practice [Page 16] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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". + + + + + + + +Farrel, et al. Best Current Practice [Page 17] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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. + + + +Farrel, et al. Best Current Practice [Page 18] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + +Farrel, et al. Best Current Practice [Page 19] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + + + +Farrel, et al. Best Current Practice [Page 20] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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. + + + + + + + + +Farrel, et al. Best Current Practice [Page 21] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +4. Architecture + +4.1. TE Reachability + + As described in Section 1.1, TE reachability is the ability to reach + a specific address along a TE path. The knowledge of TE reachability + enables an end-to-end TE path to be computed. + + In a single network, TE reachability is derived from the Traffic + Engineering Database (TED), which is the collection of all TE + information about all TE links in the network. The TED is usually + built from the data exchanged by the IGP, although it can be + supplemented by configuration and inventory details, especially in + transport networks. + + In multi-network scenarios, TE reachability information can be + described as "You can get from node X to node Y with the following TE + attributes." For transit cases, nodes X and Y will be edge nodes 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 may be qualified by TE + attributes such as TE metrics, hop count, available bandwidth, delay, + and shared risk. + + TE reachability information can be exchanged between networks so that + nodes in one network can determine whether they can establish TE + paths across or into another network. Such exchanges are subject to + a range of policies imposed by the advertiser (for security and + administrative control) and by the receiver (for scalability and + stability). + +4.2. Abstraction, Not Aggregation + + Aggregation is the process of synthesizing from available + information. Thus, the virtual node and virtual link models + described in Section 3.5 rely on processing the information available + within a network to produce the aggregate representations of links + and nodes that are presented to the consumer. As described in + Section 3, dynamic aggregation is subject to a number of pitfalls. + + In order to distinguish the 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 information within a domain, to produce + selective information that represents the potential ability to + connect across the domain. + + + + + +Farrel, et al. Best Current Practice [Page 22] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Abstraction does not offer all possible connectivity options (refer + to Section 3.5) 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 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. + + Although abstraction uses available TE information, it is subject to + policy and management choices. Thus, not all potential connectivity + will be advertised to each client network. The filters may depend on + commercial relationships, the risk of disclosing confidential + information, and concerns about what use is made of the connectivity + that is offered. + +4.2.1. Abstract Links + + An abstract link is a measure of the potential to connect a pair of + points with certain TE parameters. That is, it is a path and its + characteristics in the server network. An abstract link represents + the possibility of setting up an LSP, and LSPs may be set up over the + abstract link. + + When looking at a network such as the network shown in Figure 7, the + link from CN1 to CN4 may be an abstract link. It is easy to + advertise it as a link by abstracting the TE information in the + server network, subject to policy. + + The path (i.e., the abstract link) represents the possibility of + establishing an LSP from client network edge to client network edge + across the server network. There is not necessarily a one-to-one + relationship between the abstract link and the LSP, because more than + one LSP could be set up over the path. + + Since the client network nodes do not have visibility into the server + network, they must rely on abstraction information delivered to them + by the server network. That is, the server network will report on + the potential for connectivity. + +4.2.2. The Abstraction Layer Network + + Figure 7 introduces the abstraction layer network. This construct + separates the client network resources (nodes C1, C2, C3, and C4, and + the corresponding links) and the server network resources (nodes CN1, + CN2, CN3, and CN4, and the corresponding links). Additionally, the + architecture introduces an intermediary network layer called the + + + +Farrel, et al. Best Current Practice [Page 23] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + abstraction layer. The abstraction layer contains the client network + edge nodes (C2 and C3), the server network edge nodes (CN1 and CN4), + the client-server links (C2-CN1 and CN4-C3), and the abstract link + (CN1-CN4). + + The client network is able to operate as normal. Connectivity across + the network can be either found or not found, based on links that + appear in the client network 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 network. + + The server network also operates as normal. LSPs across the server + network between client network edges are set up in response to + management commands or in response to signaling requests. + + The abstraction layer consists of the physical links between the two + networks, and also the abstract links. The abstract links are + created by the server network according to local policy and represent + the potential connectivity that could be created across the server + network and that the server network is willing to make available for + use by the client network. Thus, in this example, the diameter of + the abstraction layer network is only three hops, but an instance of + an IGP could easily be run so that all nodes participating in the + abstraction layer (and, in particular, the client network edge nodes) + can see the TE connectivity in the 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 + + + + +Farrel, et al. Best Current Practice [Page 24] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + When the client network needs additional connectivity, it can make a + request to the abstraction layer network. For example, the operator + of the client network may want to create a link from C2 to C3. The + abstraction layer can see the potential path C2-CN1-CN4-C3 and can + set up an LSP C2-CN1-CN4-C3 across the server network and make the + LSP available as a link in the client network. + + Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the + requirements for connectivity in client-server networks and in peer + networks. + +4.2.2.1. Nodes in the Abstraction Layer Network + + Figure 7 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 may appear in the abstraction layer + network. But this is not the case: other nodes from the server + network may be 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 transit node in the server network + (here, the node is CN3) can be exposed as a node in the abstraction + layer network with abstract links connecting it to other nodes in the + abstraction layer network. Of course, in the network shown in + Figure 8, there is little if any value in exposing CN3, but if it had + other abstract links to other nodes in the abstraction layer network + and/or direct connections 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 8: Abstraction Layer Network with Additional Node + + + + + +Farrel, et al. Best Current Practice [Page 25] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + It should be noted that the nodes included in the abstraction layer + network in this way are not "abstract nodes" in the sense of a + virtual node described in Section 3.5. Although it is the case that + the policy point responsible for advertising server network resources + into the abstraction layer network could choose 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 the external interfaces of the + abstract node. + + - Management of changes in the server network that lead to limited + capabilities to reach (cross-connect) across the abstract node. + There has been recent work on control-plane extensions to describe + and operate devices (such as asymmetrical switches) that have + limited cross-connect capabilities [RFC7579] [RFC7580]. These or + similar extensions could be used to represent the same type of + limitations, as they also apply in an abstract node. + +4.2.3. Abstraction in Client-Server Networks + + Figure 9 shows the basic architectural concepts for a client-server + network. The nodes in the client network are C1, C2, CE1, CE2, C3, + and C4, where the client edge (CE) nodes are CE1 and CE2. The core + (server) network nodes are CN1, CN2, CN3, and CN4. The interfaces + CE1-CN1 and CE2-CN4 are the interfaces between the client and server + networks. + + The technologies (switching capabilities) of the client and server + networks may be the same or different. If they are different, the + client network traffic must be tunneled over a server network LSP. + If they are the same, the client network LSP may be routed over the + server network links, tunneled over a server network LSP, or + constructed from the concatenation (stitching) of client network and + server network LSP segments. + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 26] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + : : + Client Network : Server Network : Client Network + : : + -- -- --- --- -- -- + |C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4| + -- -- | | --- --- | | -- -- + | |===|CN1|================|CN4|===| | + | |---| | | |---| | + --- | | --- --- | | --- + | |--|CN2|--|CN3|--| | + --- --- --- --- + + Key + --- Direct connection between two nodes + ... CE-to-CE LSP tunnel + === Potential path across the server network (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 client network. This connection may support TE or + normal IP forwarding. To achieve this, CE1 is to be connected to CE2 + by a link in the client network. 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 CN4-CE2. A three-hop LSP is then established + from CE1 to CE2 that can be presented as a link in the client + network. + + The practicalities of how the CE1-CE2 LSP is carried across the + server network LSP may depend on the switching and signaling options + available in the server network. The CE1-CE2 LSP may be tunneled + down the server network LSP using the mechanisms of a hierarchical + LSP [RFC4206], or the LSP segments CE1-CN1 and CN4-CE2 may be + stitched to the server network LSP as described in [RFC5150]. + + Section 4.2.2 has already introduced the concept of the abstraction + layer network through an example of a simple layered network. But it + may be helpful to expand on the example using a slightly more complex + network. + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 27] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Figure 10 shows a multi-layer network comprising client network nodes + (labeled as Cn for n = 0 to 9) and server network nodes (labeled as + Sn for 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 network in Figure 10 is operated as separate client and server + networks, then the client network topology will appear as shown in + Figure 11. As can be clearly seen, the network is partitioned, and + there is no way to set up an LSP from a node on 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 11: Client Network Topology Showing Partitioned Network + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 28] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + For reference, Figure 12 shows the corresponding server network + topology. + + -- -- -- + |S1|---|S2|----|S3| + --\ --\ --\ + \-- \-- \-- + |S4| |S5|----|S6| + /-- --\ /-- + --/ -- \--/ + |S7|---|S8|----|S9| + -- -- -- + + Figure 12: Server Network Topology + + Operating on the TED for the server network, a management entity or a + software component may apply policy and consider what abstract links + it might offer for use by the client network. To do this, it + obviously needs to be aware of the connections between the 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, 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 of the abstraction layer network in Figure 13. + As can be seen, two of the links must share part of a path (S1-S9 + must share with either S1-S3 or S7-S9). This could be achieved using + distinct resources (for example, separate lambdas) where the paths + are common, but it could also be done using resource sharing. + + -- + |C3| + /-- + -- -- --/ + |C2|---|S1|==========|S3| + -- --\\ --\\ + \\ \\ + \\ \\-- -- + \\ |S6|---|C6| + \\ -- -- + -- -- \\-- -- + |C9|---|S7|=====|S9|---|C0| + -- -- -- -- + + Figure 13: Abstraction Layer Network with Abstract Links + + + + + +Farrel, et al. Best Current Practice [Page 29] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + That would mean that when both paths S1-S3 and S7-S9 carry + client-edge-to-client-edge LSPs, the resources on path S1-S9 are used + and might be depleted to the point that the path is resource + constrained and cannot be used. + + The separate IGP instance running in 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 Path Computation Element (PCE) if one is + present. + + Now the client network is able to make requests to the abstraction + layer network to provide connectivity. In our example, it requests + that C2 be connected to C3 and that C2 be 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 to make the connections. + This yields C2-S1-S3-C3 and C2-S1-S9-C0. + + 2. The management component for the abstraction layer network + instructs C2 to start the signaling process for the new LSPs in + the abstraction layer. + + 3. C2 signals the LSPs for 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 server network may support them by a number of + means, including establishing server network LSPs as tunnels, + depending on the mismatch of technologies between the client and + server networks. For example, S1-S2-S3 and S1-S2-S5-S9 might be + traversed via an LSP tunnel, using LSPs stitched together, or + simply by routing the client network LSP through the server + network. If server network LSPs are needed, they can be signaled + at this point. + + 5. Once any server network LSPs that are needed have been + established, S1 can continue to signal the client-edge-to-client- + edge LSP across the abstraction layer, using the server network + LSPs as either tunnels or stitching segments, or simply routing + through the server network. + + 6. Finally, once the client-edge-to-client-edge LSPs have been set + up, the client network can be informed and can start to advertise + the new TE links C2-C3 and C2-C0. The resulting client network + topology is shown in Figure 14. + + + + + +Farrel, et al. Best Current Practice [Page 30] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + -- -- + |C3|-|C4| + /-- --\ + / \-- + -- --/ |C5| + |C1|---|C2| /-- + -- /--\ --/ -- + / \ |C6|---|C7| + / \ /-- -- + / \--/ + --/ -- |C0| + |C8|---|C9| -- + -- -- + + Figure 14: Connected Client Network with Additional Links + + 7. Now the client network 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 multiple client networks. This + is not an uncommon state of affairs -- for example, when the server + network provides connectivity for multiple customers. + + In this case, the abstraction provided by the server network may vary + considerably according to the policies and commercial relationships + with each customer. This variance would lead to a separate + abstraction layer network maintained to support each client network. + + On the other hand, it may be that multiple client networks are + subject to the same policies and the abstraction can be identical. + In this case, a single abstraction layer network can support more + than one client. + + The choices here are made as an operational issue by the server + network. + +4.2.3.2. 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 + of the client network or may provide parallel (redundant) + connectivity for the 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 create the correct TE links in the client network. + + + +Farrel, et al. Best Current Practice [Page 31] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + That is, the relationship between the client network and the + abstraction layer network should be one to one. + +4.2.4. Abstraction in 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 + 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 + may simply traverse the path defined by the abstract links across the + various peer networks or may utilize stitching of LSP segments that + each traverse a network along the path of an abstract link. If the + network switching technologies support or necessitate the use of LSP + hierarchies, the end-to-end LSP may be tunneled across each network + using hierarchical LSPs that each traverse a network along the path + of an abstract link. + + : : : + Network A : Network B : Network C : Network D + : : : + -- -- -- -- -- -- -- -- -- -- + |A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2| + -- -- | | -- | | | | -- | | -- -- + | |========| | | |========| | + -- -- -- -- + + Key + --- Direct connection between two nodes + === Abstract link across transit network + + Figure 15: Architecture for Peering + + Peer networks exist in many situations in the Internet. Packet + networks may peer as IGP areas (levels) or as ASes. Transport + networks (such as optical networks) may peer to provide + concatenations of optical paths through single-vendor environments + (see Section 6). Figure 16 shows a simple example of three peer + networks (A, B, and C) each comprising a few nodes. + + + +Farrel, et al. Best Current Practice [Page 32] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 + their topologies or TE capabilities for scaling and confidentiality + reasons. That means, in our example, that computing a path from A1 + to C4 can be impossible without the aid of cooperating PCEs or some + form of crankback. + + But it is possible to produce abstract links for reachability across + transit peer networks and to create an abstraction layer network. + That network can be enhanced with specific reachability information + if a destination network is partitioned, as is the case with + Network C in Figure 16. + + Suppose that Network B decides to offer three abstract links B1-B3, + B4-B3, and B4-B6. The abstraction layer network could then be + constructed to look like the network 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 to that described in Section 4.2.3, Network A + can request connectivity to Network C, and abstract links can be + advertised that connect the edges of the two networks and that can be + used to carry LSPs that traverse both networks. Furthermore, if + + + +Farrel, et al. Best Current Practice [Page 33] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Network C is partitioned, reachability information can be exchanged + to allow Network A to select the correct abstract link, as shown in + Figure 18. + + Network A : Network C + : + -- -- -- : -- -- + |A1|---|A2|----|A3|=========|C1|.....|C2| + -- --\ /-- : -- -- + \--/ : + |A4| : + --\ : + -- \-- : -- -- + |A5|---|A6|=========|C3|.....|C4| + -- -- : -- -- + + 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 the networks themselves being arranged in + a mesh (for example, A6 might connect to B4 and C1 in Figure 17). + + These additional complexities can be handled gracefully by the + abstraction layer network model. + + Further examples of abstraction in peer networks can be found in + Sections 6 and 8. + +4.3. Considerations for Dynamic Abstraction + + It is possible 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 + client-edge-to-client-edge LSPs to provide new links in the client + network. Such fluidity is, however, to be treated with caution. In + particular, in the case of client-server networks of differing + technologies where hierarchical server network LSPs are used, this + caution is needed for three reasons: there may be longer turn-up + times for connections in some server networks; the server networks + are likely to be sparsely connected; and expensive physical resources + will only be deployed where there is believed to be a need for them. + More significantly, the complex commercial, policy, and + administrative relationships that may exist between client and server + network operators mean that stability is more likely to be the + desired operational practice. + + + + + +Farrel, et al. Best Current Practice [Page 34] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Thus, proposals for fully automated multi-layer networks based on + this architecture may be regarded as forward-looking topics for + research both in terms of network stability and with regard to + economic impact. + + However, some elements of automation should not be discarded. A + server network may automatically apply policy to determine the best + set of abstract links to offer and 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 abstraction layer. And, once policies have been + configured, the whole system should be able to operate independently + of operator control (which is not to say that the operator will not + have the option of exerting control at every step in the process). + +4.4. Requirements for Advertising Links and Nodes + + The abstraction layer network is "just another network layer". The + links and nodes in the network need to be advertised along with their + associated TE information (metrics, bandwidth, etc.) so that the + topology is disseminated and so that routing decisions can be made. + + This requires a routing protocol running between the nodes in the + abstraction layer network. Note that this routing information + exchange could be piggybacked on an existing routing protocol + instance (subject to different switching capabilities applying to the + links in the different networks, or to adequate address space + separation) or use a new instance (or even a new protocol). Clearly, + the information exchanged is only information that has been created + as part of the abstraction function according to policy. + + It should be noted that in many cases the abstract link represents + the potential for connectivity across the server network but that + no such connectivity exists. In this case, we may ponder how the + routing protocol in the abstraction layer 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 abstraction layer nodes so that the routing protocol + messages can flow. The answer is that control-plane connectivity + already exists in the server network and on the client-server edge + links, and this can be used to carry the routing protocol messages + for the abstraction layer network. The same consideration applies to + the advertisement, in the client network, of the potential + connectivity that the abstraction layer network can provide, although + it may be more normal to establish that connectivity before + advertising a link in the client network. + + + + +Farrel, et al. Best Current Practice [Page 35] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +4.5. 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 the + client network, yet the same address may have a different meaning in + 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 the interfaces between the network layers. That mapping + requires configuration so that, for example, when the server network + announces an abstract link from A to B, the abstraction layer network + must recognize that A and B are server network 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 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 that of the client network. + + This form of address mapping will become particularly important in + cases where one abstraction layer network is constructed from + connectivity in multiple server networks, or where one abstraction + layer network provides connectivity for multiple client networks. + +5. Building on Existing Protocols + + This section is non-normative and is not intended to prejudge a + solutions framework or any applicability work. It does, however, + very briefly serve to note the existence of protocols that could be + examined for applicability to serve in realizing the model described + in this document. + + The general principle of protocol reuse is preferred over the + invention of new protocols or additional protocol extensions, and 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 PCEs. This has many + benefits in network stability, time to deployment, and operator + training. + + It is recognized, however, that existing protocols are unlikely to be + immediately suitable 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, a new protocol can be preferable to a messy hack of an + existing protocol. + + + +Farrel, et al. Best Current Practice [Page 36] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +5.1. BGP-LS + + BGP - Link State (BGP-LS) is a set of extensions to BGP, as described + in [RFC7752]. Its purpose is to announce topology information from + one network to a "northbound" consumer. Application of BGP-LS to + date has focused on a mechanism to build a TED for a PCE. However, + BGP's mechanisms would also serve well to advertise abstract links + from a server network into the abstraction layer network or to + advertise potential connectivity from the abstraction layer network + to the client network. + +5.2. IGPs + + Both OSPF and IS-IS have been extended through a number of RFCs to + advertise TE information. Additionally, both protocols are capable + of running in a multi-instance mode either as ships that pass in the + night (i.e., completely separate instances using different address + spaces) or as dual instances on the same address space. This means + that either OSPF or IS-IS could probably be used as the routing + protocol in the abstraction layer network. + +5.3. RSVP-TE + + RSVP-TE signaling can be used to set up all TE LSPs demanded by this + model, without the need for any protocol extensions. + + If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can + be used to carry LSPs over the server network, again without needing + any protocol extensions. + + Furthermore, the procedures in [RFC6107] allow the dynamic signaling + of the purpose of 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 should be advertised and can also agree + on the addressing to be said to identify the 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, with only + minor modifications, to provide a solution. + + + + + + + +Farrel, et al. Best Current Practice [Page 37] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + A server network can be operated using GMPLS routing and signaling + protocols. Using information gathered from the routing protocol, a + TED can be 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 abstraction layer network. + + The server network can now use BGP-LS to advertise a topology of + links and nodes to form the abstraction layer network. This + information would most likely be advertised from a single point of + control that made all of the abstraction decisions, but the function + could be distributed to multiple server network edge nodes. The + information can be advertised by BGP-LS to multiple points within the + abstraction layer (such as all client network edge nodes) or to a + single controller. + + Multiple server networks may advertise information that is used to + construct an abstraction layer network, and one server network may + advertise different information in different instances of BGP-LS to + form different abstraction layer networks. Furthermore, in the 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 VPNs) of the exported information. + + Extensions may be made to BGP-LS to allow advertisement of Macro + Shared Risk Link Groups (MSRLGs) (Appendix B.1) and the + identification of mutually exclusive links (Appendix B.2), 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 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 GMPLS + routing protocol will be beneficial for collecting and correlating + the routing information 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 that the control + plane of the abstraction layer network must run in an out-of-band + control network because the data-bearing links might not yet have + been established via connections in the server network. + + + + + + + + +Farrel, et al. Best Current Practice [Page 38] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 the client network, and will take + four steps: + + - First, it will compute a path across the abstraction layer + network. + + - Then, if support of the abstract links requires the use of + server network LSPs for tunneling or stitching and if those LSPs + 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 will inform the client + network of the existence of the new client network link. + + This last step can be achieved by either (1) coordination of the + end points of the LSPs that span the abstraction layer (these points + are client network edge nodes) using mechanisms such as those + described in [RFC6107] or (2) using BGP-LS from a central controller. + + Once the 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 network. + + Sections 6, 7, and 8 discuss the applicability of this architecture + to different network types and problem spaces, while Section 9 gives + some advice about scoping future work. Section 10 ("Manageability + Considerations") is particularly relevant in the 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. Application of the Architecture to Optical Domains and Networks + + Many optical networks are arranged as a set of small domains. Each + domain is a cluster of nodes, usually from the same equipment vendor + and with the same properties. The domain may be constructed as a + mesh or a ring, or maybe as an interconnected set of rings. + + The network operator seeks to provide end-to-end connectivity across + a network constructed 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 the operational control of a Network Management System (NMS). + + + +Farrel, et al. Best Current Practice [Page 39] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + In this way, an end-to-end path may be commissioned by the OSS + instructing each NMS, and the NMSes setting up the path fragments + across the domains. + + However, in a system that uses a control plane, there is a need for + integration between the domains. + + Consider a simple domain, D1, as shown in Figure 19. In this case, + nodes A through F are arranged in a topological ring. Suppose that + there is a control plane in use in this domain and that OSPF is used + as the TE routing protocol. + + ----------------- + | D1 | + | B---C | + | / \ | + | / \ | + | A D | + | \ / | + | \ / | + | F---E | + | | + ----------------- + + Figure 19: A Simple Optical Domain + + Now consider that the operator's network is built from a mesh of such + domains, D1 through D7, as shown in Figure 20. It is possible that + these domains share a single, common instance of OSPF, in which case + there is nothing further to say because that OSPF instance will + distribute sufficient information to build a single TED spanning the + whole network, and an end-to-end path can be computed. A more likely + scenario is that each domain is running its own OSPF instance. In + this case, each is able to handle the peculiarities (or, rather, + advanced functions) of each vendor's equipment capabilities. + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 40] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + ------ ------ ------ ------ + | | | | | | | | + | D1 |---| D2 |---| D3 |---| D4 | + | | | | | | | | + ------\ ------\ ------\ ------ + \ | \ | \ | + \------ \------ \------ + | | | | | | + | D5 |---| D6 |---| D7 | + | | | | | | + ------ ------ ------ + + Figure 20: A Mesh of Simple Optical Domains + + The question now is how to combine the multiple sets of information + distributed by the different OSPF instances. Three possible models + suggest themselves, based on pre-existing routing practices. + + o In the first model (the area-based model), each domain is treated + as a separate OSPF area. The end-to-end path will be specified to + traverse multiple areas, and each area will be left to determine + the path across the nodes in the area. The feasibility of an + end-to-end path (and, thus, the selection of the sequence of + areas and their interconnections) can be derived using + hierarchical PCEs. + + This approach, however, fits poorly with established use of the + OSPF area: in this form of optical network, the interconnection + points between domains are likely to be links, and the mesh of + domains is far more interconnected and unstructured than we are + used to seeing in the normal area-based routing paradigm. + + Furthermore, while hierarchical PCEs may be able to resolve this + type of network, the effort involved may be considerable for 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 + specified to traverse multiple ASes, and each AS will be left to + determine the path across the nodes in that AS. + + This model sits more comfortably with the established routing + paradigm but causes a massive escalation of ASes in the global + Internet. It would, in practice, require that the operator use + private AS numbers [RFC6996], of which there are plenty. + + + + + + +Farrel, et al. Best Current Practice [Page 41] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Then, as suggested in the area-based model, hierarchical PCEs + could be used to determine the feasibility of an end-to-end path + and to derive the sequence of domains and the points of + interconnection to use. But just as in the area-based model, the + scalability of this model using a hierarchical PCE must be + questioned, given the sheer number of ASes and their + interconnectivity. + + Furthermore, determining the mesh of domains (i.e., the inter-AS + connections) conventionally requires the use of BGP as an + inter-domain routing protocol. However, not only is BGP not + normally available on optical equipment, but this approach + indicates that the TE properties of the 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 Automatically Switched Optical Network + (ASON) model) follows the architectural model set out by the ITU-T + [G.8080] and uses the routing protocol extensions described in + [RFC6827]. In this model, the 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 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 of OSPF. Routing advertisements flow "upward" + from the domains to the high-level OSPF instance, giving it a full + view of the whole network and allowing end-to-end paths to be + computed. Routing advertisements may also flow "downward" from + the network-wide OSPF instance to any one domain so that it can + see the connectivity of the whole network. + + Although architecturally satisfying, this model suffers from + having to handle the different characteristics of different + equipment vendors. The advertisements coming 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 of domains, each with many entry and exit + points and each with network resources that are continually being + updated, reduces to the same problem, as noted in the virtual link + model. Furthermore, in the event that the domains are under the + control of different administrations, the domains would not want + to distribute the details of their topologies and TE resources. + + + + +Farrel, et al. Best Current Practice [Page 42] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Practically, this third model turns out to be very close to the + methodology described in this document. As noted in Section 6.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. [RFC6827] even notes that some forms of aggregation + may be appropriate. Thus, we can apply the following simplifications + to the mechanisms defined in [RFC6827]: + + - Zero information is imported to low-level domains. + + - Low-level domains export only abstracted links as defined in this + document and according to local abstraction policy, and with + appropriate removal of vendor-specific information. + + - There is no need to formally define routing levels within OSPF. + + - Export of abstracted links from the 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 seen that the framework defined + in this document can be constructed from the architecture discussed + in [RFC6827], but without needing any of the protocol extensions + defined in that document. Thus, using the terminology and concepts + already established, the problem may be solved as shown 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 + + + +Farrel, et al. Best Current Practice [Page 43] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +7. Application of the Architecture to the User-Network Interface + + The User-Network Interface (UNI) is an important architectural + concept in many implementations and deployments of client-server + networks, especially those where the client and server network have + different technologies. The UNI is described in [G.8080], and 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, 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 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", and the server network. The so-called + Ethernet service network consists of links comprising the UNI links + and the tunnels across the server network, and nodes comprising the + client network edge nodes and various server network 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, the client edge nodes taking the role of + UNI Client-side (UNI-C) nodes, and the server edge nodes acting as + the UNI Network-side (UNI-N) nodes. + + + + + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 44] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Client Client + Network +----------+ +-----------+ Network + -------------+ | | | | +------------- + +----+ | | +-----+ | | +-----+ | | +----+ + ------+ | | | | | | | | | | | | +------ + ------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------ + | | | +--+--| +-+-+ | | +--+-----+-+ | + +----+ | | | +--+--+ | | | +--+--+ | | +----+ + | | | | | | | | | | + -------------+ | | | | | | | | +------------- + | | | | | | | | + -------------+ | | | | | | | | +------------- + | | | +--+--+ | | | +--+--+ | | + +----+ | | | | | | +--+--+ | | | +----+ + ------+ +-+--+ | | CN +-+----+--+ CN | | | | +------ + ------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------ + | | | | +-----+ | | +-----+ | | | | + +----+ | | | | | | +----+ + | +----------+ |-----------+ | + -------------+ Server Networks +------------- + Client UNI UNI Client + Network <-----> <-----> Network + Scope of This Document + + Legend: EN - Client Network Edge Node + CN - Server Network (Core) Node + + Figure 22: Ethernet UNI Reference Model + + An issue that is often raised relates to how a dual-homed client + network 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, to provide protection). However, in the model + described in this network, the edge node (the UNI-C node) is part of + the abstraction layer network 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. + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 45] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +8. Application of the Architecture to L3VPN Multi-AS Environments + + Serving Layer 3 VPNs (L3VPNs) 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, 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, 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 Autonomous System Border Routers + (ASBRs)) at the edges of the multiple server networks, and the PE-PE + (maybe inter-AS) links. This gives rise to the architecture shown in + Figure 23. + + The policy for adding abstract links to the abstraction layer network + will be driven substantially by the needs of the VPN. Thus, when a + new VPN site is added and the existing abstraction layer network + cannot support the required connectivity, a new abstract link will be + created out of the underlying network. + + ........... ............. + VPN Site : : VPN Site + -- -- : : -- -- + |C1|-|CE| : : |CE|-|C2| + -- | | : : | | -- + | | : : | | + | | : : | | + | | : : | | + | | : -- -- -- -- : | | + | |----|PE|=========|PE|---|PE|=====|PE|----| | + -- : | | | | | | | | : -- + ........... | | | | | | | | ............ + | | | | | | | | + | | | | | | | | + | | | | | | | | + | | - - | | | | - | | + | |-|P|-|P|-| | | |-|P|-| | + -- - - -- -- - -- + + Figure 23: The Abstraction Layer Network for a Multi-AS VPN + + + + + + +Farrel, et al. Best Current Practice [Page 46] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 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 for the UNI discussed in Section 7, the issue of + dual-homing of VPN sites is a function of the abstraction layer + network and so is just a normal routing problem in that network. + +9. Scoping Future Work + + This section is provided to help guide the work on this problem. The + overarching view is that it is important to limit and focus the work + on those things that are core and necessary to achieve the main + function, and to not attempt to add unnecessary features or to + over-complicate the architecture or the solution by attempting to + address marginal use cases or corner cases. This guidance is + non-normative for this architecture description. + +9.1. Limiting Scope to Only Part of the Internet + + The scope of the use cases and problem statement in this document is + limited to "some small set of interconnected domains." In + particular, it is not the objective of this work to turn the whole + Internet into one large, interconnected TE network. + +9.2. Working with "Related" Domains + + Starting with this subsection, the intention of this work is to solve + the TE interconnectivity for only "related" domains. Such domains + may be under common administrative operation (such as IGP areas + within a single AS, or ASes belonging to a single operator) or may + have a direct commercial arrangement for the sharing of TE + information to provide specific services. Thus, in both cases, there + is a strong opportunity for the application of policy. + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 47] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +9.3. Not Finding Optimal Paths in All Situations + + As has been well described in this document, abstraction necessarily + involves compromises and removal of information. That means that it + is not possible to guarantee that an end-to-end path over + interconnected TE domains follows the absolute optimal (by any + measure of optimality) path. This is taken as understood, and future + work should not attempt to achieve such paths, which can only be + found by a full examination of all network information across all + connected networks. + +9.4. Sanity and Scaling + + All of the 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 work + will be immediately (or even soon) extended to cover many large + interconnected domains. Obviously, the solution should, as far as + possible, be designed to be extensible and scalable; however, it is + also reasonable to make trade-offs in favor of utility and + simplicity. + +10. Manageability Considerations + + Manageability should not be a significant additional burden. Each + layer in the network model can, and should, be managed independently. + + That is, each client network will run its own management systems and + tools to manage the nodes and links in the client network: each + client network link that uses an abstract link will still be + available for management in the client network as any other link. + + Similarly, each server network will run its own management systems + and tools to manage the nodes and links in that network just as + normal. + + Three issues remain for consideration: + + - How is the abstraction layer network managed? + + - How is the interface between the client network and the + abstraction layer network managed? + + - How is the interface between the abstraction layer network and the + server network managed? + + + + + + +Farrel, et al. Best Current Practice [Page 48] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +10.1. Managing the Abstraction Layer Network + + Management of the abstraction layer network differs from the client + and server networks because not all of the links that are visible in + the TED are real links. That is, it is not possible to run + Operations, Administration, and Maintenance (OAM) on the links that + constitute the potential of a link. + + Other than that, however, the management of the abstraction layer + network should be essentially the same. Routing and signaling + protocols can be run in the abstraction layer (using out-of-band + channels for links that have not yet been established), and a + centralized TED can be constructed and used to examine the + availability and status of the links and nodes in the network. + + Note that different deployment models will place the "ownership" of + the abstraction layer network differently. In some cases, the + abstraction layer network will be constructed by the operator of the + server network and run by that operator as a 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 network run by + the operator of the client network. And it is feasible that a + business model could be built where a third-party operator manages + the abstraction layer network, constructing it from the connectivity + available in multiple server networks and facilitating connectivity + for multiple client networks. + +10.2. Managing Interactions of Abstraction Layer and Client Networks + + The interaction between the client network and the abstraction layer + network is a management task. It might be automated (software + driven), or it might require manual intervention. + + This is a two-way interaction: + + - The client network can express the need for additional + connectivity. For example, the client network may try, and fail, + to find a path across the client network and may request + additional, specific connectivity (this is similar to the + situation with the Virtual Network Topology Manager (VNTM) + [RFC5623]). Alternatively, a more proactive client network + management system may monitor traffic demands (current and + predicted), network usage, and network "hot spots" and may request + changes in connectivity by both releasing unused links and + requesting new links. + + + + + + +Farrel, et al. Best Current Practice [Page 49] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + - 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 network or can be driven by + processes within the abstraction layer (perhaps reorganizing the + use of server network resources). In any case, the presentation + of new links to the client network is heavily subject to policy, + since this is both operationally key to the success of this + architecture and the central plank of the commercial model + described in this document. Such policies belong to the operator + of 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 the link + end points (which are nodes in the client network) such that it + appears and can be advertised as a link in the client network. + + In all cases, it is important that the operators of 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 that network are + "real" physical links and which links are presented by the + abstraction layer network. + +10.3. Managing Interactions of Abstraction Layer and Server Networks + + The interactions between the abstraction layer network and the server + network are similar to those described in Section 10.2, but there is + a difference in that the server network is more likely to offer up + connectivity and the abstraction layer network is less likely to ask + for it. + + That is, the server network will, according to policy that may + include commercial relationships, offer the abstraction layer network + a "set" of potential connectivity that the abstraction layer network + can treat as links. This server network policy will include: + + - how much connectivity to offer + + - what level of server network redundancy to include + + - how to support the use of the abstract links + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 50] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + This process of offering links from the server network may include a + mechanism to indicate which links have been pre-established in the + server network and can include other properties, such as: + + - link-level protection [RFC4202] + + - SRLGs and MSRLGs (see Appendix B.1) + + - mutual exclusivity (see Appendix B.2) + + The abstraction layer network needs a mechanism to tell the server + network which links it is using. This mechanism could also include + the ability to request additional connectivity from the server + network, although it seems most likely that the server network will + already have presented as much connectivity as it is physically + capable of, subject to the constraints of policy. + + Finally, the server network 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 operators of both networks are able + to track the requests and responses, and the operator of the server + network should be able to see which links are in use. + +11. Security Considerations + + Security of signaling and routing protocols is usually administered + and achieved within the boundaries of a domain. Thus, 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 the + domain from outside. + + In this context, additional security considerations arising from this + document relate to the 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 UNI-N, between BGP-LS speakers, or between + peer domains). Thus, the security that needs to be given additional + attention for inter-domain TE concentrates on authentication of + peers; assertion that messages have not been tampered with; and, 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 Appendix A, which are + likely to provide the foundation for solutions to this architecture, + + + + +Farrel, et al. Best Current Practice [Page 51] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + already include such protection and also can be run over protected + transports such as IPsec [RFC6071], Transport Layer Security (TLS) + [RFC5246], and the TCP Authentication Option (TCP-AO) [RFC5925]. + + It is worth noting that the control plane of the abstraction layer + network is likely to be out of band. That is, 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), and the security mechanisms can be applied to the protocols + operating in the out-of-band network. + +12. Informative References + + [G.8080] International Telecommunication Union, "Architecture for + the automatically switched optical network", ITU-T + Recommendation G.8080/Y.1304, February 2012, + . + + [GMPLS-ENNI] + Bryskin, I., Ed., Doonan, W., Beeram, V., Ed., Drake, J., + Ed., Grammel, G., Paul, M., Kunze, R., Armbruster, F., + Margaria, C., Gonzalez de Dios, O., and D. Ceccarelli, + "Generalized Multiprotocol Label Switching (GMPLS) + External Network Network Interface (E-NNI): Virtual Link + Enhancements for the Overlay Model", Work in Progress, + draft-beeram-ccamp-gmpls-enni-03, September 2013. + + [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. + McManus, "Requirements for Traffic Engineering Over MPLS", + RFC 2702, DOI 10.17487/RFC2702, September 1999, + . + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + . + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, DOI 10.17487/RFC3473, January 2003, + . + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + DOI 10.17487/RFC3630, September 2003, + . + + + + +Farrel, et al. Best Current Practice [Page 52] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, + DOI 10.17487/RFC3945, October 2004, + . + + [RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, + Ed., "Requirements for Inter-Area MPLS Traffic + Engineering", RFC 4105, DOI 10.17487/RFC4105, June 2005, + . + + [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi-Protocol Label + Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, + 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, + DOI 10.17487/RFC4206, October 2005, + . + + [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, + "Generalized Multiprotocol Label Switching (GMPLS) + User-Network Interface (UNI): Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Support for the + Overlay Model", RFC 4208, DOI 10.17487/RFC4208, + October 2005, . + + [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS + Inter-Autonomous System (AS) Traffic Engineering (TE) + Requirements", RFC 4216, DOI 10.17487/RFC4216, + November 2005, . + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + . + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, + February 2006, . + + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + + + + + +Farrel, et al. Best Current Practice [Page 53] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework + for Inter-Domain Multiprotocol Label Switching Traffic + Engineering", RFC 4726, DOI 10.17487/RFC4726, + November 2006, . + + [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 + Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, + April 2007, . + + [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - + Extension to Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, + April 2007, . + + [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., + and G. Ash, "Crankback Signaling Extensions for MPLS and + GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, + . + + [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, + "Label Switched Path Stitching with Generalized + Multiprotocol Label Switching Traffic Engineering + (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, + February 2008, . + + [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A + Per-Domain Path Computation Method for Establishing + Inter-Domain Traffic Engineering (TE) Label Switched Paths + (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, + . + + [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based + Auto-Discovery for Layer-1 VPNs", RFC 5195, + DOI 10.17487/RFC5195, June 2008, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., + Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", + RFC 5251, DOI 10.17487/RFC5251, July 2008, + . + + + + + + +Farrel, et al. Best Current Practice [Page 54] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN + Auto-Discovery", RFC 5252, DOI 10.17487/RFC5252, + July 2008, . + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, + October 2008, . + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + . + + [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, + "A Backward-Recursive PCE-Based Computation (BRPC) + Procedure to Compute Shortest Constrained Inter-Domain + Traffic Engineering Label Switched Paths", RFC 5441, + DOI 10.17487/RFC5441, April 2009, + . + + [RFC5523] Berger, L., "OSPFv3-Based Layer 1 VPN Auto-Discovery", + RFC 5523, DOI 10.17487/RFC5523, April 2009, + . + + [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource + Reservation Protocol (RSVP) Extensions for Path Key + Support", RFC 5553, DOI 10.17487/RFC5553, 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, DOI 10.17487/RFC5623, + September 2009, . + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, . + + [RFC6005] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support + for Metro Ethernet Forum and G.8011 User Network Interface + (UNI)", RFC 6005, DOI 10.17487/RFC6005, October 2010, + . + + + + + +Farrel, et al. Best Current Practice [Page 55] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and + Internet Key Exchange (IKE) Document Roadmap", RFC 6071, + DOI 10.17487/RFC6071, February 2011, + . + + [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for + Dynamically Signaled Hierarchical Label Switched Paths", + RFC 6107, DOI 10.17487/RFC6107, February 2011, + . + + [RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the + Path Computation Element Architecture to the Determination + of a Sequence of Domains in MPLS and GMPLS", RFC 6805, + DOI 10.17487/RFC6805, November 2012, + . + + [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, + Ed., "Automatically Switched Optical Network (ASON) + Routing for OSPFv2 Protocols", RFC 6827, + DOI 10.17487/RFC6827, January 2013, + . + + [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for + Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, + July 2013, . + + [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path + Computation Element Architecture", RFC 7399, + DOI 10.17487/RFC7399, October 2014, + . + + [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and + J. Han, "General Network Element Constraint Encoding for + GMPLS-Controlled Networks", RFC 7579, + DOI 10.17487/RFC7579, June 2015, + . + + [RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, + "OSPF-TE Extensions for General Network Element + Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, + . + + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and + S. Ray, "North-Bound Distribution of Link-State and + Traffic Engineering (TE) Information Using BGP", RFC 7752, + DOI 10.17487/RFC7752, March 2016, + . + + + + +Farrel, et al. Best Current Practice [Page 56] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + [RSVP-TE-EXCL] + Ali, Z., Ed., Swallow, G., Ed., Zhang, F., Ed., and D. + Beller, Ed., "Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE) Path Diversity using Exclude Route", + Work in Progress, draft-ietf-teas-lsp-diversity-05, + June 2016. + + [RSVP-TE-EXT] + Zhang, F., Ed., Gonzalez de Dios, O., Ed., Hartley, M., + Ali, Z., and C. Margaria, "RSVP-TE Extensions for + Collecting SRLG Information", Work in Progress, + draft-ietf-teas-rsvp-te-srlg-collect-06, May 2016. + + [RSVP-TE-METRIC] + Ali, Z., Swallow, G., Filsfils, C., Hartley, M., Kumaki, + K., and R. Kunze, "Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE) extension for recording TE Metric of + a Label Switched Path", Work in Progress, + draft-ietf-teas-te-metric-recording-04, March 2016. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 57] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +Appendix A. Existing Work + + This appendix briefly summarizes relevant existing work that is used + to route TE paths across multiple domains. It is non-normative. + +A.1. Per-Domain Path Computation + + The mechanism for per-domain 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 the path across the domain but that details + regarding the path in the next domain are left to the next domain + entry point. The computation may be performed directly by the entry + point or may be delegated to 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 be used effectively, with a little operational guidance. + + For example, RSVP-TE [RFC3209] includes the concept of a "loose hop" + in the explicit path that is signaled. This allows the original + request for an LSP to list the domains or even domain entry points to + include on the path. Thus, in the example in Figure 1, the source + can be told to use interconnection x2. Then, the source computes the + path from itself to x2 and 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 to make TE routing + attempt to follow inter-domain IP routing. Thus, in 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 would use that to compute and then signal a + path for Domain A. Each domain in turn would apply the same approach + so that the path is progressively computed and signaled domain by + domain. + + Although the per-domain approach has many issues and drawbacks in + terms of achieving optimal (or, indeed, any) paths, it has been the + mainstay of inter-domain LSP setup to date. + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 58] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +A.2. Crankback + + Crankback addresses one of the main issues with per-domain path + computation: What happens when an initial path is selected that + cannot be completed toward the destination? For example, what + happens if, in Figure 2, the source attempts to route the path + through interconnection x2 but Domain C does not have the right TE + resources or connectivity to route the path further? + + Crankback for MPLS-TE and GMPLS networks is described in [RFC4920] + and is based on a concept similar to the 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 domain, it returns an error message in the signaling + protocol that states where the blockage occurred (link identifier, + node identifier, domain identifier, etc.) and gives some clues about + what caused 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 it upstream to a previous computation point. + + Crankback is a very powerful mechanism and can be used to find an + end-to-end path in a multi-domain network if one exists. + + On the other hand, crankback can be quite resource-intensive, as + signaling messages and path setup attempts may "wander around" in the + network, attempting to find the correct path for a long time. Since + (1) RSVP-TE signaling ties up network resources for partially + established LSPs, (2) network conditions may be in flux, and (3) most + particularly, 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 that the optimal path will be found. (Note that + there have been some academic proposals to use signaling-like + techniques to explore the whole network 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 + example of per-domain path computation (see Appendix A.1), both the + source node and each domain entry point are PCEs. On the other hand, + the PCE can also be realized as a separate network element (a server) + to which computation requests can be sent using the Path Computation + Element Communication Protocol (PCEP) [RFC5440]. + + + +Farrel, et al. Best Current Practice [Page 59] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + Each PCE is responsible for computations within a domain and has + visibility of the attributes within that domain. This immediately + enables per-domain path computation with the opportunity to offload + complex, CPU-intensive, or memory-intensive computation functions + from routers in the network. But the use of PCEs in this way + does not solve any of the problems articulated in Appendices A.1 + and A.2. + + Two significant mechanisms for cooperation between PCEs have been + described. These mechanisms are intended to specifically address the + problems of computing optimal end-to-end paths 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 the + domain entry point (or source node) to the domain exit point (or + destination node) and shares the information with its upstream + neighbor PCE, which is able to build a tree of possible paths + rooted at the destination. The PCE in the source domain can + select the optimal path. + + BRPC is sometimes described as "crankback at computation time". + It is capable of determining the optimal path in a multi-domain + network but depends on knowing the domain that contains the + destination node. Furthermore, the mechanism can become quite + complicated and can involve a lot of data in a mesh of + interconnected domains. Thus, BRPC is most often proposed for a + simple mesh of domains and specifically for a path that will cross + a known sequence of domains, but where there may be a choice of + domain interconnections. In 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 make that choice itself), but BRPC could + be used very effectively to select between interconnections x1 and + x2 in Figure 1. + + - The Hierarchical PCE (H-PCE) [RFC6805] mechanism offers a parent + PCE that is responsible for navigating a path across the domain + mesh and 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. Furthermore, it raises the + question of who operates the parent PCE, especially in networks + where the domains are under different administrative and + commercial control. + + + +Farrel, et al. Best Current Practice [Page 60] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + It should also be noted that [RFC5623] discusses how PCEs are used in + a multi-layer network with coordination between PCEs operating at + each network layer. Further issues and considerations regarding the + use of PCEs can be found in [RFC7399]. + +A.4. GMPLS UNI and Overlay Networks + + [RFC4208] defines the GMPLS User-Network Interface (UNI) to present a + routing boundary between an overlay (client) network and the server + network, i.e., the client-server interface. In the client network, + the nodes connected directly to the server network are known as edge + nodes, while the nodes in the server network 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 the routing + protocol instance that runs among the core nodes. Thus, the UNI + allows access to, and limited control of, the core nodes by edge + nodes that are unaware of the topology of the core nodes. This + respects the operational and layer boundaries while scaling the + network. + + [RFC4208] does not define any routing protocol extension for the + interaction between core and edge nodes but allows for the exchange + of reachability information between them. In terms of a VPN, the + client network can be considered as the customer network comprised of + a number of disjoint sites, and the edge nodes match the VPN CE + nodes. Similarly, the provider network in the VPN model is + equivalent to the server network. + + [RFC4208] is, therefore, a signaling-only solution that allows edge + nodes to request connectivity across the server network and leaves + the server network to select the paths for the LSPs as they traverse + the core nodes (setting up hierarchical LSPs if necessitated by the + technology). This solution is supplemented by a number of signaling + extensions, such as [RFC4874], [RFC5553], [RSVP-TE-EXCL], + [RSVP-TE-EXT], and [RSVP-TE-METRIC], to give the edge node more + control over the path within the server network and by allowing the + edge nodes to supply additional constraints on the path used in the + server network. Nevertheless, in this UNI/overlay model, the edge + node has limited information regarding precisely what LSPs could be + set up across the server network and what TE services (diverse routes + for end-to-end protection, end-to-end bandwidth, etc.) can be + supported. + + + + + + + + +Farrel, et al. Best Current Practice [Page 61] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +A.5. Layer 1 VPN + + A Layer 1 VPN (L1VPN) is a service offered by a Layer 1 server + network to provide Layer 1 connectivity (Time-Division Multiplexing + (TDM), Lambda Switch Capable (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 and type of connectivity. In the L1VPN context, three + different service models have been defined, classified by the + semantics of information exchanged over the customer interface: the + management-based model, the signaling-based (a.k.a. basic) service + model, and the signaling and routing (a.k.a. enhanced) service model. + + 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 (basic) service model [RFC5251], the CE-PE + interface allows only for signaling message exchange, and the + provider network does not export any routing information about the + server 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 + ports on the PE. This service model is much in line with GMPLS UNI + as defined in [RFC4208]. + + In the signaling and routing (enhanced) service model, there is an + additional limited exchange of routing information over the CE-PE + interface between the provider network and the customer network. The + enhanced model considers four different types of service models, + namely the overlay extension, virtual node, virtual link, and per-VPN + service models. All of these represent particular cases of the TE + information aggregation and representation. + +A.6. Policy and Link Advertisement + + Inter-domain networking relies on policy and management input to + coordinate the allocation of resources under different administrative + control. [RFC5623] introduces a functional component called the VNTM + for 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 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 + + + +Farrel, et al. Best Current Practice [Page 62] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + dynamic signaling, then there is need for the end points to exchange + the link properties that they should advertise within the client + network, and in the case of support for more than one client network, + it will be necessary to indicate which client network or networks can + use the link. This capability it provided in [RFC6107]. + +Appendix B. Additional Features + + This appendix describes additional features that may be desirable and + that can be achieved within this architecture. It is non-normative. + +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 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 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 + it can be hard for 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 network 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 + considering the two abstract links S1-S3 and S1-S9, there is no way + for the client network to know whether 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 + network 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 in a network. + However, this can produce a scalability problem in a multi-layer + network that equates to advertising in the client network the server + network route of each TE link. + + Macro SRLGs (MSRLGs) address this scaling problem and 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 network are advertised as having the same MSRLG, rather than + advertising each SRLG for each resource on each path in the server + + + + +Farrel, et al. Best Current Practice [Page 63] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + network. This saving is possible because the abstract links are + formulated on behalf of the server network 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 network (S1-S4-S7-S8-S9). It would + be possible for the client network request for C2-C0 connectivity to + also ask that the path be maximally disjoint from path C2-C3. + Although nothing can be done about the shared link C2-S1, the + abstraction layer could make a request to use link S1-S9 in a way + that is diverse from the use of link S1-S3, and this request could be + honored if the server network policy allows it. + + Note that SRLGs and MSRLGs may be very hard to describe in the case + of multiple server 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 cannot be used at the same time. This arises + when the potentiality of the links is indicated by the server + network, but the use of the links would actually compete for server + network resources. Referring to Figure 13, this situation would + arise when both link S1-S3 and link S7-S9 are used to carry LSPs: in + that case, 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 the corresponding use of server network resources will cause + the server network to withdraw the availability of the other + abstraction layer links, and these will become unavailable for + further abstraction layer path computations. + + Furthermore, in deployments where abstraction layer links are only + presented as available after server network LSPs have been + established to support them, the problem is unlikely to exist. + + However, when the server network is constrained but chooses to + advertise the potential of multiple abstraction layer links even + though they compete for resources, and when multiple client-edge-to- + client-edge LSPs are computed simultaneously (perhaps to provide + protection services), there may be contention for server network + resources. In the case where protected abstraction layer LSPs are + being established, this situation would be avoided through the use of + SRLGs and/or MSRLGs, since the two abstraction layer links that + compete for server network resources must also fate-share across + + + +Farrel, et al. Best Current Practice [Page 64] + +RFC 7926 Information Exchange between TE Networks July 2016 + + + 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 mutually exclusive links in the abstraction layer TED so + that path computation can avoid accidentally attempting to utilize + two of a set of such links at the same time. + +Acknowledgements + + Thanks to Igor Bryskin for useful discussions in the early stages of + this work and to Gert Grammel for discussions on the extent of + aggregation in abstract nodes and links. + + Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam + Somasundaram, Hannes Gredler, Stewart Bryant, Brian Carpenter, and + Hilarie Orman for review and input. + + Particular thanks to Vishnu Pavan Beeram for detailed discussions and + white-board scribbling that made many of the ideas in this document + come to life. + + Text in Section 4.2.3 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, and Daniele Ceccarelli in [GMPLS-ENNI], for + which the authors of this document express their thanks. + + + + + + + + + + + + + + + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 65] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +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 + + + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 66] + +RFC 7926 Information Exchange between TE Networks July 2016 + + +Authors' Addresses + + Adrian Farrel (editor) + Juniper Networks + + Email: adrian@olddog.co.uk + + + John Drake + Juniper Networks + + Email: jdrake@juniper.net + + + Nabil Bitar + Nokia + + Email: nbitar40@gmail.com + + + George Swallow + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + + Email: swallow@cisco.com + + + Daniele Ceccarelli + Ericsson + Via A. Negrone 1/A + Genova - Sestri Ponente + Italy + + Email: daniele.ceccarelli@ericsson.com + + + Xian Zhang + Huawei Technologies + + Email: zhang.xian@huawei.com + + + + + + + + + + +Farrel, et al. Best Current Practice [Page 67] + -- cgit v1.2.3