idnits 2.17.1 draft-viswanathan-aris-overview-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1997) is 9904 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) -- Looks like a reference, but probably isn't: '11' on line 440 == Missing Reference: 'Rsvp' is mentioned on line 474, but not defined == Unused Reference: 'IGMP-3' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC1519' is defined on line 790, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARIS-LAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'ARIS-SPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMP-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-DM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-SM' ** Downref: Normative reference to an Experimental RFC: RFC 1075 ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1583 (Obsoleted by RFC 2178) ** Downref: Normative reference to an Historic RFC: RFC 1584 ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Arun Viswanathan 3 Expiration Date: September 1997 Nancy Feldman 4 Rick Boivie 5 Rich Woundy 6 IBM Corp. 8 March 1997 10 ARIS: Aggregate Route-Based IP Switching 12 14 Status of This Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 IP based networks use a number of routing protocols, including RIP, 35 OSPF, IS-IS, and BGP, to determine how packets ought to be routed. 36 Among these protocols, OSPF and BGP are IETF-recommended standards 37 that have been extensively deployed and exercised in many networks. 38 In this memo, we describe a mechanism which uses these protocols as 39 the basis for switching IP datagrams, by the addition of a simple 40 protocol ("ARIS") that establishes switched paths through a network. 41 The ARIS protocol allows us to leverage the advantages of switching 42 technologies in an internet network. 44 1. Introduction 46 In this memo, an Integrated Switch Router (ISR), is a switch that has 47 been augmented with standard IP routing support. The ISR at an entry 48 point to the switching environment performs standard IP forwarding of 49 datagrams, but the "next hop" of the IP forwarding table has been 50 extended to include a reference to a switched path (for example, the 51 VCC in ATM technology). Each switched path may have an endpoint at a 52 neighboring router (comparable to today's IP next hops on 53 conventional routers), or may traverse a series of ISRs along the 54 best IP forwarding path, to an egress ISR endpoint. This allows 55 datagrams to be switched at hardware speeds through an entire ISR 56 network. 58 The key link between the IP network routing protocols and the ARIS 59 switched path establishment protocol is the "egress identifier", 60 which defines a routed path through a network. The egress identifier 61 may refer to an egress ISR that forwards traffic either to a foreign 62 routing domain, or across an area boundary within the same network. 63 ARIS establishes switched paths towards each unique egress 64 identifier. Since thousands of IP destinations can map to the same 65 egress identifier, ARIS minimizes the number of switch paths required 66 in an ISR network. This allows a large network to switch all of its 67 IP traffic, resulting in improved aggregate IP throughput. 69 2. ARIS Mechanism 71 In networks based on destination-based hop-by-hop forwarding, ARIS 72 [ARIS-SPEC] pre-establishes switched paths to "well known" egress 73 nodes. As a result, virtually all best-effort traffic is switched 74 through an ARIS network. These "well known" egress nodes are learned 75 through the routing protocols, such as OSPF and BGP. No routing 76 protocol modification is required for this purpose, as this 77 information is already present within the routing protocols 78 themselves. 80 Egress ISRs initiate the setup of switched paths by sending Establish 81 messages to their upstream neighbors, typically within the same 82 domain. These upstream neighbors forward the messages to their own 83 upstream neighbors in Reverse Path Multicast style, after ensuring 84 that the switched path is loop-free. Eventually, all ISRs establish 85 switched paths to all egress ISRs, which follow the routed path. 87 The switched path to an egress point, in general, takes the form of a 88 tree. A tree results because of the "merging" of switched paths that 89 occurs at a node when multiple upstream switched paths for a given 90 egress point are spliced to a single downstream switched path for 91 that egress point. 93 2.1. ARIS Messages 95 ARIS is protocol independent. In the case of IP, ARIS message are 96 transmitted with IP protocol number 104. ARIS uses the following 97 messages to manage the switched paths. 99 Init 100 This is the first message sent by an ISR to each of its neighbors, 101 as notification of its existence. It is periodically transmitted 102 until a positive acknowledgment is received. The Init message may 103 include the neighbor timeout period, acceptable label ranges, and 104 other adjacency information. 106 KeepAlive 107 This message is sent by an ISR to inform its neighbors of its con- 108 tinued existence. It is the first message that is transmitted 109 after an adjacency has been established. In order to prevent the 110 neighbor timeout period from expiring, ARIS messages must be 111 periodically sent to neighbors. The KeepAlive will only be sent 112 when no other ARIS messages have been transmitted within the 113 periodic interval time. 115 Establish 116 This message is initiated by the egress ISR, and is periodically 117 sent to each upstream neighbor to setup or refresh a switched 118 path. It is also sent by any ISR in response to a Trigger mes- 119 sage. Each ISR that receives an Establish message for an egress 120 identifier must verify that the path is correct and loop free. If 121 the Establish message changes a previously known switched path to 122 the egress identifier, the ISR unsplices the obsolete switched 123 path. The ISR creates a downstream switched path with the given 124 label for the egress identifier, and replies with an Acknowledg- 125 ment message. It then allocates a label for each of its upstream 126 neighbors, forwards the Establish message to the upstream neigh- 127 bors with its unique ISR ID appended to the ISR ID path and the 128 label for the upstream neighbor to use for forwarding, and waits 129 for an Acknowledgment message. This pattern continues until all 130 ISRs are reached. 132 Trigger 133 This message is sent by an ISR when it has detected that a local 134 IP routing change has modified its path to the egress identifier. 135 After unsplicing the obsolete switched path, the ISR sends a 136 Trigger message to its new downstream neighbor requesting an 137 Establish message. 139 Teardown 140 This message may be sent when an ISR has lost connectivity to an 141 egress identifier. The message follows the path of the Establish 142 message unsplicing and releasing the obsolete switched path. 144 Acknowledgment 145 This message is sent as a response to ARIS messages. When an ISR 146 receives a positive acknowledgment to an Establish message, it 147 splices the upstream label to the downstream label creating a 148 switched path through the ISR. 150 2.2. Egress Identifiers 152 The ARIS protocol uses egress identifiers that balance the desire to 153 share the same egress identifier among many IP destination prefixes, 154 with the desire to maximize switching benefits. To provide 155 flexibility, ARIS supports many types of egress identifiers. ISRs 156 choose the type of egress identifier to use based on routing protocol 157 information and local configuration. 159 The first type of egress identifier is the IP destination prefix. 160 This type results in each IP destination prefix sustaining its own 161 switched path tree, and thus will not scale in large backbone and 162 enterprise networks. However, this is the only information that some 163 routing protocols, such as RIP, can provide. This type of identifier 164 may work well in networks where the number of destination prefixes is 165 limited, such as in campus environments, or even in a wide-area 166 network of a private enterprise. 168 The second type of egress identifier is the egress IP address. This 169 type is used primarily for BGP protocol updates, which carry this 170 information in the NEXT_HOP attribute [RFC1771]. There are certain 171 types of OSPF routes that also use this type. 173 The third type of egress identifier is the OSPF Router ID, which 174 allows aggregation of traffic on behalf of multiple datagram 175 protocols routed by OSPF. The latest version of OSPF supports the 176 Router ID for both IP and IPv6 [RFC1583]. 178 The fourth type of egress identifier is the multicast (source, group) 179 pair [RFC1112], used by multicast protocols, such as DVMRP [RFC1075], 180 MOSPF [RFC1584] and PIM ([PIM-SM], [PIM-DM]). The fifth is the 181 (ingress-of-source, group), used for such multicast protocols as 182 MOSPF and PIM-SM. 184 Other egress identifier types may be defined, including but not 185 limited to IS-IS NSAP addresses, NLSP IPX addresses, IPv6 destination 186 prefixes, APPN etc. 188 A hierarchy amongst the egress identifiers may be introduced to allow 189 more flexible control over egress identifier selection. This allows 190 an ISR to autolearn or be configured with non-default egress 191 identifiers, and to select which egress identifiers to use in various 192 routing situations. 194 2.3. ISR Information Base 196 The ISR needs three logical information bases to compute routes and 197 forward datagrams: the routing information base, the forwarding 198 information base, and the VC information base. The first, the 199 routing information base (RIB), is used for the computation of best- 200 effort routes by various IP routing protocols. The RIB for the ISR 201 is essentially unchanged from the RIB on a standard router. In the 202 ISR context, the RIB is also used to identify egress points and 203 egress identifiers for the other two information bases. 205 The forwarding information base (FIB) of the ISR has been extended 206 beyond the content of the FIB on a standard router to include an 207 egress identifier in each next hop entry. The FIB tends to contain 208 many IP destination prefix entries, which point to a small number of 209 next hop entries that describe the hop-by-hop forwarding 210 operation(s). Next hop entries on the ISR consist of an outgoing 211 interface, next hop IP address, egress identifier, and the associated 212 established downstream label for the switched path. The association 213 of the next hops with the egress identifiers is the responsibility of 214 the routing protocols, while the association of the next hop/egress 215 identifiers with the established switched paths is the responsibility 216 of the ARIS protocol. 218 The VC information base (VCIB), which does not exist on a standard 219 router, maintains for each egress identifier the upstream to 220 downstream label mappings and related states. This mapping is 221 controlled by the ARIS protocol. 223 2.4. Forwarding 225 The forwarding ingress ISR performs a conventional longest prefix 226 match lookup in its FIB, which returns the associated switched path 227 label for the particular destination. The ingress ISR may also 228 decrement the TTL by the length of the switched path before the 229 packet is transmitted on the switched path. If no associated 230 switched path is found in the FIB, the ingress node may forward the 231 packet to the next hop via the default hop-by-hop switched path. 233 2.5. TTL Decrement 235 In order to comply with the requirements for IPv4 routers, the IP 236 datagram Time-To-Live (TTL) field must be decremented on each hop it 237 traverses [RFC1812]. Currently, switched packets within an ATM like 238 networks cannot decrement the TTL. However, ARIS can decrement TTLs 239 appropriately by maintaining a hop-count per egress identifier. This 240 hop-count is calculated by including a hop-count field in the 241 Establish message, which is incremented at each ISR as it traverses 242 the upstream path. Before forwarding a packet on a switched path, an 243 ingress ISR decrements the TTL by the hop-count plus one. If the 244 decrement value is greater than or equal to the TTL of the packet, 245 the packet may be forwarded hop-by-hop. 247 3. Loop Prevention 249 The ARIS protocol guarantees that switched path loops are prevented, 250 even in the presence of transient IP routing loops. With datagram 251 forwarding loops, each hop decrements the TTL, so traffic is 252 eventually dropped. However, some switching technologies, such as 253 ATM, do not have a counter similar to the TTL, so traffic persists in 254 a switched path loop as long as the switched path loop exists. The 255 same it true for Frame Relay and LAN switches. At best, the traffic 256 in the switched path loop steals bandwidth from other (UBR) switched 257 paths; at worst, the traffic interferes with IP routing traffic, 258 slows down routing convergence, and lengthens the life of the 259 switched path loop. 261 The ARIS protocol avoids creating switched path loops by the use of 262 an "ISR ID" list, similar in function to the BGP AS_PATH attribute. 263 Each ISR in the establishment path appends its own unique ISR ID to 264 each establishment message it forwards. In this way, an ISR is able 265 to determine the path a message has traversed, and can ensure that no 266 loops are formed. 268 Further, if an ISR modifies or deletes an egress due to an IP route 269 change, or receives a message that modifies an existing switched path 270 to an egress, the ISR must unsplice any established upstream switched 271 path from the downstream switched path. Hence transient IP routing 272 loops, potentially created by the route change, cannot produce 273 switched path loops. The ISR must then re-establish a new switched 274 path to the modified egress. Note that ARIS does not attempt to 275 suppress transient IP routing protocol loops; it only avoids 276 establishing switched path loops with this information. 278 4. Egress ISRs 280 In the ARIS protocol, Establishment messages are originated from the 281 egress ISR. An ISR is considered an egress ISR, with respect to a 282 particular egress identifier, under any of the following conditions: 284 1. The egress identifier refers to the ISR itself (including one 285 of its directly attached interfaces). 287 2. The egress identifier is reachable via a next hop router that 288 is outside the ISR switching infrastructure. 290 3. The egress identifier is reachable by crossing a routing 291 domain boundary, such as another area for OSPF summary 292 networks, or another autonomous system for OSPF AS externals 293 and BGP routes. 295 5. Examples 297 5.1. Establish Initiation Example 299 +---+ 300 .... | 2 | 301 +---+ ---> +---+ +--------+ 302 | 1 | ---> | Egress | --> ... 303 +---+ ---> +---+ +--------+ 304 .... | 3 | 305 +---+ 306 Example: Egress initiates Establish 308 a) The Egress ISR learns of an egress identifier that indicates the 309 egress is itself (see "Egress ISRs"). It creates a FIB entry 310 for its next hop and egress identifier (itself). 312 b) The Egress creates a VCIB entry with an allocated upstream label 313 to ISR1, and initiates an Establish message with the upstream 314 label, and itself in the ISR ID path. 316 c) ISR1 verifies that the Establish message was received from the 317 expected next hop (Egress) by matching its FIB entry, and 318 verifies that the ISR ID path is loop free. It then creates a 319 VCIB entry and a switched path with the downstream label to the 320 Egress, replaces the default switched path label in the FIB with 321 this new label, and replies to the Egress with an Acknowledgment 322 message. 324 d) ISR1 allocates an upstream label to each of its upstream 325 neighbors, ISR2 and ISR3, and updates the corresponding VCIB 326 entry. It forwards the Establish message to each upstream 327 neighbor, with its own ISR ID appended to the ISR ID path and 328 with the label to use. 330 e) When ISR1 receives each acknowledgment from each upstream 331 neighbor, it updates the VCIB and splices the corresponding 332 upstream label to its Egress downstream label. 334 All upstream ISRs recursively follow the same procedures as ISR1, 335 until all Ingress ISRs have been added to the switched path to the 336 Egress. 338 The Egress ISR is responsible for periodically sending refresh 339 Establish messages, to prevent switched path timeouts. If a refresh 340 is not received in the allotted time, switched paths are unspliced 341 and associated labels are released. 343 5.2. Trigger Example 345 +---+ 346 +-X-> | 2 | ---> ........ 347 | +---+ . 348 +---+ +---+ --> +--------+ 349 .... | 4 | ---> | 1 | | Egress | 350 +---+ +---+ --> +--------+ 351 | +---+ . 352 +---> | 3 | ---> ........ 353 +---+ 354 Example: ISR1 changes routes from ISR2 to ISR3 356 a) ISR1 learns of a new path to the Egress via ISR3 from the 357 routing protocols. It removes the FIB and VCIB entries for the 358 next hop ISR2/Egress. ISR1 creates a new FIB entry for the next 359 hop ISR3/Egress with the default switched path to the next hop. 361 b) ISR1 sends a Trigger message to new downstream node ISR3 362 requesting an Establish message for the switched path to the 363 Egress. 365 c) ISR3 allocates an upstream label, updates its corresponding VCIB 366 entry, and replies with an Establish message to ISR1, containing 367 the full ISR ID path and the label. 369 d) ISR1 verifies that the Establish message was received from the 370 expected next hop (ISR3), and that the ISR ID path is loop free. 371 It then creates a new VCIB entry and a switched path with the 372 given downstream label to ISR3, and replaces the default 373 switched path label in the FIB with this new label. 375 e) ISR1 sends an Acknowledgment message to ISR3. 377 f) ISR3 receives the Acknowledgment, updates the VCIB and splices 378 its ISR1 upstream label to its downstream label. 380 g) ISR1 appends its ISR ID to the Establish message, and forwards 381 the message to ISR4 with the upstream label. 383 h) ISR4 verifies the Establish message, updates the VCIB, and 384 unsplices the current switched path to ISR1/Egress from its 385 upstream node(s), and sends an Acknowledgment to ISR1. 387 i) ISR1 receives the Acknowledgment, updates the VCIB and splices 388 the ISR4 upstream label to the ISR3 downstream label. 390 j) ISR4 appends its ISR ID to the path, and forwards the 391 establishment message to its upstream neighbors with a label. 392 When ISR4 receives an Acknowledgment from an upstream neighbor, 393 it updates the VCIB and splices the upstream label to the ISR1 394 downstream label. 396 All upstream ISRs recursively follow the same procedure as ISR4, 397 until all ingress ISRs have been updated. 399 6. Explicit Routes 401 Today's Internet is predominantly based on the destination-based 402 hop-by-hop forwarding paradigm. However, other routing and 403 forwarding paradigms, such as strict source routing, may be useful to 404 provide specialized and customized services. For this reason, the 405 ARIS protocol supports the building of switched paths through 406 explicit routes. 408 This is enabled by introducing the explicit source route path 409 information in the Establish message. The Establish message is 410 forwarded along the explicit path as identified by the source route 411 information. ARIS supports building of point-to-point, point-to- 412 multipoint and multipoint-to-point switched paths either from the 413 egress node or the ingress node. Note that the switched paths built 414 by source routing are guaranteed to be loop-free. It's also possible 415 to set up bi-directional switched paths or switched paths with QoS 416 using this approach. 418 7. Multicast 420 The ARIS protocol can be used to setup switched paths for IP 421 multicast traffic. The establishment of a point-to-multipoint 422 switched path tree is initiated at the root (ingress) node. The 423 switched path tree carries traffic from the ingress ISR to all egress 424 ISRs, using multicast switching at intermediate ISRs. 426 The choice of egress identifier for multicast routing protocols such 427 as DVMRP and PIM-DM is the (S,G) pair itself. This egress identifier 428 creates one ingress routed point-to-multipoint switched path tree per 429 source address and group pair. The creation of a switched path is 430 initiated by an ingress node on receipt of traffic from a certain 431 sender for a particular multicast group. The Establish message 432 traverses from the ingress node to the downstream ISRs in the Reverse 433 Path Multicast (RPM) style. The branches of the point-to-multipoint 434 switched path tree that do not lead to receivers are pruned when the 435 multicast routing protocol prunes up by deleting forwarding entries 436 in the multicast FIB. 438 Having multicast switched paths set up on the basis of (S,G) works 439 well with the IGMPv3 Group-Source messages, since these IGMP messages 440 can create unique trees for each sender within the same group [11]. 442 For multicast routing protocols, such as PIM-SM, that use a shared 443 tree, an appropriate choice of egress identifier is (*, G) or (RP, G) 444 (where RP is the PIM-SM Rendezvous Point for the group). The 445 switched path establishment for the shared-tree works exactly as 446 explained above, except that the Establish message is initiated when 447 the PIM Join/Prune message from the receiver's DR (Designated Router) 448 reaches the RP node. The Establish message for a source-specific 449 tree is also originated at the ingress node. This again is initiated 450 by the receipt of a PIM Join/Prune message. The Establish message 451 for a source-specific tree uses the (S,G) egress identifier. In both 452 cases, the Establish message is forwarded according to the states 453 created by the PIM protocol. 455 All multicast switched path trees are periodically refreshed by 456 retransmitting an Establish message. The periodic refreshes may also 457 be used to keep the multicast forwarding states active since the 458 intermediate ISRs may not forward packets at network layer. When a 459 new receiver is explicitly grafted in the multicast distribution 460 tree, the ISR into which the new branch is spliced may issue an 461 Establish message downstream or wait for the next refresh cycle to 462 create the switched path branch along the newly grafted branch to the 463 multicast distribution tree. 465 The loop prevention mechanism for multicast works in the exact same 466 manner as for the unicast case expounded previously. Each ISR 467 appends it's ISR ID to the path in the Establish message before 468 forwarding it to the downstream ISRs. ISRs which receive an 469 Establish message verify a loop-free message via the ISR ID path. 471 8. Host-to-Host Connectivity 473 Dedicated switched paths for host-to-host connectivity may be 474 established with either RSVP [Rsvp] or ARIS. Since this may pose 475 scalability problems in networks that support a large number of 476 active hosts, it is desirable to provide complete host-to-host 477 switched path connectivity using the pre-established aggregated ARIS 478 connections in a network. This maintains good scaling properties in 479 the backbone of the network by conserving labels for premium 480 services, and at the same time provides end-to-end switching for 481 hosts directly attached to the ARIS network. In this approach, a 482 dedicated switched path is created between the host and the ingress 483 (or egress) and this in turn is spliced to the aggregated switched 484 path. The creation of the switched path can be either be initiated 485 by the host or by an ISR by thresholding on the flow. 487 9. Label Conservation 489 An important goal of the ARIS protocol is to minimize the number of 490 switched paths required by ISRs to switch all IP traffic in a 491 network. Since switches may support only a limited label space, ARIS 492 restrains its label consumption so that labels are available as 493 needed for its own use, as well as for other services, such as RSVP. 494 Further benefits include simplification of network management, both 495 for automated tools and for human comprehension and analysis, and 496 switched path setup overhead. 498 The consumption of labels is minimized: 500 o by the use of egress routers that may map thousands of IP 501 destinations to the same switched, and 503 o by enabling the merging of switched paths. 505 This combination can provide O(n) switched paths, where n is the 506 number of egress nodes. 508 9.1. Aggregation 510 The network routing domain has the greatest performance and label 511 conservation when all routers in the domain are ISRs. Maximum ARIS 512 benefits are also tied closely to an IP network routing topology with 513 a high ratio of IP destinations to egresses, as exists in a typical 514 IP backbone. However, ARIS is flexible enough to be highly 515 beneficial even in networks with partial ISR deployments or arbitrary 516 network routing topologies. 518 9.2. Switched Path Merging 520 The merging of switched paths enables ARIS to create switched path 521 trees, each of which connects all of the ingresses to a given egress. 522 This results in n trees, where n is the number of egresses in a 523 network, while still providing the benefits of full mesh connectivity 524 (without O(n**2) switched paths). 526 10. ARIS on Specific Switching Technologies 528 10.1. Asynchronous Transfer Mode (ATM) 530 The ability of the ARIS protocol to conserve the number of switched 531 paths depends on the hardware capabilities of the ISR. Some ATM 532 switching components can "merge" multiple inbound VCs onto one 533 outbound VC at close to standard switching rates. These merge- 534 capable components are able to buffer cells from the inbound VCs till 535 all cells of a frame arrive, and inject the frames into the outbound 536 VC, without interleaving cells from different frames. 538 The ARIS usage of "merged" VC flows requires that ATM switching 539 hardware have the capability of preventing cell interleaving (see "VC 540 Conservation"). Unfortunately, much of the existing ATM switching 541 hardware cannot support VC merging. One solution to this problem is 542 to use virtual paths (VPs) to egress points, rather than virtual 543 circuits (VCs). The virtual path extension merges VPs, creating 544 trees of VPs to the egress points, instead of merging VCs. Cell 545 interleaving is prevented by the assignment of unique VC identifiers 546 (VCIs) within each VP. 548 The ISRs within a network are assigned unique VCIs to prevent VCI 549 collisions when paths from different ISRs are merged. Each ISR 550 requires a block of VCIs as labels to distinguish between cell paths 551 to the same egress identifier. By assigning a unique block of VCIs 552 to each ISR, ARIS guarantees that an ISR at a network merge point can 553 safely merge upstream VP flows for an egress identifier to a single 554 downstream VP without VCI collisions. 556 Although the virtual path extension uses VCs much less efficiently 557 than a VC merging implementation, it reduces network latency and 558 hardware requirements because frame reassembly and re-segmentation is 559 not required on intermediate ISRs. In addition, although this 560 variation uses more VC space, the work involved in establishing and 561 maintaining switched paths is still O(n). 563 An alternative approach to the VC merging problem is to use an end- 564 to-end VC label upstream allocation. This allows the ingress node to 565 choose the downstream VC. In this approach, ISRs acknowledge the 566 Establishment message with a label only after they receive an 567 Acknowledgment message from their own upstream neighbor. Thus, the 568 Establishment message traverses fully to the ingress node before 569 being acknowledged. Ingress ISRs immediately acknowledge the 570 Establishment message with the VC label. These acknowledgements may 571 be merged as they travel downstream to the egress node. This method 572 adds latency in the VC set up, and removes the benefits of ARIS VC 573 aggregation (O(n**2) versus O(n) VCs). However, it adds the 574 flexibility of performing VC-switching instead of VP-switching, which 575 also makes switching possible at the routing boundaries. 577 10.2. Frame Switching Technology 579 While ARIS solves the problem of cell interleaving in the case of ATM 580 by Virtual Path switching, it naturally and easily maps to a frame 581 switching environment. This is due to the fact that multiple 582 upstream flows can be merged into a single downstream flow without 583 the problems of cell interleaving. 585 10.3. LAN Switching Technology 587 LAN switches are different than other frame switches, in that they 588 typically do not perform label swapping, and instead switch frames 589 based on their 6-byte IEEE MAC destination address. The label in 590 this case can be considered as the 6-byte MAC address, which has 591 global significance within the ARIS network. The advantages of this 592 approach are that it augments LAN switches with routing functionality 593 and helps achieve media speed switching between LAN segments [ARIS- 594 LAN] without requiring hardware enhancements. 596 11. Layer-2 Tunneling 598 Like IP-in-IP tunnels, the L2-in-L2 tunnels can be useful in several 599 different scenarios. In this, a L2 PDU is encapsulated into another 600 L2 PDU. The outer shell carries the PDU to a predetermined 601 termination point, at which the outer shell is removed and the PDU is 602 switched based on the inner shell (now the outer shell after the de- 603 encapsulation). Note that in a L2-tunnel, the label switching and 604 swapping happens only on the outer shell. The L2 header of the inner 605 shell is not examined until the tunnel termination point. 607 One simple application of this is private virtual networking, similar 608 in manner to IP-in-IP tunneling. Another important usage is 609 switching through routing hierarchies. At the egress ISR of a 610 switched path that carries aggregated traffic, the packet must be L3 611 forwarded even if the packets are to continue on a different switched 612 path. This is typical at the egress ISR. Traffic from all ingresses 613 flow towards the egress ISR using the same switched path tree. To 614 avoid L3 forwarding at the egress ISR, the egress can advertise the 615 inner shell label to the ingress ISRs in the Establish message. The 616 ingress ISRs may use this information to build its PDU accordingly. 617 At the tunnel egress ISR, the outer shell is removed and the packet 618 is switched based on the new outer shell. The egress may also 619 introduce a new inner shell for its next egress ISR in the path. In 620 this approach only one inner shell at a time is required. It is 621 possible to envisage multiple levels of inner labels where its 622 operation is similar in concept to loose source routing. 624 Some other useful applications are RSVP or DVMRP tunnels. With RSVP, 625 multiple sender flows can be "merged" into a L2-tunnel and de-merged 626 later at the end of the tunnel. At the de-merge point, L3 forwarding 627 is avoided by switching PDUs based on the new outer shell. 628 Similarly, in an ISR domain the DVMRP tunnels can be mapped to L2- 629 tunnels. For example, the ATM Virtual Path Switching can be used as 630 a tunneling mechanism for DVMRP tunnels, in that each (S, G) is 631 identified through an unique Virtual Circuit Identifier. 633 In situations when the ARIS Establish message originates at the 634 egress node, the label to be used at the end of the L2 tunnel may be 635 carried in the Establish message. The ISRs at the start of the 636 tunnel can use this information to build the inner shell. For 637 example, when establishing a multipoint-to-point switched path for an 638 egress BGP node, the establish message can carry the inner shell 639 label for each CIDR prefix. Alternatively, an optimization would be 640 to advertise these labels through an extension to the BGP protocol. 642 12. Quality of Service 644 ARIS can be extended to support Quality of Service (QoS) parameters. 645 This will be addressed in a future ARIS revision. 647 13. ARIS Advantages 649 This section summarizes the advantages of the ARIS protocol. Several 650 of the advantages listed below come from the egress orientation of 651 the ARIS protocol. 653 13.1. Single Point of Control 655 The ARIS protocol is largely root oriented (originating Establish 656 message at the root node of a switched path tree, although not 657 limited to it. For creating multipoint-to-point or point-to- 658 multipoint switched paths this gives the advantage of having a single 659 node, the root node, as the point of control. This provides the 660 convenience of only having to configure a single node to aggregate, 661 deaggregate, switching establishment on/off, or apply QoS etc. 663 13.2. Aggregation and Merging 665 As mentioned in a previous section, the switched path conservation in 666 ARIS is derived from the aggressive use of aggregation and switched 667 path merging. With aggregation, several flows are bundled into the 668 same switched path to reach the egress node. The switched path 669 merging provides the multipoint-to-point tree, which is most suitable 670 to carry best-effort traffic. These two features keep the order of 671 switched paths for ALL traffic to O(n), where n is the number of edge 672 nodes. 674 13.3. Multiple Levels of Aggregation 676 Multiple levels of aggregation can exists simultaneously in an ARIS 677 network. For example, there can be an aggregated switched path for 678 all networks (CIDRs) behind an egress BGP node, as well as individual 679 nonaggregated switched paths for CIDRs behind the same egress node. 680 This feature can be used to provide special services to a selective 681 set of CIDRs. 683 13.4. Loop Detection/Prevention 685 ARIS supports an explicit mechanism to either detect or prevent 686 looped switched paths. This feature can be useful in environments 687 employing switching technology that do not have a TTL equivalent 688 mechanism to contain resource wastage from switched path loops. This 689 mechanism does not require any switch specific hardware 690 implementation and can be effectively used to guarantee loop-free 691 switched paths in networks employing existing, commonly available 692 switches, such as ATM. 694 13.5. Traceroute Support 696 Traceroute is a tool commonly used by operators and users of a 697 network to debug, trace and locate network problems. ARIS provides 698 the optional support of making the ARIS switched network visible to 699 the traceroute tool. 701 13.6. Multicast 703 ARIS support for multicast, both source-specific and shared tree, is 704 similar in operation to the unicast support. No multicast routing 705 protocol changes are required. 707 13.7. Multipath 709 Equal cost multipath is a commonly used paradigm in existing networks 710 to load share traffic across multiple routed paths. ARIS has 711 explicit support for multipath in which multiple switched paths (one 712 corresponding to each routed path) is extended to the ingress node. 713 The ingress node can distribute traffic into these multiple switched 714 path as in conventional routers. Since the Establish message 715 originating at the egress node traverses the multipath nodes on its 716 way to the ingress ISRs, the support for multipath in ARIS is 717 straighforward. 719 13.8. L2 Tunneling 721 There is direct support for L2 tunneling in the ARIS protocol. The 722 inner shell labels can be advertised to the upstream ISRs via the 723 ARIS Establish message. This provides a self-contained solution for 724 leveraging L2 tunneling benefits. 726 13.9. Migration 728 Since an ISR behaves as a conventional router in addition to a 729 switch, networks can migrate to ARIS on an incremental basis. The 730 ISRs can be simply "dropped" into existing networks employing 731 conventional routers. In addition, due to the superset nature of the 732 ISR with respect to conventional routers, network management tools 733 work as is, with no required learning curve. 735 14. Security Consideration 737 An analysis of security considerations will be provided in a future 738 revision of this memo. 740 15. Intellectual Property Considerations 742 International Business Machines Corporation may seek patent or other 743 intellectual property protection for some or all of the aspects 744 discussed in the forgoing document. 746 16. Acknowledgements 748 The authors wish to acknowledge the following people for their input 749 and support: Brian Carpenter, Steve Blake, Ed Bowen, Jerry Marin, 750 Wayne Pace, Dean Skidmore, Hal Sandick, and Vijay Srinivasan. 752 17. References 754 [ARIS-LAN] 755 S. Blake, A. Ghanwani, W. Pace, V. Srinivasan, "ARIS Support for 756 LAN Media Switching", Internet Draft , March 1997 759 [ARIS-SPEC] 760 N. Feldman, A. Viswanathan, "ARIS Specification", Internet Draft 761 , March 1997 763 [IGMP-3] 764 B. Cain, S. Deering, A. Thyagarajan, "Internet Group Management 765 Protocol Version 3", Internet Draft , 766 University of Delaware, Xerox PARC, August 1995 768 [PIM-DM] 769 D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma, 770 A. Helmy, "Protocol Independent Multicast-Dense Mode (PIM-DM): 771 Protocol Specification", Internet Draft , USC, Cisco Systems, LBL, January 1996 774 [PIM-SM] 775 S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. 776 Wei, P. Sharma, A. Helmy, "Protocol Independent Multicast-Sparse 777 Mode (PIM-SM): Protocol Specification", Internet Draft , Xerox, Cisco Systems, USC, LBL, 779 September 1995 781 [RFC1075] 782 D. Waitzman, C. Partridge, S. Deering, "Distance Vector 783 Multicast Routing Protocol", RFC 1075, BBN, Stanford University, 784 November 1988 786 [RFC1112] 787 S. Deering, "Host extensions for IP multicasting", RFC 1112, 788 Stanford University, August 1989 790 [RFC1519] 791 V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain 792 Routing (CIDR): an Address Assignment and Aggregation 793 Strategy", RFC 1519, BARRNET, Cisco Systems, MERIT, OARnet, 794 September, 1993 796 [RFC1583] 797 J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March 1994 799 [RFC1584] 800 J. Moy, "Multicast Extensions to OSPF", RFC 1584, Proteon Inc, 801 March 1994 803 [RFC1771] 804 Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 805 1771, IBM Corp, Cisco Systems, March 1995 807 [RFC1812] 808 F. Baker (Editor), "Requirements for IP Version 4 Routers", RFC 809 1812, Cisco Systems, June 1995 811 Authors' Addresses 813 Rick Boivie 814 IBM Corp. 815 17 Skyline Drive 816 Hawthorne, NY 10532 817 Phone: +1 914-784-3251 818 Email: rboivie@vnet.ibm.com 820 Nancy Feldman 821 IBM Corp. 822 17 Skyline Drive 823 Hawthorne, NY 10532 824 Phone: +1 914-784-3254 825 Email: nkf@vnet.ibm.com 827 Arun Viswanathan 828 IBM Corp. 829 17 Skyline Drive 830 Hawthorne, NY 10532 831 Phone: +1 914-784-3273 832 Email: arunv@vnet.ibm.com 834 Richard Woundy 835 Continental Cablevision 836 The Pilot House - Lewis Wharf 837 Boston, MA 02110 838 Phone: +1 617-854-3351 839 Email: rwoundy@continental.com