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]