idnits 2.17.00 (12 Aug 2021) /tmp/idnits49847/draft-thubert-rtgwg-arc-bicast-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 186 has weird spacing: '...rrrrrrr lll==...' == Line 202 has weird spacing: '... l Left packe...' == Line 203 has weird spacing: '...et path r ...' == Line 208 has weird spacing: '...rrrrrrr lll==...' == Line 246 has weird spacing: '...rrrrrrr lll==...' == (2 more instances...) -- The document date (October 11, 2012) is 3509 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: 0 errors (**), 0 flaws (~~), 8 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 14, 2013 Cisco Systems 6 October 11, 2012 8 Applying Available Routing Constructs to bicasting 9 draft-thubert-rtgwg-arc-bicast-00 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 14, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Downward Bicasting Operation . . . . . . . . . . . . . . . . . 5 60 4. Upward Bicasting Operations . . . . . . . . . . . . . . . . . 6 61 4.1. Resolving crossing ARCs . . . . . . . . . . . . . . . . . 6 62 4.2. Single Point of Failure . . . . . . . . . . . . . . . . . 7 63 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.1. In conjunction with Protocol Independent Multicast . . . . 9 65 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Traditional routing and forwarding uses the concept of path as the 77 basic routing paradigm to get a packet from a source to a destination 78 by following an ordered sequence of arrows between intermediate 79 nodes. In this serial design, a path is broken as soon as a single 80 arrow is, and getting around a breakage can require path 81 recomputation, network reconvergence, and incur delays to till 82 service is restored. 84 Available Routing Constructs [I-D.thubert-rtgwg-arc] (ARC) introduces 85 the concept of ARC as a routing construct made of a sequence of nodes 86 and links with 2 outgoing edges, that is this resilient to one 87 breakage so that an ARC topology is resilient to one breakage per 88 ARC. 90 The routing graph to reach a certain destination is expressed as a 91 cascade of ARCs, which terminates in an abstract destination Omega, 92 each ARC providing its own independent domain of fault isolation and 93 recovery: 95 +========I========+ 96 | | 97 | +====J====+ 98 | | | 99 +====H====+ | +=====K=====+ 100 | | | | | 101 +====D====+ +====E====+ +====F====+ +====G====+ 102 | | | | | | | | 103 +=========B=========+ | | +==========C==========+ 104 | | | | | | 105 | +======A=======+ | 106 | | | | 107 ------------------------------------------------------------------Omega 109 Figure 1: ARC Representation 111 This cascade of ARCs appears ideally suited to the operation of 112 bicasting (a.k.a. duocasting), which consists in sending two copies 113 of a single packet, if possible over divergent - that is fully or 114 partially non-congruent - paths, in order to augment the chances that 115 at least one of the copies reaches the destination timely. 117 2. Terminology 119 The draft uses the terminology defined in [I-D.thubert-rtgwg-arc]. 121 This specificatin also introduces Sided ARCs, that is ARCs with at 122 least an Edge that is known as Left and an Edge that is known as 123 Right. The sense of Left and Right adds up to the existing sense of 124 height that is already defined in [I-D.thubert-rtgwg-arc]. 126 R========I========L 127 | | 128 | L====J====R 129 | | | 130 L====H====R | R=====K=====L 131 | | | | | 132 R====D====L L====E====R L====F====R R===G====L 133 | | | | | | | | 134 R=========B=========L | | R==========C==========L 135 | | | | | | 136 | L======A=======R | 137 | | | | 138 ------------------------------------------------------------------Omega 140 Figure 2: Orienting ARCs 142 One way of doing this is 144 o The basic rule is that an ARC MUST have at least one Left and one 145 Right Edge. 147 o The leg of an ARC between the cursor and the Edge inherits the 148 side of the Edge. In a Comb, the whole buttressing ARC inherits 149 the side of the Edge. 151 o An Edge ending in Omega can arbitrarily become Left or Right as 152 long as the basic rule is satisfied. 154 o An Edge that does not end in Omega inherits the side of an ARC it 155 terminates into, again as long as the basic rule is satisfied. 157 o A collision occurs if all the Edges end up on the same side. The 158 shortest path is used to resolve the collision and restore the 159 basic rule: the Edge closer to Omega and all butressing ARCs on 160 the same side of the cursor keep the side, and the other Edges are 161 toggled. In case of equal cost, an other tie breaker must be 162 used. 164 o For instance, this situation occurs in the representation above 165 for ARC F, which has both ends ending in a Right side of ARCs, and 166 since the Edge closer to Omega is the one that ends in ARC C, that 167 Edge becomes Right and the other becomes Left. 169 3. Downward Bicasting Operation 171 Two copies of a same packet from a given node are forwarded downwards 172 along opposite side of the cascading ARCs, each packet bearing an 173 indication (such as a tag or a label) of its intended side, Left or 174 Right. 176 The packets exit the ARCs along their paths through an Edge that 177 matches the indication in the packet. 179 packet | 180 rrrrrrrrrrrrrrVllll 181 r l 182 r llll=J====R 183 r l | 184 L====H=rrrr l R=====K=====L 185 | r l | | 186 R====D====L L==rrrrrrrr lll==F====R R===G====L 187 | | | r l | | | 188 R=========B=========L r l R==========C==========L 189 | | r l | | 190 | lllllllllrrlrrrr | 191 | l r | 192 ------------------------------------------------------------------Omega 194 Figure 3: Bicasting Down an ARC ascade 196 As it goes, the method does not guarantee a full non congruence of 197 the paths, as illustrated above. In case of a breakage, this can be 198 compensated by the capability to return a packet along an ARC upon a 199 failure, that is already used to protect unicast traffic. 201 packet | 202 l Left packet path rrrrrrrrrrrrrrVllll 203 R Right packet path r l 204 r llll=J====R 205 r l | 206 L====H=rrrr l R=====K=====L 207 | r l | | 208 R====D====L L==rrrrrrrr lll==F====R R===G====L 209 | | | r l | | | 210 R=========B=========L r l R==========C==========L 211 | | r l | | 212 | rrrrrrrrr\/lllll | 213 | r /\ l | 214 ------------------------------------------------------------------Omega 216 Figure 4: Breakage at a Congruent Link 218 4. Upward Bicasting Operations 220 It is also possible with a downward bicasting to place states in the 221 intermediate routers in order to provision an upward bicast path from 222 Omega to a source D. In that case, if the graph is biconnected, it is 223 possible to resolve the pathological cases so as to ensure a real 224 separation of the left and Right paths. 226 4.1. Resolving crossing ARCs 228 The first pathological case occurs when both Left and Right packet 229 cross over the same ARC, as illustrated below. Say that the Right 230 reservation comes first and sets up the right path: 232 r | 233 R====D====L L==rrrrrrrr L====F====R R===G====L 234 | | | r | | | | 235 R=========B=========L r | R==========C==========L 236 | | r | | | 237 | L======Arrrrrrrr | 238 | | r | 239 ------------------------------------------------------------------Omega 241 Figure 5: crossing: Right packet 243 Then comes the left reservation which collisions: 245 r l 246 R====D====L L==rrrrrrrr lll==F====R R===G====L 247 | | | r l | | | 248 R=========B=========L r l R==========C==========L 249 | | r l | | 250 | L======Arrr?rrrr | 251 | | r | 252 ------------------------------------------------------------------Omega 254 Figure 6: crossing: left packet approaching 256 The segment between the two incoming point of the common ARC is 257 common to both path and expose the bicasted traffic. The resolution 258 is to leave the second packet through but prune the unwanted states 259 along the collision segment of the ARC afterwards. 261 r l 262 R====D====L L==rrrrrrrr lll==F====R R===G====L 263 | | | r l | | | 264 R=========B=========L r l R==========C==========L 265 | | r l | | 266 | lllllllll==rrrrr | 267 | l r | 268 ------------------------------------------------------------------Omega 270 Figure 7: crossing: Resolved state 272 States along the ARC between the two incoming points are cleaned, up 273 and the paths that were generated by the Left and Right packets are 274 now crossed. This results in two non-congruent upward paths. 276 4.2. Single Point of Failure 278 The second pathological case occurs when both Left and Right packet 279 reach a same ARC at the same node, which is this a Single Point Of 280 Failure (SPoF) for both paths. 282 r | 283 R====D====L L==rrrrrrrr L====F====R R===G====L 284 | | | r | | | | 285 R=========B=========L r / R==========C==========L 286 | | r/ | | 287 | L======A==rrrrrr | 288 | | r | 289 ------------------------------------------------------------------Omega 291 Figure 8: SPoF: Right packet 293 The resoution is to reject the second packet and send it back along 294 the incoming ARC to exit on the other side. The rejected packet 295 clans up the states that it has created on its way back and then 296 creates states on the other side of the ARC. 298 r l 299 R====D====L L==rrrrrrrr lllllllllll R===G====L 300 | | | r lll l | | 301 R=========B=========L r ll R=====lllllllllllllllll 302 | | rll | l 303 | L======Arrrrrrrr l 304 | | r l 305 ------------------------------------------------------------------Omega 307 Figure 9: SPoF: Left Packet 309 At this point the downward packet will exit the incoming ARC in the 310 wrong side for its own indication. 312 r l 313 R====D====L L==rrrrrrrr L=lllllllll R===G====L 314 | | | r | l | | 315 R=========B=========L r | R=====lllllllllllllllll 316 | | r | | l 317 | L======Arrrrrrrr l 318 | | r l 319 ------------------------------------------------------------------Omega 321 Figure 10: SPoF: Resolved state 323 This is in fact what happens also in the case of a monoconnected 324 zone, or if a breakage cause the downward packet to bounce. 326 5. Applicability 328 5.1. In conjunction with Protocol Independent Multicast 330 (To be refined in 01) Upwards bicasting can be used for Protocol 331 Independent Multicast PIM [RFC4601] and Point-to-Multipoint and 332 Multipoint-to-Multipoint Label Switched Paths mLDP [RFC6388]. A 333 bicasted downards Join message would establish two non congruent 334 return paths, each path joining the receiver and Omega that is the 335 set of existing receivers. 337 6. Manageability 339 This specification describes a generic model. Protocols and 340 management will come later 342 7. IANA Considerations 344 This specification does not require IANA action. 346 8. Security Considerations 348 This specification is not found to introduce new security threat. 350 9. Acknowledgements 352 The authors wishes to thank Dirk Anteunis, Stewart Bryant, Patrice 353 Bellagamba, George Swallow, Eric Osborne, Clarence Filsfils and Eric 354 Levy-Abegnoli for their participation and continuous support to the 355 work presented here. 357 10. References 359 10.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 10.2. Informative References 366 [I-D.thubert-rtgwg-arc] 367 Thubert, P. and P. Bellagamba, "Available Routing 368 Constructs", draft-thubert-rtgwg-arc-00 (work in 369 progress), October 2012. 371 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 372 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 373 Protocol Specification (Revised)", RFC 4601, August 2006. 375 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 376 "Label Distribution Protocol Extensions for Point-to- 377 Multipoint and Multipoint-to-Multipoint Label Switched 378 Paths", RFC 6388, November 2011. 380 Authors' Addresses 382 Pascal Thubert (editor) 383 Cisco Systems, Inc 384 Village d'Entreprises Green Side 385 400, Avenue de Roumanille 386 Batiment T3 387 Biot - Sophia Antipolis 06410 388 FRANCE 390 Phone: +33 497 23 26 34 391 Email: pthubert@cisco.com 393 IJsbrand Wijnands 394 Cisco Systems 395 De kleetlaan 6a 396 Diegem 1831 397 Belgium 399 Email: ice@cisco.com