home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-woundy-aris-ipswitching-00.txt < prev    next >
Text File  |  1996-11-18  |  41KB  |  1,017 lines
  1.  
  2.  
  3. Internet-Draft                                            Richard Woundy
  4. Expiration Date: May 1997                               Arun Viswanathan
  5.                                                            Nancy Feldman
  6.                                                              Rick Boivie
  7.                                                                IBM Corp.
  8.  
  9.                                                            November 1996
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.                 ARIS: Aggregate Route-Based IP Switching
  17.  
  18.                  <draft-woundy-aris-ipswitching-00.txt>
  19.  
  20.  
  21.  
  22.  
  23.  
  24. Status of This Memo
  25.  
  26.    This document is an Internet-Draft.  Internet-Drafts are working
  27.    documents of the Internet Engineering Task Force (IETF), its areas,
  28.    and its working groups.  Note that other groups may also distribute
  29.    working documents as Internet-Drafts.
  30.  
  31.    Internet-Drafts are draft documents valid for a maximum of six months
  32.    and may be updated, replaced, or obsoleted by other documents at any
  33.    time.  It is inappropriate to use Internet-Drafts as reference
  34.    material or to cite them other than as "work in progress."
  35.  
  36.    To learn the current status of any Internet-Draft, please check the
  37.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  38.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  39.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  40.    ftp.isi.edu (US West Coast).
  41.  
  42.  
  43. Abstract
  44.  
  45.    IP based networks use a number of routing protocols, including RIP,
  46.    OSPF, IS-IS, and BGP, to determine how packets ought to be routed.
  47.    Among these protocols, OSPF and BGP are IETF-recommended standards
  48.    that have been extensively deployed and exercised in many networks.
  49.    In this memo, we describe a mechanism which uses these protocols as
  50.    the basis for switching IP datagrams, by the addition of a simple
  51.  
  52.  
  53.  
  54. Woundy, et al.            Expiration: May 1997                  [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60. Internet-Draft                    ARIS                     November 1996
  61.  
  62.  
  63.    protocol ("ARIS") that establishes switched paths through a network.
  64.    The ARIS protocol allows us to leverage the advantages of switching
  65.    technologies in an internet network.
  66.  
  67.    This memo is defined with respect to ATM.  ARIS can be easily
  68.    extended to other switching technologies.
  69.  
  70.  
  71. 1. Introduction
  72.  
  73.    In this paper, an Integrated Switch Router (ISR), is a standard IP
  74.    router that has been augmented with ATM virtual circuit (VC)
  75.    switching support.  The ISR at an entry point to the ATM switching
  76.    environment performs standard IP forwarding of datagrams, but the
  77.    "next hop" of the IP forwarding table has been extended to include a
  78.    reference to a VC (switched path).  Each VC may have an endpoint at a
  79.    neighboring router (comparable to today's IP next hops on
  80.    conventional routers), or may traverse a series of ISRs along the
  81.    best IP forwarding path, to an egress ISR endpoint.  This allows
  82.    datagrams to be switched at hardware speeds through an entire ISR
  83.    network.
  84.  
  85.    The key link between the IP network routing protocols and the ARIS VC
  86.    establishment protocol is the "egress identifier".  The egress
  87.    identifier refers to an egress ISR that forwards traffic either to a
  88.    foreign routing domain, or across an area boundary within the same
  89.    network.  ARIS establishes VCs towards each unique egress identifier.
  90.    Since thousands of IP destinations can map to the same egress
  91.    identifier, ARIS minimizes the number of VCs required in an ISR
  92.    network.  This allows a large network to switch all of its IP
  93.    traffic, resulting in improved aggregate IP throughput.
  94.  
  95.    Egress ISRs initiate the setup of VCs by sending Establishment
  96.    messages to their upstream neighbors, typically within the same
  97.    domain.  These upstream neighbors forward the messages to their own
  98.    upstream neighbors in Reverse Path Multicast style, after ensuring
  99.    that the VC path is loop-free.  Eventually, all ISRs establish VCs to
  100.    all egress ISRs.
  101.  
  102.    The VC to an egress point, in general, takes the form of a tree.  A
  103.    tree results because of the "merging" of VCs that occurs at a node
  104.    when multiple upstream VCs for a given egress point are spliced to a
  105.    single downstream VC for that egress point.
  106.  
  107.  
  108. 2. VC Conservation
  109.  
  110.    An important goal of the ARIS protocol is to minimize the number of
  111.  
  112.  
  113.  
  114. Woundy, et al.            Expiration: May 1997                  [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120. Internet-Draft                    ARIS                     November 1996
  121.  
  122.  
  123.    VCs required by ISRs to switch all IP traffic in the switching cloud.
  124.    Since switches may support only a limited VPI/VCI space, ARIS
  125.    restrains its VC consumption so that VCs are available as needed for
  126.    its own use, as well as for ATM services and other applications, such
  127.    as RSVP.  Further benefits include simplification of network
  128.    management, both for automated tools and for human comprehension and
  129.    analysis, and VC-setup overhead.
  130.  
  131.    The consumption of VCs is minimized:
  132.  
  133.         o    by the use of egress routers that may map thousands of IP
  134.              destinations to the same VC, and
  135.  
  136.         o    by enabling the merging of VCs.
  137.  
  138.    The merging of VCs enables ARIS to create VC trees, each of which
  139.    connects all of the ingresses to a given egress.  This results in n
  140.    trees, where n is the number of egresses in a network, while still
  141.    providing the benefits of full mesh connectivity (without O(n**2)
  142.    VCs).
  143.  
  144.    The network routing domain has the greatest performance and VC
  145.    conservation when all routers in the domain are ISRs.  Maximum ARIS
  146.    benefits are also tied closely to an IP network routing topology with
  147.    a high ratio of IP destinations to egresses, as exists in a typical
  148.    IP backbone.  However, ARIS is flexible enough to be highly
  149.    beneficial even in networks with partial ISR deployments or arbitrary
  150.    network routing topologies.
  151.  
  152.    The ability of the ARIS protocol to conserve the number of VCs
  153.    depends on the hardware capabilities of the ISR.  Some ATM switching
  154.    components can "merge" multiple inbound VCs onto one outbound VC at
  155.    close to standard switching rates.  These merge-capable components
  156.    are able to reassemble cells from the inbound VCs into frames, and
  157.    inject the frames into the outbound VC, without interleaving cells
  158.    from different frames.
  159.  
  160.  
  161. 3. Loop Prevention
  162.  
  163.    The ARIS protocol guarantees that VC loops are prevented, even in the
  164.    presence of transient IP routing loops.  With datagram forwarding
  165.    loops, each hop decrements the TTL, so traffic is eventually dropped.
  166.    However, ATM switching does not have a counter similar to the TTL, so
  167.    traffic persists in a VC loop as long as the VC loop exists.  At
  168.    best, the traffic in the VC loop steals bandwidth from other (UBR)
  169.    VCs; at worst, the traffic interferes with IP routing traffic, slows
  170.    down routing convergence, and lengthens the life of the VC loop.
  171.  
  172.  
  173.  
  174. Woundy, et al.            Expiration: May 1997                  [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Internet-Draft                    ARIS                     November 1996
  181.  
  182.  
  183.    The ARIS protocol avoids creating VC loops by the use of an "ISR ID"
  184.    list, similar in function to the BGP AS_PATH attribute.  Each ISR in
  185.    the VC establishment path appends its own unique ISR ID to each
  186.    establishment message it forwards.  In this way, an ISR is able to
  187.    determine the path a message has traversed, and can ensure that no
  188.    loops are formed.
  189.  
  190.    Further, if an ISR modifies or deletes an egress due to an IP route
  191.    change, or receives a message that modifies an existing VC to an
  192.    egress, the ISR must unsplice any established upstream VC from the
  193.    downstream VC.  This unsplicing forces inbound traffic to be
  194.    forwarded at the IP network layer, so that transient IP routing
  195.    loops, potentially created by the route change, cannot produce VC
  196.    loops.  The ISR must then re-establish a new VC to the modified
  197.    egress.  Note that ARIS does not attempt to suppress transient IP
  198.    routing protocol loops; it only avoids establishing VC loops with
  199.    this information.
  200.  
  201.  
  202. 4. ARIS Messages
  203.  
  204.    The ARIS protocol runs directly over IP, using IP protocol TBD.  The
  205.    following messages are used to manage the ISR switching cloud:
  206.  
  207.    Init
  208.       This is the first message sent by an ISR to each of its neighbors,
  209.       as notification of its existence.  It is periodically transmitted
  210.       until a positive acknowledgment is received.  The Init message may
  211.       include the neighbor timeout period, acceptable VC label range,
  212.       encapsulation scheme [1], and other adjacency information.
  213.  
  214.    KeepAlive
  215.       This message is sent by an ISR to inform its neighbors of its
  216.       continued existence.  It is the first message that is transmitted
  217.       after an adjacency has been established.  In order to prevent the
  218.       neighbor timeout period from expiring, ARIS messages must be
  219.       periodically sent to neighbors.  The VC KeepAlive will only be
  220.       sent when no other ARIS messages have been transmitted within the
  221.       periodic interval time.  A recommended transmission interval is
  222.       1/3 of the exchanged neighbor timeout period.
  223.  
  224.    Establishment
  225.       This message is initiated by the egress ISR, and is periodically
  226.       sent to each upstream neighbor to setup or refresh a VC.  It is
  227.       also sent by any ISR in response to a Trigger message.  Each ISR
  228.       that receives an Establishment message for an egress identifier
  229.       must verify that the path is correct and loop free.  If the
  230.       Establishment message changes a previously known VC path to the
  231.  
  232.  
  233.  
  234. Woundy, et al.            Expiration: May 1997                  [Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240. Internet-Draft                    ARIS                     November 1996
  241.  
  242.  
  243.       egress identifier, the ISR unsplices the obsolete VC.  The ISR
  244.       creates a downstream VC for the egress identifier, and replies
  245.       with an Acknowledgment message.  It then creates a VC for each of
  246.       its upstream neighbors, forwards the Establishment message to the
  247.       upstream neighbors with its unique ISR ID appended to the ISR ID
  248.       path and the VC label for the upstream neighbor to use for
  249.       forwarding, and waits for an Acknowledgment message.  This pattern
  250.       continues until all ISRs are reached.
  251.  
  252.    Trigger
  253.       This message is sent by an ISR when it has detected that a local
  254.       IP routing change has modified its path to the egress identifier.
  255.       After unsplicing the obsolete VC, the ISR sends a Trigger message
  256.       to its new downstream neighbor requesting an Establishment
  257.       message.
  258.  
  259.    Teardown
  260.       This message may be sent when an ISR has lost all connectivity to
  261.       an egress identifier, or when a downstream node to an egress
  262.       identifier has become an upstream node due to routing changes.  In
  263.       the former case, the message traverses the upstream ISR paths of
  264.       the VC, unsplicing each VC along the way.  In the latter case, the
  265.       message is sent single hop to the new upstream (previously
  266.       downstream) node, unsplicing the obsolete VC.
  267.  
  268.    Acknowledgment
  269.       This message is sent as a response to ARIS messages.  When an ISR
  270.       receives a positive acknowledgment to Init message, it responds
  271.       with a KeepAlive message.  When an ISR receives a positive
  272.       acknowledgment to an Establishment message, it splices the
  273.       upstream VC to the downstream VC.
  274.  
  275.  
  276. 5. ISR Information Bases
  277.  
  278.    The ISR needs three logical information bases to compute routes and
  279.    forward datagrams: the routing information base, the forwarding
  280.    information base, and the VC information base.  The first, the
  281.    routing information base (RIB), is used for the computation of best-
  282.    effort routes by various IP routing protocols.  The RIB for the ISR
  283.    is essentially unchanged from the RIB on a standard router.  In the
  284.    ISR context, the RIB is also used to identify egress points and
  285.    egress identifiers for the other two information bases.
  286.  
  287.    The forwarding information base (FIB) of the ISR has been extended
  288.    beyond the content of the FIB on a standard router to include an
  289.    egress identifier in each next hop entry.  The FIB tends to contain
  290.    many IP destination prefix entries, which point to a small number of
  291.  
  292.  
  293.  
  294. Woundy, et al.            Expiration: May 1997                  [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. Internet-Draft                    ARIS                     November 1996
  301.  
  302.  
  303.    next hop entries that describe the hop-by-hop forwarding
  304.    operation(s).  Next hop entries on the ISR consist of an outgoing
  305.    interface, next hop IP address, egress identifier, and the associated
  306.    established downstream VC.  The association of the next hops with the
  307.    egress identifiers is the responsibility of the routing protocols,
  308.    while the association of the next hop/egress identifiers with the
  309.    established VCs is the responsibility of the ARIS protocol.
  310.  
  311.    The VC information base (VCIB), which does not exist on a standard
  312.    router, maintains for each egress identifier the upstream to
  313.    downstream VC mappings and related states. This mapping is controlled
  314.    by the ARIS protocol.
  315.  
  316.  
  317. 6. Egress Identifiers
  318.  
  319.    The ARIS protocol uses egress identifiers that balance the desire to
  320.    share the same egress identifier among many IP destination prefixes,
  321.    with the desire to maximize switching benefits.  To provide
  322.    flexibility, ARIS supports many types of egress identifiers.  ISRs
  323.    choose the type of egress identifier to use based on routing protocol
  324.    information and local configuration.
  325.  
  326.    The first type of egress identifier is the IP destination prefix.
  327.    This type results in each IP destination prefix sustaining its own VC
  328.    tree, and thus will not scale in large backbone and enterprise
  329.    networks.  However, this is the only information that some routing
  330.    protocols, such as RIP, can provide.  This type of identifier may
  331.    work well in networks where the number of destination prefixes is
  332.    limited, such as in campus environments, or even in a wide-area
  333.    network of a private enterprise.
  334.  
  335.    The second type of egress identifier is the egress IP address.  This
  336.    type is used primarily for BGP protocol updates, which carry this
  337.    information in the NEXT_HOP attribute [2].  There are certain types
  338.    of OSPF routes that also use this type.  See "BGP Interaction" and
  339.    "OSPF Interaction" for detailed information.
  340.  
  341.    The third type of egress identifier is the OSPF Router ID, which
  342.    allows aggregation of traffic on behalf of multiple datagram
  343.    protocols routed by OSPF.  The latest version of OSPF, OSPFv3,
  344.    supports the Router ID for both IP and IPv6 [3].  See "OSPF
  345.    Interaction" for further information.
  346.  
  347.    The fourth type of egress identifier is the multicast (source, group)
  348.    pair [4], used by multicast protocols, such as DVMRP [5], MOSPF [6]
  349.    and PIM ([7], [8]).  The fifth is the (ingress-of-source, group),
  350.    used for such multicast protocols as MOSPF and PIM.  See "IP
  351.  
  352.  
  353.  
  354. Woundy, et al.            Expiration: May 1997                  [Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360. Internet-Draft                    ARIS                     November 1996
  361.  
  362.  
  363.    Multicast Interaction" for IP multicast protocol details.
  364.  
  365.    Other egress identifier types may be defined, including but not
  366.    limited to IS-IS NSAP addresses, NLSP IPX addresses, IPv6 destination
  367.    prefixes, etc.
  368.  
  369.    A hierarchy amongst the egress identifiers may be introduced to allow
  370.    more flexible control over egress identifier selection.  This allows
  371.    an ISR to autolearn or be configured with non-default egress
  372.    identifiers, and to select which egress identifiers to use in various
  373.    routing situations.
  374.  
  375.    It should be noted that a network achieves a further performance
  376.    optimization with ARIS when egress identifiers refer to the next hop
  377.    router of the egress ISR.  This allows datagrams to be switched
  378.    entirely from the ingress point in the routing domain to the router
  379.    past the egress ISR.
  380.  
  381.  
  382. 7. Egress ISRs
  383.  
  384.    In the ARIS protocol, Establishment messages are originated from the
  385.    egress ISR.  An ISR is considered an egress ISR, with respect to a
  386.    particular egress identifier, under any of the following conditions:
  387.  
  388.         1.   The egress identifier refers to the ISR itself (including
  389.              one of its directly attached interfaces).
  390.  
  391.         2.   The egress identifier is reachable via a next hop router
  392.              that is outside the ISR switching infrastructure.
  393.  
  394.         3.   The egress identifier is reachable by crossing a routing
  395.              domain boundary, such as another area for OSPF summary
  396.              networks, or another autonomous system for OSPF AS
  397.              externals and BGP routes.
  398.  
  399.  
  400. 8. Establishment Initiation Example
  401.  
  402.  
  403.                  +---+
  404.             .... | 2 |
  405.                  +---+ ---> +---+      +--------+
  406.                             | 1 | ---> | Egress | --> ...
  407.                  +---+ ---> +---+      +--------+
  408.             .... | 3 |
  409.                  +---+
  410.               Example: Egress initiates Establishment
  411.  
  412.  
  413.  
  414. Woundy, et al.            Expiration: May 1997                  [Page 7]
  415.  
  416.  
  417.  
  418.  
  419.  
  420. Internet-Draft                    ARIS                     November 1996
  421.  
  422.  
  423.    a)   The Egress ISR learns of an egress identifier that indicates the
  424.         egress is itself (see "Egress ISRs").  It creates a FIB entry
  425.         for its next hop and egress identifier (itself).
  426.  
  427.    b)   The Egress creates a VCIB entry with an upstream VC to ISR1, and
  428.         initiates a VC Establishment message with the upstream VC label
  429.         to use, and itself in the ISR ID path.
  430.  
  431.    c)   ISR1 verifies that the Establish message was received from the
  432.         expected next hop (Egress) by matching its FIB entry, and that
  433.         the ISR ID path is loop free.  It then creates a VCIB entry and
  434.         a downstream VC to the Egress with the given VC label, replaces
  435.         the default VC in the FIB with this new value, and replies to
  436.         the Egress with an Acknowledgment message.
  437.  
  438.    d)   ISR1 creates an upstream VC to each of its upstream neighbors,
  439.         ISR2 and ISR3, and updates the corresponding VCIB entry.  It
  440.         forwards the Establishment message to each upstream neighbor,
  441.         with its own ISR ID appended to the ISR ID path and with the VC
  442.         label to use.
  443.  
  444.    e)   When ISR1 receives each acknowledgment from each upstream
  445.         neighbor, it updates the VCIB and splices the corresponding
  446.         upstream VC to its Egress downstream VC.
  447.  
  448.    All upstream nodes recursively follow the same procedures as ISR1,
  449.    until all Ingress nodes have been added to the VC path to the Egress.
  450.  
  451.    The Egress ISR is responsible for periodically sending refresh VC
  452.    Establishment messages, to prevent VC timeouts.  If a refresh is not
  453.    received in the allotted time, VCs are unspliced and discarded.
  454.  
  455.  
  456. 9. Establishment Trigger Example
  457.  
  458.  
  459.                                    +---+
  460.                              +-X-> | 2 | ---> ........
  461.                              |     +---+             .
  462.                 +---+      +---+                      --> +--------+
  463.            .... | 4 | ---> | 1 |                          | Egress |
  464.                 +---+      +---+                      --> +--------+
  465.                              |     +---+             .
  466.                              +---> | 3 | ---> ........
  467.                                    +---+
  468.               Example: ISR1 changes routes from ISR2 to ISR3
  469.  
  470.  
  471.  
  472.  
  473.  
  474. Woundy, et al.            Expiration: May 1997                  [Page 8]
  475.  
  476.  
  477.  
  478.  
  479.  
  480. Internet-Draft                    ARIS                     November 1996
  481.  
  482.  
  483.    a)   ISR1 learns of a new path to the Egress via ISR3 from the
  484.         routing protocols. It removes the FIB and VCIB entries for the
  485.         next hop ISR2/Egress.  ISR1 creates a new FIB entry for the next
  486.         hop ISR3/Egress with a default VC to the next hop.
  487.  
  488.    b)   ISR1 sends a Trigger message to new downstream node ISR3
  489.         requesting an Establish message for the VC path to the Egress.
  490.  
  491.    c)   ISR3 creates an upstream VC, updates its corresponding VCIB
  492.         entry, and replies with an Establish message to ISR1, containing
  493.         the full ISR ID path and the VC label.
  494.  
  495.    d)   ISR1 verifies that the Establish message was received from the
  496.         expected next hop (ISR3), and that the ISR ID path is loop free.
  497.         It then creates a new VCIB entry and downstream VC to ISR3 with
  498.         the given VC label, and replaces the default VC in the FIB with
  499.         this new value.
  500.  
  501.    e)   ISR1 sends an Acknowledgment message to ISR3.
  502.  
  503.    f)   ISR3 receives the Acknowledgment, updates the VCIB and splices
  504.         its ISR1 upstream VC to its downstream VC.
  505.  
  506.    g)   ISR1 appends its ISR ID to the Establish message, and forwards
  507.         the message to ISR4 with the upstream VC label.
  508.  
  509.    h)   ISR4 verifies the Establish message, updates the VCIB, and
  510.         unsplices the current VC to ISR1/Egress from its upstream
  511.         node(s), and sends an Acknowledgment to ISR1.
  512.  
  513.    i)   ISR1 receives the Acknowledgment, updates the VCIB and splices
  514.         the ISR4 upstream VC to the ISR3 downstream VC.
  515.  
  516.    j)   ISR4 appends its ISR ID to the path, and forwards the
  517.         establishment message to its upstream neighbors with a VC label.
  518.         When ISR4 receives an Acknowledgment from an upstream neighbor,
  519.         it updates the VCIB and splices the upstream VC to the ISR1
  520.         downstream VC.
  521.  
  522.    All upstream nodes recursively follow the same procedure as ISR4,
  523.    until all ingress nodes have been updated.
  524.  
  525.  
  526. 10. TTL Decrement
  527.  
  528.    In order to comply with the requirements for IPv4 routers, the IP
  529.    datagram Time-To-Live (TTL) field must be decremented on each hop it
  530.    traverses [9].  Currently, switched packets within ATM cannot
  531.  
  532.  
  533.  
  534. Woundy, et al.            Expiration: May 1997                  [Page 9]
  535.  
  536.  
  537.  
  538.  
  539.  
  540. Internet-Draft                    ARIS                     November 1996
  541.  
  542.  
  543.    decrement the TTL.  However, ARIS can decrement TTLs appropriately by
  544.    maintaining a hop-count per egress identifier.  This hop-count is
  545.    calculated by including a hop-count field in the Establish message,
  546.    which is incremented at each ISR as it traverses the upstream path.
  547.    Before forwarding a packet on a VC, an ingress ISR decrements the TTL
  548.    by the hop-count plus one.  If the decrement value is greater than or
  549.    equal to the TTL of the packet, the packet is forwarded hop-by-hop.
  550.  
  551.  
  552. 11. Multipath Considerations
  553.  
  554.    Many IP routing protocols such as OSPF support the notion of equal-
  555.    cost multipath routes, in which a router maintains multiple next hops
  556.    for one destination prefix when two or more equal-cost paths to the
  557.    prefix exist.  Unfortunately, because of limitations in most ATM
  558.    switching hardware, each path needs its own VC.  Therefore, ingress
  559.    ISRs may maintain a number of VCs to one egress ISR, each VC
  560.    representing a different equal-cost path to the egress.  In this
  561.    case, the ingress ISR will make multipath decisions for traffic on
  562.    behalf of all downstream ISRs.
  563.  
  564.    Each ISR that receives multiple (legal) Establishment messages from
  565.    downstream ISRs with different paths to the same egress identifier
  566.    can choose one of four different approaches for sending Establishment
  567.    messages upstream.  One approach is to send multiple Establishment
  568.    messages upstream, preserving multiple VCs to the egress ISR.  Each
  569.    Establishment message requires an additional numeric identifier to be
  570.    able to distinguish multiple distinct VCs to the destination, so that
  571.    successive Establishment messages for distinct VCs are not
  572.    misinterpreted as consecutive replacements of the same VC.  When
  573.    multiple Establishment VCs are preserved upstream, they require
  574.    distinct VPI/VCI assignments, which works against conservation of
  575.    VCs.
  576.  
  577.    Another approach, that conserves VCs at the cost of switching
  578.    performance, is to originate one Establishment message upstream, and
  579.    to forward datagrams at the IP network layer on the multipath point
  580.    ISR.
  581.  
  582.    A third approach is to propagate only one Establishment message from
  583.    the downstream ISRs to the upstream ISRs, and ignore the content of
  584.    other VC Establishment messages.  This conserves VCs and maintains
  585.    switching performance, but may not balance loads across downstream
  586.    links as well as the first two approaches, even if VCs are
  587.    selectively dropped.
  588.  
  589.    The final approach is to propagate one Establishment message that
  590.    carries the content of all downstream Establishment messages, so that
  591.  
  592.  
  593.  
  594. Woundy, et al.            Expiration: May 1997                 [Page 10]
  595.  
  596.  
  597.  
  598.  
  599.  
  600. Internet-Draft                    ARIS                     November 1996
  601.  
  602.  
  603.    only one upstream VC is created to the multipath point.  This
  604.    requires that the ATM switching hardware on the multipath ISR be
  605.    capable of correctly distributing the traffic of upstream VCs onto
  606.    multiple downstream VCs.  Furthermore, the Establishment message to
  607.    send upstream must concatenate the ISR ID lists from downstream
  608.    messages, in order to preserve the VC loop-free property.  The ISR ID
  609.    list concatenation is similar to using AS_SETs for aggregation in the
  610.    BGP protocol.  This final approach has the benefit of both VC
  611.    conservation and performance, although it requires a slightly more
  612.    complex implementation.
  613.  
  614.  
  615. 12. BGP Interactions with ARIS
  616.  
  617.    The BGP implementation of the ISR uses the NEXT_HOP attribute as the
  618.    egress identifier.  When the BGP border ISR injects routes into the
  619.    BGP mesh, it may use its own IP address or the address of its
  620.    external BGP peer as the value of the NEXT_HOP attribute.  This
  621.    choice of NEXT_HOP attribute value creates different Establishment
  622.    behaviors with ARIS.
  623.  
  624.    If the BGP border ISR uses its own IP address as the NEXT_HOP
  625.    attribute in its injected routes, then all of these BGP routes share
  626.    the same egress identifier.  This approach establishes only one tree
  627.    to the BGP border ISR, and the ISR must forward traffic at the IP
  628.    layer towards its external BGP neighbors.
  629.  
  630.    If the BGP border ISR uses the external BGP peer as the NEXT_HOP
  631.    attribute in its injected routes, then the BGP routes from each
  632.    unique external BGP neighbor share the same egress identifier.  This
  633.    approach establishes one VC tree per external BGP neighbor of the BGP
  634.    border ISR.  The BGP border ISR can switch traffic directly to its
  635.    external BGP neighbors.
  636.  
  637.  
  638. 13. OSPF Interactions with ARIS
  639.  
  640.    The OSPF protocol exchanges five types of "link state advertisements"
  641.    to create OSPF routing tables.  All types of advertisements contain
  642.    an "Advertising Router" field, which identifies the OSPF Router ID of
  643.    the router that originates the advertisement.  The ISR uses this OSPF
  644.    Router ID as the egress identifier.
  645.  
  646.    The use of the OSPF Router ID as an egress identifier allows a new
  647.    level of destination prefix abstraction.  In a typical network, a
  648.    router may be connected to several LANs (Ethernets, Token Rings,
  649.    etc.), and may communicate to remote networks outside of its routing
  650.    domain via adjacent routers.  The remote destination networks may be
  651.  
  652.  
  653.  
  654. Woundy, et al.            Expiration: May 1997                 [Page 11]
  655.  
  656.  
  657.  
  658.  
  659.  
  660. Internet-Draft                    ARIS                     November 1996
  661.  
  662.  
  663.    injected into the link state routing domain via static configuration,
  664.    or via other routing protocols (such as RIP or BGP).  These local and
  665.    remote networks may be represented in the router forwarding tables as
  666.    many destination prefixes, which cannot be aggregated into shorter
  667.    prefixes (even when using CIDR [10]).  Router labels (OSPF Router ID)
  668.    provide a compact means to represent a number of destination prefixes
  669.    that exit the link state routing domain at the same egress router.
  670.    The association between destination prefixes and router labels is an
  671.    easy by-product of the normal SPF computation.
  672.  
  673.    The one exception to using the OSPF Router ID is when ISRs receive an
  674.    AS external link advertisement with a non-zero forwarding address.
  675.    The OSPF protocol uses the forwarding address to allow traffic to
  676.    bypass the router that originates the advertisement.  Since the OSPF
  677.    Router ID refers to the bypassed router, it is inadequate as an
  678.    egress identifier in this case.  Instead, the ARIS protocol must use
  679.    the forwarding address as the egress identifier.
  680.  
  681.    Using the forwarding address as the egress identifier provides
  682.    significant benefits.  Since the AS external forwarding address and
  683.    the BGP NEXT_HOP attribute are both external IP addresses, they are
  684.    compatible types of egress identifiers, which may allow BGP and OSPF
  685.    routes to share the same VC.  Further, the OSPF AS boundary ISR can
  686.    switch traffic directly to its external neighbors, just like BGP.
  687.  
  688.    The ISR identifies itself as an OSPF egress when the ISR is an area
  689.    border router or an AS boundary router, or when it is directly
  690.    attached to a LAN.
  691.  
  692.  
  693. 14. IP Multicast Interactions with ARIS
  694.  
  695.    The ARIS protocol can be used to setup VCs for IP multicast traffic,
  696.    in particular for multicast protocols using Reverse Path Multicasting
  697.    (RPM).  The typical RPM forwarding information base maps a source IP
  698.    network address and multicast group pair, (S,G), to an expected
  699.    incoming interface and a set of outgoing interfaces.  The ISR extends
  700.    the forwarding information base to include one egress identifier per
  701.    (S,G).
  702.  
  703.    The current choice of egress identifier is the (S,G) pair itself.
  704.    This egress identifier creates one source-based VC tree per source
  705.    address and group pair.  The VC tree carries traffic from the ingress
  706.    ISR to all egress ISRs, using multicast switching within intermediate
  707.    ISRs.  Egress ISRs for multicast are similar to egress ISRs for the
  708.    unicast case, except that multicast egress ISRs are determined by
  709.    group membership location, instead of egress point reachability.  An
  710.    ISR becomes an egress for a particular (S,G) when it forwards traffic
  711.  
  712.  
  713.  
  714. Woundy, et al.            Expiration: May 1997                 [Page 12]
  715.  
  716.  
  717.  
  718.  
  719.  
  720. Internet-Draft                    ARIS                     November 1996
  721.  
  722.  
  723.    from a source S to a group G over a non-ISR link.
  724.  
  725.    Having multicast VCs set up on the basis of (S,G) works well with the
  726.    IGMPv3 Group-Source messages, since these IGMP messages can create
  727.    unique trees for each sender within the same group [11].
  728.  
  729.    An alternative egress identifier choice is to use the "ingress" of
  730.    the source address S in the (S,G) pair.  This choice creates one
  731.    ingress-based VC tree for all of the sources of a group that share a
  732.    given ingress, instead of one for each of the sources.  This permits
  733.    a greater amount of VC aggregation in the ISR cloud.  The ingress of
  734.    a source address is calculated in a similar fashion to calculating an
  735.    egress identifier for a destination prefix. Unfortunately, one cannot
  736.    calculate useful ingress identifiers for DVMRP, for the same reason
  737.    that one cannot calculate useful egress identifiers for RIP.
  738.    Furthermore, since some protocols permit source-specific multicast
  739.    pruning, the multicast distribution tree for a particular group may
  740.    differ according to source address, even if sources share the same
  741.    ingress point.  However, the advantages this approach offers with
  742.    regards to VC conservation on those protocols capable of supporting
  743.    the ingress of source may outweigh the disadvantages of wasting
  744.    bandwidth by sending traffic to leaf networks where a particular
  745.    source may be filtered.
  746.  
  747.    Based on the topology of the multicast distribution tree, there may
  748.    be multiple egress ISRs for the egress identifier (S,G).  Each ISR
  749.    can send one multicast Establishment message to the one upstream ISR
  750.    on the path back toward the source address.  The ISR ID lists of
  751.    multicast downstream ISRs, with the current ISR ID, are concatenated
  752.    (like BGP AS_SETs) before sending the Establishment message to the
  753.    upstream ISR.
  754.  
  755.    The observant reader may note that ARIS uses a multicast scheme to
  756.    build unicast VCs, and a unicast scheme to build multicast VCs.
  757.  
  758.  
  759. 15. Virtual Path Extension
  760.  
  761.    The ARIS usage of "merged" VC flows requires that ATM switching
  762.    hardware have the capabilty of preventing cell interleaving (see "VC
  763.    Conservation"). Unfortunately, much of the existing ATM switching
  764.    hardware cannot support VC merging.  One solution to this problem is
  765.    to use virtual paths (VPs) to egress points, rather than virtual
  766.    circuits (VCs).  The virtual path extension merges VPs, creating
  767.    trees of VPs to the egress points, instead of merging VCs.  Cell
  768.    interleaving is prevented by the assignment of unique VC identifiers
  769.    (VCIs) within each VP.
  770.  
  771.  
  772.  
  773.  
  774. Woundy, et al.            Expiration: May 1997                 [Page 13]
  775.  
  776.  
  777.  
  778.  
  779.  
  780. Internet-Draft                    ARIS                     November 1996
  781.  
  782.  
  783.    The ISRs within a network are assigned unique VCIs to prevent VCI
  784.    collisions when paths from different ISRs are merged.  Each ISR
  785.    requires a block of VCIs as labels to distinguish between cell paths
  786.    to the same egress identifier.  By assigning a unique block of VCIs
  787.    to each ISR, ARIS guarantees that an ISR at a network merge point can
  788.    safely merge upstream VP flows for an egress identifier to a single
  789.    downstream VP without VCI collisions.
  790.  
  791.    Although the virtual path extension uses VCs much less efficiently
  792.    than a VC merging implementation, it reduces network latency and
  793.    hardware requirements because frame reassembly and re-segmentation is
  794.    not required on intermediate ISRs.  In addition, although this
  795.    variation uses more VC space, the work involved in establishing and
  796.    maintaining switched paths is still O(n).
  797.  
  798.    An alternative approach to the VC merging problem is to use an end-
  799.    to-end VC label upstream allocation.  This allows the ingress node to
  800.    choose the downstream VC.  In this approach, ISRs acknowledge the
  801.    Establishment message with a label only after they receive an
  802.    Acknowledgment message from their own upstream neighbor. Thus, the
  803.    Establishment message traverses fully to the ingress node before
  804.    being acknowledged.  Ingress ISRs immediately acknowledge the
  805.    Establishment message with the VC label.  These acknowledgements may
  806.    be merged as they travel downstream to the egress node.  This method
  807.    adds latency in the VC set up, and removes the benefits of ARIS VC
  808.    aggregation (O(n**2) versus O(n) VCs).  However, it adds the
  809.    flexibility of performing VC-switching instead of VP-switching, which
  810.    also makes switching possible at the routing boundaries.
  811.  
  812.  
  813. 16. Multiprotocol Support
  814.  
  815.    ARIS is capable of multi-protocol support.  Further, the egress
  816.    aggregation feature of ARIS is applicable to those network layer
  817.    topologies (IP, CLNP, IPX) that use a link state routing protocol.
  818.    In particular, integrated IS-IS can calculate routes for CLNP, IP4,
  819.    and IP6 simultaneously (with one Dijkstra calculation), and OSPFv3
  820.    (the new draft of OSPF) can calculate routes for IP4 and IP6
  821.    simultaneously.  Both integrated IS-IS and OSPFv3 use a single router
  822.    label to represent a single router that supports multiple network
  823.    layer protocols.  In this context, ARIS can minimize switching paths
  824.    by using a single switching path for traffic from multiple network
  825.    protocols destined to the same egress multiprotocol router.
  826.  
  827.  
  828. 17. ARIS And Frame Switching Technology
  829.  
  830.    The ARIS protocol is easily extendible to other switching
  831.  
  832.  
  833.  
  834. Woundy, et al.            Expiration: May 1997                 [Page 14]
  835.  
  836.  
  837.  
  838.  
  839.  
  840. Internet-Draft                    ARIS                     November 1996
  841.  
  842.  
  843.    environments.  Though the present document illustrates ARIS in ATM
  844.    cell switching technology, it may later be extended to other
  845.    switching technologies. In fact, ARIS applies well to frame switching
  846.    technology.
  847.  
  848.    While ARIS solves the problem of cell interleaving in the case of ATM
  849.    by Virtual Path switching, it naturally and easily maps to a frame
  850.    switching environment.  This is due to the fact that multiple
  851.    upstream flows can be merged into a single downstream flow without
  852.    the problems of cell interleaving.
  853.  
  854.  
  855. 18. Quality of Service
  856.  
  857.    ARIS can be extended to support Quality of Service (QoS) parameters.
  858.    This will be addressed in a future ARIS revision.
  859.  
  860.  
  861. 19. ARIS Advantages
  862.  
  863.    The ARIS approach to IP switching offers the following advantages:
  864.  
  865.    o    VC aggregation
  866.           - Use of egress identifiers allows many route (CIDR) prefixes
  867.             to map to the same VC
  868.           - Ability to create O(n) ARIS VCs (not O(n**2)) on full mesh,
  869.             where n is the number of nodes in a network.
  870.  
  871.    o    Low VC setup overhead
  872.           - Few VCs to setup due to routing-based and aggregated VCs
  873.           - VC teardown/setup only on internal route changes
  874.  
  875.    o    Switches large proportion of traffic
  876.           - All traffic assigned to VCs
  877.           - VCs created independent of traffic patterns
  878.  
  879.    o    Guaranteed loop-free VC paths
  880.  
  881.    o    Preserves VC's for RSVP flows or standard ATM connections
  882.  
  883.    o    Scales to large networks
  884.  
  885.  
  886. 20. Security Consideration
  887.  
  888.    Security considerations are not addressed in this memo.
  889.  
  890.  
  891.  
  892.  
  893.  
  894. Woundy, et al.            Expiration: May 1997                 [Page 15]
  895.  
  896.  
  897.  
  898.  
  899.  
  900. Internet-Draft                    ARIS                     November 1996
  901.  
  902.  
  903. 21. Intellectual Property Considerations
  904.  
  905.    International Business Machines Corporation may seek patent or other
  906.    intellectual property protection for some or all of the aspects
  907.    discussed in the forgoing document.
  908.  
  909.  
  910. 22. Acknowledgements
  911.  
  912.    The authors wish to acknowledge the following people for their input
  913.    and support: Ed Bowen, Jerry Marin, Wayne Pace, Dean Skidmore, and
  914.    Vijay Srinivasan.
  915.  
  916.  
  917. 23. References
  918.  
  919.    [1]  Juha Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
  920.         Layer 5", RFC 1483, Telecom Finland, July 1993
  921.  
  922.    [2]  Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
  923.         1771, IBM Corp, Cisco Systems, March 1995
  924.  
  925.    [3]  J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March 1994
  926.  
  927.    [4]  S. Deering, "Host extensions for IP multicasting", RFC 1112,
  928.         Stanford University, August 1989
  929.  
  930.    [5]  D. Waitzman, C. Partridge, S. Deering, "Distance Vector
  931.         Multicast Routing Protocol", RFC 1075, BBN, Stanford University,
  932.         November 1988
  933.  
  934.    [6]  J. Moy, "Multicast Extensions to OSPF", RFC 1584, Proteon Inc,
  935.         March 1994
  936.  
  937.    [7]  S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L.
  938.         Wei, P. Sharma, A. Helmy, "Protocol Independent Multicast-Sparse
  939.         Mode (PIM-SM):  Protocol Specification", Internet Draft <draft-
  940.         ietf-idmr-pim-spec-02.txt>, Xerox, Cisco Systems, USC, LBL,
  941.         September 1995
  942.  
  943.    [8]  D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma,
  944.         A. Helmy, "Protocol Independent Multicast-Dense Mode (PIM-DM):
  945.         Protocol Specification", Internet Draft <draft-ietf-idmr-pim-
  946.         dm-spec-01.txt>, USC, Cisco Systems, LBL, January 1996
  947.  
  948.    [9]  F. Baker (Editor), "Requirements for IP Version 4 Routers", RFC
  949.         1812, Cisco Systems, June 1995
  950.  
  951.  
  952.  
  953.  
  954. Woundy, et al.            Expiration: May 1997                 [Page 16]
  955.  
  956.  
  957.  
  958.  
  959.  
  960. Internet-Draft                    ARIS                     November 1996
  961.  
  962.  
  963.    [10] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
  964.         Routing (CIDR):  an Address Assignment and Aggregation
  965.         Strategy", RFC 1519, BARRNET, Cisco Systems, MERIT, OARnet,
  966.         September, 1993
  967.  
  968.    [11] B. Cain, S. Deering, A. Thyagarajan, "Internet Group Management
  969.         Protocol Version 3", Internet Draft <draft-cain-igmp-00.txt>,
  970.         University of Delaware, Xerox PARC, August 1995
  971.  
  972.  
  973. 24. Authors' Addresses
  974.  
  975.    Rick Boivie
  976.    IBM Corp.
  977.    17 Skyline Drive
  978.    Hawthorne, NY 10532
  979.    Phone: +1 914-784-3251
  980.    Email: rboivie@vnet.ibm.com
  981.  
  982.  
  983.    Nancy Feldman
  984.    IBM Corp.
  985.    17 Skyline Drive
  986.    Hawthorne, NY 10532
  987.    Phone: +1 914-784-3254
  988.    Email: nkf@vnet.ibm.com
  989.  
  990.  
  991.    Arun Viswanathan
  992.    IBM Corp.
  993.    17 Skyline Drive
  994.    Hawthorne, NY 10532
  995.    Phone: +1 914-784-3273
  996.    Email: arunv@vnet.ibm.com
  997.  
  998.  
  999.    Richard Woundy
  1000.    Continental Cablevision
  1001.    The Pilot House - Lewis Wharf
  1002.    Boston, MA 02110
  1003.    Phone: +1 617-854-3351
  1004.    Email: rwoundy@continental.com
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014. Woundy, et al.            Expiration: May 1997                 [Page 17]
  1015.  
  1016.  
  1017.