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

Versions: 00

Internet-Draft                                             Nancy Feldman
Expiration Date: September 1997                         Arun Viswanathan
                                                               IBM Corp.

                                                              March 1997






                           ARIS Specification

                    <draft-feldman-aris-spec-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

   ARIS (Aggregate Route-Based IP Switching) adds the advantages of
   high-speed switching to a network based on routing protocols.  It
   provides a means of mapping network-layer routing information to
   link-layer switched paths, enabling datagrams to traverse a network
   at media speeds.  This memo defines the ARIS protocol and its
   mechanisms.







Feldman, et al.        Expiration: September 1997               [Page 1]


Internet-Draft             ARIS Specification                 March 1997


   Table of Contents


       1       Introduction ........................................ 4
       2       ARIS Messaging ...................................... 4
       2.1     ARIS Objects ........................................ 5
       2.2     Init ................................................ 6
       2.3     Establish ........................................... 6
       2.3.1   Destination-Based Routing ........................... 6
       2.3.2   Explicit Routes ..................................... 9
       2.4     Trigger ............................................. 10
       2.5     Teardown ............................................ 11
       2.6     Acknowledge ......................................... 11
       2.7     KeepAlive ........................................... 12
       3       Neighbor Adjacency .................................. 13
       3.1     State Transition .................................... 13
       4       Egress Identifiers .................................. 15
       4.1     Egress ISR .......................................... 15
       4.2     Selecting Egress Identifiers ........................ 15
       5       Destination-Based Routing ........................... 17
       5.1     Forwarding Information Bases ........................ 17
       5.2     TTL Decrement ....................................... 18
       5.3     Loop Prevention ..................................... 18
       5.4     BGP Interaction with ARIS ........................... 19
       5.5     OSPF Interaction with ARIS .......................... 19
       6       L2-Tunnels .......................................... 20
       7       Label Management .................................... 21
       7.1     VCIB ................................................ 21
       7.2     Label Swapping ...................................... 21
       8       Multicast ........................................... 21
       8.1     DVMRP and PIM-DM .................................... 22
       8.2     PIM-SM .............................................. 22
       9       Multipath ........................................... 23
       10      Timers .............................................. 24
       11      Configuration ....................................... 25
       12      ARIS Signaling Pseudo Code .......................... 26
       13      Object Definitions .................................. 30
       13.1    Common Header ....................................... 30
       13.2    Common Object Header ................................ 31
       13.3    Label Object ........................................ 32
       13.4    Egress Identifier Object ............................ 32
       13.5    Multipath Identifier Object ......................... 36
       13.6    Router Path Object .................................. 36
       13.7    Explicit Path Object ................................ 37
       13.8    Tunnel Object ....................................... 38
       13.9    Timer Object ........................................ 39
       13.10   Acknowledge Message Object .......................... 40
       13.11   Init Message Object ................................. 40



Feldman, et al.        Expiration: September 1997               [Page 2]


Internet-Draft             ARIS Specification                 March 1997


       14      Error Codes ......................................... 41
       15      Security Consideration .............................. 41
       16      Intellectual Property Considerations ................ 42
       17      Acknowledgements .................................... 42
       18      References .......................................... 42
       19      Authors' Addresses .................................. 43













































Feldman, et al.        Expiration: September 1997               [Page 3]


Internet-Draft             ARIS Specification                 March 1997


1. Introduction

   An Integrated Switch Router (ISR) is a switch that has been augmented
   with standard IP routing support.  The ARIS protocol establishes
   switched paths through a network of ISRs by mapping network-layer
   routing information directly to data-link layer switched paths.
   These switched paths may have an endpoint at a directly attached
   neighbor (comparable to IP hop-by-hop forwarding), or may have an
   endpoint at a network egress node, enabling switching via all
   intermediary nodes.

   A switched path is created for an "egress identifier", which
   identifies a routed path through a network. The egress identifiers
   may be extracted from information existing in the routing protocols,
   or may be configured. Routes that are populated in a router's
   forwarding table are extended to include a reference to an egress
   identifier with a corresponding switched path.  ARIS supports
   switched path granularity ranging from end-to-end flows to the
   aggregation of all traffic through a common egress node.  The choice
   of granularity is determined by the choice of the egress identifier.
   Since multiple routes may map to the same egress identifier, the
   number of switched paths needed in a network is minimized.  Switched
   paths for different levels of aggregation may exist simultaneously.

   ARIS can support IP or other network protocols. This version of the
   draft is defined with respect to IPv4, and will be extended to
   support other protocols in future revisions.

   It is assumed the reader is familiar with the ARIS architecture, as
   defined in the ARIS Overview Internet Draft [aris].


2. ARIS Messaging

   ARIS messages are used to communicate with directly attached ARIS
   neighbors.  Their purpose is to manage the switched paths in an ARIS
   network.

   ARIS messages are transmitted single hop to adjacent neighbors
   directly over IP, with IP protocol number 104.  The following ARIS
   messages are defined:

   INIT        - This message establishes neighbor adjacencies
   KEEPALIVE   - This message maintains neighbor adjacencies
   ESTABLISH   - This message creates switched path(s)
   TRIGGER     - This message requests an Establish message
   TEARDOWN    - This message deletes established switched path(s)
   ACKNOWLEDGE - This message positively or negatively acknowledges a



Feldman, et al.        Expiration: September 1997               [Page 4]


Internet-Draft             ARIS Specification                 March 1997


                 received ARIS message


2.1. ARIS Objects

   All ARIS messages begin with a common header, and may be followed by
   one or more ARIS objects.  See section 13 for a definition of the
   common header and objects.

   ARIS Common Header:
        The common header authenticates an ARIS message.

   Egress Identifier Object (EGRID_OBJ):
        A representation of one or more routes that traverse a common
        switched path through a network.  ARIS creates a switched path
        for each egress identifier.

   Label Object (LABEL_OBJ):
        The unique label assigned to a switched path on a link.

   Multipath Object (MPATH_OBJ):
        A numeric identifier used to distinguish multiple switched paths
        to the same egress identifier.  It is of local significance per
        link.

   Router Path Object (RPATH_OBJ):
        The list of ISRs through which the message has traversed, where
        each ISR is identified via a unique router-id.  This object's
        purpose is to detect routing loops, where a loop is detected
        when an ISR finds its own router-id in the received message
        router-id list.

   Explicit Path Object (EPATH_OBJ):
        The source routed path the Establish message must follow.

   Tunnel Object (TUNNEL_OBJ):
        A label used for an encapsulated tunnel.  This enables a de-
        aggregating ISR to avoid L3 forwarding, by removing an incoming
        L2 header and switching on an encapsulated label.

   Timer Object (TIMER_OBJ):
        A value used for timeouts.  In the Init message, this is the
        neighbor adjacency timeout.  In the Establish message, this is
        the Establish refresh timeout.

   Acknowledge Object (ACK_OBJ):
        An indication of the success or failure of an ARIS message.




Feldman, et al.        Expiration: September 1997               [Page 5]


Internet-Draft             ARIS Specification                 March 1997


   Init Object (INIT_OBJ):
        Information that must be communicated to adjacent ARIS neighbors
        on initialization.



2.2. Init

   This is the first message exchanged by ARIS neighbors to establish
   adjacency.

   The format of an Init Message is:
        <Init Message> ::= <Common Header>
                           <INIT_OBJ>
                           <TIMER_OBJ>

   The INIT message MUST be periodically transmitted over each ARIS link
   until a successful INIT message exchange, at which time the neighbor
   state is transitioned to ACTIVE.  All other ARIS messages may only be
   transmitted after the ACTIVE state is achieved.  The INIT message
   contains such information as the neighbor timeout period, and the
   ISR's supported label ranges.

   The neighbor adjacency sequence is addressed in section 3.


2.3. Establish

   Neighbors that are in the ACTIVE state may exchange Establish mes-
   sages.


