draft-ietf-teas-interconnected-te-info-exchange-05.txt   draft-ietf-teas-interconnected-te-info-exchange-06.txt 
Network Working Group A. Farrel (Ed.) Network Working Group A. Farrel (Ed.)
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Best Current Practice Juniper Networks Intended status: Best Current Practice Juniper Networks
Expires: October 26, 2016 Expires: November 10, 2016
N. Bitar N. Bitar
Nokia Nokia
G. Swallow G. Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
X. Zhang X. Zhang
Huawei Huawei
April 26, 2016 May 10, 2016
Problem Statement and Architecture for Information Exchange Problem Statement and Architecture for Information Exchange
Between Interconnected Traffic Engineered Networks Between Interconnected Traffic Engineered Networks
draft-ietf-teas-interconnected-te-info-exchange-05.txt draft-ietf-teas-interconnected-te-info-exchange-06.txt
Abstract Abstract
In Traffic Engineered (TE) systems, it is sometimes desirable to In Traffic Engineered (TE) systems, it is sometimes desirable to
establish an end-to-end TE path with a set of constraints (such as establish an end-to-end TE path with a set of constraints (such as
bandwidth) across one or more network from a source to a destination. bandwidth) across one or more network from a source to a destination.
TE information is the data relating to nodes and TE links that is TE information is the data relating to nodes and TE links that is
used in the process of selecting a TE path. TE information is used in the process of selecting a TE path. TE information is
usually only available within a network. We call such a zone of usually only available within a network. We call such a zone of
visibility of TE information a domain. An example of a domain may be visibility of TE information a domain. An example of a domain may be
skipping to change at page 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 5 1. Introduction ................................................. 5
1.1. Terminology ................................................ 6 1.1. Terminology ................................................ 6
1.1.1. TE Paths and TE Connections .............................. 6 1.1.1. TE Paths and TE Connections .............................. 6
1.1.2. TE Metrics and TE Attributes ............................. 6 1.1.2. TE Metrics and TE Attributes ............................. 6
1.1.3. TE Reachability .......................................... 7 1.1.3. TE Reachability .......................................... 7
1.1.4. Domain ................................................... 7 1.1.4. Domain ................................................... 7
1.1.5. Aggregation .............................................. 7 1.1.5. Server Network ........................................... 7
1.1.6. Abstraction .............................................. 7 1.1.6. Client Network ........................................... 7
1.1.7. Abstract Link ............................................ 8 1.1.7. Aggregation .............................................. 7
1.1.8. Abstract Node or Virtual Node ............................ 8 1.1.8. Abstraction .............................................. 8
1.1.9. Abstraction Layer Network ................................ 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. Overview of Use Cases ........................................ 9
2.1. Peer Networks .............................................. 9 2.1. Peer Networks .............................................. 9
2.2. Client-Server Networks ..................................... 10 2.2. Client-Server Networks ..................................... 11
2.3. Dual-Homing ................................................ 13 2.3. Dual-Homing ................................................ 13
2.4. Requesting Connectivity .................................... 14 2.4. Requesting Connectivity .................................... 14
2.4.1. Discovering Server Network Information ................... 16 2.4.1. Discovering Server Network Information ................... 16
3. Problem Statement ............................................ 16 3. Problem Statement ............................................ 16
3.1. Policy and Filters ......................................... 17 3.1. Policy and Filters ......................................... 17
3.2. Confidentiality ............................................ 17 3.2. Confidentiality ............................................ 17
3.3. Information Overload ....................................... 18 3.3. Information Overload ....................................... 18
3.4. Issues of Information Churn ................................ 18 3.4. Issues of Information Churn ................................ 18
3.5. Issues of Aggregation ...................................... 19 3.5. Issues of Aggregation ...................................... 19
4. Architecture ................................................. 20 4. Architecture ................................................. 20
4.1. TE Reachability ............................................ 20 4.1. TE Reachability ............................................ 20
4.2. Abstraction not Aggregation ................................ 21 4.2. Abstraction not Aggregation ................................ 21
4.2.1. Abstract Links ........................................... 22 4.2.1. Abstract Links ........................................... 22
4.2.2. The Abstraction Layer Network ............................ 22 4.2.2. The Abstraction Layer Network ............................ 22
4.2.3. Abstraction in Client-Server Networks..................... 25 4.2.3. Abstraction in Client-Server Networks..................... 25
4.2.4. Abstraction in Peer Networks ............................. 30 4.2.4. Abstraction in Peer Networks ............................. 30
4.3. Considerations for Dynamic Abstraction ..................... 32 4.3. Considerations for Dynamic Abstraction ..................... 32
4.4. Requirements for Advertising Links and Nodes ............... 33 4.4. Requirements for Advertising Links and Nodes ............... 33
4.5. Addressing Considerations .................................. 33 4.5. Addressing Considerations .................................. 34
5. Building on Existing Protocols ............................... 34 5. Building on Existing Protocols ............................... 34
5.1. BGP-LS ..................................................... 34 5.1. BGP-LS ..................................................... 35
5.2. IGPs ....................................................... 35 5.2. IGPs ....................................................... 35
5.3. RSVP-TE .................................................... 35 5.3. RSVP-TE .................................................... 35
5.4. Notes on a Solution ........................................ 35 5.4. Notes on a Solution ........................................ 35
6. Applicability to Optical Domains and Networks ................. 37 6. Applicability to Optical Domains and Networks ................. 37
7. Modeling the User-to-Network Interface ....................... 41 7. Modeling the User-to-Network Interface ....................... 41
8. Abstraction in L3VPN Multi-AS Environments ................... 43 8. Abstraction in L3VPN Multi-AS Environments ................... 43
9. Scoping Future Work .......................................... 44 9. Scoping Future Work .......................................... 44
9.1. Not Solving the Internet ................................... 44 9.1. Not Solving the Internet ................................... 44
9.2. Working With "Related" Domains ............................. 44 9.2. Working With "Related" Domains ............................. 44
9.3. Not Finding Optimal Paths in All Situations ................ 44 9.3. Not Finding Optimal Paths in All Situations ................ 44
skipping to change at page 5, line 52 skipping to change at page 5, line 52
end TE path establishment and describes the best current practice end TE path establishment and describes the best current practice
architecture to meet this problem statement. The scope of this architecture to meet this problem statement. The scope of this
document is limited to the simple TE constraints and information document is limited to the simple TE constraints and information
(such as TE metrics, hop count, bandwidth, delay, shared risk) (such as TE metrics, hop count, bandwidth, delay, shared risk)
necessary to determine TE reachability: discussion of multiple necessary to determine TE reachability: discussion of multiple
additional constraints that might qualify the reachability can additional constraints that might qualify the reachability can
significantly complicate aggregation of information and the stability significantly complicate aggregation of information and the stability
of the mechanism used to present potential connectivity as is of the mechanism used to present potential connectivity as is
explained in the body of this document. explained in the body of this document.
An Appendix to this document summarizes existing relevant existing An Appendix to this document summarizes relevant existing work that
work that is used to route TE paths across multiple domains. is used to route TE paths across multiple domains.
1.1. Terminology 1.1. Terminology
This section introduces some key terms that need to be understood to This section introduces some key terms that need to be understood to
arrive at a common understanding of the problem space. Some of the arrive at a common understanding of the problem space. Some of the
terms are defined in more detail in the sections that follow (in terms are defined in more detail in the sections that follow (in
which case forward pointers are provided) and some terms are taken which case forward pointers are provided) and some terms are taken
from definitions that already exist in other RFCs (in which case from definitions that already exist in other RFCs (in which case
references are given, but no apology is made for repeating or references are given, but no apology is made for repeating or
summarizing the definitions here). summarizing the definitions here).
skipping to change at page 7, line 29 skipping to change at page 7, line 29
attributes and TE metrics such as hop count, available bandwidth, attributes and TE metrics such as hop count, available bandwidth,
delay, shared risk, etc. delay, shared risk, etc.
1.1.4. Domain 1.1.4. Domain
As defined in [RFC4726], a domain is any collection of network As defined in [RFC4726], a domain is any collection of network
elements within a common sphere of address management or path elements within a common sphere of address management or path
computational responsibility. Examples of such domains include computational responsibility. Examples of such domains include
Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
1.1.5. Aggregation 1.1.5. Server Network
A Server Network is a network that provides connectivity for another
network (the Client Network) in a client-server relationship. A
Server Network is sometimes referred to as an underlay network.
1.1.6. Client Network
A Client Network is a network that uses the connectivity provided by
a Server Network. A Client Network is sometimes referred to as an
overlay network.
1.1.7. Aggregation
The concept of aggregation is discussed in Section 3.5. In The concept of aggregation is discussed in Section 3.5. In
aggregation, multiple network resources from a domain are represented aggregation, multiple network resources from a domain are represented
outside the domain as a single entity. Thus multiple links and nodes outside the domain as a single entity. Thus multiple links and nodes
forming a TE connection may be represented as a single link, or a forming a TE connection may be represented as a single link, or a
collection of nodes and links (perhaps the whole domain) may be collection of nodes and links (perhaps the whole domain) may be
represented as a single node with its attachment links. represented as a single node with its attachment links.
1.1.6. Abstraction 1.1.8. Abstraction
Section 4.2 introduces the concept of abstraction and distinguishes Section 4.2 introduces the concept of abstraction and distinguishes
it from aggregation. Abstraction may be viewed as "policy-based it from aggregation. Abstraction may be viewed as "policy-based
aggregation" where the policies are applied to overcome the issues aggregation" where the policies are applied to overcome the issues
with aggregation as identified in Section 3 of this document. with aggregation as identified in Section 3 of this document.
Abstraction is the process of applying policy to the available TE Abstraction is the process of applying policy to the available TE
information within a domain, to produce selective information that information within a domain, to produce selective information that
represents the potential ability to connect across the domain. Thus, represents the potential ability to connect across the domain. Thus,
abstraction does not necessarily offer all possible connectivity abstraction does not necessarily offer all possible connectivity
options, but presents a general view of potential connectivity options, but presents a general view of potential connectivity
according to the policies that determine how the domain's according to the policies that determine how the domain's
administrator wants to allow the domain resources to be used. administrator wants to allow the domain resources to be used.
1.1.7. Abstract Link 1.1.9. Abstract Link
An abstract link is the representation of the characteristics of a An abstract link is the representation of the characteristics of a
path between two nodes in a domain produced by abstraction. The path between two nodes in a domain produced by abstraction. The
abstract link is advertised outside that domain as a TE link for use abstract link is advertised outside that domain as a TE link for use
in signaling in other domains. Thus, an abstract link represents in signaling in other domains. Thus, an abstract link represents
the potential to connect between a pair of nodes. the potential to connect between a pair of nodes.
More details of abstract links are provided in Section 4.2.1. More details of abstract links are provided in Section 4.2.1.
1.1.8. Abstract Node or Virtual Node 1.1.10. Abstract Node or Virtual Node
An abstract node was defined in [RFC3209] as a group of nodes whose 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 internal topology is opaque to an ingress node of the LSP. More
generally, an abstract node is the representation as a single node in 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 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 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 outside the domain as a TE node for use in path computation and
signaling in other domains. signaling in other domains.
The term virtual node has typically been applied to the aggregation The term virtual node has typically been applied to the aggregation
of a domain (that is, a collection of nodes and links that operate of a domain (that is, a collection of nodes and links that operate
as a single administrative entity for TE purposes) into a single as a single administrative entity for TE purposes) into a single
entity that is treated as a node for the purposes of end-to-end entity that is treated as a node for the purposes of end-to-end
traffic engineering. Virtual nodes are often considered a way to traffic engineering. Virtual nodes are often considered a way to
present islands of single vendor equipment in an optical network. present islands of single vendor equipment in an optical network.
Sections 3.5 and 4.2.2.1 provide more information about the uses Sections 3.5 and 4.2.2.1 provide more information about the uses
and issues of abstract nodes and virtual nodes. and issues of abstract nodes and virtual nodes.
1.1.9. Abstraction Layer Network 1.1.11. Abstraction Layer Network
The abstraction layer network is introduced in Section 4.2.2. It may The abstraction layer network is introduced in Section 4.2.2. It may
be seen as a brokerage layer network between one or more server be seen as a brokerage layer network between one or more server
networks and one or more client network. The abstraction layer network and one or more client network. The abstraction layer
network is the collection of abstract links that provide potential network is the collection of abstract links that provide potential
connectivity across the server network(s) and on which path connectivity across the server networks and on which path computation
computation can be performed to determine edge-to-edge paths that can be performed to determine edge-to-edge paths that provide
provide connectivity as links in the client network. connectivity as links in the client network.
In the simplest case, the abstraction layer network is just a set of In the simplest case, the abstraction layer network is just a set of
edge-to-edge connections (i.e., abstract links), but to make the use edge-to-edge connections (i.e., abstract links), but to make the use
of server resources more flexible, the abstract links might not all of server network resources more flexible, the abstract links might
extend from edge to edge, but might offer connectivity between server not all extend from edge to edge, but might offer connectivity
nodes to form a more complex network. between server network nodes to form a more complex network.
2. Overview of Use Cases 2. Overview of Use Cases
2.1. Peer Networks 2.1. Peer Networks
The peer network use case can be most simply illustrated by the The peer network use case can be most simply illustrated by the
example in Figure 1. A TE path is required between the source (Src) example in Figure 1. A TE path is required between the source (Src)
and destination (Dst), that are located in different domains. There and destination (Dst), that are located in different domains. There
are two points of interconnection between the domains, and selecting are two points of interconnection between the domains, and selecting
the wrong point of interconnection can lead to a sub-optimal path, or the wrong point of interconnection can lead to a sub-optimal path, or
even fail to make a path available. Note that peer networks are even fail to make a path available. Note that peer networks are
assumed to have the same technology type: that is, the same assumed to have the same technology type: that is, the same
"switching capability" to use the term from GMPLS [RFC3945]. "switching capability" to use the term from GMPLS [RFC3945].
-------------- --------------
| Domain A | x1 | Domain Z |
| ----- +----+ ----- |
| | Src | +----+ | Dst | |
| ----- | x2 | ----- |
-------------- --------------
Figure 1 : Peer Networks
For example, when Domain A attempts to select a path, it may For example, when Domain A attempts to select a path, it may
determine that adequate bandwidth is available from Src through both determine that adequate bandwidth is available from Src through both
interconnection points x1 and x2. It may pick the path through x1 interconnection points x1 and x2. It may pick the path through x1
for local policy reasons: perhaps the TE metric is smaller. However, for local policy reasons: perhaps the TE metric is smaller. However,
if there is no connectivity in Domain Z from x1 to Dst, the path if there is no connectivity in Domain Z from x1 to Dst, the path
cannot be established. Techniques such as crankback may be used to cannot be established. Techniques such as crankback may be used to
alleviate this situation, but do not lead to rapid setup or alleviate this situation, but do not lead to rapid setup or
guaranteed optimality. Furthermore RSVP signalling creates state in guaranteed optimality. Furthermore RSVP signalling creates state in
the network that is immediately removed by the crankback procedure. the network that is immediately removed by the crankback procedure.
Frequent events of such a kind impact scalability in a non- Frequent events of such a kind impact scalability in a non-
deterministic manner. More details of crankback can be found in deterministic manner. More details of crankback can be found in
Section A.2. Section A.2.
-------------- --------------
| Domain A | x1 | Domain Z |
| ----- +----+ ----- |
| | Src | +----+ | Dst | |
| ----- | x2 | ----- |
-------------- --------------
Figure 1 : Peer Networks
There are countless more complicated examples of the problem of peer There are countless more complicated examples of the problem of peer
networks. Figure 2 shows the case where there is a simple mesh of networks. Figure 2 shows the case where there is a simple mesh of
domains. Clearly, to find a TE path from Src to Dst, Domain A must domains. Clearly, to find a TE path from Src to Dst, Domain A must
not select a path leaving through interconnect x1 since Domain B has not select a path leaving through interconnect x1 since Domain B has
no connectivity to Domain Z. Furthermore, in deciding whether to no connectivity to Domain Z. Furthermore, in deciding whether to
select interconnection x2 (through Domain C) or interconnection x3 select interconnection x2 (through Domain C) or interconnection x3
though Domain D, Domain A must be sensitive to the TE connectivity though Domain D, Domain A must be sensitive to the TE connectivity
available through each of Domains C and D, as well the TE available through each of Domains C and D, as well the TE
connectivity from each of interconnections x4 and x5 to Dst within connectivity from each of interconnections x4 and x5 to Dst within
Domain Z. The problem may be further complicated when the source Domain Z. The problem may be further complicated when the source
domain does not know in which domain the destination node is located, domain does not know in which domain the destination node is located,
since the choice of a domain path clearly depends on the knowledge of since the choice of a domain path clearly depends on the knowledge of
the destination domain: this issue is obviously mitigated in IP the destination domain: this issue is obviously mitigated in IP
networks by inter-domain routing [RFC4271]. networks by inter-domain routing [RFC4271].
Of course, many network interconnection scenarios are going to be a Of course, many network interconnection scenarios are going to be a
combination of the situations expressed in these two examples. There combination of the situations expressed in these two examples. There
may be a mesh of domains, and the domains may have multiple points of may be a mesh of domains, and the domains may have multiple points of
interconnection. interconnection.
-------------- --------------
| Domain B | | Domain B |
| | | |
| | | |
/-------------- /--------------
/
/ /
/x1 /x1
--------------/ -------------- --------------/ --------------
| Domain A | | Domain Z | | Domain A | | Domain Z |
| | -------------- | | | | -------------- | |
| ----- | x2| Domain C | x4| ----- | | ----- | x2| Domain C | x4| ----- |
| | Src | +---+ +---+ | Dst | | | | Src | +---+ +---+ | Dst | |
| ----- | | | | ----- | | ----- | | | | ----- |
| | -------------- | | | | -------------- | |
--------------\ /-------------- --------------\ /--------------
skipping to change at page 11, line 4 skipping to change at page 11, line 19
referred to as overlay networks. In both cases, the client and referred to as overlay networks. In both cases, the client and
server network may have the same switching capability, or may be server network may have the same switching capability, or may be
built from nodes and links that have different technology types in built from nodes and links that have different technology types in
the client and server networks. the client and server networks.
The first group of use cases, shown in Figure 3, occurs when domains The first group of use cases, shown in Figure 3, occurs when domains
belonging to one network are connected by a domain belonging to belonging to one network are connected by a domain belonging to
another network. In this scenario, once connectivity is formed another network. In this scenario, once connectivity is formed
across the lower layer network, the domains of the upper layer across the lower layer network, the domains of the upper layer
network can be merged into a single domain by running IGP adjacencies network can be merged into a single domain by running IGP adjacencies
and by treating the server layer connectivity as links in the higher and by treating the server network layer connectivity as links in the
layer network. The TE relationship between the domains (higher and higher layer network. The TE relationship between the domains
lower layer) in this case is reduced to determining what server layer (higher and lower layers) in this case is reduced to determining what
connectivity to establish, how to trigger it, how to route it in the server network connectivity to establish, how to trigger it, how to
server layer, and what resources and capacity to assign within the route it in the server network, and what resources and capacity to
server layer. As the demands in the higher layer network vary, the assign within the server network layer. As the demands in the higher
connectivity in the server layer may need to be modified. Section layer (client) network vary, the connectivity in the server network
2.4 explains in a little more detail how connectivity may be may need to be modified. Section 2.4 explains in a little more
requested. detail how connectivity may be requested.
-------------- -------------- ---------------- ----------------
| Domain A | | Domain Z | | Client Network | | Client Network |
| | | | | Domain A | | Domain B |
| ----- | | ----- | | | | |
| | Src | | | | Dst | | | ----- | | ----- |
| ----- | | ----- | | | Src | | | | Dst | |
| | | | | ----- | | ----- |
--------------\ /-------------- | | | |
\x1 x2/ ----------------\ /----------------
\ / \x1 x2/
\ / \ /
\---------------/ \ /
| Server Domain | \----------------/
| | | Server Network |
| | | Domain |
--------------- | |
----------------
Figure 3 : Client-Server Networks Figure 3 : Client-Server Networks
The second class of use case of client-server networking is for The second class of use case of client-server networking is for
Virtual Private Networks (VPNs). In this case, as opposed to the Virtual Private Networks (VPNs). In this case, as opposed to the
former one, it is assumed that the client network has a different former one, it is assumed that the client network has a different
address space than that of the server layer where non-overlapping IP address space than that of the server network where non-overlapping
addresses between the client and the server networks cannot be IP addresses between the client and the server networks cannot be
guaranteed. A simple example is shown in Figure 4. The VPN sites guaranteed. A simple example is shown in Figure 4. The VPN sites
comprise a set of domains that are interconnected over a core domain, comprise a set of domains that are interconnected over a core domain,
the provider network. the provider network, that is the server network in our model.
Note that in the use cases shown in Figures 3 and 4 the client layer Note that in the use cases shown in Figures 3 and 4 the client
domains may (and, in fact, probably do) operate as a single connected network domains may (and, in fact, probably do) operate as a single
network. connected network.
-------------- -------------- -------------- --------------
| Domain A | | Domain Z | | Domain A | | Domain Z |
| (VPN site) | | (VPN site) | | (VPN site) | | (VPN site) |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | Src | | | | Dst | | | | Src | | | | Dst | |
| ----- | | ----- | | ----- | | ----- |
| | | | | | | |
--------------\ /-------------- --------------\ /--------------
skipping to change at page 13, line 38 skipping to change at page 13, line 38
| (VPN site) | | (VPN site) | | (VPN site) | | (VPN site) |
| | | | | | | |
------------ ------------ ------------ ------------
Figure 5 : A VPN Supported Over Multiple Server Domains Figure 5 : A VPN Supported Over Multiple Server Domains
2.3. Dual-Homing 2.3. Dual-Homing
A further complication may be added to the client-server relationship A further complication may be added to the client-server relationship
described in Section 2.2 by considering what happens when a client described in Section 2.2 by considering what happens when a client
domain is attached to more than one server domain, or has two points network domain is attached to more than one domain in the server
of attachment to a server domain. Figure 6 shows an example of this network, or has two points of attachment to a server network domain.
for a VPN. Figure 6 shows an example of this for a VPN.
------------ ------------
| Domain A | | Domain B |
| (VPN site) | | (VPN site) |
------------ | ----- | ------------ | ----- |
| Domain B | | | Src | | | Domain A | | | Src | |
| (VPN site) | | ----- | | (VPN site) | | ----- |
| | | | | | | |
------------\ -+--------+- ------------\ -+--------+-
\x1 | | \x1 | |
\ x2| |x3 \ x2| |x3
\ | | ------------ \ | | ------------
\--------+- -+-------- | Domain Z | \--------+- -+-------- | Domain C |
| Domain X | x8 | Domain Y | x4 | (VPN site) | | Domain X | x8 | Domain Y | x4 | (VPN site) |
| (core) +----+ (core) +----+ ----- | | (core) +----+ (core) +----+ ----- |
| | | | | | Dst | | | | | | | | Dst | |
| +----+ +----+ ----- | | +----+ +----+ ----- |
| | x9 | | x5 | | | | x9 | | x5 | |
/---------- ----------\ ------------ /---------- ----------\ ------------
/ \ / \
/ \ / \
/x6 x7\ /x6 x7\
------------/ \------------ ------------/ \------------
| Domain C | | Domain D | | Domain D | | Domain E |
| (VPN site) | | (VPN site) | | (VPN site) | | (VPN site) |
| | | | | | | |
------------ ------------ ------------ ------------
Figure 6 : Dual-Homing in a Virtual Private Network Figure 6 : Dual-Homing in a Virtual Private Network
2.4. Requesting Connectivity 2.4. Requesting Connectivity
The relationship between domains can be entirely under the control of The relationship between domains can be entirely under the control of
management processes, dynamically triggered by the client network, or management processes, dynamically triggered by the client network, or
some hybrid of these cases. In the management case, the server some hybrid of these cases. In the management case, the server
network may be requested to establish a set of LSPs to provide client network may be requested to establish a set of LSPs to provide client
layer connectivity. In the dynamic case, the client may make a network connectivity. In the dynamic case, the client network may
request to the server network exerting a range of controls over the make a request to the server network exerting a range of controls
paths selected in the server network. This range extends from no over the paths selected in the server network. This range extends
control (i.e., a simple request for connectivity), through a set of from no control (i.e., a simple request for connectivity), through a
constraints (such as latency, path protection, etc.), up to and set of constraints (such as latency, path protection, etc.), up to
including full control of the path and resources used in the server and including full control of the path and resources used in the
network (i.e., the use of explicit paths with label subobjects). server network (i.e., the use of explicit paths with label
subobjects).
There are various models by which a server network can be requested There are various models by which a server network can be requested
to set up the connections that support a service provided to the to set up the connections that support a service provided to the
client network. These requests may come from management systems, client network. These requests may come from management systems,
directly from the client network control plane, or through an directly from the client network control plane, or through an
intermediary broker such as the Virtual Network Topology Manager intermediary broker such as the Virtual Network Topology Manager
(VNTM) [RFC5623]. (VNTM) [RFC5623].
The trigger that causes the request to the server layer is also The trigger that causes the request to the server network is also
flexible. It could be that the client layer discovers a pressing flexible. It could be that the client network discovers a pressing
need for server layer resources (such as the desire to provision an need for server network resources (such as the desire to provision an
end-to-end connection in the client layer, or severe congestion on end-to-end connection in the client network or severe congestion on
a specific path), or it might be that a planning application has a specific path), or it might be that a planning application has
considered how best to optimize traffic in the client network or considered how best to optimize traffic in the client network or
how to handle a predicted traffic demand. how to handle a predicted traffic demand.
In all cases, the relationship between client and server networks is In all cases, the relationship between client and server networks is
subject to policy so that server resources are under the subject to policy so that server network resources are under the
administrative control of the operator or the server layer network administrative control of the operator or the server network and are
and are only used to support a client layer network in ways that the only used to support a client network in ways that the server network
server layer operator approves. operator approves.
As just noted, connectivity requests issued to a server network may As just noted, connectivity requests issued to a server network may
include varying degrees of constraint upon the choice of path that include varying degrees of constraint upon the choice of path that
the server network can implement. the server network can implement.
o Basic Provisioning is a simple request for connectivity. The only o Basic Provisioning is a simple request for connectivity. The only
constraints are the end points of the connection and the capacity constraints are the end points of the connection and the capacity
(bandwidth) that the connection will support for the client layer. (bandwidth) that the connection will support for the client
In the case of some server networks, even the bandwidth component network. In the case of some server networks, even the bandwidth
of a basic provisioning request is superfluous because the server component of a basic provisioning request is superfluous because
layer has no facility to vary bandwidth, but can offer connectivity the server network has no facility to vary bandwidth, but can offer
only at a default capacity. connectivity only at a default capacity.
o Basic Provisioning with Optimization is a service request that o Basic Provisioning with Optimization is a service request that
indicates one or more metrics that the server layer must optimize indicates one or more metrics that the server network must optimize
in its selection of a path. Metrics may be hop count, path length, in its selection of a path. Metrics may be hop count, path length,
summed TE metric, jitter, delay, or any number of technology- summed TE metric, jitter, delay, or any number of technology-
specific constraints. specific constraints.
o Basic Provisioning with Optimization and Constraints enhances the o Basic Provisioning with Optimization and Constraints enhances the
optimization process to apply absolute constraints to functions of optimization process to apply absolute constraints to functions of
the path metrics. For example, a connection may be requested that the path metrics. For example, a connection may be requested that
optimizes for the shortest path, but in any case requests that the optimizes for the shortest path, but in any case requests that the
end-to-end delay be less than a certain value. Equally, end-to-end delay be less than a certain value. Equally,
optimization my be expressed in terms of the impact on the network. optimization my be expressed in terms of the impact on the network.
For example, a service may be requested in order to leave maximal For example, a service may be requested in order to leave maximal
flexibility to satisfy future service requests. flexibility to satisfy future service requests.
o Fate Diversity requests ask for the server layer to provide a path o Fate Diversity requests ask for the server network to provide a
that does not use any network resources (usually links and nodes) path that does not use any network resources (usually links and
that share fate (i.e., can fail as the result of a single event) as nodes) that share fate (i.e., can fail as the result of a single
the resources used by another connection. This allows the client event) as the resources used by another connection. This allows
layer to construct protection services over the server layer the client network to construct protection services over the server
network, for example by establishing links that are known to be network, for example by establishing links that are known to be
fate diverse. The connections that have diverse paths need not fate diverse. The connections that have diverse paths need not
share end points. share end points.
o Provisioning with Fate Sharing is the exact opposite of Fate o Provisioning with Fate Sharing is the exact opposite of Fate
Diversity. In this case two or more connections are requested to Diversity. In this case two or more connections are requested to
to follow same path in the server network. This may be requested, to follow same path in the server network. This may be requested,
for example, to create a bundled or aggregated link in the client for example, to create a bundled or aggregated link in the client
layer where each component of the client layer composite link is network where each component of the client layer composite link is
required to have the same server layer properties (metrics, delay, required to have the same server network properties (metrics,
etc.) and the same failure characteristics. delay, etc.) and the same failure characteristics.
o Concurrent Provisioning enables the inter-related connections o Concurrent Provisioning enables the inter-related connections
requests described in the previous two bullets to be enacted requests described in the previous two bullets to be enacted
through a single, compound service request. through a single, compound service request.
o Service Resilience requests the server layer to provide o Service Resilience requests the server network to provide
connectivity for which the server layer takes responsibility to connectivity for which the server network takes responsibility to
recover from faults. The resilience may be achieved through the recover from faults. The resilience may be achieved through the
use of link-level protection, segment protection, end-to-end use of link-level protection, segment protection, end-to-end
protection, or recovery mechanisms. protection, or recovery mechanisms.
2.4.1. Discovering Server Network Information 2.4.1. Discovering Server Network Information
Although the topology and resource availability information of a Although the topology and resource availability information of a
server network may be hidden from the client network, the service server network may be hidden from the client network, the service
request interface may support features that report details about the request interface may support features that report details about the
services and potential services that the server network supports. services and potential services that the server network supports.
skipping to change at page 17, line 51 skipping to change at page 17, line 51
3.2. Confidentiality 3.2. Confidentiality
A feature of the policy described in Section 3.1 is that an operator 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 of a domain may desire to keep confidential the details about its
internal network topology and loading. This information could be internal network topology and loading. This information could be
construed as commercially sensitive. construed as commercially sensitive.
Although it is possible that TE information exchange will take place Although it is possible that TE information exchange will take place
only between parties that have significant trust, there are also use only between parties that have significant trust, there are also use
cases (such as the VPN supported over multiple server domains cases (such as the VPN supported over multiple server network domains
described in Section 2.4) where information will be shared between described in Section 2.4) where information will be shared between
domains that have a commercial relationship, but a low level of domains that have a commercial relationship, but a low level of
trust. trust.
Thus, it must be possible for a domain to limit the information share Thus, it must be possible for a domain to limit the information share
to just that which the computing domain needs to know with the to just that which the computing domain needs to know with the
understanding that less information that is made available the more understanding that the less information that is made available the
likely it is that the result will be a less optimal path and/or more more likely it is that the result will be a less optimal path and/or
crankback events. more crankback events.
3.3. Information Overload 3.3. Information Overload
One reason that networks are partitioned into separate domains is to One reason that networks are partitioned into separate domains is to
reduce the set of information that any one router has to handle. reduce the set of information that any one router has to handle.
This also applies to the volume of information that routing protocols This also applies to the volume of information that routing protocols
have to distribute. have to distribute.
Over the years routers have become more sophisticated with greater Over the years routers have become more sophisticated with greater
processing capabilities and more storage, the control channels on processing capabilities and more storage, the control channels on
skipping to change at page 20, line 33 skipping to change at page 20, line 33
both high bandwidth and low delay. both high bandwidth and low delay.
The trick to this multidimensional problem, therefore, is to The trick to this multidimensional problem, therefore, is to
aggregate in a way that retains as much useful information as aggregate in a way that retains as much useful information as
possible while removing the data that is not needed. An important possible while removing the data that is not needed. An important
part of this trick is a clear understanding of what information is part of this trick is a clear understanding of what information is
actually needed. actually needed.
It should also be noted in the context of Section 3.4 that changes in It should also be noted in the context of Section 3.4 that changes in
the information within a domain may have a bearing on what aggregated the information within a domain may have a bearing on what aggregated
data is shared with another domain. Thus, while the data shared in data is shared with another domain. Thus, while the data shared is
reduced, the aggregation algorithm (operating on the routers reduced, the aggregation algorithm (operating on the routers
responsible for sharing information) may be heavily exercised. responsible for sharing information) may be heavily exercised.
4. Architecture 4. Architecture
4.1. TE Reachability 4.1. TE Reachability
As described in Section 1.1, TE reachability is the ability to reach As described in Section 1.1, TE reachability is the ability to reach
a specific address along a TE path. The knowledge of TE reachability a specific address along a TE path. The knowledge of TE reachability
enables an end-to-end TE path to be computed. enables an end-to-end TE path to be computed.
skipping to change at page 21, line 47 skipping to change at page 21, line 47
connectivity. Abstraction may have a dynamic element, but is not connectivity. Abstraction may have a dynamic element, but is not
intended to keep pace with the changes in TE attribute availability intended to keep pace with the changes in TE attribute availability
within the network. within the network.
Thus, when relying on an abstraction to compute an end-to-end path, Thus, when relying on an abstraction to compute an end-to-end path,
the process might not deliver a usable path. That is, there is no the process might not deliver a usable path. That is, there is no
actual guarantee that the abstractions are current or feasible. actual guarantee that the abstractions are current or feasible.
While abstraction uses available TE information, it is subject to While abstraction uses available TE information, it is subject to
policy and management choices. Thus, not all potential connectivity policy and management choices. Thus, not all potential connectivity
will be advertised to each client. The filters may depend on will be advertised to each client network. The filters may depend on
commercial relationships, the risk of disclosing confidential commercial relationships, the risk of disclosing confidential
information, and concerns about what use is made of the connectivity information, and concerns about what use is made of the connectivity
that is offered. that is offered.
4.2.1. Abstract Links 4.2.1. Abstract Links
An abstract link is a measure of the potential to connect a pair of An abstract link is a measure of the potential to connect a pair of
points with certain TE parameters. That is, it is a path and its points with certain TE parameters. That is, it is a path and its
characteristics in the server network. An abstract link represents characteristics in the server network. An abstract link represents
the possibility of setting up an LSP, and LSPs may be set up over the the possibility of setting up an LSP, and LSPs may be set up over the
abstract link. abstract link.
When looking at a network such as that in Figure 7, the link from CN1 When looking at a network such as that in Figure 7, the link from CN1
to CN4 may be an abstract link. It is easy to advertise it as a link to CN4 may be an abstract link. It is easy to advertise it as a link
by abstracting the TE information in the server network subject to by abstracting the TE information in the server network subject to
policy. policy.
The path (i.e., the abstract link) represents the possibility of The path (i.e., the abstract link) represents the possibility of
establishing an LSP from client edge to client edge across the server establishing an LSP from client network edge to client network edge
network. There is not necessarily a one-to-one relationship between across the server network. There is not necessarily a one-to-one
abstract link and LSP because more than one LSP could be set up over relationship between abstract link and LSP because more than one LSP
the path. could be set up over the path.
Since the client nodes do not have visibility into the core network, Since the client network nodes do not have visibility into the server
they must rely on abstraction information delivered to them by the network, they must rely on abstraction information delivered to them
core network. That is, the core network will report on the potential by the server network. That is, the server network will report on
for connectivity. the potential for connectivity.
4.2.2. The Abstraction Layer Network 4.2.2. The Abstraction Layer Network
Figure 7 introduces the abstraction layer network. This construct Figure 7 introduces the abstraction layer network. This construct
separates the client layer resources (nodes C1, C2, C3, and C4, and separates the client network resources (nodes C1, C2, C3, and C4, and
the corresponding links), and the server layer resources (nodes CN1, the corresponding links), and the server network resources (nodes
CN2, CN3, and CN4 and the corresponding links). Additionally, the CN1, CN2, CN3, and CN4 and the corresponding links). Additionally,
architecture introduces an intermediary layer called the abstraction the architecture introduces an intermediary network layer called the
layer. The abstraction layer contains the client layer edge nodes abstraction layer. The abstraction layer contains the client network
(C2 and C3), the server layer edge nodes (CN1 and CN4), the client- edge nodes (C2 and C3), the server network edge nodes (CN1 and CN4),
server links (C2-CN1 and CN4-C3) and the abstract link CN1-CN4. the client-server links (C2-CN1 and CN4-C3) and the abstract link
CN1-CN4.
The client layer network is able to operate as normal. Connectivity The client network is able to operate as normal. Connectivity across
across the network can either be found or not found based on links the network can either be found or not found based on links that
that appear in the client layer TED. If connectivity cannot be appear in the client network TED. If connectivity cannot be found,
found, end-to-end LSPs cannot be set up. This failure may be end-to-end LSPs cannot be set up. This failure may be reported, but
reported but no dynamic action is taken by the client layer. no dynamic action is taken by the client network.
The server network layer also operates as normal. LSPs across the The server network also operates as normal. LSPs across the server
server layer between client edges are set up in response to network between client network edges are set up in response to
management commands or in response to signaling requests. management commands or in response to signaling requests.
The abstraction layer consists of the physical links between the The abstraction layer consists of the physical links between the
two networks, and also the abstract links. The abstract links are two networks, and also the abstract links. The abstract links are
created by the server network according to local policy and represent created by the server network according to local policy and represent
the potential connectivity that could be created across the server the potential connectivity that could be created across the server
network and which the server network is willing to make available for network and which the server network is willing to make available for
use by the client network. Thus, in this example, the diameter of use by the client network. Thus, in this example, the diameter of
the abstraction layer network is only three hops, but an instance of the abstraction layer network is only three hops, but an instance of
an IGP could easily be run so that all nodes participating in the an IGP could easily be run so that all nodes participating in the
skipping to change at page 23, line 34 skipping to change at page 23, line 35
| | --- --- | | Server Network | | --- --- | | Server Network
| |--|CN2|--|CN3|--| | | |--|CN2|--|CN3|--| |
--- --- --- --- --- --- --- ---
Key Key
--- Direct connection between two nodes --- Direct connection between two nodes
=== Abstract link === Abstract link
Figure 7 : Architecture for Abstraction Layer Network Figure 7 : Architecture for Abstraction Layer Network
When the client layer needs additional connectivity it can make a When the client network needs additional connectivity it can make a
request to the abstraction layer network. For example, the operator request to the abstraction layer network. For example, the operator
of the client network may want to create a link from C2 to C3. The of the client network may want to create a link from C2 to C3. The
abstraction layer can see the potential path C2-CN1-CN4-C3 and can abstraction layer can see the potential path C2-CN1-CN4-C3 and can
set up an LSP C2-CN1-CN4-C3 across the server network and make the set up an LSP C2-CN1-CN4-C3 across the server network and make the
LSP available as a link in the client network. LSP available as a link in the client network.
Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the
requirements for connectivity in client-server networks and in peer requirements for connectivity in client-server networks and in peer
networks. networks.
skipping to change at page 25, line 9 skipping to change at page 25, line 9
- Management of changes in the server network that lead to limited - Management of changes in the server network that lead to limited
capabilities to reach (cross-connect) across the Abstract Node. It capabilities to reach (cross-connect) across the Abstract Node. It
may be noted that recent work on limited cross-connect capabilities may be noted that recent work on limited cross-connect capabilities
such as exist in asymmetrical switches could be used to represent such as exist in asymmetrical switches could be used to represent
the limitations in an abstract node [RFC7579], [RFC7580]. the limitations in an abstract node [RFC7579], [RFC7580].
4.2.3. Abstraction in Client-Server Networks 4.2.3. Abstraction in Client-Server Networks
Figure 9 shows the basic architectural concepts for a client-server Figure 9 shows the basic architectural concepts for a client-server
network. The client network nodes are C1, C2, CE1, CE2, C3, and C4. network. The client network nodes are C1, C2, CE1, CE2, C3, and C4.
The core network nodes are CN1, CN2, CN3, and CN4. The interfaces The server (core) network nodes are CN1, CN2, CN3, and CN4. The
CE1-CN1 and CE2-CN2 are the interfaces between the client and core interfaces CE1-CN1 and CE2-CN2 are the interfaces between the client
networks. and server networks.
The technologies (switching capabilities) of the client and server The technologies (switching capabilities) of the client and server
networks may be the same or different. If they are different, the networks may be the same or different. If they are different, the
client layer traffic must be tunneled over a server layer LSP. If client network traffic must be tunneled over a server network LSP.
they are the same, the client LSP may be routed over the server layer If they are the same, the client network LSP may be routed over the
links, tunneled over a server layer LSP, or constructed from the server network links, tunneled over a server network LSP, or
concatenation (stitching) of client layer and server layer LSP constructed from the concatenation (stitching) of client network and
segments. server network LSP segments.
: : : :
Client Network : Core Network : Client Network Client Network : Server Network : Client Network
: : : :
-- -- --- --- -- -- -- -- --- --- -- --
|C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4| |C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|
-- -- | | --- --- | | -- -- -- -- | | --- --- | | -- --
| |===|CN1|================|CN4|===| | | |===|CN1|================|CN4|===| |
| |---| | | |---| | | |---| | | |---| |
--- | | --- --- | | --- --- | | --- --- | | ---
| |--|CN2|--|CN3|--| | | |--|CN2|--|CN3|--| |
--- --- --- --- --- --- --- ---
Key Key
--- Direct connection between two nodes --- Direct connection between two nodes
... CE-to-CE LSP tunnel ... CE-to-CE LSP tunnel
=== Potential path across the core (abstract link) === Potential path across the server network (abstract link)
Figure 9 : Architecture for Client-Server Network Figure 9 : Architecture for Client-Server Network
The objective is to be able to support an end-to-end connection, The objective is to be able to support an end-to-end connection,
C1-to-C4, in the client network. This connection may support TE or C1-to-C4, in the client network. This connection may support TE or
normal IP forwarding. To achieve this, CE1 is to be connected to CE2 normal IP forwarding. To achieve this, CE1 is to be connected to CE2
by a link in the client layer. This enables the client network to by a link in the client network. This enables the client network to
view itself as connected and to select an end-to-end path. view itself as connected and to select an end-to-end path.
As shown in the figure, three abstraction layer links are formed: As shown in the figure, three abstraction layer links are formed:
CE1-CN1, CN1-CN2, and CN2-CE2. A three-hop LSP is then established CE1-CN1, CN1-CN2, and CN2-CE2. A three-hop LSP is then established
from CE1 to CE2 that can be presented as a link in the client layer. from CE1 to CE2 that can be presented as a link in the client
network.
The practicalities of how the CE1-CE2 LSP is carried across the core The practicalities of how the CE1-CE2 LSP is carried across the
LSP may depend on the switching and signaling options available in server network LSP may depend on the switching and signaling options
the core network. The LSP may be tunneled down the core LSP using available in the server network. The LSP may be tunneled down the
the mechanisms of a hierarchical LSP [RFC4206], or the LSP segments server network LSP using the mechanisms of a hierarchical LSP
CE1-CN1 and CN2-CE2 may be stitched to the core LSP as described in [RFC4206], or the LSP segments CE1-CN1 and CN2-CE2 may be stitched to
[RFC5150]. the server network LSP as described in [RFC5150].
Section 4.2.2 has already introduced the concept of the abstraction Section 4.2.2 has already introduced the concept of the abstraction
layer network through an example of a simple layered network. But it layer network through an example of a simple layered network. But it
may be helpful to expand on the example using a slightly more complex may be helpful to expand on the example using a slightly more complex
network. network.
Figure 10 shows a multi-layer network comprising client nodes Figure 10 shows a multi-layer network comprising client network nodes
(labeled as Cn for n= 0 to 9) and server nodes (labeled as Sn for (labeled as Cn for n= 0 to 9) and server network nodes (labeled as Sn
n = 1 to 9). for n = 1 to 9).
-- -- -- --
|C3|---|C4| |C3|---|C4|
/-- --\ /-- --\
-- -- -- -- --/ \-- -- -- -- -- --/ \--
|C1|---|C2|---|S1|---|S2|----|S3| |C5| |C1|---|C2|---|S1|---|S2|----|S3| |C5|
-- /-- --\ --\ --\ /-- -- /-- --\ --\ --\ /--
/ \-- \-- \-- --/ -- / \-- \-- \-- --/ --
/ |S4| |S5|----|S6|---|C6|---|C7| / |S4| |S5|----|S6|---|C6|---|C7|
/ /-- --\ /-- /-- -- / /-- --\ /-- /-- --
--/ -- --/ -- \--/ --/ --/ -- --/ -- \--/ --/
|C8|---|C9|---|S7|---|S8|----|S9|---|C0| |C8|---|C9|---|S7|---|S8|----|S9|---|C0|
-- -- -- -- -- -- -- -- -- -- -- --
Figure 10 : An example Multi-Layer Network Figure 10 : An example Multi-Layer Network
If the network in Figure 10 is operated as separate client and server If the network in Figure 10 is operated as separate client and server
networks then the client layer topology will appear as shown in networks then the client network topology will appear as shown in
Figure 11. As can be clearly seen, the network is partitioned and
-- -- -- --
|C3|---|C4| |C3|---|C4|
-- --\ -- --\
-- -- \-- -- -- \--
|C1|---|C2| |C5| |C1|---|C2| |C5|
-- /-- /-- -- /-- /--
/ --/ -- / --/ --
/ |C6|---|C7| / |C6|---|C7|
/ /-- -- / /-- --
--/ -- --/ --/ -- --/
|C8|---|C9| |C0| |C8|---|C9| |C0|
-- -- -- -- -- --
Figure 11 : Client Layer Topology Showing Partitioned Network Figure 11 : Client Network Topology Showing Partitioned Network
Figure 11. As can be clearly seen, the network is partitioned and
there is no way to set up an LSP from a node on the left hand side there is no way to set up an LSP from a node on the left hand side
(say C1) to a node on the right hand side (say C7). (say C1) to a node on the right hand side (say C7).
For reference, Figure 12 shows the corresponding server layer For reference, Figure 12 shows the corresponding server network
topology. topology.
-- -- -- -- -- --
|S1|---|S2|----|S3| |S1|---|S2|----|S3|
--\ --\ --\ --\ --\ --\
\-- \-- \-- \-- \-- \--
|S4| |S5|----|S6| |S4| |S5|----|S6|
/-- --\ /-- /-- --\ /--
--/ -- \--/ --/ -- \--/
|S7|---|S8|----|S9| |S7|---|S8|----|S9|
-- -- -- -- -- --
Figure 12 : Server Layer Topology Figure 12 : Server Network Topology
Operating on the TED for the server layer, a management entity or a Operating on the TED for the server network, a management entity or a
software component may apply policy and consider what abstract links software component may apply policy and consider what abstract links
it might offer for use by the client layer. To do this it obviously it might offer for use by the client network. To do this it
needs to be aware of the connections between the layers (there is no obviously needs to be aware of the connections between the layers
point in offering an abstract link S2-S8 since this could not be of (there is no point in offering an abstract link S2-S8 since this
any use in this example). could not be of any use in this example).
In our example, after consideration of which LSPs could be set up in In our example, after consideration of which LSPs could be set up in
the server layer, four abstract links are offered: S1-S3, S3-S6, the server network, four abstract links are offered: S1-S3, S3-S6,
S1-S9, and S7-S9. These abstract links are shown as double lines on S1-S9, and S7-S9. These abstract links are shown as double lines on
the resulting topology of the abstraction layer network in Figure 13. the resulting topology of the abstraction layer network in Figure 13.
As can be seen, two of the links must share part of a path (S1-S9 As can be seen, two of the links must share part of a path (S1-S9
must share with either S1-S3 or with S7-S9). This could be achieved must share with either S1-S3 or with S7-S9). This could be achieved
using distinct resources (for example, separate lambdas) where the
-- --
|C3| |C3|
/-- /--
-- -- --/ -- -- --/
|C2|---|S1|==========|S3| |C2|---|S1|==========|S3|
-- --\\ --\\ -- --\\ --\\
\\ \\ \\ \\
\\ \\-- -- \\ \\-- --
\\ |S6|---|C6| \\ |S6|---|C6|
\\ -- -- \\ -- --
-- -- \\-- -- -- -- \\-- --
|C9|---|S7|=====|S9|---|C0| |C9|---|S7|=====|S9|---|C0|
-- -- -- -- -- -- -- --
Figure 13 : Abstraction Layer Network with Abstract Links Figure 13 : Abstraction Layer Network with Abstract Links
using distinct resources (for example, separate lambdas) where the
paths are common, but it could also be done using resource sharing. paths are common, but it could also be done using resource sharing.
That would mean that when both paths S1-S3 and S7-S9 carry client- That would mean that when both paths S1-S3 and S7-S9 carry client-
edge to client-edge LSPs the resources on the path S1-S9 are used and edge to client-edge LSPs the resources on the path S1-S9 are used and
might be depleted to the point that the path is resource constrained might be depleted to the point that the path is resource constrained
and cannot be used. and cannot be used.
The separate IGP instance running in the abstraction layer network The separate IGP instance running in the abstraction layer network
means that this topology is visible at the edge nodes (C2, C3, C6, means that this topology is visible at the edge nodes (C2, C3, C6,
C9, and C0) as well as at a PCE if one is present. C9, and C0) as well as at a PCE if one is present.
Now the client layer is able to make requests to the abstraction Now the client network is able to make requests to the abstraction
layer network to provide connectivity. In our example, it requests layer network to provide connectivity. In our example, it requests
that C2 is connected to C3 and that C2 is connected to C0. This that C2 is connected to C3 and that C2 is connected to C0. This
results in several actions: results in several actions:
1. The management component for the abstraction layer network asks 1. The management component for the abstraction layer network asks
its PCE to compute the paths necessary to make the connections. its PCE to compute the paths necessary to make the connections.
This yields C2-S1-S3-C3 and C2-S1-S9-C0. This yields C2-S1-S3-C3 and C2-S1-S9-C0.
2. The management component for the abstraction layer network 2. The management component for the abstraction layer network
instructs C2 to start the signaling process for the new LSPs in instructs C2 to start the signaling process for the new LSPs in
the abstraction layer. the abstraction layer.
3. C2 signals the LSPs for setup using the explicit routes 3. C2 signals the LSPs for setup using the explicit routes
C2-S1-S3-C3 and C2-S1-S9-C0. C2-S1-S3-C3 and C2-S1-S9-C0.
4. When the signaling messages reach S1 (in our example, both LSPs 4. When the signaling messages reach S1 (in our example, both LSPs
traverse S1) the server layer network may support them by a traverse S1) the server network may support them by a number of
number of means including establishing server layer LSPs as means including establishing server network LSPs as tunnels
tunnels depending on the mismatch of technologies between the depending on the mismatch of technologies between the client and
client and server networks. For example, S1-S2-S3 and S1-S2-S5-S9 server networks. For example, S1-S2-S3 and S1-S2-S5-S9 might be
might be traversed via an LSP tunnel, using LSPs stitched traversed via an LSP tunnel, using LSPs stitched together, or
together, or simply by routing the client layer LSP through the simply by routing the client network LSP through the server
server network. If server layer LSPs are needed to they can be network. If server network LSPs are needed to they can be
signaled at this point. signaled at this point.
5. Once any server layer LSPs that are needed have been established, 5. Once any server network LSPs that are needed have been
S1 can continue to signal the client-edge to client-edge LSP established, S1 can continue to signal the client-edge to client-
across the abstraction layer either using the server layer LSPs as edge LSP across the abstraction layer either using the server
tunnels or as stitching segments, or simply routing through the network LSPs as tunnels or as stitching segments, or simply
server layer network. routing through the server network.
6. Finally, once the client-edge to client-edge LSPs have been set 6. Finally, once the client-edge to client-edge LSPs have been set
up, the client layer can be informed and can start to advertise up, the client network can be informed and can start to advertise
the new TE links C2-C3 and C2-C0. The resulting client layer the new TE links C2-C3 and C2-C0. The resulting client network
topology is shown in Figure 14. topology is shown in Figure 14.
-- -- -- --
|C3|-|C4| |C3|-|C4|
/-- --\ /-- --\
/ \-- / \--
-- --/ |C5| -- --/ |C5|
|C1|---|C2| /-- |C1|---|C2| /--
-- /--\ --/ -- -- /--\ --/ --
/ \ |C6|---|C7| / \ |C6|---|C7|
/ \ /-- -- / \ /-- --
/ \--/ / \--/
--/ -- |C0| --/ -- |C0|
|C8|---|C9| -- |C8|---|C9| --
-- -- -- --
Figure 14 : Connected Client Layer Network with Additional Links Figure 14 : Connected Client Network with Additional Links
7. Now the client layer can compute an end-to-end path from C1 to C7. 7. Now the client network can compute an end-to-end path from C1 to
C7.
4.2.3.1 A Server with Multiple Clients 4.2.3.1 A Server with Multiple Clients
A single server network may support multiple client networks. This A single server network may support multiple client networks. This
is not an uncommon state of affairs for example when the server is not an uncommon state of affairs for example when the server
network provides connectivity for multiple customers. network provides connectivity for multiple customers.
In this case, the abstraction provided by the server layer may vary In this case, the abstraction provided by the server network may vary
considerably according to the policies and commercial relationships considerably according to the policies and commercial relationships
with each customer. This variance would lead to a separate with each customer. This variance would lead to a separate
abstraction layer network maintained to support each client network. abstraction layer network maintained to support each client network.
On the other hand, it may be that multiple clients are subject to the On the other hand, it may be that multiple clients networks are
same policies and the abstraction can be identical. In this case, a subject to the same policies and the abstraction can be identical.
single abstraction layer network can support more than one client. In this case, a single abstraction layer network can support more
than one client.
The choices here are made as an operational issue by the server layer The choices here are made as an operational issue by the server
network. network.
4.2.3.2 A Client with Multiple Servers 4.2.3.2 A Client with Multiple Servers
A single client network may be supported by multiple server networks. A single client network may be supported by multiple server networks.
The server networks may provide connectivity between different parts The server networks may provide connectivity between different parts
of the client network or may provide parallel (redundant) of the client network or may provide parallel (redundant)
connectivity for the client network. connectivity for the client network.
In this case the abstraction layer network should contain the In this case the abstraction layer network should contain the
skipping to change at page 31, line 8 skipping to change at page 31, line 8
Peer networks exist in many situations in the Internet. Packet Peer networks exist in many situations in the Internet. Packet
networks may peer as IGP areas (levels) or as ASes. Transport networks may peer as IGP areas (levels) or as ASes. Transport
networks (such as optical networks) may peer to provide networks (such as optical networks) may peer to provide
concatenations of optical paths through single vendor environments concatenations of optical paths through single vendor environments
(see Section 6). Figure 16 shows a simple example of three peer (see Section 6). Figure 16 shows a simple example of three peer
networks (A, B, and C) each comprising a few nodes. networks (A, B, and C) each comprising a few nodes.
Network A : Network B : Network C Network A : Network B : Network C
: : : :
-- -- -- : -- -- -- : -- -- -- -- -- : -- -- -- : -- --
|A1|---|A2|----|A3|---|B1|---|B2----|B3|---|C1|---|C2| |A1|---|A2|----|A3|---|B1|---|B2|---|B3|---|C1|---|C2|
-- --\ /-- : -- /--\ -- : -- -- -- --\ /-- : -- /--\ -- : -- --
\--/ : / \ : \--/ : / \ :
|A4| : / \ : |A4| : / \ :
--\ : / \ : --\ : / \ :
-- \-- : --/ \-- : -- -- -- \-- : --/ \-- : -- --
|A5|---|A6|---|B4|----------|B6|---|C3|---|C4| |A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
-- -- : -- -- : -- -- -- -- : -- -- : -- --
: : : :
: : : :
skipping to change at page 32, line 42 skipping to change at page 32, line 42
Sections 6 and 8. Sections 6 and 8.
4.3. Considerations for Dynamic Abstraction 4.3. Considerations for Dynamic Abstraction
It is possible to consider a highly dynamic system where the server It is possible to consider a highly dynamic system where the server
network adaptively suggests new abstract links into the abstraction network adaptively suggests new abstract links into the abstraction
layer, and where the abstraction layer proactively deploys new layer, and where the abstraction layer proactively deploys new
client-edge to client-edge LSPs to provide new links in the client client-edge to client-edge LSPs to provide new links in the client
network. Such fluidity is, however, to be treated with caution network. Such fluidity is, however, to be treated with caution
especially in the case of client-server networks of differing especially in the case of client-server networks of differing
technologies where hierarchical server layer LSPs are used because of technologies where hierarchical server network LSPs are used because
the longer turn-up times of connections in some server networks, of the longer turn-up times of connections in some server networks,
because the server networks are likely to be sparsely connected and because the server networks are likely to be sparsely connected and
expensive physical resources will only be deployed where there is expensive physical resources will only be deployed where there is
believed to be a need for them. More significantly, the complex believed to be a need for them. More significantly, the complex
commercial, policy, and administrative relationships that may exist commercial, policy, and administrative relationships that may exist
between client and server network operators mean that stability is between client and server network operators mean that stability is
more likely to be the desired operational practice. more likely to be the desired operational practice.
Thus, proposals for fully automated multi-layer networks based on Thus, proposals for fully automated multi-layer networks based on
this architecture may be regarded as forward-looking topics for this architecture may be regarded as forward-looking topics for
research both in terms of network stability and with regard to research both in terms of network stability and with regard to
skipping to change at page 33, line 29 skipping to change at page 33, line 29
4.4. Requirements for Advertising Links and Nodes 4.4. Requirements for Advertising Links and Nodes
The abstraction layer network is "just another network layer". The The abstraction layer network is "just another network layer". The
links and nodes in the network need to be advertised along with their links and nodes in the network need to be advertised along with their
associated TE information (metrics, bandwidth, etc.) so that the associated TE information (metrics, bandwidth, etc.) so that the
topology is disseminated and so that routing decisions can be made. topology is disseminated and so that routing decisions can be made.
This requires a routing protocol running between the nodes in the This requires a routing protocol running between the nodes in the
abstraction layer network. Note that this routing information abstraction layer network. Note that this routing information
exchange could be piggy-backed on an existing routing protocol exchange could be piggy-backed on an existing routing protocol
instance, or use a new instance (or even a new protocol). Clearly, instance (subject to different switching capabilities applying to the
the information exchanged is only that which has been created as links in the different networks, or to adequate address space
part of the abstraction function according to policy. separation), or use a new instance (or even a new protocol).
Clearly, the information exchanged is only that which has been
created as part of the abstraction function according to policy.
It should be noted that in many cases the abstract represents the It should be noted that in many cases the abstract represents the
potential for connectivity across the server network but that no such potential for connectivity across the server network but that no such
connectivity exists. In this case we may ponder how the routing connectivity exists. In this case we may ponder how the routing
protocol in the abstraction layer will advertise topology information protocol in the abstraction layer will advertise topology information
for and over a link that has no underlying connectivity. In other for and over a link that has no underlying connectivity. In other
words, there must be a communication channel between the abstract words, there must be a communication channel between the abstract
layer nodes so that the routing protocol messages can flow. The layer nodes so that the routing protocol messages can flow. The
answer is that control plane connectivity already exists in the answer is that control plane connectivity already exists in the
server network and on the client-server edge links, and this can be server network and on the client-server edge links, and this can be
skipping to change at page 34, line 23 skipping to change at page 34, line 28
announces an abstract link from A to B, the abstraction layer 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 must recognize that A and B are server network addresses and must map
them to abstraction layer addresses (say P and Q) before including them to abstraction layer addresses (say P and Q) before including
the link in its own topology. And similarly, when the abstraction the link in its own topology. And similarly, when the abstraction
layer network informs the client network that a new link is available 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 from S to T, it must map those addresses from its own address space
to that of the client network. to that of the client network.
This form of address mapping will become particularly important in This form of address mapping will become particularly important in
cases where one abstraction layer network is constructed from cases where one abstraction layer network is constructed from
connectivity in multiple server layer networks, or where one connectivity in multiple server networks, or where one abstraction
abstraction layer network provides connectivity for multiple client layer network provides connectivity for multiple client networks.
networks.
5. Building on Existing Protocols 5. Building on Existing Protocols
This section is not intended to prejudge a solutions framework or any This section is not intended to prejudge a solutions framework or any
applicability work. It does, however, very briefly serve to note the applicability work. It does, however, very briefly serve to note the
existence of protocols that could be examined for applicability to existence of protocols that could be examined for applicability to
serve in realizing the model described in this document. serve in realizing the model described in this document.
The general principle of protocol re-use is preferred over the The general principle of protocol re-use is preferred over the
invention of new protocols or additional protocol extensions, and it invention of new protocols or additional protocol extensions, and it
skipping to change at page 35, line 28 skipping to change at page 35, line 32
spaces) or as dual instances on the same address space. This means spaces) or as dual instances on the same address space. This means
that either IGP could probably be used as the routing protocol in the that either IGP could probably be used as the routing protocol in the
abstraction layer network. abstraction layer network.
5.3. RSVP-TE 5.3. RSVP-TE
RSVP-TE signaling can be used to set up all traffic engineered LSPs RSVP-TE signaling can be used to set up all traffic engineered LSPs
demanded by this model without the need for any protocol extensions. demanded by this model without the need for any protocol extensions.
If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can
be used to carry LSPs over the server layer network, again without be used to carry LSPs over the server network, again without needing
needing any protocol extensions. any protocol extensions.
Furthermore, the procedures in [RFC6107] allow the dynamic signaling Furthermore, the procedures in [RFC6107] allow the dynamic signaling
of the purpose of any LSP that is established. This means that of the purpose of any LSP that is established. This means that
when an LSP tunnel is set up, the two ends can coordinate into which when an LSP tunnel is set up, the two ends can coordinate into which
routing protocol instance it should be advertised, and can also agree routing protocol instance it should be advertised, and can also agree
on the addressing to be said to identify the link that will be on the addressing to be said to identify the link that will be
created. created.
5.4. Notes on a Solution 5.4. Notes on a Solution
skipping to change at page 36, line 39 skipping to change at page 36, line 42
The abstraction layer network may operate under central control or The abstraction layer network may operate under central control or
use a distributed control plane. Since the links and nodes may be a use a distributed control plane. Since the links and nodes may be a
mix of physical and abstract links, and since the nodes may have mix of physical and abstract links, and since the nodes may have
diverse cross-connect capabilities, it is most likely that a GMPLS diverse cross-connect capabilities, it is most likely that a GMPLS
routing protocol will be beneficial for collecting and correlating routing protocol will be beneficial for collecting and correlating
the routing information and for distributing updates. No special the routing information and for distributing updates. No special
additional features are needed beyond adding those extra parameters additional features are needed beyond adding those extra parameters
just described for BGP-LS, but it should be noted that the control just described for BGP-LS, but it should be noted that the control
plane of the abstraction layer network must run in an out of band plane of the abstraction layer network must run in an out of band
control network because the data-bearing links might not yet have control network because the data-bearing links might not yet have
been established via connections in the server layer network. been established via connections in the server network.
The abstraction layer network is also able to determine potential The abstraction layer network is also able to determine potential
connectivity from client network edge to client network edge. It connectivity from client network edge to client network edge. It
will determine which client network links to create according to will determine which client network links to create according to
policy and subject to requests from the client network, and will policy and subject to requests from the client network, and will
take four steps: take four steps:
- First it will compute a path for across the abstraction layer - First it will compute a path for across the abstraction layer
network. network.
- Then, if the support of the abstract links requires the use of
server layer LSPs for tunneling or stitching, and if those LSPs are
not already established, it will ask the server layer to set them
up.
- Then, if the support of the abstract links requires the use of
server network LSPs for tunneling or stitching, and if those LSPs
are not already established, it will ask the server layer to set
them up.
- Then, it will signal the client-edge to client-edge LSP. - Then, it will signal the client-edge to client-edge LSP.
- Finally, the abstraction layer network will inform the client - Finally, the abstraction layer network will inform the client
network of the existence of the new client network link. network of the existence of the new client network link.
This last step can be achieved either by coordination of the end This last step can be achieved either by coordination of the end
points of the LSPs that span the abstraction layer (these points are points of the LSPs that span the abstraction layer (these points are
client network edge nodes) using mechanisms such as those described client network edge nodes) using mechanisms such as those described
in [RFC6107], or using BGP-LS from a central controller. in [RFC6107], or using BGP-LS from a central controller.
Once the client network edge nodes are aware of a new link, they will Once the client network edge nodes are aware of a new link, they will
skipping to change at page 41, line 48 skipping to change at page 41, line 50
Ethernet UNI reference model, and that figure can serve as an example Ethernet UNI reference model, and that figure can serve as an example
for all similar UNIs. In this case, the UNI is an interface between for all similar UNIs. In this case, the UNI is an interface between
client network edge nodes and the server network. It should be noted client network edge nodes and the server network. It should be noted
that neither the client network nor the server network need be an that neither the client network nor the server network need be an
Ethernet switching network. Ethernet switching network.
There are three network layers in this model: the client network, the 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", and the server network. The so-called
Ethernet service network consists of links comprising the UNI links Ethernet service network consists of links comprising the UNI links
and the tunnels across the server network, and nodes comprising the and the tunnels across the server network, and nodes comprising the
client network edge nodes and various server nodes. That is, the client network edge nodes and various server network nodes. That is,
Ethernet service network is equivalent to the abstraction layer the Ethernet service network is equivalent to the abstraction layer
network with the UNI links being the physical links between the network with the UNI links being the physical links between the
client and server networks, and the client edge nodes taking the client and server networks, and the client edge nodes taking the
role of UNI Client-side (UNI-C) and the server edge nodes acting as role of UNI Client-side (UNI-C) and the server edge nodes acting as
the UNI Network-side (UNI-N) nodes. the UNI Network-side (UNI-N) nodes.
Client Client Client Client
Network +----------+ +-----------+ Network Network +----------+ +-----------+ Network
-------------+ | | | | +------------- -------------+ | | | | +-------------
+----+ | | +-----+ | | +-----+ | | +----+ +----+ | | +-----+ | | +-----+ | | +----+
------+ | | | | | | | | | | | | +------ ------+ | | | | | | | | | | | | +------
skipping to change at page 42, line 27 skipping to change at page 42, line 29
-------------+ | | | | | | | | +------------- -------------+ | | | | | | | | +-------------
| | | | | | | | | | | | | | | |
-------------+ | | | | | | | | +------------- -------------+ | | | | | | | | +-------------
| | | +--+--+ | | | +--+--+ | | | | | +--+--+ | | | +--+--+ | |
+----+ | | | | | | +--+--+ | | | +----+ +----+ | | | | | | +--+--+ | | | +----+
------+ +-+--+ | | CN +-+----+--+ CN | | | | +------ ------+ +-+--+ | | CN +-+----+--+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------ ------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | | +-----+ | | +-----+ | | | | | | | | +-----+ | | +-----+ | | | |
+----+ | | | | | | +----+ +----+ | | | | | | +----+
| +----------+ |-----------+ | | +----------+ |-----------+ |
-------------+ Server Network(s) +------------- -------------+ Server Networks +-------------
Client UNI UNI Client Client UNI UNI Client
Network <-----> <-----> Network Network <-----> <-----> Network
Scope of This Document Scope of This Document
Legend: EN - Client Edge Node Legend: EN - Client Network Edge Node
CN - Server Node CN - Server Network (Core) Node
Figure 22 : Ethernet UNI Reference Model Figure 22 : Ethernet UNI Reference Model
An issue that is often raised concerns how a dual-homed client edge An issue that is often raised concerns how a dual-homed client
node (such as that shown at the bottom left-hand corner of Figure 22) network edge node (such as that shown at the bottom left-hand corner
can make determinations about how they connect across the UNI. This of Figure 22) can make determinations about how they connect across
can be particularly important when reachability across the server the UNI. This can be particularly important when reachability across
network is limited or when two diverse paths are desired (for the server network is limited or when two diverse paths are desired
example, to provide protection). However, in the model described in (for example, to provide protection). However, in the model
this network, the edge node (the UNI-C) is part of the abstraction described in this network, the edge node (the UNI-C) is part of the
layer network and can see sufficient topology information to make abstraction layer network and can see sufficient topology information
these decisions. If the approach introduced in this document is used to make these decisions. If the approach introduced in this document
to model the UNI as described in this section, there is no need to is used to model the UNI as described in this section, there is no
enhance the signaling protocols at the GMPLS UNI nor to add routing need to enhance the signaling protocols at the GMPLS UNI nor to add
exchanges at the UNI. routing exchanges at the UNI.
8. Abstraction in L3VPN Multi-AS Environments 8. Abstraction in L3VPN Multi-AS Environments
Serving layer-3 VPNs (L3PVNs) across a multi-AS or multi-operator Serving layer-3 VPNs (L3PVNs) across a multi-AS or multi-operator
environment currently provides a significant planning challenge. environment currently provides a significant planning challenge.
Figure 6 shows the general case of the problem that needs to be Figure 6 shows the general case of the problem that needs to be
solved. This section shows how the abstraction layer network can solved. This section shows how the abstraction layer network can
address this problem. address this problem.
In the VPN architecture, the CE nodes are the client network edge In the VPN architecture, the CE nodes are the client network edge
skipping to change at page 45, line 47 skipping to change at page 45, line 47
Other than that, however, the management should be essentially the Other than that, however, the management should be essentially the
same. Routing and signaling protocols can be run in the abstraction same. Routing and signaling protocols can be run in the abstraction
layer (using out of band channels for links that have not yet been layer (using out of band channels for links that have not yet been
established), and a centralized TED can be constructed and used to established), and a centralized TED can be constructed and used to
examine the availability and status of the links and nodes in the examine the availability and status of the links and nodes in the
network. network.
Note that different deployment models will place the "ownership" of Note that different deployment models will place the "ownership" of
the abstraction layer network differently. In some case the the abstraction layer network differently. In some case the
abstraction layer network will be constructed by the operator of the abstraction layer network will be constructed by the operator of the
server layer and run by that operator as a service for one or more server network and run by that operator as a service for one or more
client networks. In other cases, one or more server networks will client networks. In other cases, one or more server networks will
present the potential of links to an abstraction layer network run present the potential of links to an abstraction layer network run
by the operator of the client network. And it is feasible that a by the operator of the client network. And it is feasible that a
business model could be built where a third-party operator manages business model could be built where a third-party operator manages
the abstraction layer network, constructing it from the connectivity the abstraction layer network, constructing it from the connectivity
available in multiple server networks, and facilitating connectivity available in multiple server networks, and facilitating connectivity
for multiple client networks. for multiple client networks.
10.2. Managing Interactions of Client and Abstraction Layer Networks 10.2. Managing Interactions of Client and Abstraction Layer Networks
The interaction between the client network and the abstraction layer The interaction between the client network and the abstraction layer
network is a management task. It might be automated (software network is a management task. It might be automated (software
driven) or it might require manual intervention. driven) or it might require manual intervention.
This is a two-way interaction: This is a two-way interaction:
- The client network can express the need for additional - The client network can express the need for additional
connectivity. For example, the client layer may try and fail to connectivity. For example, the client network may try and fail to
find a path across the client network and may request additional, find a path across the client network and may request additional,
specific connectivity (this is similar to the situation with specific connectivity (this is similar to the situation with
Virtual Network Topology Manager (VNTM) [RFC5623]). Alternatively, Virtual Network Topology Manager (VNTM) [RFC5623]). Alternatively,
a more proactive client layer management system may monitor traffic a more proactive client network management system may monitor
demands (current and predicted), network usage, and network "hot traffic demands (current and predicted), network usage, and network
spots" and may request changes in connectivity by both releasing "hot spots" and may request changes in connectivity by both
unused links and by requesting new links. releasing unused links and by requesting new links.
- The abstraction layer network can make links available to the - The abstraction layer network can make links available to the
client network or can withdraw them. These actions can be in client network or can withdraw them. These actions can be in
response to requests from the client layer, or can be driven by response to requests from the client network, or can be driven by
processes within the abstraction layer (perhaps reorganizing the processes within the abstraction layer (perhaps reorganizing the
use of server layer resources). In any case, the presentation of use of server network resources). In any case, the presentation of
new links to the client layer is heavily subject to policy since new links to the client network is heavily subject to policy since
this is both operationally key to the success of this architecture this is both operationally key to the success of this architecture
and the central plank of the commercial model described in this and the central plank of the commercial model described in this
document. Such policies belong to the operator of the abstraction document. Such policies belong to the operator of the abstraction
layer network and are expected to be fully configurable. layer network and are expected to be fully configurable.
Once the abstraction layer network has decided to make a link Once the abstraction layer network has decided to make a link
available to the client network it will install it at the link end 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 points (which are nodes in the client network) such that it appears
and can be advertised as a link in the client network. and can be advertised as a link in the client network.
In all cases, it is important that the operators of both networks are 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 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 client network should be able to see which links in that network are
"real" physical links, and which are presented by the abstraction "real" physical links, and which are presented by the abstraction
layer network. layer network.
10.3. Managing Interactions of Abstraction Layer and Server Networks 10.3. Managing Interactions of Abstraction Layer and Server Networks
The interactions between the abstraction layer network and the server The interactions between the abstraction layer network and the server
network a similar to those described in Section 10.2, but there is a network a similar to those described in Section 10.2, but there is a
difference in that the server layer is more likely to offer up difference in that the server network is more likely to offer up
connectivity, and the abstraction layer network is less likely to ask connectivity, and the abstraction layer network is less likely to ask
for it. for it.
That is, the server network will, according to policy that may That is, the server network will, according to policy that may
include commercial relationships, offer the abstraction layer network include commercial relationships, offer the abstraction layer network
a set of potential connectivity that the abstraction layer network a set of potential connectivity that the abstraction layer network
can treat as links. This server network policy will include: can treat as links. This server network policy will include:
- how much connectivity to offer - how much connectivity to offer
- what level of server layer redundancy to include - what level of server network redundancy to include
- how to support the use of the abstraction links, - how to support the use of the abstraction links,
This process of offering links from the server network may include a This process of offering links from the server network may include a
mechanism to indicate which links have been pre-established in the mechanism to indicate which links have been pre-established in the
server network, and can include other properties such as: server network, and can include other properties such as:
- link-level protection ([RFC4202]) - link-level protection ([RFC4202])
- SRLG and MSRLG (see Appendix A) - SRLG and MSRLG (see Appendix A)
- mutual exclusivity (see Appendix B). - mutual exclusivity (see Appendix B).
The abstraction layer network needs a mechanism to tell the server The abstraction layer network needs a mechanism to tell the server
This mechanism could also include the ability to request additional network which links it is making use of. This mechanism could also
connectivity from the server layer, although it seems most likely include the ability to request additional connectivity from the
that the server layer will already have presented as much server network, although it seems most likely that the server network
connectivity as it is physically capable of subject to the will already have presented as much connectivity as it is physically
constraints of policy. capable of subject to the constraints of policy.
Finally, the server layer will need to confirm the establishment of Finally, the server network will need to confirm the establishment of
connectivity, withdraw links if they are no longer feasible, and connectivity, withdraw links if they are no longer feasible, and
report failures. report failures.
Again, it is important that the operators of both networks are able Again, it is important that the operators of both networks are able
to track the requests and responses, and the operator of the server to track the requests and responses, and the operator of the server
network should be able to see which links are in use. network should be able to see which links are in use.
11. IANA Considerations 11. IANA Considerations
This document makes no requests for IANA action. The RFC Editor may This document makes no requests for IANA action. The RFC Editor may
safely remove this section. safely remove this section.
12. Security Considerations 12. Security Considerations
Security of signaling and routing protocols is usually administered Security of signaling and routing protocols is usually administered
and achieved within the boundaries of a domain. Thus, and for and achieved within the boundaries of a domain. Thus, and for
example, a domain with a GMPLS control plane [RFC3945] would apply example, a domain with a GMPLS control plane [RFC3945] would apply
the security mechanisms and considerations that are appropriate to the security mechanisms and considerations that are appropriate to
GMPLS [RFC5920]. Furthermore, domain-based security relies strongly GMPLS [RFC5920]. Furthermore, domain-based security relies strongly
on ensuring that control plane messages are not allowed to enter the on ensuring that control plane messages are not allowed to enter the
domain from outside. Thus, the mechanisms in this document for domain from outside.
inter-domain exchange of control plane messages and information
naturally raise additional questions of security.
In this context, additional security considerations arising from this In this context, additional security considerations arising from this
document relate to the exchange of control plane information between document relate to the exchange of control plane information between
domains. Messages are passed between domains using control plane domains. Messages are passed between domains using control plane
protocols operating between peers that have predictable relationships protocols operating between peers that have predictable relationships
(for example, UNI-C to UNI-N, between BGP-LS speakers, or between (for example, UNI-C to UNI-N, between BGP-LS speakers, or between
peer domains). Thus, the security that needs to be given additional peer domains). Thus, the security that needs to be given additional
attention for inter-domain TE concentrates on authentication of attention for inter-domain TE concentrates on authentication of
peers, assertion that messages have not been tampered with, and to a peers, assertion that messages have not been tampered with, and to a
lesser extent protecting the content of the messages from inspection lesser extent protecting the content of the messages from inspection
skipping to change at page 48, line 37 skipping to change at page 48, line 35
and the security mechanisms can be applied to the protocols operating and the security mechanisms can be applied to the protocols operating
in the out of band network. in the out of band network.
13. Acknowledgements 13. Acknowledgements
Thanks to Igor Bryskin for useful discussions in the early stages of Thanks to Igor Bryskin for useful discussions in the early stages of
this work and to Gert Grammel for discussions on the extent of this work and to Gert Grammel for discussions on the extent of
aggregation in abstract nodes and links. aggregation in abstract nodes and links.
Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam
Somasundaram, Hannes Gredler, and Stewart Bryant for review and Somasundaram, Hannes Gredler, Stewart Bryant, Brian Carpenter, and
input. Hilarie Orman for review and input.
Particular thanks to Vishnu Pavan Beeram for detailed discussions and Particular thanks to Vishnu Pavan Beeram for detailed discussions and
white-board scribbling that made many of the ideas in this document white-board scribbling that made many of the ideas in this document
come to life. come to life.
Text in Section 4.2.3 is freely adapted from the work of Igor Text in Section 4.2.3 is freely adapted from the work of Igor
Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel, Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel,
Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria, Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria,
Oscar Gonzalez de Dios, and Daniele Ceccarelli in Oscar Gonzalez de Dios, and Daniele Ceccarelli in
[I-D.beeram-ccamp-gmpls-enni] for which the authors of this document [I-D.beeram-ccamp-gmpls-enni] for which the authors of this document
skipping to change at page 57, line 41 skipping to change at page 57, line 41
used very effectively to select between interconnections x1 and x2 used very effectively to select between interconnections x1 and x2
in Figure 1. in Figure 1.
- Hierarchical PCE (H-PCE) [RFC6805] offers a parent PCE that is - Hierarchical PCE (H-PCE) [RFC6805] offers a parent PCE that is
responsible for navigating a path across the domain mesh and for responsible for navigating a path across the domain mesh and for
coordinating intra-domain computations by the child PCEs coordinating intra-domain computations by the child PCEs
responsible for each domain. This approach makes computing an end- responsible for each domain. This approach makes computing an end-
to-end path across a mesh of domains far more tractable. However, to-end path across a mesh of domains far more tractable. However,
it still leaves unanswered the issue of determining the location of it still leaves unanswered the issue of determining the location of
the destination (i.e., discovering the destination domain) as the destination (i.e., discovering the destination domain) as
described in Section 2.1.1. Furthermore, it raises the question of described in Section 2.1. Furthermore, it raises the question of
who operates the parent PCE especially in networks where the who operates the parent PCE especially in networks where the
domains are under different administrative and commercial control. domains are under different administrative and commercial control.
It should also be noted that [RFC5623] discusses how PCE is used in a It should also be noted that [RFC5623] discusses how PCE is used in a
multi-layer network with coordination between PCEs operating at each multi-layer network with coordination between PCEs operating at each
network layer. Further issues and considerations of the use of PCE network layer. Further issues and considerations of the use of PCE
can be found in [RFC7399]. can be found in [RFC7399].
A.4. GMPLS UNI and Overlay Networks A.4. GMPLS UNI and Overlay Networks
[RFC4208] defines the GMPLS User-to-Network Interface (UNI) to [RFC4208] defines the GMPLS User-to-Network Interface (UNI) to
present a routing boundary between an overlay network and the core present a routing boundary between an overlay (client) network and
network, i.e. the client-server interface. In the client network, the server network, i.e. the client-server interface. In the client
the nodes connected directly to the core network are known as edge network, the nodes connected directly to the server network are known
nodes, while the nodes in the server network are called core nodes. 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 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 closed system and the edge nodes do not participate in the routing
protocol instance that runs among the core nodes. Thus the UNI protocol instance that runs among the core nodes. Thus the UNI
allows access to and limited control of the core nodes by edge nodes allows access to and limited control of the core nodes by edge nodes
that are unaware of the topology of the core nodes. This respects that are unaware of the topology of the core nodes. This respects
the operational and layer boundaries while scaling the network. the operational and layer boundaries while scaling the network.
[RFC4208] does not define any routing protocol extension for the [RFC4208] does not define any routing protocol extension for the
interaction between core and edge nodes but allows for the exchange interaction between core and edge nodes but allows for the exchange
of reachability information between them. In terms of a VPN, the of reachability information between them. In terms of a VPN, the
client network can be considered as the customer network comprised client network can be considered as the customer network comprised
of a number of disjoint sites, and the edge nodes match the VPN CE of a number of disjoint sites, and the edge nodes match the VPN CE
nodes. Similarly, the provider network in the VPN model is nodes. Similarly, the provider network in the VPN model is
equivalent to the server network. equivalent to the server network.
[RFC4208] is, therefore, a signaling-only solution that allows edge [RFC4208] is, therefore, a signaling-only solution that allows edge
nodes to request connectivity cross the core network, and leaves the nodes to request connectivity cross the server network, and leaves
core network to select the paths for the LSPs as they traverse the the server network to select the paths for the LSPs as they traverse
core (setting up hierarchical LSPs if necessitated by the the core nodes (setting up hierarchical LSPs if necessitated by the
technology). This solution is supplemented by a number of signaling technology). This solution is supplemented by a number of signaling
extensions such as [RFC4874], [RFC5553], [I-D.ietf-ccamp-xro-lsp- extensions such as [RFC4874], [RFC5553], [I-D.ietf-ccamp-xro-lsp-
subobject], [I-D.ietf-ccamp-rsvp-te-srlg-collect], and [I-D.ietf- subobject], [I-D.ietf-ccamp-rsvp-te-srlg-collect], and [I-D.ietf-
ccamp-te-metric-recording] to give the edge node more control over ccamp-te-metric-recording] to give the edge node more control over
path within the core network and by allowing the edge nodes to supply path within the server network and by allowing the edge nodes to
additional constraints on the path used in the core network. supply additional constraints on the path used in the server network.
Nevertheless, in this UNI/overlay model, the edge node has limited Nevertheless, in this UNI/overlay model, the edge node has limited
information of precisely what LSPs could be set up across the core, information of precisely what LSPs could be set up across the server
and what TE services (such as diverse routes for end-to-end network, and what TE services (such as diverse routes for end-to-end
protection, end-to-end bandwidth, etc.) can be supported. protection, end-to-end bandwidth, etc.) can be supported.
A.5. Layer One VPN A.5. Layer One VPN
A Layer One VPN (L1VPN) is a service offered by a core layer 1 A Layer One VPN (L1VPN) is a service offered by a layer 1 server
network to provide layer 1 connectivity (TDM, LSC) between two or network to provide layer 1 connectivity (TDM, LSC) between two or
more customer networks in an overlay service model [RFC4847]. more customer networks in an overlay service model [RFC4847].
As in the UNI case, the customer edge has some control over the As in the UNI case, the customer edge has some control over the
establishment and type of the connectivity. In the L1VPN context establishment and type of the connectivity. In the L1VPN context
three different service models have been defined classified by the three different service models have been defined classified by the
semantics of information exchanged over the customer interface: semantics of information exchanged over the customer interface:
Management Based, Signaling Based (a.k.a. basic), and Signaling and Management Based, Signaling Based (a.k.a. basic), and Signaling and
Routing service model (a.k.a. enhanced). Routing service model (a.k.a. enhanced).
In the management based model, all edge-to-edge connections are set In the management based model, all edge-to-edge connections are set
up using configuration and management tools. This is not a dynamic up using configuration and management tools. This is not a dynamic
control plane solution and need not concern us here. control plane solution and need not concern us here.
In the signaling based service model [RFC5251] the CE-PE interface In the signaling based service model [RFC5251] the CE-PE interface
allows only for signaling message exchange, and the provider network allows only for signaling message exchange, and the provider network
does not export any routing information about the core network. VPN does not export any routing information about the server network.
membership is known a priori (presumably through configuration) or is VPN membership is known a priori (presumably through configuration)
discovered using a routing protocol [RFC5195], [RFC5252], [RFC5523], or is discovered using a routing protocol [RFC5195], [RFC5252],
as is the relationship between CE nodes and ports on the PE. This [RFC5523], as is the relationship between CE nodes and ports on the
service model is much in line with GMPLS UNI as defined in [RFC4208]. PE. This service model is much in line with GMPLS UNI as defined in
[RFC4208].
In the enhanced model there is an additional limited exchange of In the enhanced model there is an additional limited exchange of
routing information over the CE-PE interface between the provider routing information over the CE-PE interface between the provider
network and the customer network. The enhanced model considers four network and the customer network. The enhanced model considers four
different types of service models, namely: Overlay Extension, Virtual different types of service models, namely: Overlay Extension, Virtual
Node, Virtual Link and Per-VPN service models. All of these Node, Virtual Link and Per-VPN service models. All of these
represent particular cases of the TE information aggregation and represent particular cases of the TE information aggregation and
representation. representation.
A.6. Policy and Link Advertisement A.6. Policy and Link Advertisement
skipping to change at page 59, line 44 skipping to change at page 59, line 45
An important companion to this function is determining how An important companion to this function is determining how
connectivity across the abstraction layer network is made available connectivity across the abstraction layer network is made available
as a TE link in the client network. Obviously, if the connectivity as a TE link in the client network. Obviously, if the connectivity
is established using management intervention, the consequent client is established using management intervention, the consequent client
network TE link can also be configured manually. However, if network TE link can also be configured manually. However, if
connectivity from client edge to client edge is achieved using connectivity from client edge to client edge is achieved using
dynamic signalling then there is need for the end points to exchange dynamic signalling then there is need for the end points to exchange
the link properties that they should advertise within the client the link properties that they should advertise within the client
network, and in the case of support for more than one client network, network, and in the case of support for more than one client network,
it will be necessary to indicate which client or clients can use the it will be necessary to indicate which client network or networks can
link. This capability it provided in [RFC6107]. use the link. This capability it provided in [RFC6107].
Appendix B. Additional Features Appendix B. Additional Features
This Appendix describes additional features that may be desirable and This Appendix describes additional features that may be desirable and
that can be achieved within this architecture. that can be achieved within this architecture.
B.1. Macro Shared Risk Link Groups B.1. Macro Shared Risk Link Groups
Network links often share fate with one or more other links. That Network links often share fate with one or more other links. That
is, a scenario that may cause a link to fail could cause one or more is, a scenario that may cause a link to fail could cause one or more
other links to fail. This may occur, for example, if the links are other links to fail. This may occur, for example, if the links are
supported by the same fiber bundle, or if some links are routed down supported by the same fiber bundle, or if some links are routed down
the same duct or in a common piece of infrastructure such as a the same duct or in a common piece of infrastructure such as a
bridge. A common way to identify the links that may share fate is to bridge. A common way to identify the links that may share fate is to
label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202]. label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202].
TE links created from LSPs in lower layers may also share fate, and TE links created from LSPs in lower layers may also share fate, and
it can be hard for a client network to know about this problem it can be hard for a client network to know about this problem
because it does not know the topology of the server network or the because it does not know the topology of the server network or the
path of the server layer LSPs that are used to create the links in path of the server network LSPs that are used to create the links in
the client network. the client network.
For example, looking at the example used in Section 4.2.3 and For example, looking at the example used in Section 4.2.3 and
considering the two abstract links S1-S3 and S1-S9 there is no way considering the two abstract links S1-S3 and S1-S9 there is no way
for the client layer to know whether the links C2-C0 and C2-C3 share for the client network to know whether the links C2-C0 and C2-C3
fate. Clearly, if the client layer uses these links to provide a share fate. Clearly, if the client layer uses these links to provide
link-diverse end-to-end protection scheme, it needs to know that the a link-diverse end-to-end protection scheme, it needs to know that
links actually share a piece of network infrastructure (the server the links actually share a piece of network infrastructure (the
layer link S1-S2). server network link S1-S2).
Per [RFC4202], an SRLG represents a shared physical network resource Per [RFC4202], an SRLG represents a shared physical network resource
upon which the normal functioning of a link depends. Multiple SRLGs upon which the normal functioning of a link depends. Multiple SRLGs
can be identified and advertised for every TE link in a network. can be identified and advertised for every TE link in a network.
However, this can produce a scalability problem in a mutli-layer However, this can produce a scalability problem in a mutli-layer
network that equates to advertising in the client layer the server network that equates to advertising in the client network the server
layer route of each TE link. network route of each TE link.
Macro SRLGs (MSRLGs) address this scaling problem and are a form of Macro SRLGs (MSRLGs) address this scaling problem and are a form of
abstraction performed at the same time that the abstract links are abstraction performed at the same time that the abstract links are
derived. In this way, links that actually share resources in the derived. In this way, links that actually share resources in the
server layer are advertised as having the same MSRLG, rather than server network are advertised as having the same MSRLG, rather than
advertising each SRLG for each resource on each path in the server advertising each SRLG for each resource on each path in the server
layer. This saving is possible because the abstract links are network. This saving is possible because the abstract links are
formulated on behalf of the server layer by a central management formulated on behalf of the server network by a central management
agency that is aware of all of the link abstractions being offered. agency that is aware of all of the link abstractions being offered.
It may be noted that a less optimal alternative path for the abstract It may be noted that a less optimal alternative path for the abstract
link S1-S9 exists in the server layer (S1-S4-S7-S8-S9). It would be link S1-S9 exists in the server network (S1-S4-S7-S8-S9). It would
possible for the client layer request for connectivity C2-C0 to ask be possible for the client network request for connectivity C2-C0 to
that the path be maximally disjoint from the path C2-C3. While ask that the path be maximally disjoint from the path C2-C3. While
nothing can be done about the shared link C2-S1, the abstraction nothing can be done about the shared link C2-S1, the abstraction
layer could request to use the link S1-S9 in a way that is diverse layer could request to use the link S1-S9 in a way that is diverse
from use of the link S1-S3, and this request could be honored if the from use of the link S1-S3, and this request could be honored if the
server layer policy allows. server network policy allows.
Note that SRLGs and MSRLGs may be very hard to describe in the case Note that SRLGs and MSRLGs may be very hard to describe in the case
of multiple server layer networks because the abstraction points will of multiple server networks because the abstraction points will not
not know whether the resources in the various server layers share know whether the resources in the various server layers share
physical locations. physical locations.
B.2. Mutual Exclusivity B.2. Mutual Exclusivity
As noted in the discussion of Figure 13, it is possible that some As noted in the discussion of Figure 13, it is possible that some
abstraction layer links can not be used at the same time. This abstraction layer links can not be used at the same time. This
arises when the potentiality of the links is indicated by the server arises when the potentiality of the links is indicated by the server
layer, but the use the links would actually compete for server layer network, but the use the links would actually compete for server
resources. In Figure 13 this arose when both link S1-S3 and link network resources. In Figure 13 this arose when both link S1-S3 and
S7-S9 were used to carry LSPs: in that case the link S1-S9 could no link S7-S9 were used to carry LSPs: in that case the link S1-S9 could
longer be used. no longer be used.
Such a situation need not be an issue when client-edge to client-edge Such a situation need not be an issue when client-edge to client-edge
LSPs are set up one by one because the use of one abstraction layer LSPs are set up one by one because the use of one abstraction layer
link and the corresponding use of server layer resources will cause link and the corresponding use of server network resources will cause
the server layer to withdraw the availability of the other the server network to withdraw the availability of the other
abstraction layer links, and these will become unavailable for abstraction layer links, and these will become unavailable for
further abstraction layer path computations. further abstraction layer path computations.
Furthermore, in deployments where abstraction layer links are only Furthermore, in deployments where abstraction layer links are only
presented as available after server layer LSPs have been established presented as available after server network LSPs have been
to support them, the problem is unlikely exist. established to support them, the problem is unlikely exist.
However, when the server layer is constrained, but chooses to However, when the server network is constrained, but chooses to
advertise the potential of multiple abstraction layer links even advertise the potential of multiple abstraction layer links even
though they compete for resources, and when multiple client-edge to though they compete for resources, and when multiple client-edge to
client-edge LSPs are computed simultaneously (perhaps to provide client-edge LSPs are computed simultaneously (perhaps to provide
protection services) there may be contention for server layer protection services) there may be contention for server network
resources. In the case that protected abstraction layer LSPs are resources. In the case that protected abstraction layer LSPs are
being established, this situation would be avoided through the use of being established, this situation would be avoided through the use of
SRLGs and/or MSRLGs since the two abstraction layer links that SRLGs and/or MSRLGs since the two abstraction layer links that
compete for server layer resources must also fate share across those compete for server network resources must also fate share across
resources. But in the case where the multiple client-edge to client- those resources. But in the case where the multiple client-edge to
edge LSPs do not care about fate sharing, it may be necessary to flag client-edge LSPs do not care about fate sharing, it may be necessary
the mutually exclusive links in the abstraction layer TED so that to flag the mutually exclusive links in the abstraction layer TED so
path computation can avoid accidentally attempting to utilize two of that path computation can avoid accidentally attempting to utilize
a set of such links at the same time. two of a set of such links at the same time.
 End of changes. 120 change blocks. 
296 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/