< draft-hokelek-rlfap-00.txt   draft-hokelek-rlfap-01.txt >
Network Working Group I. Hokelek Network Working Group I. Hokelek
Internet-Draft M. Fecko Internet-Draft M. Fecko
Expires: February 2, 2008 P. Gurung Expires: August 28, 2008 P. Gurung
S. Samtani S. Samtani
S. Cevher
J. Sucec
Applied Research Applied Research
Telcordia Technologies, Inc. Telcordia Technologies, Inc.
July 2, 2007 February 25, 2008
Loop-Free IP Fast Reroute Using Local and Remote LFAPs Loop-Free IP Fast Reroute Using Local and Remote LFAPs
draft-hokelek-rlfap-00.txt draft-hokelek-rlfap-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This draft describes a new loop-free IP fast reroute mechanism which This draft describes a new loop-free IP fast reroute mechanism which
enhances the IP Fast-ReRoute (IPFRR) [1,15] by introducing the enhances the IP Fast-ReRoute (IPFRR) [1,15] by introducing the
concept of pre-computed remote Loop-Free Alternate Paths (rLFAPs) on concept of pre-computed remote Loop-Free Alternate Paths (rLFAPs) on
top of the IPFRR local LFAP. In rLFAP, a router which is adjacent to top of the IPFRR local LFAP. In rLFAP, a router which is adjacent to
the failed resource switches over to pre-computed LFAPs, if they the failed resource switches over to pre-computed LFAPs, if they
exist, immediately after failure detection. Multi-hop neighbors exist, immediately after failure detection. Multi-hop neighbors
(MNBs) are notified about this remote failure as quickly as possible (MNBs) are notified about this remote failure as quickly as possible
skipping to change at line 351 skipping to change at line 353
away routers is sufficient for maintaining MNBHs). Each node takes away routers is sufficient for maintaining MNBHs). Each node takes
its best fast reroute action independently in case of a failure its best fast reroute action independently in case of a failure
within its MNBH. Minimal inconsistencies (hence micro-loops) are within its MNBH. Minimal inconsistencies (hence micro-loops) are
expected as a result of each node's independent decision since two expected as a result of each node's independent decision since two
overlapping MNBHs' partial topologies have a lot common information. overlapping MNBHs' partial topologies have a lot common information.
3.2 Alternate Path Calculation 3.2 Alternate Path Calculation
We describe the alternate path calculation methodology for the node We describe the alternate path calculation methodology for the node
N44 in Figure 5. Other nodes in the network repeat the same steps N44 in Figure 5. Other nodes in the network repeat the same steps
but using their own MNBHs. For simplicity, we assume that only link but using their own MNBHs. For simplicity, we assume that only a
failures occur. single link failure occurs.
N44 has four local links. For each local link LL_k (k=1,2,3,4), the N44 has four local links. For each local link LL_k (k=1,2,3,4), the
following calculations are done per each destination Nij following calculations are done per each destination Nij
(i=1,2,3,5,6,7 and j=1,2,3,5,6,7): (i=1,2,3,5,6,7 and j=1,2,3,5,6,7):
- remove LL_k from the topology to anticipate the failure - Remove LL_k from the topology to anticipate the failure
- calculate the shortest path to Nij using the new topology. If - Calculate the shortest path to Nij using the new topology. If
the new shortest path to Nij (after the failure) is the same as the new shortest path to Nij (after the failure) is the same as
the primary path to Nij (before the failure) then break (do not the primary path to Nij (before the failure) then break (do not
perform the following three steps). Do not store any alternate perform the following three steps). Do not store any alternate
path to Nij for the failure of LL_k path to Nij for the failure of LL_k. If the primary path to Nij
- calculate three local shortest alternate paths (SAPs) via before the failure has equal cost multipaths (ECMPs) and at
least one of these ECMPs is affected from the failure, then
the following three steps should also be performed.
- Calculate three local shortest alternate paths (SAPs) via
immediate neighbors to Nij (there are three immediate neighbors immediate neighbors to Nij (there are three immediate neighbors
after the link failure and therefore three SAPs need to be after the link failure and therefore three SAPs need to be
calculated). Here SAP is defined as the shortest distance path to calculated). Here SAP is defined as the shortest distance path to
Nij calculated by the Djikstra algorithm after removing LL_k from Nij via an immediate neighbor calculated by the Djikstra
the topology algorithm after removing LL_k from the topology
- store the shortest local LFAP among these three local SAPs (if - Store the shortest local LFAP among these three local SAPs (if
LFAP exists) LFAP exists) and modify the entry, corresponding to this
- if none of these local SAPs are loop-free then store the shortest source-destination pair, in the path safety matrix. This matrix
local SAP as an alternate path keeps track of loop-free source-destination pairs which will be
used during the remote LFAP calculation
A similar method will be used for calculating remote alternate A similar method will be used for calculating remote alternate
paths. N44 has 32 remote links within its MNBH. For each remote link paths. N44 has 32 remote links within its MNBH. For each remote link
RL_k (k=5,6,...,32), the following calculations are done per each RL_k (k=5,6,...,32), the following calculations are done per each
destination Nij (i=1,2,3,5,6,7 and j=1,2,3,5,6,7): destination Nij (i=1,2,3,5,6,7 and j=1,2,3,5,6,7):
- remove RL_k from the topology to anticipate the failure - Remove RL_k from the topology to anticipate the failure
- calculate the shortest path to Nij using the new topology. If the - Calculate the shortest path to Nij using the new topology. If the
shortest path to Nij is the same as the primary path to Nij shortest path to Nij is the same as the primary path to Nij
then break (do not perform the following three steps). Do not then break (do not perform the following three steps). Do not
store any alternate path to Nij for the failure of RL_k store any alternate path to Nij for the failure of RL_k
- calculate four remote shortest alternate paths (SAPs) via - Calculate four remote shortest alternate paths (SAPs) via
immediate neighbors to Nij (since RL_k is not a local interface immediate neighbors to Nij (since RL_k is not a local interface
there are four immediate neighbors for this node) there are four immediate neighbors for this node).
- store the shortest remote LFAP among these four remote SAPs - Store the shortest remote LFAP among these four remote SAPs and
- if none of these SAPs are LFAP then store the shortest remote update the path safety matrix if any LFAP exists. If there is no
SAP LFAP, then check the path safety matrix if there is any neighbor
which has a loop-free path to this destination indicated by
the path safety matrix. If there is/are such neighbor(s), then
use the shortest one as remote LFAP and update the corresponding
entry in the path safety matrix.
The above algorithms make sure that a local or remote alternate The above algorithms make sure that a local or remote alternate
path (either LFAP or SAP) will be stored only if the primary path path will be stored only if the primary path does not function
does not function anymore after the failure. Therefore, rLFAP anymore after the failure. Therefore, rLFAP stores only the
stores only the required alternate paths and is scalable. Note that required alternate paths and is scalable. Note that routers only
routers only store alternate next-hops (not the alternate path store alternate next-hops (not the alternate path itself).
itself).
3.3 Fast Failure Notification Mechanism 3.3 Fast Failure Notification Mechanism
The objectives of a multi-hop failure notification mechanism are as The objectives of a multi-hop failure notification mechanism are as
follows: follows:
- Routers should be notified about failures as fast as possible to - Routers should be notified about failures as fast as possible to
minimize the reroute delay from the primary path to an LFAP minimize the reroute delay from the primary path to an LFAP
- Failure notification should create minimal overhead in terms of - Failure notification should create minimal overhead in terms of
bandwidth consumption. For example, generating too many LSA bandwidth consumption. For example, generating too many LSA
packets in OSPF consumes the available bandwidth and may cause packets in OSPF consumes the available bandwidth and may cause
skipping to change at line 601 skipping to change at line 610
by the routing protocol). by the routing protocol).
Another important feature of rLFAP is that the minimum number of Another important feature of rLFAP is that the minimum number of
next hop changes is expected during switching from LFAPs to new next hop changes is expected during switching from LFAPs to new
primary paths of the dynamic routing protocol. The reason is that primary paths of the dynamic routing protocol. The reason is that
the next hop change will occur only if the next hop in the new the next hop change will occur only if the next hop in the new
primary path is different than the next hop in the alternate path. primary path is different than the next hop in the alternate path.
Due to the MNBH concept, it is conjectured that the next hops for Due to the MNBH concept, it is conjectured that the next hops for
LFAPs and the new primary paths will be the same with a high LFAPs and the new primary paths will be the same with a high
probability and the minimum number of FIB updates is expected probability and the minimum number of FIB updates is expected
during switching from LFAPs to new primary paths. during switching from LFAPs to new primary paths. Our initial
analysis shows that
4. Scope and Applicability 3.6 Applicability of rLFAP Mechanism to Support Fast PIM-SM Tree
Repair
Protocol Independent Multicast - Sparse Mode (PIM-SM) [16] is a
widely available multicast protocol that achieves efficient
distribution of multicast content through on-demand construction of
shared trees and shortest path trees. Key to its efficiency is its
use of Join messages to build the multicast tree from the multicast
group members towards the Rendezvous Point (RP) or the content
source for the cases of shared trees and shortest path trees (SPTs),
respectively.
Unfortunately, PIM-SM reacts to link failure events even more slowly
than the underlying routing protocol (e.g., OSPF, IS-IS, etc.).
Specifically, not only must the underlying unicast routing protocol
converge to reflect the degraded network topology, but the
appropriate PIM Join messages must be sent, received, and processed
before multicast tree repair is completed. Furthermore, depending
on the router implementation, PIM-SM may not even recognize a
change in the underlying unicast paths for several seconds when
time-based events are used to trigger the PIM-SM process to compare
the current routing information for changes that impact the reverse
path forwarding (RPF) to RPs and multicast sources.
The rLFAP features can help speed up PIM-SM tree repair by
accelerating the convergence to correct RPF information about a
failure at affected nodes in the LUP TTL MNBH. To illustrate
potential benefits of the rLFAP mechanism in the context of PIM-SM,
the topology of Figure 2 is considered again. Here, however, Node S
is supposed to denote the source node for packets to be delivered by
an SPT to the multicast group Z comprising Nodes D and G. The SPT
constructed by PIM-SM (assuming unit cost links) is shown in Figure
6.
S A B C
|
|
|
|
E-----------------------F-----------D
|
|
|
|
G H
Figure 6: SPT constructed by PIM-SM for multicast group Z = (D,G)
with source node S based on the topology of Figure 2 (links not
part of the SPT are omitted from the figure).
Now, per the scenario of Figure 2, it is assumed that links E-F and
F-H of Figure 2 fail at the same time. However, when the LUP
originated by Node F arrives at Node D, D will recognize that the RPF
to S has changed and D will use the pre-computed LFAP to S via the
link D-C as the link for the new RPF to S. The processing described
thus far is native to the rLFAP mechanisms already presented herein.
In order to complete the speed-up of PIM-SM tree repair, routers
employing rLFAP mechanisms MUST trigger the PIM-SM process to check
the impact on RPF information of those multicast groups for which
PIM-SM state is maintained locally whenever a LUP is received and
processed. In doing so, the PIM-SM process will learn of the new
correct RPF information for affected multicast groups within
milliseconds of the received LUP being processed. The PIM-SM
implementation MUST then immediately issue the appropriate (*,G)
and/or (S,G) Join messages. For the scenario of Figure 6, Node D
will issue a (S,G) Join message to its PIM neighbor Node C via the
link D-C which, in turn, sends a Join message to Node B, and so
forth. The resulting repaired PIM-SM SPT for Group Z is shown in
Figure 7.
S-----------A-----------B-----------C
| |
| |
| |
| |
E F D
|
|
|
|
G H
Figure 7: Reconstructed by PIM-SM for multicast group Z = (D,G)
following fast tree repair based on LUPs originated by Node F (links
not part of the SPT are omitted from the figure).
A few additional points regarding the illustrative scenario of
Figures 6 and 7 are worth noting. First, the routing instance at
Node F does not originate a new Join message for Group Z as it is no
longer "upstream" to Group Z members. That is, a router applying
the rLFAP mechanism to speed up PIM-SM tree repair SHOULD suppress
sending PIM Join messages if the neighbors for which it maintained
Join state are no longer "downstream" from it with respect to the
source. Second, the illustrative scenario given here applies without
loss of generality to RP-based (i.e., shared) trees: The only
difference being (in the example here) that Node D would issue a
(*,G) Join message to repair its branch of the multicast tree. Last,
the SPT branch going to multicast group member G was not affected by
the link failures and, therefore, LUPs originated by Nodes E and H
received at Node G (correctly) did not initiate tree repair.
4. Experimental Results
4.1 LFAP Coverage Analysis
We performed the coverage analysis of the fast reroute mechanism
presented here on realistic topologies, which were generated by the
BRITE topology generator in bottom-up mode [17]. The LFAP coverage
percentage is defined here as the percentage of the number of LFAPs
for protecting the primary paths which are failed because of link
failures to the number of all failed primary paths. Only local LFAPs
are considered in the coverage calculation for the neighborhood depth
of 0 (i.e., X=0) while both local and remote LFAPs are taken into
account when the neighborhood depth is set to a value greater than 0
(i.e., X>0).
The realistic topologies include AT&T and DFN using pre-determined
BRITE parameter values from Ref.[17] and various random topologies
with different number of nodes and varying network connectivity. For
example, the number of nodes for AT&T and DFN are 154 and 30,
respectively, while the number of nodes for other random topologies
is varied from 20 to 100. The BRITE parameters which are used in our
topology generation process are summarized in Figure 10 (see Ref.[17]
for the details of each parameter). In summary, m represents the
average number of edges per node and is set to either 2 or 3. A
uniform bandwidth distribution in the range 100-1024 Mbps is selected
and the link cost is obtained deterministically from the link
bandwidth (i.e., inversely proportional to the link bandwidth as used
by many vendors). Since the values for p(add) and beta determine the
number of edges in the generated topologies, their values are varied
to obtain network topologies with varying connectivity (e.g., sparse
and dense).
|----------------------------|-----------------------|
| | Bottom up |
|----------------------------|-----------------------|
| Grouping Model | Random pick |
| Model | GLP |
| Node Placement | Random |
| Growth Type | Incremental |
| Preferential Connectivity | On |
| BW Distribution | Uniform |
| Minimum BW | 100 |
| Maximum BW | 1024 |
| m | 2-3 |
| Number of Nodes (N) | 20,30,50,100,154 |
| p(add) | 0.01,0.05,0.10,0.42 |
| beta | 0.01,0.05,0.15,0.62 |
|----------------------------|-----------------------|
Figure 10: BRITE topology generator parameters
The coverage percentage of our fast reroute method is reported for
different network topologies (e.g., different number of nodes and
varying network connectivity) using neighborhood depths of 0, 1,
and 2. (i.e., X=0, 1, and 2). For a particular failure, LFAPs
protecting the failed primary paths are calculated only by those
nodes which are within the multi-hop neighborhood of this failure.
Note that these nodes are determined by the parameter X as follows:
For X=0, two nodes which are directly connected to the failed link,
for X=1, two nodes which are directly connected to the failed link
and also neighboring nodes which are adjacent to one of the
outgoing links of these two nodes, and so on.
The LFAP coverage percentage for a certain topology is computed by
the following formula: LFAP Coverage Percentage = N_lfaps*100/N_fpp
where N_lfaps is the number of source-destination pairs whose
primary paths are failed because of link failures and have LFAPs for
protecting these failed paths, and N_fpp is the number of
source-destination pairs whose primary paths are failed because of
link failures. The source-destination pairs, in which source and
destination nodes do not have any physical connectivity after a
failure, are excluded from N_fpp. Note that the coverage percentage
includes a network-wide result which is calculated by averaging all
coverage results obtained by individually failing all edges for a
certain network topology.
Figure 11 shows the LFAP coverage percentage results for random
topologies with different number of nodes (N) and network
connectivity, and Figure 12 shows these results for AT&T and DFN
topologies. In these figures, E_mean represents the average number
of edges per node for a certain topology. Note that the average
number of edges per node is determined by the parameters m, p(add),
and beta. We observed that E_mean increases when p(add) and beta
values increase. For each topology, LFAP coverage analysis is
repeated for 10 topologies generated randomly by using the same
BRITE parameters. E_mean and LFAP coverage percentage are
obtained by averaging the results of these ten experiments.
|------------|-----|------|------|------|------|
| Case |N |E_mean|X=0 |X=1 |X=2 |
|------------|-----|------|------|------|------|
|p(add)=0.01 |20 |3.64 |82.39 |98.85 |100.0 |
|beta=0.01 |50 |3.86 |82.10 |98.69 |100.0 |
| |100 |3.98 |83.21 |98.04 |100.0 |
|------------|-----|------|------|------|------|
|p(add)=0.05 |20 |3.70 |85.60 |99.14 |100.0 |
|beta=0.05 |50 |4.01 |84.17 |99.09 |100.0 |
| |100 |4.08 |83.35 |98.01 |100.0 |
|------------|-----|------|------|------|------|
|p(add)=0.1 |20 |5.52 |93.24 |100.0 |100.0 |
|beta=0.15 |50 |6.21 |91.46 |99.87 |100.0 |
| |100 |6.39 |91.17 |99.86 |100.0 |
|------------|-----|------|------|------|------|
Figure 11: Coverage percentage results for random topologies
|------------|-----------|------|------|------|------|
| Case |N |E_mean|X=0 |X=1 |X=2 |
|------------|-----------|------|------|------|------|
|p(add)=0.42 |154 (AT&T) |6.88 |91.04 |99.81 |100.0 |
|beta=0.62 |30 (DFN) |8.32 |93.76 |100.0 |100.0 |
|------------|-----------|------|------|------|------|
Figure 12: Coverage percentage results for AT&T and DFN topologies
There are two main observations from these results:
1. As the neighborhood depth (X) increases the LFAP coverage
percentage increases and the complete coverage is obtained using
a low neighborhood depth value (i.e., X=2). This result is
significant since failure notification message needs to be sent
only to nodes which are two-hop away from the point of failure
for the complete coverage. This result supports that our method
provides fast convergence by introducing minimal signaling
overhead within only the two-hop neighborhood.
2. The topologies with higher connectivity (i.e., higher E_mean
values) have better LFAP coverage compared to the topologies
with lower connectivity (i.e., lower E_mean values). This is
an intuitive result since the number of possible alternate hops
in dense network topologies is higher than the number of
possible alternate hops in sparse topologies. This phenomenon
increases the likelihood of finding LFAPs, and therefore the
LFAP coverage percentage.
4.2 Convergence Analysis Based on Testbed Experiments
F-----------E------------A------------|
| | | |
| | | |
| | | |
| | | |
G-----------D------------| B
| |
| |
| |
| |
C-------------------------|
Figure 13: 7-node network topology for local LFAP convergence
experiments
F-----------E------------A------------|
| | |
| | |
| | |
| | |
G-----------D B
| |
| |
| |
| |
C-------------------------|
Figure 14: 7-node network topology for remote LFAP convergence
experiments
We performed the convergence analysis of our new fast reroute
presented here using 7-node network consisting of 2600 and 3600
series Cisco routers as shown in Figures 13 and 14. Link costs are
set to the same value for all links. A dedicated computer
(e.g., an agent), which is running our fast reroute technology,
is connected to each router through an Ethernet cable. These
agents obtain the network topology from the routers in real-time
by issuing an SNMP request. Using the retrieved network topology
information, a set of LFAPs, which protects the failed primary
paths when a real failure occurs, is pre-computed and stored. For
both networks, the link between routers A and E is failed for all
experiments.
The convergence time on the alternate path is measured by running
a session, similar to a ping application, between routers A and E.
When the link between routers A and E is failed on the topology as
shown in Figure 13, the primary path A-E (and hence the session
between them) fails. Once the failure is detected, the router A (E)
reroutes its traffic over the alternate path A-D-E (E-D-A) by
installing its pre-computed local LFAP. However, when the same
scenario is applied to the topology in Figure 14, there is no local
LFAP in the router A (E) to protect the primary path A-E (E-A) for
this failure. For the above scenario, our fast reroute technology
propagates the failure information to router B (D) which is
already pre-computed a set of remote LFAPs for this particular
failure. As a result, the session is rerouted through the
alternate path A-B-C-D-E (E-D-C-B-A).
For both local and remote LFAP scenarios, the experiments are
repeated for 10 times. The mean convergence time for the local LFAP
scenario is 602 milliseconds while the mean convergence time for
the remote LFAP scenario is 612 milliseconds. Note that LFAPs are
stored in the agents which are external to the routers. These agents
issue an IOS command to install the right set of LFAPs when a
failure is detected. In reality, the agent technology should run
in the router as a GPP and LFAPs should be installed beforehand
and waiting for a failure signal to be activated. Therefore, the
results should be used to compare the difference between local and
remote LFAPs rather than their absolute values.
The convergence times do not include the failure detection time
since our primary objective in these experiments is to compare local
and remote LFAP rather than proposing a new failure detection
mechanism. For the sake of experiments, we implemented a heuristic
based failure detection mechanism using periodic light-weight
hearbeat messages similar to the Bidirectional Forwarding Detection.
Note that the alternate path between A and E in the remote LFAP
scenario is longer (A-D-E vs. A-B-C-D-E). The failure information is
reached to one-hop neighbor within a few milliseconds since the round
trip time between two neighboring agents is measured around 1-2
milliseconds. These results indicate that the convergence time of the
remote LFAP mechanism is only slightly higher compared to the only
local LFAP mechanism due to the failure notification. This increase
is bounded by the neighborhood depth times a few milliseconds.
However, the remote LFAP significantly increases the alternate path
coverage since there is no local LFAP to protect the session between
routers A and E when the link between routers A and E fails in
Figure 14.
5. Scope and Applicability
This work is proposed initially for link state IGPs (i.e., OSPF and This work is proposed initially for link state IGPs (i.e., OSPF and
IS-IS). Further study is needed for extending its applicability to IS-IS). Further study is needed for extending its applicability to
non-link state IGPs or BGP. non-link state IGPs or BGP.
5. Acknowledgements 6. Acknowledgements
The authors would like to thank John Scudder, the co-chair of the The authors would like to thank John Scudder, the co-chair of the
IETF RTGWG, for his valuable comments and suggestions on the IETF RTGWG, for his valuable comments and suggestions on the
preliminary version of this draft. preliminary version of this draft.
6. References 7. References
Internet-drafts are works in progress available from Internet-drafts are works in progress available from
<http://www.ietf.org/internet-drafts/> <http://www.ietf.org/internet-drafts/>
[1] M. Shand and S. Bryant, "IP Fast Reroute Framework", [1] M. Shand and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-06.txt, Oct. 2006 (work in draft-ietf-rtgwg-ipfrr-framework-06.txt, Oct. 2006 (work in
progress). progress).
[2] S. Bryant and M. Shand, "A Framework for Loop-free Convergence", [2] S. Bryant and M. Shand, "A Framework for Loop-free Convergence",
draft-bryant-shand-lf-conv-frmwk-03.txt, Oct. 2006 (work in draft-bryant-shand-lf-conv-frmwk-03.txt, Oct. 2006 (work in
skipping to change at line 674 skipping to change at line 1011
December 1999. December 1999.
[14] S. Lee, Y. Yu, S. Nelakuditi, Z. Zhang, and C. Chuah, [14] S. Lee, Y. Yu, S. Nelakuditi, Z. Zhang, and C. Chuah,
"Proactive vs. reactive approaches to failure resilient "Proactive vs. reactive approaches to failure resilient
routing", Proc. INFOCOM 2004. routing", Proc. INFOCOM 2004.
[15] A. Atlas and A. Zinin, "Basic Specification for IP Fast- [15] A. Atlas and A. Zinin, "Basic Specification for IP Fast-
Rerorute: Loop-free Alternates", <draft-ietf-rtgwg-ipfrr-spec- Rerorute: Loop-free Alternates", <draft-ietf-rtgwg-ipfrr-spec-
base-06.txt>, March 2007 (work in progress). base-06.txt>, March 2007 (work in progress).
7. Authors' Addresses [16] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, "Protocol
Independent Multicast (PIM-SM): Protocol Specification,"RFC
4601, August 2006.
[17] Oliver Heckmann et al., "How to use topology generators to
create realistic topologies", Technical Report, Dec 2002.
8. Authors' Addresses
Ibrahim Hokelek Ibrahim Hokelek
Applied Research, Applied Research,
Telcordia Technologies, Inc. Telcordia Technologies, Inc.
RRC-1E313 RRC-1E313
One Telcordia Drive, One Telcordia Drive,
Piscataway, NJ 08854 Piscataway, NJ 08854
United States. Email: ihokelek@research.telcordia.com United States. Email: ihokelek@research.telcordia.com
Mariusz A. Fecko Mariusz A. Fecko
skipping to change at line 708 skipping to change at line 1052
United States. Email: pgurung@research.telcordia.com United States. Email: pgurung@research.telcordia.com
Sunil Samtani Sunil Samtani
Applied Research, Applied Research,
Telcordia Technologies, Inc. Telcordia Technologies, Inc.
RRC-1P387 RRC-1P387
One Telcordia Drive, One Telcordia Drive,
Piscataway, NJ 08854 Piscataway, NJ 08854
United States. Email: ssamtani@research.telcordia.com United States. Email: ssamtani@research.telcordia.com
Selcuk Cevher
Applied Research,
Telcordia Technologies, Inc.
RRC-1A212
One Telcordia Drive,
Piscataway, NJ 08854
United States. Email: cevhers@research.telcordia.com
John Sucec
Applied Research,
Telcordia Technologies, Inc.
RRC-1G313
One Telcordia Drive,
Piscataway, NJ 08854
United States. Email: sucecj@research.telcordia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
 End of changes. 23 change blocks. 
39 lines changed or deleted 399 lines changed or added

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