idnits 2.17.1 draft-thubert-rtgwg-arc-bicast-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 181 has weird spacing: '...rrrrrrr lll==...' == Line 195 has weird spacing: '... l Left packe...' == Line 196 has weird spacing: '...et path r ...' == Line 201 has weird spacing: '...rrrrrrr lll==...' == Line 235 has weird spacing: '...rrrrrrr lll==...' == (2 more instances...) -- The document date (October 18, 2013) is 3814 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) == Outdated reference: A later version (-03) exists of draft-thubert-rtgwg-arc-00 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG P. Thubert, Ed. 3 Internet-Draft cisco 4 Intended status: Standards Track IJ. Wijnands 5 Expires: April 19, 2014 Cisco Systems 6 October 18, 2013 8 Applying Available Routing Constructs to bicasting 9 draft-thubert-rtgwg-arc-bicast-01 11 Abstract 13 This draft introduces methods that leverage the concept of ARC to 14 enable bicasting operations. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 20 "OPTIONAL" in this document are to be interpreted as described in RFC 21 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 19, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Downward Bicasting Operation . . . . . . . . . . . . . . . . . 4 59 4. Upward Bicasting Operations . . . . . . . . . . . . . . . . . 5 60 4.1. Resolving crossing ARCs . . . . . . . . . . . . . . . . . 5 61 4.2. Single Point of Failure . . . . . . . . . . . . . . . . . 6 62 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. In conjunction with Protocol Independent Multicast . . . . 7 64 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 10.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Traditional routing and forwarding uses the concept of path as the 76 basic routing paradigm to get a packet from a source to a destination 77 by following an ordered sequence of arrows between intermediate 78 nodes. In this serial design, a path is broken as soon as a single 79 arrow is, and getting around a breakage can require path 80 recomputation, network reconvergence, and incur delays to till 81 service is restored. 83 Available Routing Constructs [I-D.thubert-rtgwg-arc] (ARC) introduces 84 the concept of ARC as a routing construct made of a sequence of nodes 85 and links with 2 outgoing edges, that is this resilient to one 86 breakage so that an ARC topology is resilient to one breakage per 87 ARC. 89 The routing graph to reach a certain destination is expressed as a 90 cascade of ARCs, which terminates in an abstract destination Omega, 91 each ARC providing its own independent domain of fault isolation and 92 recovery: 94 +========I========+ 95 | | 96 | +====J====+ 97 | | | 98 +====H====+ | +=====K=====+ 99 | | | | | 100 +====D====+ +====E====+ +====F====+ +====G====+ 101 | | | | | | | | 102 +=========B=========+ | | +==========C==========+ 103 | | | | | | 104 | +======A=======+ | 105 | | | | 106 ------------------------------------------------------------------Omega 108 This cascade of ARCs appears ideally suited to the operation of 109 bicasting (a.k.a. duocasting), which consists in sending two copies 110 of a single packet, if possible over divergent - that is fully or 111 partially non-congruent - paths, in order to augment the chances that 112 at least one of the copies reaches the destination timely. 114 2. Terminology 116 The draft uses the terminology defined in [I-D.thubert-rtgwg-arc]. 118 This specificatin also introduces Sided ARCs, that is ARCs with at 119 least an Edge that is known as Left and an Edge that is known as 120 Right. The sense of Left and Right adds up to the existing sense of 121 height that is already defined in [I-D.thubert-rtgwg-arc]. 123 R========I========L 124 | | 125 | L====J====R 126 | | | 127 L====H====R | R=====K=====L 128 | | | | | 129 R====D====L L====E====R L====F====R R===G====L 130 | | | | | | | | 131 R=========B=========L | | R==========C==========L 132 | | | | | | 133 | L======A=======R | 134 | | | | 135 ------------------------------------------------------------------Omega 137 One way of doing this is 139 o The basic rule is that an ARC MUST have at least one Left and one 140 Right Edge. 142 o The leg of an ARC between the cursor and the Edge inherits the 143 side of the Edge. In a Comb, the whole buttressing ARC inherits 144 the side of the Edge. 146 o An Edge ending in Omega can arbitrarily become Left or Right as 147 long as the basic rule is satisfied. 149 o An Edge that does not end in Omega inherits the side of an ARC it 150 terminates into, again as long as the basic rule is satisfied. 152 o A collision occurs if all the Edges end up on the same side. The 153 shortest path is used to resolve the collision and restore the 154 basic rule: the Edge closer to Omega and all butressing ARCs on 155 the same side of the cursor keep the side, and the other Edges are 156 toggled. In case of equal cost, an other tie breaker must be 157 used. 159 o For instance, this situation occurs in the representation above 160 for ARC F, which has both ends ending in a Right side of ARCs, and 161 since the Edge closer to Omega is the one that ends in ARC C, that 162 Edge becomes Right and the other becomes Left. 164 3. Downward Bicasting Operation 166 Two copies of a same packet from a given node are forwarded downwards 167 along opposite side of the cascading ARCs, each packet bearing an 168 indication (such as a tag or a label) of its intended side, Left or 169 Right. 171 The packets exit the ARCs along their paths through an Edge that 172 matches the indication in the packet. 174 packet | 175 rrrrrrrrrrrrrrVllll 176 r l 177 r llll=J====R 178 r l | 179 L====H=rrrr l R=====K=====L 180 | r l | | 181 R====D====L L==rrrrrrrr lll==F====R R===G====L 182 | | | r l | | | 183 R=========B=========L r l R==========C==========L 184 | | r l | | 185 | lllllllllrrlrrrr | 186 | l r | 187 ------------------------------------------------------------------Omega 189 As it goes, the method does not guarantee a full non congruence of 190 the paths, as illustrated above. In case of a breakage, this can be 191 compensated by the capability to return a packet along an ARC upon a 192 failure, that is already used to protect unicast traffic. 194 packet | 195 l Left packet path rrrrrrrrrrrrrrVllll 196 R Right packet path r l 197 r llll=J====R 198 r l | 199 L====H=rrrr l R=====K=====L 200 | r l | | 201 R====D====L L==rrrrrrrr lll==F====R R===G====L 202 | | | r l | | | 203 R=========B=========L r l R==========C==========L 204 | | r l | | 205 | rrrrrrrrr\/lllll | 206 | r /\ l | 207 ------------------------------------------------------------------Omega 209 4. Upward Bicasting Operations 211 It is also possible with a downward bicasting to place states in the 212 intermediate routers in order to provision an upward bicast path from 213 Omega to a source D. In that case, if the graph is biconnected, it is 214 possible to resolve the pathological cases so as to ensure a real 215 separation of the left and Right paths. 217 4.1. Resolving crossing ARCs 219 The first pathological case occurs when both Left and Right packet 220 cross over the same ARC, as illustrated below. Say that the Right 221 reservation comes first and sets up the right path: 223 r | 224 R====D====L L==rrrrrrrr L====F====R R===G====L 225 | | | r | | | | 226 R=========B=========L r | R==========C==========L 227 | | r | | | 228 | L======Arrrrrrrr | 229 | | r | 230 ------------------------------------------------------------------Omega 232 Then comes the left reservation which collisions: 234 r l 235 R====D====L L==rrrrrrrr lll==F====R R===G====L 236 | | | r l | | | 237 R=========B=========L r l R==========C==========L 238 | | r l | | 239 | L======Arrr?rrrr | 240 | | r | 241 ------------------------------------------------------------------Omega 243 The segment between the two incoming point of the common ARC is 244 common to both path and expose the bicasted traffic. The resolution 245 is to leave the second packet through but prune the unwanted states 246 along the collision segment of the ARC afterwards. 248 r l 249 R====D====L L==rrrrrrrr lll==F====R R===G====L 250 | | | r l | | | 251 R=========B=========L r l R==========C==========L 252 | | r l | | 253 | lllllllll==rrrrr | 254 | l r | 255 ------------------------------------------------------------------Omega 257 States along the ARC between the two incoming points are cleaned, up 258 and the paths that were generated by the Left and Right packets are 259 now crossed. This results in two non-congruent upward paths. 261 4.2. Single Point of Failure 263 The second pathological case occurs when both Left and Right packet 264 reach a same ARC at the same node, which is this a Single Point Of 265 Failure (SPoF) for both paths. 267 r | 268 R====D====L L==rrrrrrrr L====F====R R===G====L 269 | | | r | | | | 270 R=========B=========L r / R==========C==========L 271 | | r/ | | 272 | L======A==rrrrrr | 273 | | r | 274 ------------------------------------------------------------------Omega 276 The resoution is to reject the second packet and send it back along 277 the incoming ARC to exit on the other side. The rejected packet 278 clans up the states that it has created on its way back and then 279 creates states on the other side of the ARC. 281 r l 282 R====D====L L==rrrrrrrr lllllllllll R===G====L 283 | | | r lll l | | 284 R=========B=========L r ll R=====lllllllllllllllll 285 | | rll | l 286 | L======Arrrrrrrr l 287 | | r l 288 ------------------------------------------------------------------Omega 290 At this point the downward packet will exit the incoming ARC in the 291 wrong side for its own indication. 293 r l 294 R====D====L L==rrrrrrrr L=lllllllll R===G====L 295 | | | r | l | | 296 R=========B=========L r | R=====lllllllllllllllll 297 | | r | | l 298 | L======Arrrrrrrr l 299 | | r l 300 ------------------------------------------------------------------Omega 302 This is in fact what happens also in the case of a monoconnected 303 zone, or if a breakage cause the downward packet to bounce. 305 5. Applicability 307 5.1. In conjunction with Protocol Independent Multicast 309 Upwards bicasting can be used for Protocol Independent Multicast PIM 310 [RFC4601] and Point-to-Multipoint and Multipoint-to-Multipoint Label 311 Switched Paths mLDP [RFC6388]. A bicasted downards Join message 312 would establish two non congruent return paths, each path joining the 313 receiver and Omega that is the set of existing receivers. 315 6. Manageability 317 This specification describes a generic model. Protocols and 318 management will come later 320 7. IANA Considerations 322 This specification does not require IANA action. 324 8. Security Considerations 326 This specification is not found to introduce new security threat. 328 9. Acknowledgements 329 The authors wishes to thank Dirk Anteunis, Stewart Bryant, Patrice 330 Bellagamba, George Swallow, Eric Osborne, Clarence Filsfils and Eric 331 Levy-Abegnoli for their participation and continuous support to the 332 work presented here. 334 10. References 336 10.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 10.2. Informative References 343 [I-D.thubert-rtgwg-arc] 344 Thubert, P. and P. Bellagamba, "Available Routing 345 Constructs", Internet-Draft draft-thubert-rtgwg-arc-00, 346 October 2012. 348 [RFC4601] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, 349 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 350 Protocol Specification (Revised)", RFC 4601, August 2006. 352 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K. and B. Thomas, 353 "Label Distribution Protocol Extensions for Point-to- 354 Multipoint and Multipoint-to-Multipoint Label Switched 355 Paths", RFC 6388, November 2011. 357 Authors' Addresses 359 Pascal Thubert, editor 360 Cisco Systems, Inc 361 Village d'Entreprises Green Side 362 400, Avenue de Roumanille 363 Batiment T3 364 Biot - Sophia Antipolis, 06410 365 FRANCE 367 Phone: +33 497 23 26 34 368 Email: pthubert@cisco.com 370 IJsbrand Wijnands 371 Cisco Systems 372 De kleetlaan 6a 373 Diegem, 1831 374 Belgium 376 Email: ice@cisco.com