2.3.1. Destination-Based Routing

   The format of the Establish Message is:
        <Establish Message> ::=  <Common Header>
                               { <EGRID_OBJ>
                                [<TIMER_OBJ>]
                                [<RPATH_OBJ>]
                                 <LABEL_OBJ>
                                 <MPATH_OBJ>
                                [<TUNNEL_OBJ>] } ...

   The "destination-based" Establish message builds switched paths for
   egress identifiers which follow the forwarding paths created by the
   network layer routing protocols.  The switched paths form a
   multipoint-to-point tree, where the egress ISR is the root and the
   ingress ISRs are the leaves.



Feldman, et al.        Expiration: September 1997               [Page 6]


Internet-Draft             ARIS Specification                 March 1997


   The Establish message is initiated by the egress ISR (see section 4.1
   for egress definition), and is periodically sent to each upstream
   neighbor to setup or refresh a switched path.  These upstream neigh-
   bors forward the messages to their own upstream neighbors in Reverse
   Path Multicast (RPM) style, continuing this pattern until each ISR
   with a routed path to the given egress identifier establishes a
   switched path.

   An Establish message is also sent by any ISR in response to a Trigger
   message.  In this case, the Establish message is only forwarded to
   the triggering ISR.

   An egress ISR initiating an Establish message for an egress identif-
   ier allocates a label for each upstream ACTIVE ARIS neighbor, where
   the downstream neighbor is determined by the forwarding table (FIB).
   The egress ISR creates and forwards an Establish message to each
   upstream neighbor.

   The Establish message contains:

        o    a hop-count set to 0 if the Egress is the switched path
             endpoint, else the hop-count set to 1

        o    the router-id list set to the Egress ISR's router-id if
             loop prevention is configured

        o    the allocated upstream label


   Each ISR that receives an Establish message for an egress identifier
   verifies that the message was received from the correct next-hop for
   the given egress identifier, as indicated by the forwarding table
   (FIB), and if loop prevention is configured, verifies that the path
   taken is loop free by examining the ISR list.  A message that con-
   tains a loop or is received from a non-downstream neighbor is dropped
   and a negative acknowledge MUST be transmitted to the sender of the
   invalid message.

   On receipt of a valid Establish message, the ISR uses the multipath
   identifier to determine if the switched path for each given egress
   identifier is new or is an update to a previously established
   switched path.

   An ISR receiving a new valid Establish message populates the FIB with
   the given downstream label and replies to the sender with a positive
   Acknowledge message.  The ISR then allocates a label for each of its
   ARIS upstream neighbors (where the downstream neighbor is the ISR
   from which the Establish was received).  The ISR splices the given



Feldman, et al.        Expiration: September 1997               [Page 7]


Internet-Draft             ARIS Specification                 March 1997


   downstream with the newly allocated upstream label(s), unless loop
   prevention is configured; when loop prevention is configured, the
   paths MUST NOT be spliced until a positive Acknowledge is received.
   The ISR then forwards the Establish message RPM style.

   An ISR forwards the Establish message to the upstream neighbors with:

        o    incremented hop-count

        o    the ISR's router id appended to the ISR list if loop
             prevention is configured

        o    the allocated upstream label


   An ISR receiving a valid Establish message for a previously esta-
   blished switched path determines if the path has been modified by
   examining the label and the ISR list (if loop prevention configured).
   If these are unchanged the message is considered a refresh, else the
   message is an update.

   An ISR receiving a refresh Establish message MUST acknowledge the
   message and forward the Establish RPM style, with the local router id
   appended to the ISR list (if loop prevention configured) and the pre-
   viously allocated upstream label.

   An ISR receiving an update Establish with a new downstream label MUST
   unsplice the obsolete downstream switched path, and populate the FIB
   with the newly acquired label.  An ISR receiving a new ISR list MUST
   unsplice the downstream switched path if loop prevention is config-
   ured. The ISR then follows the procedures described above for for-
   warding the Establish message upstream.

   An Establish message MAY also use the form of upstream allocation, as
   decided on initialization.  This option, in conjunction with an end-
   to-end acknowledge, may be useful on switches that do not support
   merging.  In this case, the egress ISR initiates an Establish message
   to its upstream neighbors with an end-to-end bit, and a zero label
   value.  Each intermediary ISR that receives such an Establish for-
   wards the message RPM style as describe above, except that no label
   is allocated, and no Acknowledge is immediately returned.  The label
   selection is initiated at each ingress ISR, and transmitted to the
   sender of the Establish via the Acknowledge message.  The intermedi-
   ary ISRs which receive a label via the Acknowledge message splice the
   given label to an allocated downstream label, and forward an Ack-
   nowledge message with the selected downstream label to the ISR from
   which the Establish was received.




Feldman, et al.        Expiration: September 1997               [Page 8]


Internet-Draft             ARIS Specification                 March 1997


   The Establish message must be retransmitted at the Retransmit Timer
   interval (see section 10), until an Acknowledge message is received.
   In the case of an end-to-end acknowledgment, the Establish retransmit
   interval SHOULD be a configured multiple of the Retransmit Timer
   value.

   The egress ISR MUST send a refresh Establish message within the con-
   figured RefreshEstablish interval (see section 10).  The RefreshEs-
   tablish interval is transmitted to the upstream ISRs in the Establish
   Timer object.  An ISR SHOULD timeout an established switched path if
   no refresh is received within the given interval.  If a Timer object
   is not present in the received Establish message, the switched path
   SHOULD NOT timeout.


2.3.2. Explicit Routes

   The format of the Establish Message is:
        <Establish Message> ::=  <Common Header>
                               { <EGRID_OBJ>
                                [<TIMER_OBJ>]
                                 <EPATH_OBJ>
                                 <LABEL_OBJ>
                                 <MPATH_OBJ>
                                [<TUNNEL_OBJ>] } ...

   The explicit-route Establish message builds switched paths for an
   egress identifier that follow an explicitly chosen loop-free path.
   An Establish message is identified as an explicit-route by the pres-
   ence of an Explicit Path object.  Such an Establish is initiated by
   the first ISR in the explicit path, and is periodically sent to the
   path neighbors to setup or refresh a switched path.  Since the expli-
   cit Establish may be initiated by an ingress or egress ISR, the
   Establish indicates the direction of the dataflow.

   The initiator of the explicit-route Establish message for a particu-
   lar egress identifier allocates a label for each given adjacent ARIS
   neighbor in the explicit path.  It then creates an explicit path
   Establish message with an indication of upstream or downstream path
   direction, and forwards the Establish to the explicitly given neigh-
   bors.

   Each ISR that receives an explicit route Establish message for an
   egress replies with an Acknowledge message.  It then allocates labels
   for the listed ARIS neighbors, and splices the given label to the
   newly allocated label.  The message is forwarded to the listed ARIS
   neighbors with an update to the Exlicit Path object indicating the
   current path location.



Feldman, et al.        Expiration: September 1997               [Page 9]


Internet-Draft             ARIS Specification                 March 1997


   Note that the Establish message may contain a zero label rather than
   an allocated label.  This causes the receiving node to do the label
   allocation and respond with the given label in the Acknowledge mes-
   sage.

   The Establish message MUST be retransmitted at the Retransmit Timer
   rate (see section 10), until an Acknowledge message is received.

   The initiating ISR MUST send a refresh Establish message within the
   configured RefreshEstablish interval (see section 10).  The
   RefreshEstablish interval is transmitted to the neighbor ISRs in the
   Establish Timer Object.  An ISR SHOULD timeout an established
   switched path if no refresh is received within the given interval.
   If a Timer Object is not present in the received Establish message,
   the switched path SHOULD NOT timeout.


