draft-ietf-teas-interconnected-te-info-exchange-04.txt   draft-ietf-teas-interconnected-te-info-exchange-05.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: September 20, 2016 Expires: October 26, 2016
N. Bitar N. Bitar
Nuage Networks Nokia
G. Swallow G. Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
X. Zhang X. Zhang
Huawei Huawei
March 20, 2016 April 26, 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-04.txt draft-ietf-teas-interconnected-te-info-exchange-05.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
an IGP area or an Autonomous System. an IGP area or an Autonomous System.
In order to determine the potential to establish a TE path through a In order to determine the potential to establish a TE path through a
series of connected networks, it is necessary to have available a series of connected networks, it is necessary to have available a
certain amount of TE information about each network. This need not certain amount of TE information about each network. This need not
be the full set of TE information available within each network, but be the full set of TE information available within each network, but
does need to express the potential of providing TE connectivity. This does need to express the potential of providing TE connectivity. This
subset of TE information is called TE reachability information. subset of TE information is called TE reachability information.
This document sets out the problem statement and architecture for the This document sets out the problem statement for the exchange of TE
exchange of TE information between interconnected TE networks in information between interconnected TE networks in support of end-to-
support of end-to-end TE path establishment. For reasons that are end TE path establishment and describes the best current practice
architecture to meet this problem statement. For reasons that are
explained in the document, this work is limited to simple TE explained in the document, this work is limited to simple TE
constraints and information that determine TE reachability. constraints and information that determine TE reachability.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 .......................................... 6 1.1.3. TE Reachability .......................................... 7
1.1.4. Domain ................................................... 7 1.1.4. Domain ................................................... 7
1.1.5. Aggregation .............................................. 7 1.1.5. Aggregation .............................................. 7
1.1.6. Abstraction .............................................. 7 1.1.6. Abstraction .............................................. 7
1.1.7. Abstract Link ............................................ 7 1.1.7. Abstract Link ............................................ 8
1.1.8. Abstract Node or Virtual Node ............................ 8 1.1.8. Abstract Node or Virtual Node ............................ 8
1.1.9. Abstraction Layer Network ................................ 8 1.1.9. Abstraction Layer Network ................................ 8
2. Overview of Use Cases ........................................ 8 2. Overview of Use Cases ........................................ 9
2.1. Peer Networks .............................................. 8 2.1. Peer Networks .............................................. 9
2.2. Client-Server Networks ..................................... 10 2.2. Client-Server Networks ..................................... 10
2.3. Dual-Homing ................................................ 12 2.3. Dual-Homing ................................................ 13
2.4. Requesting Connectivity .................................... 13 2.4. Requesting Connectivity .................................... 14
2.4.1. Discovering Server Network Information ................... 15 2.4.1. Discovering Server Network Information ................... 16
3. Problem Statement ............................................ 15 3. Problem Statement ............................................ 16
3.1. Policy and Filters ......................................... 15 3.1. Policy and Filters ......................................... 17
3.2. Confidentiality ............................................ 15 3.2. Confidentiality ............................................ 17
3.3. Information Overload ....................................... 17 3.3. Information Overload ....................................... 18
3.4. Issues of Information Churn ................................ 17 3.4. Issues of Information Churn ................................ 18
3.5. Issues of Aggregation ...................................... 18 3.5. Issues of Aggregation ...................................... 19
4. Architecture ................................................. 19 4. Architecture ................................................. 20
4.1. TE Reachability ............................................ 19 4.1. TE Reachability ............................................ 20
4.2. Abstraction not Aggregation ................................ 20 4.2. Abstraction not Aggregation ................................ 21
4.2.1. Abstract Links ........................................... 21 4.2.1. Abstract Links ........................................... 22
4.2.2. The Abstraction Layer Network ............................ 21 4.2.2. The Abstraction Layer Network ............................ 22
4.2.3. Abstraction in Client-Server Networks..................... 24 4.2.3. Abstraction in Client-Server Networks..................... 25
4.2.4. Abstraction in Peer Networks ............................. 29 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 ............... 32 4.4. Requirements for Advertising Links and Nodes ............... 33
4.5. Addressing Considerations .................................. 33 4.5. Addressing Considerations .................................. 33
5. Building on Existing Protocols ............................... 33 5. Building on Existing Protocols ............................... 34
5.1. BGP-LS ..................................................... 34 5.1. BGP-LS ..................................................... 34
5.2. IGPs ....................................................... 34 5.2. IGPs ....................................................... 35
5.3. RSVP-TE .................................................... 34 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 ................. 36 6. Applicability to Optical Domains and Networks ................. 37
7. Modeling the User-to-Network Interface ....................... 40 7. Modeling the User-to-Network Interface ....................... 41
8. Abstraction in L3VPN Multi-AS Environments ................... 42 8. Abstraction in L3VPN Multi-AS Environments ................... 43
9. Scoping Future Work .......................................... 43 9. Scoping Future Work .......................................... 44
9.1. Not Solving the Internet ................................... 43 9.1. Not Solving the Internet ................................... 44
9.2. Working With "Related" Domains ............................. 43 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
9.4. Sanity and Scaling ......................................... 44 9.4. Sanity and Scaling ......................................... 44
10. Manageability Considerations ................................ 44 10. Manageability Considerations ................................ 45
10.1. Managing the Abstraction Layer Network .................... 44 10.1. Managing the Abstraction Layer Network .................... 45
10.2. Managing Interactions of Client and Abstraction Layer Networks 10.2. Managing Interactions of Client and Abstraction Layer Networks
45 46
10.3. Managing Interactions of Abstraction Layer and Server Networks 10.3. Managing Interactions of Abstraction Layer and Server Networks
46 46
11. IANA Considerations ......................................... 47 11. IANA Considerations ......................................... 47
12. Security Considerations ..................................... 47 12. Security Considerations ..................................... 47
13. Acknowledgements ............................................ 47 13. Acknowledgements ............................................ 48
14. References .................................................. 48 14. References .................................................. 49
14.1. Informative References .................................... 48 14.1. Informative References .................................... 49
Authors' Addresses ............................................... 52 Authors' Addresses ............................................... 52
Contributors ..................................................... 52 Contributors ..................................................... 53
A. Existing Work ................................................ 54 A. Existing Work ................................................ 55
A.1. Per-Domain Path Computation ................................ 54 A.1. Per-Domain Path Computation ................................ 55
A.2. Crankback .................................................. 54 A.2. Crankback .................................................. 55
A.3. Path Computation Element ................................... 55 A.3. Path Computation Element ................................... 56
A.4. GMPLS UNI and Overlay Networks ............................. 57 A.4. GMPLS UNI and Overlay Networks ............................. 58
A.5. Layer One VPN .............................................. 57 A.5. Layer One VPN .............................................. 58
A.6. Policy and Link Advertisement .............................. 58 A.6. Policy and Link Advertisement .............................. 59
B. Additional Features .......................................... 59 B. Additional Features .......................................... 60
B.1. Macro Shared Risk Link Groups .............................. 59 B.1. Macro Shared Risk Link Groups .............................. 60
B.2. Mutual Exclusivity ......................................... 60 B.2. Mutual Exclusivity ......................................... 61
1. Introduction 1. Introduction
Traffic Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS Traffic Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS
[RFC3945] offer a way to establish paths through a network in a [RFC3945] offer a way to establish paths through a network in a
controlled way that reserves network resources on specified links. controlled way that reserves network resources on specified links.
TE paths are computed by examining the Traffic Engineering Database TE paths are computed by examining the Traffic Engineering Database
(TED) and selecting a sequence of links and nodes that are capable of (TED) and selecting a sequence of links and nodes that are capable of
meeting the requirements of the path to be established. The TED is meeting the requirements of the path to be established. The TED is
constructed from information distributed by the IGP running in the constructed from information distributed by the IGP running in the
skipping to change at page 5, line 40 skipping to change at page 5, line 40
connection points through which to route a path, it is necessary to connection points through which to route a path, it is necessary to
have available a certain amount of TE information about each domain. have available a certain amount of TE information about each domain.
This need not be the full set of TE information available within each This need not be the full set of TE information available within each
domain, but does need to express the potential of providing TE domain, but does need to express the potential of providing TE
connectivity. This subset of TE information is called TE connectivity. This subset of TE information is called TE
reachability information. The TE reachability information can be reachability information. The TE reachability information can be
exchanged between domains based on the information gathered from the exchanged between domains based on the information gathered from the
local routing protocol, filtered by configured policy, or statically local routing protocol, filtered by configured policy, or statically
configured. configured.
This document sets out the problem statement and architecture for the This document sets out the problem statement for the exchange of TE
exchange of TE information between interconnected TE domains in information between interconnected TE networks in support of end-to-
support of end-to-end TE path establishment. The scope of this end TE path establishment and describes the best current practice
architecture to meet this problem statement. The scope of this
document is limited to the simple TE constraints and information 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 existing relevant existing
work that is used to route TE paths across multiple domains. work that is used to route TE paths across multiple domains.
skipping to change at page 6, line 29 skipping to change at page 6, line 30
path) in order to provide a specific service such as bandwidth path) in order to provide a specific service such as bandwidth
guarantee, separation of traffic, or resilience between a well-known guarantee, separation of traffic, or resilience between a well-known
pair of end points. pair of end points.
1.1.2. TE Metrics and TE Attributes 1.1.2. TE Metrics and TE Attributes
TE metrics and TE attributes are terms applied to parameters of links TE metrics and TE attributes are terms applied to parameters of links
(and possibly nodes) in a network that is traversed by TE (and possibly nodes) in a network that is traversed by TE
connections. The TE metrics and TE attributes are used by path connections. The TE metrics and TE attributes are used by path
computation algorithms to select the TE paths that the TE connections computation algorithms to select the TE paths that the TE connections
traverse. Provisioning a TE connection through a network may result traverse. A TE metric is a quantifiable value (including measured
in dynamic changes to the TE metrics and TE attributes of the links characteristics) describing some property of a link or node that can
and nodes in the network. be used as part of TE routing or planning, while a TE attribute is a
wider term (i.e., including the concept of a TE metric) that refers
to any property or characteristic of a link or node that can be used
as part of TE routing or planning. Thus, the delay introduced by
transmission of a packet on a link is an example of a TE metric while
the geographic location of a router is an example of a more general
attribute.
Provisioning a TE connection through a network may result in dynamic
changes to the TE metrics and TE attributes of the links and nodes in
the network.
These terms are also sometimes used to describe the end-to-end These terms are also sometimes used to describe the end-to-end
characteristics of a TE connection and can be derived according to a characteristics of a TE connection and can be derived according to a
formula from the metrics and attributes of the links and nodes that formula from the TE metrics and TE attributes of the links and nodes
the TE connection traverses. Thus, for example, the end-to-end delay that the TE connection traverses. Thus, for example, the end-to-end
for a TE connection is usually considered to be the sum of the delay delay for a TE connection is usually considered to be the sum of the
on each link that the connection traverses. delay on each link that the connection traverses.
1.1.3. TE Reachability 1.1.3. TE Reachability
In an IP network, reachability is the ability to deliver a packet to In an IP network, reachability is the ability to deliver a packet to
a specific address or prefix. That is, the existence of an IP path a specific address or prefix. That is, the existence of an IP path
to that address or prefix. TE reachability is the ability to reach a to that address or prefix. TE reachability is the ability to reach a
specific address along a TE path. More specifically, it is the specific address along a TE path. More specifically, it is the
ability to establish a TE connection in an MPLS-TE or GMPLS sense. ability to establish a TE connection in an MPLS-TE or GMPLS sense.
Thus we talk about TE reachability as the potential of providing TE Thus we talk about TE reachability as the potential of providing TE
connectivity. connectivity.
skipping to change at page 8, line 9 skipping to change at page 8, line 19
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.8. 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 or virtual node is the representation as generally, an abstract node is the representation as a single node in
a single node in a TE topology of one or more nodes and the links a TE topology of some or all of the resources of one or more nodes
that connect them. An abstract node may be advertised outside the and the links that connect them. An abstract node may be advertised
domain as a TE node for use in path computation and signaling in outside the domain as a TE node for use in path computation and
other domains. signaling in other domains.
The term virtual node has typically been applied to the aggregation
of a domain (that is, a collection of nodes and links that operate
as a single administrative entity for TE purposes) into a single
entity that is treated as a node for the purposes of end-to-end
traffic engineering. Virtual nodes are often considered a way to
present islands of single vendor equipment in an optical network.
Sections 3.5 and 4.2.2.1 provide more information about the uses 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.9. 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 networks 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
skipping to change at page 9, line 25 skipping to change at page 9, line 45
| ----- | x2 | ----- | | ----- | x2 | ----- |
-------------- -------------- -------------- --------------
Figure 1 : Peer Networks 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
though Domain D, Domain A must be sensitive to the TE connectivity
available through each of Domains C and D, as well the TE
connectivity from each of interconnections x4 and x5 to Dst within
Domain Z. The problem may be further complicated when the source
domain does not know in which domain the destination node is located,
since the choice of a domain path clearly depends on the knowledge of
the destination domain: this issue is obviously mitigated in IP
networks by inter-domain routing [RFC4271].
Of course, many network interconnection scenarios are going to be a
combination of the situations expressed in these two examples. There
may be a mesh of domains, and the domains may have multiple points of
interconnection.
-------------- --------------
| Domain B | | Domain B |
| | | |
| | | |
/-------------- /--------------
/ /
/ /
/x1 /x1
--------------/ -------------- --------------/ --------------
skipping to change at page 10, line 5 skipping to change at page 10, line 38
\ / \ /
\ /x5 \ /x5
\--------------/ \--------------/
| Domain D | | Domain D |
| | | |
| | | |
-------------- --------------
Figure 2 : Peer Networks in a Mesh Figure 2 : Peer Networks in a Mesh
select interconnection x2 (through Domain C) or interconnection x3
though Domain D, Domain A must be sensitive to the TE connectivity
available through each of Domains C and D, as well the TE
connectivity from each of interconnections x4 and x5 to Dst within
Domain Z. The problem may be further complicated when the source
domain does not know in which domain the destination node is located,
since the choice of a domain path clearly depends on the knowledge of
the destination domain: this issue is obviously mitigated in IP
networks by inter-domain routing [RFC4271].
Of course, many network interconnection scenarios are going to be a
combination of the situations expressed in these two examples. There
may be a mesh of domains, and the domains may have multiple points of
interconnection.
2.2. Client-Server Networks 2.2. Client-Server Networks
Two major classes of use case relate to the client-server Two major classes of use case relate to the client-server
relationship between networks. These use cases have sometimes been relationship between networks. These use cases have sometimes been
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
layer network. The TE relationship between the domains (higher and
lower layer) in this case is reduced to determining what server layer
connectivity to establish, how to trigger it, how to route it in the
server layer, and what resources and capacity to assign within the
server layer. As the demands in the higher layer network vary, the
connectivity in the server layer may need to be modified. Section
2.4 explains in a little more detail how connectivity may be
requested.
-------------- -------------- -------------- --------------
| Domain A | | Domain Z | | Domain A | | Domain Z |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | Src | | | | Dst | | | | Src | | | | Dst | |
| ----- | | ----- | | ----- | | ----- |
| | | | | | | |
--------------\ /-------------- --------------\ /--------------
\x1 x2/ \x1 x2/
\ / \ /
\ / \ /
\---------------/ \---------------/
| Server Domain | | Server Domain |
| | | |
| | | |
--------------- ---------------
Figure 3 : Client-Server Networks Figure 3 : Client-Server Networks
and by treating the server layer connectivity as links in the higher
layer network. The TE relationship between the domains (higher and
lower layer) in this case is reduced to determining what server layer
connectivity to establish, how to trigger it, how to route it in the
server layer, and what resources and capacity to assign within the
server layer. As the demands in the higher layer network vary, the
connectivity in the server layer may need to be modified. Section
2.4 explains in a little more detail how connectivity may be
requested.
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 layer where non-overlapping IP
addresses between the client and the server networks cannot be 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.
Note that in the use cases shown in Figures 3 and 4 the client layer
domains may (and, in fact, probably do) operate as a single connected
network.
-------------- -------------- -------------- --------------
| Domain A | | Domain Z | | Domain A | | Domain Z |
| (VPN site) | | (VPN site) | | (VPN site) | | (VPN site) |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | Src | | | | Dst | | | | Src | | | | Dst | |
| ----- | | ----- | | ----- | | ----- |
| | | | | | | |
--------------\ /-------------- --------------\ /--------------
\x1 x2/ \x1 x2/
skipping to change at page 12, line 5 skipping to change at page 12, line 34
/x3 x4\ /x3 x4\
--------------/ \-------------- --------------/ \--------------
| Domain B | | Domain C | | Domain B | | Domain C |
| (VPN site) | | (VPN site) | | (VPN site) | | (VPN site) |
| | | | | | | |
| | | | | | | |
-------------- -------------- -------------- --------------
Figure 4 : A Virtual Private Network Figure 4 : A Virtual Private Network
Note that in the use cases shown in Figures 3 and 4 the client layer
domains may (and, in fact, probably do) operate as a single connected
network.
Both use cases in this section become "more interesting" when Both use cases in this section become "more interesting" when
combined with the use case in Section 2.1. That is, when the combined with the use case in Section 2.1. That is, when the
connectivity between higher layer domains or VPN sites is provided connectivity between higher layer domains or VPN sites is provided
by a sequence or mesh of lower layer domains. Figure 5 shows how by a sequence or mesh of lower layer domains. Figure 5 shows how
this might look in the case of a VPN. this might look in the case of a VPN.
------------ ------------ ------------ ------------
| Domain A | | Domain Z | | Domain A | | Domain Z |
| (VPN site) | | (VPN site) | | (VPN site) | | (VPN site) |
| ----- | | ----- | | ----- | | ----- |
skipping to change at page 13, line 36 skipping to change at page 14, line 36
------------/ \------------ ------------/ \------------
| Domain C | | Domain D | | Domain C | | Domain D |
| (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
This relationship between domains can be entirely under the control The relationship between domains can be entirely under the control of
of management processes, dynamically triggered by the client network, management processes, dynamically triggered by the client network, or
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 layer connectivity. In the dynamic case, the client may make a
request to the server network exerting a range of controls over the request to the server network exerting a range of controls over the
paths selected in the server network. This range extends from no paths selected in the server network. This range extends from no
control (i.e., a simple request for connectivity), through a set of control (i.e., a simple request for connectivity), through a set of
constraints (such as latency, path protection, etc.), up to and constraints (such as latency, path protection, etc.), up to and
including full control of the path and resources used in the server including full control of the path and resources used in the server
network (i.e., the use of explicit paths with label subobjects). 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
skipping to change at page 25, line 43 skipping to change at page 26, line 37
/ /-- --\ /-- /-- -- / /-- --\ /-- /-- --
--/ -- --/ -- \--/ --/ --/ -- --/ -- \--/ --/
|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 layer topology will appear as shown in
Figure 11. As can be clearly seen, the network is partitioned and Figure 11. As can be clearly seen, the network is partitioned and
there is no way to set up an LSP from a node on the left hand side
(say C1) to a node on the right hand side (say C7).
-- -- -- --
|C3|---|C4| |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 Layer Topology Showing Partitioned Network
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).
For reference, Figure 12 shows the corresponding server layer For reference, Figure 12 shows the corresponding server layer
topology. topology.
-- -- -- -- -- --
|S1|---|S2|----|S3| |S1|---|S2|----|S3|
--\ --\ --\ --\ --\ --\
\-- \-- \-- \-- \-- \--
|S4| |S5|----|S6| |S4| |S5|----|S6|
/-- --\ /-- /-- --\ /--
--/ -- \--/ --/ -- \--/
skipping to change at page 26, line 49 skipping to change at page 27, line 37
point in offering an abstract link S2-S8 since this could not be of point in offering an abstract link S2-S8 since this could not be of
any use in this example). 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 layer, 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 using distinct resources (for example, separate lambdas) where the
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-
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
and cannot be used.
-- --
|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
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-
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
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 layer 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
skipping to change at page 28, line 14 skipping to change at page 28, line 48
together, or simply by routing the client layer LSP through the together, or simply by routing the client layer LSP through the
server network. If server layer LSPs are needed to they can be server network. If server layer 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 layer LSPs that are needed have been established,
S1 can continue to signal the client-edge to client-edge LSP S1 can continue to signal the client-edge to client-edge LSP
across the abstraction layer either using the server layer LSPs as across the abstraction layer either using the server layer LSPs as
tunnels or as stitching segments, or simply routing through the tunnels or as stitching segments, or simply routing through the
server layer network. server layer network.
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
the new TE links C2-C3 and C2-C0. The resulting client layer
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 Layer Network with Additional Links
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
the new TE links C2-C3 and C2-C0. The resulting client layer
topology is shown in Figure 14.
7. Now the client layer can compute an end-to-end path from C1 to C7. 7. Now the client layer 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 layer may vary
considerably according to the policies and commercial relationships considerably according to the policies and commercial relationships
skipping to change at page 29, line 37 skipping to change at page 30, line 21
to-Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1. to-Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1.
The objective is to be able to support an end-to-end connection A1- The objective is to be able to support an end-to-end connection A1-
to-D2. This connection is for TE connectivity. to-D2. This connection is for TE connectivity.
As shown in the figure, abstract links that span the transit networks As shown in the figure, abstract links that span the transit networks
are used to achieve the required connectivity. These links form the are used to achieve the required connectivity. These links form the
key building blocks of the end-to-end connectivity. An end-to-end key building blocks of the end-to-end connectivity. An end-to-end
LSP uses these links as part of its path. If the stitching LSP uses these links as part of its path. If the stitching
capabilities of the networks are homogeneous then the end-to-end LSP capabilities of the networks are homogeneous then the end-to-end LSP
may simply traverse the path defined by the abstract links across the
various peer networks or may utilize stitching of LSP segments that
each traverse a network along the path of an abstract link. If the
network switching technologies support or necessitate the use of LSP
hierarchies, the end-to-end LSP may be tunneled across each network
using hierarchical LSPs that each each traverse a network along the
path of an abstract link.
: : : : : :
Network A : Network B : Network C : Network D Network A : Network B : Network C : Network D
: : : : : :
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2| |A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2|
-- -- | | -- | | | | -- | | -- -- -- -- | | -- | | | | -- | | -- --
| |========| | | |========| | | |========| | | |========| |
-- -- -- -- -- -- -- --
Key Key
--- Direct connection between two nodes --- Direct connection between two nodes
=== Abstract link across transit network === Abstract link across transit network
Figure 15 : Architecture for Peering Figure 15 : Architecture for Peering
may simply traverse the path defined by the abstract links across the
various peer networks or may utilize stitching of LSP segments that
each traverse a network along the path of an abstract link. If the
network switching technologies support or necessitate the use of LSP
hierarchies, the end-to-end LSP may be tunneled across each network
using hierarchical LSPs that each each traverse a network along the
path of an abstract link.
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
: : : :
-- -- -- : -- -- -- : -- -- -- -- -- : -- -- -- : -- --
skipping to change at page 34, line 36 skipping to change at page 35, line 17
would also serve well to advertise abstract links from a server would also serve well to advertise abstract links from a server
network into the abstraction layer network, or to advertise potential network into the abstraction layer network, or to advertise potential
connectivity from the abstraction layer network to the client connectivity from the abstraction layer network to the client
network. network.
5.2. IGPs 5.2. IGPs
Both OSPF and IS-IS have been extended through a number of RFCs to Both OSPF and IS-IS have been extended through a number of RFCs to
advertise TE information. Additionally, both protocols are capable advertise TE information. Additionally, both protocols are capable
of running in a multi-instance mode either as ships that pass in the of running in a multi-instance mode either as ships that pass in the
night (i.e., completely separate instances using different address) night (i.e., completely separate instances using different address
or as dual instances on the same address space. This means that spaces) or as dual instances on the same address space. This means
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 layer network, again without
needing any protocol extensions. needing any protocol extensions.
skipping to change at page 36, line 46 skipping to change at page 37, line 28
Sections 6, 7, and 8 discuss the applicability of this architecture Sections 6, 7, and 8 discuss the applicability of this architecture
to different network types and problem spaces, while Section 9 gives to different network types and problem spaces, while Section 9 gives
some advice about scoping future work. Section 9 on manageability some advice about scoping future work. Section 9 on manageability
considerations is particularly relevant in the context of this considerations is particularly relevant in the context of this
section because it contains a discussion of the policies and section because it contains a discussion of the policies and
mechanisms for indicating connectivity and link availability between mechanisms for indicating connectivity and link availability between
network layers in this architecture. network layers in this architecture.
6. Applicability to Optical Domains and Networks 6. Applicability to Optical Domains and Networks
Many optical networks are arranged a set of small domains. Each Many optical networks are arranged as a set of small domains. Each
domain is a cluster of nodes, usually from the same equipment vendor domain is a cluster of nodes, usually from the same equipment vendor
and with the same properties. The domain may be constructed as a and with the same properties. The domain may be constructed as a
mesh or a ring, or maybe as an interconnected set of rings. mesh or a ring, or maybe as an interconnected set of rings.
The network operator seeks to provide end-to-end connectivity across The network operator seeks to provide end-to-end connectivity across
a network constructed from multiple domains, and so (of course) the a network constructed from multiple domains, and so (of course) the
domains are interconnected. In a network under management control domains are interconnected. In a network under management control
such as through an Operations Support System (OSS), each domain is such as through an Operations Support System (OSS), each domain is
under the operational control of a Network Management System (NMS). under the operational control of a Network Management System (NMS).
skipping to change at page 37, line 37 skipping to change at page 38, line 21
| \ / | | \ / |
| \ / | | \ / |
| F---E | | F---E |
| | | |
----------------- -----------------
Figure 19 : A Simple Optical Domain Figure 19 : A Simple Optical Domain
Now consider that the operator's network is built from a mesh of such Now consider that the operator's network is built from a mesh of such
domains, D1 through D7, as shown in Figure 20. It is possible that domains, D1 through D7, as shown in Figure 20. It is possible that
these domains share a single, common instance of OSPF in which case
there is nothing further to say because that OSPF instance will
distribute sufficient information to build a single TED spanning the
whole network, and an end-to-end path can be computed. A more likely
scenario is that each domain is running its own OSPF instance. In
this case, each is able to handle the peculiarities (or rather,
advanced functions) of each vendor's equipment capabilities.
------ ------ ------ ------ ------ ------ ------ ------
| | | | | | | | | | | | | | | |
| D1 |---| D2 |---| D3 |---| D4 | | D1 |---| D2 |---| D3 |---| D4 |
| | | | | | | | | | | | | | | |
------\ ------\ ------\ ------ ------\ ------\ ------\ ------
\ | \ | \ | \ | \ | \ |
\------ \------ \------ \------ \------ \------
| | | | | | | | | | | |
| D5 |---| D6 |---| D7 | | D5 |---| D6 |---| D7 |
| | | | | | | | | | | |
------ ------ ------ ------ ------ ------
Figure 20 : A Simple Optical Domain Figure 20 : A Simple Optical Domain
these domains share a single, common instance of OSPF in which case
there is nothing further to say because that OSPF instance will
distribute sufficient information to build a single TED spanning the
whole network, and an end-to-end path can be computed. A more likely
scenario is that each domain is running its own OSPF instance. In
this case, each is able to handle the peculiarities (or rather,
advanced functions) of each vendor's equipment capabilities.
The question now is how to combine the multiple sets of information The question now is how to combine the multiple sets of information
distributed by the different OSPF instances. Three possible models distributed by the different OSPF instances. Three possible models
suggest themselves based on pre-existing routing practices. suggest themselves based on pre-existing routing practices.
o In the first model (the Area-Based model) each domain is treated as o In the first model (the Area-Based model) each domain is treated as
a separate OSPF area. The end-to-end path will be specified to a separate OSPF area. The end-to-end path will be specified to
traverse multiple areas, and each area will be left to determine traverse multiple areas, and each area will be left to determine
the path across the nodes in the area. The feasibility of an end- the path across the nodes in the area. The feasibility of an end-
to-end path (and, thus, the selection of the sequence of areas and to-end path (and, thus, the selection of the sequence of areas and
their interconnections) can be derived using hierarchical PCE. their interconnections) can be derived using hierarchical PCE.
skipping to change at page 41, line 22 skipping to change at page 42, line 5
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 nodes. That is, the
Ethernet service network is equivalent to the abstraction layer 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
the UNI Network-side (UNI-N) nodes.
Client Client Client Client
Network +----------+ +-----------+ Network Network +----------+ +-----------+ Network
-------------+ | | | | +------------- -------------+ | | | | +-------------
+----+ | | +-----+ | | +-----+ | | +----+ +----+ | | +-----+ | | +-----+ | | +----+
------+ | | | | | | | | | | | | +------ ------+ | | | | | | | | | | | | +------
------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------ ------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------
| | | +--+--| +-+-+ | | +--+-----+-+ | | | | +--+--| +-+-+ | | +--+-----+-+ |
+----+ | | | +--+--+ | | | +--+--+ | | +----+ +----+ | | | +--+--+ | | | +--+--+ | | +----+
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 42, line 5 skipping to change at page 42, line 37
-------------+ Server Network(s) +------------- -------------+ Server Network(s) +-------------
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 Edge Node
CN - Server Node CN - Server Node
Figure 22 : Ethernet UNI Reference Model Figure 22 : Ethernet UNI Reference Model
role of UNI Client-side (UNI-C) and the server edge nodes acting as
the UNI Network-side (UNI-N) nodes.
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 edge
node (such as that shown at the bottom left-hand corner of Figure 22) node (such as that shown at the bottom left-hand corner of Figure 22)
can make determinations about how they connect across the UNI. This can make determinations about how they connect across the UNI. This
can be particularly important when reachability across the server can be particularly important when reachability across the server
network is limited or when two diverse paths are desired (for network is limited or when two diverse paths are desired (for
example, to provide protection). However, in the model described in example, to provide protection). However, in the model described in
this network, the edge node (the UNI-C) is part of the abstraction this network, the edge node (the UNI-C) is part of the abstraction
layer network and can see sufficient topology information to make layer network and can see sufficient topology information to make
these decisions. If the approach introduced in this document is used these decisions. If the approach introduced in this document is used
to model the UNI as described in this section, there is no need to to model the UNI as described in this section, there is no need to
skipping to change at page 42, line 45 skipping to change at page 43, line 29
also includes the PEs (maybe ASBRs) at the edges of the multiple also includes the PEs (maybe ASBRs) at the edges of the multiple
server networks, and the PE-PE (maybe inter-AS) links. This gives server networks, and the PE-PE (maybe inter-AS) links. This gives
rise to the architecture shown in Figure 23. rise to the architecture shown in Figure 23.
The policy for adding abstract links to the abstraction layer network The policy for adding abstract links to the abstraction layer network
will be driven substantially by the needs of the VPN. Thus, when a will be driven substantially by the needs of the VPN. Thus, when a
new VPN site is added and the existing abstraction layer network new VPN site is added and the existing abstraction layer network
cannot support the required connectivity, a new abstract link will be cannot support the required connectivity, a new abstract link will be
created out of the underlying network. created out of the underlying network.
It is important to note that each VPN instance can have a separate
abstraction layer network. This means that the server network
resources can be partitioned and that traffic can be kept separate.
This can be achieved even when VPN sites from different VPNs connect
at the same PE. Alternatively, multiple VPNs can share the same
abstraction layer network if that is operationally preferable.
Lastly, just as for the UNI discussed in Section 7, the issue of
dual-homing of VPN sites is a function of the abstraction layer
network and so is just a normal routing problem in that network.
........... ............. ........... .............
VPN Site : : VPN Site VPN Site : : VPN Site
-- -- : : -- -- -- -- : : -- --
|C1|-|CE| : : |CE|-|C2| |C1|-|CE| : : |CE|-|C2|
-- | | : : | | -- -- | | : : | | --
| | : : | | | | : : | |
| | : : | | | | : : | |
| | : : | | | | : : | |
| | : -- -- -- -- : | | | | : -- -- -- -- : | |
| |----|PE|=========|PE|---|PE|=====|PE|----| | | |----|PE|=========|PE|---|PE|=====|PE|----| |
skipping to change at page 43, line 28 skipping to change at page 43, line 50
........... | | | | | | | | ............ ........... | | | | | | | | ............
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | - - | | | | - | | | | - - | | | | - | |
| |-|P|-|P|-| | | |-|P|-| | | |-|P|-|P|-| | | |-|P|-| |
-- - - -- -- - -- -- - - -- -- - --
Figure 23 : The Abstraction Layer Network for a Multi-AS VPN Figure 23 : The Abstraction Layer Network for a Multi-AS VPN
It is important to note that each VPN instance can have a separate
abstraction layer network. This means that the server network
resources can be partitioned and that traffic can be kept separate.
This can be achieved even when VPN sites from different VPNs connect
at the same PE. Alternatively, multiple VPNs can share the same
abstraction layer network if that is operationally preferable.
Lastly, just as for the UNI discussed in Section 7, the issue of
dual-homing of VPN sites is a function of the abstraction layer
network and so is just a normal routing problem in that network.
9. Scoping Future Work 9. Scoping Future Work
The section is provided to help guide the work on this problem and to The section is provided to help guide the work on this problem and to
ensure that oceans are not knowingly boiled. ensure that oceans are not knowingly boiled.
9.1. Not Solving the Internet 9.1. Not Solving the Internet
The scope of the use cases and problem statement in this document is The scope of the use cases and problem statement in this document is
limited to "some small set of interconnected domains." In limited to "some small set of interconnected domains." In
particular, it is not the objective of this work to turn the whole particular, it is not the objective of this work to turn the whole
skipping to change at page 45, line 15 skipping to change at page 45, line 45
the links that constitute the potential of a link. the links that constitute the potential of a link.
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 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 layer 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.
skipping to change at page 47, line 52 skipping to change at page 48, line 33
It is worth noting that the control plane of the abstraction layer It is worth noting that the control plane of the abstraction layer
network is likely to be out of band. That is, control plane messages network is likely to be out of band. That is, control plane messages
will be exchanged over network links that are not the links to which will be exchanged over network links that are not the links to which
they apply. This models the facilities of GMPLS (but not of MPLS-TE) they apply. This models the facilities of GMPLS (but not of MPLS-TE)
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. this work and to Gert Grammel for discussions on the extent of
aggregation in abstract nodes and links.
Thanks to Gert Grammel for discussions on the extent of 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, and Hannes Gredler for review and input. Somasundaram, Hannes Gredler, and Stewart Bryant 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 52, line 16 skipping to change at page 52, line 51
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
John Drake John Drake
Juniper Networks Juniper Networks
EMail: jdrake@juniper.net EMail: jdrake@juniper.net
Nabil Bitar Nabil Bitar
Nuage Networks Nokia
EMail: nbitar40@gmail.com EMail: nbitar40@gmail.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
EMail: swallow@cisco.com EMail: swallow@cisco.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
 End of changes. 50 change blocks. 
156 lines changed or deleted 172 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/