One document matched: draft-leroux-pce-backup-comp-frwk-00.txt
PCE BOF JP Vasseur (Ed.)
Internet Draft Anna Charny
Francois Le Faucheur
Cisco System Inc.
Javier Achirica
Telefonica
JL Le Roux (Ed.)
France Telecom
Category: Standard Track
Expires: January 2005 July 2004
Framework for PCE-based MPLS-TE Fast Reroute Backup Path Computation
draft-leroux-pce-backup-comp-frwk-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
By submitting this Internet-Draft, I certify that any applicable
patent or IPR claims of which I am aware have been disclosed, or will
be disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Vasseur, Le Roux et al. Expires January 2005 [Page 1]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
Abstract
This document proposes a framework for the use of Path Computation
Elements (PCE) to compute bypass tunnels paths, in the context of the
MPLS-TE Fast Reroute, while allowing bandwidth sharing between bypass
tunnels protecting independent resources. Both a centralized and a
distributed PCE scenarios are described. The corresponding required
Routing and signalling extensions are beyond the scope of this
framework and will be addressed in separate documents.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
0. Background
This draft is a new revision of the expired draft draft-vasseur-mpls-
backup-computation-02.
Table of Contents
1. Terminology.................................................4
2. Introduction................................................5
3. Requirements................................................5
3.1. Bandwidth Protection........................................5
3.2. Bandwidth sharing...........................................6
4. Bypass tunnel path computation models.......................7
5. Limitations of the independent CSPF-based computation model.8
5.1. Bandwidth sharing...........................................8
5.2. Potential inability to find a placement of a set of
bypass.tunnels satisfying constraints.......................9
6. The PCE-based Computation Model.............................9
6.1. Solution Overview...........................................9
6.2. Information required by the PCE............................10
6.3. Centralized PCE scenario...................................11
6.3.1. PCE responsible for both the primary and bypass tunnels
path.computation...........................................11
6.3.1.1. PLR-PCE Signaling........................................12
6.3.1.2. Signaling Bypass tunnels with zero Bandwidth.............12
6.3.2. PCE responsible for bypass tunnels path computation only
(not primary TE LSPs)......................................13
6.3.2.1. Backup Pool advertised in IGP............................13
6.3.2.2. Backup Pool not being advertised in IGP..................14
Vasseur, Le Roux et al. Expires December 2004 [Page 2]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
6.4. Distributed PCE scenario...................................14
6.4.1. Node Protection............................................14
6.4.2. Link Protection............................................16
6.4.3. SRLG protection............................................16
7. Validity of the Independent failure assumption.............17
8. Operations with links belonging to multiple SRLGs..........19
8.1. Notion of SRLG dependency, and Shared SRLG Dependency
Link Group (SDLG)..........................................20
8.2. SDLG protection............................................21
8.2.1. Distributed scenario for SDLGs protection..................22
8.3. Alternative solution.......................................22
9. Operations with DS-TE and multiple Class-Types.............22
9.1. Single backup pool.........................................23
9.2. Multiple backup pools......................................25
10. Interaction with scheduling................................27
11. PLR-PCE Signaling: Functional description..................28
11.1. Element to protect.........................................28
11.2. Bandwidth to protect.......................................28
11.3. Affinities.................................................28
11.4. Maximum number of bypass tunnels...........................28
11.5. Minimum bandwidth on any element of a set of bypass
tunnels....................................................28
11.6. Class Type to protect......................................29
11.7. Set of already in place bypass tunnels.....................29
12. Bypass tunnel - Make before break..........................29
13. Stateless versus Statefull PCE.............................29
14. Packing algorithm..........................................29
15. Security Considerations....................................30
16. Acknowledgements...........................................30
17. Security Considerations....................................30
18. Intellectual Property Statement............................30
18.1. IPR Disclosure Acknowledgement.............................30
19. References.................................................31
20. Authors' Address:..........................................32
Vasseur, Le Roux et al. Expires December 2004 [Page 3]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
1. Terminology
Terminology used in this document
LSR - Label Switch Router
LSP - An MPLS Label Switched Path
PCE - Path Computation Element. A PCE may be
any kind of LSR or an offline tool not forwarding packets. A
PCE computes paths for TE-LSPs it is not the head-end for.
PCC - Path Computation Client (any LSR) requesting a path
computation of the Path Computation Element.
Local Repair - Techniques used to repair LSP tunnels quickly
when a node or link along the LSPs path fails.
Protected LSP - An LSP is said to be protected at a given hop if
it has one or multiple associated bypass tunnels originating
at that hop.
Bypass Tunnel - An LSP that is used to protect a set of LSPs
passing over a common facility.
PLR - Point of Local Repair. The head-end of a bypass tunnel.
MP - Merge Point. The LSR where bypass tunnels meet the protected
LSP. A MP may also be a PLR.
NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A bypass tunnel
which bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A bypass
tunnel which bypasses a single node of the protected LSP.
Reroutable LSP - Any LSP for which the "Local protection desired"
bit is set in the Flag field of the SESSION-ATTRIBUTE object
of its Path messages (and/or a FAST-REROUTE object is
included in its Path message).
CSPF - Constraint-based Shortest Path First.
Vasseur, Le Roux et al. Expires December 2004 [Page 4]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
2. Introduction
This document proposes a framework for the use of Path Computation
Element(s) to compute bypass tunnels paths, in the context of the
MPLS-TE Fast Reroute, while allowing bandwidth sharing between bypass
tunnels protecting independent resources. Both a centralized and a
distributed PCE scenarios are described.
The focus of this document is ''Bandwidth protection'' in the context
of local repair capability of MPLS Fast Reroute. Bandwidth Protection
refers to the issues related to the computation of a bypass tunnel
path satisfying the capacity requirements of the primary tunnels
protected by the considered bypass tunnel. We do not propose another
method for MPLS Traffic Engineering Fast Reroute. This draft makes
the assumption that the fast reroute technique named Facility backup
and described in [FAST-REROUTE] is used to provide fast recovery in
case of link/node failure.
The exact algorithms for placement of the bypass tunnels with
bandwidth guarantees are outside the scope of this draft. Rather, we
concentrate on the mechanisms enabling the bypass tunnel path
computation to be performed by a Path Computation Element (PCE) which
holds sufficient information in order to achieve efficient sharing of
bandwidth between bypass tunnels protecting independent failures. The
mechanisms are described in the context of both a centralized (the
PCE computes the set of bypass tunnels to protect every facility in
the network) and a distributed computation (every LSR behaves a PCE
to compute the set of bypass tunnels for each of its neighbours in
case of its own failure or failure of one of its own links).
The required routing and signalling extensions (PLR-PCE signalling)
will be addressed in separate documents.
3. Requirements
3.1. Bandwidth Protection
As defined in [FAST-REROUTE], a TE LSP can explicitly request to be
fast protected (in case of link/node/SRLG failure the TE LSP will be
locally rerouted onto a backup tunnel, as defined in [FAST REROUTE])
and rerouted onto a backup tunnel with an equivalent bandwidth (in
other words without QOS degradation, supposing here that offering an
equivalent QOS can be reduced to preserving bandwidth requirement).
This can be signaled (in the Path message) in two ways:
- with the SESSION-ATTRIBUTE object by setting:
- the ''Local protection desired'' bit
- the ''Bandwidth protection desired'' bit
- with the FAST-REROUTE object by setting a non-zero
bandwidth.
Note that other parameters related to the backup tunnel can also be
signaled in the Path message.
Vasseur, Le Roux et al. Expires December 2004 [Page 5]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
Bandwidth protection would typically be requested for TE LSPs
carrying very sensitive traffic (Voice trunking, ...).
When a link/node/SRLG failure occurs, the PLR (Point of Local Repair)
fast reroutes the protected LSPs onto their bypass tunnel. The PLR
should also send a Path Error notifying the head-end LSRs that the
protected LSPs have been locally repaired so that head-ends can
trigger a re-optimization, and potentially reroute the TE LSP in a
non disruptive manner (make before break) following a more optimal
path, provided such a path exists.
The bandwidth of the bypass tunnels that the protected LSPs will be
rerouted onto will dictate the level of bandwidth protection and in
turn the QOS during failure until the TE LSPs are being re-optimized
by their respective head-end (if such a re-optimization can be
performed, depending on the available network resources).
Various constraints can be taken into account for the bypass tunnels:
(1) must be diversely routed from the protected element
(link/node/SRLG diverse),
(2) must be setup in such a way that they get enough
bandwidth so that the protected LSPs requesting bandwidth
protection should receive the same level of QOS when
rerouted. Note that the notion of bandwidth protection is
on a per LSP basis.
(1) must always be satisfied and makes FRR an efficient protection
mechanism to reroute protected TE LSP in 10s of milliseconds in case
of link or node failure.
(2) allows FRR to provide an equivalent level of QOS during failure
to the TE LSPs that have requested bandwidth protection.
A backup Path computation mechanism ensuring bandwidth protection is
highly desirable.
3.2. Bandwidth sharing
Since local repair is expected to be used for only a short period of
time after failure, typically followed by re-optimization of the
affected primary LSPs, it is reasonable to expect that the
probability of multiple failures (of facilities which do not share an
SRLG) in this short period of time is very small. As a result, being
able to share bandwidth on the link among bypass tunnels protecting
independent facilities (with regards to failure risks) typically
results in large savings in the bandwidth required for protection.
This is what we refer many times in this document as ''efficient
bandwidth sharing'' or as achieving ''bandwidth sharing''. Note also
that the single failure assumption needed for such bandwidth sharing
is a pre-requisite to any protection approach which uses pre-computed
protected paths, clearly even two completely link and node disjoint
Vasseur, Le Roux et al. Expires December 2004 [Page 6]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
pre-computed paths can both fail if more than one failure can occur
as one failure may occur on the primary and the other on the second
path. It is worth underlining that the single failure of a SRLG may
result in the actual failure of multiple links. For the purposes of
this draft we consider the entire SRLG as a single element that needs
to be protected.
Once the head-end receives the Path Error (''Tunnel locally
repaired''), reoptimization should be triggered followed by an LSP
reroute making use of the ''Make Before Break'' technique to avoid
traffic disruption, assuming such a more optimal path obeying the
constraints within the new network topology can be found. If such a
path cannot be found, the TE LSP will not be reoptimized and will
still be fast rerouted by the immediately upstream PLR attached to
the failed element.
The two following situations result in a multiple independent
failures scenario where bandwidth protection with backup bandwidth
sharing cannot be ensured:
- a second failure occurs before the TE LSP is reoptimized,
- the TE LSP cannot be reoptimized and a second failure
happens before the first failure has been restored.
Note however that in networks where bandwidth is a reasonably
available resource, this situation is unlikely to happen as the
TE LSP reoptimization will succeed. Furthermore, in networks
where bandwidth is a very scarce resource, bandwidth protection
without backup bandwidth sharing is likely to require
substantially more bandwidth, and therefore is likely to be
impossible anyway.
As a result, bandwidth sharing among bypass tunnels protecting
independent failures is highly desirable.
4. Bypass tunnel path computation models
Various bypass tunnel path computation models have been proposed:
independent CSPF-based computation, [KINI], [BP-PLACEMENT], ...
A new model, named ''PCE based computation model'' is proposed in
this draft.
Vasseur, Le Roux et al. Expires December 2004 [Page 7]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
5. Limitations of the independent CSPF-based computation model
The simplest mechanism (called independent CSPF-based computation
model) to get bandwidth protection available is to rely on
existing IGP TE advertisement and for the head-end of the bypass
tunnel:
- to determine the bandwidth requirements of the desired
bypass tunnel(s),
- to compute the bypass tunnels path in the network where the
appropriate amount of bandwidth is available using standard
CSPF-based computation,
- to signal the bandwidth requirements of the individual
bypass tunnels explicitly.
While this approach is quite attractive for its simplicity, it
presents a substantial set of challenges:
- Inability to perform bandwidth sharing between bypass tunnels
protecting independent resources, resulting in very large
wastage of bandwidth.
- Potential inability to find a placement of the bypass tunnels
satisfying the bandwidth constraints, even if such a
placement exist
5.1. Bandwidth sharing
Improvements to the independent CSPF-based computation model have
been proposed in [KINI] and [BP-PLACEMENT] in order to achieve
bandwidth sharing. They still rely on an independent CSPF computation
performed by PLRs.
In [BP-PLACEMENT], routing extensions are proposed to propagate the
set of bypass LSPs and their attributes, allowing for a complete
bandwidth sharing, but with a significant impact on the IGP.
While the approach described in [KINI] substantially reduces
the amount of information that needs to be propagated in routing
updates, it sacrifices the amount of achievable sharing.
Both approaches also require modifications to admission control
algorithms, as well as signaling extensions to convey the information
necessary to perform specific call admission control for backup LSPs.
In contrast, the approach described in this draft can be used to
achieve complete sharing without any routing extensions and without
any modification to admission control (although as discussed further
in section 7.2 a small amount of routing extensions is desirable for
the distributed case to provide flexibility in the choice of
protection strategies)
Vasseur, Le Roux et al. Expires December 2004 [Page 8]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
5.2. Potential inability to find a placement of a set of bypass
tunnels satisfying constraints
Another well-known issue with independent CSPF-based computation with
explicitly signaled bandwidth requirements is its potential inability
to find a placement of the bypass tunnels satisfying the bandwidth
constraints, even if such a placement exists. This issue is not
specific to the placement of the bypass tunnels - rather it is due to
the sub-optimality of a greedy on-demand nature of the CSPF approach
and the non coordinated bypass tunnel computation approach to protect
a given facility
While addressing this problem is not a primary goal of this draft,
The PCE-based computation model described in this draft provides the
opportunity to improve the chance of finding a feasible placement of
the bypass tunnel as it enables the use of algorithms that can take
advantage of coordination between the placement of bypass tunnels
protecting the same element. However, the exact algorithms
appropriate for this purpose are outside of the scope of this draft.
6. The PCE-based Computation Model
This draft proposes another model for bypass tunnel path
Computation, based on the use of PCE capabilities. It is referred as
the ''PCE based computation model''.
Note that in this section we assume that a bypass LSP protects only
one facility (link, node or SRLG). The PCE based computation model
can be extended to more general case where bypass tunnel can protect
more than one facility, but this requires specific procedures that
are addressed in sections 7 (NNHOP activated in case of both link and
node failures) and 8 (NHOP protecting link belonging to multiple
SRLGs).
6.1. Solution Overview
The proposed solution consists in moving the bypass computation from
the PLR to a Path Computation Element that computes, in a coordinated
manner, all bypass LSPs protecting a given facility.
Given the single failure assumption, the set of bypass tunnels
protecting a given facility is computed independently of any other
bypass tunnel protecting a distinct facility, and making use of all
bandwidth available for backup purpose. This directly ensures
bandwidth sharing. Also, the sets of bypass tunnels protecting
independent facilities can be computed by distinct PCEs, allowing for
a distributed scenario.
As bypass tunnels protecting a common facility are computed in a
coordinated manner and as they do not compete for bandwidth with
Vasseur, Le Roux et al. Expires December 2004 [Page 9]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
bypass tunnels protecting independent facilities, they can be
signalled with zero bandwidth. This avoids any extension to RSVP and
local admission control, to take into account bandwidth sharing. This
requires, when primary and bypass tunnel are not computed by the same
entity, the definition of a backup-bandwidth pool because the
bandwidth used by the bypass tunnels is invisible to the entity
responsible for the computation of the primary TE LSPs.
The PCE based computation model can be implemented in two
different ways: centralized or distributed.
In the centralized case a single PCE computes the protection of all
facilities. We distinguish two options whether the PCE is also
responsible for the placement of primary tunnels or not.
In the distributed case the PCE function is distributed on LSRs. The
distribution should be so that all bypass tunnels protecting a given
facility are computed by the same LSR:
-For node protection, the PCE is the protected LSR itself
-For link protection, the PCE is one of the two link end-points
-For SRLG protection, the PCE is one elected LSR among the end-
points of the SRLG links end-points.
In all of these scenarios the PCE-based computation enables sharing
of bandwidth among bypass tunnels protecting independent failures. In
addition, all of these scenarios also allow overcoming some of the
limitations of the greedy independent CSPF-based placement of the
bypass tunnels, increasing the chances of finding a bypass tunnels
placement satisfying the constraints if such a solution exists.
While some of these approaches can benefit from an IGP-TE extension
advertising an additional backup bandwidth pool, all of these
approaches can be usefully deployed in a limited fashion in the
existing networks without any additional routing extensions at all.
Some signaling protocol is required to allow communication between
PLRs and PCE, so that the PLR can request the PCE for backup
computation and the PCE can reply with the computed paths.
The required routing and signaling protocol extensions will be
addressed in separate documents.
6.2. Information required by the PCE
To compute the bypass tunnels protecting a given element, the PCE
needs to know:
- the network topology,
- the desired amount of primary traffic that needs to be
bandwidth protected (this could be either the actual
bandwidth reserved by primary TE LSPs requiring bandwidth
protection or the whole bandwidth pool from which the
primary LSPs reserve bandwidth)
- the amount of bandwidth available for the placement of the
bypass tunnels (also referred to as backup bandwidth).
Vasseur, Le Roux et al. Expires December 2004 [Page 10]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
The network topology is available directly from the IGP TE database
as well as the desired amount of primary traffic that needs to be
protected if one protects a bandwidth pool (and not the actual
bandwidth reserved by primary TE LSPs requiring bandwidth
protection).
The information about the backup bandwidth pool depends on the exact
model and is discussed separately in above scenarios.
6.3. Centralized PCE scenario
In the centralized scenario, the bypass tunnel path computation is
being performed on a central PCE (which can be a workstation or
another LSR). The PCE will be responsible for the computation of the
bypass tunnels for some or all the LSRs in the network. Typically,
there could be one PCE per area in the context of a multi-area
network. The PCE(s) address(es) may be manually configured on every
LSR or automatically discovered using IGP extensions.
WE distinguish two cases, whether the PCE is also responsible for the
computation of primary tunnels or not. There differ in the way backup
bandwidth is handled.
6.3.1. PCE responsible for both the primary and bypass tunnels path
computation
In this scenario, the PCE can easily take advantage of knowing all
the primary tunnels to define bandwidth protection requirements based
on actual primary LSPs.
There is substantial flexibility in choosing what bandwidth can be
used for the bypass tunnel placement. One approach might be to use
for the bypass tunnels the same bandwidth pool as the corresponding
primary LSPs.
At some point the user will have to specify the policy to the server.
For example, protect traffic of a pool X with a bypass tunnel in the
same pool but also the proportion of pool X that can be used for
backup and primary. For pool X, the user could specify: ''up to y% of
pool X can be used for backup''.
Since in this scenario the server is responsible for the placement of
both the primary traffic and the bypass tunnels, at any given time in
the computation of the bypass tunnels it has complete information
about the topology and the current placement of all bypass and
primary tunnels. Therefore, the server can compute the bypass tunnels
protecting one element at a time, and when placing its bypass tunnels
simply ignore the bandwidth of any bypass tunnels already placed if
Vasseur, Le Roux et al. Expires December 2004 [Page 11]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
those protect a different element, thus ensuring implicitly the
desired bandwidth sharing. In this case, there is no need to specify
a notion of backup bandwidth pool.
6.3.1.1. PLR-PCE Signaling
A PLR has to request the PCE for bypass path computation, potentially
indicating the amount of bandwidth that has to be protected.
Having computed the bypass tunnels, the PCE needs to inform the PLR,
about the placement of the bypass tunnels, their bandwidth, and the
elements they protect.
Such PLR-PCE communication requires an LSR-PCE signalling protocol
for communication of bypass path computation request from the LSR to
the PCE and bypass path computation responses from the PCE to the
LSR.
6.3.1.2. Signaling Bypass tunnels with zero Bandwidth
Once an LSR has received the information about the bypass tunnels for
one or more elements it is the head-end for, it needs to establish
those tunnels along the specified paths. At first glance, given the
need to ensure bandwidth protection, it seems natural to signal the
bandwidth requirements of the bypass tunnel explicitly. However, as
discussed in [BP-PLACEMENT], such approach requires that the local
admission control is changed to be aware of the bandwidth sharing,
and additional signaling extensions need to be implemented to enable
an LSR to tell a primary LSP from a bypass LSP so that admission
control can be performed differently in the two cases.
However, since the placement of both the primary and the bypass
tunnels in this case is done by the server which maintains the
bandwidth requirements of all these primary and bypass LSPs, it is
sufficient to signal zero-bandwidth tunnels, thus avoiding the need
for any additional signaling extensions or changes to admission
control. Even though the required bandwidth will not be explicitly
signaled, it will nevertheless be available along the path upon
failure by virtue of the computation of this placement by the server
which is fully aware of the global topology and places all TE LSPs in
such a way that their bandwidth requirements are satisfied.
Note also that although the bandwidth requirements are not explicitly
signaled, the PLR may store this information locally, since it may
be needed in determination of which primary LSPs to assign to which
bypass tunnels in the case where more than one bypass tunnel exists
(see section 14).
Vasseur, Le Roux et al. Expires December 2004 [Page 12]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
6.3.2. PCE responsible for bypass tunnels path computation only
(not primary TE LSPs)
A key aspect of the previous scenario (PCE computing both the
primary and backup LSPs) was the fact that the PCE could make
use, for the bypass tunnels, of any available bandwidth not reserved
for primary TE LSPs. As a consequence, definition of a
separate backup pool was not required. On the other hand, if the PCE
is just responsible for the bypass tunnels paths (i.e the primary
tunnels are established on-line or by any other mechanism external to
the backup path computation server), and if the bypass tunnels are
signaled with zero bandwidth to enable efficient bandwidth sharing,
then the bypass
tunnels cannot draw bandwidth from the same pool as the primary
traffic they protect. This is because the bandwidth used by the
bypass tunnels is invisible to the entity responsible for the
computation of the primary TE LSPs and therefore the primary TE LSPs
could make use of the entire bandwidth of a given pool. Therefore if
the PCE used for bypass tunnel path computation uses any bandwidth of
the same pool bandwidth protection violation might occur. Achieving
efficient bandwidth sharing in this case requires the definition of a
separate pool that could only be used for bypass tunnels. We refer to
this pool as a backup pool.
As in the previous approach:
- A Signaling protocol is required for communication between
PLRs and the PCE.
- Bypass tunnels are signalled with zero bandwidth
Note that the notion of backup bandwidth pool is similar to that
described in [BP-PLACEMENT].
The backup bandwidth pool approach can be used in two ways:
- being advertised in IGP
- without being advertised in IGP
6.3.2.1. Backup Pool advertised in IGP
In this approach, an additional bandwidth pool is established, and is
flooded in the routing updates.
If the backup PCE uses the value of the backup
bandwidth pool for its computation, no bandwidth overbooking will
ever occur, since the primary tunnels now use the bandwidth from a
different pool. The additional state that needs to be flooded in
routing updates to implement the backup bandwidth pool does not
impact the IGP scalability as the bandwidth protection pool being
announced by IGP-TE is a static value, it does not dynamically change
as backup TE LSP are set up, which preserves IGP scalability. As the
bandwidth protection pool is being defined on a per link basis, this
allows for different policies depending on the link characteristics.
Vasseur, Le Roux et al. Expires December 2004 [Page 13]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
6.3.2.2. Backup Pool not being advertised in IGP
The routing extensions discussed in the previous section are
desirable but not necessary to deploy this approach in the existing
network in a limited, but nevertheless useful fashion.
Since the computation of the bypass tunnels in this approach is
performed by a centralized PCE, the PCE can use the notion of the
backup bandwidth pool implicitly. Just as in the case of a PCE
computing the placement of both primary and backup LSPs, such policy
may be simply configured on the PCE for every link. The policy must
ensure that the backup pool never overlaps with the pool requiring
bandwidth protection.
A generic approach could be for the PCE to compute, for each link,
the backup bandwidth as: link-bandwidth - maximum-reservable-
bandwidth. This approach requires that link-bandwidth > maximum-
reservable-bandwidth which prevents the user from allowing TE
overbooking.
6.4. Distributed PCE scenario
While there are several clear advantages of a centralized (off-line)
model, there are also well-known disadvantages of it (such as the
single point of failure, the necessity to provide reliable
communication channels to the server, etc.) While most of these
issues can be addressed by the proper architectural design of the
network, a dynamic distributed solution is clearly desirable.
This section presents the use of the ''facility-based computation''
solution in a distributed bypass path computation scenario.
6.4.1. Node Protection
Consider first the problem of node protection. The key idea is to
shift the computation of the bypass tunnels from the head-ends of
those bypass tunnels to the node that is being protected.
Essentially, each node protects itself by computing the placement of
all the bypass tunnels that are required to protect the bandwidth of
traffic traversing this node in the case of its failure. Once the
bypass tunnels are computed, they need to be communicated to their
head-ends (in this case the neighbors of the protected node) for
installation. The bypass tunnel head-ends play the role of PLR.
Essentially, each node becomes a PCE for all of its neighbors,
computing all NNHOP bypass tunnels between each pair of its neighbors
which are necessary for its own protection. The fact that the bypass
tunnels to protect a node X are being computed by a single PCE (node
X) is essential and much more efficient than the non-coordinated
independent CSPF-based computation.
Vasseur, Le Roux et al. Expires December 2004 [Page 14]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
The key pieces that make this model work are those already described
in the context of the centralized PCE:
1) Making use of explicitly defined backup bandwidth pool
which is logically disjoint from the primary bandwidth
pool,
2) Taking advantage of a single failure assumption to achieve
bandwidth sharing,
3) Installing bypass tunnels with zero bandwidth.
These three things together allow the computation of the placement of
bypass tunnels for a given node to be completely independent of the
placement of bypass tunnels for any other node. Essentially, each
node has the entire backup bandwidth pool available for itself. The
problem it needs to solve is how to place a set of NNHOP bypass
tunnels (one or more for each pair of its direct neighbors) in a
network with available capacity on each link equal to the backup
bandwidth pool. This problem can be solved by any algorithm for
finding a feasible placement of a set of flows with given demands in
a network with links of given capacity.
While the details of such algorithm are beyond the scope of this
draft, it is clear that since the node now has control over all
bypass tunnels protecting itself, it is more likely that it can find
such a placement, and potentially find a more optimal placement, than
is possible if the PLRs compute the placement of these tunnels
independently of each other.
Just as in the case of a centralized PCE, installing the bypass
tunnels with zero bandwidth ensures that no changes to admission
control are necessary to allow sharing of the backup pool by bypass
tunnels protecting different nodes, thus enabling bandwidth sharing
between independent failures. Yet, by virtue of the computation, the
bypass tunnels protecting a given node will also have enough
bandwidth in the case of that node's failure.
Note also that the backup pools can be implicitly derived from the
routing information already available. This could be done by
configuring max global reservable pool to being less than the link
speed by the desired value of the backup pool. Every node computing
its bypass tunnels then can by default use link speed minus the max
global reservable pool as the value of the backup pool to use in its
computation of the bypass tunnels placement.
As described earlier, there is substantial benefit in defining the
backup pool explicitly and advertise its value as part of the
topology in the routing updates. This clearly requires an IGP-TE
extension that will be defined in a separate draft. The benefit of
Vasseur, Le Roux et al. Expires December 2004 [Page 15]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
doing so is that it provides much more flexibility in the design of
the network.
Yet it is important to emphasize that while IGP-TE extensions is a
clear benefit for facility-based computation, it is not a requirement
for this solution to work under a limited set of assumptions (namely,
as discussed above if the backup pool is set to link speed minus
maximum reservable primary bandwidth, the latter being configured to
less than link speed).
Finally, as for a centralized PCE, a signaling protocol is required
for communication between the protected node acting as PCE and its
neighbour acting as PLRs.
6.4.2. Link Protection
In order to protect a link with MPLS TE Fast Reroute in both
directions, two bypass tunnels protecting each direction of this link
are installed by the corresponding head-end of that link. To make
sure that traffic requesting bandwidth protection traversing this
link is protected in case of a link failure (if both directions fail
simultaneously), it is necessary to account for the interaction of
the bypass tunnels protecting different directions of this link. That
is, one needs to make sure that if a bypass tunnel T1 protecting
bandwidth B1 on a directed link A->B and the tunnel T2 protecting
bandwidth B2 on a directed link B->A traverse the same directed link
L, then link L has spare capacity of at least B1+B2.
If the two ends of the link compute their bypass tunnels
independently, the way to ensure this condition would be to
explicitly signal the bandwidth of the bypass tunnels. However, as
discussed earlier, this approach makes the sharing of bandwidth
between the bypass tunnels protecting different elements impractical
and would require IGP and admission control extensions. To achieve
this goal in a distributed setting we propose that one of the two
end-nodes of the link takes the responsibility for computing the
bypass tunnels for both directions using the backup pools explicitly
or implicitly defined. We propose that by default the node with the
smaller IGP id serves as the PCE for the other end of the link.
Therefore, by default a node with id X serves as a PCE for NNHOP
bypass tunnels protecting itself and NHOP bypass tunnels protecting
any adjacent bi-directional link for which the other end has an IGP
id larger than X.
6.4.3. SRLG protection
In the case when each link in the network cannot belong to more than
one SRLG, we propose to use exactly the same approach as for the bi-
directional link. That is, if an SRLG consists of a set of bi-
directional links, the node with the smallest IGP id of all the
Vasseur, Le Roux et al. Expires December 2004 [Page 16]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
endpoints of these links serves by default as a PCE. The case where
links are part of more than one SRLG requires
specific processing (see section 8).
7. Validity of the Independent failure assumption
The facility based computation model is heavily dependent on the
single independent failure assumption. That is, it is assumed that
the probability of multiple independent element failures in the
interval of time required for the network to re-optimize primary
tunnels affected by a given failure and to re-compute the bypass
tunnels for other elements is low.
In a distributed model both of these tasks are likely to be
accomplished within a very short time so the assumption typically can
be justified. The loss of bandwidth protection in the rare cases that
the assumption is violated is offset by the benefit of sharing the
bandwidth between bypass tunnels protecting different elements.
However, not all elements are independent. One example of elements
that are not independent is a set of links in the same SRLG.
Therefore, as discussed above, SRLG is treated as a single element
and is protected as a single entity.
Another example of failures that are not independent is a failure of
a node and links adjacent to it. It is possible (and is frequently
the case) that a failure of a node results also in the failure of the
link(s). However, in the approach described in the draft the
computation of bypass tunnel paths for link and node protection is
done independently. This is necessary to ensure that NNHOP tunnels
for a node can be computed completely independently of the NHOP
tunnels for adjacent links, thus enabling the distributed
computation. The justification for this is that when a node fails,
traffic that does not terminate at this node is protected because it
is rerouted over the NNHOP tunnels, and traffic that does terminate
at the failed node does not need to be protected against the failure
of adjacent links since it would get dropped anyway.
Thus, the underlying assumption is that if a node fails, the NHOP
tunnels protecting the link are not used, while if a link fails but
the router does not, the NHOP tunnels are used. So they can in fact
be computed independently. However, this reasoning only works if it
is in fact possible to identify the type of failure correctly and use
the appropriate set of tunnels depending on the failure.
There are several cases to be considered:
- A downstream router fails but the link does not,
- The link fails but the downstream router does not,
- The link fails because the downstream router failed.
Vasseur, Le Roux et al. Expires December 2004 [Page 17]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
The first case is typically identifiable by means of RSVP hello or
some IGP hellos mechanism on layer 2 link providing fast failure
notification. However, when a link failure does occur, using the
currently deployed mechanisms, a node adjacent to the failed link
cannot tell within the time appropriate for Fast Reroute whether the
node on the other side of that link is operational or not. Therefore,
it is currently impossible to reliably tell apart the second and the
third cases above. Hence, to protect both traffic that terminates at
the failed node in case the failure was a link failure, and at the
same time to protect traffic transit through the failed node in case
it was a node failure, the LSR adjacent to the failed link is forced
to use both the NHOP and the NNHOP tunnels at the same time. This may
lead to a violation of bandwidth guarantees, since the NHOP and NNHOP
tunnels were computed independently using the same backup bandwidth
pool, and so they may share a link with enough bandwidth for only one
but not the other.
A similar issue occurs in the case of bi-directional link failure.
Since the two nodes on each side of the link will see the failure of
an adjacent link, unless they can detect that it was a link and not a
node failure, they will be forced to activate the NHOP tunnel
protecting the link, and the NNHOP tunnel protecting the node on the
other side. Essentially, the system will operate as if two failures
have occurred simultaneously when in reality only a single (bi-
directional) link failed.
This clearly can result in a violation of a bandwidth guarantee.
To address this issue, one needs a mechanism to differentiate a link
from a node failure. Such a mechanism is described in [LINKNODE-
FAILURE].
Note that in the centralized model, the PCE may compensate for the
lack of the ability to tell a link from a node failure by making sure
that the NNHOP bypass tunnels for adjacent nodes and the NHOP bypass
tunnels for the corresponding links do not collide. While this makes
the problem of finding such backup tunnels algorithmically more
challenging, it remains possible to achieve bandwidth sharing in this
case. However, the ability to tell a link from a node failure is
crucial for the distributed model when node protection is desired.
It is worth mentioning however that if just NHOP bypass tunnels are
required (nodes are considered as reliable ''enough'') and just links
are protected against failures, then there is no need to distinguish
between node and link failure even in the distributed case.
Vasseur, Le Roux et al. Expires December 2004 [Page 18]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
8. Operations with links belonging to multiple SRLGs
In section 7 we limit the study to the case of links that are not
part of more than one SRLG. However in some networks links might be
part of more than one SRLG. This section presents the use of the PCE
based computation model in the general case where links are part of
zero, one or more SRLGs. Both centralized and distributed scenarios
are addressed.
Recall that PCE based computation model consists of a coordinated
placement of the set of bypass protecting one element by the same
PCE, independently of the protection of each other element.
This is clearly not applicable when bypass tunnels protect multiple
independent elements, which is the case when bypass tunnels protect
links belonging to multiple SRLGs, as an SRLG can be considered as an
independent element (in terms of failure risk).
In case SRLGs are not disjoint, the placement of bypass LSPs
protecting a given SRLG cannot be done independently of any other
SRLG. Even if SRLGs remain independent elements in term of failure
risk, their bandwidth protection computation can no longer be done
independently, and must be coordinated.
For instance, lets take 3 links L1, L2, L3 and two SRLGs S1 and S2
such that S1= {L1, L2} and S2={L2, L3}. S1 and S2 are not disjoint,
and their intersection is the link L2. If b1, b2 and b3 are NHOP
bypass tunnels protecting respectively L1, L2, and L3 then:
- b1 and b2 computations must be coordinated, as they protect a
common SRLG S1.
- b2 and b3 computations must be coordinated as they protect a
common SRLG S2.
It results clearly that b1, b2 and b3 path computations must be
coordinated, (and thus in the framework of facility-based computation
model must be performed by the same PCS) and we say that L1, L2 and
L3 are SRLG dependant.
It is important to note in this case that even if b1 and b3 protect
independent elements, in terms of failure (L1 and L3 are SRLG
diverse), their path computation must be coordinated.
Bandwidth sharing can still be ensured in that case, but this
additional level of dependency in the computation of bypass LSPs
requires more intelligence on the server, and can substantially
reduce the degree of distribution in case of a distributed setting.
The use of the PCE based computation model, in this context,
requires accounting for such dependency. The proposed solution is to
regroup together all links whose protection placement must be
coordinated into a new entity called Shared SRLG Dependency Link
Group (SDLG). These links are said SRLG dependant. The result of such
grouping is a set of disjoint groups, called Shared SRLG Dependency
Link Groups, and noted SDLG.
Vasseur, Le Roux et al. Expires December 2004 [Page 19]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
Then, in the context of the PCE based computation model, we extend
the notion of facility to SDLGs. Each SDLG is treated, as a single
element and is protected as a single entity (as a link or node), but
with a modified aggregate bandwidth constraints, in order to take
into account the assumption that only one SRLG fails and thus that
not all bypass tunnels protecting a given SDLG are activated
simultaneously. This is discussed in more detail below.
8.1. Notion of SRLG dependency, and Shared SRLG Dependency Link
Group (SDLG)
To take into account, in the facility based computation model, links
that take part of multiple SRLGs, we define the notion of SRLG
dependency: two links are said SRLG dependant, in the context of the
facility based computation model, if their protection cannot be
computed independently, or in other words if the computation of the
NHOP bypass tunnels protecting these links must be done in a
coordinated manner.
It is clear that if two links are part of the same SRLG then they are
SRLG dependant, but this is not necessary. Two SRLG diverse links
maybe SRLG dependant, indeed in the above example, L1 and L3 are SRLG
diverse but SRLG dependant.
Note that this dependency relation is transitive. It means that if L1
and L2 are dependant and L2 and L3 are dependant then L1 and L3 are
dependant.
We define a Shared SRLG Dependency Link Group, noted SDLG, as a group
of SRLG dependant links. An SDLG regroups all links that are SRLG
dependant. From the transitivity property mentioned above, a link
cannot belong to two SDLGs. Thus, it results that every link of a
network, part of one ore more SRLGs, can be associated with a unique
SDLG. The union of all the disjoint SDLGs is the set of links in the
network.
The number of SDLGs will depend on the repartition of SRLGs among
network links.
The number of SDLGs is always less than the number of SRLGs. At most
(best case), nb SDLG = nb SRLG: this corresponds in fact to the
particular case where all network links are part of 0 or one SRLG.
At least (worst case) nb SDLG =1: it is the case where all SRLGs are
linked, i.e. we cannot find two disjoint SRLGs.
It is worth pointing out that a SDLG is no more than a union of
linked SRLGs (ie a union of non disjoint SRLGs). An SDLG can be
viewed as a union of SRLGs whose bandwidth protection computation
must be done in a coordinated manner.
Vasseur, Le Roux et al. Expires December 2004 [Page 20]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
Thus a SDLG is noted S1 U S2 ... U Sk. This significantly simplifies
the manipulation of SDLGs by LSRs, and the algorithm to determine the
set of SDLGs.
The identification of SDLGs is required in a distributed computation.
We propose to use as SDLG id, the lowest id of the union of SRLGs
that compose the SDLG.
8.2. SDLG protection
The key idea to support links that belong to multiple SRLGs, in the
PCE based computation model, is to treat an SDLG as a single
element, and protect it as a single entity (as links or node). The
placement of the set of bypass tunnels protecting links from an SDLG
is performed independently of any other element.
The procedure is then relatively similar to the one for other
elements (links or nodes). The computation of the set of tunnels
protecting links of an SDLG, is performed in a coordinated manner,
ignoring bandwidth of any bypass LSP protecting a distinct element
(link, node or SDLG).
The only distinction relies on the aggregate bandwidth constraint.
Bypass tunnels computed for protection of an SDLG may protect
different SRLGs. Thus, assuming than only one SRLG fails
simultaneously, these bypass tunnels are not all activated
simultaneously and it results that the aggregate bandwidth constraint
on a link is lower than the cumulated bypass bandwidth. It is in fact
the maximal bandwidth protecting an SRLG
The PCE SHOULD take this specific aggregate bandwidth constraint into
account when computing the placement of bypass tunnels corresponding
to an SDLG to maximize the bandwidth sharing ratio.
It is clear that the problem it has to solve is algorithmically more
challenging than the simple problem of the placement of given
bandwidth demands on a network of given topology. Here the problem it
has to solve is how to find a feasible placement for a set of NON-
ALL-SIMULTANEOUS flows of given demands, in a network of given
topology.
Both the centralized and distributed scenarios are supported. The
centralized scenario requires no modification to what is defined in
section 7.1, except the addition of the specific aggregate bandwidth
constraint. By contrast, distributed computation requires a procedure
specific to SDLGs that is specified in the section bellow.
Vasseur, Le Roux et al. Expires December 2004 [Page 21]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
8.2.1. Distributed scenario for SDLGs protection.
The same approach as defined in 6.2.3, is used to achieve a
distributed SDLG protection. We propose that one of the end-nodes of
the links forming the SDLG, be elected as PCS for whole SDLG. By
default, the node with the lowest IGP id serves as PCS for the whole
SDLG.
PLR processing:
- A PLR dynamically finds the SDLG its adjacent links belong to.
- Then it determines for each SDLG, the corresponding PCE (ie
the end-node with the lowest IGP id), and sends a Path
computation request to these PCEs, indicating the SDLG id
Note 1: In the particular case where all links are part of zero or
one SRLG, a SDLG is reduced to a single SRLG, and the resulting
distributed setting is then identical to what is proposed in 6.2.3.
Thus SDLG protection supports networks were links belong to 0 or one
SRLG.
Note 2: In case all links are SRLG dependent, there is only one SDLG,
and the result is a centralized computation (single PCE).
Note 3: As soon as there is one link in the network that belongs to
multiple SRLGs, the SDLG approach must be used.
8.3. Alternative solution
An alternative solution to solve the problem of the computation of
NHOP bypass tunnels protecting links part of multiple SRLGs could be
to simply compute separate bypass LSP per SRLG for links belonging to
multiple SRLGs. If the PLR could detect, upon the failure of a link,
which of the SRLGs to which the link belongs actually failed, it
could then use the appropriate bypass tunnel. In this case, each SRLG
could be protected independently.
However, this approach clearly requires that a PLR is capable of
determining which SRLG actually fails when it observes a failure of a
link belonging to multiple SRLGs. Unfortunately, no mechanism to
identify which of the SRLGs actually failed currently exists.
9. Operations with DS-TE and multiple Class-Types
This section assumes the reader is familiar with Diff-Serv-aware MPLS
Traffic Engineering as specified in [DSTE-REQTS] and [DSTE-PROTO] and
with its associated concepts such as Class-Types (CTs), Bandwidth
Constraints (BCs) and the Russian Dolls bandwidth constraint model
defined in [RDM].
Vasseur, Le Roux et al. Expires December 2004 [Page 22]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
The bandwidth protection approach described in this document supports
DS-TE and operations with multiple Class-Types.
It is worth mentioning that both the primary and backup bandwidth
pools sizes have to be carefully determined by the network
administrator as their values dictate the congestion level in case of
failure, as discussed below. In the absence of failure, up to the max
reservable bandwidth pool (i.e the primary bandwidth pool) of
(primary) traffic will be forwarded onto a link. In case of failure,
potentially up to "Primary bandwidth pool" + "backup bandwidth pool"
of traffic will be active on a link. Various scenarios as to what the
backup bandwidth should be reserved for, are discussed in the
following sections. The determination of their values compared to the
link speed is a critical factor.
9.1. Single backup pool
Several bandwidth protection scenarios only require the use of a
single backup pool.
First, when a single Class-Type is used (i.e. network which do not
use Diff-Serv or use Diff-Serv but only enforce a single bandwidth
constraint to all the TE tunnels), bandwidth protection can be
achieved via a single backup bandwidth pool.
Second, when multiple Class-Types are used, a single backup pool can
be used to provide bandwidth protection to LSPs from a single Class-
Type CTc, which is the active CT with the highest index c, (in other
words the active CT with the smallest Bandwidth Constraint), while
LSPs from the other Class-Types do not get bandwidth protection.
Here is an example of such scenario. Let's consider the following
network where:
- DS-TE and the Russian Dolls bandwidth constraint model are used
- two Class-Types (CTs) are used:
o CT1 is used for Voice Traffic
o CT0 is used for Data traffic
From a bandwidth protection perspective, let's assume that:
- Voice traffic (i.e. CT1 LSPs) requires Bandwidth Protection
during failure
- Data traffic (i.e. CT0 LSPs) does not need Bandwidth
Protection during failure.
Let's further assume that the network administrator has elected to
use the notion of backup pool and specify bandwidth requirements for
Vasseur, Le Roux et al. Expires December 2004 [Page 23]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
bypass tunnels based on the full bandwidth pool of primary tunnels
(i.e. BC1) as configured towards the protected facility (as opposed
to the amount of bandwidth currently used by the primary LSPs
requiring bandwidth protection).
Then, for every link the network administrator will configure:
- BC0, the Bandwidth Constraint on the aggregate across all
primary LSPs (CT0+CT1)
- BC1, the Bandwidth Constraint for primary CT1 LSPs
- BCbu, the Bandwidth Constraint for the Backup CT1 LSPs
The bandwidth requirement of each backup LSP is configured based on
the value of BC1 configured towards the facility it protects. In
other words, the backup LSPs are only sized to protect voice traffic
transiting via the protected facility.
Purely for illustration purposes, the diagram below represent these
bandwidth constraints in a pictorial manner.
I-------------------------------------------I ---------------I
I--------------I I I
I CT1 I I I
I Primary I I I
I--------------I I CT1 Backup I
I CT1 + CT0 I I
I-------------------------------------------I ---------------I
I-----BC1------>
I--------------------------------BC0------> I----BCbu------->
Note that while this scenario assumes Data traffic does not need
Bandwidth protection during failure, Data traffic can be either not
protected at all by Fast Reroute or be protected by Fast Reroute but
without bandwidth protection during failure. In the former case, CT0
LSPs transporting Data traffic would not be rerouted into backup LSPs
on failure. In the latter case, CT0 LSPs would be rerouted onto
backup LSPs upon failure; the bypass tunnels could either be a
different set of bypass tunnel from the bypass tunnels for voice, or
could be the same bypass tunnels as for Voice assuming appropriate
DiffServ marking and scheduling differentiation are configured
properly, as discussed below.
From a scheduling perspective, a possible approach is for Voice
traffic to be treated as the exact same Ordered Aggregate (i.e. use
the same EF PHB) whether it is transported on primary LSPs or on
backup LSPs. In that case, on a given link, BC1 and BCbu must clearly
be configured in such a way that the Voice QoS objectives are met
when there is simultaneously, on that link, up to BC1 worth of
traffic on primary CT1 LSPs and up to BCbu worth of Voice Traffic on
backup LSPs.
Vasseur, Le Roux et al. Expires December 2004 [Page 24]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
The size of the backup pool BCbu is configured on all links such that
the CT1 LSP QoS objectives are met when there is simultaneously, on
that link, up to BC1 worth of primary LSPs and up to BCbu worth of
backup CT1 traffic.
Notes
- If the objective for CT1 traffic is only to protect CT1
bandwidth then the network administrator must just make sure that:
BC1+BCbu<Link Speed. If the objective is also to guarantee low jitter
for CT1 traffic, one may desire to make sure that BC1+BCbu<U*Link
Speed where U<1. Also as discussed below, the scheduling must be set
appropriately.
- If BCbu+BC0>Link Speed, CT0 traffic may experiment congestion
during failure but CT1 traffic is still bandwidth-protected.
Other scenarios can be addressed with a single bandwidth pool. This
includes the case where all Class-Types need bandwidth protection but
it is acceptable to relax delay guarantee to these classes during the
failure and only offer bandwidth protection. Operations is very
similar to the previous scenario described (e.g. size bypass tunnel
based on BC0), the only difference is that QoS objectives other than
bandwidth guarantee of other CTs than CT0 are not necessarily
guaranteed to be preserved during failure. These CTs only get
bandwidth assurances.
9.2. Multiple backup pools
When DS-TE is used and multiple Class-Types are supported, the
operations described above can be easily extended to multiple
bandwidth pools in the case where backup LSPs are sized based on the
actual amount of established LSPs: one backup pool can be used to
separately constrain the bandwidth used by backup LSPs of each Class-
Type. In that case, each CT can be given bandwidth protection during
failure with guarantee that each CT will also meet all its respective
QoS objectives during the failure and without any bandwidth wastage.
Here is an example of such scenario. Let's consider the following
network where:
- DS-TE and the Russian Dolls bandwidth constraint model are used
- two Class-Types (CTs) are used:
o CT1 is used for Voice Traffic
o CT0 is used for Data traffic
From a bandwidth protection perspective, let's assume that:
- Voice traffic (i.e. CT1 LSPs) needs Bandwidth Protection during
failure
- Data traffic (i.e. CT0 LSPs) also needs Bandwidth Protection
during failure.
Let's further assume that the network administrator has elected to
Vasseur, Le Roux et al. Expires December 2004 [Page 25]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
specify bandwidth requirements for bypass tunnels based on the actual
amount of established primary LSPs requiring bandwidth protection (as
opposed to the full bandwidth pool of primary tunnels as configured
towards the protected facility).
Then, for every link the network administrator will configure:
- BC0, the Bandwidth Constraint on the aggregate across all
primary LSPs (CT0+CT1)
- BC1, the Bandwidth Constraint for primary CT1 LSPs
- BCbu0, the Bandwidth Constraint on the aggregate across all
backup LSPs (CT0+CT1)
- BCbu1, the Bandwidth Constraint on the CT1 backup LSPs
The bandwidth requirement of each CT0 backup LSP is configured based
on the actual amount of established CT0 primary LSPs it protects. The
bandwidth requirement of each CT1 backup LSP is configured based on
the actual amount of established CT1 primary LSPs it protects.
Purely for illustration purposes, the diagram below represents these
bandwidth constraints in a pictorial manner.
I--------------------------------------I--------------------I
I--------------I I----------I I
I CT1 I I CT1 I I
I Primary I I Backup I I
I--------------I I----------I I
I CT1 + CT0 Primary I CT1+CT0 Backup I
I--------------------------------------I--------------------I
I-----BC1------> I--BCbu1-->
I----------------------------BC0------>I-------BCbu0------->
The size of the backup pool BCbu0 is configured on all links such
that the CT0 LSP QoS objectives are met when there is simultaneously,
on that link, up to BC0 worth of CT0 primary LSPs and up to BCbu0
worth of backup CT0 traffic.
The size of the backup pool BCbu1 is configured on all links such
that the CT1 LSP QoS objectives are met when there is simultaneously,
on that link, up to BC1 worth of CT1 primary LSPs and up to BCbu1
worth of backup CT1 traffic.
In the case where backup LSPs are sized based on the amount of
reservable bandwidth, it is also possible to extend operations to
multiple bandwidth pools in the same way, but this may result in
bandwidth wastage. This is because BC1 will be effectively reserved
both from BC1bu and from BC0bu (with the RDM model).
Operations with multiple backup pools, as well as operations with the
Maximum Allocation Model [MAM]), will be discussed in more details in
subsequent versions of this draft.
Vasseur, Le Roux et al. Expires December 2004 [Page 26]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
10. Interaction with scheduling
The bandwidth protection approach described in this document does not
require any enhancement or modification to MPLS scheduling mechanisms
beyond those defined in [MPLS-DIFF]. In particular, scheduling can
remain entirely unaware of Fast Reroute and bandwidth protection; in
particular this approach does not require that scheduling behave
differently depending on whether a packet is transported on a primary
LSP or a backup LSP, nor does it require per-LSP scheduling.
This approach simply requires that the existing MPLS scheduling
mechanisms (e.g. Diff-Serv PHBs) are configured in a manner which is
compatible with the goal of bandwidth protection, because while the
bandwidth protection allocates bandwidth appropriately in the control
plane, it is scheduling which is responsible for the actual
enforcement in the data path of the corresponding service rates to
packets in a way which will achieve the targeted bandwidth
protection.
The details of which configuration is appropriate depends on multiple
parameters such as the details of the Diff-Serv policy, the bandwidth
protection policy and the number of DS-TE Class-Types supported.
Thus, it is outside the scope of this draft.
For illustration purpose, the uniform Diff-Serv tunneling mode
defined in section 2.6 of [MPLS-DIFF] may be used on the bypass
tunnels, for bandwidth protected LSPs. In particular, when a packet
is steered into a bypass tunnel by the PLR (i.e. when the bypass
tunnel label entry is pushed onto the packet) the EXP field of the
packet is copied into the EXP field of the bypass tunnel label entry.
In the particular case where the PLR could not establish a bypass
tunnel with the full requested amount of bandwidth (due to some lack
of bandwidth in the backup pool) and instead established a bypass
tunnel with a smaller bandwidth, when rerouting LSPs onto this bypass
tunnel, the PLR may ensure that the amount of rerouted primary LSPs
complies with the actual bandwidth of the bypass tunnel. This can
done using the same bypass tunnel (or a separate bypass tunnel) with
the pipe DiffServ tunneling mode for the non bandwidth protected
primary rerouted TE LSPs (this both includes the set of TE LSPs not
requiring bandwidth protection and the set of TE LSP that have
required bandwidth protection but for which there was not enough
backup bandwidth on the bypass tunnel to accommodate their request).
Otherwise, this would simply violate bandwidth protection (for
traffic on this bypass tunnel as well as for all traffic on any LSP
using the same PHBs) because more traffic than reserved for would end
up in the bypass tunnel.
Vasseur, Le Roux et al. Expires December 2004 [Page 27]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
11. PLR-PCE Signaling: Functional description
A LSR-PCE signaling protocol is required for PLR-PCE communication.
The PLR will have to send a request to the PCE, for the computation
of a bypass path. Such request will be characterized by the
specification of several parameters that are discussed bellow.
11.1. Element to protect
The PLR specifies the element to protect: Link, Node, SRLG or SDLG.
Typically, a link protection request will result in a set of NHOP
bypass tunnels as a node protection request will result in a set of
NNHOP bypass tunnels.
11.2. Bandwidth to protect
There are two different approaches for the bandwidth-to-protect
parameter:
- The bypass tunnel bandwidth may be based on the amount of
reservable bandwidth pool on a particular network resource,
- The bypass tunnel bandwidth may be based on the sum of
bandwidths actually reserved by established TE LSPs requiring
bandwidth protection on a particular resource.
11.3. Affinities
The requesting node may also specify affinities constraint.
Affinities for the bypass tunnel may be configured on the PLR by the
network administrator or derived from the FAST-REROUTE object of the
protected TE LSP, if used. In this former case, this would require
some rules to derive the affinities of the bypass tunnel from the
affinities of the protected TE LSPs making use of this bypass tunnel.
11.4. Maximum number of bypass tunnels
It may happen that no single bypass tunnel can fulfil the constraints
requirements. In such a situation, a set of bypass tunnels could be
computed such that the sum of the bandwidths of every element in the
set is at least equal to the required bandwidth. It may be desirable
to bound the number of elements in this set by specifying a maximum
number of bypass tunnels originating at a PLR and protecting an
element.
11.5. Minimum bandwidth on any element of a set of bypass tunnels
When a solution can be found with a set of bypass tunnels it may also
Vasseur, Le Roux et al. Expires December 2004 [Page 28]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
be desirable to provide some constraint on the minimal bandwidth
value for any bypass tunnel in the set. As an example, if a 100M
bypass tunnel is required, a set of 1000 tunnels each having 100K is
likely to be unacceptable. Also, it is worth reminding that a single
protected TE LSP will make use of a single bypass tunnel at a given
time.
11.6. Class Type to protect
Specifies the Class-Type(s) to protect. See section 9 on operations
with DS-TE.
11.7. Set of already in place bypass tunnels
In certain circumstances (stateless PCE), it may also be useful for
the PLR to provide to the PCE the set of already in place bypass
tunnels with their corresponding constraints for the PCE to try to
minimize the incremental changes of the existing bypass tunnels due
to the placement of new bypass tunnels.
12. Bypass tunnel - Make before break
In case of bypass tunnel path change, the new bypass tunnel may be
set up using make before break. This may or not be possible depending
on the change in the set of bypass tunnels.
13. Stateless versus Statefull PCE
There are basically two options for the PCE:
- can be statefull: the PCE registers the various bypass
tunnels computation requests and results. It will also monitor the
network states (bypass tunnels in place, ...)
- can be stateless: the PCE does not maintain any state. This
approach is the recommended approach for the distributed model.
14. Packing algorithm
Once the set of bypass tunnels is in place and their respective
bandwidth, the PLR should, for each protected TE LSP successfully
signaled, select a corresponding bypass tunnel. As per defined in
[FAST-REROUTE], the bandwidth protection requirement for the
protected LSP can be specified using the FAST-REROUTE object or by
setting the ''Bandwidth protection desired'' bit in the SESSION-
ATTRIBUTE of the Path message. Based on the signaled backup bandwidth
requirement for the protected LSP, the PLR should appropriately
select the bypass tunnel to use for the protected TE LSP, making sure
the requested backup bandwidth requirement is met.
Vasseur, Le Roux et al. Expires December 2004 [Page 29]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
15. Security Considerations
The practice described in this draft does not raise specific security
issues beyond those of existing TE.
16. Acknowledgements
The authors would like to thank Carol Iturralde, Rog Goguen, Vishal
Sharma, Shahram Davari and Renaud Moignard for their useful comments
in a former version of this draft.
17. Security Considerations
No new security issues are raised in this document.
18. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org..
18.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Vasseur, Le Roux et al. Expires December 2004 [Page 30]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
19. References
Normative references
[RFC] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[TE-REQ] Awduche et al, Requirements for Traffic Engineering over
MPLS, RFC2702, September 1999.
Informative Reference
[FAST-REROUTE] Pan, P. et al., "Fast Reroute Techniques in RSVP-TE",
Internet Draft, draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, work in
progress
[BP-PLACEMENT] Le Roux, J.L., Calvignac, G., "A method for an
Optimized Online Placement of MPLS Bypass Tunnels", draft-leroux-
mpls-bypass-placement-00.txt, February 2002.
[KINI] Kini et al, "Shared Backup Label Switched Path Restoration",
draft-kini-restoration-shared-backup-01.txt, May 2001.
[MPLS-DIFF] Le Faucheur et al, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May 2002.
[RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints Model
for Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff-
te-russian-06.txt, work in progress.
[MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth
Constraints Model for Diff-Serv-aware MPLS Traffic Engineering" ,
draft-ietf-tewg-diff-te-mam-03.txt, work in progress.
[LINKNODE-FAILURE] Vasseur, Charny, "Distinguish a link from a node
failure using RSVP Hellos extensions", draft-vasseur-mpls-linknode-
failure-00.txt, November 2002.
[RFC3469] Sharma V., et al, "Framework for Multi-Protocol Label
Switching (MPLS)-based Recovery", Feb 2003.
Vasseur, Le Roux et al. Expires December 2004 [Page 31]
Internet Draft draft-leroux-pce-backup-comp-frwk-00 July 2004
20. Authors' Address:
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Anna Charny
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: acharny@cisco.com
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
FRANCE
Email: flefauch@cisco.com
Javier Achirica
Telefonica Data Espana
Beatriz de Bobadilla, 14
28040 Madrid
SPAIN
Email: javier.achirica@telefonica-data.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
E-mail: jeanlouis.leroux@francetelecom.com
Full Copyright Statement
"Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Vasseur, Le Roux et al. Expires December 2004 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:55 |