2.4. Trigger

   Neighbors that are in the ACTIVE state may exchange Trigger messages.

   The format of a Trigger Message is:
        <Trigger Message> ::=   <Common Header>
                              { <EGRID_OBJ> } ...

   A Trigger message is used in destination-based routing, when a local
   routing change has modified the network layer path to an egress iden-
   tifier.  When this occurs, the ISR MUST unsplice the obsolete
   switched path, and transmit a Trigger message to the new downstream
   neighbor, requesting an Establish message.

   An ISR that receives a Trigger message for a particular egress iden-
   tifier identifies the downstream switched path(s) and allocates the
   label(s) to the upstream triggering ISR.  The upstream label is
   spliced to the downstream label, unless loop prevention is config-
   ured; in this case, the paths are NOT spliced until a positive Ack-
   nowledge is received.

   The ISR transmits an Establish to the triggering neighbor with:

        o    incremented hop-count

        o    ISR's router id appended to the ISR list (if loop preven-
             tion configured)

        o    the allocated upstream label





Feldman, et al.        Expiration: September 1997              [Page 10]


Internet-Draft             ARIS Specification                 March 1997


   An ISR that receives a trigger but has no downstream path to the
   egress identifier replies to the triggering ISR with a Nak.

   The Trigger message must be retransmitted at the Retransmit Timer
   rate, until an Establish or a Nak is received.

   Note that the Trigger message is NOT a requirement for switched path
   corrections, as switched paths are consistently refreshed and re-
   established via the refresh Establish message.


2.5. Teardown

   Neighbors that are in the ACTIVE state may exchange Teardown mes-
   sages.

   The format of a Teardown Message is:
        <Tear Message> ::=   <Common Header>
                           { <EGRID_OBJ>
                             <LABEL_OBJ>
                             <MPATH_OBJ> } ...

   A teardown message is used to delete a switched path to an egress
   identifier.  When the routing protocols indicate an egress identifier
   is no longer in use, the egress ISR SHOULD initiate a teardown.  When
   an ISR changes from an egress ISR to a non-egress ISR due to an ARIS
   link turning ACTIVE, the ISR SHOULD initiate a teardown for its
   obsolete established switched paths.

   The Teardown follows the same path as the Establish message.  On
   receipt of a Teardown message, the allocated labels for the given
   egress identifier MUST be released.

   The Teardown message must be retransmitted at the Retransmit Timer
   interval, until an Acknowledge message is received.


2.6. Acknowledge

   This message is sent as a response to ARIS messages.  It may be used
   as a positive acknowledge (Ack) or negative acknowledge (Nak).

   The format of an Acknowledge Message is:
        <Ack Message> ::= <Common Header>
                          <ACK_OBJ>
                         [<LABEL_OBJ>]
                         [<TUNNEL_OBJ>]




Feldman, et al.        Expiration: September 1997              [Page 11]


Internet-Draft             ARIS Specification                 March 1997


   ARIS messages requiring a response SHOULD be placed on a retransmit
   queue.  If an expected ARIS response is not received within the
   Retransmit Timer period, the ARIS message is retransmitted.

   The Init, Trigger, Teardown, and Establish messages may receive a
   negative acknowledge (Nak) on an error condition.  The only messages
   that require a positive acknowledge (Ack) are the Teardown and Estab-
   lish messages.  On receipt of an Acknowledge message, the original
   message MUST be removed from the retransmit queue.

   On receipt of a positive Acknowledge message in response to a
   destination- based Establish message, the ISR splices the upstream
   label to the downstream label when loop prevention is configured.
   When a received Establish message contained a zero label, the Ack-
   nowledge returns the allocated label.

   See DVMRP section 8.1 for a discussion on the use of the Acknowledge
   Tunnel object.


2.7. KeepAlive

   Neighbors that are in the ACTIVE state may exchange KeepAlive mes-
   sages.

   The format of a KeepAlive Message is:
        <KeepAlive Message> ::= <Common Header>

   Note that the KeepAlive message is the only ARIS message to have no
   objects.

   This message is sent by an ISR to inform its neighbors of its contin-
   ued 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.  A
   recommended transmission interval is 1/3 of the exchanged neighbor
   timeout period.












Feldman, et al.        Expiration: September 1997              [Page 12]


Internet-Draft             ARIS Specification                 March 1997


3. Neighbor Adjacency

   ARIS must form an adjacency with each of its directly attached ARIS
   neighbors before it may begin establishing switched paths.  Initiali-
   zation messages are transmitted over ARIS interfaces to discover the
   ARIS neighbors and exchange adjacency information.


3.1. State Transition

   Local Session Number (LSN):
      Sending ISR's own session number.  This is always sent in the common
      header "Sender Session Number" field, and verified in the "Receiver
      Session Number" field upon receipt of a message.

   Neighbor Session Number (NSN):
      The session number of an adjacent ISR as learned via the common header
      "Sender Session Number" field received via the INIT message.  It is sent
      in the "Receive Session Number" field in all subsequent messages.  If
      the Neighbor Session Number is unknown, this field must be set to zero.


   Match condition (S1):   Receiver Session Number == 0
   Match condition (S2):   Local Session Number == Receiver Session Number
   Match condition (S3):   Local Session Number == Receiver Session Number &&
                           Neighbor Session Number == Sender Session Number

   Note:
   INIT w/0:   INIT transmitted with the Receiver Session Number set to 0
   INIT w/NSN: INIT transmitted with the Receiver Session Number set to the
               learned Neighbor Session Number

   State: INITSENT

   +====================================================================+
   | Receive        | Action                                | New State |
   +================+=======================================+===========+
   | INIT && (S1)   | Update NSN; Send INIT w/NSN           | INITRCVD  |
   +----------------+---------------------------------------+-----------+
   | INIT && (S2)   | Update NSN; Send KEEP                 | ACTIVE    |
   +----------------+---------------------------------------+-----------+
   | INIT && !(S2)  | Send INIT w/0                         | INITSENT  |
   +----------------+---------------------------------------+-----------+
   | other          | Drop Packet                           | INITSENT  |
   +----------------+---------------------------------------+-----------+
   | timeout        | Send INIT w/0                         | INITSENT  |
   +====================================================================+




Feldman, et al.        Expiration: September 1997              [Page 13]


Internet-Draft             ARIS Specification                 March 1997


   State: INITRCVD

   +====================================================================+
   | Receive        | Action                                | New State |
   +================+=======================================+===========+
   | INIT && (S1)   | Update NSN; Send INIT w/NSN           | INITRCVD  |
   +----------------+---------------------------------------+-----------+
   | INIT && (S2)   | Update NSN; Send KEEP                 | ACTIVE    |
   +----------------+---------------------------------------+-----------+
   | INIT && !(S2)  | Send INIT w/0                         | INITSENT  |
   +----------------+---------------------------------------+-----------+
   | KEEP && (S3)   | Send KEEP                             | ACTIVE    |
   +----------------+---------------------------------------+-----------+
   | KEEP && !(S3)  | Send INIT w/0                         | INITSENT  |
   +----------------+---------------------------------------+-----------+
   | other          | Drop Packet                           | INITRCVD  |
   +----------------+---------------------------------------+-----------+
   | timeout        | Send INIT w/0                         | INITSENT  |
   +====================================================================+


   State: ACTIVE

   +====================================================================+
   | Receive        | Action                                | New State |
   +================+=======================================+===========+
   | INIT && (S1)   | New LSN; Update NSN; Send INIT w/NSN  | INITRCVD  |
   +----------------+---------------------------------------+-----------+
   | INIT && (S3)   | Send KEEP                             | ACTIVE    |
   +----------------+---------------------------------------+-----------+
   | KEEP && (S3)   | Send KEEP                             | ACTIVE    |
   +----------------+---------------------------------------+-----------+
   | other          | Drop Packet                           | ACTIVE    |
   +----------------+---------------------------------------+-----------+
   | timeout        | New LSN; Send INIT                    | INITSENT  |
   +====================================================================+


   NOTES:
   ======
   * No more than one KEEPALIVE may be sent within the KeepAlive transmission
     interval
   * No more than one INIT may be sent within the Retransmit Timer interval
   * Once ARIS neighbors are in the ACTIVE state, all ARIS messages MUST verify
     the session numbers and the neighbor router-id.






