idnits 2.17.1 draft-andersson-reroute-frmwrk-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 1 form feeds but 7 pages 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. ** There are 28 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 187 has weird spacing: '...used to preve...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Loa Andersson 2 Brad Cain 3 Bilel Jamoussi 4 Nortel Networks 6 Requirement Framework for Fast Re-route with MPLS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Interest has recently grown in using MPLS for the creation of 32 engineered backup paths. To evaluate the merits of these proposals we 33 discuss the a framework of general requirements for fast re-route 34 schemes. This document attempts to document the areas against which 35 proposals can be considered. 37 1. Introduction 39 This memo describes a requirement framework for evaluation of MPLS 40 re-routing schemes. We discuss the areas where providers may have 41 specific requirements. This document does not propose a specific 42 re-route scheme but can be used as a framework for evaluation. 44 1.1. Background 46 Through the use of dynamic routing protocols, IP networks have the 47 capability to re-route traffic around node or link failures. 48 Using the current routing protocols this re-routing process may take 49 several seconds to minutes. During this period of time black holes or 50 transient loops may occur in the network, causing trafic delivery to 51 be interupted. For a certain types of applications (e.g. www, mail 52 and file tranfer) this is, if not optimal, at least acceptable. For 53 other applications (e.g. real time applications) it is greater 54 concern. The need to provide a much faster re-routing mechanism has 55 been identified. 57 Fast protection/re-route of LSP's in cases of link and/or node 58 failure by means of alternative label switched paths (LSP) 59 has been suggested [haskins] and [krishnan]. In [haskins] the 60 ability to quickly re-route data traffic around a failure or 61 congestion on a alternative label switched path is described. This 62 can be important for in mission critical applications. When a link or 63 node failure occurs, recovery is through the use of re-routing data 64 over an alternative path. Such alternative paths can be established 65 after a primary path failure is detected or, alternatively, it can be 66 established beforehand in order to reduce the path failover time. 68 1.2. Backup Schemes 70 In this section we explain the use of MPLS backup routing methods and 71 describe in general how these schemes work. 73 1.2.1. Definitions 75 MPLS backup schemes use secondary paths when routing on primary paths 76 is unavailable. We now define the definitions for these two terms: 78 - Primary path: We define the primary path as the path on which 79 the traffic is directed by the routing protocol or a TE 80 mechanism and which is (from some aspect) considered optimal 81 for that traffic. 83 - Secondary path: We define the secondary path as the path on 84 which the traffic is directed by the re-routing mechanism. 85 This is considered to be a potential sub-optimal. We 86 consider networks in which traffic is using secondary paths 87 to be in a semi-stable state. We also use the term "backup 88 path" to describe a secondary path. 90 ^L 92 1.2.2. Generalization of Schemes 94 MPLS backup schemes both establish backup paths and dynamically route 95 traffic to these paths during failures. We now discuss the components 96 of a backup schemes to frame the requirements. 98 - Path Algorithms: Backup paths can be either pre-established or 99 established dynamically (after a failure). Schemes may differ in 100 the types of algorithms used to compute backup paths as well as 101 whether the computation is on-line or off-line. 103 - MPLS Use: Closely related to the path algorithm is the manner in 104 which MPLS is utilized to construct and create the backup paths. 105 Schemes may differ in the use of bi-directional paths, 106 label-stacking, etc. 108 - Failure Detection: Once a failure is detected, a notification must be 109 sent to a router which either has a pre-established backup or can 110 dynamically establish one. Schemes may differ in how the 111 notification signal is propagated. For example, a notification 112 could be explicit (e.g. RSVP or LDP) or data driven. 114 1.2.3. The Recovery Cycle 116 We now present a generalized set of events which occur in a network 117 when a failure occurs when a re-routing mechanism is active. 119 1. Link/Node failure occurs 120 2. Failure is detected (signaling initiated) 121 3. Signaling indicating the failure arrives at an entity which 122 can perform the switch-over 123 4. The switch-over of traffic from the primary to the secondary 124 occurs 125 5. The network enters a semi-stable state 126 6. Dynamic routing protocols converge after failure 127 7. New primary paths are established (through dynamic protocols) 128 8. New secondary paths may be established 129 9. Traffic switched over to the new primary paths 131 While in the semi-stable state another failure might occur for the 132 secondary path, the cycle could, if the the secondary path is 133 protected, begin again. This however is a one way scheme, the 134 abandoned primary path is not taken in to operation again, unless 135 verified by the routing protocol after convergence. 137 ^L 139 2. Requirements for MPLS Re-Route 141 The traffic engineering of routed networks in general and the 142 fast re-route area in particular are emerging technologies. We see a 143 need for defining a set of general requirement areas by which MPLS 144 fast re-route schemes can be measured and evaluated. We specifically 145 do not specify and hard (e.g. numerical) requirements at this time 146 but give a framework for these specifications. 148 2.1. Backup restoration time 150 We define backup restoration time as the time required for a backup 151 path to be activated (and traffic flowing) after a failure. Backup 152 Restoration Time is the sum of the Detection Time and the Signal 153 Propagation Time. 155 - Detection Time: We define detection time as the time lapsed 156 between a failure of a node or link in the network and the time 157 that any *local* action (at the point of failure) is taken in 158 response to the failure. This time may be highly dependent on 159 lower layer protocols. 161 - Signal Propagation Time: We define signal propagation time 162 as the time laspsed between the detection time and the time 163 before a backup path is installed. An example of signal 164 propagation time is the time required to signal a failure 165 back to a node which can re-route traffic on a backup path. 167 2.2. Full Restoration Time 169 We define full restoration time as the time required for a suitable 170 semi-permanent restoration. This is the time required for traffic to 171 be routed onto links which are capable or have been engineered 172 sufficiently to handle excess traffic in failure scenarios. Note that 173 this time may or may not be different from the "Backup Restoration 174 Time" depending on the complexity of a scheme or the capacity of a 175 network. 177 A network that is in a semi-stable state (i.e. traffic flowing over 178 sub-optimal paths), may show deteriating service over time. The 179 network needs to be put back in a condition where "optimal paths" are 180 used. 182 2.3. Holddown Time 184 We define the holddown period as a bounded time for which 185 a backup path must be used. In some scenarios it may be difficult 186 to determine if the primary path is stable. In these cases a 187 holddown time may be used to prevent excess flapping of traffic 188 between a primary and secondary path. 190 ^L 192 2.4. Backup Capacity 194 Backup schemes may require differing amounts of "backup capacity" 195 in the advent of a failure. This capacity will be dependant on the 196 traffic characteristics of the network. However, it may also be 197 dependant on the particular backup path selection algorithms as well 198 as the signaling and re-routing methods. 200 2.5. Additive Latency 202 Backup schemes may introduce additive latency traffic. For example, 203 a backup path may take many more hops. This may be dependent on the 204 backup path selection algorithms as well as the signaling and 205 re-routing methods. 207 2.6. Failure Types 209 Backup schemes may account for only link failures or both node and 210 link failures. For example, a scheme may require more backup paths to 211 take node failures into account. 213 2.7. Re-ordering 215 Backup schemes may introduce re-ordering of packets. This occurs when 216 packets are re-routed back to the re-route point and fall behind 217 packets which are now already on the backup path. For example, 218 re-ordering may occur during detection and signaling time. Also the 219 action of putting traffic back on optimal paths might cause packet 220 re-ordering. 222 2.8. State Overhead 224 As the number of backup paths grows, the state required to maintain 225 them also grows. Schemes may require differing numbers of paths to 226 maintain certain levels of coverage, etc. The state required may 227 also depend on the particular scheme used to re-route packets. In 228 many cases the state overhead will be in proportion to the number of 229 backup LSPs. 231 2.9. Loss 233 Backup schemes may introduce a certain amount of packet loss during 234 switchover to a backup path. Schemes which introduce loss during 235 detection and signaling time can measure this loss by evaluating 236 restoration times in proportion to the link speed. 238 In case of link or node failure a certain packet loss is inevitable. 239 The packet loss is a function of packets per second times the full 240 restoration time. 242 ^L 244 2.10. Coverage 246 Backup schemes may offer various types of failover coverage. The 247 total coverage may be defined in terms of several metrics: 249 - Number of concurrent failures: dependent on the 250 layout of backup paths, multiple failure scenarios 251 may be able to be restored. 253 - Number of backup paths: for a given failure, there 254 may be one or more backup paths. 256 - Percentage of coverage: dependent on a scheme and 257 its implementation, a certain percentage of failures 258 may be covered. This may be subdivided into percentage 259 of link failures and percentage of node failures. 261 The number of protected LSP's will highly effect how fast the total 262 set of LSP's affected by a failure could be re-routed. The ratio of 263 protected is n/N, there n is the number of protected LSPs and N is the 264 total number of LSPs. 266 ^L 268 3. References 270 [haskin] Dimitry Haskin, Ram Krishnan "A Method for Setting an 271 Alternative Label Switched Paths to Handle Fast Reroute", 272 draft-haskin-mpls-fast-reroute-01.txt, 1999, Work in progress. 274 [krishnan] Dimitry Haskin, Ram Krishnan "Extensions to RSVP 275 to Handle Establishment of Alternate Label-Switched Paths 276 for Fast Re-route", 277 draft-krishnan-mpls-reroute-rsvpext-01.txt, 1999, Work in progress. 279 [makan] S. Makam, V. Sharma, K. Owens, C. Haung, "Protection/ 280 Restoration of MPLS Networks", 281 draft-makam-mpls-protection-00.txt, 1999, Work in progress. 283 4. Author's Addresses 285 Loa Andersson 286 Nortel Networks 287 St Eriksgatan 115, PO Box 6701 288 113 85 Stockholm, Sweden 289 phone: +46 8 50 88 36 34 290 e-mail: loa.andersson@nortelnetworks.com 292 Brad Cain 293 Email: bcain@baynetworks.com 294 Bilel Jamoussi 295 Email: jamoussi@nortelnetworks.com 296 Nortel Networks 297 3 Federal Street, BL3-03 298 Billerica, MA 01821, USA