idnits 2.17.1 draft-balls-ccamp-relax-loop-check-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to directly say this. It does mention RFC3209 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3209, updated by this document, for RFC5378 checks: 1998-11-20) -- 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 (November 19, 2012) is 4169 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP S. Balls, Ed. 3 Internet-Draft J. Hardwick 4 Updates: 3209 (if approved) Metaswitch 5 Intended status: Informational C. Margaria 6 Expires: May 23, 2013 Nokia Siemens Networks 7 November 19, 2012 9 Relaxing RSVP Loop Checking 10 draft-balls-ccamp-relax-loop-check-02 12 Abstract 14 This specification relaxes the rules governing loop checking within 15 RSVP. These were originally defined in RFC3209 and are too strict 16 for the requirements of today's data planes. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 23, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. General Overview . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Example in WDM networks . . . . . . . . . . . . . . . . . 3 56 2.2. Example using Connectivity Matrices . . . . . . . . . . . 4 57 2.3. Example with additional label restrictions . . . . . . . . 5 58 2.4. Example In Distributed Networks . . . . . . . . . . . . . 6 59 2.5. Example with Ingress Protection . . . . . . . . . . . . . 7 60 3. Existing workaround . . . . . . . . . . . . . . . . . . . . . 7 61 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Assumptions and limitations . . . . . . . . . . . . . . . 7 64 4.3. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 65 4.4. RRO handling . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.5. ERO handling . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.6. Interface handling . . . . . . . . . . . . . . . . . . . . 8 68 4.7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 81 Paths (LSPs) are prohibited from passing through a single node more 82 than once. Today's data planes are such that allowing spiral paths 83 through a control plane node should be allowed in order to set up 84 LSPs. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. General Overview 94 With today's data planes it is acceptable for a single data flow 95 (LSP) to pass through a single control plane node on more than one 96 occasion on the path from source to destination. Currently control 97 plane protocols will prevent such a path being managed in the control 98 plane as they explicitly detect this as a loop. However, this may 99 not necessarily be a loop in the data plane and it is desirable for 100 such LSPs to be able to be managed in the same way as non-looping 101 LSPs. This document refers to such LSPs as spiralling LSPs. 103 2.1. Example in WDM networks 105 In WDM networks it can be necessary to route the data via an 106 additional box in order to fulfil regeneration or wavelength 107 conversion requirements. For example, consider the following simple 108 example. 110 +-----+ +-----+ +-----+ 111 | | Link 1 | | Link 2 | | 112 | A |----------| B |----------| C | 113 | | | | | | 114 +-----+ +-----+ +-----+ 115 | | 116 | | 117 Link 3 | | Link 4 118 | | 119 | | 120 +-----+ 121 | | 122 | D | 123 | | 124 +-----+ 126 Figure 1 128 If node B cannot perform wavelength conversion but Link 1 and Link 2 129 do not have a common free wavelength then the only way to set up a 130 path from node A to node C will be via node D. This requires two 131 passes through node B which to RSVP looks like a loop, but is a 132 spiral. 134 2.2. Example using Connectivity Matrices 136 In any type of network a specific node may have connectivity 137 restrictions that limit the output ports available given the input 138 ports. Connectivity Matrices are described in [RFC6163] For example, 139 given the above network, where node B has the following connectivity 140 restrictions. 142 +-------+ 143 | | 144 1 | B | 2 145 ----|-\ /-|---- 146 | | | | 147 | | | | 148 +-------+ 149 | | 150 3 | | 4 151 | | 153 Figure 2 155 As in the above example, the only way to set up a path from node A to 156 node C will be via node D. This requires two passes through node B 157 which to RSVP looks like a loop, but is a sprial. 159 2.3. Example with additional label restrictions 161 Connections between ports on a node may be restricted based on 162 labels. Consider the following network. 164 +-----+ +-----+ +-----+ 165 | | Link 1 | | Link 2 | | 166 | A |----------| B |----------| C | 167 | | | | | | 168 +-----+ +-----+ +-----+ 169 \ | 170 \ | 171 \ Link 3 | 172 \ | 173 \ +-----+ 174 \ | | 175 Link 4 +-------| D | 176 | | 177 +-----+ 179 Figure 3 181 This network has the following properties. 183 o Node A is electro-optical outputting Lambda 1 and can switch 184 Lambda 2. 186 o Node D can convert between Lambda 1 and Lambda 2. 188 o Link 1 and Link 3 have Lambda 1 available. 190 o All links have Lambda 2 available. 192 To setup a path from A to C in this network, the LSP must pass 193 through Link 1 twice: once using Lambda 1 and once using Lambda 2. 194 This results in the path A-B-D-A-B-C being taken which requires two 195 passes through node A. This looks like a loop, but due to the 196 different lambdas used on each pass is a spiral. 198 2.4. Example In Distributed Networks 200 In networks where the control plane and data plane are physically 201 distinct, it is possible that a single control plane element will be 202 controlling multiple data plane elements. This is the case now in 203 some ASON networks, and will increasingly be the case with the move 204 towards SDN networks. Consider the following network. 206 +-----+ 207 Control | | 208 /--------------------| CP |----\ 209 | | | | 210 | +-----+ | 211 | +-----+ | +-----+ 212 | | | | | | 213 | | CP | | | CP | 214 | | | | | | 215 | +-----+ | +-----+ 216 | | | | 217 +-----+ +-----+ +-----+ +-----+ 218 | | Data | | Data | | Data | | 219 | A |----------| B |----------| D |----------| C | 220 | | | | | | | | 221 +-----+ +-----+ +-----+ +-----+ 223 Figure 4 225 CP are the control planes instances, with A, B, D and C the data 226 plane. Since data nodes A and D are managed by one control plane, an 227 LSP from A to C would appear as a loop, where it is clear that this 228 is not the case in the data plane. As different interfaces are being 229 used the control plane could treat such an LSP as a spiral. 231 2.5. Example with Ingress Protection 233 If performing ingress protection with an off-forwarding-path backup 234 node, as described by [I-D.torvi-mpls-rsvp-ingress-protection], then 235 the ingress node will see a Path message for the same session twice. 236 Preventing a data plane loop, but allowing a spiral is also required 237 in this case. 239 3. Existing workaround 241 In current networks it is possible to support such paths either 242 through management configuration at each node, or splitting the path 243 into two or more signalling sessions. In the above examples this can 244 be achieved with one session from A to D, and a second session from D 245 to C. It would also require management on node D to join the data 246 paths together. It is desirable that a single signalling session can 247 be used to set up such paths, thus only requiring management input at 248 the ingress. 250 4. Solution 252 4.1. Overview 254 To support such networks, the rules governing RSVP loop checking are 255 relaxed to allow spirals, but still prevent loops. No changes to 256 protocol messages are made. 258 4.2. Assumptions and limitations 260 These changes are only applicable to GMPLS out of band signalling 261 when using point to point data links. 263 4.3. General Rules 265 The following rules govern the changes in behaviour that allow RSVP 266 loop checking to be relaxed while still setting up non-looping data 267 paths in RSVP. 269 o For each pass through the control plane node, the pair of inbound 270 and outbound data interfaces and labels must be different. 272 4.4. RRO handling 274 Section 4.4.4 of [RFC3209] states that RSVP must reject a Path 275 message if the receiving router is already in the RRO. This is now 276 relaxed to allow such a condition provided a different interface- 277 label pair is used in each case. If the router has existing session 278 state for a received Path message, and it MUST verify that the newly 279 requested data path (input and output interface and label) is 280 different from the existing data path(s) for that session, and the 281 existing data path(s) is (are) present earlier in the RRO. If this 282 is not the case, the router MUST return a "Routing problem" PathErr 283 message with the error value "loop detected". 285 In order to carry out this checking correctly, specific interfaces 286 and labels SHOULD be recorded in the RRO. If this is not the case, 287 each node can only verify the path is acceptable against local state 288 and should not reject the RRO if the local state is valid. 290 It is allowable for local policy to exist to limit the number of 291 different paths through a router in a single LSP instance. If this 292 limit is exceeded the router SHOULD return a "Routing problem" 293 PathErr message with the error value "loop detected". This local 294 policy is not intended to be advertised in routing. It is present as 295 a backstop to protect against malicious Path messages consuming all 296 resources on the router. 298 4.5. ERO handling 300 Sections 4.3.4.1 and 4.3.5 of [RFC3209] also state that RSVP must 301 detect and avoid loops. This checking is also relaxed to allow 302 spirals in the cases stated above. Again, local policy can limit the 303 number of different paths through a router in a single LSP instance. 304 A router may "look ahead" in the ERO to determine such local policy 305 will be exceeded in advance of it happening and SHOULD return a 306 "Routing problem" PathErr message with the error value "loop 307 detected" in such a case. 309 When calculating or expanding an ERO a router may include multiple 310 entries through a single router. If the ERO contains loose hops that 311 form a loop, and a node determines a non-looping route is available, 312 it MAY remove the loop from the ERO. 314 4.6. Interface handling 316 As stated in the general rules, an implementation supporting multiple 317 passes through a node must ensure that for each pass the input and 318 output interfaces and labels are different. 320 Internally, this means that if a Path message is received using a 321 different input interface this may no longer mean the LSP has been 322 rerouted upstream. Implementations must check the RRO to determine 323 the correct behaviour when processing such a Path message. Care must 324 be taken to handle valid cases where the incoming label can change. 326 4.7. Signalling 328 For the avoidance of doubt, no new signalling is being defined in 329 this draft. 331 The behaviour of refresh or error messages is unchanged and should 332 therefore be sent along the looped path (if present). Nodes SHOULD 333 NOT shortcut the loop. 335 4.8. Error Handling 337 How to behave when receiving a PathErr with error value "loop 338 detected" is out of scope of this draft and is a local implementation 339 decision. For example, it may choose to try and recalculate the path 340 mandating that the error node is avoided, or does not support 341 looping. 343 5. Acknowledgements 345 With thanks to Jonathan Sadler and Yimin Shen for their input when 346 discussing this draft. 348 6. IANA Considerations 350 This memo includes no request to IANA. 352 7. Security Considerations 354 In principle these changes to RSVP pose no security exposures over 355 and above [RFC3209]. However, by allowing loops a single LSP can now 356 consume multiple resources. As suggested local policy can limit the 357 number of paths and thus the resource a single LSP can consume. 359 8. References 361 8.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 367 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 368 Tunnels", RFC 3209, December 2001. 370 8.2. Informative References 372 [I-D.torvi-mpls-rsvp-ingress-protection] 373 Atlas, A., Torvi, R., and M. Jork, "Ingress Protection for 374 RSVP-TE p2p and p2mp LSPs", 375 draft-torvi-mpls-rsvp-ingress-protection-00 (work in 376 progress), July 2012. 378 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 379 GMPLS and Path Computation Element (PCE) Control of 380 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 381 April 2011. 383 Authors' Addresses 385 Steve Balls (editor) 386 Metaswitch 387 100 Church Street 388 Enfield, EN2 6BQ 389 UK 391 Phone: +44 208 366 1177 392 Email: steve.balls@metaswitch.com 394 Jonathan Hardwick 395 Metaswitch 396 100 Church Street 397 Enfield, EN2 6BQ 398 UK 400 Phone: +44 208 366 1177 401 Email: jonathan.hardwick@metaswitch.com 403 Cyril Margaria 404 Nokia Siemens Networks 405 St Martin Strasse 76 406 Munich, 81541 407 Germany 409 Phone: +49 89 5159 16934 410 Email: cyril.margaria@nsn.com