Feldman, et al.        Expiration: September 1997              [Page 14]


Internet-Draft             ARIS Specification                 March 1997


4. Egress Identifiers

   A unique switched path is established for each egress identifier,
   where an egress identifier represents one or more routes that share a
   common switched path through a network.  Egress identifiers may be
   extracted from information in the routing protocols, or may be expli-
   citly configured.  The egress identifiers are populated in an ISR
   forwarding table.  Once ARIS neighbors are ACTIVE, they may begin
   exchanging switched path labels for each egress identifier via the
   Establish message.


4.1. Egress ISR

   An ISR is defined to be an "egress ISR" on a per egress identifier
   basis. Thus, an ISR may considered an egress for a particular set of
   egress identifiers, and a non-egress for others.

   An ISR is an egress ISR, with respect to a particular egress identif-
   ier, 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 net-
             works, or another autonomous system for OSPF AS externals
             and BGP routes [rfc1583] [rfc1771].



4.2. Selecting Egress Identifiers

   Following are the currently defined egress identifiers. New egress
   identifiers may be added as needed:

        a)   IPv4 address
             This egress identifier contains an IP address.  This iden-
             tifier is used for host or CIDR prefixes [rfc1519].  This
             type results in each IP destination prefix sustaining its
             own switched path tree.  It is recommended in environments
             where no aggregation information is provided by the routing
             protocols (such as RIP), or in networks where the number of
             destination prefixes is limited.




Feldman, et al.        Expiration: September 1997              [Page 15]


Internet-Draft             ARIS Specification                 March 1997


        b)   BGP Next Hop
             This egress identifier contains the value in the BGP
             NEXT_HOP attribute.  It may be the IP address of a BGP
             border router (enabling one switched path tree for all des-
             tinations reachable through the same egress point), or the
             address of an external BGP peer (enabling one switched path
             tree for all routes destinated to the same external peer).
             This identifier provides the maximum obtainable aggrega-
             tion.

        c)   OSPF Router ID
             This egress identifier contains the OSPF Router ID of the
             router that initiated the link state advertisement.  This
             type allows aggregation of traffic on behalf of multiple
             datagram protocols routed by OSPF.

        d)   OSPF Area Border Router
             This egress identifier contains the OSPF Router ID of the
             border router.  This identifier is used in OSPF external
             link advertisement with a non-zero forwarding address.

        e)   Explicit Path
             This egress identifier contains an explicitly defined
             source-routed path.  This information may be provided via
             configuration, or may be computed via a Dijkstra calcula-
             tion for a certain metric (e.g. QoS, Tos), and may be used
             for point-to-point, point-to-multipoint, or multipoint-to-
             point paths.  This type of egress identifier may be egress
             or ingress based.

        f)   CIDR group
             This egress identifier contains a list of CIDR prefixes
             that are to share a common egress point.  This type is con-
             figured, and may be used when additional aggregation not
             provided by the routing protocols is required.

        g)   Flow
             This egress identifiers contains information pertaining to
             a constant set of datagram information, such as port,
             dest-addr, src-addr, etc.  This feature provides the user
             with the ability to use ARIS with no aggregation.  This
             type of egress identifier may be egress or ingress based.

        h)   Multicast (S,G)
             This egress identifier contains the unique (Source, Group)
             multicast pair. It creates one switched path tree per (S,G)
             pair.  It is used by DVMRP and PIM-DM [rfc1075] [pim-dm].




Feldman, et al.        Expiration: September 1997              [Page 16]


Internet-Draft             ARIS Specification                 March 1997


        i)   Multicast (G)
             This egress identifier contains the unique multicast group
             on a multicast tree.  It creates one switched path tree per
             group.  It is used by PIM-SM [pim-sm].



5. Destination-Based Routing


5.1. Forwarding Information Bases

   An ISR extends the FIB to associate route entries with egress iden-
   tifiers via the routing protocols or configuration.  An egress iden-
   tifier may be defined for a single route entry, or may be "aggre-
   gated", where it is shared by multiple route entries.  These egress
   identifiers are assigned switched paths by the ARIS protocol.

   Route lookups are performed as they are on conventional routers
   (longest prefix match).  However, if an ARIS switched path is associ-
   ated with the route, traffic is forwarded on that path.  If a
   switched path is not available, traffic may be forwarded as on a con-
   ventional router.

   Note that any route may be associated with both an aggregated
   switched path (sharing a common switched path with many routes), as
   well as an individual switched path (de-aggregated from the shared
   path).  The switched path selected will always be the most specific
   available as decided by a longest prefix match or policy.



                              +---+
                              | A |
                              +---+
                                |
                                V
                              +---+
                              | B |
                            / +---+ \
                           V         V
                         +---+     +---+
                         | C |     | D |
                         +---+     +---+
                           |         |
                           V         V
                         Net 1     Net 2
                         Net 3     Net 4



Feldman, et al.        Expiration: September 1997              [Page 17]


Internet-Draft             ARIS Specification                 March 1997


     Figure 1:  Sample Topology

   In Figure 1, The Forwarding Information Base (FIB) on ISR A knows of
   two aggregated egress identifiers, ISR C and ISR D.  Net 1 and Net 3
   in the FIB are associated with the switched path assigned to
   (egress-id:C), while Net 2 and Net 4 are associated with switched
   path assigned to (egress-id:D).

   It is also possible to de-aggregate a prefix from the select aggre-
   gate egress-id, and setup a unique switched path.  For example, the
   FIB entry on ISR A for a de-aggregated Net 2 would be associated with
   (egress-id:Net2).


5.2. TTL Decrement

   In order to comply with the requirements for IPv4 routers [rfc1812],
   the IP datagram Time-To-Live (TTL) field must be decremented on each
   hop it traverses.  The forwarding ISR SHOULD decrement a packet TTL
   by the number of switched hops plus one when the the link-layer
   packet header does not have a TTL field (as in ATM).  The switched
   path hop-count is computed via the Establish message.  If the decre-
   ment value is greater than or equal to the TTL of the packet, the
   packet MAY be forwarded hop-by-hop or discarded.


5.3. Loop Prevention

   An ISR may be configured with loop prevention.  In this, an egress
   ISR initiating an Establish message includes the Router Path object.
   The ISR list in the object MUST be concatenated with the unique
   router-id of each ISR through which the Establish traverses.  If an
   ISR receives an Establish message with itself in the list, a loop is
   detected.  When this occurs, the Establish message MUST be ter-
   minated.

   Further, if an ISR modifies the network layer path to an egress iden-
   tifier due to a routing change, the ISR MUST NOT splice the upstream
   switched path(s) to the new downstream switched path until it for-
   wards the new ISR list to the upstream ISR(s) via the Establish mes-
   sage, and receives the Acknowledge message(s) in return.  An ISR that
   receives an Establish message with a modified ISR list in the Router
   Path object MUST unsplice any established upstream switched path(s)
   from the downstream switched path, and re-establish the path through
   the Establish/Acknowledge mechanism.

   If an ISR is not configured with loop prevention, no Router Path
   object is included in the Establish message, and modified paths to



Feldman, et al.        Expiration: September 1997              [Page 18]


Internet-Draft             ARIS Specification                 March 1997


   egress identifiers are immediately spliced.  The default configura-
   tion is loop prevention.


5.4. BGP Interaction with ARIS

   The BGP implementation of the ISR uses the NEXT_HOP attribute as the
   egress identifier.  When the BGP border ISR injects routes into the
   BGP mesh, it may use its own IP address or the address of its exter-
   nal BGP peer as the value of the NEXT_HOP attribute.  This choice of
   NEXT_HOP attribute value creates different establishment behaviors
   with ARIS.

   If the BGP border ISR uses its own IP address as the NEXT_HOP attri-
   bute in its injected routes, then all of these BGP routes share the
   same egress identifier.  This approach establishes only one tree to
   the BGP border ISR, and the border ISR may forward traffic at the IP
   layer towards its external BGP neighbors.

   If the BGP border ISR uses the external BGP peer as the NEXT_HOP
   attribute in its injected routes, then the BGP routes from each
   unique external BGP neighbor share the same egress identifier.  This
   approach establishes one switched path tree per external BGP neighbor
   of the BGP border ISR.  The BGP border ISR can switch traffic
   directly to its external BGP neighbors.


