idnits 2.17.00 (12 Aug 2021) /tmp/idnits14407/draft-hokelek-rlfap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1106. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1120 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1,15]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 670: '...rLFAP mechanisms MUST trigger the PIM-...' RFC 2119 keyword, line 676: '... implementation MUST then immediately...' RFC 2119 keyword, line 703: '... up PIM-SM tree repair SHOULD suppress...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 969, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 993, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtgwg-ipfrr-framework has been published as RFC 5714 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-ipfrr-framework (ref. '1') -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2740 (ref. '13') (Obsoleted by RFC 5340) -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 4601 (ref. '16') (Obsoleted by RFC 7761) -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group I. Hokelek 2 Internet-Draft M. Fecko 3 Expires: August 28, 2008 P. Gurung 4 S. Samtani 5 S. Cevher 6 J. Sucec 7 Applied Research 8 Telcordia Technologies, Inc. 9 February 25, 2008 11 Loop-Free IP Fast Reroute Using Local and Remote LFAPs 12 draft-hokelek-rlfap-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 28, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This draft describes a new loop-free IP fast reroute mechanism which 46 enhances the IP Fast-ReRoute (IPFRR) [1,15] by introducing the 47 concept of pre-computed remote Loop-Free Alternate Paths (rLFAPs) on 48 top of the IPFRR local LFAP. In rLFAP, a router which is adjacent to 49 the failed resource switches over to pre-computed LFAPs, if they 50 exist, immediately after failure detection. Multi-hop neighbors 51 (MNBs) are notified about this remote failure as quickly as possible 52 using fast failure notification mechanism. Upon receipt of failure 53 information, MNBs activate their pre-computed remote LFAPs that they 54 maintain for protecting against remote failures within their 55 multi-hop neighborhoods. In the worst case, where IPFRR results in 56 forming micro-loops, rLFAP completely prevents micro-loops for 57 single link failures and quickly converges to a loop-free path in 58 case of multiple link failures. 60 1. Introduction 62 Fast reroute in communication networks is defined as the dynamic and 63 timely redirection of a primary path to an alternate secondary path 64 in response to degradation/failure of the primary path. IP Fast- 65 ReRoute (IPFRR) drafts [1,15] provide a framework for the fast- 66 reroute mechanism which minimizes the adverse effects of link or 67 node failures by timely invoking the pre-computed repair paths. 69 IPFRR performs well when a router which is adjacent to the failed 70 resource (link or router) has Loop-Free Alternate Paths (LFAPs). 71 However, major issues arise either when there is no local LFAP or 72 the router assumes that the alternate path is loop-free but this 73 might not be true if there are inconsistencies in the routers' FIBs 74 (e.g., due to failure propagation and FIB update delays). In the 75 latter case, a micro-loop might be formed when the primary path is 76 replaced with the alternate path. 78 A relative performance of a fast-reroute mechanism should not be 79 worse than the performance with relying on the routing protocol's 80 (e.g., OSPF or IS-IS) standard repair mechanism. The performance 81 metrics include repair delay, additional overhead, ability to handle 82 micro-loops, backward compatibility, complexity (processing and 83 memory), and the repair path coverage and quality. An ideal but 84 non-realistic fast-reroute mechanism would have zero repair delay, 85 create no extra overhead, either be micro-loop free or handle all 86 micro-loops, be backward compatible, require minimum amount of 87 processing power and memory, and cover all failure scenarios. 89 Fast reroute can be severely impaired by micro-loops which represent 90 the worst case scenario for IPFRR. Ref. [2] summarizes the 91 techniques proposed for minimizing the adverse effects of micro- 92 loops. These techniques either can resolve the micro-loops only 93 partially [3], or can suffer high delays [4, "incremental cost 94 advertisement"], or are highly complex [5,6]. Therefore, a fast 95 reroute mechanism that is micro-loop free and has comparable 96 performance results to IPFRR in terms of the above metrics will 97 significantly help IETF to reach its goal of dynamic and timely 98 rerouting. 100 This document describes a new micro-loop free fast reroute mechanism 101 which enhances IPFRR [1,15] by introducing the concept of pre- 102 computed remote LFAPs (rLFAPs) on top of the IPFRR local LFAP. This 103 mechanism achieves complete and fast micro-loop prevention at the 104 minimal amount of extra complexity. In rLFAP, a router that is 105 adjacent to the failed resource immediately switches over pre- 106 computed LFAPs if LFAPs for protecting against this local failure 107 exist (the same as IPFRR) and instantly propagates failure 108 information to multi-hop neighbors (MNBs) (e.g., X-hop neighbors, 109 where X is an integer number representing how many hops away from 110 the failure). Upon receipt of failure information, MNBs activate 111 their pre-computed LFAPs that they maintain for protecting against 112 remote failures within their MNBs. Note that this draft uses the 113 existing well-defined LFAP criteria in [15] but extends its 114 applicability by calculating remote LFAPs to protect against remote 115 failures. 117 2. Overview of rLFAP 119 The number of LFAP choices to bypass a failed resource is either 120 equal or higher at routers which are multi-hop away from the failed 121 component compared to the router adjacent to the failure (the latter 122 is the subset of the first). This fact together with the concept of 123 remote LFAP, which protects against failures at multi-hop routers, 124 is the key motivation behind rLFAP. 126 One might think that rLFAP would not be fast enough since there is a 127 certain failure notification delay before activating remote LFAPs. 128 However, in rLFAP, each router pre-computes two sets of LFAPs: the 129 first set includes local LFAPs which are activated instantly (if 130 exist) when a local failure is detected and the second set includes 131 remote LFAPs which are activated when notifications of remote 132 failures arrive from multi-hop routers. Therefore, rLFAP follows the 133 approach proposed in the IPFRR draft [1] for its local best-effort 134 fast reroute and quickly continues to correct the previous best 135 effort decisions as failure notifications keep on arriving from 136 MNBs. Since rLFAP gradually corrects the previous decisions, micro 137 loops are detected and corrected before or shortly after they are 138 formed (rLFAP completely prevents micro-loops for single link 139 failures and quickly converges to a loop-free path in case of 140 multiple link failures). 142 The main features of rLFAP are as follows: 143 - Prevention of micro-loops without tunneling 144 - Handling multiple link/node failures 145 - Faster than IPFRR in the worst case scenarios; comparable 146 otherwise 147 - Ability to distinguish link and node failures 148 - Scalability due to limiting the scope of MNBs to X hops 149 - Minimal additional overhead for fast failure notification 151 2.1 Micro-loop Prevention Using Remote LFAPs 153 S----------------A------------------B 154 | | 155 | | 156 | | 157 | | 158 E-----------------------------------D 159 | | 160 | | 161 | | 162 | | 163 F-----------G-----------H-----------J 165 Figure 1: Micro-loop prevention with rLFAP (link E-D fails) 167 An example link failure scenario is shown in Figure 1, where link 168 metrics are unity (i.e., hop-count). The primary path from S to D is 169 S-E-D before link E-D fails. After E detects the failure, IPFRR 170 switches instantly over the shortest alternate path E-S-A-B-D. 171 In this case, a micro-loop is formed between S and E and will cause 172 network disruption until a new primary path S-A-B-D converges if 173 none of the techniques in Ref. [2] is employed. However, rLFAP 174 immediately starts using LFAP S-A-B-D when S is notified about the 175 failure of link E-D. Note that LFAP S-A-B-D is pre-computed at S to 176 protect against the failure of link E-D (this is a remote link 177 failure from router S point of view and the path S-A-B-D is a remote 178 LFAP from link E-D point of view). 180 2.2 Handling Multiple Simultaneous Failures 182 S-----------A-----------B-----------C 183 | | 184 | | 185 | | 186 | | 187 E-----------------------F-----------D 188 | | 189 | | 190 | | 191 | | 192 G-----------------------H 194 Figure 2: A simple topology with unit link costs demonstrating 195 rLFAP's capability for handling multiple simultaneous failures 196 (links E-F and H-F fail at the same time) 198 Figure 2 shows a scenario where two link failures (links E-F and H- 199 F) occur. Using IPFRR, E switches over the shortest alternate 200 path E-G-H-F-D as soon as it detects the failure of link E-F. 201 However, after the switchover, H sends all packets coming from the 202 source E back to G since link H-F also failed. The micro-loop 203 between E and H should be resolved. After resolving the micro-loop 204 between E and H, another micro-loop between E and S should also be 205 resolved to enable successful reroute. If S is notified about these 206 two link failures, then the best LFAP S-A-B-C-D can be utilized 207 quickly (X=3 is needed in this scenario). The number of LFAPs needed 208 for the multiple link failures will not be scalable if they are 209 required to be pre-computed by each router for any combination of 210 failures within the entire network. However, rLFAP only needs to 211 protect failures within its MNBs (explained in Section 3.1); 212 therefore rLFAP significantly enhances the IPFRR scalability in 213 resolving micro-loops in case of multiple failures (e.g., compared 214 to the NOT-VIA mechanism [6]). 216 2.3 Distinguishing Link and Node Failures 218 A------------B-------------C 219 | | | 220 | | | 221 | | | 222 | | | 223 S------------E-------------D 224 \ / 225 \ / 226 \ / 227 \ / 228 \ / 229 \ / 230 F 232 Figure 3: rLFAP's ability to distinguish link and node failures 233 (either link S-E or router E fail) 235 Another important rLFAP feature is the ability to distinguish 236 between link and node failures. Figure 3 shows an example topology 237 with unit link costs for demonstrating the rLFAP's ability to 238 distinguish link and node failures. The primary path from S to D is 239 S-E-D before any failure. Initially, a router assumes that it is a 240 link failure whenever its communication to a neighboring node is 241 disrupted (e.g., S detects that it can't reach node E through link 242 S-E). In this case, the pre-computed LFAP S-F-E-D will be activated 243 immediately without waiting for distinguishing whether it is a link 244 or node failure. However, if it is a router failure (e.g., node E 245 fails), the failure notification concept of rLFAP makes it possible 246 for routers to receive the failure notification from other 247 interfaces of the failed router (e.g., node S receives failure 248 notifications of links B-E and F-E using 2-hop (i.e., X=2) failure 249 notification mechanism). Upon detection of router's failure, the 250 pre-computed LFAP S-A-B-C-D is activated. Hence, in rLFAP, routers 251 can distinguish between link and node failures. The significance of 252 this feature is supported by the recent work by Gjoka et. al. [7], 253 which shows that the failure coverage of the fast reroute mechanisms 254 is different for link and node failure cases. 256 3. Design Details 258 rLFAP achieves loop-free convergence by introducing two additional 259 mechanisms on top of IPFRR: multi-hop failure notification and remote 260 alternate paths (remote LFAPs or SAPs) for protecting against 261 failures at multi-hop routers. Apart from these mechanisms, rLFAP 262 implements all its functionalities using the IPFRR framework [1]. In 263 this section, we first describe multi-hop neighborhoods (MNBHs) which 264 limit the number of the required remote LFAPs/SAPs for 265 scalability. And then, two fast failure notification mechanisms and 266 LFAP calculations for local and remote failures within MNBH are 267 presented. It is crucial for all fast reroute mechanisms that the 268 underlying dynamic routing protocol should converge back to its 269 optimum routes without causing micro-loops once the topology change 270 is disseminated to all routers in the network. rLFAP provides a fast 271 re-convergence from LFAPs to the optimum new routes by utilizing 272 new routes shortly after they are calculated. 274 3.1 Multi-hop Neighborhood (MNBH) 276 N11----N12----N13----N14----N15----N16----N17 277 | | | | | | | 278 | | | | | | | 279 N21----N22----N23----N24----N25----N26----N27 280 | | | | | | | 281 | | | | | | | 282 N31----N32----N33----N34----N35----N36----N37 283 | | | | | | | 284 | | | | | | | 285 N41----N42----N43----N44----N45----N46----N47 286 | | | | | | | 287 | | | | | | | 288 N51----N52----N53----N54----N55----N56----N57 289 | | | | | | | 290 | | | | | | | 291 N61----N62----N63----N64----N65----N66----N67 292 | | | | | | | 293 | | | | | | | 294 N71----N72----N73----N74----N75----N76----N77 296 Figure 4: An example network 298 Figure 4 shows an example network consists of 49 nodes. A node on 299 the boundary has two neighbors if it is located on one of four 300 corner positions (e.g., N11); otherwise three neighbors (e.g., N12). 301 A non-boundary node has four neighbors (e.g., N22) irrespective of 302 its location. The issue is to decide the structure of two adjacent 303 MNBHs: overlapping or non-overlapping. Inconsistencies or micro- 304 loops may arise on boundaries of adjacent MNBHs if they are 305 non-overlapping since each MNBH has only a partial view of the 306 global topology (e.g., failures close to the boundary of adjacent 307 MNBHs). Also, an additional mechanism is needed to explicitly 308 maintain the boundaries if multi-hop NHs are non-overlapping. 309 Therefore, rLFAP uses overlapping MNBHs. 311 | 312 | 313 ----N24---- 314 | | | 315 | | | 316 ----N33----N34----N35---- 317 | | | | | 318 | | | | | 319 ----N42----N43----N44----N45----N46---- 320 | | | | | 321 | | | | | 322 ----N53----N54----N55---- 323 | | | 324 | | | 325 ----N64---- 326 | 327 | 329 Figure 5: 2-hop MNBH for N44 331 The MNBH for each node only defines a local scope within which to 332 propagate failure notifications. For example, 2-hop (i.e., X-hop 333 where X=2) MNBH of N11 consists of nodes together with their all 334 links which are at most 2-hop away from N11. These nodes include N12, 335 N13, N21, N22, and N31; and hence, there are 5 nodes and 11 links 336 within 2-hop MNBH of N11. However, N44's 2-hop MNBH includes 12 nodes 337 and 36 links as shown in Figure 5. N44 has to calculate separate 338 LFAPs/SAPs for each destination in the network to protect against 339 link/node failures within its MNBH. Since MNBHs are overlapping and 340 define only a local scope for each node, no additional mechanism is 341 needed to explicitly maintain the MNBHs in the network (e.g., a 342 simple flooding mechanism similar to OSPF LSAs but limited to X-hop 343 away routers is sufficient for maintaining MNBHs). Each node takes 344 its best fast reroute action independently in case of a failure 345 within its MNBH. Minimal inconsistencies (hence micro-loops) are 346 expected as a result of each node's independent decision since two 347 overlapping MNBHs' partial topologies have a lot common information. 349 3.2 Alternate Path Calculation 351 We describe the alternate path calculation methodology for the node 352 N44 in Figure 5. Other nodes in the network repeat the same steps 353 but using their own MNBHs. For simplicity, we assume that only a 354 single link failure occurs. 356 N44 has four local links. For each local link LL_k (k=1,2,3,4), the 357 following calculations are done per each destination Nij 358 (i=1,2,3,5,6,7 and j=1,2,3,5,6,7): 359 - Remove LL_k from the topology to anticipate the failure 360 - Calculate the shortest path to Nij using the new topology. If 361 the new shortest path to Nij (after the failure) is the same as 362 the primary path to Nij (before the failure) then break (do not 363 perform the following three steps). Do not store any alternate 364 path to Nij for the failure of LL_k. If the primary path to Nij 365 before the failure has equal cost multipaths (ECMPs) and at 366 least one of these ECMPs is affected from the failure, then 367 the following three steps should also be performed. 368 - Calculate three local shortest alternate paths (SAPs) via 369 immediate neighbors to Nij (there are three immediate neighbors 370 after the link failure and therefore three SAPs need to be 371 calculated). Here SAP is defined as the shortest distance path to 372 Nij via an immediate neighbor calculated by the Djikstra 373 algorithm after removing LL_k from the topology 374 - Store the shortest local LFAP among these three local SAPs (if 375 LFAP exists) and modify the entry, corresponding to this 376 source-destination pair, in the path safety matrix. This matrix 377 keeps track of loop-free source-destination pairs which will be 378 used during the remote LFAP calculation 380 A similar method will be used for calculating remote alternate 381 paths. N44 has 32 remote links within its MNBH. For each remote link 382 RL_k (k=5,6,...,32), the following calculations are done per each 383 destination Nij (i=1,2,3,5,6,7 and j=1,2,3,5,6,7): 384 - Remove RL_k from the topology to anticipate the failure 385 - Calculate the shortest path to Nij using the new topology. If the 386 shortest path to Nij is the same as the primary path to Nij 387 then break (do not perform the following three steps). Do not 388 store any alternate path to Nij for the failure of RL_k 389 - Calculate four remote shortest alternate paths (SAPs) via 390 immediate neighbors to Nij (since RL_k is not a local interface 391 there are four immediate neighbors for this node). 392 - Store the shortest remote LFAP among these four remote SAPs and 393 update the path safety matrix if any LFAP exists. If there is no 394 LFAP, then check the path safety matrix if there is any neighbor 395 which has a loop-free path to this destination indicated by 396 the path safety matrix. If there is/are such neighbor(s), then 397 use the shortest one as remote LFAP and update the corresponding 398 entry in the path safety matrix. 400 The above algorithms make sure that a local or remote alternate 401 path will be stored only if the primary path does not function 402 anymore after the failure. Therefore, rLFAP stores only the 403 required alternate paths and is scalable. Note that routers only 404 store alternate next-hops (not the alternate path itself). 406 3.3 Fast Failure Notification Mechanism 408 The objectives of a multi-hop failure notification mechanism are as 409 follows: 410 - Routers should be notified about failures as fast as possible to 411 minimize the reroute delay from the primary path to an LFAP 412 - Failure notification should create minimal overhead in terms of 413 bandwidth consumption. For example, generating too many LSA 414 packets in OSPF consumes the available bandwidth and may cause 415 disruption in other parts of the network beyond the failure 416 point 417 - A solution which does not require modifications to the 418 underlying routing protocol is preferable 419 - A failure notification should not cause the network instability 420 under some worst-case scenarios (e.g., sending too many OSPF LSA 421 messages for transient failures (link flapping) may cause the 422 network instability) 424 There are two options for the multi-hop failure notification in 425 rLFAP when a router detects a local failure: 426 1) Configuring routing protocol's parameters for the fast failure 427 propagation by relying on periodic link state updates (e.g., 428 LSAs for OSPF and LSPs for IS-IS) 429 2) Implementing a new efficient fast failure notification mechanism 430 within the MNBH 432 3.3.1 Configuring Routing Protocol's Parameters 434 rLFAP is proposed initially for link state IGPs, where link state 435 update packets are LSAs in OSPF and LSPs in IS-IS. For simplicity, we 436 describe the concept for OSPF; all the procedures are applicable to 437 IS-IS as well. This option does not introduce a new signaling 438 mechanism but optimizes the existing link state update mechanisms for 439 rLFAP's performance efficiency. 441 The flooding procedure by which OSPF distributes LSAs is reliable. A 442 router packages its new LSA within a link state update packet (may 443 contain multiple distinct LSAs) and transmits it on each of its 444 interfaces which are in the same OSPF area impacted by the LSA. Each 445 recipient acknowledges the router from which the LSA was received, 446 repackages the LSA within a new link state update packet and sends 447 it out on each of its interfaces except for the interface on which 448 the LSA was received. 450 When the content of an LSA changes, a new LSA is originated 451 [8]. However, two instances of the same LSA may not be originated 452 within the time period MinLSInterval. This may require that the 453 generation of the next instance may be delayed by up to 454 inLSInterval. Although MinLSInterval is an architectural constant 455 (default is 5 secs), implementations could make this interval 456 configurable in order to speed up the failure propagation [12]. 458 Ref. [9] studies how to achieve sub-second IGP convergence in large 459 IP networks by configuring the routing protocol parameters. Ref. 460 [10] shows that minLSInterval around 20-30 ms does not generate much 461 overhead while providing fast failure propagation to multi-hop 462 routers. Based on these studies, we suggest that minLSInterval which 463 is around 20-30 ms will provide rLFAP with fast failure notification 464 mechanism due to the MNBH, where the maximum number of hops between 465 two nodes in which one node includes another within its MNBH is 466 limited to X hops. Note also that this interval limits the successive 467 generations of the same LSA. The maximum delay (i.e., 20-30 ms) is 468 realized only if there are two successive topology changes in which 469 the second failure occurs just after an LSA for the first failure is 470 generated. 472 3.3.2 An Efficient Failure Flooding Mechanism within MNBH 474 For the stable wired backbone networks, configuring routing 475 protocols' parameters for fast failure notification will neither 476 create much additional signaling overhead nor network instability 477 since transient failures (i.e., link flapping) are rarely occured in 478 these networks. However, for wireless mobile ad-hoc or backbone 479 networks, the drawback of configuring the routing protocol's 480 parameters for fast failure propagation is that the routing protocol 481 overhead will be enormous in the case where frequent transient 482 failures (e.g., link flapping) occur. This overhead is due to too 483 many LSA updates which are generated for each transient topology 484 change and flooded to the entire network. The frequent transient 485 failures may also cause the network instability since the routing 486 protocol may repeat shortest path calculations and FIB updates too 487 frequently for each topology change without allowing a common 488 convergence. 490 The LSA flooding scope is more explicit in OSPF IPv6 and appears in 491 the LS type field [13]. There are three separate flooding scopes for 492 LSAs: 493 - Link-local scope: LSA is flooded only on the local link and no 494 further. 495 - Area scope: LSA is flooded only throughout a single OSPF area. 496 - AS scope: LSA is flooded throughout the routing domain. 498 However, rLFAP needs LSA's scope to be configurable to its MNBH and 499 none of these scopes satisfies this requirement. Moreover, an LSA is 500 needed by the routing protocol and should be at least flooded within 501 the same OSPF area. 503 Therefore, another option for the fast failure notification mechanism 504 in rLFAP is to implement a new flooding procedure within MNBH which 505 minimizes routing protocol instability and overhead. The new flooding 506 mechanism defines a new link update packet (LUP) which is similar to 507 LSA in OSPF but includes two new fields: Time-To-Live (TTL) and 508 Stop-Flooding (SF) bit. TTL indicates the maximum number of hops a 509 new LUP will be transmitted. The transmission is stopped if TTL field 510 is zero and SF is one (i.e., true). SF decides whether the flooding 511 of LUP will continue beyond the MNBH. A router continues flooding an 512 LUP within the MNBH irrespective of its SF value. However, if TTL is 513 zero, then a router continues the flooding procedure only if the 514 LUP's SF value is zero (i.e., false). An intermediate router changes 515 SF value to one if LFAPs, which protect against this particular 516 failure described in LUP, are found for all destinations in the 517 network. An intermediate router is not allowed to change SF value 518 from one to zero because the SF value 1 indicates that LFAPs are 519 found for all destinations (i.e., full coverage). 521 LUP has its own timers for controlling its new packet generation and 522 flooding mechanism. This is another reason for introducing a new 523 packet format since the timers for controlling LSA flooding can not 524 be set independently for each LSA. The rLFAP flooding procedure 525 will be the same as OSPF's flooding procedure but with the following 526 modifications: 527 - Parameters (e.g., timers) for the LUP flooding are set to 528 aggressive values for fast failure notifications while parameters 529 for LSAs are set to relatively conservative for minimizing the 530 routing protocol instability and overhead. 531 - Each router sets TTL field to the number of maximum hops defined 532 by the MNBH (i.e., parameter X in X-hop MNBH) and SF bit to 0 533 upon generation of a new LUP packet. 534 - Each recipient of a LUP packet decrements TTL and sets SF bit to 535 1 if all required LFAPs are found and then transmits it on each 536 of its interfaces except for the interface on which the LUP was 537 received only if TTL field is nonzero. 538 - Each recipient which observes zero TTL field continue the 539 flooding procedure if SF bit is still zero; otherwise stops the 540 flooding procedure. 542 There are two advantages in this method: i) minimal routing overhead 543 since flooding LUP update messages are limited to MNBH, ii) fast 544 failure notification since the parameters of the flooding procedure 545 (e.g., timers) can be set independently from the routing protocol's 546 flooding mechanism's parameters. This efficient flooding mechanism 547 is expected to substantially decrease the amount of additional 548 overhead and routing protocol instability, which are observed during 549 the transient failures, while fast failure notifications are still 550 provided. 552 3.4 Remote LFAPs and Scalability 554 In rLFAP, remote LFAPs are calculated only to protect against node 555 and link failures within the MNBH. Therefore, the number of 556 LFAPs for a single failure scenario will not be an important issue 557 in terms of scalability. 559 However, in case of protecting against multiple failures, the number 560 of pre-computed LFAPs to protect against some combinations of these 561 failures might not be scalable in rLFAP depending on the depth of 562 the MNBH (i.e., parameter X) and the average number of links for 563 each node. Our design utilizes the concept of KEYLINKS introduced 564 in Ref. [14] for the purpose of handling this scalability problem. 565 The main idea behind KEYLINKS is that LFAP for a certain 566 destination is needed only if the primary path fails. Therefore, 567 each node maintains what nodes/links in its MNBH are used for 568 reaching a certain destination and calculates an LFAP only for the 569 links on its primary path (i.e., LFAP, which is needed only if at 570 least one of the links on the primary path fails, should not use any 571 of multiple failures). Maintaining key links and nodes adds 572 additional complexity while the gain is obtained in terms of 573 scalability (i.e., fewer LFAPs need to be pre-computed and stored). 574 For example, N44's 2-hop MNBH includes 12 nodes and 36 links as 575 shown in Figure 5. For a certain destination, assume that 2 nodes 576 and 3 links from the 2-hop MNBH of N44 are on the primary path. 577 Therefore, LFAPs are needed only to protect against 5 members (5 578 LFAPs) instead of 48 members (48 LFAPs) of the 2-hop MNBH for a 579 single failure scenario. This reduction for a single destination is 580 significant since each node needs to pre-compute LFAPs for all 581 possible destinations in the network. 583 3.5 Routing Convergence from LFAPs to New Primary Paths 585 It is crucial for all fast reroute mechanisms that the underlying 586 dynamic routing protocol should converge to its new optimum routes 587 once the topology change is disseminated to all routers in the 588 network. The loops can still form in this phase if the FIB updates 589 are not done in the right order. 591 In rLFAP, all nodes within the MNBH have pre-computed alternate 592 paths protecting against the failures within the MNBH. This makes 593 sure that all nodes within the MNBH are aware of these failures 594 and therefore their current routes do not include the failed 595 resources. This feature provides a flexibility of timely switching 596 back to new primary paths when new paths are calculated by the 597 routing protocol. rLFAP switches back to new primary paths after 598 waiting for a constant delay representing the rLFAP convergence 599 time within the MNBH (this delay starts after new paths are found 600 by the routing protocol). 602 Another important feature of rLFAP is that the minimum number of 603 next hop changes is expected during switching from LFAPs to new 604 primary paths of the dynamic routing protocol. The reason is that 605 the next hop change will occur only if the next hop in the new 606 primary path is different than the next hop in the alternate path. 607 Due to the MNBH concept, it is conjectured that the next hops for 608 LFAPs and the new primary paths will be the same with a high 609 probability and the minimum number of FIB updates is expected 610 during switching from LFAPs to new primary paths. Our initial 611 analysis shows that 613 3.6 Applicability of rLFAP Mechanism to Support Fast PIM-SM Tree 614 Repair 616 Protocol Independent Multicast - Sparse Mode (PIM-SM) [16] is a 617 widely available multicast protocol that achieves efficient 618 distribution of multicast content through on-demand construction of 619 shared trees and shortest path trees. Key to its efficiency is its 620 use of Join messages to build the multicast tree from the multicast 621 group members towards the Rendezvous Point (RP) or the content 622 source for the cases of shared trees and shortest path trees (SPTs), 623 respectively. 625 Unfortunately, PIM-SM reacts to link failure events even more slowly 626 than the underlying routing protocol (e.g., OSPF, IS-IS, etc.). 627 Specifically, not only must the underlying unicast routing protocol 628 converge to reflect the degraded network topology, but the 629 appropriate PIM Join messages must be sent, received, and processed 630 before multicast tree repair is completed. Furthermore, depending 631 on the router implementation, PIM-SM may not even recognize a 632 change in the underlying unicast paths for several seconds when 633 time-based events are used to trigger the PIM-SM process to compare 634 the current routing information for changes that impact the reverse 635 path forwarding (RPF) to RPs and multicast sources. 637 The rLFAP features can help speed up PIM-SM tree repair by 638 accelerating the convergence to correct RPF information about a 639 failure at affected nodes in the LUP TTL MNBH. To illustrate 640 potential benefits of the rLFAP mechanism in the context of PIM-SM, 641 the topology of Figure 2 is considered again. Here, however, Node S 642 is supposed to denote the source node for packets to be delivered by 643 an SPT to the multicast group Z comprising Nodes D and G. The SPT 644 constructed by PIM-SM (assuming unit cost links) is shown in Figure 645 6. 647 S A B C 648 | 649 | 650 | 651 | 652 E-----------------------F-----------D 653 | 654 | 655 | 656 | 657 G H 659 Figure 6: SPT constructed by PIM-SM for multicast group Z = (D,G) 660 with source node S based on the topology of Figure 2 (links not 661 part of the SPT are omitted from the figure). 663 Now, per the scenario of Figure 2, it is assumed that links E-F and 664 F-H of Figure 2 fail at the same time. However, when the LUP 665 originated by Node F arrives at Node D, D will recognize that the RPF 666 to S has changed and D will use the pre-computed LFAP to S via the 667 link D-C as the link for the new RPF to S. The processing described 668 thus far is native to the rLFAP mechanisms already presented herein. 669 In order to complete the speed-up of PIM-SM tree repair, routers 670 employing rLFAP mechanisms MUST trigger the PIM-SM process to check 671 the impact on RPF information of those multicast groups for which 672 PIM-SM state is maintained locally whenever a LUP is received and 673 processed. In doing so, the PIM-SM process will learn of the new 674 correct RPF information for affected multicast groups within 675 milliseconds of the received LUP being processed. The PIM-SM 676 implementation MUST then immediately issue the appropriate (*,G) 677 and/or (S,G) Join messages. For the scenario of Figure 6, Node D 678 will issue a (S,G) Join message to its PIM neighbor Node C via the 679 link D-C which, in turn, sends a Join message to Node B, and so 680 forth. The resulting repaired PIM-SM SPT for Group Z is shown in 681 Figure 7. 683 S-----------A-----------B-----------C 684 | | 685 | | 686 | | 687 | | 688 E F D 689 | 690 | 691 | 692 | 693 G H 695 Figure 7: Reconstructed by PIM-SM for multicast group Z = (D,G) 696 following fast tree repair based on LUPs originated by Node F (links 697 not part of the SPT are omitted from the figure). 699 A few additional points regarding the illustrative scenario of 700 Figures 6 and 7 are worth noting. First, the routing instance at 701 Node F does not originate a new Join message for Group Z as it is no 702 longer "upstream" to Group Z members. That is, a router applying 703 the rLFAP mechanism to speed up PIM-SM tree repair SHOULD suppress 704 sending PIM Join messages if the neighbors for which it maintained 705 Join state are no longer "downstream" from it with respect to the 706 source. Second, the illustrative scenario given here applies without 707 loss of generality to RP-based (i.e., shared) trees: The only 708 difference being (in the example here) that Node D would issue a 709 (*,G) Join message to repair its branch of the multicast tree. Last, 710 the SPT branch going to multicast group member G was not affected by 711 the link failures and, therefore, LUPs originated by Nodes E and H 712 received at Node G (correctly) did not initiate tree repair. 714 4. Experimental Results 716 4.1 LFAP Coverage Analysis 718 We performed the coverage analysis of the fast reroute mechanism 719 presented here on realistic topologies, which were generated by the 720 BRITE topology generator in bottom-up mode [17]. The LFAP coverage 721 percentage is defined here as the percentage of the number of LFAPs 722 for protecting the primary paths which are failed because of link 723 failures to the number of all failed primary paths. Only local LFAPs 724 are considered in the coverage calculation for the neighborhood depth 725 of 0 (i.e., X=0) while both local and remote LFAPs are taken into 726 account when the neighborhood depth is set to a value greater than 0 727 (i.e., X>0). 729 The realistic topologies include AT&T and DFN using pre-determined 730 BRITE parameter values from Ref.[17] and various random topologies 731 with different number of nodes and varying network connectivity. For 732 example, the number of nodes for AT&T and DFN are 154 and 30, 733 respectively, while the number of nodes for other random topologies 734 is varied from 20 to 100. The BRITE parameters which are used in our 735 topology generation process are summarized in Figure 10 (see Ref.[17] 736 for the details of each parameter). In summary, m represents the 737 average number of edges per node and is set to either 2 or 3. A 738 uniform bandwidth distribution in the range 100-1024 Mbps is selected 739 and the link cost is obtained deterministically from the link 740 bandwidth (i.e., inversely proportional to the link bandwidth as used 741 by many vendors). Since the values for p(add) and beta determine the 742 number of edges in the generated topologies, their values are varied 743 to obtain network topologies with varying connectivity (e.g., sparse 744 and dense). 746 |----------------------------|-----------------------| 747 | | Bottom up | 748 |----------------------------|-----------------------| 749 | Grouping Model | Random pick | 750 | Model | GLP | 751 | Node Placement | Random | 752 | Growth Type | Incremental | 753 | Preferential Connectivity | On | 754 | BW Distribution | Uniform | 755 | Minimum BW | 100 | 756 | Maximum BW | 1024 | 757 | m | 2-3 | 758 | Number of Nodes (N) | 20,30,50,100,154 | 759 | p(add) | 0.01,0.05,0.10,0.42 | 760 | beta | 0.01,0.05,0.15,0.62 | 761 |----------------------------|-----------------------| 763 Figure 10: BRITE topology generator parameters 765 The coverage percentage of our fast reroute method is reported for 766 different network topologies (e.g., different number of nodes and 767 varying network connectivity) using neighborhood depths of 0, 1, 768 and 2. (i.e., X=0, 1, and 2). For a particular failure, LFAPs 769 protecting the failed primary paths are calculated only by those 770 nodes which are within the multi-hop neighborhood of this failure. 771 Note that these nodes are determined by the parameter X as follows: 772 For X=0, two nodes which are directly connected to the failed link, 773 for X=1, two nodes which are directly connected to the failed link 774 and also neighboring nodes which are adjacent to one of the 775 outgoing links of these two nodes, and so on. 777 The LFAP coverage percentage for a certain topology is computed by 778 the following formula: LFAP Coverage Percentage = N_lfaps*100/N_fpp 779 where N_lfaps is the number of source-destination pairs whose 780 primary paths are failed because of link failures and have LFAPs for 781 protecting these failed paths, and N_fpp is the number of 782 source-destination pairs whose primary paths are failed because of 783 link failures. The source-destination pairs, in which source and 784 destination nodes do not have any physical connectivity after a 785 failure, are excluded from N_fpp. Note that the coverage percentage 786 includes a network-wide result which is calculated by averaging all 787 coverage results obtained by individually failing all edges for a 788 certain network topology. 790 Figure 11 shows the LFAP coverage percentage results for random 791 topologies with different number of nodes (N) and network 792 connectivity, and Figure 12 shows these results for AT&T and DFN 793 topologies. In these figures, E_mean represents the average number 794 of edges per node for a certain topology. Note that the average 795 number of edges per node is determined by the parameters m, p(add), 796 and beta. We observed that E_mean increases when p(add) and beta 797 values increase. For each topology, LFAP coverage analysis is 798 repeated for 10 topologies generated randomly by using the same 799 BRITE parameters. E_mean and LFAP coverage percentage are 800 obtained by averaging the results of these ten experiments. 802 |------------|-----|------|------|------|------| 803 | Case |N |E_mean|X=0 |X=1 |X=2 | 804 |------------|-----|------|------|------|------| 805 |p(add)=0.01 |20 |3.64 |82.39 |98.85 |100.0 | 806 |beta=0.01 |50 |3.86 |82.10 |98.69 |100.0 | 807 | |100 |3.98 |83.21 |98.04 |100.0 | 808 |------------|-----|------|------|------|------| 809 |p(add)=0.05 |20 |3.70 |85.60 |99.14 |100.0 | 810 |beta=0.05 |50 |4.01 |84.17 |99.09 |100.0 | 811 | |100 |4.08 |83.35 |98.01 |100.0 | 812 |------------|-----|------|------|------|------| 813 |p(add)=0.1 |20 |5.52 |93.24 |100.0 |100.0 | 814 |beta=0.15 |50 |6.21 |91.46 |99.87 |100.0 | 815 | |100 |6.39 |91.17 |99.86 |100.0 | 816 |------------|-----|------|------|------|------| 818 Figure 11: Coverage percentage results for random topologies 820 |------------|-----------|------|------|------|------| 821 | Case |N |E_mean|X=0 |X=1 |X=2 | 822 |------------|-----------|------|------|------|------| 823 |p(add)=0.42 |154 (AT&T) |6.88 |91.04 |99.81 |100.0 | 824 |beta=0.62 |30 (DFN) |8.32 |93.76 |100.0 |100.0 | 825 |------------|-----------|------|------|------|------| 827 Figure 12: Coverage percentage results for AT&T and DFN topologies 829 There are two main observations from these results: 831 1. As the neighborhood depth (X) increases the LFAP coverage 832 percentage increases and the complete coverage is obtained using 833 a low neighborhood depth value (i.e., X=2). This result is 834 significant since failure notification message needs to be sent 835 only to nodes which are two-hop away from the point of failure 836 for the complete coverage. This result supports that our method 837 provides fast convergence by introducing minimal signaling 838 overhead within only the two-hop neighborhood. 840 2. The topologies with higher connectivity (i.e., higher E_mean 841 values) have better LFAP coverage compared to the topologies 842 with lower connectivity (i.e., lower E_mean values). This is 843 an intuitive result since the number of possible alternate hops 844 in dense network topologies is higher than the number of 845 possible alternate hops in sparse topologies. This phenomenon 846 increases the likelihood of finding LFAPs, and therefore the 847 LFAP coverage percentage. 849 4.2 Convergence Analysis Based on Testbed Experiments 851 F-----------E------------A------------| 852 | | | | 853 | | | | 854 | | | | 855 | | | | 856 G-----------D------------| B 857 | | 858 | | 859 | | 860 | | 861 C-------------------------| 863 Figure 13: 7-node network topology for local LFAP convergence 864 experiments 866 F-----------E------------A------------| 867 | | | 868 | | | 869 | | | 870 | | | 871 G-----------D B 872 | | 873 | | 874 | | 875 | | 876 C-------------------------| 878 Figure 14: 7-node network topology for remote LFAP convergence 879 experiments 881 We performed the convergence analysis of our new fast reroute 882 presented here using 7-node network consisting of 2600 and 3600 883 series Cisco routers as shown in Figures 13 and 14. Link costs are 884 set to the same value for all links. A dedicated computer 885 (e.g., an agent), which is running our fast reroute technology, 886 is connected to each router through an Ethernet cable. These 887 agents obtain the network topology from the routers in real-time 888 by issuing an SNMP request. Using the retrieved network topology 889 information, a set of LFAPs, which protects the failed primary 890 paths when a real failure occurs, is pre-computed and stored. For 891 both networks, the link between routers A and E is failed for all 892 experiments. 894 The convergence time on the alternate path is measured by running 895 a session, similar to a ping application, between routers A and E. 896 When the link between routers A and E is failed on the topology as 897 shown in Figure 13, the primary path A-E (and hence the session 898 between them) fails. Once the failure is detected, the router A (E) 899 reroutes its traffic over the alternate path A-D-E (E-D-A) by 900 installing its pre-computed local LFAP. However, when the same 901 scenario is applied to the topology in Figure 14, there is no local 902 LFAP in the router A (E) to protect the primary path A-E (E-A) for 903 this failure. For the above scenario, our fast reroute technology 904 propagates the failure information to router B (D) which is 905 already pre-computed a set of remote LFAPs for this particular 906 failure. As a result, the session is rerouted through the 907 alternate path A-B-C-D-E (E-D-C-B-A). 909 For both local and remote LFAP scenarios, the experiments are 910 repeated for 10 times. The mean convergence time for the local LFAP 911 scenario is 602 milliseconds while the mean convergence time for 912 the remote LFAP scenario is 612 milliseconds. Note that LFAPs are 913 stored in the agents which are external to the routers. These agents 914 issue an IOS command to install the right set of LFAPs when a 915 failure is detected. In reality, the agent technology should run 916 in the router as a GPP and LFAPs should be installed beforehand 917 and waiting for a failure signal to be activated. Therefore, the 918 results should be used to compare the difference between local and 919 remote LFAPs rather than their absolute values. 921 The convergence times do not include the failure detection time 922 since our primary objective in these experiments is to compare local 923 and remote LFAP rather than proposing a new failure detection 924 mechanism. For the sake of experiments, we implemented a heuristic 925 based failure detection mechanism using periodic light-weight 926 hearbeat messages similar to the Bidirectional Forwarding Detection. 927 Note that the alternate path between A and E in the remote LFAP 928 scenario is longer (A-D-E vs. A-B-C-D-E). The failure information is 929 reached to one-hop neighbor within a few milliseconds since the round 930 trip time between two neighboring agents is measured around 1-2 931 milliseconds. These results indicate that the convergence time of the 932 remote LFAP mechanism is only slightly higher compared to the only 933 local LFAP mechanism due to the failure notification. This increase 934 is bounded by the neighborhood depth times a few milliseconds. 935 However, the remote LFAP significantly increases the alternate path 936 coverage since there is no local LFAP to protect the session between 937 routers A and E when the link between routers A and E fails in 938 Figure 14. 940 5. Scope and Applicability 942 This work is proposed initially for link state IGPs (i.e., OSPF and 943 IS-IS). Further study is needed for extending its applicability to 944 non-link state IGPs or BGP. 946 6. Acknowledgements 948 The authors would like to thank John Scudder, the co-chair of the 949 IETF RTGWG, for his valuable comments and suggestions on the 950 preliminary version of this draft. 952 7. References 954 Internet-drafts are works in progress available from 955 957 [1] M. Shand and S. Bryant, "IP Fast Reroute Framework", 958 draft-ietf-rtgwg-ipfrr-framework-06.txt, Oct. 2006 (work in 959 progress). 961 [2] S. Bryant and M. Shand, "A Framework for Loop-free Convergence", 962 draft-bryant-shand-lf-conv-frmwk-03.txt, Oct. 2006 (work in 963 progress). 965 [3] Alex Zinin, "Analysis and Minimization of Microloops in Link- 966 state Routing Protocols", draft-ietf-rtgwg-microloop-analysis- 967 01.txt, Oct. 2005 (work in progress). 969 [4] Francois et. al., "Loop-free convergence using ordered FIB 970 updates", , Oct. 2006 (work 971 in progress). 973 [5] S. Bryant, M. Shand, "IP Fast Reroute using tunnels", , Apr 2005 (work in progress). 976 [6] S. Bryant, M. Shand, and S. Previdi, "IP Fast Reroute Using Not- 977 via Addresses", , Oct. 2006 (Work in progress). 980 [7] M. Gjoka, V. Ram, and X. Yang, "Evaluation of IP Fast Reroute 981 Proposals", to appear in IEEE/Create-Net/ICST COMSWARE 2007. 983 [8] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 985 [9] P. Francois, C. Filsfils, J. Evans, and O. Bonaventure, 986 "Achieving sub-second IGP convergence in large IP network", 987 SIGCOMM Comput. Commun. Rev., 35(3):35-44, 2005. 989 [10] M. Pitkanen and M. Luoma, "OSPF Flooding Process Optimization", 990 Workshop on High Performance Switcing and Routing (HPSR), 991 pp.448-452, May 2005. 993 [11] G. Iannaccone et. al., "Analysis of link failures in an IP 994 backbone", in Proc. ACM Sigcomm Internet Measurement Workshop, 995 Nov. 2002. 997 [12] Cisco Systems, Inc., Cisco IOS IP Routing Protocols 998 Configuration Guide, Release 12.4. 1000 [13] R. Coltun, D. Ferguson, and J. Moy, "OSPF for IPv6", RFC 2740, 1001 December 1999. 1003 [14] S. Lee, Y. Yu, S. Nelakuditi, Z. Zhang, and C. Chuah, 1004 "Proactive vs. reactive approaches to failure resilient 1005 routing", Proc. INFOCOM 2004. 1007 [15] A. Atlas and A. Zinin, "Basic Specification for IP Fast- 1008 Rerorute: Loop-free Alternates", , March 2007 (work in progress). 1011 [16] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, "Protocol 1012 Independent Multicast (PIM-SM): Protocol Specification,"RFC 1013 4601, August 2006. 1015 [17] Oliver Heckmann et al., "How to use topology generators to 1016 create realistic topologies", Technical Report, Dec 2002. 1018 8. Authors' Addresses 1020 Ibrahim Hokelek 1021 Applied Research, 1022 Telcordia Technologies, Inc. 1023 RRC-1E313 1024 One Telcordia Drive, 1025 Piscataway, NJ 08854 1026 United States. Email: ihokelek@research.telcordia.com 1028 Mariusz A. Fecko 1029 Applied Research, 1030 Telcordia Technologies, Inc. 1031 RRC-1E326 1032 One Telcordia Drive, 1033 Piscataway, NJ 08854 1034 United States. Email: mfecko@research.telcordia.com 1036 Provin Gurung 1037 Applied Research, 1038 Telcordia Technologies, Inc. 1039 RRC-1D305 1040 One Telcordia Drive, 1041 Piscataway, NJ 08854 1042 United States. Email: pgurung@research.telcordia.com 1044 Sunil Samtani 1045 Applied Research, 1046 Telcordia Technologies, Inc. 1047 RRC-1P387 1048 One Telcordia Drive, 1049 Piscataway, NJ 08854 1050 United States. Email: ssamtani@research.telcordia.com 1052 Selcuk Cevher 1053 Applied Research, 1054 Telcordia Technologies, Inc. 1055 RRC-1A212 1056 One Telcordia Drive, 1057 Piscataway, NJ 08854 1058 United States. Email: cevhers@research.telcordia.com 1060 John Sucec 1061 Applied Research, 1062 Telcordia Technologies, Inc. 1063 RRC-1G313 1064 One Telcordia Drive, 1065 Piscataway, NJ 08854 1066 United States. Email: sucecj@research.telcordia.com 1068 Full Copyright Statement 1070 Copyright (C) The IETF Trust (2008). 1072 This document is subject to the rights, licenses and restrictions 1073 contained in BCP 78, and except as set forth therein, the authors 1074 retain all their rights. 1076 This document and the information contained herein are provided on an 1077 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1078 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1079 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1080 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1081 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1082 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1084 Intellectual Property 1086 The IETF takes no position regarding the validity or scope of any 1087 Intellectual Property Rights or other rights that might be claimed to 1088 pertain to the implementation or use of the technology described in 1089 this document or the extent to which any license under such rights 1090 might or might not be available; nor does it represent that it has 1091 made any independent effort to identify any such rights. Information 1092 on the procedures with respect to rights in RFC documents can be 1093 found in BCP 78 and BCP 79. 1095 Copies of IPR disclosures made to the IETF Secretariat and any 1096 assurances of licenses to be made available, or the result of an 1097 attempt made to obtain a general license or permission for the use of 1098 such proprietary rights by implementers or users of this 1099 specification can be obtained from the IETF on-line IPR repository at 1100 http://www.ietf.org/ipr. 1102 The IETF invites any interested party to bring to its attention any 1103 copyrights, patents or patent applications, or other proprietary 1104 rights that may cover technology that may be required to implement 1105 this standard. Please address the information to the IETF at 1106 ietf-ipr@ietf.org.