Internet Draft Internet-Draft Arun Viswanathan Expiration Date: September 1997 Nancy Feldman Rick Boivie Rich Woundy IBM Corp. March 1997 ARIS: Aggregate Route-Based IP Switching <draft-viswanathan-aris-overview-00.txt> Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract IP based networks use a number of routing protocols, including RIP, OSPF, IS-IS, and BGP, to determine how packets ought to be routed. Among these protocols, OSPF and BGP are IETF-recommended standards that have been extensively deployed and exercised in many networks. In this memo, we describe a mechanism which uses these protocols as the basis for switching IP datagrams, by the addition of a simple protocol ("ARIS") that establishes switched paths through a network. The ARIS protocol allows us to leverage the advantages of switching technologies in an internet network. Viswanathan, et al. Expires: September 1997 [Page 1] Internet-Draft ARIS Overview March 1997 1. Introduction In this memo, an Integrated Switch Router (ISR), is a switch that has been augmented with standard IP routing support. The ISR at an entry point to the switching environment performs standard IP forwarding of datagrams, but the "next hop" of the IP forwarding table has been extended to include a reference to a switched path (for example, the VCC in ATM technology). Each switched path may have an endpoint at a neighboring router (comparable to today's IP next hops on conventional routers), or may traverse a series of ISRs along the best IP forwarding path, to an egress ISR endpoint. This allows datagrams to be switched at hardware speeds through an entire ISR network. The key link between the IP network routing protocols and the ARIS switched path establishment protocol is the "egress identifier", which defines a routed path through a network. The egress identifier may refer to an egress ISR that forwards traffic either to a foreign routing domain, or across an area boundary within the same network. ARIS establishes switched paths towards each unique egress identifier. Since thousands of IP destinations can map to the same egress identifier, ARIS minimizes the number of switch paths required in an ISR network. This allows a large network to switch all of its IP traffic, resulting in improved aggregate IP throughput. 2. ARIS Mechanism In networks based on destination-based hop-by-hop forwarding, ARIS [ARIS-SPEC] pre-establishes switched paths to "well known" egress nodes. As a result, virtually all best-effort traffic is switched through an ARIS network. These "well known" egress nodes are learned through the routing protocols, such as OSPF and BGP. No routing protocol modification is required for this purpose, as this information is already present within the routing protocols themselves. Egress ISRs initiate the setup of switched paths by sending Establish messages to their upstream neighbors, typically within the same domain. These upstream neighbors forward the messages to their own upstream neighbors in Reverse Path Multicast style, after ensuring that the switched path is loop-free. Eventually, all ISRs establish switched paths to all egress ISRs, which follow the routed path. The switched path to an egress point, in general, takes the form of a tree. A tree results because of the "merging" of switched paths that occurs at a node when multiple upstream switched paths for a given egress point are spliced to a single downstream switched path for Viswanathan, et al. Expires: September 1997 [Page 2] Internet-Draft ARIS Overview March 1997 that egress point. 2.1. ARIS Messages ARIS is protocol independent. In the case of IP, ARIS message are transmitted with IP protocol number 104. ARIS uses the following messages to manage the switched paths. Init This is the first message sent by an ISR to each of its neighbors, as notification of its existence. It is periodically transmitted until a positive acknowledgment is received. The Init message may include the neighbor timeout period, acceptable label ranges, and other adjacency information. KeepAlive This message is sent by an ISR to inform its neighbors of its con- tinued existence. It is the first message that is transmitted after an adjacency has been established. In order to prevent the neighbor timeout period from expiring, ARIS messages must be periodically sent to neighbors. The KeepAlive will only be sent when no other ARIS messages have been transmitted within the periodic interval time. Establish This message is initiated by the egress ISR, and is periodically sent to each upstream neighbor to setup or refresh a switched path. It is also sent by any ISR in response to a Trigger mes- sage. Each ISR that receives an Establish message for an egress identifier must verify that the path is correct and loop free. If the Establish message changes a previously known switched path to the egress identifier, the ISR unsplices the obsolete switched path. The ISR creates a downstream switched path with the given label for the egress identifier, and replies with an Acknowledg- ment message. It then allocates a label for each of its upstream neighbors, forwards the Establish message to the upstream neigh- bors with its unique ISR ID appended to the ISR ID path and the label for the upstream neighbor to use for forwarding, and waits for an Acknowledgment message. This pattern continues until all ISRs are reached. Trigger This message is sent by an ISR when it has detected that a local IP routing change has modified its path to the egress identifier. After unsplicing the obsolete switched path, the ISR sends a Trigger message to its new downstream neighbor requesting an Establish message. Viswanathan, et al. Expires: September 1997 [Page 3] Internet-Draft ARIS Overview March 1997 Teardown This message may be sent when an ISR has lost connectivity to an egress identifier. The message follows the path of the Establish message unsplicing and releasing the obsolete switched path. Acknowledgment This message is sent as a response to ARIS messages. When an ISR receives a positive acknowledgment to an Establish message, it splices the upstream label to the downstream label creating a switched path through the ISR. 2.2. Egress Identifiers The ARIS protocol uses egress identifiers that balance the desire to share the same egress identifier among many IP destination prefixes, with the desire to maximize switching benefits. To provide flexibility, ARIS supports many types of egress identifiers. ISRs choose the type of egress identifier to use based on routing protocol information and local configuration. The first type of egress identifier is the IP destination prefix. This type results in each IP destination prefix sustaining its own switched path tree, and thus will not scale in large backbone and enterprise networks. However, this is the only information that some routing protocols, such as RIP, can provide. This type of identifier may work well in networks where the number of destination prefixes is limited, such as in campus environments, or even in a wide-area network of a private enterprise. The second type of egress identifier is the egress IP address. This type is used primarily for BGP protocol updates, which carry this information in the NEXT_HOP attribute [RFC1771]. There are certain types of OSPF routes that also use this type. The third type of egress identifier is the OSPF Router ID, which allows aggregation of traffic on behalf of multiple datagram protocols routed by OSPF. The latest version of OSPF supports the Router ID for both IP and IPv6 [RFC1583]. The fourth type of egress identifier is the multicast (source, group) pair [RFC1112], used by multicast protocols, such as DVMRP [RFC1075], MOSPF [RFC1584] and PIM ([PIM-SM], [PIM-DM]). The fifth is the (ingress-of-source, group), used for such multicast protocols as MOSPF and PIM-SM. Other egress identifier types may be defined, including but not limited to IS-IS NSAP addresses, NLSP IPX addresses, IPv6 destination Viswanathan, et al. Expires: September 1997 [Page 4] Internet-Draft ARIS Overview March 1997 prefixes, APPN etc. A hierarchy amongst the egress identifiers may be introduced to allow more flexible control over egress identifier selection. This allows an ISR to autolearn or be configured with non-default egress identifiers, and to select which egress identifiers to use in various routing situations. 2.3. ISR Information Base The ISR needs three logical information bases to compute routes and forward datagrams: the routing information base, the forwarding information base, and the VC information base. The first, the routing information base (RIB), is used for the computation of best- effort routes by various IP routing protocols. The RIB for the ISR is essentially unchanged from the RIB on a standard router. In the ISR context, the RIB is also used to identify egress points and egress identifiers for the other two information bases. The forwarding information base (FIB) of the ISR has been extended beyond the content of the FIB on a standard router to include an egress identifier in each next hop entry. The FIB tends to contain many IP destination prefix entries, which point to a small number of next hop entries that describe the hop-by-hop forwarding operation(s). Next hop entries on the ISR consist of an outgoing interface, next hop IP address, egress identifier, and the associated established downstream label for the switched path. The association of the next hops with the egress identifiers is the responsibility of the routing protocols, while the association of the next hop/egress identifiers with the established switched paths is the responsibility of the ARIS protocol. The VC information base (VCIB), which does not exist on a standard router, maintains for each egress identifier the upstream to downstream label mappings and related states. This mapping is controlled by the ARIS protocol. 2.4. Forwarding The forwarding ingress ISR performs a conventional longest prefix match lookup in its FIB, which returns the associated switched path label for the particular destination. The ingress ISR may also decrement the TTL by the length of the switched path before the packet is transmitted on the switched path. If no associated switched path is found in the FIB, the ingress node may forward the packet to the next hop via the default hop-by-hop switched path. Viswanathan, et al. Expires: September 1997 [Page 5] Internet-Draft ARIS Overview March 1997 2.5. TTL Decrement In order to comply with the requirements for IPv4 routers, the IP datagram Time-To-Live (TTL) field must be decremented on each hop it traverses [RFC1812]. Currently, switched packets within an ATM like networks cannot decrement the TTL. However, ARIS can decrement TTLs appropriately by maintaining a hop-count per egress identifier. This hop-count is calculated by including a hop-count field in the Establish message, which is incremented at each ISR as it traverses the upstream path. Before forwarding a packet on a switched path, an ingress ISR decrements the TTL by the hop-count plus one. If the decrement value is greater than or equal to the TTL of the packet, the packet may be forwarded hop-by-hop. 3. Loop Prevention The ARIS protocol guarantees that switched path loops are prevented, even in the presence of transient IP routing loops. With datagram forwarding loops, each hop decrements the TTL, so traffic is eventually dropped. However, some switching technologies, such as ATM, do not have a counter similar to the TTL, so traffic persists in a switched path loop as long as the switched path loop exists. The same it true for Frame Relay and LAN switches. At best, the traffic in the switched path loop steals bandwidth from other (UBR) switched paths; at worst, the traffic interferes with IP routing traffic, slows down routing convergence, and lengthens the life of the switched path loop. The ARIS protocol avoids creating switched path loops by the use of an "ISR ID" list, similar in function to the BGP AS_PATH attribute. Each ISR in the establishment path appends its own unique ISR ID to each establishment message it forwards. In this way, an ISR is able to determine the path a message has traversed, and can ensure that no loops are formed. Further, if an ISR modifies or deletes an egress due to an IP route change, or receives a message that modifies an existing switched path to an egress, the ISR must unsplice any established upstream switched path from the downstream switched path. Hence transient IP routing loops, potentially created by the route change, cannot produce switched path loops. The ISR must then re-establish a new switched path to the modified egress. Note that ARIS does not attempt to suppress transient IP routing protocol loops; it only avoids establishing switched path loops with this information. Viswanathan, et al. Expires: September 1997 [Page 6] Internet-Draft ARIS Overview March 1997 4. Egress ISRs In the ARIS protocol, Establishment messages are originated from the egress ISR. An ISR is considered an egress ISR, with respect to a particular egress identifier, under any of the following conditions: 1. The egress identifier refers to the ISR itself (including one of its directly attached interfaces). 2. The egress identifier is reachable via a next hop router that is outside the ISR switching infrastructure. 3. The egress identifier is reachable by crossing a routing domain boundary, such as another area for OSPF summary networks, or another autonomous system for OSPF AS externals and BGP routes. 5. Examples 5.1. Establish Initiation Example +---+ .... | 2 | +---+ ---> +---+ +--------+ | 1 | ---> | Egress | --> ... +---+ ---> +---+ +--------+ .... | 3 | +---+ Example: Egress initiates Establish a) The Egress ISR learns of an egress identifier that indicates the egress is itself (see "Egress ISRs"). It creates a FIB entry for its next hop and egress identifier (itself). b) The Egress creates a VCIB entry with an allocated upstream label to ISR1, and initiates an Establish message with the upstream label, and itself in the ISR ID path. c) ISR1 verifies that the Establish message was received from the expected next hop (Egress) by matching its FIB entry, and verifies that the ISR ID path is loop free. It then creates a VCIB entry and a switched path with the downstream label to the Egress, replaces the default switched path label in the FIB with Viswanathan, et al. Expires: September 1997 [Page 7] Internet-Draft ARIS Overview March 1997 this new label, and replies to the Egress with an Acknowledgment message. d) ISR1 allocates an upstream label to each of its upstream neighbors, ISR2 and ISR3, and updates the corresponding VCIB entry. It forwards the Establish message to each upstream neighbor, with its own ISR ID appended to the ISR ID path and with the label to use. e) When ISR1 receives each acknowledgment from each upstream neighbor, it updates the VCIB and splices the corresponding upstream label to its Egress downstream label. All upstream ISRs recursively follow the same procedures as ISR1, until all Ingress ISRs have been added to the switched path to the Egress. The Egress ISR is responsible for periodically sending refresh Establish messages, to prevent switched path timeouts. If a refresh is not received in the allotted time, switched paths are unspliced and associated labels are released. 5.2. Trigger Example +---+ +-X-> | 2 | ---> ........ | +---+ . +---+ +---+ --> +--------+ .... | 4 | ---> | 1 | | Egress | +---+ +---+ --> +--------+ | +---+ . +---> | 3 | ---> ........ +---+ Example: ISR1 changes routes from ISR2 to ISR3 a) ISR1 learns of a new path to the Egress via ISR3 from the routing protocols. It removes the FIB and VCIB entries for the next hop ISR2/Egress. ISR1 creates a new FIB entry for the next hop ISR3/Egress with the default switched path to the next hop. b) ISR1 sends a Trigger message to new downstream node ISR3 requesting an Establish message for the switched path to the Egress. c) ISR3 allocates an upstream label, updates its corresponding VCIB Viswanathan, et al. Expires: September 1997 [Page 8] Internet-Draft ARIS Overview March 1997 entry, and replies with an Establish message to ISR1, containing the full ISR ID path and the label. d) ISR1 verifies that the Establish message was received from the expected next hop (ISR3), and that the ISR ID path is loop free. It then creates a new VCIB entry and a switched path with the given downstream label to ISR3, and replaces the default switched path label in the FIB with this new label. e) ISR1 sends an Acknowledgment message to ISR3. f) ISR3 receives the Acknowledgment, updates the VCIB and splices its ISR1 upstream label to its downstream label. g) ISR1 appends its ISR ID to the Establish message, and forwards the message to ISR4 with the upstream label. h) ISR4 verifies the Establish message, updates the VCIB, and unsplices the current switched path to ISR1/Egress from its upstream node(s), and sends an Acknowledgment to ISR1. i) ISR1 receives the Acknowledgment, updates the VCIB and splices the ISR4 upstream label to the ISR3 downstream label. j) ISR4 appends its ISR ID to the path, and forwards the establishment message to its upstream neighbors with a label. When ISR4 receives an Acknowledgment from an upstream neighbor, it updates the VCIB and splices the upstream label to the ISR1 downstream label. All upstream ISRs recursively follow the same procedure as ISR4, until all ingress ISRs have been updated. 6. Explicit Routes Today's Internet is predominantly based on the destination-based hop-by-hop forwarding paradigm. However, other routing and forwarding paradigms, such as strict source routing, may be useful to provide specialized and customized services. For this reason, the ARIS protocol supports the building of switched paths through explicit routes. This is enabled by introducing the explicit source route path information in the Establish message. The Establish message is forwarded along the explicit path as identified by the source route information. ARIS supports building of point-to-point, point-to- multipoint and multipoint-to-point switched paths either from the Viswanathan, et al. Expires: September 1997 [Page 9] Internet-Draft ARIS Overview March 1997 egress node or the ingress node. Note that the switched paths built by source routing are guaranteed to be loop-free. It's also possible to set up bi-directional switched paths or switched paths with QoS using this approach. 7. Multicast The ARIS protocol can be used to setup switched paths for IP multicast traffic. The establishment of a point-to-multipoint switched path tree is initiated at the root (ingress) node. The switched path tree carries traffic from the ingress ISR to all egress ISRs, using multicast switching at intermediate ISRs. The choice of egress identifier for multicast routing protocols such as DVMRP and PIM-DM is the (S,G) pair itself. This egress identifier creates one ingress routed point-to-multipoint switched path tree per source address and group pair. The creation of a switched path is initiated by an ingress node on receipt of traffic from a certain sender for a particular multicast group. The Establish message traverses from the ingress node to the downstream ISRs in the Reverse Path Multicast (RPM) style. The branches of the point-to-multipoint switched path tree that do not lead to receivers are pruned when the multicast routing protocol prunes up by deleting forwarding entries in the multicast FIB. Having multicast switched paths set up on the basis of (S,G) works well with the IGMPv3 Group-Source messages, since these IGMP messages can create unique trees for each sender within the same group [11]. For multicast routing protocols, such as PIM-SM, that use a shared tree, an appropriate choice of egress identifier is (*, G) or (RP, G) (where RP is the PIM-SM Rendezvous Point for the group). The switched path establishment for the shared-tree works exactly as explained above, except that the Establish message is initiated when the PIM Join/Prune message from the receiver's DR (Designated Router) reaches the RP node. The Establish message for a source-specific tree is also originated at the ingress node. This again is initiated by the receipt of a PIM Join/Prune message. The Establish message for a source-specific tree uses the (S,G) egress identifier. In both cases, the Establish message is forwarded according to the states created by the PIM protocol. All multicast switched path trees are periodically refreshed by retransmitting an Establish message. The periodic refreshes may also be used to keep the multicast forwarding states active since the intermediate ISRs may not forward packets at network layer. When a new receiver is explicitly grafted in the multicast distribution Viswanathan, et al. Expires: September 1997 [Page 10] Internet-Draft ARIS Overview March 1997 tree, the ISR into which the new branch is spliced may issue an Establish message downstream or wait for the next refresh cycle to create the switched path branch along the newly grafted branch to the multicast distribution tree. The loop prevention mechanism for multicast works in the exact same manner as for the unicast case expounded previously. Each ISR appends it's ISR ID to the path in the Establish message before forwarding it to the downstream ISRs. ISRs which receive an Establish message verify a loop-free message via the ISR ID path. 8. Host-to-Host Connectivity Dedicated switched paths for host-to-host connectivity may be established with either RSVP [Rsvp] or ARIS. Since this may pose scalability problems in networks that support a large number of active hosts, it is desirable to provide complete host-to-host switched path connectivity using the pre-established aggregated ARIS connections in a network. This maintains good scaling properties in the backbone of the network by conserving labels for premium services, and at the same time provides end-to-end switching for hosts directly attached to the ARIS network. In this approach, a dedicated switched path is created between the host and the ingress (or egress) and this in turn is spliced to the aggregated switched path. The creation of the switched path can be either be initiated by the host or by an ISR by thresholding on the flow. 9. Label Conservation An important goal of the ARIS protocol is to minimize the number of switched paths required by ISRs to switch all IP traffic in a network. Since switches may support only a limited label space, ARIS restrains its label consumption so that labels are available as needed for its own use, as well as for other services, such as RSVP. Further benefits include simplification of network management, both for automated tools and for human comprehension and analysis, and switched path setup overhead. The consumption of labels is minimized: o by the use of egress routers that may map thousands of IP destinations to the same switched, and o by enabling the merging of switched paths. Viswanathan, et al. Expires: September 1997 [Page 11] Internet-Draft ARIS Overview March 1997 This combination can provide O(n) switched paths, where n is the number of egress nodes. 9.1. Aggregation The network routing domain has the greatest performance and label conservation when all routers in the domain are ISRs. Maximum ARIS benefits are also tied closely to an IP network routing topology with a high ratio of IP destinations to egresses, as exists in a typical IP backbone. However, ARIS is flexible enough to be highly beneficial even in networks with partial ISR deployments or arbitrary network routing topologies. 9.2. Switched Path Merging The merging of switched paths enables ARIS to create switched path trees, each of which connects all of the ingresses to a given egress. This results in n trees, where n is the number of egresses in a network, while still providing the benefits of full mesh connectivity (without O(n**2) switched paths). 10. ARIS on Specific Switching Technologies 10.1. Asynchronous Transfer Mode (ATM) The ability of the ARIS protocol to conserve the number of switched paths depends on the hardware capabilities of the ISR. Some ATM switching components can "merge" multiple inbound VCs onto one outbound VC at close to standard switching rates. These merge- capable components are able to buffer cells from the inbound VCs till all cells of a frame arrive, and inject the frames into the outbound VC, without interleaving cells from different frames. The ARIS usage of "merged" VC flows requires that ATM switching hardware have the capability of preventing cell interleaving (see "VC Conservation"). Unfortunately, much of the existing ATM switching hardware cannot support VC merging. One solution to this problem is to use virtual paths (VPs) to egress points, rather than virtual circuits (VCs). The virtual path extension merges VPs, creating trees of VPs to the egress points, instead of merging VCs. Cell interleaving is prevented by the assignment of unique VC identifiers (VCIs) within each VP. The ISRs within a network are assigned unique VCIs to prevent VCI Viswanathan, et al. Expires: September 1997 [Page 12] Internet-Draft ARIS Overview March 1997 collisions when paths from different ISRs are merged. Each ISR requires a block of VCIs as labels to distinguish between cell paths to the same egress identifier. By assigning a unique block of VCIs to each ISR, ARIS guarantees that an ISR at a network merge point can safely merge upstream VP flows for an egress identifier to a single downstream VP without VCI collisions. Although the virtual path extension uses VCs much less efficiently than a VC merging implementation, it reduces network latency and hardware requirements because frame reassembly and re-segmentation is not required on intermediate ISRs. In addition, although this variation uses more VC space, the work involved in establishing and maintaining switched paths is still O(n). An alternative approach to the VC merging problem is to use an end- to-end VC label upstream allocation. This allows the ingress node to choose the downstream VC. In this approach, ISRs acknowledge the Establishment message with a label only after they receive an Acknowledgment message from their own upstream neighbor. Thus, the Establishment message traverses fully to the ingress node before being acknowledged. Ingress ISRs immediately acknowledge the Establishment message with the VC label. These acknowledgements may be merged as they travel downstream to the egress node. This method adds latency in the VC set up, and removes the benefits of ARIS VC aggregation (O(n**2) versus O(n) VCs). However, it adds the flexibility of performing VC-switching instead of VP-switching, which also makes switching possible at the routing boundaries. 10.2. Frame Switching Technology While ARIS solves the problem of cell interleaving in the case of ATM by Virtual Path switching, it naturally and easily maps to a frame switching environment. This is due to the fact that multiple upstream flows can be merged into a single downstream flow without the problems of cell interleaving. 10.3. LAN Switching Technology LAN switches are different than other frame switches, in that they typically do not perform label swapping, and instead switch frames based on their 6-byte IEEE MAC destination address. The label in this case can be considered as the 6-byte MAC address, which has global significance within the ARIS network. The advantages of this approach are that it augments LAN switches with routing functionality and helps achieve media speed switching between LAN segments [ARIS- LAN] without requiring hardware enhancements. Viswanathan, et al. Expires: September 1997 [Page 13] Internet-Draft ARIS Overview March 1997 11. Layer-2 Tunneling Like IP-in-IP tunnels, the L2-in-L2 tunnels can be useful in several different scenarios. In this, a L2 PDU is encapsulated into another L2 PDU. The outer shell carries the PDU to a predetermined termination point, at which the outer shell is removed and the PDU is switched based on the inner shell (now the outer shell after the de- encapsulation). Note that in a L2-tunnel, the label switching and swapping happens only on the outer shell. The L2 header of the inner shell is not examined until the tunnel termination point. One simple application of this is private virtual networking, similar in manner to IP-in-IP tunneling. Another important usage is switching through routing hierarchies. At the egress ISR of a switched path that carries aggregated traffic, the packet must be L3 forwarded even if the packets are to continue on a different switched path. This is typical at the egress ISR. Traffic from all ingresses flow towards the egress ISR using the same switched path tree. To avoid L3 forwarding at the egress ISR, the egress can advertise the inner shell label to the ingress ISRs in the Establish message. The ingress ISRs may use this information to build its PDU accordingly. At the tunnel egress ISR, the outer shell is removed and the packet is switched based on the new outer shell. The egress may also introduce a new inner shell for its next egress ISR in the path. In this approach only one inner shell at a time is required. It is possible to envisage multiple levels of inner labels where its operation is similar in concept to loose source routing. Some other useful applications are RSVP or DVMRP tunnels. With RSVP, multiple sender flows can be "merged" into a L2-tunnel and de-merged later at the end of the tunnel. At the de-merge point, L3 forwarding is avoided by switching PDUs based on the new outer shell. Similarly, in an ISR domain the DVMRP tunnels can be mapped to L2- tunnels. For example, the ATM Virtual Path Switching can be used as a tunneling mechanism for DVMRP tunnels, in that each (S, G) is identified through an unique Virtual Circuit Identifier. In situations when the ARIS Establish message originates at the egress node, the label to be used at the end of the L2 tunnel may be carried in the Establish message. The ISRs at the start of the tunnel can use this information to build the inner shell. For example, when establishing a multipoint-to-point switched path for an egress BGP node, the establish message can carry the inner shell label for each CIDR prefix. Alternatively, an optimization would be to advertise these labels through an extension to the BGP protocol. Viswanathan, et al. Expires: September 1997 [Page 14] Internet-Draft ARIS Overview March 1997 12. Quality of Service ARIS can be extended to support Quality of Service (QoS) parameters. This will be addressed in a future ARIS revision. 13. ARIS Advantages This section summarizes the advantages of the ARIS protocol. Several of the advantages listed below come from the egress orientation of the ARIS protocol. 13.1. Single Point of Control The ARIS protocol is largely root oriented (originating Establish message at the root node of a switched path tree, although not limited to it. For creating multipoint-to-point or point-to- multipoint switched paths this gives the advantage of having a single node, the root node, as the point of control. This provides the convenience of only having to configure a single node to aggregate, deaggregate, switching establishment on/off, or apply QoS etc. 13.2. Aggregation and Merging As mentioned in a previous section, the switched path conservation in ARIS is derived from the aggressive use of aggregation and switched path merging. With aggregation, several flows are bundled into the same switched path to reach the egress node. The switched path merging provides the multipoint-to-point tree, which is most suitable to carry best-effort traffic. These two features keep the order of switched paths for ALL traffic to O(n), where n is the number of edge nodes. 13.3. Multiple Levels of Aggregation Multiple levels of aggregation can exists simultaneously in an ARIS network. For example, there can be an aggregated switched path for all networks (CIDRs) behind an egress BGP node, as well as individual nonaggregated switched paths for CIDRs behind the same egress node. This feature can be used to provide special services to a selective set of CIDRs. Viswanathan, et al. Expires: September 1997 [Page 15] Internet-Draft ARIS Overview March 1997 13.4. Loop Detection/Prevention ARIS supports an explicit mechanism to either detect or prevent looped switched paths. This feature can be useful in environments employing switching technology that do not have a TTL equivalent mechanism to contain resource wastage from switched path loops. This mechanism does not require any switch specific hardware implementation and can be effectively used to guarantee loop-free switched paths in networks employing existing, commonly available switches, such as ATM. 13.5. Traceroute Support Traceroute is a tool commonly used by operators and users of a network to debug, trace and locate network problems. ARIS provides the optional support of making the ARIS switched network visible to the traceroute tool. 13.6. Multicast ARIS support for multicast, both source-specific and shared tree, is similar in operation to the unicast support. No multicast routing protocol changes are required. 13.7. Multipath Equal cost multipath is a commonly used paradigm in existing networks to load share traffic across multiple routed paths. ARIS has explicit support for multipath in which multiple switched paths (one corresponding to each routed path) is extended to the ingress node. The ingress node can distribute traffic into these multiple switched path as in conventional routers. Since the Establish message originating at the egress node traverses the multipath nodes on its way to the ingress ISRs, the support for multipath in ARIS is straighforward. 13.8. L2 Tunneling There is direct support for L2 tunneling in the ARIS protocol. The inner shell labels can be advertised to the upstream ISRs via the ARIS Establish message. This provides a self-contained solution for leveraging L2 tunneling benefits. Viswanathan, et al. Expires: September 1997 [Page 16] Internet-Draft ARIS Overview March 1997 13.9. Migration Since an ISR behaves as a conventional router in addition to a switch, networks can migrate to ARIS on an incremental basis. The ISRs can be simply "dropped" into existing networks employing conventional routers. In addition, due to the superset nature of the ISR with respect to conventional routers, network management tools work as is, with no required learning curve. 14. Security Consideration An analysis of security considerations will be provided in a future revision of this memo. 15. Intellectual Property Considerations International Business Machines Corporation may seek patent or other intellectual property protection for some or all of the aspects discussed in the forgoing document. 16. Acknowledgements The authors wish to acknowledge the following people for their input and support: Brian Carpenter, Steve Blake, Ed Bowen, Jerry Marin, Wayne Pace, Dean Skidmore, Hal Sandick, and Vijay Srinivasan. 17. References [ARIS-LAN] S. Blake, A. Ghanwani, W. Pace, V. Srinivasan, "ARIS Support for LAN Media Switching", Internet Draft, March 1997 [ARIS-SPEC] N. Feldman, A. Viswanathan, "ARIS Specification", Internet Draft <draft-feldman-aris-spec-00.txt>, March 1997 [IGMP-3] B. Cain, S. Deering, A. Thyagarajan, "Internet Group Management Protocol Version 3", Internet Draft , University of Delaware, Xerox PARC, August 1995 [PIM-DM] Viswanathan, et al. Expires: September 1997 [Page 17] Internet-Draft ARIS Overview March 1997 D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma, A. Helmy, "Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol Specification", Internet Draft , USC, Cisco Systems, LBL, January 1996 [PIM-SM] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma, A. Helmy, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", Internet Draft , Xerox, Cisco Systems, USC, LBL, September 1995 [RFC1075] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, BBN, Stanford University, November 1988 [RFC1112] S. Deering, "Host extensions for IP multicasting", RFC 1112, Stanford University, August 1989 [RFC1519] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNET, Cisco Systems, MERIT, OARnet, September, 1993 [RFC1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March 1994 [RFC1584] J. Moy, "Multicast Extensions to OSPF", RFC 1584, Proteon Inc, March 1994 [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, IBM Corp, Cisco Systems, March 1995 [RFC1812] F. Baker (Editor), "Requirements for IP Version 4 Routers", RFC 1812, Cisco Systems, June 1995 Authors' Addresses Rick Boivie IBM Corp. 17 Skyline Drive Hawthorne, NY 10532 Viswanathan, et al. Expires: September 1997 [Page 18] Internet-Draft ARIS Overview March 1997 Phone: +1 914-784-3251 Email: rboivie@vnet.ibm.com Nancy Feldman IBM Corp. 17 Skyline Drive Hawthorne, NY 10532 Phone: +1 914-784-3254 Email: nkf@vnet.ibm.com Arun Viswanathan IBM Corp. 17 Skyline Drive Hawthorne, NY 10532 Phone: +1 914-784-3273 Email: arunv@vnet.ibm.com Richard Woundy Continental Cablevision The Pilot House - Lewis Wharf Boston, MA 02110 Phone: +1 617-854-3351 Email: rwoundy@continental.com Viswanathan, et al. Expires: September 1997 [Page 19]