5.5. OSPF Interaction with ARIS

   The OSPF protocol exchanges five types of "link state advertisements"
   to create OSPF routing tables.  All types of advertisements contain
   an "Advertising Router" field, which identifies the OSPF Router ID of
   the router that originates the advertisement.  The ISR uses this OSPF
   Router ID as the egress identifier.

   The use of the OSPF Router ID as an egress identifier allows a new
   level of destination prefix abstraction.  In a typical network, a
   router may be connected to several LANs (Ethernets, Token Rings,
   etc.), and may communicate to remote networks outside of its routing
   domain via adjacent routers.  The remote destination networks may be
   injected into the link state routing domain via static configuration,
   or via other routing protocols (such as RIP or BGP).  These local and
   remote networks may be represented in the router forwarding tables as
   many destination prefixes, which cannot be aggregated into shorter
   prefixes (even when using CIDR]).  Router labels (OSPF Router ID)
   provide a compact means of representing a number of destination pre-
   fixes that exit the link state routing domain at the same egress
   router.  The association between destination prefixes and router



Feldman, et al.        Expiration: September 1997              [Page 19]


Internet-Draft             ARIS Specification                 March 1997


   labels is an easy by-product of the normal SPF computation.

   The one exception to using the OSPF Router ID is when ISRs receive an
   AS external link advertisement with a non-zero forwarding address.
   The OSPF protocol uses the forwarding address to allow traffic to
   bypass the router that originates the advertisement.  Since the OSPF
   Router ID refers to the bypassed router, it is inadequate as an
   egress identifier in this case.  Instead, the ARIS protocol must use
   the forwarding address as the egress identifier.

   Using the forwarding address as the egress identifier provides signi-
   ficant benefits.  Since the AS external forwarding address and the
   BGP NEXT_HOP attribute are both external IP addresses, they are com-
   patible types of egress identifiers, which may allow BGP and OSPF
   routes to share the same switched path.  Further, the OSPF AS boun-
   dary ISR can switch traffic directly to its external neighbors, just
   like BGP.

   The ISR identifies itself as an OSPF egress when the ISR is an area
   border router or an AS boundary router, or when it is directly
   attached to a LAN.


6. L2-Tunnels

   L2-tunnels provide a mechnism by which L2 data units can be switched
   at a de-aggregating ISR without performing network layer forwarding.
   The ARIS protocol enables a de-aggregating ISR to advertise labels to
   the upstream ingress ISRs.  Ingress ISRs use this information to
   build a packet with the advertised label in the L2 header.  This
   packet is then encapsulated into another L2 header with the label
   representing the switched path to the de-aggregating ISR.

   The de-aggregating ISR advertises the labels via the Establish mes-
   sage using the tunnel object, where this object contains a list of
   egress identifiers that are to use the tunnel label.  An ISR receiv-
   ing a tunnel object for an egress identifier that is not in the for-
   warding table ignores the tunnel information.

   For example, the egress identifiers in the Tunnel object may be a
   list of CIDRs.  This enables those CIDRs to share a switched path to
   a de-aggregation point, and then be de-encapsulated and switched
   towards their final destinations on different paths.

   Although the current specification provides only two levels of tun-
   neling, multiple level support may be provided in future revisions.





Feldman, et al.        Expiration: September 1997              [Page 20]


Internet-Draft             ARIS Specification                 March 1997


7. Label Management


7.1. VCIB

   The VC information base (VCIB), which does not exist on a standard
   router, maintains for each egress identifier the upstream to down-
   stream switched path label mappings and related states. This mapping
   is controlled by the ARIS protocol.  The labels are populated in the
   label swapping cross-connect table.


7.2. Label Swapping

   An incoming L2 data unit is forwarded using the information provided
   by an L2 forwarding and label swapping table.  This table is indexed
   directly by the incoming port number and label, and provides the
   mapped outgoing port(s) and outgoing label(s). In the case of point-
   to-multipoint, outgoing information for each branch is obtained.
   This cross-connect table and the L2 forwarding/swapping mechanism
   currently exists in standard ATM and Frame Relay switches.

   The label swapping table should be extended to include L2-tunnel
   information, so when an ISR is a switched path termination point,
   de-encapsulation and appropriate re-encapsulation can take place.
   All related information for this purpose should be maintained in this
   table.


8. Multicast

   The establishment of the IP Multicast 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 mechanism for establishing the switched path is virtually the
   same as described in the unicast destination-based routing case.  The
   root of the tree (ingress in this case) transmits the Establish RPM
   style to all child links as determined by the multicast fib.  Each
   ISR that receives the Establish MUST verify the message was received
   from the correct parent, and if loop prevention is configured, uses
   the Router Path object to guarantee a loop-free path.  The switched
   paths MAY be created such that the Establish carries NO Label object,
   and the Acknowledge message returns the downstream link label that is
   spliced to the upstream label.  A new receiver joining an established
   tree may either send a trigger message to the parent ISR, or wait for
   the next refresh cycle to be spliced into the switched path.



Feldman, et al.        Expiration: September 1997              [Page 21]


Internet-Draft             ARIS Specification                 March 1997


8.1. DVMRP and PIM-DM

   The choice of egress identifier for the multicast routing protocols
   DVMRP and PIM-DM is the (S,G) pair.  This egress identifier creates
   one ingress routed point-to-multipoint switched path tree per source
   address and group pair.  The creation of the switched path is ini-
   tiated by the ingress node on receipt of traffic from the sender S
   for a particular multicast group G.

   The branches of the multipoint-to-point 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.

   ARIS can also support the notion of DVMRP tunnel switched paths,
   through the Establish and L2-tunneling mechanism.  In this case, the
   egress identifier is the DVMRP tunnel endpoint.  The source of the
   tunnel initiates the Establish message to its next-hop, but with the
   end-to-end option.  Each intermediary node that receives such an
   Establish may create the switched path, but does not immediately send
   an Acknowledge message.  It forwards the message to its next-hop and
   waits for the DVMRP tunnel endpoint to initiate the Acknowledge.
   This Acknowledge message includes a Tunnel object, where the Tunnel
   object contains the list of labels for all reachable (S, G) pairs.
   These labels are used by the DVMRP tunnel source to populate its
   label-swapping table for the purpose of encapsulation.  At the source
   of the DVMRP tunnel, an incoming header is replaced by a header with
   the DVMRP tunnel label, followed by the label used by the DVMRP tun-
   nel endpoint to the given (S,G).  This enables the DVMRP tunnel end-
   point to de-encapsulate the packet, and forward the message on its
   switched path to (S, G).


8.2. PIM-SM

   The choice of egress identifier for those groups on a shared tree is
   (RP,G), where RP is the PIM-SM rendezvous point.  For the groups on a
   source-specific tree, the egress identifier is (S, G).

   The PIM-SM switched path Establish is initiated by an ingress when it
   receives a PIM Join/Prune message.  In the shared-tree case, the RP
   behaves as the ingress, and initiates the switched path for all down-
   stream receivers.  For those groups that are on a source-specific
   tree, the ingress of the source initiates the switched path.  A
   source-specific switched path for a group that was created by the
   rendezvous point SHOULD be spliced to the downstream shared tree.






Feldman, et al.        Expiration: September 1997              [Page 22]


Internet-Draft             ARIS Specification                 March 1997


