RFC 7926
Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
RFC 7926: Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks 🦋
Okay bestie, let's start with the title block, because it has the important facts ✨
- Series and number: RFC 7926 from the IETF 🌐
- Category: Best Current Practice, so it's the official "here's how we do it" doc. Its BCP number is 206 💅
- ISSN: 2070-1721
- Date: July 2016 🌸
- Authors: A. Farrel (Editor), J. Drake (Juniper Networks), N. Bitar (Nokia), G. Swallow (Cisco Systems, Inc.), D. Ceccarelli (Ericsson), and X. Zhang (Huawei)
- Obsoletes and updates: the title block doesn't list any RFCs that this one obsoletes or updates 🙈
Abstract
Okay so, in Traffic-Engineered (TE) systems, it's sometimes super useful to set up an end-to-end TE path from a source to a destination. That path comes with constraints, like bandwidth, and it can cross one or more networks 🛤️ TE information is the data about nodes and TE links that gets used when picking a TE path. It's usually only visible inside one network. We call that zone of visibility a domain, and an IGP area or an Autonomous System (AS) can be an example of one 🏰
To figure out whether a TE path can even be set up across a bunch of connected networks, you need a certain amount of TE information about each network. It doesn't have to be the full set, but it does have to show that TE connectivity is possible. That subset is called TE reachability information 🦋
This document sets out the problem statement for swapping TE information between interconnected TE networks so end-to-end TE paths can be set up. It also describes the best current practice architecture that deals with this problem. For reasons explained in the document, the work is limited to simple TE constraints and to the information that determines TE reachability. The vibe is focused, not everything-all-at-once 💜
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 went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 7841 ✨
For info on the current status of this document, any errata, and how to give feedback on it, check 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) as they're in effect on the date of publication. Please actually read these docs, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 🫶
Table of Contents
1. Introduction ....................................................5
1.1. Terminology ................................................6
1.1.1. TE Paths and TE Connections .........................6
1.1.2. TE Metrics and TE Attributes ........................6
1.1.3. TE Reachability .....................................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
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 ................................................671. Introduction ✨
Okay, so Traffic-Engineered (TE) systems like MPLS-TE [RFC2702] and GMPLS [RFC3945] let you set up paths through a network in a controlled way, reserving network resources on the links you pick 🌸 TE paths get computed by looking through the Traffic Engineering Database (TED) and picking a sequence of links and nodes that can meet the path's requirements. The TED gets built from info the Interior Gateway Protocol (IGP) spreads around the network. Examples are OSPF-TE [RFC3630] and ISIS-TE [RFC5305] 🧚
Sometimes you want an end-to-end TE path that crosses more than one network or administrative domain, as described in [RFC4105] and [RFC4216] 🛣️ In those cases, TE info is usually only available inside each network. These networks are often called domains [RFC4726], and this document uses that definition, which goes like this:
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).
To work out whether a TE path can go through a series of connected domains, and to pick the right connection points between domains for routing it, you need a certain amount of TE info about each domain 💅 It doesn't have to be the full set, but it does have to show that TE connectivity is possible. That subset is called TE reachability information. TE reachability info can be exchanged between domains, based on what the local routing protocol gathers, filtered by configured policy, or configured statically 🦋
This document sets out the problem statement for swapping TE info between interconnected TE networks so end-to-end TE paths can be set up. It also describes the best current practice architecture for solving that problem 🎀 The scope is limited to simple TE constraints and info, like TE metrics, hop count, bandwidth, delay, and shared risk, that are needed to determine TE reachability. Adding lots of extra constraints that could qualify reachability can seriously complicate how info gets aggregated, and it can make the mechanism for presenting potential connectivity less stable, as the body of the document explains 🔥
1.1. Terminology ✨
okay so before we get into the good stuff, we need to agree on what the words mean 🫶 some terms get a proper deep dive later on (there are forward pointers, so you can jump ahead), and some are borrowed from other RFCs. we're not apologising for repeating those definitions here, because consistency is everything bestie 💅
1.1.1. TE Paths and TE Connections 🛤️
okay so a TE connection is a Label Switched Path (LSP) through an MPLS-TE or GMPLS network. it sends traffic along one specific path (the TE path) to give you a particular service, like a bandwidth guarantee, traffic separation, or resilience between a well-known pair of end points. main character energy 👑
1.1.2. TE Metrics and TE Attributes 📏
"TE metrics" and "TE attributes" are the terms for parameters on links (and maybe nodes) in a network that TE connections travel through. path computation algorithms use them to pick the TE paths. a TE metric is a quantifiable value (measured characteristics count too) describing some property of a link or node that can be used for TE routing or planning. a TE attribute is the wider term, the one that includes TE metrics. it covers any property or characteristic of a link or node that can be used for TE routing or planning 🧚 so the delay a packet picks up on a link is a TE metric, and the geographic location of a router is a more general attribute. it's giving categories, lowkey iconic 💜
provisioning a TE connection through a network may cause dynamic changes to the TE metrics and TE attributes of the links and nodes in that network 🔄
these terms are also sometimes used for the end-to-end characteristics of a TE connection. you can derive those with a formula from the TE metrics and TE attributes of the links and nodes the connection goes through. for example, the end-to-end delay for a TE connection is usually considered to be the sum of the delay on each link it traverses ➕
1.1.3. TE Reachability 🗺️
in an IP network, reachability is the ability to deliver a packet to a specific address or prefix. put simply, it means there's 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's the ability to set up a TE connection in the MPLS-TE or GMPLS sense. so we talk about TE reachability as the potential to provide TE connectivity 🦋
TE reachability can be unqualified, which means there's a TE path but no info about available resources or other constraints is provided. that's especially helpful when you're finding a path to a destination in an unknown domain. it can also be qualified by TE attributes and TE metrics, like hop count, available bandwidth, delay, and shared risk 🎀
1.1.4. Domain 🏰
as defined in [RFC4726], a domain is any collection of network elements that sit within a common sphere of address management or path computational responsibility. examples 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. people sometimes call it an underlay network 🌊
1.1.6. Client Network 📱
a Client Network is a network that uses the connectivity a Server Network provides. people sometimes call it 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 get represented outside that domain as a single entity. so multiple links and nodes that form a TE connection might show up as one link, or a whole collection of nodes and links (maybe the entire domain) might show up as a single node along with its attachment links ✨
1.1.8. Abstraction 🎭
Section 4.2 introduces abstraction and tells it apart from aggregation. you can think of abstraction as "policy-based aggregation," where the policies are applied to fix the issues with aggregation that are identified in Section 3 of this document. it's giving glow-up energy 🌟
abstraction is the process of applying policy to the available TE information within a domain, so you get selective information that represents the potential ability to connect across that domain. abstraction doesn't necessarily offer every possible connectivity option. what it gives you is a general view of potential connectivity, shaped by the policies that decide how the domain's administrator wants the domain's 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, and abstraction is what produces it. it gets advertised outside that domain as a TE link, for use in signaling in other domains. so an abstract link represents the potential to connect between a pair of nodes 💫
more details about abstract links are 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 (a collection of nodes and links that operate as a single administrative entity for TE purposes) into a single entity. that entity gets treated as a node for 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 give more info about the uses and issues of abstract nodes and virtual nodes 📚
1.1.11. Abstraction Layer Network 🌉
the abstraction layer network is introduced in Section 4.2.2. think of it as a brokerage-layer network sitting between one or more server networks and one or more client networks. it's the collection of abstract links that provide potential connectivity across the server networks. path computation can run on it to find edge-to-edge paths, which then 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 (in other words, abstract links). but to make using server network resources more flexible, the abstract links don't always have to go from edge to edge. they might offer connectivity between server network nodes instead, forming a more complex network 🕸️
2. Overview of Use Cases 🌈
2.1. Peer Networks 🤝
the peer network use case is easiest to see in the example in Figure 1. a TE path is required between the source (Src) and the destination (Dst), and they're in different domains. there are two points of interconnection between the domains, and picking the wrong one can lead to a suboptimal path or even stop a path from being available at all 😭 note that peer networks are assumed to have the same technology type. that means the same "switching capability," to use the term from GMPLS [RFC3945] 🔥
-------------- --------------
| Domain A | x1 | Domain Z |
| ----- +----+ ----- |
| | Src | +----+ | Dst | |
| ----- | x2 | ----- |
-------------- --------------
Figure 1: Peer Networksfor example, when Domain A tries to select a path, it might find adequate bandwidth from Src through both interconnection points, x1 and x2. it could pick the path through x1 for local policy reasons, maybe because the TE metric is smaller. but if there's no connectivity in Domain Z from x1 to Dst, the path can't be established 💀 crankback can be used to ease this situation, but it doesn't lead to rapid setup or guaranteed optimality. on top of that, RSVP signaling creates state in the network that the crankback procedure removes right away. frequent events like this will hurt scalability in a non-deterministic way. more details about crankback are in Appendix A.2 🫠
there are countless more complicated versions of the peer network problem. Figure 2 shows a simple mesh of domains. to find a TE path from Src to Dst, Domain A must not select a path that leaves through interconnect x1, because Domain B has no connectivity to Domain Z. deciding between interconnection x2 (through Domain C) and interconnection x3 (through Domain D) means Domain A has to care about the TE connectivity available through each of Domains C and D. it also has to care about the TE connectivity from each of interconnections x4 and x5 to Dst within Domain Z. it gets even messier when the source domain doesn't know which domain the destination node is in, because choosing a domain path depends on knowing the destination domain. this is obviously mitigated in IP networks by inter-domain routing [RFC4271] 😮💨
of course, plenty of network interconnection scenarios are a mix of these two examples. you can have a mesh of domains where the domains also have multiple points of interconnection 🧃
--------------
| Domain B |
| |
| |
/--------------
/
/x1
--------------/ --------------
| Domain A | | Domain Z |
| | -------------- | |
| ----- | x2| Domain C | x4| ----- |
| | Src | +---+ +---+ | Dst | |
| ----- | | | | ----- |
| | -------------- | |
--------------\ /--------------
\x3 /
\ /
\ /x5
\--------------/
| Domain D |
| |
| |
--------------
Figure 2: Peer Networks in a Mesh2.2. Client-Server Networks
okay bestie so there are two major classes of use case about the client-server relationship between networks 🫶 people have sometimes called these overlay networks ✨ in both classes the client and server networks might have the same switching capability, or they might be built from nodes and links with different technology types. no cap, both setups are valid 💅
the first group, shown in Figure 3, happens when domains belonging to one network get connected by a domain belonging to another network 🦋 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) is basically reduced to figuring out 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 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 for client-server networking is for Virtual Private Networks (VPNs) 🌸 this one is different from the first because the client network is assumed to have a different address space than the server network, and you can't guarantee that the IP addresses between the client and server networks won't overlap 🙈 a simple example is in Figure 4. the VPN sites are a set of domains that are interconnected over a core domain (i.e., the provider network), which is the server network in our model ✨
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 🦋
both use cases in this section get "more interesting" 🤩 when you combine them with the use case in Section 2.1, meaning 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 for a VPN 🧚
------------ ------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
------------\ /------------
\x1 x2/
\ /
\ /
\---------- ----------/
| Domain X |x5 | Domain Y |
| (core) +---+ (core) |
| | | |
| +---+ |
| |x6 | |
/---------- ----------\
/ \
/ \
/x3 x4\
------------/ \------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------Figure 5: A VPN Supported over Multiple Server Domains 💜
2.3. Dual-Homing
ok so this is the next level of the client-server situation 😭 you can add a further complication to the relationship from Section 2.2 by thinking about what happens when a client network domain is attached to more than one domain in the server network, or when it 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 🦋
okay so the relationship between domains can be totally under the control of management processes, or dynamically triggered by the client network, or some hybrid of the two. bestie, it's giving flexibility 💅. In the management case, the server network may be asked to set up a set of LSPs to provide client network connectivity. In the dynamic case, the client network may make a request to the server network and exert a whole range of controls over the paths selected in the server network. This range goes from no control at all (just a simple request for connectivity), through a set of constraints (latency, path protection, etc.), all the way up to 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 super 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 🔥. Server network resources are under the administrative control of the operator or the server network, and they are only used to support a client network in ways that the server network operator approves. Main character energy for the operator, ngl 💜.
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 💅.
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" 😭.
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 🌸.
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 🎀.
3.4. Issues of Information Churn ✨
okay so, every time an LSP gets set up or torn down, the TE resources on the links in the network shift 🔄. To compute a TE path reliably, the computation point needs an up-to-date view of what's available, bestie. But collecting that info can put a lot of load on the distribution protocol and churn the stored data 😭. To deal with this even inside a single domain, updates get sent at periodic intervals or whenever there's a significant change in resources, whichever happens first ⏰.
Picture a TE LSP that crosses ten links 🦋. When it's set up or torn down, the resources available on each of those links change, so each link gets a new advertisement of its capabilities and capacity. If new LSPs arrive pretty fast and the hold times are short, the network can be in a constant state of flux 🌪️. And this isn't just a within-one-domain problem, because the info shared between domains is changing too 💅. On top of that, what one domain needs to share with another can change because of LSPs that are contained within or cross the first domain, even when those LSPs don't matter at all to the domain receiving the TE info 🙈.
In packet networks, the capacity of an LSP is often a small fraction of the resources on any link, so this issue is partly handled by the advertising routers 🫶. They can apply a threshold, so they skip updating the advertised available resources on a link when the change is less than a configured percentage of the total (or, alternatively, the remaining) resources ✨. In that case, the updated info gets disseminated based on an update interval instead of a resource change event 🌸.
Non-packet networks are a different story 🔥. There, link resources are physical switching resources (like timeslots or wavelengths), so an LSP's capacity may more often be a big chunk of the available link resources. Some switching environments also need end-to-end resource continuity (like using the same wavelength along the whole length of an LSP), so it's way more desirable to keep the TE info held at the computation points up to date 👑. The good news? Non-packet networks tend to be quite a bit smaller than packet networks, non-packet LSPs arrive much less often, and their hold times are considerably longer 🧚. So the info churn may be sustainable 💜.
3.5. Issues of Aggregation
One possible fix for the problems in the other subsections of this section is to aggregate the TE info shared between domains 🧩. Two aggregation mechanisms come up a lot:
- Virtual node model. Here, the domain gets aggregated as if it were 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 one link can be routed out through any other link. (Recent work on "limited cross-connect switches" may help with this problem [RFC7579] 🎀.)
- Virtual link model. In this one, the domain is reduced to a set of edge-to-edge TE links 🌈. So when a computation point is figuring out a path for an LSP that crosses the domain, it can see which domain entry points can be connected to which others, and what TE attributes come with each connection 👀.
Here's the catch: aggregation means info gets removed from the system, and that can cause inaccuracies and failed path computation 😬. In the virtual node model, there might not actually be a TE path between a pair of domain entry points, but the model isn't sophisticated enough to represent that "limited cross-connect capability" inside the virtual node 💀. In the virtual link model, it can be super hard to aggregate multiple link characteristics. For example, there might be one path with high bandwidth and another with low delay, but that doesn't mean the connectivity should be assumed or advertised as having both high bandwidth and low delay 🙅♀️.
So the trick to this multidimensional problem is to aggregate in a way that keeps as much useful info as possible while tossing the data nobody needs 💖. A huge part of that trick is being clear on exactly what info is actually needed 🔍.
It's also worth noting, in the context of Section 3.4, that changes to the info within a domain may affect what aggregated data gets shared with another domain 🔄. So even though the data shared is reduced, the aggregation algorithm (running on the routers that are responsible for sharing info) may be heavily exercised 🏋️♀️.
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 📍. Knowing TE reachability is what lets an end-to-end TE path get computed, so it's kind of the whole point ✨.
Within a single network, TE reachability is derived from the Traffic Engineering Database (TED), which is the collection of all TE info about all TE links in the network 🗂️. The TED is usually built from the data exchanged by the IGP, though it can be supplemented by configuration and inventory details, especially in transport networks 🛠️.
In multi-network scenarios, TE reachability info 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's also important to think about the info on TE connectivity between an edge node and a specific destination node 💅. TE reachability can be qualified by TE attributes such as TE metrics, hop count, available bandwidth, delay, and shared risk 📊.
TE reachability info can be exchanged between networks, so nodes in one network can figure out whether they can set up TE paths across or into another network 🌉. But these exchanges are subject to a range of policies: the advertiser imposes some (for security and administrative control), and the receiver imposes others (for scalability and stability) 🔐.
4.2. Abstraction, Not Aggregation
Aggregation is the process of synthesizing from available info 🧪. So the virtual node and virtual link models described in Section 3.5 rely on processing the info available within a network to produce the aggregate representations of links and nodes that get presented to the consumer 🎁. As described in Section 3, dynamic aggregation comes with a bunch of pitfalls 🕳️.
To tell the architecture in this document apart from the earlier aggregation work, we use the term "abstraction" here ✨. Abstraction is the process of applying policy to the available TE info within a domain, to produce selective info that represents the potential ability to connect across the domain 🎯.
Abstraction doesn't offer every possible connectivity option (refer to Section 3.5), but it does give a general view of potential connectivity 🌤️. It may have a dynamic element, but it isn't meant to keep pace with every change in TE attribute availability within the network 🐢.
So when you rely on an abstraction to compute an end-to-end path, the process might not actually deliver a usable path 😅. There's no real guarantee that the abstractions are current or feasible 🙃.
Even though abstraction uses available TE info, it's subject to policy and management choices 🧾. So not all potential connectivity will be advertised to each client network 🙈. The filters may depend on commercial relationships, the risk of disclosing confidential info, and concerns about what use gets made of the connectivity that's 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 🔗. In other words, it's 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 💖.
Say you're looking at a network like the one shown in Figure 7 🖼️. The link from CN1 to CN4 may be an abstract link. It's easy to advertise it as a link by abstracting the TE info 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 isn't 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 client network nodes don't have visibility into the server network, they have to rely on abstraction info delivered to them by the server network 🙏. That means the server network is the one that reports on the potential for connectivity 📡.
4.2.2. The Abstraction Layer Network ✨
Okay bestie, Figure 7 is the star here 🌟. It splits everything into three layers: the client network resources (nodes C1, C2, C3, and C4, plus their links), the server network resources (nodes CN1, CN2, CN3, and CN4, plus their links), and an in-between layer called the abstraction layer 🦋. The abstraction layer holds 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 just operates as normal 💅. Connectivity across it is either found or not found, based on the links that show up in the client network TED. If connectivity can't be found, end-to-end LSPs can't get set up. That failure may be reported, but the client network takes no dynamic action 🙈
The server network also operates as normal. LSPs across it between client network edges get set up in response to management commands or in response to signaling requests 🔥
The abstraction layer is made of the physical links between the two networks, plus the abstract links. The server network creates the abstract links according to local policy, and they represent the potential connectivity the server network is willing to make available for the client network to use 👑 So in this example, the diameter of the abstraction layer is only three hops. But an IGP could easily run so that every node in the layer (especially the client network edge nodes) can see the TE connectivity in there ✨
-- -- -- --
|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 NetworkWhen the client network needs extra connectivity, it can make a request to the abstraction layer network 🎀 For example, the client network operator might want a link from C2 to C3. The abstraction layer can see the potential path C2-CN1-CN4-C3, so it can set up an LSP C2-CN1-CN4-C3 across the server network and make that LSP available as a link in the client network. Iconic, honestly 😭
Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the connectivity requirements in client-server networks and in peer networks 🧚
4.2.2.1. Nodes in the Abstraction Layer Network 🌸
Figure 7 is a super simplified diagram, so you'd be forgiven for thinking that only client network edge nodes and server network edge nodes can show up in the abstraction layer network 🙈 But nope, other nodes from the server network can be there too! That lets the abstraction layer network be way more complex than a full mesh with access spokes 💖
So in Figure 8, a transit node in the server network (here, the node is CN3) gets exposed as a node in the abstraction layer network, with abstract links connecting it to other nodes in that layer 🦋 Honestly, in the network shown in Figure 8 there's 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, the resulting network would be much richer 🍓
-- -- -- -- Client
|C1|--|C2| |C3|--|C4| Network
-- | | | | --
| | | | . . . . . . . . .
| | | |
| | | |
| | --- --- --- | | Abstraction
| |--|CN1|========|CN3|========|CN5|--| | Layer Network
-- | | | | | | --
| | | | | | . . . . . . . . . . . .
| | | | | |
| | | | | | Server
| | --- | | --- | | Network
| |--|CN2|-| |-|CN4|--| |
--- --- --- --- ---
Figure 8: Abstraction Layer Network with Additional NodeIt should be noted that the nodes included in the abstraction layer network this way are not "abstract nodes" in the sense of a virtual node described in Section 3.5 🤓 Sure, 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. But it is believed that doing so would add 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 ✨
Okay bestie, Figure 9 is the basic vibe for a client-server network 🎀. The client nodes are C1, C2, CE1, CE2, C3, and C4, with CE1 and CE2 as the client edge (CE) nodes. The core (server) nodes are CN1, CN2, CN3, and CN4. The interfaces CE1-CN1 and CE2-CN4 are where the client and server networks meet 🦋.
: :
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 NetworkThe client and server networks can have the same technologies (switching capabilities) or different ones 💅. If they're different, the client network traffic must be tunneled over a server network LSP. If they match, the client network LSP can be routed over the server network links, tunneled over a server network LSP, or built by stitching client network and server network LSP segments together (that's the concatenation (stitching) move 🧚).
The goal is to support an end-to-end connection, C1-to-C4, in the client network. That connection might do TE or plain old normal IP forwarding ✨. To make it happen, CE1 needs to be connected to CE2 by a link in the client network. That's what lets the client network see itself as connected and pick an end-to-end path 👑.
As the figure shows, three abstraction layer links get formed: CE1-CN1, CN1-CN2, and CN4-CE2. Put together, they give you a three-hop LSP from CE1 to CE2, and that LSP can show up as a link in the client network 🌸.
How the CE1-CE2 LSP actually rides across the server network LSP depends on what switching and signaling options the server network has 🙈. The CE1-CE2 LSP can be tunneled down the server network LSP using the mechanisms of a hierarchical LSP [RFC4206], or the LSP segments CE1-CN1 and CN4-CE2 can be stitched to the server network LSP as described in [RFC5150].
Section 4.2.2 already introduced the abstraction layer network with a simple layered example. But a slightly bigger network makes the idea even clearer, so let's go there 🌈.
Figure 10 shows a multi-layer network with 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 NetworkIf you ran Figure 10 as two separate networks, a client and a server, the client topology would look like Figure 11 💀. And honestly? The network is split in half. There's no way to set up an LSP from a node on the left (say C1) to a node on the right (say C7) 😭.
-- --
|C3|---|C4|
-- --\
-- -- \--
|C1|---|C2| |C5|
-- /-- /--
/ --/ --
/ |C6|---|C7|
/ /-- --
--/ -- --/
|C8|---|C9| |C0|
-- -- --
Figure 11: Client Network Topology Showing Partitioned NetworkFor reference, here's the matching server network topology in Figure 12 🧚.
-- -- --
|S1|---|S2|----|S3|
--\ --\ --\
\-- \-- \--
|S4| |S5|----|S6|
/-- --\ /--
--/ -- \--/
|S7|---|S8|----|S9|
-- -- --
Figure 12: Server Network TopologyNow, a management entity or software component works from the server network TED and applies policy 💅. It decides which abstract links to offer to the client network. To do that, it has to know how the layers connect to each other. There's zero point in offering an abstract link S2-S8, since it couldn't be useful in this example 🙈.
In our example, after checking which LSPs could be set up in the server network, four abstract links get offered: S1-S3, S3-S6, S1-S9, and S7-S9 ✨. Figure 13 shows them as double lines on the abstraction layer network topology. Two of them have to share part of a path, because S1-S9 has to share with either S1-S3 or S7-S9 😵. You could keep things separate with distinct resources (like separate lambdas) where the paths overlap, or you could use resource sharing instead 🦋.
--
|C3|
/--
-- -- --/
|C2|---|S1|==========|S3|
-- --\\ --\\
\\ \\
\\ \\-- --
\\ |S6|---|C6|
\\ -- --
-- -- \\-- --
|C9|---|S7|=====|S9|---|C0|
-- -- -- --
Figure 13: Abstraction Layer Network with Abstract LinksSo if both S1-S3 and S7-S9 are carrying client-edge-to-client-edge LSPs, the resources on S1-S9 get used up 🥺. They might run low enough that the path becomes resource constrained and can't be used anymore.
The separate IGP instance running in the abstraction layer network means this topology is visible at the edge nodes (C2, C3, C6, C9, and C0) and also at a Path Computation Element (PCE), if there is one 👀.
Now the client network can ask the abstraction layer network to set up connectivity 💖. In our example, it asks for C2 to be connected to C3, and for C2 to be connected to C0. Here's what happens next 🎀:
- The management component for the abstraction layer network asks its PCE to compute the paths needed for those connections. That gives C2-S1-S3-C3 and C2-S1-S9-C0.
- The management component for the abstraction layer network tells C2 to start signaling for the new LSPs in the abstraction layer.
- C2 signals the LSPs using the explicit routes C2-S1-S3-C3 and C2-S1-S9-C0.
- When the signaling messages reach S1 (both LSPs go through it in our example), the server network can support them in a few ways, including setting up server network LSPs as tunnels. Which one it picks depends on how different the client and server technologies are 🧚. For example, S1-S2-S3 and S1-S2-S5-S9 might be traversed via an LSP tunnel, through stitched LSPs, or just by routing the client network LSP through the server network. If server network LSPs are needed, they can be signaled right at this point.
- Once any server network LSPs that are needed are up, S1 can keep signaling the client-edge-to-client-edge LSP across the abstraction layer. It can use the server network LSPs as tunnels or stitching segments, or just route through the server network 🌸.
- Finally, once the client-edge-to-client-edge LSPs are set up, the client network gets informed and can start advertising the new TE links C2-C3 and C2-C0 🔥. The resulting client network topology is shown in Figure 14.
-- --
|C3|-|C4|
/-- --\
/ \--
-- --/ |C5|
|C1|---|C2| /--
-- /--\ --/ --
/ \ |C6|---|C7|
/ \ /-- --
/ \--/
--/ -- |C0|
|C8|---|C9| --
-- --
Figure 14: Connected Client Network with Additional Links- Now the client network can compute an end-to-end path from C1 to C7 🦋✨.
4.2.3.1. A Server with Multiple Clients
One server network can support multiple client networks 🌈. It's pretty common, honestly. For example, a server network might provide connectivity for several customers at once 💅.
When that happens, the abstraction the server network provides can vary a lot depending on the policies and business deals with each customer 💼. That variation means a separate abstraction layer network gets maintained for each client network 🎀.
But sometimes multiple client networks follow the same policies, and then the abstraction can be identical for all of them ✨. In that case, a single abstraction layer network can support more than one client 🫶.
Which way to go is an operational decision for the server network 👑.
4.2.3.2. A Client with Multiple Servers
One client network can be supported by multiple server networks 💜. Those server networks might connect different parts of the client network to each other, or they might give parallel (redundant) connectivity to the client network 🌸.
In this case, the abstraction layer network should include the abstract links from all of the server networks. That way it can run the right computations and create the correct TE links in the client network 🧠✨.
So basically, the relationship between the client network and the abstraction layer network should be one to one 💖.
4.2.4. Abstraction in Peer Networks ✨
okay so figure 15 shows the basic setup for connecting across peer networks 🫶 there are four networks in it: A1 and A2 come from one network, B1, B2, and B3 come from another, and so on. the interfaces between the networks (sometimes called External Network Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1 🔥
the goal is to support an end-to-end connection, A1-to-D2 💅 this connection is for TE connectivity.
: : :
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 networkFigure 15: Architecture for Peering
as the figure shows, abstract links that span the transit networks are used to get the connectivity we need 🦋 these links are 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 it may use 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 🧚
peer networks are everywhere on the Internet 🌈 packet networks may peer as IGP areas (levels) or as ASes, and transport networks (such as optical networks) may peer to provide concatenations of optical paths through single-vendor environments (see Section 6). figure 16 is a simple example of three peer networks (A, B, and C), each with a few nodes.
Network A : Network B : Network C
: :
-- -- -- : -- -- -- : -- --
|A1|---|A2|----|A3|---|B1|---|B2|---|B3|---|C1|---|C2|
-- --\ /-- : -- /--\ -- : -- --
\--/ : / \ :
|A4| : / \ :
--\ : / \ :
-- \-- : --/ \-- : -- --
|A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
-- -- : -- -- : -- --
: :
: :Figure 16: A Network Comprising Three Peer Networks
ngl this is the part that's giving "why is this hard" 😭 as discussed in Section 2, peered networks do not share visibility of their topologies or TE capabilities, for scaling and confidentiality reasons. so in our example, 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, which is the case with Network C in figure 16.
say 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 the one 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 Network C is partitioned, reachability information can be exchanged so Network A can 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 can get way more complex 💀 with dual-homing between network peering nodes (for example, A3 might connect to B1 and B4 in figure 17), and with the networks themselves arranged in a mesh (for example, A6 might connect to B4 and C1 in figure 17).
the good news is these extra 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's possible to imagine a super 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 🦋 but honestly? this kind of fluidity needs to be treated with caution ⚠️ especially for client-server networks of differing technologies where hierarchical server network LSPs are used, because there are 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. even more importantly, 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 💅
so 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 🔮
that said, 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. a client network may dynamically observe congestion, lack of connectivity, or predicted changes in traffic demand, and it 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 it could 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 💜
here's the tricky bit 🙈 in many cases the abstract link represents the potential for connectivity across the server network, but no such connectivity exists. so 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.
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 means 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 🙈 human operators may well get confused, and 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 ✨
okay so this section is totally non-normative 💅 it's not trying to boss anyone around about how to build their solution. it just gives a quick shoutout to protocols that could be looked at for helping realize the model in this doc 🦋
the big vibe here is protocol reuse. like, we'd much rather use something that's already commonly running on network nodes and already deployed than invent brand new protocols or pile on extensions. it can also mean using existing computational elements like PCEs 🧚 the benefits are honestly huge: better network stability, faster time to deployment, and way less operator training 🙌
BUT (and this is the tea 🍵) existing protocols probably won't be perfect for this problem space without some extensions. extending a protocol has to be done with care, and you have to think about keeping existing deployments stable 😭 in the extreme case, a brand new protocol can honestly be better than a messy hack on an old one 💀
5.1. BGP-LS
okay BGP-LS is a set of extensions to BGP, described in [RFC7752] 🌸 its whole purpose is to announce topology info from one network to a "northbound" consumer 💜 so far it's mostly been used to build a TED for a PCE, which is cute, but BGP's mechanisms could also totally slay at advertising abstract links from a server network into the abstraction layer network 🔥 and advertising potential connectivity from the abstraction layer network to the client network too ✨
5.2. IGPs
both OSPF and IS-IS have been extended through a bunch of RFCs to advertise TE info 💖 and they can both run in a multi-instance mode too 👑 either as ships that pass in the night (aka completely separate instances using different address spaces) or as dual instances on the same address space 🎀 which means either OSPF or IS-IS could probably be the routing protocol in the abstraction layer network 🦋 very flexible, very iconic 💅
5.3. RSVP-TE
RSVP-TE signaling can set up all the TE LSPs this model demands 🌈 and no protocol extensions needed, bestie 🫶
if needed, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can carry LSPs over the server network 🌸 again, no extensions required ✨
and then there's [RFC6107], which lets you dynamically signal the purpose of any LSP that gets established 🔥 so when an LSP tunnel is set up, the two ends can coordinate which routing protocol instance it should be advertised into 💜 and they can also agree on the addressing that will identify the link that gets created 🧚 the way that's so organized it's giving main character energy 👑
5.4. Notes on a Solution
okay this part is not prescriptive at all 🙈 it's not dictating which protocol solutions you have to use to satisfy the architecture. it just shows how the existing protocols from the previous sections could be combined, with only minor modifications, to give you a solution 🎀
so a server network can be operated using GMPLS routing and signaling protocols 🌊 from the info the routing protocol gathers, you can build a TED with resource availability and Shared Risk Link Group (SRLG) details 💖 then a policy-based process decides which nodes and abstract links it wants 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 info would most likely come from a single point of control that makes all the abstraction decisions, but the function could be distributed across multiple server network edge nodes 🫶 the info can be advertised by BGP-LS to multiple points in the abstraction layer (like all the client network edge nodes) or to a single controller 🧚
multiple server networks might advertise info that gets used to build an abstraction layer network, and one server network might advertise different info in different BGP-LS instances to form different abstraction layer networks 🌈 and if one controller is constructing multiple abstraction layer networks, BGP-LS uses the route target mechanism from [RFC4364] to tell the different applications apart. basically, effectively abstraction layer network VPNs for the exported info 💜 it's giving organized 💅
extensions to BGP-LS may be made to advertise Macro Shared Risk Link Groups (MSRLGs) (see Appendix B.1) and to identify mutually exclusive links (see Appendix B.2), and to indicate whether the abstract link has been pre-established or not 🔥 these extensions are valid options, but they don't form a core component of this architecture 🙌
the abstraction layer network can run under central control or use a distributed control plane 🌸 since the links and nodes can be a mix of physical and abstract links, and the nodes may have diverse cross-connect capabilities, a GMPLS routing protocol is most likely going to be helpful for collecting and correlating the routing info and distributing updates 💖 no special extra features are needed beyond adding those extra parameters we just talked about for BGP-LS ✨ but it's worth noting 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 have been established via connections in the server network yet 😭
the abstraction layer network can also figure out the potential connectivity from client network edge to client network edge 🦋 it decides which client network links to create according to policy and subject to requests from the client network, and it takes four steps 🫶
- first, it computes a path across the abstraction layer network 🧚
- then, if supporting the abstract links requires server network LSPs for tunneling or stitching, and those LSPs aren't already established, it asks the server layer to set them up 🌈
- then, it signals the client-edge-to-client-edge LSP 💜
- finally, the abstraction layer network informs the client network about the new client network link 👑
this last step can be done in one of two ways: (1) coordinating the end points of the LSPs that span the abstraction layer (those points are client network edge nodes) using mechanisms like the ones in [RFC6107], or (2) using BGP-LS from a central controller 🔥
once the client network edge nodes know about a new link, they'll automatically advertise it using their routing protocol, and then it's available for use by traffic in the client network 🌸✨
Sections 6, 7, and 8 talk about how applicable this architecture is to different network types and problem spaces 🎀 and Section 9 gives some advice about scoping future work 💖 Section 10 ("Manageability Considerations") is especially relevant to this section, because it covers the policies and mechanisms for indicating connectivity and link availability between network layers in this architecture 🦋 this is the part that's giving the whole plot 👑
6. Application of the Architecture to Optical Domains and Networks 🌈
Okay so, a lot of optical networks are built as a bunch of small domains 🧚 Each domain is a cluster of nodes, usually from the same equipment vendor and with the same properties 💅 A domain can be a mesh or a ring, or maybe an interconnected set of rings. Iykyk 🔁
The network operator wants end-to-end connectivity across a network made of multiple domains, so (obviously) the domains are interconnected 🫶 In a network under management control, like through an Operations Support System (OSS), each domain sits under the operational control of a Network Management System (NMS) 👑
So an end-to-end path can get commissioned like this: the OSS tells each NMS what to do, and the NMSes set up the path fragments across their domains 🦋
Still, 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. Here, nodes A through F are arranged in a topological ring. Suppose there's 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 DomainNow picture the operator's network built from a mesh of these domains, D1 through D7, as in Figure 20 🌸 It's possible these domains share a single, common instance of OSPF. If so, there's nothing more to say, because that OSPF instance will distribute enough info to build one TED spanning the whole network, and an end-to-end path can be computed ✨ A more likely scenario is that each domain runs its own OSPF instance. Then each one can handle the peculiarities (or, rather, advanced functions) of each vendor's equipment capabilities 🙈
------ ------ ------ ------
| | | | | | | |
| D1 |---| D2 |---| D3 |---| D4 |
| | | | | | | |
------\ ------\ ------\ ------
\ | \ | \ |
\------ \------ \------
| | | | | |
| D5 |---| D6 |---| D7 |
| | | | | |
------ ------ ------
Figure 20: A Mesh of Simple Optical DomainsSo the big question is how to combine the multiple sets of info distributed by the different OSPF instances. Three possible models come to mind, all based on existing routing practices 🧠
- 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 work out the path across its own nodes. The feasibility of an end-to-end path (and, thus, the choice of the sequence of areas and their interconnections) can be derived using hierarchical PCEs.
This approach, however, fits poorly with how the OSPF area is normally used. In this kind of optical network, the interconnection points between domains are likely to be links, and the mesh of domains is way more interconnected and unstructured than we're used to seeing in the normal area-based routing paradigm 😭
Also, while hierarchical PCEs may be able to handle this type of network, the effort involved may be considerable for more than a small collection of domains 💀
- 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 work out the path across the nodes in that AS.
This model sits more comfortably with the established routing paradigm, but it causes a massive escalation of ASes in the global Internet 🌍 In practice, it would require the operator to use private AS numbers [RFC6996], of which there are plenty 🍓
Then, as suggested in the area-based model, hierarchical PCEs could be used to figure out the feasibility of an end-to-end path and to derive the sequence of domains and the points of interconnection to use. But just like in the area-based model, the scalability of this model using a hierarchical PCE must be questioned, given the sheer number of ASes and how interconnected they are 🫠
Furthermore, working out the mesh of domains (i.e., the inter-AS connections) conventionally requires BGP as an inter-domain routing protocol. Not only is BGP not normally available on optical equipment, but this approach also means the TE properties of the inter-domain links would need to be distributed and updated using BGP -- which is not well suited to that job 🙅♀️
- 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. Looking back at Figure 20, each OSPF instance running in a domain would be construed as a "lower-level" OSPF instance, and it 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 treating 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 domain can see the connectivity of the whole network 👀
Although it's architecturally satisfying, this model struggles with handling 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 😩 On top of that, the scaling issues tied to a well-meshed network of domains (each with many entry and exit points, and each with network resources that are constantly being updated) boil down to the same problem noted in the virtual link model. And if the domains are under the control of different administrations, those domains would not want to distribute the details of their topologies and TE resources 🔒
Practically speaking, 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. So 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's clear that the framework defined in this document can be built from the architecture discussed in [RFC6827], but without needing any of the protocol extensions defined in that document. So using the terminology and concepts already established, the problem can be solved as shown in Figure 21 🦋 The abstraction layer network is built 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 Network7. Application of the Architecture to the User-Network Interface 🎀
Okay so the User-Network Interface (UNI) is literally such a core idea in lots of client-server network setups, especially when the client network and the server network use totally different technologies 💅. The UNI is described in [G.8080], and the GMPLS take on the UNI lives in [RFC4208]. Other GMPLS docs get into specific UNI situations too: for example, [RFC6005] explains how GMPLS can back up a UNI that gives access to Ethernet services 🌸.
Figure 1 of [RFC6005] gets reproduced here as Figure 22 🦋. It shows the Ethernet UNI reference model, and honestly that figure works as an example for every similar UNI 🔥. In this case, the UNI sits between the client network edge nodes and the server network. Also, neither the client network nor the server network has to be an Ethernet switching network, so don't get it twisted 💀.
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 is made of links, which are the UNI links plus the tunnels across the server network, and nodes, which are the client network edge nodes plus various server network nodes 🧚. So the Ethernet service network is basically the same thing as the abstraction layer network ✨. The UNI links are the physical links between the client and server networks, the client edge nodes play the role of UNI Client-side (UNI-C) nodes, and the server edge nodes act as the UNI Network-side (UNI-N) nodes 👑.
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 ModelNow here's a fun one that people ask about a lot 🙈. How does a dual-homed client network edge node (like the one at the bottom left-hand corner of Figure 22) figure out how to connect across the UNI? This matters a lot when reachability across the server network is limited, or when you want two diverse paths (for example, for protection) 🛡️. BUT, in the model described in this network, the edge node (the UNI-C node) is part of the abstraction layer network and can see enough topology information to make these calls 😤. If the approach from this document is used to model the UNI like this section describes, there's no need to enhance the signaling protocols at the GMPLS UNI, and no need to add routing exchanges at the UNI 🥳.
8. Application of the Architecture to L3VPN Multi-AS Environments 🦋
Serving Layer 3 VPNs (L3VPNs) across a multi-AS or multi-operator environment is currently a seriously big planning challenge 😭. Figure 6 shows the general version of the problem that needs solving, and this section shows how the abstraction layer network can tackle it 💅.
In the VPN architecture, the CE nodes are the client network edge nodes, and the PE nodes are the server network edge nodes 🌈. So the abstraction layer network is made up of the CE nodes, the CE-PE links, the PE nodes, and the PE-PE tunnels, which are the abstract links ✨.
In the multi-AS or multi-operator case, the abstraction layer network also includes the PEs (which might be Autonomous System Border Routers (ASBRs)) at the edges of the multiple server networks, plus the PE-PE links (which might be inter-AS links) 🔥. This gives us the architecture shown in Figure 23 💜.
........... .............
VPN Site : : VPN Site
-- -- : : -- --
|C1|-|CE| : : |CE|-|C2|
-- | | : : | | --
| | : : | |
| | : : | |
| | : : | |
| | : -- -- -- -- : | |
| |----|PE|=========|PE|---|PE|=====|PE|----| |
-- : | | | | | | | | : --
........... | | | | | | | | ............
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | - - | | | | - | |
| |-|P|-|P|-| | | |-|P|-| |
-- - - -- -- - --
Figure 23: The Abstraction Layer Network for a Multi-AS VPNThe policy for adding abstract links to the abstraction layer network is going to be driven mostly by what the VPN needs 🎀. So when a new VPN site gets added and the existing abstraction layer network can't support the connectivity it needs, a new abstract link gets created out of the underlying network 🙌.
It's important to note that each VPN instance can have its own separate abstraction layer network 🫶. That means the server network resources can be partitioned, and the traffic can be kept separate 🔐.
This can be done even when VPN sites from different VPNs connect at the same PE 💖. Or, if it's operationally better, multiple VPNs can share the same abstraction layer network instead 🌸.
Lastly, just like the UNI we talked about in Section 7, dual-homing of VPN sites is a function of the abstraction layer network, so it's just a normal routing problem in that network 💅.
9. Scoping Future Work 🔮
This section is here to help guide the work on this problem 🧭. The big picture is that it's super important to keep the work limited and focused on the stuff that's core and necessary to achieve the main function ✨. Don't add unnecessary features, don't over-complicate the architecture or the solution, and don't try 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." 🧩 So it's NOT the goal of this work to turn the whole Internet into one giant interconnected TE network 🙅♀️.
9.2. Working with "Related" Domains 🤝
Starting with this subsection, the work is meant to solve TE interconnectivity for only "related" domains 💜. These domains may be under common administrative operation (like IGP areas within a single AS, or ASes belonging to a single operator), or they may have a direct commercial arrangement for sharing TE information to provide specific services 💸. So in both cases, there's a strong opportunity to apply policy 🔥.
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 it's not possible to guarantee that an end-to-end path over interconnected TE domains follows the absolute optimal path (by any measure of optimality) 📉. This is taken as understood, so future work should NOT try to achieve such paths, since they can only be found by fully examining all network information across all connected networks 🚫.
9.4. Sanity and Scaling 🧠
All of the above points lead to one final observation 🎯. This work is meant to "bite off" a small problem for some relatively simple use cases, as described in Section 2 🍓. It's 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 📈. But it's 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 😌.
Wait, let me correct that to match the original exactly:
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, just like 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? 🧵
10.1. Managing the Abstraction Layer Network 🧠
okay so managing the abstraction layer network is kinda different from managing the client and server networks, bc not all the links you see in the TED are actually real links 😭. you literally cannot run Operations, Administration, and Maintenance (OAM) on the links that make up the potential of a link. it's giving "not there yet" 💀
otherwise the management should be essentially the same vibe ✨ Routing and signaling protocols can run in the abstraction layer (using out-of-band channels for links that haven't been established yet), and you can build a centralized TED to check the availability and status of the links and nodes in the network. slay 💅
Now, who "owns" the abstraction layer network is a whole thing and depends on the deployment model 👑. Sometimes the operator of the server network builds it and runs it as a service for one or more client networks. Other times, one or more server networks present the potential of links to an abstraction layer network that's run by the operator of the client network. And it's feasible (no cap) 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 street, bestie:
- 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.
- 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: 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
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 is the main character here, so pay attention, bestie. 😭
Security of signaling and routing protocols is usually administered and achieved within the boundaries of a domain. So, 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 heavily on making sure that control-plane messages are not allowed to enter the domain from outside 🚧.
In this context, the additional security considerations that come from this document are about the exchange of control-plane information between domains. Messages are passed between domains using control-plane protocols that operate between peers with predictable relationships (for example, UNI-C to UNI-N, between BGP-LS speakers, or between peer domains). So the security that needs extra attention for inter-domain TE is mostly about 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, already include such protection. They 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 📚
Here's the reading list, bestie 🎀:
[G.8080] International Telecommunication Union, "Architecture for
the automatically switched optical network", ITU-T
Recommendation G.8080/Y.1304, February 2012,
<https://www.itu.int/rec/T-REC-G.8080-201202-I/en>.
[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,
<http://www.rfc-editor.org/info/rfc2702>.
[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,
<http://www.rfc-editor.org/info/rfc3209>.
[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,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.
[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,
<http://www.rfc-editor.org/info/rfc4105>.
[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, <http://www.rfc-editor.org/info/rfc4202>.
[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,
<http://www.rfc-editor.org/info/rfc4206>.
[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, <http://www.rfc-editor.org/info/rfc4208>.
[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, <http://www.rfc-editor.org/info/rfc4216>.
[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,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364,
February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. [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, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847,
April 2007, <http://www.rfc-editor.org/info/rfc4847>.
[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, <http://www.rfc-editor.org/info/rfc4874>.
[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,
<http://www.rfc-editor.org/info/rfc4920>.
[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, <http://www.rfc-editor.org/info/rfc5150>.
[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,
<http://www.rfc-editor.org/info/rfc5152>.
[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,
<http://www.rfc-editor.org/info/rfc5195>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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,
<http://www.rfc-editor.org/info/rfc5251>.
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN
Auto-Discovery", RFC 5252, DOI 10.17487/RFC5252,
July 2008, <http://www.rfc-editor.org/info/rfc5252>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305,
October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[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,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5523] Berger, L., "OSPFv3-Based Layer 1 VPN Auto-Discovery",
RFC 5523, DOI 10.17487/RFC5523, April 2009,
<http://www.rfc-editor.org/info/rfc5523>.
[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,
<http://www.rfc-editor.org/info/rfc5553>.
[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, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[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,
<http://www.rfc-editor.org/info/rfc6005>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<http://www.rfc-editor.org/info/rfc6071>.
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths",
RFC 6107, DOI 10.17487/RFC6107, February 2011,
<http://www.rfc-editor.org/info/rfc6107>.
[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,
<http://www.rfc-editor.org/info/rfc6805>.
[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,
<http://www.rfc-editor.org/info/rfc6827>.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996,
July 2013, <http://www.rfc-editor.org/info/rfc6996>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>.
[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,
<http://www.rfc-editor.org/info/rfc7579>.
[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,
<http://www.rfc-editor.org/info/rfc7580>.
[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,
<http://www.rfc-editor.org/info/rfc7752>.
[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.Appendix A. Existing Work ✨
Okay bestie, this appendix is a quick recap of the existing work people already use to route TE paths across multiple domains 🧚. It's non-normative, so it's just background vibes, not rules 💅.
A.1. Per-Domain Path Computation 🦋
So the per-domain path setup is described in [RFC5152], and [RFC4726] talks about whether it actually applies. The basic idea is that each domain entry point is responsible for computing the path across its own domain 🌸. The details about the path in the next domain get left to the next domain's entry point, which is a very "you do your part, I'll do mine" energy 🫶. The computation can happen right at the entry point, or the entry point can hand it off to a computation server 💖.
This basic mode can run into a bunch of the problems we talked about with the use cases in Section 2 😭. But honestly? In practice it works pretty well, as long as you have a little operational guidance ✨.
For example, RSVP-TE [RFC3209] has this thing called a "loose hop" in the explicit path that gets signaled 🎀. That lets the original LSP request list the domains, or even the domain entry points, that should be on the path. So in the Figure 1 example, the source can be told to use interconnection x2 🍓. The source then computes the path from itself to x2 and kicks off the signaling. When the signaling message gets to Domain Z, the entry point to that domain computes the rest of the path to the destination and keeps the signaling going 🔥.
Another option suggested in [RFC5152] is to make TE routing try to follow inter-domain IP routing 👑. So in the Figure 2 example, the source looks at the BGP routing information to figure out the right interconnection point for forwarding IP packets, and then uses that to compute and signal a path for Domain A 🌈. Every domain does the same thing in turn, so the path gets built progressively, domain by domain 🧚.
Look, the per-domain approach has a lot of issues and drawbacks when it comes to getting optimal (or, honestly, any) paths 💀. But it's been the mainstay of inter-domain LSP setup so far, and that's kind of iconic ⭐.
A.2. Crankback 🔄✨
okay so crankback is the answer to the biggest drama in per-domain path computation 😭 The question is: what happens when you pick a path that can't actually be finished toward the destination? Like in Figure 2, if the source tries to route through interconnection x2, but Domain C doesn't have the right TE resources or connectivity to take it further? 💀
Crankback for MPLS-TE and GMPLS networks is described in [RFC4920] 🎀 and it's based on a similar idea to the Acceptable Label Set mechanism for GMPLS signaling in [RFC3473]. Here's the vibe: when a node (aka a domain entry point) can't compute a path any further across its domain, it sends back an error message in the signaling protocol. That message says where the blockage happened (link identifier, node identifier, domain identifier, etc.) and gives some clues about what caused it (bad choice of label, insufficient bandwidth available, etc.) 🔍 This info lets an earlier computation point pick a different path, or bundle up the crankback info and send it further upstream to a previous computation point 🦋
Crankback is a very powerful mechanism and it can find an end-to-end path across a multi-domain network if one exists 👑
BUT (and this is a big but 🙈) crankback can be super resource-intensive, because signaling messages and path setup attempts may "wander around" the network, trying to find the right path for a long time 😩 Here's why it's not a popular mechanism:
- RSVP-TE signaling ties up network resources for partially established LSPs.
- Network conditions may be in flux.
- Most especially, LSP setup within well-known time limits is highly desirable 🥺
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's an abstract functional entity that computes paths. So in the per-domain path computation example (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) that computation requests get sent to, using the Path Computation Element Communication Protocol (PCEP) [RFC5440] 🖥️
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 bonus opportunity to offload complex, CPU-intensive, or memory-intensive computation functions from routers in the network 🙌 But using PCEs this way does not solve any of the problems in Appendices A.1 and A.2. Not me being the bearer of bad news 😤
Two significant mechanisms for cooperation between PCEs have been described 🌈 These are intended to specifically tackle the problem of computing optimal end-to-end paths in multi-domain environments. Main character energy 💅
- 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 that info with its upstream neighbor PCE, which builds a tree of possible paths rooted at the destination. The PCE in the source domain can then select the optimal path 👑
BRPC is sometimes described as "crankback at computation time" 🙃 It's capable of determining the optimal path in a multi-domain network, but it depends on knowing the domain that contains the destination node. It can also get complicated and involve a lot of data in a mesh of interconnected domains 😵💫 So BRPC is most often proposed for a simple mesh of domains, and specifically for a path that will cross a known sequence of domains, where there may be a choice of domain interconnections. Following that logic, 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's responsible for navigating a path across the domain mesh and for coordinating intra-domain computations by the child PCEs responsible for each domain. This makes computing an end-to-end path across a mesh of domains way 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. And it raises the question of who operates the parent PCE, especially in networks where the domains are under different administrative and commercial control 🤔
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. So the UNI allows access to, and limited control of, the core nodes by edge nodes that are unaware of the core topology. 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 it does allow for the exchange of reachability information between them 🙈 In terms of a VPN, the client network can be considered the customer network, made up 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 💜
So [RFC4208] is a signaling-only solution that lets edge nodes 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 the technology necessitates it) 🪄 This solution is supplemented by a number of signaling extensions, such as [RFC4874], [RFC5553], [RSVP-TE-EXCL], [RSVP-TE-EXT], and [RSVP-TE-METRIC]. These give the edge node more control over the path within the server network, and let edge nodes supply additional constraints on the path used in the server network 🎀 Nevertheless, in this UNI/overlay model, the edge node has limited information about 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 😭
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] 🌐
Just like 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 very 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 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 figuring out 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 resulting client network TE link can also be configured manually. However, if connectivity from client edge to client edge is achieved using dynamic signaling, then the end points need to exchange the link properties 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 is 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 🦋
okay so network links often share fate with other links 🫶 meaning one thing going wrong (like a cut) can take out a bunch of links at once. this happens if they're bundled in the same fiber, run down the same duct, or sit on the same piece of infrastructure like a bridge 🌉. the usual way to flag links that might share fate is to tag them as part of a Shared Risk Link Group (SRLG) [RFC4202] 💅
TE links built from LSPs in lower layers can also share fate, and this is lowkey hard for the client network to spot 😭 it doesn't know the server network's topology or which server network LSPs are carrying the links it uses 💀
for example, look at the setup from Section 4.2.3 with the two abstract links S1-S3 and S1-S9 🧚 the client network has no way to tell whether links C2-C0 and C2-C3 share fate. and honestly, if the client layer wants a link-diverse end-to-end protection scheme, it needs to know these links both lean on the same piece of infrastructure (the server network link S1-S2) 🔥
per [RFC4202], an SRLG is a shared physical network resource that a link's normal functioning depends on 🌸 you can identify and advertise several SRLGs for every TE link in a network. BUT ngl that can turn into a scalability nightmare in a multi-layer network, because it ends up meaning the client network has to hear about the server network route of every single TE link 😩
enter Macro SRLGs (MSRLGs) ✨ they solve the scaling problem and they're a form of abstraction that happens at the same time the abstract links get derived 👑 so links that actually share resources in the server network get advertised with the same MSRLG, instead of advertising every SRLG for every resource on every path in the server network. this saving works because the abstract links are formulated on behalf of the server network by a central management agency that knows about every link abstraction on offer 🫧
it's worth noting there's a less optimal alternative path for the abstract link S1-S9 in the server network (S1-S4-S7-S8-S9) 🍓 the client network could ask that its C2-C0 connectivity request also be maximally disjoint from path C2-C3. nothing can fix the shared link C2-S1, but the abstraction layer could ask to use link S1-S9 in a way that's diverse from the use of link S1-S3 💜 and that request could be honored if the server network policy allows it 🙈
and heads up, SRLGs and MSRLGs can be super hard to describe when there are multiple server networks 😵💫 the abstraction points won't know whether the resources in the various server layers share physical locations.
B.2. Mutual Exclusivity 🎀
as mentioned in the Figure 13 discussion, some abstraction layer links might not be usable at the same time 🙈 this happens when the server network says a link is potentially available, but using it would actually compete for server network resources 💅 in Figure 13, that's the case if both link S1-S3 and link S7-S9 are used to carry LSPs. then link S1-S9 can no longer be used 💀
this doesn't have to be a problem when client-edge-to-client-edge LSPs get set up one by one ✨ using one abstraction layer link and its matching server network resources makes the server network withdraw the availability of the other abstraction layer links, so they drop out of future abstraction layer path computations. iconic self-regulation 👑
also, in deployments where abstraction layer links only show up as available after server network LSPs have been set up to support them, the problem is unlikely to happen 🌈
the tea gets spicy when the server network is constrained but still advertises the potential of multiple abstraction layer links even though they compete for resources 🍵 and when several client-edge-to-client-edge LSPs get computed at the same time (maybe to provide protection services) 😭 then there may be contention for server network resources. if protected abstraction layer LSPs are being established, this gets avoided through SRLGs and/or MSRLGs, since the two abstraction layer links that compete for server network resources must also fate-share across those resources 🫶 but if the multiple client-edge-to-client-edge LSPs don't care about fate sharing, it may be necessary to flag the mutually exclusive links in the abstraction layer TED. that way path computation can avoid accidentally trying to use two of a set of such links at the same time 🧚
Acknowledgements ✨
thank you 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 🔥
the 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], and the authors of this document express their thanks 🌸
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.esAuthors' 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📦 where this page comes from
- ietf: rfc7926 2016-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms