draft-ietf-teas-interconnected-te-info-exchange-01.txt   draft-ietf-teas-interconnected-te-info-exchange-02.txt 
Network Working Group A. Farrel (Ed.) Network Working Group A. Farrel (Ed.)
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: August 7, 2015 Expires: September 7, 2015
N. Bitar N. Bitar
Verizon Networks Verizon Networks
G. Swallow G. Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
X. Zhang X. Zhang
Huawei Huawei
February 7, 2015 March 7, 2015
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-01.txt draft-ietf-teas-interconnected-te-info-exchange-02.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-tfo-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. The availability of TE used in the process of selecting a TE path. TE information is
information is usually limited to within a network (such as an IGP usually only available within a network. We call such a zone of
area) often referred to as a domain. visibility of TE information a domain. An example of a domain may be
an IGP area or an Autonomous System.
In order to determine the potential to establish a TE path through a 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 and architecture for the
exchange of TE information between interconnected TE networks in exchange of TE information between interconnected TE networks in
skipping to change at page 3, line 43 skipping to change at page 3, line 43
4.1. Per-Domain Path Computation ................................ 21 4.1. Per-Domain Path Computation ................................ 21
4.2. Crankback .................................................. 22 4.2. Crankback .................................................. 22
4.3. Path Computation Element ................................... 23 4.3. Path Computation Element ................................... 23
4.4. GMPLS UNI and Overlay Networks ............................. 24 4.4. GMPLS UNI and Overlay Networks ............................. 24
4.5. Layer One VPN .............................................. 25 4.5. Layer One VPN .............................................. 25
4.6. VNT Manager and Link Advertisement ......................... 25 4.6. VNT Manager and Link Advertisement ......................... 25
4.7. What Else is Needed and Why? ............................... 26 4.7. What Else is Needed and Why? ............................... 26
5. Architectural Concepts ....................................... 27 5. Architectural Concepts ....................................... 27
5.1. Basic Components ........................................... 27 5.1. Basic Components ........................................... 27
5.1.1. Peer Interconnection ..................................... 27 5.1.1. Peer Interconnection ..................................... 27
5.1.2. Client-Server Interconnection ............................ 27 5.1.2. Client-Server Interconnection ............................ 28
5.2. TE Reachability ............................................ 28 5.2. TE Reachability ............................................ 29
5.3. Abstraction not Aggregation ................................ 29 5.3. Abstraction not Aggregation ................................ 29
5.3.1. Abstract Links ........................................... 30 5.3.1. Abstract Links ........................................... 30
5.3.2. The Abstraction Layer Network ............................ 30 5.3.2. The Abstraction Layer Network ............................ 30
5.3.3. Abstraction in Client-Server Networks..................... 33 5.3.3. Abstraction in Client-Server Networks..................... 33
5.3.4. Abstraction in Peer Networks ............................. 34 5.3.4. Abstraction in Peer Networks ............................. 39
5.4. Considerations for Dynamic Abstraction ..................... 40 5.4. Considerations for Dynamic Abstraction ..................... 41
5.5. Requirements for Advertising Links and Nodes ............... 40 5.5. Requirements for Advertising Links and Nodes ............... 42
5.6. Addressing Considerations .................................. 40 5.6. Addressing Considerations .................................. 42
6. Building on Existing Protocols ............................... 41 6. Building on Existing Protocols ............................... 43
6.1. BGP-LS ..................................................... 41 6.1. BGP-LS ..................................................... 43
6.2. IGPs ....................................................... 41 6.2. IGPs ....................................................... 43
6.3. RSVP-TE .................................................... 41 6.3. RSVP-TE .................................................... 43
7. Applicability to Optical Domains and Networks ................. 42 6.4. Notes on a Solution ........................................ 44
8. Modeling the User-to-Network Interface ....................... 43 7. Applicability to Optical Domains and Networks ................. 46
9. Abstraction in L3VPN Multi-AS Environments ................... 47 8. Modeling the User-to-Network Interface ....................... 50
10. Scoping Future Work ......................................... 49 9. Abstraction in L3VPN Multi-AS Environments ................... 51
10.1. Not Solving the Internet .................................. 49 10. Scoping Future Work ......................................... 53
10.2. Working With "Related" Domains ............................ 49 10.1. Not Solving the Internet .................................. 53
10.3. Not Finding Optimal Paths in All Situations ............... 49 10.2. Working With "Related" Domains ............................ 53
10.4. Not Breaking Existing Protocols ........................... 49 10.3. Not Finding Optimal Paths in All Situations ............... 53
10.5. Sanity and Scaling ........................................ 49 10.4. Not Breaking Existing Protocols ........................... 53
11. Manageability Considerations ................................ 50 10.5. Sanity and Scaling ........................................ 53
12. IANA Considerations ......................................... 50 11. Manageability Considerations ................................ 54
13. Security Considerations ..................................... 50 11.1. Managing the Abstraction Layer Network .................... 54
14. Acknowledgements ............................................ 50 11.2. Managing Interactions of Client and Abstraction Layer Networks
15. References .................................................. 51 55
15.1. Informative References .................................... 51 11.3. Managing Interactions of Abstraction Layer and Server Networks
Authors' Addresses ............................................... 55 56
Contributors ..................................................... 55 12. IANA Considerations ......................................... 56
13. Security Considerations ..................................... 57
14. Acknowledgements ............................................ 57
15. References .................................................. 58
15.1. Informative References .................................... 58
Authors' Addresses ............................................... 62
Contributors ..................................................... 63
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 6, line 34 skipping to change at page 6, line 34
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. Provisioning a TE connection through a network may result
in dynamic changes to the TE metrics and TE attributes of the links in dynamic changes to the TE metrics and TE attributes of the links
and nodes in the network. 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 formulaically characteristics of a TE connection and can be derived according to a
from the metrics and attributes of the links and nodes that the TE formula from the metrics and attributes of the links and nodes that
connection traverses. Thus, for example, the end-to-end delay for a the TE connection traverses. Thus, for example, the end-to-end delay
TE connection is usually considered to be the sum of the delay on for a TE connection is usually considered to be the sum of the delay
each link that the connection traverses. 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 30, line 36 skipping to change at page 30, line 42
an LSP can be abstracted from the TE information in the core network an LSP can be abstracted from the TE information in the core network
subject to policy, and the resultant potential LSP can be advertised. subject to policy, and the resultant potential LSP can be advertised.
Since the client nodes do not have visibility into the core network, Since the client nodes do not have visibility into the core network,
they must rely on abstraction information delivered to them by the they must rely on abstraction information delivered to them by the
core network. That is, the core network will report on the potential core network. That is, the core network will report on the potential
for connectivity. for connectivity.
5.3.2. The Abstraction Layer Network 5.3.2. The Abstraction Layer Network
Figure 9 introduces the Abstraction Layer Network. This construct Figure 9 introduces the abstraction layer network. This construct
separates the client layer resources (nodes C1, C2, C3, and C4, and separates the client layer resources (nodes C1, C2, C3, and C4, and
the corresponding links), and the server layer resources (nodes CN1, the corresponding links), and the server layer resources (nodes CN1,
CN2, CN3, and CN4 and the corresponding links). Additionally, the CN2, CN3, and CN4 and the corresponding links). Additionally, the
architecture introduces an intermediary layer called the Abstraction architecture introduces an intermediary layer called the abstraction
Layer. The Abstraction Layer contains the client layer edge nodes layer. The abstraction layer contains the client layer edge nodes
(C2 and C3), the server layer edge nodes (CN1 and CN4), the client- (C2 and C3), the server layer edge nodes (CN1 and CN4), the client-
server links (C2-CN1 and CN4-C3) and the abstract link CN1-CN4. server links (C2-CN1 and CN4-C3) and the abstract link CN1-CN4.
-- -- -- -- -- -- -- --
|C1|--|C2| |C3|--|C4| Client Network |C1|--|C2| |C3|--|C4| Client Network
-- | | | | -- -- | | | | --
| | | | . . . . . . . . . . . | | | | . . . . . . . . . . .
| | | | | | | |
| | | | | | | |
| | --- --- | | Abstraction | | --- --- | | Abstraction
skipping to change at page 31, line 37 skipping to change at page 31, line 37
The client layer network is able to operate as normal. Connectivity The client layer network is able to operate as normal. Connectivity
across the network can either be found or not found based on links across the network can either be found or not found based on links
that appear in the client layer TED. If connectivity cannot be that appear in the client layer TED. If connectivity cannot be
found, end-to-end LSPs cannot be set up. This failure may be found, end-to-end LSPs cannot be set up. This failure may be
reported but no dynamic action is taken by the client layer. reported but no dynamic action is taken by the client layer.
The server network layer also operates as normal. LSPs across the The server network layer also operates as normal. LSPs across the
server layer are set up in response to management commands or in server layer are set up in response to management commands or in
response to signaling requests. 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
Abstraction Layer (and in particular the client network edge nodes) abstraction layer (and in particular the client network edge nodes)
can see the TE connectivity in the layer. can see the TE connectivity in the layer.
When the client layer needs additional connectivity it can make a When the client layer 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 asks abstraction layer can see the potential path C2-CN1-CN4-C3, and asks
the server layer to realise the abstract link CN1-CN4. The server the server layer to realize the abstract link CN1-CN4. The server
layer provisions the LSP CN1-CN2-CN3-CN4 and makes the LSP available layer provisions the LSP CN1-CN2-CN3-CN4 and makes the LSP available
as a hierarchical LSP to turn the abstract link into a link that can as a hierarchical LSP to turn the abstract link into a link that can
be used in the client network. The Abstraction Layer can then set up be used in the client network. The abstraction layer can then set up
an LSP C2-CN1-CN4-C3 using stitching or tunneling, and make the LSP an LSP C2-CN1-CN4-C3 using stitching or tunneling, and make the LSP
available as a virtual link in the client network. available as a virtual link in the client network.
Sections 5.3.3 and 5.3.4 show how this model is used to satisfy the Sections 5.3.3 and 5.3.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.
5.3.2.1. Nodes in the Abstraction Layer Network 5.3.2.1. Nodes in the Abstraction Layer Network
Figure 9 shows a very simplified network diagram and the reader would Figure 9 shows a very simplified network diagram and the reader would
be forgiven for thinking that only Client Network edge nodes and be forgiven for thinking that only client network edge nodes and
Server Network edge nodes may appear in the Abstraction Layer server network edge nodes may appear in the abstraction layer
Network. But this is not the case: other nodes from the Server network. But this is not the case: other nodes from the server
Network may be present. This allows the Abstraction Layer network network may be present. This allows the abstraction layer network
to be more complex than a full mesh with access spokes. to be more complex than a full mesh with access spokes.
Thus, as shown in Figure 10, a transit node in the Server Network Thus, as shown in Figure 10, a transit node in the server network
(here the node is CN3) can be exposed as a node in the Abstraction (here the node is CN3) can be exposed as a node in the abstraction
Layer Network with Abstract Links connecting it to other nodes in layer network with abstract links connecting it to other nodes in
the Abstraction Layer Network. Of course, in the network shown in the abstraction layer network. Of course, in the network shown in
Figure 10, there is little if any value in exposing CN3, but if it Figure 10, there is little if any value in exposing CN3, but if it
had other Abstract Links to other nodes in the Abstraction Layer had other abstract links to other nodes in the abstraction layer
Network and/or direct connections to Client Network nodes, then the network and/or direct connections to client network nodes, then the
resulting network would be richer. resulting network would be richer.
-- -- -- -- Client -- -- -- -- Client
|C1|--|C2| |C3|--|C4| Network |C1|--|C2| |C3|--|C4| Network
-- | | | | -- -- | | | | --
| | | | . . . . . . . . . | | | | . . . . . . . . .
| | | | | | | |
| | | | | | | |
| | --- --- --- | | Abstraction | | --- --- --- | | Abstraction
| |--|CN1|========|CN3|========|CN5|--| | Layer Network | |--|CN1|========|CN3|========|CN5|--| | Layer Network
-- | | | | | | -- -- | | | | | | --
| | | | | | . . . . . . . . . . . . | | | | | | . . . . . . . . . . . .
| | | | | | | | | | | |
| | | | | | Server | | | | | | Server
| | --- | | --- | | Network | | --- | | --- | | Network
| |--|CN2|-| |-|CN4|--| | | |--|CN2|-| |-|CN4|--| |
--- --- --- --- --- --- --- --- --- ---
Figure 10 : Abstraction Layer Network with Additional Node Figure 10 : Abstraction Layer Network with Additional Node
It should be noted that the nodes included in the Abstraction Layer It should be noted that the nodes included in the abstraction layer
network in this way are not "Abstract Nodes" in the sense of a network in this way are not "abstract nodes" in the sense of a
virtual node described in Section 3.6. While it is the case that virtual node described in Section 3.6. While it is the case that
the policy point responsible for advertising Server Network resources the policy point responsible for advertising server network resources
into the Abstraction Layer Network could choose to advertise Abstract into the abstraction layer network could choose to advertise abstract
Nodes in place of real physical nodes, it is believed that doing so nodes in place of real physical nodes, it is believed that doing so
would introduce significant complexity in terms of: would introduce significant complexity in terms of:
- Coordination between all of the external interfaces of the Abstract - Coordination between all of the external interfaces of the abstract
Node node
- 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 the limitations in an abstract node
[I-D.ietf-ccamp-general-constraint-encode], [I-D.ietf-ccamp-general-constraint-encode],
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]. [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te].
5.3.3. Abstraction in Client-Server Networks 5.3.3. Abstraction in Client-Server Networks
Section 5.3.2 has already introduced the concept of the Abstraction Section 5.3.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 11 shows a multi-layer network comprising client nodes Figure 11 shows a multi-layer network comprising client 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 nodes (labeled as Sn for
n = 1 to 9). n = 1 to 9).
-- -- -- --
|C3|---|C4| |C3|---|C4|
/-- --\ /-- --\
skipping to change at page 34, line 46 skipping to change at page 34, line 46
Operating on the TED for the server layer, a management entity or a Operating on the TED for the server layer, 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 layer. To do this it obviously
needs to be aware of the connections between the layers (there is no needs to be aware of the connections between the layers (there is no
point in offering an abstract link S2-S8 since this could not be of 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 14. the resulting topology of the abstraction layer network in Figure 14.
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. paths are common, but it could also be done using resource sharing.
That would mean that when both S1-S3 and S7-S9 are realized as links That would mean that when both S1-S3 and S7-S9 are realized as links
carrying Abstraction Layer LSPs, the link S1-S9 can no longer be carrying abstraction layer LSPs, the link S1-S9 can no longer be
used. used.
-- --
|C3| |C3|
/-- /--
-- -- --/ -- -- --/
|C2|---|S1|==========|S3| |C2|---|S1|==========|S3|
-- --\\ --\\ -- --\\ --\\
\\ \\ \\ \\
\\ \\-- -- \\ \\-- --
\\ |S6|---|C6| \\ |S6|---|C6|
\\ -- -- \\ -- --
-- -- \\-- -- -- -- \\-- --
|C9|---|S7|=====|S9|---|C0| |C9|---|S7|=====|S9|---|C0|
-- -- -- -- -- -- -- --
Figure 14 : Abstraction Layer Network with Abstract Links Figure 14 : Abstraction Layer Network with Abstract Links
The separate IGP instance running in the Abstraction Layer Network The separate IGP instance running in the abstraction layer network
mean that this topology is visible at the edge nodes (C2, C3, C6, C9, means that this topology is visible at the edge nodes (C2, C3, C6,
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
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 Abstraction Layer Network may find that the traverse S1) the abstraction layer network may find that the
necessary underlying LSPs (S1-S2-S3 and S1-S2-S5-S9) have not necessary underlying LSPs (S1-S2-S3 and S1-S2-S5-S9) have not
been established since it is not a requirement that an abstract been established since it is not a requirement that an abstract
link be backed up by a real LSP. In this case, S1 computes the link be backed up by a real LSP. In this case, S1 computes the
paths of the underlying LSPs and signals them. paths of the underlying LSPs and signals them.
5. Once the serve layer LSPs have been established, S1 can continue 5. Once the serve layer LSPs have been established, S1 can continue
to signal the Abstraction Layer LSPs either using the server layer to signal the abstraction layer LSPs either using the server layer
LSPs as tunnels or as stitching segments. LSPs as tunnels or as stitching segments.
-- -- -- --
|C3|-|C4| |C3|-|C4|
/-- --\ /-- --\
/ \-- / \--
-- --/ |C5| -- --/ |C5|
|C1|---|C2| /-- |C1|---|C2| /--
-- /--\ --/ -- -- /--\ --/ --
/ \ |C6|---|C7| / \ |C6|---|C7|
/ \ /-- -- / \ /-- --
/ \--/ / \--/
--/ -- |C0| --/ -- |C0|
|C8|---|C9| -- |C8|---|C9| --
-- -- -- --
Figure 15 : Connected Client Layer Network with Additional Links Figure 15 : Connected Client Layer Network with Additional Links
6. Finally, once the Abstraction Layer LSPs have been set up, the 6. Finally, once the abstraction layer LSPs have been set up, the
client layer can be informed and can start to advertise 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 new TE links C2-C3 and C2-C0. The resulting client layer topology
is shown in Figure 15. is shown in Figure 15.
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.
5.3.3.1 Macro Shared Risk Link Groups 5.3.3.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 links to fail could cause one or more is, a scenario that may cause a links to fail could cause one or more
skipping to change at page 37, line 25 skipping to change at page 37, line 25
derived. In this way, only the links that actually links in the derived. In this way, only the links that actually links in the
server layer need to be advertised rather than every link that server layer need to be advertised rather than every link that
potentially shares resources. This saving is possible because the potentially shares resources. This saving is possible because the
abstract links are formulated on behalf of the server layer by a abstract links are formulated on behalf of the server layer by a
central management agency that is aware of all of the link central management agency that is aware of all of the link
abstractions being offered. 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 is would link S1-S9 exists in the server layer (S1-S4-S7-S8-S9). It is would
be possible for the client layer request for connectivity C2-C0 to be possible for the client layer request for connectivity C2-C0 to
request that the path be maximally disjoint from the path C2-C3. ask that the path be maximally disjoint from the path C2-C3. While
While nothing can be done about the shared link C2-S1, the nothing can be done about the shared link C2-S1, the abstraction
Abstraction Layer could request that the server layer instantiate the layer could request that the server layer instantiate the link S1-S9
link S1-S9 to be diverse from the link S1-S3, and this request could to be diverse from the link S1-S3, and this request could be honored
be honored if the server layer policy allows. if the server layer policy allows.
5.3.3.2 A Server with Multiple Clients 5.3.3.2 Mutual Exclusivity
As noted in the discussion of Figure 14, it is possible that some
abstraction layer links can not be realized and/or used at the same
time. This arises when the potentiality of the links is indicated by
the server layer, but the realization of the links by LSPs in the
server layer network would actually compete for server layer
resources. In Figure 14 this arose when both link S1-S3 and link
S7-S9 were realized as links carrying abstraction layer LSPs: in that
case the link S1-S9 could no longer be used.
Such a situation need not be an issue when abstraction layer LSPs are
set up one by one because the use of one abstraction layer link and
th corresponding use of server layer resources will cause the server
layer to withdraw the availability of the other abstraction layer
links, and these will become unavailable for further abstraction
layer path computations.
Furthermore, in deployments where abstraction layer links are only
presented as available after server layer LSPs have been established
to support them, the problem is unlikely exist.
However, when the server layer is constrained, but chooses to
advertise the potential of multiple abstraction layer links even
though they compete for resources, and when multiple abstraction
layer LSPs are computed simultaneously (perhaps to provide protection
services, there may be contention for server layer resources. In the
case that protected abstraction layer LSPs are being established,
this situation would be avoided through the use of SRLGs and/or
MSRLGs since the two abstraction layer links that compete for server
layer resources must also fate share across those resources. But in
the case where the multiple abstraction layer LSPs do not care about
fate sharing, it may be necessary to flag the mutually exclusive
links in the abstraction layer TED so that path computation can avoid
accidentally attempting to utilize two of a set of such links at the
same time.
5.3.3.3 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
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 are subject to the
same policies and the abstraction can be identical. In this case, a same policies and the abstraction can be identical. In this case, a
single Abstraction Layer Network can support more than one client. 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 layer
network. network.
5.3.3.3 A Client with Multiple Servers 5.3.3.4 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
abstract links from all server networks so that it can make suitable abstract links from all server networks so that it can make suitable
computations and create the correct TE links in the client network. computations and create the correct TE links in the client network.
That is, the relationship between client network and Abstraction That is, the relationship between client network and abstraction
Layer Network should be one-to-one. layer network should be one-to-one.
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 layer networks because the abstraction points will
not know whether the resources in the various server layers share not know whether the resources in the various server layers share
physical locations. physical locations.
5.3.4. Abstraction in Peer Networks 5.3.4. Abstraction in Peer Networks
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
skipping to change at page 39, line 6 skipping to change at page 39, line 39
Figure 16 : A Network Comprising Three Peer Networks Figure 16 : A Network Comprising Three Peer Networks
As discussed in Section 2, peered networks do not share visibility of As discussed in Section 2, peered networks do not share visibility of
their topologies or TE capabilities for scaling and confidentiality their topologies or TE capabilities for scaling and confidentiality
reasons. That means, in our example, that computing a path from A1 reasons. That means, in our example, that computing a path from A1
to C4 can be impossible without the aid of cooperating PCEs or some to C4 can be impossible without the aid of cooperating PCEs or some
form of crankback. form of crankback.
But it is possible to produce abstract links for the reachability But it is possible to produce abstract links for the reachability
across transit peer networks and instantiate an Abstraction Layer across transit peer networks and instantiate an abstraction layer
Network. That network can be enhanced with specific reachability network. That network can be enhanced with specific reachability
information if a destination network is partitioned as is the case information if a destination network is partitioned as is the case
with Network C in Figure 16. with Network C in Figure 16.
Suppose Network B decides to offer three abstract links B1-B3, B4-B3, Suppose Network B decides to offer three abstract links B1-B3, B4-B3,
and B4-B6. The Abstraction Layer Network could then be constructed and B4-B6. The abstraction layer network could then be constructed
to look like the network in Figure 17. to look like the network in Figure 17.
-- -- -- -- -- -- -- --
|A3|---|B1|====|B3|----|C1| |A3|---|B1|====|B3|----|C1|
-- -- //-- -- -- -- //-- --
// //
// //
// //
-- --// -- -- -- --// -- --
|A6|---|B4|=====|B6|---|C3| |A6|---|B4|=====|B6|---|C3|
skipping to change at page 40, line 6 skipping to change at page 40, line 45
-- -- : -- -- -- -- : -- --
Figure 18 : Tunnel Connections to Network C with TE Reachability Figure 18 : Tunnel Connections to Network C with TE Reachability
Peer networking cases can be made far more complex by dual homing Peer networking cases can be made far more complex by dual homing
between network peering nodes (for example, A3 might connect to B1 between network peering nodes (for example, A3 might connect to B1
and B4 in Figure 17) and by the networks themselves being arranged in and B4 in Figure 17) and by the networks themselves being arranged in
a mesh (for example, A6 might connect to B4 and C1 in Figure 17). a mesh (for example, A6 might connect to B4 and C1 in Figure 17).
These additional complexities can be handled gracefully by the These additional complexities can be handled gracefully by the
Abstraction Layer Network model. abstraction layer network model.
Further examples of abstraction in peer networks can be found in Further examples of abstraction in peer networks can be found in
Sections 7 and 9. Sections 7 and 9.
5.4. Considerations for Dynamic Abstraction 5.4. Considerations for Dynamic Abstraction
<TBD> It is possible to consider a highly dynamic system where the server
network adaptively suggests new abstract links into the abstraction
layer, and where the abstraction layer proactively deploys new LSPs
to provide new connections in the client network. Such fluidity is,
however, to be treated with caution because of the longer turn-up
times of connections in server networks, because the server networks
are likely to be sparsely connected and expensive physical resources
will only be deployed where there is believed to be a need for them,
and because of the complex commercial or administrative relationships
that may exist between client and server network operators.
Thus, proposals for fully automated multi-layer networks based on
this architecture may be regarded as forward-looking topics for
research both in terms of network stability and with regard to
eccomonic impact.
However, some elements of automation should not be discarded. A
server network may automatically apply policy to determine the best
set of abstract links to offer and the most suitable server network
LSPs to realize those links. And a client network may dynamically
observe congestion, lack of connectivity, or predicted changes in
traffic demand, and may use this information to request additional
links from the abstraction layer. And, once policies have been
configured, the whole system should be able to operate autonomous of
operator control (which is not to say that the operator will not have
the option of exerting control at every step in the process).
But it is important, in this discussion, to rule out most processes
of dynamic abstraction. As the available resources in the server
layer fluctuate because of newly provisioned server layer LSPs or due
to failed resources, it would significantly destabilize the system to
continually update the advertised abstract links. Thus, and
notwithstanding the discussion of mutually exclusive links in Section
5.3.3.2, a server network will mainly plan and advertise abstract
links that are stable in the event of establishment of other abstract
links.
As an example of this last point, consider two abstract links that
can be realized by a pair of server network LSPs that share a single
server network link at some point in their paths. Those abstract
links could be advertised each with the full capacity of the server
network link. But if this were done, then the establishment of one
abstract link would immediately preclude the other causing some small
degree of flap in the abstraction layer network topology. A server
network might instead choose to split the shared resources between
the two server network LSPs and so make the abstraction layer network
stable. This ability is, of course, highly dependent on the network
technology in the server network.
5.5. Requirements for Advertising Links and Nodes 5.5. 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, or use a new instance (or even a new protocol). Clearly,
the information exchanged is only that which has been created as the information exchanged is only that which has been created as
part of the abstraction function according to policy. part of the abstraction function according to policy.
It should be noted that in some cases Abstract Link enablement is on- It should be noted that in some cases abstract link enablement is on-
demand and all that is advertised in the topology for the Abstraction demand and all that is advertised in the topology for the abstraction
Layer Network is the potential for an Abstract Link to be set up. In layer network is the potential for an abstract link to be set up. In
this case we may ponder how the routing protocol will advertise this case we may ponder how the routing protocol will advertise
topology information over a link that is not yet established. In topology information over a link that is not yet established. In
other words, there must be a communication channel between the other words, there must be a communication channel between the
participating nodes so that the routing protocol messages can flow. participating nodes so that the routing protocol messages can flow.
The answer is that control plane connectivity exists in the Server The answer is that control plane connectivity exists in the server
Network and on the client-server edge links, and this can be used to network and on the client-server edge links, and this can be used to
carry the routing protocol messages for the Abstraction Layer carry the routing protocol messages for the abstraction layer
Network. The same consideration applies to the advertisement, in the network. The same consideration applies to the advertisement, in the
Client Network of the potential connectivity that the Abstraction client network of the potential connectivity that the abstraction
Layer Network can provide. layer network can provide.
5.6. Addressing Considerations 5.6. Addressing Considerations
[Editor Note: Need to work up some text on addressing to cover the case The network layers in this architecture should be able to operate
of each domain having a different (potentially overlapping) address with separate address spaces and these may overlap without any
space and the need for inter-domain addressing. In fact, this should be technical issues. That is, one address may mean one thing in the
quite simple but needs discussion. client network, yet the same address may have a different meaning in
Also needed is a discussion of the case where two client networks share the abstraction layer network or the server network. In other words
an abstraction network (section 5.3.3.2). How does addressing work here? there is complete address separation between networks.
Are there security issues?]
<TBD> However, this will require some care both because human operators may
well become confused, and because mapping between address spaces is
needed at the interfaces between the network layers. That mapping
requires configuration so that, for example, when the server network
announces an abstract link from A to B, the abstraction layer network
must recognize that A and B are server network addresses and must map
them to abstraction layer addresses (say P and Q) before including
the link in its own topology. And similarly, when the abstraction
layer network informs the client network that a new link is available
from S to T, it must map those addresses from its own address space
to that of the client network.
This form of address mapping will become particularly important in
cases where one abstraction layer network is constructed from
connectivity in multiple server layer networks, or where one
abstraction layer network provides connectivity for multiple client
networks.
6. Building on Existing Protocols 6. 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 as invention of new protocols or additional protocol extensions as
mentioned in Section 3.1. mentioned in Section 3.1.
6.1. BGP-LS 6.1. BGP-LS
BGP-LS is a set of extensions to BGP described in BGP-LS is a set of extensions to BGP described in
[I-D.ietf-idr-ls-distribution]. It's purpose is to announce topology [I-D.ietf-idr-ls-distribution]. It's purpose is to announce topology
information from one network to a "north-bound" consumer. information from one network to a "north-bound" consumer.
Application of BGP-LS to date has focused on a mechanism to build a Application of BGP-LS to date has focused on a mechanism to build a
TED for a PCE. However, BGP's mechanisms would also serve well to TED for a PCE. However, BGP's mechanisms would also serve well to
advertise Abstract Links from a Server Network into the Abstraction advertise abstract links from a server network into the abstraction
Layer Network, or to advertise potential connectivity from the layer network, or to advertise potential connectivity from the
Abstraction Layer Network to the Client Network. abstraction layer network to the client network.
6.2. IGPs 6.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 or as dual instances on the same address space. This means that
either IGP could probably be used as the routing protocol in the either IGP could probably be used as the routing protocol in the
Abstraction Layer Network. abstraction layer network.
6.3. RSVP-TE 6.3. RSVP-TE
RSVP-TE signaling can be used to set up traffic engineered LSPs to RSVP-TE signaling can be used to set up traffic engineered LSPs to
serve as hierarchical LSPs in the core network providing Abstract serve as hierarchical LSPs in the core network providing abstract
Links for the Abstraction Layer Network as described in [RFC4206]. links for the abstraction layer network as described in [RFC4206].
Similarly, the CE-to-CE LSP tunnel across the Abstraction Layer Similarly, the CE-to-CE LSP tunnel across the abstraction layer
Network can be established using RSVP-TE without any protocol network can be established using RSVP-TE without any protocol
extensions. 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.
6.4. Notes on a Solution
This section is not intended to be proscriptive or dictate the
protocol solutions that may be used to satisfy the architecture
described in this document, but it does show how the existing
protocols listed in the previous sections can be combined to provide
a solution with only minor modifications.
A server network can be operated using GMPLS routing and signaling
protocols. Using information gathered from the routing protocol, a
TED can be constructed containing resource availability information
and SRLG details. A policy-based process can then determine which
nodes and abstract links it wishes to advertise to form the abstract
layer network.
The server network can now use BGP-LS to advertise a topology of
links and nodes to form the abstraction layer network. This
information would most likely be advertised from a single point of
control that made all of the abstraction decisions, but the function
could be distributed to multiple server network edge nodes. The
information can be advertised by BGP-LS to multiple points within the
abstraction layer (such as all client network edge nodes) or to a
single controller.
Multiple server networks may advertise information that is used to
construct an abstraction layer network, and one server network may
advertise different information in different instances of BGP-LS to
form different abstraction layer networks. Furthermore, in the case
of one controller constructing multiple abstraction layer networks,
BGP-LS uses the route target mechanism defined in [RFC4364] to
distinguish the different applications (effectively abstraction layer
network VPNs) of the exported information.
Extensions may be made to BGP-LS to allow advertisement of MSLRGs,
mutually exclusive links, and to indicate whether the abstract link
has been pre-established or not.
The abstraction layer network may operate under central control or
use a distributed control plane. Since the links and nodes may be a
mix of physical and abstract links, and since the nodes may have
diverse cross-connect capabilities, it is most likely that a GMPLS
routing protocol will be beneficial for collecting and correlating
the routing information and for distributing updates. No special
additional features are needed beyond adding those extra parameters
just described for BGP-LS, but it should be noted that the control
plane of the abstraction layer network must run in an out of band
control network because the data-bearing links might not yet have
been established via connections in the server layer network.
The abstraction layer network is also able to determine potential
connectivity from client network edge to client network edge. It
will determine which client network links to create according to
policy and subject to requests from the client network, and will
take four steps:
- First it will compute a path for an abstraction layer LSP that
will realize the link for the client network.
- First it will request the server layer network to realize any
abstraction layer links that the LSP traverses and that are not
yet enabled.
- Then, once those links have been realized, it will signal the
abstraction layer LSP.
- Finally, the abstraction layer network will inform the client
network of the existence of the new client network link.
This last step can be achieved either by coordination of the end
points of the abstraction layer LSP (these points are client network
edge nodes) using mechanisms such as those described in [RFC6107],
or using BGP-LS from a central controller.
Once the client network edge nodes are aware of a new link, they will
automatically advertise it their routing protocol and it will become
available for use by traffic in the client network.
Sections 7, 8, and 9 discuss the applicability of this architecture
to different network types and problem spaces, while Section 10 gives
some advice about scoping future work. Section 11 on manageability
considerations is particularly relevant in the context of this
section because it contains a discussion of the policies and
mechanisms for indicating connectivity and link availability between
network layers in this architecture.
7. Applicability to Optical Domains and Networks 7. Applicability to Optical Domains and Networks
Many optical networks are arranged a set of small domains. Each Many optical networks are arranged 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
skipping to change at page 46, line 22 skipping to change at page 50, line 28
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 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 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
-------------+ | | | | +------------- -------------+ | | | | +-------------
+----+ | | +-----+ | | +-----+ | | +----+ +----+ | | +-----+ | | +-----+ | | +----+
------+ | | | | | | | | | | | | +------ ------+ | | | | | | | | | | | | +------
------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------ ------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------
skipping to change at page 47, line 40 skipping to change at page 51, line 40
CN - Server Node CN - Server 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 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
enhance the signaling protocols at the GMPLS UNI nor to add routing enhance the signaling protocols at the GMPLS UNI nor to add routing
exchanges at the UNI. exchanges at the UNI.
9. Abstraction in L3VPN Multi-AS Environments 9. 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
nodes, and the PE nodes are the server network edge nodes. The nodes, and the PE nodes are the server network edge nodes. The
Abstraction Layer Network is made up of the CE nodes, the CE-PE abstraction layer network is made up of the CE nodes, the CE-PE
links, the PE nodes, and PE-PE tunnels that are the Abstract Links. links, the PE nodes, and PE-PE tunnels that are the abstract links.
In the multi-AS or multi-operator case, the Abstraction Layer Network In the multi-AS or multi-operator case, the abstraction layer network
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.
........... ............. ........... .............
VPN Site : : VPN Site VPN Site : : VPN Site
-- -- : : -- -- -- -- : : -- --
|C1|-|CE| : : |CE|-|C2| |C1|-|CE| : : |CE|-|C2|
-- | | : : | | -- -- | | : : | | --
| | : : | | | | : : | |
skipping to change at page 48, line 37 skipping to change at page 52, line 37
........... | | | | | | | | ............ ........... | | | | | | | | ............
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | - - | | | | - | | | | - - | | | | - | |
| |-|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
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 It is important to note that each VPN instance can have a separate
Abstraction Layer Network. This means that the Server Network abstraction layer network. This means that the server network
resources can be partitioned and that traffic can be kept separate. resources can be partitioned and that traffic can be kept separate.
This can be achieved even when VPN sites from different VPNs connect This can be achieved even when VPN sites from different VPNs connect
at the same PE. Alternatively, multiple VPNs can share the same at the same PE. Alternatively, multiple VPNs can share the same
Abstraction Layer Network if that is operationally preferable. abstraction layer network if that is operationally preferable.
Lastly, just as for the UNI discussed in Section 8, the issue of Lastly, just as for the UNI discussed in Section 8, the issue of
dual-homing of VPN sites is a function of the Abstraction Layer dual-homing of VPN sites is a function of the abstraction layer
Network and so is just a normal routing problem in that network. network and so is just a normal routing problem in that network.
10. Scoping Future Work 10. 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.
10.1. Not Solving the Internet 10.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
skipping to change at page 50, line 12 skipping to change at page 54, line 12
intended to bite off a small problem for some relatively simple use intended to bite off a small problem for some relatively simple use
cases as described in Section 2. It is not intended that this work cases as described in Section 2. It is not intended that this work
will be immediately (or even soon) extended to cover many large will be immediately (or even soon) extended to cover many large
interconnected domains. Obviously the solution should as far as interconnected domains. Obviously the solution should as far as
possible be designed to be extensible and scalable, however, it is possible be designed to be extensible and scalable, however, it is
also reasonable to make trade-offs in favor of utility and also reasonable to make trade-offs in favor of utility and
simplicity. simplicity.
11. Manageability Considerations 11. Manageability Considerations
<TBD> Manageability should not be a significant additional burden. Each
layer in the network model can and should be managed independently.
That is, each client network will run its own management systems and
tools to manage the nodes and links in the client network: each
client network link that is realized by mans of an abstract link will
still be available for management in the client network as any other
link.
Similarly, each server network will run its own management systems
and tools to manage the nodes and links in that network just as
normal.
Three issues remain for consideration:
- How is the abstraction layer network managed?
- How is the interface between the client network and the abstraction
layer network managed?
- How is the interface between the abstraction layer network and the
server network managed?
11.1. Managing the Abstraction Layer Network
Management of the abstraction layer network differs from the client
and server networks because not all of the links that are visible in
the TED have been realized. That is, it is not possible to run OAM
on the links that constitute the potential of a link that could be
realized by an LSP in the server network, but that have not yet been
established.
Other than that, however, the management should be essentially the
same. Routing and signaling protocols can be run in the abstraction
layer (using out of band channels for links that have not yet been
established), and a centralized TED can be constructed and used to
examine the availability and status of the links and nodes in the
network.
Note that different deployment models will place the "ownership" of
th abstraction layer network differently. In some case the 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
client networks. In other cases, one or more server networks will
present the potential of links to an abstraction layer network run
by the operator of the client network. And it is feasible that a
business model could be built where a third-party operator manages
the abstraction layer network, constructing it from the connectivity
available in multiple server networks, and facilitating connectivity
for multiple client networks.
11.2. Managing Interactions of Client and Abstraction Layer Networks
The interaction between the client network and th abstraction layer
network is a management task. It might be automated (software
driven) or it might require manual intervention.
This is a two-way interaction:
- The client network can express the need for additional
connectivity. For example, the client layer may try and fail to
find a path across the client network and may request additional,
specific connectivity (this is similar to the situation with
Virtual Network Topology Manager (VNTM) [RFC5623]). Alternatively,
a more proactive client layer management system may monitor traffic
demands (current and predicted), network usage, and network "hot
spots" and may request changes in connectivity by both releasing
unused links and by requesting new links.
- The abstraction layer network can make links available to the
client network or can withdraw them. These actions can be in
response to requests from the client layer, or can be driven by
processes within the abstraction layer (perhaps reorganizing the
use of server layer resources). In any case, the presentation of
new links to the client layer is heavily subject to policy since
this is both operationally key to the success of this architecture
and the central plank of the commercial model described in this
document. Such policies belong to the operator of the abstraction
layer network and are expected to be fully configurable.
Once the abstraction layer network has decided to make a link
available to the client network it will install it at the link end
points (which are nodes in the client network) such that it appears
and can be advertised as a link in the client network.
In all cases, it is important that the operators of both networks are
able to track the requests and responses, and the operator of the
client network should be able to see which links in that network are
"real" physical links, and which are presented by the abstraction
layer network.
11.3. Managing Interactions of Abstraction Layer and Server Networks
The interactions between the abstraction layer network and the server
network a similar to those described in Section 11.2, but there is a
difference in that the server layer is more likely to offer up
connectivity, and the abstraction layer network is less likely to ask
for it.
That is, the server network will, according to policy that may
include commercial relationships, offer the abstraction layer network
a set of potential connectivity that the abstraction layer network
can treat as links. This server network policy will include:
- how much connectivity to offer
- what level of server layer redundancy to include
- whether to realize the connectivity when it is offered, or to wait
until the abstraction layer network asks to use a link.
This process of offering links from the server network may include a
mechanism to indicate which links have been pre-established in the
server network, and can include other properties such as:
- link-level protection ([RFC4202])
- SRLG and MSRLG (Section 5.3.3.1)
- mutual exclusivity (Section 5.3.3.2).
The abstraction layer network needs a mechanism to request that a
link is realized if it hasn't already been established as an LSP in
the server network. This mechanism could also include the ability
to request additional connectivity from the server layer, although
it seems most likely that the server layer will already have
presented as much connectivity as it is physically capable of
subject to the constraints of policy.
Finally, the server layer will need to confirm the establishment of
connectivity, withdraw links if they are no longer feasible, and
report failures.
Again, it is important that the operators of both networks are able
to track the requests and responses, and the operator of the server
network should be able to see which links are in use.
12. IANA Considerations 12. 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.
13. Security Considerations 13. Security Considerations
Security of signaling routing protocols is usually administered and Security of signaling and routing protocols is usually administered
achieved within the boundaries of a domain. Thus, and for example, and achieved within the boundaries of a domain. Thus, and for
a domain with a GMPLS control plane [RFC3945] would apply the example, a domain with a GMPLS control plane [RFC3945] would apply
security mechanisms and considerations that are appropriate to GMPLS the security mechanisms and considerations that are appropriate to
[RFC5920]. Furthermore, domain-based security relies strongly on GMPLS [RFC5920]. Furthermore, domain-based security relies strongly
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 proposals in this document for inter- domain from outside. Thus, the mechanisms in this document for
domain exchange of control plane information naturally raise inter-domain exchange of control plane messages and information
additional questions of security. 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 predicted relationships protocols operating between peers that have predictable relationships
(for example, UNI-C to UNI-N, or between BGP-LS speakers). Thus, (for example, UNI-C to UNI-N, between BGP-LS speakers, or between
the security that needs to be given additional attention for peer domains). Thus, the security that needs to be given additional
inter-domain TE concentrates on authentication of peers, assertion attention for inter-domain TE concentrates on authentication of
that messages have not been tampered with, and to a lesser extent peers, assertion that messages have not been tampered with, and to a
protecting the content of the messages from inspection since that lesser extent protecting the content of the messages from inspection
might give away sensitive information about the networks. The since that might give away sensitive information about the networks.
protocols described in Section 6 and which are likely to provide The protocols described in Section 6 and which are likely to provide
the foundation to solutions to this architecture already include the foundation to solutions to this architecture already include
such protection and further can be run over protected transports such protection and further can be run over protected transports
such as IPsec [RFC6701], TLS [RFC5246], and the TCP Authentication such as IPsec [RFC6701], TLS [RFC5246], and the TCP Authentication
Option (TCP-AO) [RFC5925]. Option (TCP-AO) [RFC5925].
It is worth noting that the control plane of the abstraction layer
network is likely to be out of band. That is, control plane messages
will be exchanged over network links that are not the links to which
they apply. This models the facilities of GMPLS (but not of MPLS-TE)
and the security mechanisms can be applied to the protocols operating
in the out of band network.
14. Acknowledgements 14. 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.
Thanks to Gert Grammel for discussions on the extent of aggregation Thanks to Gert Grammel for discussions on the extent of aggregation
in abstract nodes and links. in abstract nodes and links.
Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, and Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam
Vallinayakam Somasundaram for review and input. Somasundaram, and Hannes Gredler 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 5.3.3 is freely adapted from the work of Igor Text in Section 5.3.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 53, line 21 skipping to change at page 60, line 12
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-Autonomous [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, November 2005. RFC 4216, November 2005.
[RFC4271] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and Ayyangar, A., "A Framework [RFC4726] Farrel, A., Vasseur, J.-P., and Ayyangar, A., "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC4847] T. Takeda (Ed.), "Framework and Requirements for Layer 1 [RFC4847] T. Takeda (Ed.), "Framework and Requirements for Layer 1
Virtual Private Networks," RFC 4847, April 2007. Virtual Private Networks," RFC 4847, April 2007.
 End of changes. 72 change blocks. 
163 lines changed or deleted 490 lines changed or added

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