9. Multipath

   Many IP routing protocols such as OSPF support the notion of equal-
   cost multipath routes, in which a router maintains multiple next hops
   for one destination prefix when two or more equal-cost paths to the
   prefix exist.  Each ISR that receives multiple Establishment messages
   from downstream ISRs with different paths to the same egress identif-
   ier can choose via configuration one of four different approaches for
   sending Establish messages upstream.

   One approach is to send multiple Establish messages upstream,
   preserving multiple switched paths to the egress ISR, where each
   switched path represents a different equal-cost path.  In this case,
   the ingress ISR will make multipath decisions for traffic on behalf
   of all downstream ISRs.  Each Establish message requires an addi-
   tional numeric identifier to be able to distinguish multiple distinct
   switched paths to the destination, so that successive Establish mes-
   sages for distinct switched paths are not misinterpreted as consecu-
   tive replacements of the same switched path.  When multiple Establish
   switched paths are preserved upstream, they require distinct label
   assignments, which works against conservation of switched paths.

   Another approach, that conserves switched paths at the cost of
   switching performance, is to originate one Establish message
   upstream, and to forward datagrams at the IP network layer on the
   multipath point ISR.

   A third approach is to propagate only one Establish message from the
   downstream ISRs to the upstream ISRs, and ignore the content of other
   Establish messages.  This conserves switched paths and maintains
   switching performance, but may not balance loads across downstream
   links as well as the first two approaches, even if switched paths are
   selectively dropped.

   The final approach is to propagate one Establish message that carries
   the content of all downstream Establish messages, so that only one
   upstream switched path is created to the multipath point.  This
   requires that the switching hardware on the multipath ISR be capable
   of correctly distributing the traffic of an upstream switched path
   onto multiple downstream switched paths.  Furthermore, the Establish
   message to send upstream must concatenate the ISR ID lists from down-
   stream messages, in order to preserve the loop-free property.  The
   ISR ID list concatenation is similar to using AS_SETs for aggregation
   in the BGP protocol.  This final approach has the benefit of both
   conservation and performance, although it requires a slightly more
   complex implementation.

   The default behavior is to ignore the multipath route(s), and



Feldman, et al.        Expiration: September 1997              [Page 23]


Internet-Draft             ARIS Specification                 March 1997


   establish only one switched path to the egress identifier.


                              +---+
                              | A |
                              +---+
                                |
                                V
                              +---+
                              | B |
                            / +---+ \
                           V         V
                         +---+     +---+
                         | C |     | D |
                         +---+ \ / +---+
                                V
                              +---+
                              | E |
                              +---+
                                |
                              Net 1

   Figure 2:  Multipath Sample Topology

   Figure 2 shows a topology for a network with two equal cost paths to the
   egress identifier, ISR E.  On ISR A, the Forwarding Information Base (FIB)
   for Net 1 is associated with both (egress-id:E, mpath-id:1) and
   (egress-id:E, mpath-id:2).


10. Timers

        a)   KeepAlive Timer
             This configured value is exchanged via the INIT message
             Timer object, and is the interval by which an ARIS message
             must be received to prevent neighbor adjacency time-out.  A
             recommended KeepAlive transmission interval is 1/3 of the
             exchanged neighbor timeout period.

        b)   EstablishRefresh Timer
             This configured value is received in the Establish message
             Timer object, and is the interval by which an Establish
             refresh message MUST be received to prevent an egress
             identifier's switched path time-out.  If this value is 0,
             no refresh Establish message will be transmitted, else the
             refresh will be transmitted at 1/3 of the EstablishRefresh
             Timer value.  Note that this value MUST be greater than the
             Retransmit Timer value.



Feldman, et al.        Expiration: September 1997              [Page 24]


Internet-Draft             ARIS Specification                 March 1997


        c)   Retransmit Timer
             This is the interval by which an ARIS message must receive
             a response.  If a response is not received within the
             interval, the ARIS message will be retransmitted.  Note
             that this value MUST be less than the EstablishRefresh
             Timer value.



11. Configuration

   ARIS MUST allow configuration of the various timers as described in
   section 10.

   The configuration MUST support egress identifier selection.  By
   default, ARIS egress identifiers are selected via the routing proto-
   cols.  For example, BGP may select the egress identifier from its
   NEXT_HOP field, OSPF may select the area border router, and other
   protocols may select the CIDR prefix. However, configuration can
   override these defaults.  In addition, the user may configure addi-
   tional egress identifiers for specifically requested switched paths
   at edge routers.  The configuration SHOULD also provide the ability
   to stop an egress ISR from originating Establishes for a specified
   set of egress identifiers.

   The configuration MUST allow the selection of the owner/allocator of
   the incoming and the outgoing label space for each link.  Note that
   this MUST have a matching configuration on the link neighbor.

   The configuration SHOULD support the choice of ATM encapsulation
   [rfc1483].  The default is NULL encapsulation.

   The configuration SHOULD support the choice of action for multipath.
   The default action MUST be to propagate only one path towards the
   ingress.
















Feldman, et al.        Expiration: September 1997              [Page 25]


Internet-Draft             ARIS Specification                 March 1997


