Internet-Draft Nancy Feldman Expiration Date: September 1997 Arun Viswanathan IBM Corp. March 1997 ARIS Specification 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: ::= 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: ::= { [] [] [] } ... 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: ::= { [] [] } ... 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: ::= { } ... 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: ::= { } ... 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: ::= [] [] 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: ::= 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 , 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 , 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 , 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]