Network Working Group JL. Le Roux
Internet Draft France Telecom R&D
Expiration Date: August 2002
G. Calvignac
France Telecom R&D
February 2002
A method for an Optimized Online Placement of MPLS Bypass Tunnels
draft-leroux-mpls-bypass-placement-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 [1].
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.
Abstract
The present document focuses on the MPLS Fast Reroute many-to-one
solution. It defines on the one hand, a specific PLR behavior for the
dynamic setup of bypass LSPs, and on the other hand a distributed
bypass LSP path computation mechanism, taking into account the
possibility to share protection resources.
It proposes ISIS-TE/OSPF-TE and RSVP-TE extensions required to
support the described functionality.
Le Roux et al. Expires August 2002 [Page 1]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
Table of Contents
1. Introduction................................................3
1.1. Abbreviations...............................................4
2. Definitions.................................................4
3. Solution overview...........................................5
4. Dynamic bypass tunnel setup.................................7
4.1. SESSION_ATTRIBUTE parameters................................8
4.2. Bandwidth protection........................................8
4.3. Bypass LSP properties.......................................9
4.3.1. Bypass bandwidth............................................9
4.3.2. Bypass priority............................................10
4.3.3. Parallel links.............................................10
4.4. Dynamic bypass creation on PLRs............................11
4.4.1. PLR behavior...............................................11
4.4.2. Example....................................................13
5. Protection bandwidth: Definition, sharing and accounting...14
5.1. Protection bandwidth pool..................................14
5.2. Protection Resource Sharing principle: PRS.................14
5.3. SRLG information...........................................15
5.4. Failure Risks: FR..........................................17
5.4.1. Protected Failure Risk Group of a Bypass LSP: PFRG(B)......17
5.4.2. Protected Failure Risk Group on a link: PFRG(L)............18
5.4.3. Protection Bandwidth on a link L, for a Failure Risk F:
PB(L, F).................................................18
5.4.4. Example....................................................19
5.5. PRS-aware accounting of reserved protection bandwidth......20
5.6. PRS-aware bypass admission control on a link...............21
6. PRS-aware online bypass path computation...................22
7. Routing extensions for PRS-aware bypass path computation...24
7.1. New TE link parameters for protection......................24
7.1.1. Protection bandwidth.......................................24
7.1.2. SRLG.......................................................25
7.2. Bypass advertisement.......................................26
7.2.1. Tail Router ID sub-TLV.....................................26
7.2.2. Path sub-TLV...............................................27
7.2.3. Bypass Information sub-TLV.................................27
7.3. PLR processing.............................................28
7.4. Bypass database............................................29
8. RSVP-TE extensions for bypass LSPs setup...................29
8.1. Bypass object..............................................29
8.2. Processing of the Bypass Object............................31
9. Security Considerations....................................31
10. Intellectual property consideration........................31
11. Acknowledgment.............................................31
12. References.................................................32
13. Authors Information........................................32
Le Roux et al. Expires August 2002 [Page 2]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
1. Introduction
MPLS local protection consists in establishing, locally, backup LSPs
to protect against link or node failure. Backup LSPs start at a point
of local repair (PLR) and end at a merge point (MP). In case of
failure on the protected node or link, the PLR splices the traffic
onto the corresponding backup LSPs.
[FRR] proposes two main solutions for the local protection of TE
LSPs, the one-to-one solution, which consists in establishing one
"detour" LSP per primary LSP to be locally repaired, and the many-to-
one solution, which allows the protection of many LSPs by the same
"bypass" LSP using LSP nesting technique.
The solution here is based on the many-to-one scheme, i.e. on bypass
LSPs.
Several options are mentioned in [FRR] for the creation and placement
of bypass LSPs:
-They can be setup initially or dynamically.
-Their path can be statically configured on each PLR, it can be
computed by an offline tool, or it can also be computed online
by PLRs.
This document focuses, firstly on the dynamic setup of bypass LSPs,
and secondly on an online bypass path computation by PLRs.
A specific PLR behavior is proposed for dynamic setup of bypass LSPs,
triggered by LSPs requiring local repair.
A distributed bypass path computation algorithm is proposed, which
takes into account the possibility to share protection resources.
This requires several routing and signalling extensions, which are
proposed at the end of the document.
The main characteristics of the proposed solution are:
-Scalability, as it is based on the many-to-one scheme.
-Automaticity, as it does not require manual intervention to
configure bypass LSPs on each PLR.
-Distributed computation, as it does not require a centralized
server.
-Optimisation, as it proposes a path computation taking
into account protection resource sharing, PRS.
Le Roux et al. Expires August 2002 [Page 3]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
1.1. Abbreviations
BAC Bypass Admission Control
BEB Best Effort Bypass
PB Protection Bandwidth on a link, for a failure risk.
BPB Bandwidth Protection Bypass
BPD Bandwidth Protection Desired
BPU Bandwidth Protection Undesired.
CSPF Constraint-based Shortest Path First algorithm
FR Failure Risk
LPD Local Protection Desired
LSP Label Switched Path
LSR Label Switching Router
MP Merge Point
MRPbw Maximum Reservable Protection bandwidth
NHOP Next Hop
NPD Node Protection Desired
NNHOP Next Next Hop
PFRG Protected Failure Risk Group of a link or bypass LSP.
PLR Point of Local Repair
PRS Protection Resource Sharing
RPbw Protection Bandwidth Reserved on a link
RRO RSVP Record-Route Object
SAO RSVP Session_Attribute Object
SRLG Shared Risk Link Group
TE Traffic Engineering
2. Definitions
This document is in full conformance with the sections of [FRR]
defining the bypass mechanisms for the many-to-one solution. This
document only proposes several extensions for the purpose of an
online bypass path computation taking into account protection
resources sharing.
A bypass tunnel is an LSP, which is used to protect a downstream link
or node. Many primary LSPs can use the bypass facility in case of
failure, using LSP nesting principle.
RSVP-TE extensions (mainly SAO and RRO) and specific processing for
bypass tunnels utilisation are defined in [FRR]. This document is in
full conformance with these extensions.
The PLR (Point of Local Repair) is the bypass head-end node. It
splices traffic on the bypass LSP in case of failure.
The MP (Merge Point) is the bypass tail-end node. On this point,
backup LSPs are merged into corresponding primary LSPs.
Two types of bypass tunnels are defined in [FRR], regarding the
entities they protect:
Le Roux et al. Expires August 2002 [Page 4]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
-A link protection bypass tunnel (also called NHOP bypass
tunnel) protects against failures occurring on a downstream link
connecting a PLR and a PLR next-hop node. The head end is the PLR and
the tail-end is the PLR next hop. It may be used, in case of failure,
by primary LSPs using the downstream link.
-A node protection bypass tunnel (also called NNHOP bypass
tunnel) protects against several failures occurring on a downstream
node. The head end is a PLR, the tail end is a PLR next-next-hop. It
may be used, in case of failure by primary LSP whose path includes
the PLR->PLR_NHOP->PLR_NNHOP trunk.
Note that node protection implies also protection of the downstream
link PLR->PLR_NHOP.
This document does not modify basic bypass mechanisms.
3. Solution overview
Firstly, in 4, we propose a specific PLR behavior and several rules,
for dynamic setup of bypass LSPs, triggered by primary LSPs requiring
local protection.
Basically, it consists in setting up bypass tunnels dynamically and
mutualizing the bypass tunnels as much as possible, for the
particular entity (node/link) to be protected: In case a new primary
LSP requiring local protection is being established, if a bypass
tunnel already exists then use that one as long as there is enough
bandwidth left on the links it goes through, and increment the
bandwidth of this bypass tunnel (if bandwidth protection is desired).
If there is no bypass tunnel, or no available bandwidth on existing
bypass paths, then compute and establish a new bypass tunnel, which
handles the local protection requirement. The bandwidth of the new
bypass should be equal to the primary LSP bandwidth if bandwidth
protection is desired, if not then it should be 0.
Note that two types of bypass LSPs are distinguished: Bypass LSPs
which reserve protection resources (ie bw>0), called Bandwidth
Protection Bypass, and bypass LSPs which do not reserve protection
resources (ie bw=0), called Best Effort Bypass.
The second part of the document (section 5,6,7 and 8) focuses on a
distributed solution for Protection Resource Sharing, PRS. It is not
relevant for Best Effort Bypass LSPs, which do not reserve protection
resources.
The main concept behind this is that, in most cases, failures will
impact a single entity (node/link/SRLG) at a time. Therefore
protection resources can possibly be shared between bypass tunnels
protecting different entities, since in case of failure, only the
bypass tunnels, which will actually be used by the impacted protected
LSP, will make use of the protection resource.
Le Roux et al. Expires August 2002 [Page 5]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
Here we propose a PRS-aware online bypass path computation mechanism,
and a PRS-aware bypass local admission control. It requires several
routing and signalling extensions.
In 5, we define a new protection bandwidth pool dedicated to bypass
LSPs.
Two new link parameters are defined: The Maximum Reservable
Protection bandwidth, MRPbw, and the Reserved Protection bandwidth,
RPbw. The reserved protection bandwidth can be expressed as the
highest cumulated bandwidth of bypass tunnels that could be active at
the same time in case of failure.
An algorithm is then proposed for the accounting of reserved
protection bandwidth. Based on this algorithm we define a PRS-aware
admission control on links, for bypass tunnels. This admission
control requires having knowledge of all bypass tunnels that goes
through a link, and the entities they are protecting.
In 6, we propose a PRS-aware CSPF for bypass path computation by
PLRs.
It consists in modifying classical CSPF to take into account PRS.
Basically a PRS-aware admission control must be performed on all
candidate links for the path. Links that do not support the required
protection bandwidth must be pruned from topology.
To perform this PRS-aware admission control on a link, the PLR must
have knowledge of all bypass LSPs that are already established on the
link, and the entities they are protecting. Thus, a LSR has to have
knowledge of the whole bypass topology. Routing extensions are
required to advertise the whole bypass topology.
In 7, we propose extensions to ISIS-TE/OSPF-TE to support PRS-aware
online bypass path computation.
A new sub-TLV is defined to advertise the Maximum Reservable
Protection Bandwidth on a link. It must be included in the ISIS-TE IS
reachability TLV, and OSPF-TE Link TLV, to support the proposed
functionality.
A new TLV is defined to advertise a bypass LSP attached on a given
PLR, and its properties (path, bandwidth, protected link, protected
node).
To support the proposed functionality, it may be included in the ISIS
LSP and in the OSPF TE-LSA.
This new TLV enables to distribute the whole bypass topology. The
information may be used by LSRs to maintain a bypass database that
will be used during bypass path computation to verify if protection
resource can be shared.
In 8, we propose an RSVP-TE extension for bypass LSP setup. The local
admission control of bypass LSPs requires the knowledge of the entity
they are protecting. A new object is defined, to advertise that an
LSP is a bypass LSP, and to specify the entities it is protecting. To
support the proposed functionality, it must be included in the path
message corresponding to a bypass LSP.
Le Roux et al. Expires August 2002 [Page 6]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
4. Dynamic bypass tunnel setup
Bypass tunnels can be pre-established, but this requires a
centralized server or a manual intervention at each node.
Another option, that minimizes operational costs, is a dynamic bypass
path computation by PLR, triggered by an LSP requiring protection.
Note this dynamic bypass creation is mentioned in [FRR] (bypass
section), and we intend here to specify more precisely a possible PLR
behavior.
In this section we just focus on the triggering mechanism.
In 5 and 6 we will propose a distributed protection resources sharing
mechanism, and, in 7 and 8, the required routing and signalling
extensions.
Basically, the triggering mechanism is the following:
When a primary LSP is established with local repair required, each
transit LSR on the primary path must check if there is already a
bypass tunnel that can address the required protection (link or node,
bandwidth). If a bypass is found, its bandwidth may be updated
depending on the protection bandwidth required by the primary LSP.
This bypass will be used by the primary LSP in case of failure.
If there is no such bypass available, transit LSRs try to compute and
establish a new bypass tunnel addressing constraints, which may be
subsequently reused to protect other primary LSPs. Note that the
bandwidth of this new bypass must be initially equal to the bandwidth
of the triggering LSP, if bandwidth protection is required, or else
0.
Note that two types of bypass LSPs are distinguished: Bypass LSPs
that ensure bandwidth protection, and Bypass LSPs that do not ensure
bandwidth protection.
When a primary LSP is torn down, bandwidth of bypass tunnels
protecting this LSP may be decremented. Bypass tunnels that were
protecting only this LSP may also be torn down.
It MUST be possible to deactivate, by configuration, dynamic bypass
creation on a node, if the network administrator does not want this
node to establish bypass tunnels. In that case, the node must ignore
local repair request.
Le Roux et al. Expires August 2002 [Page 7]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
4.1. SESSION_ATTRIBUTE parameters
All information concerning the desired protection for an LSP is
included in the RSVP SESSION_ATTRIBUTE Object (SAO).
The head-end LSR can specify the desired protection (Link or Node
protection, Bandwidth protection) by setting the appropriate flags in
the SAO.
- The local protection desired bit (LPD) indicates, if set, that
transit LSR may protect this LSP using a bypass tunnel.
- The node protection desired bit (NPD) indicates, if set, that
NNHOP bypass tunnels should be used to protect this LSPs (except the
penultimate hop).
- The bandwidth protection desired bit (BPD) indicates, if set,
that the bypass tunnel should offer to the protected LSP, an
equivalent bandwidth.
These parameters are specified in detail in [FRR] (many-to-one
section).
Note that BPD bit should not be set if LSP bandwidth is zero.
Notation:
A BPD LSP is an LSP with bandwidth protection desired.
A BPU (Undesired) LSP is an LSP without bandwidth protection desired.
4.2. Bandwidth protection
In section 4 of [FRR], it is mentioned the possibility to maintain
protected LSP bandwidth after failure. This is called bandwidth
protection.
So there are to types of protected LSPs:
-Bandwidth protected LSPs
-Bandwidth unprotected LSPs.
These two types of LSPs must be protected by distinct bypass LSPs.
So we define two types of bypass LSPs:
-Bypass LSPs that ensure bandwidth protection. They are called
Bandwidth Protection Bypass (BPB).
-Bypass LSPs that do not ensure bandwidth protection. They are
called Best Effort Bypass (BEB).
Bandwidth protection bypass LSPs should protect only BPD LSPs.
Best Effort bypass LSPs should protect BPU LSPs, and also BPD LSPs
whose bandwidth protection request can't be enforced.
Le Roux et al. Expires August 2002 [Page 8]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
The only parameter that distinguishes these two types of bypass LSPs
is their bandwidth.
-Bandwidth of BPB must be equal to the cumulated bandwidth of
LSPs that they protect. They reserve protection resources
(bw(BPB)>0).
-Bandwidth of BEB must be zero. They do not reserve
protection resources (bw(BEB) = 0).
In the rest of the document we don't make distinction between these
two types. We only deal with "bypass LSPs". BEB are only a particular
case of bypass LSP, with zero bandwidth.
Example: Let's assume that 3 LSPs require NHOP local repair, for the
same link, on the same PLR:
-LSP 1: bw 50M, BPD.
-LSP 2: bw 30M, BPU.
-LSP 3: bw 40M, BPU.
Two bypass tunnels are required to ensure the protection:
A bypass LSP with bandwidth 50M, to protect LSP1.
A bypass LSP with bandwidth 0, to protect LSP 2 and 3.
Note that this is obviously not sufficient to ensure bandwidth
protection. A DiffServ mechanism could be used to differentiate BEB
and BPB, and to ensure bandwidth guaranties to BPB.
4.3. Bypass LSP properties
4.3.1. Bypass bandwidth
The bandwidth of a bypass LSP must be signalled as a classical LSP in
the RSVP Sender_Tspec and Flow_Spec objects.
As mentioned previously,
-bw(BPB)= sum (bw( protected LSPs)) > 0
-bw(BEB)= 0.
As explained latter in the document, a new bandwidth pool, the link
protection bandwidth, is defined for bypass LSPs (see 5.1).
So there is a distinct admission control for primary and bypass LSPs.
Thus primary and bypass LSP must be distinguished in signaling. A new
RSVP object is defined in 8, for the setup of bypass LSPs. It is used
to indicate that an LSP is a bypass LSP, and specific bypass
properties.
Le Roux et al. Expires August 2002 [Page 9]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
4.3.2. Bypass priority
In this first specification, pre-emption of bypass LSPs is not
supported. All bypass LSPs have the same priorities (7,7) whatever
the priorities of the primary LSPs they are protecting may be.
Note that primary LSPs and bypass LSPs work on two separate bandwidth
pools (see 5.1). Thus there is no competition between them.
4.3.3. Parallel links
For a better protection resource sharing (see section 5), it's better
to isolate failure risk, so we defines the following rules:
-A NHOP bypass is protecting only one downstream link.
-A NNHOP bypass is protecting only one couple (downstream link,
downstream node).
---------------
| |
| | figure 1
|----|1--------|----| |----|
| A |2--------| B |--------| C |
|----|3--------|----| |----|
| |
|----------------------------|
So, for instance, on figure 1:
A NHOP bypass LSP, B1, is established from A to B, to protect link
A1->B. It can be used only to protect LSPs going through A1->B. Other
NHOP bypass LSPs must be setup to protect LSPs going through A2->B or
A3->B.
A NNHOP bypass LSP B2 is established from A to C to protect (link A2-
>B, node B). It can be used only by LSPs going through A2->B->C.
Other NNHOP bypass LSPS must be setup to protect LSPs going through
A1->B->C and A2->B->C.
There is a lost in terms of scalability. The reason for these rules
is a better protection resources sharing by isolating failures as
much as possible. Note that a trade-off must be found between high
scalability and protection resource sharing.
Le Roux et al. Expires August 2002 [Page 10]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
4.4. Dynamic bypass creation on PLRs
4.4.1. PLR behavior
The mechanism proposed here consists in an automatic bypass
establishment, triggered by primary LSP requiring protection.
It must be possible to Activate/Deactivate this triggering on an LSR,
by configuration, globally or on a specific interface.
We define distinct processing, for PBD and PBU LSP. When there is not
enough protection bandwidth to protect a PBD LSP, it may be handled
as a PBU LSP.
-PBD LSP processing:
When an LSR receives a Resv message for an LSP l, desiring local
protection, and also bandwidth protection, it must performs the
following tasks:
1- Check among its bandwidth protection bypass LSPs (ie bypass
LSPs with bw > 0) already established, if there are candidates
to protect l.
A candidate bypass tunnel, in case of link protection, is a
tunnel which protects l downstream link and whose tail-end is l
next-hop. In case of node protection, it's a tunnel which
protects l downstream link, l downstream node, and whose tail-
end is l next-next hop.
Then remove from the candidate list, bypass LSPs whose path
cannot address the required protection bandwidth. For this, for
each candidate bypass tunnel B, check if all the links along the
path of B can support the bandwidth increment bw(B)+bw(l). A
mechanism to perform these protection resources verifications is
proposed in section 5, and more particularly in section 5.6.
2- If there are still one or more candidate bypass LSPs, then
select one of them, B, and, modify bw(B) by a make-before-break
mechanism (bw(B)=bw(B)+ bw(l)). Then update the protection
database (i.e. map l to B).
3- If there is no candidate bypass LSP, and if bypass triggering
is activated globally or on downstream interface of l, then
compute a path for a new bypass tunnel which addresses the
protection required by l (Link or node, bandwidth). If a path is
found, establish the bypass LSP, B, with bw(B)=bw(l) . Then
update the protection database (by mapping l to B).
A mechanism for bypass path computation by PLR is proposed
latter in the document (section 6).
If no path is found, the bandwidth protection request cannot be
addressed by the PLR. The PLR may process the LSP has a PBU
LSP, and try to protect it with a Best Effort bypass LSP.
The PLR may periodically try to recompute and setup a bandwidth
Le Roux et al. Expires August 2002 [Page 11]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
protection bypass LSP.
-PBU LSP processing:
When an LSR receives a Resv message for an LSP l, with local
protection desired, and bandwidth protection not desired it must
performs the following tasks:
1- Check among its best effort bypass LSPs (ie bypass LSPs with
bw = 0), already established, candidates to protect l.
2- If there are candidates, then select one of them, B, and
update the protection database (by mapping l to B)
3-If there are no candidate then compute a bypass path with
bandwidth zero. If a path is found, establish bypass B, and
update protection database (by mapping l to B). If no path is
found then the local repair request can't be ensured. The LSR
may try periodically to find a path.
Each transit LSR must then update the RRO with the result of the
process: Local Protection available or not, bandwidth protection
available or not (RRO).
When the PLR computes a new bandwidth protection bypass path, or
checks if there is available protection bandwidth on the existing
bypass links to protect a supplementary primary LSP, it must also
take into consideration the possibility to share bandwidth with other
bypass tunnels which go through the same links, but protect different
nodes/links and thus may not be active at the same time. Indeed, if
two bypass tunnels B1 and B2 go through a common link L and protect
distinct links that are SRLG diverse, or distinct nodes, in case of
node protection, (this means that they will not be active at the same
time), they can share bandwidth. The protection bandwidth reserved on
L (RPbw(L)) must then be equal to RPbw(L)=Max(bw(B1), bw(B2)), in the
particular case of only two bypass tunnels going over L.
To perform these controls, the PLR must be aware of all bypass
tunnels that go through a link, their bandwidth, and the entity
(link, node), they are protecting.
Mechanisms for bypass local admission control and bypass path
computation, taking into account sharing of protection resources are
defined in 5, 6 and the required routing/signalling extensions in 7,
8.
Le Roux et al. Expires August 2002 [Page 12]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
4.4.2. Example
Figure 2
[A]-----[B]-----[C]-----[D]
| | | |
[E]-----[F]-----[G]-----[H]
| | | |
[I]-----[J]-----[K]-----[L]
Let's assume, that a new bandwidth pool, dedicated to protection
(protection bandwidth), is configurable on each link and that bypass
tunnel bandwidth reservation is performed on this protection
bandwidth pool (see section 5.1 ).
On all links the Max reservable Protection Bandwidth is set to 10M.
Initially, no bypass tunnels are established. Bypass triggering is
activated only on nodes F, G and K.
A 5M LSP is established from E to H through F and G with local
protection and bandwidth protection desired, and node protection not
desired. F and G determine that here is not already a bypass tunnel
protecting respectively links F->G and G->H. They compute a path for
a bypass tunnel, respectively B1 and B2, with bandwidth 5M according
to primary bandwidth. The paths computed are respectively F->B->C->G
and G->C->D->H. The RRO received on E indicates that local protection
and bandwidth protection are available only on F and G. The reserved
protection bandwidth on links F->B, B->C, C->G , G->C, C->D, D->H is
now 5M.
A second LSP is established from I to H through J, K and G. Its
bandwidth is 3M.
The existing bypass B2, G->C->D->H, is a candidate bypass to protect
this LSP. G checks if there is enough bandwidth on links G->C, C->D
and D->H. It is the case, and bw(B2) is updated to 8M, using make-
before-break. Note that there is no new RSVP session; this is a big
advantage of the many-to-one solution.
In return on K there is not yet a bypass tunnel to protect K->G. K
computes and establishes a bypass B3, with bandwidth 3M from K to G
through J and F. The protection bandwidth reserved on links K->J, J-
>F, F->G is now 3M.
Le Roux et al. Expires August 2002 [Page 13]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
5. Protection bandwidth: Definition, sharing and accounting
5.1. Protection bandwidth pool
For good protection resources optimization and sharing, it is
convenient to split the link resources into two pools: A primary
bandwidth, which can be used by primary LSPs (it corresponds to
classical TE bandwidth), and a protection bandwidth, which is used by
bypass LSPs.
This new resource pool must be advertised by IGP-TE protocols, as an
additive TE parameter. In fact two parameters must be advertised:
- The maximum reservable protection bandwidth (MRPbw),
- The reserved protection bandwidth (RPbw).
These extensions are described in section 7.
Note that these values have unidirectional meaning, as classical TE
bw. Links A->B and B->A may have distinct values, depending on bypass
tunnels established through A->B and B->A and on configuration (for
the max value).
Bypass tunnels cannot be pre-empted, so only one value is advertised
in IGP (not a value at each priority level).
Note that protection bandwidth may be used by low priority LSPs that
are pre-empted in case of failure on protected LSPs. This requires
signaling extensions that are out of the scope of this document.
Note that Best Effort Bypass LSPs do not reserve protection
bandwidth. So all the following is relevant only for Bandwidth
Protection bypass tunnels, ie bypass LSPs that reserve protection
bandwidth.
5.2. Protection Resource Sharing principle: PRS
There are different ways to count the protection bandwidth reserved
on a link. The easiest way consists in adding the bandwidth reserved
by each bypass tunnel. But this will result rapidly in the saturation
of protection bandwidth.
Example with figure 2:
Let's assume that MRPbw is 0 on C->B, and 10M on all other links.
A NNHOP bypass B1, B->C->G->K->J is already established, protecting
node F with bandwidth 8M. So reserved protection bandwidth on B->C,
C->G, G->K and K->J is 8M.
Le Roux et al. Expires August 2002 [Page 14]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
D wants to establish a NHOP bypass, B2, to H, protecting link D-H,
with bandwidth 3M. B2 cannot use C->B, in so far as there is no
protection bandwidth on C->B. If C->G is used, reserved protection
bandwidth on this link would become: bw(B1)+bw(B2)= 11M. So C->G
cannot be used by B2, and there is no solution for this bypass.
In fact, if we assume a single point of failure in a network, and if
B-F and D-H do not share a common resource (fiber, DXC, OXC) then B2
could use link C->G, because both bypass tunnels will never be active
at the same time. Indeed, in case of failure the protection bandwidth
in use on C->G would be 8M, ie Max(bw(B1), bw(B2)). So B2 path could
be D->C->G->H and the reserved protection bandwidth (RPbw) on C->G,
would remain 8M. This is the concept of protection resource sharing.
But for this mechanism to work, D must be aware of the first bypass
already established, it must know its path, its bandwidth, and also
which link and node this bypass is protecting. This requires
extension to IGP-TE to advertise bypass tunnels, their properties and
the entities they are protecting.
In return, a NNHOP bypass LSP established by G to E, protecting node
F could not share resources on link G->K and K->J, with the first
bypass LSP established by B to J, protecting also F, because in case
of failure of node F both bypass LSPs could be active. Thus for these
two bypass tunnels, bandwidth must be added and not "maximized".
In the following we define some rules for Protection resources
sharing.
5.3. SRLG information
The concept of SRLG is defined in [GMPLS-RTG].
A SRLG is a set of links that share a common resource whose failure
may impact all links in the set. For instance two POS links using the
same fiber belong to the same SRLG. An SRLG is defined by a 32 bit
id, unique to the area. A link can belong to multiple SRLG, so the
SRLG information of a link is a set of SRLG ids the link belongs to.
Two links are said SRLG diverse if their SRLG sets are disjoint. By
extension, two links that do not belong to any SRLG are said to be
SRLG diverse.
This information must be advertised in the routing protocol. If a
link does not belong to any SRLG, no SRLG information is announced.
Note that a node is not considered as a resource for a link. Two
links that start at the same node are not necessarily in the same
SRLG, even if node failure can impact both links at the same time.
Le Roux et al. Expires August 2002 [Page 15]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
The SRLG set of an LSP is a concatenation of SRLG sets of links used
by the LSPs. Two LSPs are said SRLG diverse if their SRLG set are
disjoint.
Example on figure 3:
[R1]
\
[O1] figure 3
|
f1|
|
|
| f2
[R2]-[O2]------[O3]
|
[R3]
3 routers R1, R2, R3 are connected to three OXC O1, O2, O3.
OXC are interconnected by fibers f1 and f2 with WDM.
3 IP links are setup: R1-R2, R1-R3 and R2-R3.
SRLG 1 and 2 are defined by the set of IP links going through fibers
f1 and f2 respectively.
R1-R2 uses the lightpath O1-O2, so its SRLG set is {1}.
R1-R3 uses the lightpath O1-O2-O3, so its SRLG set is {1,2}.
R2-R3 uses the lightpath O2-O3, so its SRLG set is {2}.
Thus R1-R2 and R2-R3 are SRLG diverse. In return R1-R2 and R1, and,
R1-R3 and R2-R3, are not SRLG diverse.
We define a SRLG failure as the failure of the resource shared by all
members of the SRLG. For instance, SRLG 2 failure corresponds to
fiber 2 failure.
A SRLG failure, or more exactly the failure of the shared resource,
may trigger several link failures. For instance, SRLG 3 failure will
trigger links R2-R3 and R1-R3 failures.
In return, a link failure maybe independent from an SRLG failure. For
instance a failure on the link R2-O2, connecting R2 to R3, triggers
R2-R3 failure, and is independent from SRLG 2, indeed R1-R3 does not
fail in that case.
That is the reason why we distinguish link failure from SRLG failure.
A SRLG failure trigger link failures, but a link failure maybe
independent from any SRLG failure, for instance if a link does not
belong to any SRLG!
Le Roux et al. Expires August 2002 [Page 16]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
Note that we can configure a common SRLG on two links, even if there
is no shared resource, if we want to be protected against multiple
points of failure: This is the concept of Virtual SRLG.
Note that the SRLG concept may be extended to nodes. A Shared Risk
Node Group (SRNG) is a set of nodes that share, for instance, the
same building.
This is not supported in this document, but it is the same approach,
and requires only a few extensions to what is described above.
5.4. Failure Risks: FR
For protection bandwidth sharing purpose, it is necessary to identify
the entities whose failure may activate a bypass LSP. Two bypass LSPs
that protect a same entity cannot share protection bandwidth, whereas
bypass LSPs that protect distinct entities can.
We call these entities Failure Risks.
We distinguish three types of FRs: a link, a node, or an SRLG.
A SRLG FR corresponds to the risk of failure of the shared resource.
We need to consider both link and SRLG FRs, to encompass links that
do not belong to any SRLG.
We gives in the following, several definitions, that will be useful
the reserved bandwidth accounting method
5.4.1. Protected Failure Risk Group of a Bypass LSP: PFRG(B)
As mentioned previously, there are two types of bypass tunnels: link
protection and node protection bypass tunnels.
A link protection bypass tunnel (NHOP bypass) starts at a PLR an ends
at the PLR's next-hop. Of course it must not use the link it is
protecting, but it must also be SRLG diverse with the link it is
protecting.
A node protection bypass tunnel (NNHOP bypass) starts at a PLR an
ends at the PLR next-next-hop. It must not use the downstream node
and link it is protecting, and it must also be SRLG diverse with the
downstream link. A NNHOP bypass protects not only the downstream
node, but also the downstream link.
We define the Protected Failure Risk Group of a bypass LSP B, PFRG(B)
as the set of FRs protected by B, i.e. the set of FRs whose failure
will activate B utilisation.
Le Roux et al. Expires August 2002 [Page 17]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
The PFRG of an NHOP bypass tunnel is the concatenation of the
downstream link and its SRLG set.
The PFRG of a NNHOP bypass tunnel is the concatenation of the
downstream node it is protecting, but also, in so far as node
protection encompasses attached link protection, the downstream link,
and its SRLG set.
The three conditions for bypass tunnels to be PFRG diverse are:
1- they do not protect the same link.
2- the link they protect are SRLG diverse.
3- they do not protect the same node (In case of NNHOP).
5.4.2. Protected Failure Risk Group on a link: PFRG(L)
We define the protected Failure Risk group on a link L
(unidirectional meaning), PFRG(L), as the set of FRs that are
protected on the link. It corresponds to the concatenation of PFRG of
bypass LSPs going through the link.
Here "link" has a unidirectional meaning, there is no relationship
between PFRG(I->J) and PFRG(J->I).
5.4.3. Protection Bandwidth on a link L, for a Failure Risk F: PB(L, F)
We define the Protection Bandwidth, on a link L (unidirectional
meaning), for a Failure Risk F, PBR(L, F), as the cumulated bandwidth
of bypass LSPs protecting F, an using L.
PB(L, F)= sum {bw(B)}, over B, where B goes through L and F
belongs to PFRG(B).
This corresponds to the aggregate bandwidth, of bypass LSPs that will
be in use on L in case of failure F.
Le Roux et al. Expires August 2002 [Page 18]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
5.4.4. Example
Let's assume, on figure 2, that B-C belongs to SRLG 1 and 2, and J-K
to SRLG 2.
A NHOP bypass LSP B1 is established by B, to protect B->C, with
bandwidth 10M. It goes through B->F, F->G and G->C.
A NNHOP bypass LSP B2 is established by B to D, protecting node C,
with bandwidth 10M. It goes through B->F, F->G, G->H and H->D.
A NHOP bypass LSP B3 is established by J to L, to protect node K,
with bandwidth 10M. It goes through J->F, F->G, G->H, H->L.
A NNHOP bypass LSP B4 is established by I to K, protecting node J,
with bandwidth 10M. It goes through I->E, E->F, F->G, G->K.
The protected failure risk groups of bypass LSPs are:
PFRG(B1) = {Link B-C, SRLG 1, SRLG 2}.
PFRG(B2) = {Link B-C, Node C, SRLG 1, SRLG 2}.
PFRG(B3) = {Link J-K, Node K, SRLG 2}.
PFRG(B4) = {Link I-J, Node J}.
On link F->G, 4 bypass tunnels are established: B1, B2, B3 and B4.
The PFRG(F->G) is {Link B-C, Link J-K, Link I-J, Node C, Node K, Node
J, SRLG 1, SRLG 2}.
The protection bandwidth on link F->G, are for each protected FR:
PB(F->G, Link B-C)=bw(B1)+bw(B2)=20M.
PB(F->G, Link J-K)=bw(B3)=10M.
PB(F->G, Link I-J)=bw(B4)=10M.
PB(F->G, Node C)=bw(B2)=10M.
PB(F->G, Node K)=bw(B3)=10M.
PB(F->G, Node J)=bw(B4)=10M.
PB(F->G, SRLG 1)=bw(B1)+bw(B2)=20M.
PB(F->G, SRLG 2)=bw(B1)+bw(B2)+bw(B3)=30M.
Le Roux et al. Expires August 2002 [Page 19]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
5.5. PRS-aware accounting of reserved protection bandwidth
We assume in all the following that there are only single points of
failure. That means that only one link or one node or one SRLG fails.
Bandwidth of bypass tunnels and protection bandwidth effectively
reserved on a link must not be confused.
The reserved protection bandwidth on a link L, RPbw(L), is defined as
the highest cumulated bandwidth, of bypass LSPs that could be in use
at the same time.
The basic sharing concept is that bypass tunnels, which are PFRG
diverse can share protection resources.
Let's assume that N bypass tunnels B1, B2, ... BN of bandwidth
bw(B1), bw(B2), ... bw(BN) use the same link L (unidirectional
meaning). How to account the reserved protection bandwidth?
It's quite easy in two particular cases:
1- All bypass LSPs are PFRG diverse:
In that case RPbw(L)=max{bw(B1),
,bw(BN)}.
2- All bypass share at least a common FR:
In that case RPbw(L)=sum{bw(B1),
,bw(BN)}.
In the general case, we have to consider each FR. Indeed, if we go
back to the definition, bypass tunnels that can be active at the same
time are bypass tunnels that protect a same FR, and the cumulated
bandwidth of bypass that share a same FR F on a link L is, as defined
in 5.4.3, the protection bandwidth on L for F, PB(L, F).
So the reserved protection bandwidth on a link L, is the highest PB(
L, F). It can be expressed as following:
RPbw(L) = max {PB(L,F)}, F belonging to PFRG(L).
Example:
In the previous case, we derive the reserved protection bandwidth on
link F->G: 30M
RPbw(F->G)= Max { PB(F->G, Link B-C), PB(F->G, Link J-K), PB(F->G,
Link I-J), PB(F->G, Node C,), PB(F->G, Node K), PB(F->G, Node J),
PB(F->G, SRLG 1), PB(F->G, SRLG 2)} = PB(F->G, SRLG 2)= 30M
Le Roux et al. Expires August 2002 [Page 20]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
5.6. PRS-aware bypass admission control on a link
The admission control of a bypass tunnel B on a link L
(unidirectional meaning) consists in computing the resulting reserved
protection bandwidth RPbw adding B on L. B can use L if the resulting
reserved protection bandwidth on L remains <= Maximum reservable
protection bandwidth on L ( RPbw(L)<= MRPbw(L))
This is similar in concept to a classical TE admission control, but
the main distinction here is that protection bandwidth can be shared
between bypass tunnels.
Admission control example:
Let's assume that the maximum protection bandwidth on link F->G is
50M.
Given the previous configuration, a new NHOP bypass B5 protecting
link F-J (SRLG 1), with bandwidth 30M can use F->G. Indeed RPbw(F->G)
would become 50M.
In return, a new NHOP bypass B6 protecting link B-F (SRLG 2) with
bandwidth 25M cannot use F->G because RPbw(F->G) would become 55M.
Here there is no longer a simple relationship between current
reserved protection bandwidth and resulting reserved protection
bandwidth with a new added bypass LSP. The determination of the
resulting reserved protection bandwidth with a new bypass requires
the knowledge of all current bypass tunnels that are using the link,
and their properties (bypass bandwidth, bypass PFRG).
Thus information required to perform bypass admission control on a
link, is not the reserved protection bandwidth, but all the bypass
tunnels, which are using this link, their bandwidth and PFRG, and
also the maximum reservable bandwidth.
Bypass admission control on links, is performed, distantly, by PLRs,
when computing a bypass path, or checking if existing bypass
bandwidth can be increased, and, locally, by transit LSRs on a bypass
LSP path when handling RSVP Path/Resv messages for bypass setup.
A PLR, which has to compute a bypass path must prune from the
topology all the links, which cannot support the bypass. In other
words, it must perform a bypass admission control on each candidate
link for the path. To perform these controls it must have knowledge
of all bypass LSPs that use a link, and their properties (PFRG, bw).
Links for which bypass admission control fails must be pruned from
the topology database.
Thus, it must have knowledge of all bypass tunnels existing in the
area, in order to verify, if the bypass being computed can share
protection resources on a link, with other existing bypass going
through this link. This requires several IGP-TE routing extensions in
order to distribute the whole bypass topology.
Le Roux et al. Expires August 2002 [Page 21]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
Bypass local admission control by transit LSR, on the bypass LSP
path, requires RSVP-TE extensions.
RSVP-TE must be extended to indicate that a LSP is a bypass LSP, and
to indicate the entities it is protecting, i.e. its PFRG.
Extensions are proposed in 8.
With this extension, a LSR has all the information to perform local
bypass admission controls.
6. PRS-aware online bypass path computation
Bypass tunnel computation may be performed by a PLR. It is triggered
by primary LSP requiring local repair, or by configuration. The
constraint based Dijkstra algorithm (CSPF) used for computation of
classical MPLS-TE LSP must be modified for Bypass LSPs.
Firstly, protected and bypass tunnels must be diversely routed:
- For a NHOP bypass tunnel, the path computed must not use the
downstream link and it must be SRLG diverse with the downstream link.
- For a NNHOP bypass tunnel, the path computed must not use the
downstream node, and it must be SRLG diverse with the downstream
link.
Secondly, a bypass admission control must be performed by the PLR, on
each candidate link for the path. Links that cannot support the
bypass tunnel are pruned from computation.
As mentioned in 5.6 bypass admission control on a link requires that
the PLR knows all existing bypass going through the link, their
bandwidth and their PFRG.
The proposed solution to distribute the whole bypass topology
consists in extending IGP TE so that each PLR advertises its bypass
in link state advertisements. The advertisement must include:
- The type of bypass (NHOP or NNHOP)
- The path followed by the bypass
- The bypass bandwidth
- The bypass PFRG (link, SRLG, node protected).
New TLVs is defined for ISIS/OSPF in 7.
Note that the maximum reservable protection bandwidth of links must
also be advertised in the IGP.
These extensions may be used by each potential PLR to build a bypass
database which contains, for each unidirectional link, all FRs
protected on this link, i.e. the PFRG of the link, and their PB, and
also the max reservable protection bandwidth.
This database may be used during bypass path computation to perform
bypass admission control on all links and to prune links that cannot
handle the required bandwidth.
Le Roux et al. Expires August 2002 [Page 22]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
To summarize, a PLR, when computing a bypass LSP path, must have
knowledge the whole bypass topology, in order to know if the bypass
LSP can share protection resources with other existing bypass LSPs.
Example:
Let's go back to figure 3.
We assume that MRPbw on all links is set to 50M, and that B-C and
J-K do not belong to any SRLG.
Let's assume that a NHOP bypass B1 is already established from B to
C, protecting B->C, with bandwidth 50M. It goes through B->F->G->C.
B is advertising this bypass to all router by piggybacking the
information about the bypass path bandwidth and PFRG, into the LSA.
So the bypass database embedded on each router contains the following
information for link F->G entry:
Link F->G: PFRG {link B-C, PB 50M; node C, PB 50M}, MRPbw 50M.
A LSP is established from I to L through I->J->K->L with bandwidth
50M, node protection and bandwidth protection desired.
On transit LSR J, there is no bypass LSP that can protect the LSP.
Thus bypass creation is triggered.
J has to compute a NNHOP bypass path from J to L, to protect node K,
with bandwidth 50M.
J has to prune from bypass database all links that can't handle B2.
The only link that could eventually be pruned is link F->G. The
resulting reserved protection with B2 remains 50M in so far as B1 and
B2 are PFRG disjoints. So link F->G is not pruned from computation.
Thus the B2 path computed by J is J->F->G->K. B2 is then established,
with bandwidth 50M.
B2 is then advertised by J, into the IGP.
Le Roux et al. Expires August 2002 [Page 23]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
7. Routing extensions for PRS-aware bypass path computation
In this section, we propose several routing extensions, required to
support online PRS-aware bypass CSPF.
Extensions are defined for ISIS-TE and OSPF-TE.
Classical TE link properties are extended to advertise maximal
reservable protection bandwidth and reserved protection bandwidth.
The SRLG extensions defined in [GMPLS-ISIS] and [GMPLS-OSPF] must
also be used.
Note that reserved protection bandwidth advertisement is optional, in
so far as it is not used in PRS-aware bypass path computation.
Each LSR must have knowledge of the whole bypass topology. For this
purpose, a new TLV, the bypass TLV, is defined to advertise a bypass
LSP and its parameters.
7.1. New TE link parameters for protection
[OSPF-TE] and [ISIS-TE] both define TE parameters that are announced
in LSA/LSP to describe TE link properties (affinity, maximum
reservable bandwidth, available bandwidth
). These TE properties are
encoded in sub-TLV, included in Link TLVs of TE LSA for OSPF, and in
IS reachability TLVs for ISIS.
New TE parameters are defined to advertise protection bandwidth
properties.
Note that SRLG TLV defined in GMPLS-RTG must also be added in
ISIS-TE/OSPF-TE LSA/LSPs, to support the proposed functionality.
7.1.1. Protection bandwidth
Two new sub TLVs are defined:
-Max reservable protection bandwidth sub-TLV: this sub-TLV contains
the maximum protection bandwidth that can be reserved on this link in
this direction (from the node originating the LSA to its
neighbors). The maximum protection bandwidth is encoded in 32 bits in
IEEE floating-point format. The units are bytes per second.
OSPF and ISIS type are TBD.
Le Roux et al. Expires August 2002 [Page 24]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max res prot bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-Reserved Protection bandwidth sub-TLV: This sub-TLV contains the
effective bandwidth reserved by bypass tunnels on the link in this
direction. This is not the sum of bypass tunnel bandwidths, but the
highest cumulated bandwidth of bypass tunnels that could be activated
at the same time on the link, in case of single network failure. By
active bypass tunnel we means a bypass tunnel currently in use to
recover from a network failure. The reserved protection bandwidth is
encoded in 32 bits in IEEE floating-point format. The units are bytes
per second. OSPF and ISIS type are TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved prot bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To support the proposed functionality, these sub-TLVs must be
included into IS reacheability TLV for ISIS and Link TLV for OSPF.
Note that reserved protection bandwidth is optional, in so far as it
is not relevant for PRS-aware bypass admission control.
7.1.2. SRLG
The SRLG TLV is already defined in [OSPF-GMPLS] and [ISIS-GMPLS]. It
indicates the set of SRLG the link belongs to. It is defined as a new
TLV in ISIS Link State PDU, and as a new sub-TLV of the Link TLV in
OSPF TE LSA.
Note that another option could be to reuse link administrative
groups.
Le Roux et al. Expires August 2002 [Page 25]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
7.2. Bypass advertisement
As explained before, to compute a bypass path, taking into account
protection resource sharing, the PLR must know the whole bypass
topology. That means that each bypass LSP must be advertised by IGP-
TE. The relevant information is the bypass path, the bypass
bandwidth, and the failure risks protected (Node, Link, SRLG), i.e.
the PFRG.
A bypass TLV is defined to advertise bypass LSPs and their
properties. This new TLV must be added in OSPF TE LSA or ISIS Link
State PDU.
To support the proposed functionality, each LSR must include, in its
Link State Advertisement, a bypass TLV for each, non-zero bandwidth
bypass LSP, for which it is the head-end.
Note that there is no need to advertise Best Effort Bypass LSPs,
which do not reserve bandwidth.
This new TLV contains three sub-TLVs:
- Bypass tail Router Id
- Bypass Path
- Bypass Information.
Its type is TBD.
7.2.1. Tail Router ID sub-TLV
This sub-TLV contains a 4-octet IPv4 address used to identify the
bypass LSP merge point, i.e. the bypass LSP tail-end node. This is
actually the merge point router ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Roux et al. Expires August 2002 [Page 26]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
7.2.2. Path sub-TLV
This sub-TLV is already defined in [LSP-HIER]. It contains the
information about the path taken by the bypass tunnel. It should be
used for bypass path computation purpose, to determine the bypass
tunnels that use a given link.
In both IS-IS and OSPF, this TLV is encoded as follows: the type is
TBD, the length is 4 times the path length, and the value is a list
of 4 octet IPv4 addresses identifying the links in the order that
they form the path of the bypass tunnel.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 4 * No. of links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.2.3. Bypass Information sub-TLV.
This new TLV contains information required for bypass CSPF, i.e.
bypass type, bandwidth, and PFRG.
It is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Link Local IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Link Neighbour Ipv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Roux et al. Expires August 2002 [Page 27]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
Type is TBD, length is 20 bytes.
T: 1 bit
Indicates, if set, that the Bypass is NNHOP, and not set, that the
bypass is NHOP.
Note that this info could also be deduced from the path sub-TLV.
Bit 33 to 64 are reserved for future extensions
Protected Router ID: 32 bits
IPv4 address: The router ID of the protected downstream node.
zero if type=NNHOP.
Protected Link Local IPv4 address: 32 bit
Local IPv4 address of the protected link.
Protected Link Neighbour IPv4 Address:
Neighbour IPv4 address of the protected link
Bypass Bandwidth: 32 bit IEEE floating point number.
This sub-TLV enables to determine the PFRG, and bandwidth of the
bypass tunnel.
Protected Router Id identifies the downstream node, and
Local/Neigbour IPv4 address identifies the downstream link. The SRLG
of the protected downstream link can be found in the TLV
corresponding to the link.
The SRLG information of the protected downstream link is not added
again here, in so far as it is already advertised as a TE link
parameter.
7.3. PLR processing
A LSR must include in its periodically flooded LSA, the
information corresponding to each, non zero bandwidth bypass tunnel,
for which it is the head-end.
That means that when flooding is completed, each LSR has the
knowledge of the whole bypass topology.
Bypass bandwidth may change dynamically due to protected LSP being
setup or torn down. These changes must be advertised to the whole
network. Several triggering rules may be defined for LSA flooding, in
order to limit flooding overload.
Le Roux et al. Expires August 2002 [Page 28]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
7.4. Bypass database
To facilitate bypass CSPF, each LSR could maintain a database which
contains, for each link, all the FRs F protected on the link, i.e.
PFRG(L), and the corresponding protection bandwidths PB(L, F) (cf 6).
This table is created by analyzing each bypass TLV.
To perform a bypass admission control on a link L, during the bypass
path computation, the PLR has just to check the entry corresponding
to L, computes the resulting reserved protection bandwidth, and
compares it with the maximum reservable bandwidth of L. Links which
cannot support the required protection must be pruned from the
computation.
8. RSVP-TE extensions for bypass LSPs setup
In [FRR] a many-to-one bypass LSP is signaled as a normal LSP.
Whereas in the solution proposed here, primary LSPs and bypass LSPs
work on distinct bandwidth pools, a different admission control must
be performed for these LSPs.
Each transit LSR on a bypass LSP path must perform a PRS-aware bypass
admission control. This requires information such as bypass
bandwidth, and the PFRG of the bypass.
Thus RSVP-TE must be extended for the establishment of bypass LSPs.
A new Object is defined for bypass LSPs. It contains the bypass type
(NHOP or NNHOP) and the bypass PFRG (link, SRLG, node protected).
8.1. Bypass object
To support the proposed functionality, this object must be added to
the Path and Resv messages for the setup of bypass tunnels.
It indicates that the LSP is a bypass tunnel, which must be handled
separately. It also indicates the downstream node, link and its SRLG,
protected by the bypass.
Class = TBD, C_Type= 1
Length= 16 + N * SRLGnum.
Le Roux et al. Expires August 2002 [Page 29]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Local IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Neighbour IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............................................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T: 1 bit
If set, it indicates that the bypass is NNHOP. else that the bypass
is NHOP.
Reserved: 31 bit
This field is reserved. It must be set to zero on transmission and
ignored on receipt.
Protected Router ID: 32 bit
The IPv4 router id of the downstream node protected by the bypass.
Zero if Type=NHOP
Protected Local IPv4 address: 32 bit
The local IPv4 address of the link protected by the bypass.
Protected Neighbour IPv4 address: 32 bit
The neighbour IPv4 address of the link protected by the bypass.
SRLG: 32 bit
32 bit ids indicating SRLGs the link belongs to.
Note that bypass LSP bandwidth is encoded, as classical LSPs, in the
SenderTspec and FlowSpec objects.
The presence of this object indicates that the LSP is a bypass
tunnel; it also indicates the bypass type and PFRG.
Le Roux et al. Expires August 2002 [Page 30]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
8.2. Processing of the Bypass Object
The RSVP global state machine is not modified. The presence of the
Bypass object in Path/Resv messages, just indicates that a local
admission control specific to bypass LSPs must be performed.
In case a node does not recognize the Bypass Object, it must send a
PathErr message, upstream to the PLR with an error code "Bypass Not
Supported".
The bypass local admission control consists, as mentioned in 5.4, in
computing the resulting reserved protection bandwidth with this new
bypass, on the downstream link, taking into account its PFRG and
other bypass already established on the link.
If the resulting bandwidth remains lower than the maximum reservable
protection bandwidth then the reservation request is accepted, else
it is rejected.
Note that, this control is not needed for zero bandwidth bypass LSPs.
Note that, for bypass local admission control purpose, each LSR may
contain a table, maintaining, for each attached link, the set of FRs
protected on the link, and the corresponding protected bandwidth.
When a request for a new bypass arrives, the resulting reserved
protection bandwidth is easily computed, checking this table.
9. Security Considerations
This document does not introduce new security issues.
10. Intellectual property consideration
France Telecom is seeking patent protection on the specification
described in this Internet-Draft. If it is adopted as a standard,
France Telecom agrees to licence, on reasonable and non-
discriminatory terms, any patent rights it obtains covering the
specification to the extent necessary to comply with the standard.
11. Acknowledgment
We acknowledge the helpful comments and discussions with Renaud
Moignard and Jean-Yves Mazeas.
Le Roux et al. Expires August 2002 [Page 31]
Internet Draft draft-leroux-mpls-bypass-placement-00.txt February 2002
12. References
[FRR] Pan, et al, "Fast-Reroute Techniques in RSVP-TE",
draft-ping-rsvp-fastreroute-00.txt (work in pogress).
[ATLAS] Atlas, A. et al., "RSVP-TE Interoperability for Local
Protection/ Fast Reroute",
draft-atlas-rsvp-local-protect-interop-02.txt (work in progress)
[RSVP-TE] D. Adwuche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3209
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-02.txt (work in progress)
[OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to
OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress)
[HIER] Rekter, Y., Kompella, K., "LSP Hierarchy with MPLS-TE",
draft-ietf-mpls-lsp-hierarchy-03.txt (work in progress)
[GMPLS-RTG] "Routing Extensions in Support of Generalized MPLS",
draft-many-ccamp-gmpls-routing-00.txt
[OSPF-G] Kompella, K. et al., "OSPF Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-00.txt
[ISIS-G] Kompella, K. et al., "IS-IS Extensions in Support of
Generalized MPLS", draft-ietf-isis-gmpls-extensions-04.txt
13. Authors Information
Jean-Louis Le Roux
France Telecom R & D
Avenue Pierre Marzin
22300 Lannion, France
email: jeanlouis.leroux@francetelecom.com
phone: +33 2 96 05 30 20
Geraldine Calvignac
France Telecom R & D
Avenue Pierre Marzin
22300 Lannion, France
email: geraldine.calvignac@francetelecom.com
phone: +33 2 96 05 10 59
Le Roux et al. Expires August 2002 [Page 32]