12. ARIS Signaling Pseudo Code

   receive_message(arispkt, nbr)
   {

      if (verify_msg(arispkt) fails)
          return;

      switch(arispkt->type) {
      case INIT:
           See state table defined in section 3.1
      case KEEPALIVE:
           See state table defined in section 3.1
           break;
      case ESTABLISH:
           process_establish_msg(arispkt->establish_contents, nbr);
           update nbr->rcv_time to current-time;
           break;
      case TRIGGER:
           process_trigger_msg(arispkt->trigger_contents, nbr);
           update nbr->rcv_time to current-time;
           break;
      case ACK:
           process_ack_msg(arispkt->ack_contents, nbr);
           update nbr->rcv_time to current-time;
           break;
      case TEAR:
           process_teardown_msg(arispkt->tear_contents, nbr);
           update nbr->rcv_time to current-time;
           break;
      }
   }

   /*
    * Verify contents of ARIS common header
    */
   int
   verify_msg(arispkt, nbr)
   {
      if (IP-style header checksum fails ||
          common-header sequence number check fails)
          return(error);
      if (nbr->state == ACTIVE) {
          if (common-header neighbor router id not matched ||
              common-header sender session number not matched ||
              common-header receiver session number not matched)
              return(error);
      }



Feldman, et al.        Expiration: September 1997              [Page 26]


Internet-Draft             ARIS Specification                 March 1997


      return(0);
   }

   /*
    * Process received establish message (destination-based)
    */
   process_establish_msg(establish_msg, sender-nbr)
   {
       for (each egress-id in establish_msg) {
           fib_verify(egress-id, sender-nbr);
           transmit ack to sender-nbr;
           if ((new egress-id) || (different multipath-identifier)) {
               create VCIB entry;
               populate fib with given label;
               for (each ARIS-nbr) {
                    if (ARIS-nbr == sender-nbr)
                        continue;    /* ignore downstream nbr */
                    allocate upstream label/populate VCIB;
                    tx_establish_message(establish_msg, ARIS-nbr);
               }
           } else {
               if ((ISR list same as previously received) &&
                   (switched-path label same as previously received)) {
                    /* This is a refresh message */
                    for (each ARIS-nbr) {
                        if (ARIS-nbr == sender-nbr)
                            continue;    /* ignore downstream nbr */
                        tx_establish_msg(establish_msg, ARIS-nbr)
               } else {
                   unsplice current downstream label;
                   if (new switched-path label)
                       repopulate fib with given label;
                   for (each ARIS-nbr) {
                       if (ARIS-nbr == sender-nbr)
                           continue;    /* ignore downstream nbr */
                       tx_establish_msg(establish_msg, ARIS-nbr);
                   }
               }
           }
           if (egress-id is on retransmit queue)   /* May be triggering */
               remove egress-id from retransmit queue
       }
   }

   tx_establish_msg(establish_msg, upstream-nbr)
   {
       append router-id to ISR-list
       increment hopcount



Feldman, et al.        Expiration: September 1997              [Page 27]


Internet-Draft             ARIS Specification                 March 1997


       set upstream-nbr label
       tx_msg(establish_msg, upstream-nbr, ESTABLISH)
   }

   /*
    * Process received trigger message
    */
   process_trigger_msg(trigger_msg, upstream-nbr)
   {
       for (each egress-id in trigger_msg) {
           for (each ARIS-nbr) {
               if (ARIS-nbr is next-hop for egress-id) {
                  build establish_msg;
                  if (no upstream-nbr label)
                      allocate upstream label/populate VCIB;
                  tx_establish_message(establish-message, upstream-nbr)
               }
           }
       }
   }

   /*
    * Process received acknowledge message
    */
   process_ack_msg(ack-message, sender-nbr)
   {
       if (match original sequence number and msg type to retransmit queue entry)
           remove item from retransmit queue;
       if (original message was establish-message)
          splice upstream label to downstream label;
   }

   tx_msg(arispkt, nbr, msg-type)
   {
       prepend common-header to arispkt;
       if (arispkt->type != ACK)
           put message on retransmit queue
       prepend protocol header to arispkt;
       update nbr->send_time to current-time;
       transmit message to nbr
   }

   /*
    * Forwarding Table signals ARIS with an egress identifier
    */
   learn_egress_identifier(egress-id, next-hop)
   {
      if ((next-hop is not aris_nbr) ||



Feldman, et al.        Expiration: September 1997              [Page 28]


Internet-Draft             ARIS Specification                 March 1997


          (next-hop is different OSPF-area) ||
          (next-hop is different domain)) {
           /* I am the egress */
           initiate_establish(egress-id)
       } else {
           /* I am intermediary ISR or ingress */
           send_trigger(egress-id, next-hop)
       }
   }

   /*
    * Egress node initiates Establish message
    */
   initiate_establish(egress-id)
   {
       for (each ARIS-nbr) {
           if (ARIS-nbr is next-hop for egress-id)
               continue;           /* ignore downstream nbr(s) */
           allocate upstream label/populate VCIB;
           build establish_msg;
           tx_establish_message(establish_msg, ARIS-nbr)
       }
       put egress-id on EstablishRefresh queue
   }



























Feldman, et al.        Expiration: September 1997              [Page 29]


Internet-Draft             ARIS Specification                 March 1997


13. Object Definitions


13.1. Common Header

      ARIS messages begin with the following header.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Version    |    Msg Type   |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Header Checksum       |           Reserved            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Sender Router ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Sender Sequence Number                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Sender Session Number                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Receiver Session Number                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Version
            Version number of the ARIS protocol, currently 1.

        Msg Type
            Defines the type of the ARIS message, as follows:

                  INIT        = 1
                  KEEPALIVE   = 2
                  TRIGGER     = 3
                  ESTABLISH   = 4
                  TEARDOWN    = 5
                  ACKNOWLEDGE = 6

        Length
            Total length of the ARIS message, including this header.

        Header Checksum
            IP style checksum of the complete ARIS message, that includes
            the ARIS Common Header and all the objects therein.

        Sender Router ID
            Sender router identifier.

        Sender Sequence Number
            Sender message sequence number. The upper 16 bits may be used



Feldman, et al.        Expiration: September 1997              [Page 30]


Internet-Draft             ARIS Specification                 March 1997


            as local flags, while the lower 16 bits represent sequence numbers
            from 1 through 2^16-1.

        Sender Session Number
            Unique session number of the sender.

        Receiver Session Number
            Session number of the receiver as known by the sender through
            a previous INIT message.  The sender MUST set this to 0 in
            an INIT message if there is no learned receiver session number.


13.2. Common Object Header

      All objects in the ARIS message start with the following object
      header. The objects are placed back-to-back within the ARIS message.
      Each object MUST be padded to a word boundary.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Obj Type   |    Sub Type   |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Object Type
            Object type of this object. Currently the following objects
            are defined:
                 LABEL_OBJ       = 1
                 EGRID_OBJ       = 2
                 MPATH_OBJ       = 3
                 RPATH_OBJ       = 4
                 EPATH_OBJ       = 5
                 TUNNEL_OBJ      = 6
                 TIMER_OBJ       = 7
                 ACK_OBJ         = 8
                 INIT_OBJ        = 9

        Sub Type
            Sub type of the object. See object definitions for sub types
            of an object.

        Length
            Length of the object, including this header.








Feldman, et al.        Expiration: September 1997              [Page 31]


Internet-Draft             ARIS Specification                 March 1997


13.3. Label Object

      The selected link-layer label.

      Obj Type = 1, Sub Type = 1  (ATM)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |E|Res|V|          VPI          |              VCI              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        E-bit
            End-to-End Acknowledge bit.

        V-bit
            Virtual Path switching indicator bit.  If V-bit is 1, only the
            VPI field is significant.  If V-bit is 0, both VPI and VCI are
            significant.

        VPI (12 bits)
            Virtual Path Identifier. If VPI is less than 12-bits it should
            be right justified in this field and preceding bits should be
            set to 0.  If both the VPI and the VCI are 0, the receiver
            allocates the label.

        VCI (16 bits)
            Virtual Connection Identifier. If the VCI is less than 16-bits,
            it should be right justified in the field and the preceding
            bit must be set to 0. If Virtual Path switching is indicated
            in the VP field, then this field must be ignored by the receiver
            and set to 0 by the sender.  If both the VPI and the VCI are 0,
            the receiver allocates the label.


13.4. Egress Identifier Object

      The egress identifier, in any one of the following formats:

      Obj Type = 2, Sub Type = 1  (IPv4 Address)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Reserved                   |  Prefix Len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            IPv4 Address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Feldman, et al.        Expiration: September 1997              [Page 32]


Internet-Draft             ARIS Specification                 March 1997


        Prefix Len
            Number of significant bits of the IPv4 Network Address field.

        IPv4 Address
            Egress identifier represented by an IPv4 Network address.


      Obj Type = 2, Sub Type = 2  (BGP NEXT_HOP)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     BGP Next Hop IPv4 Address                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        BGP Next Hop
           The IPv4 address of the BGP Next Hop router.


      Obj Type = 2, Sub Type = 3  (OSPF Router ID)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        OSPF Router Id                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        OSPF Router ID
            Router identifier of the OSPF node.


      Obj Type = 2, Sub Type = 4  (OSPF Area Border Router)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Reserved                   |  Prefix Len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     IPv4 Network Address                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  OSPF Area Border Router ID                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Prefix Len
            Number of significant bits of the IPv4 Network Address field.

        IPv4 Network Address
            Network Address.



Feldman, et al.        Expiration: September 1997              [Page 33]


Internet-Draft             ARIS Specification                 March 1997


        OSPF Area Border Router ID
            Router identifier of the OSPF ABR node.


      Obj Type = 2, Sub Type = 5  (Multicast Source,Group)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    IPv4 Source Address                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 Multicast Group Address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        IPv4 Source Address
            Source IPv4 address of the multicast stream.

        IPv4 Multicast Group Address
            IPv4 Multicast Group Address.


      Obj Type = 2, Sub Type = 6  (Multicast Group)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    IPv4 Rendezvous Point                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 Multicast Group Address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        IPv4 Rendezvous Point
            IPv4 address the rendezvous point of the multicast stream.

        IPv4 Multicast Group Address
            IPv4 Multicast Group Address.


      Obj Type = 2, Sub Type = 7  (Flow)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    IPv4 Source Address                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    IPv4 Dest Address                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Source Port           |        Dest Port              |



Feldman, et al.        Expiration: September 1997              [Page 34]


Internet-Draft             ARIS Specification                 March 1997


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Protocol   |   Direction   |        Reserved               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        IPv4 Source Address
            Source IPv4 address.

        IPv4 Destination Address
            Destination IPv4 address.

         Source Port
            Source port.

         Destination Port
            Destination port.

         Protocol
             Protocol type.

         Direction
            Field indicating the direction of the switched path.  Field is
            set to 1 on Downstream; field is set to 2 on Upstream.


      Obj Type = 2, Sub Type = 8  (CIDR list)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Aggregate Router-Id                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Count             |    Reserved   |  Prefix Len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          IPv4 Address                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                                                               ~
        |                                                               |
        ~                                                               ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Prefix Len   |              IPv4 Address...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ...         |                 Pad                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Aggregate Router-Id
            The IPv4 Address of the ISR which is the aggregation point
            for the listed set of IPv4 Addresses.




Feldman, et al.        Expiration: September 1997              [Page 35]


Internet-Draft             ARIS Specification                 March 1997


        Count
            The number of IPv4 addresses in this object, which comprise
            the set of addresses that share the aggregation ISR.

        Prefix Len
            Number of significant bits of the IPv4 Address field.

         IPv4 Address
            An IPv4 Address associated with the aggregation ISR.
            Note this value may not be word aligned.


13.5. Multipath Identifier Object

      Uniquely identifies a switched path to an egress identifier.

      Obj Type = 3, Sub Type = 1

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Multipath Identifier                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Multipath Identifier
            A unique value that identifies a switched path.


13.6. Router Path Object

      Information related to the path the Establish message traverses.

      Obj Type = 4, Sub Type = 1

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Hop Count   |   Reserved    |        Router Id Count        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Router Id 1                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                                                               ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Router Id n                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Feldman, et al.        Expiration: September 1997              [Page 36]


Internet-Draft             ARIS Specification                 March 1997


        Hop Count
            The number of hops to the egress identifier.  It is incremented
            at each forwarding ISR.

        Router Id Count
             The number of Router Identifiers in this object.

        Router Id 1 to n-1
            A series of Router Identifiers indicating the path that the message
            has traversed.

        Router Id n
            Router Identifier of the router that sent the current message.
            This must be an adjacent router.


13.7. Explicit Path Object

      Explicitly defined source-routed path.

      Obj Type = 5, Sub Type = 1

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Direction   |  Reserved     |          Current              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          IPv4 Address                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   NH-Cnt      |   NH-Offset   |   NH-Offset   |   ...         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                                                               ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           IPv4 Address                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   NH-Cnt      |   NH-Offset   |   NH-Offset   |   ...         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Direction
            Field indicating the direction of the switched path.  Field is
            set to 1 on Downstream; field is set to 2 on Upstream.

         Current
            Pointer to the current IP address location in the explicit path.

         IPv4 Address



Feldman, et al.        Expiration: September 1997              [Page 37]


Internet-Draft             ARIS Specification                 March 1997


            IP address of a node in the switched path.  Note this value
            may not be word aligned.

         NH-Cnt
            The number of next-hops for the corresponding IP Address.
            A value of 0 indicates the end of the list.

         NH-Ptr
            A relative offset from the corresponding IP address to the
            location of a next-hop IP address.


13.8. Tunnel Object

      Encapsulation label.

      Obj Type = 6, Sub Type = 1  (IPv4 addresses)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Link-layer Label                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Count     |                Reserved                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Prefix Len   |       IPv4 Address...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ...         |    Prefix Len   |          IPv4 Addr...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                                                               ~
        |                                                               |
        ~                                                               ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Prefix Len   |                 IPv4 Address...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ...         |                 Pad                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Link-layer Label
            The label to use in tunnel encapsulation.

         Count
            The number of IPv4 addresses associated with the given label.

        Prefix Len
            Number of significant bits of the IPv4 Address field.

         IPv4 Address



Feldman, et al.        Expiration: September 1997              [Page 38]


Internet-Draft             ARIS Specification                 March 1997


            IP address that is to use the associated label.  Note this value
            may not be word aligned.


      Obj Type = 6, Sub Type = 2  (S, G)

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Link-layer Label                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       Count   |                Reserved                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    IPv4 Source Address                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 Multicast Group Address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                                                               ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    IPv4 Source Address                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 Multicast Group Address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Link-layer Label
            The label to use in tunnel encapsulation.

         Count
            The number of (S,G) pairs associated with the given label.

         IPv4 Source Address
            Source IPv4 address of the multicast stream.

         IPv4 Multicast Group Address
            IPv4 Multicast Group Address.


13.9. Timer Object

      Timeout value.

      Obj Type = 7, Sub Type = 1

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Timer Interval                           |



Feldman, et al.        Expiration: September 1997              [Page 39]


Internet-Draft             ARIS Specification                 March 1997


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Timer Interval
            A timeout interval (in seconds).  When present in an Init message,
            it is the Neighbor Dead Interval.  This interval is the maximum
            number of seconds that may elapse between received ARIS messages.
            When present in an Establish message, it is the RefreshEstablish
            Interval.  This interval is maximum number of seconds that may
            elapse between egress identifier refresh Establish messages.
            This value MUST be greater than 0.


13.10. Acknowledge Message Object

      Status of an ARIS message.

      Obj Type = 8, Sub Type = 1

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 Acknowledge Sequence Number                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Obj Type    |     Reserved  |             Error             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Acknowledge Sequence Number
             The sequence number of the originating message that is being
             acknowledged.

        Obj Type
              Type of message being acknowledged

        Error
              An error code.  A value of 0 indicates no error.


13.11. Init Message Object

      Information pertaining to neighbor initialization.

      Obj Type = 9, Sub Type = 1

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Res  |    Minimum VPI        |        Minimum VCI            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Feldman, et al.        Expiration: September 1997              [Page 40]


Internet-Draft             ARIS Specification                 March 1997


        |  Res  |    Maximum VPI        |        Maximum VCI            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Res
            Reserved.

        Minimum VPI (12 bits)
            Minimum Virtual Path Identifier that is supported on the switch.
            If VPI is less than 12-bits it should be right justified in this
            field and preceding bits should be set to 0.

        Minimum VCI (16 bits)
            Minimum Virtual Connection Identifier that is supported on the
            switch.  If VCI is less than 16-bits it should be right justified
            in this field and preceding bits should be set to 0.

        Maximum VPI (12 bits)
            Maximum Virtual Path Identifier that is supported on the switch.
            If VPI is less than 12-bits it should be right justified in this
            field and preceding bits should be set to 0.

        Maximum VCI (16 bits)
            Maximum Virtual Connection Identifier that is supported on the
            switch.  If VCI is less than 16-bits it should be right justified
            in this field and preceding bits should be set to 0.


14. Error Codes

   Error conditions and codes will be provided in a future revision of
   this memo.


15. Security Consideration

   An analysis of security considerations will be provided in a future
   revision of this memo.














Feldman, et al.        Expiration: September 1997              [Page 41]


Internet-Draft             ARIS Specification                 March 1997


16. Intellectual Property Considerations

   International Business Machines Corporation may seek patent or other
   intellectual property protection for some or all of the aspects dis-
   cussed in the forgoing document.


17. Acknowledgements

   The authors wish to acknowledge Rick Boivie, Steve Blake, and Hal
   Sandick for their valuable technical input.


18. References

   [aris]    A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, "Aggregate
             Route-Based IP Switching (ARIS)", Internet Draft
             <draft-viswanathan-aris-overview-00.txt>, IBM Corp, March 1997

   [rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
             Layer 5", RFC 1483, Telecom Finland, July 1993

   [rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
             RFC 1771, IBM Corp, Cisco Systems, March 1995

   [rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March 1994

   [rfc1075] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast
             Routing Protocol", RFC 1075, BBN, Stanford University,
             November 1988

   [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

   [pim-dm]  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

   [rfc1812] F. Baker (Editor), "Requirements for IP Version 4 Routers",
             RFC 1812, Cisco Systems, June 1995

   [rfc1519] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
             Routing (CIDR):  an Address Assignment and Aggregation Strategy",



Feldman, et al.        Expiration: September 1997              [Page 42]


Internet-Draft             ARIS Specification                 March 1997


             RFC 1519, BARRNET, Cisco Systems, MERIT, OARnet, September, 1993


19. Authors' Addresses

   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
































Feldman, et al.        Expiration: September 1997              [Page 43]


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