[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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 <draft-blake-aris-lan-
        00.txt>, 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 <draft-cain-igmp-00.txt>,
        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 <draft-ietf-idmr-pim-
        dm-spec-01.txt>, 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 <draft-
        ietf-idmr-pim-spec-02.txt>, 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/