One document matched: draft-armitage-ion-distmars-spec-00.txt
Internet-Draft Grenville Armitage
Bellcore
January 22nd, 1997
A Distributed MARS Protocol
<draft-armitage-ion-distmars-spec-00.txt>
Status of this Memo
This document was submitted to the IETF Internetworking over NBMA
(ION) WG. Publication of this document does not imply acceptance by
the ION WG of any ideas expressed within. Comments should be
submitted to the ion@nexen.com mailing list.
Distribution of this memo is unlimited.
This memo 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
Please check the lid-abstracts.txt listing contained in the
internet-drafts shadow directories on ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim) to learn the current status of any
Internet Draft.
Abstract
The Server Cache Synchronisation Protocol (SCSP) has been proposed as
a general mechanism for synchronising the databases of IP/ATM
Servers, such as those used by NHRP and MARS. This document specifies
an application of SCSP to allow multiple MARS entities to provide
fault tolerance to MARS Clusters.
1. Introduction.
[Editors note: this probably has holes you could drive a bus through.
if you drive buses and have an interest in this topic, offers of co-
authorship will be well received.]
Armitage Expires July 22nd, 1997 [Page 1]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
SCSP [1] being developed within the Internetworking over NBMA (ION)
working group as a general solution for synchronizing distributed
databases such as distributed Next Hop Servers [2] and MARSs [3].
Analysis of the possible distributed MARS scenarios is available in
the form of an Internet Draft submitted to the ION working group [4].
It is assumed that the reader understands the issues raised in [4]
regarding the Fault Tolerant model, and understands the services
provided by SCSP as described in [1]. {Whether the author does is
another matter entirely!}
In the current MARS model a Cluster consists of a number of MARS
Clients (IP/ATM interfaces in routers and/or hosts) utilizing the
services of a single MARS. This MARS is responsible for tracking the
IP group membership information across all Cluster members, and
providing on-demand associations between IP multicast group
identifiers (addresses) and specific sets of one or more ATM endpoint
addresses (for building ATM level multipoint forwarding paths). This
MARS is also responsible for allocating Cluster Member IDs (CMIs) to
Cluster members (inserted into outgoing data packets, to allow
reflected packet detection when Multicast Servers are placed in the
data path).
In [4] two different methods of using multiple MARS entities in a
single cluster are defined - the Fault Tolerant model and the Load
Sharing model. This document specifies the use of SCSP to provide the
Fault Tolerant model. [Actually, at this point it doesn't really do
either.] This model contains the following elements:
Active MARS
The single MARS serving the Cluster. It allocates
CMIs and tracks group membership changes by itself.
It is the sole entity that constructs replies to
MARS_REQUESTs.
Backup MARS
An additional MARS that tracks the information being
generated by the Active MARS. Cluster members may
re-register with a Backup MARS if the Active MARS
fails, and they'll assume the Backup has sufficient
up to date knowledge of the Cluster's state to take
the role of Active MARS.
Living Group
The set of Active MARS and current Backup MARS
entities. When a MARS entity dies it falls out of
the Living Group. When it restarts, it rejoins the
Living Group. Election of the Active MARS takes
place amongst the members of the Living Group.
Armitage Expires July 22nd, 1997 [Page 2]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
MARS Group
The total set of MARS entities configured to be part
of the distributed MARS. This is the combination of
the Living Group and 'dead' MARS entities that may
be currently dying, dead, or restarting. The list is
constructed in the following order {Active MARS,
Backup MARS, ... Backup MARS, dead MARS,.... dead
MARS}. If there are no 'dead' MARS entities, the
MARS Group and Living Group are identical.
SCSP assumes that the state held by a given server is contained in a
local object known as a cache. Keeping this cached state synchronized
among each server in a Server Group (SG) is what SCSP does, with the
use of alignment and update messages. Client State Update (CSU)
messages contain actual cache update data within individual Client
State Advertisement (CSA) records. These may be transmitted by a
server when a local cache state change occurs, or when solicited by a
neighboring server using a Client State Update Solicitation (CSUS)
message.
SCSP also defines an alignment phase where members of a Server Group
discover if their caches are out of alignment be comparing Client
State Advertisement Summary (CSAS) records. CSAS records are carried
in Client Alignment (CA) messages between neighboring servers.
The rest of this document is structured as follows:
[TBD]
2. MARS Sub-caches
For the purpose of applying SCSP to the distributed MARS scenario, we
subdivide the SCSP "cache" into a number of sub-caches, each of which
are kept independently synchronized. Any given server in an SG builds
up its notion of a distributed sub-cache's contents from the sum of
sub-cache information flooded by other servers in the SG.
Each MARS sub-cache has a separate sequence number space, allowing
sub-caches to be updated/flooded independently.
The sub-caches are derived from the following components of the
overall MARS state for a given Cluster:
Cluster membership list.
Cluster Member IDs.
Armitage Expires July 22nd, 1997 [Page 3]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
MCS (Multicast Server) membership list.
Absolute maximum and minimum group addresses for protocol being
supported.
Member map (hostmap) for each Layer 3 group.
MCS (Multicast Server) Servermap for each Layer 3 group.
Block-join map.
Redirect_map.
The Cluster membership list is the most fundamental object for a
MARS. It contains the ATM addresses of every cluster member, and
explicitly maps Cluster Member ATM addresses to Cluster Member IDs.
Both of these pieces of information will be combined into a single
CMI map sub-cache.
The MCS membership list is essential to enable construction of a
backup ServerControlVC by any one of the backup MARSs.
Each multicast group is represented by a membership map (hostmap)
sub-cache. Since a given multicast group may also have MCSs
registered to support it there is also a matching Servermap. Hostmaps
and Servermaps are treated as separate sub-caches. To simplify and
shorten the CSA Records, members of these maps are identified by
their Cluster Member IDs rather than enumerating their actual ATM
addresses. The key into a hostmap or servermap is the group's
multicast address.
Since hostmaps for a given group may be quite large, and most
MARS_JOIN/LEAVE events simply result in an incremental change to the
host map, two different types of CSA record will be defined. One will
represent the sub-cache in its entirety (for use when aligning
servers), and the second will have semantics to match the JOIN/LEAVE
event (allowing an incremental addition to, or deletion from, the
sub-cache associated with the specific multicast group). The same
will apply to the CSA records for Servermaps. SCSP has a mechanism
for segmenting large CSA Records across multiple CSU messages.
The block-join map represents all currently valid block MARS_JOINs
registered with the MARS. This allows the preceding, group-specific
hostmaps to be simplified. (The CSA Records representing the hostmap
for a given group only lists nodes that have issued a specific
single-group MARS_JOIN for that group.) Internally, the MARS builds
whatever database structure is required to ensure that replies to
MARS_REQUESTs, and general hole-punching activities, take the block-
Armitage Expires July 22nd, 1997 [Page 4]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
join map's contents into account.
The Redirect_map is the list of MARS entities a given server is
currently sending in its MARS_REDIRECT_MAP messages. The MARS Clients
consider this list to be the available Backup MARS entities. Its use
is TBD.
3. Client State Advertisement Summary (CSAS) records.
Client State Advertisement Summary (CSAS) records are carried within
SCSP Cache Alignment (CA) messages. They are used to inform one
server of another server's {sub}cache state without sending the
contents of the cache itself.
CSAS records have an 4 byte fixed header defined by SCSP, followed by
protocol specific fields (the Server Group ID - SGID - is contained
in the header of the CA messages that carry CSAS records).
For MARS use we add a 16 bit CSAS record (sub-cache) type field. The
first 6 bytes of each CSAS record are thus:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits CSAS record sub-cache type.
The CSA Sequence number indicates how recently the specified sub-
cache (csas$type) has been modified. This is used to determine
whether a re-alignment is required. Each CSAS also contains an
Originator ID field, which identfies which server in the SG is the
"owner" (originator) of the sub-cache information to which the CSAS
refers. For a MARS server group, the Orignator ID is the NBMA address
of the originating MARS.
The remaining bytes of the CSAS record are determined by csas$type.
The MARS CSAS record types are:
CSAS_CMI_MAP 1
CSAS_MCS_LIST 2
CSAS_HOST_MAP 3
CSAS_MCS_MAP 4
CSAS_BLOCK_JOINS 5
CSAS_REDIRECT_MAP 6
The specific formats of each CSAS record are described in the
following sub-sections.
Armitage Expires July 22nd, 1997 [Page 5]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
3.1 CSAS_CMI_MAP.
The complete CSAS Record looks like:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits Set to 1 (CSAS_CMI_MAP)
csas$orig_len 8 bits Length of csas$origin field.
csas$unused 8 bits unused.
csas$origin x octets Originator ID.
For this CSAS, the sequence number is incremented every time a new
cluster member registers, or an old one is considered to have died or
deregistered.
3.2 CSAS_MCS_LIST.
The complete CSAS Record looks like:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits Set to 2 (CSAS_MCS_LIST)
csas$orig_len 8 bits Length of csas$origin field.
csas$unused 8 bits unused.
csas$origin x octets Originator ID.
For this CSAS, the sequence number is incremented every time a new
MCS registers, or an old one is considered to have died or
deregistered.
3.3 CSAS_HOST_MAP.
The complete CSAS Record looks like:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits Set to 3 (CSAS_HOST_MAP)
csas$orig_len 8 bits Length of csas$origin field.
csas$group_len 8 bits Length of group address.
csas$origin x octets Originator ID.
csas$group y octets Hostmap entry's group address.
For this CSAS, the sequence number is incremented whenever a cluster
member joins or leaves the group specified by csas$group.
3.4 CSAS_MCS_MAP.
The complete CSAS Record looks like:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits Set to 4 (CSAS_MCS_MAP)
Armitage Expires July 22nd, 1997 [Page 6]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
csas$orig_len 8 bits Length of csas$origin field.
csas$group_len 8 bits Length of group address.
csas$origin x octets Originator ID.
csas$group y octets Servermap entry's group address.
For this CSAS, the sequence number is incremented whenever an MCS
joins or leaves the group specified by csas$group.
3.5 CSAS_BLOCK_JOINS.
The complete CSAS Record looks like:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits Set to 5 (CSAS_BLOCK_JOINS)
csas$orig_len 8 bits Length of csas$origin field.
csas$unused 8 bits unused.
csas$origin x octets Originator ID.
For this CSAS, the sequence number is incremented whenever a block
MARS_JOIN, or matching block MARS_LEAVE, occurs.
3.6 CSAS_REDIRECT_MAP.
The complete CSAS Record looks like:
csas$sequence 32 bits CSA Sequence Number.
csas$type 16 bits Set to 6 (CSAS_REDIRECT_MAP)
csas$orig_len 8 bits Length of csas$origin field.
csas$unused 8 bits unused.
csas$origin x octets Originator ID.
For this CSAS, the sequence number is incremented whenever the local
server modifies the list of MARS entities in its MARS_REDIRECT_MAP
list.
4. Client State Advertisement (CSA) Records.
CSA records have an 12 byte fixed header defined by SCSP, followed by
protocol specific fields. For MARS use we add a 16 bit CSA record
(sub-cache) type field. The first 14 bytes of each CSAS record are
thus:
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL.
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits CSA Record sub-cache type.
Armitage Expires July 22nd, 1997 [Page 7]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
The CSA Sequence number indicates how recently the specified sub-
cache (csa$type) has been modified. This is used to determine whether
a re-alignment is required. The Server Group ID identifies an
instance of a Server Group. Since Server Groups will exist on a per-
protocol basis (IPv4, IPv6, etc) the csa$sgid field implicitly
identifies the formats of any 'group' address fields within the CSA
Records.
Each CSA also contains an Originator ID field, which identfies which
server in the SG is the "owner" (originator) of the sub-cache
information to which the CSA refers. In the case of MARS server
groups, the originator is identified by its ATM address (cf. the NHRP
case where the 'protocol address' is used). The format of the ATM
address is irrelevant - the originator field is simply an
uninterpreted octet string used for pattern matching.
The remaining bytes of the CSA record are determined by csa$type.
To match the CSAS records, the following set of CSA record types are
defined:
CSA_CMI_MAP 1
CSA_MCS_LIST 2
CSA_HOST_MAP 3
CSA_MCS_MAP 4
CSA_BLOCK_JOINS 5
CSA_REDIRECT_MAP 6
In addition, to allow indication of incremental updates to some of
the sub-caches, matching
CSA_CMI_MAP_JOIN 128
CSA_CMI_MAP_LEAVE 129
CSA_MCS_LIST_JOIN 130
CSA_MCS_LIST_LEAVE 131
CSA_HOST_MAP_JOIN 132
CSA_HOST_MAP_LEAVE 133
CSA_MCS_MAP_JOIN 134
CSA_MCS_MAP_LEAVE 135
(csa$type values in the range 1 to 127 correspond to entire sub-
caches, whilst the range 128 to 512 are allocated to incremental
sub-cache updates.)
The amount of information carried by a specific CSA_HOST_MAP or
CSA_CMI_MAP may exceed the size of a link layer PDU. SCSP allows a
large CSA Record to be fragmented across a number of CSU Request
messages.
Armitage Expires July 22nd, 1997 [Page 8]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
4.1 CSA_CMI_MAP.
This CSA Record carries the entire membership of the current cluster,
along with the Cluster Member IDs (CMIs) assigned by the MARS they
registered with. These CMIs are then used as a short-form
representation of the actual cluster members to compress the size of
subsequent CSA_HOST_MAP messages.
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits Set to 1 (CSA_CMI_MAP).
csa$orig_len 8 bits Length of csa$origin.
csa$unused 8 bits unused.
csa$cnum 16 bits Number of entries in this CSA (N).
csa$thtl 8 bits Type and length of ATM addresses.
csa$tstl 8 bits Type and length of ATM sub-addresses.
csa$origin x octets Originator's NBMA address.
csa$atmaddr.1 q octets ATM address of member 1.
csa$subaddr.1 r octets ATM sub-address of member 1.
csa$cmi.1 16 bits Cluster Member ID for entry 1.
[..etc..]
csa$atmaddr.N q octets ATM address of member N.
csa$subaddr.N r octets ATM sub-address of member N.
csa$cmi.N 16 bits Cluster Member ID for entry N.
4.2 CSA_MCS_LIST.
This CSA Record carries the entire list of currently registered
Multicast Servers (MCSs). Each MCS is also assigned an internal ID by
the MARS they registered with - this is used to compress the size of
subsequent CSA_MCS_MAP messages.
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits Set to 2 (CSA_MCS_LIST).
csa$orig_len 8 bits Length of csa$origin.
csa$unused 8 bits unused.
csa$cnum 16 bits Number of entries in this CSA (N).
csa$thtl 8 bits Type and length of ATM addresses.
csa$tstl 8 bits Type and length of ATM sub-addresses.
csa$origin x octets Originator's NBMA address.
csa$atmaddr.1 q octets ATM address of MCS 1.
csa$subaddr.1 r octets ATM sub-address of MCS 1.
Armitage Expires July 22nd, 1997 [Page 9]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
csa$cmi.1 16 bits Internal MCS ID for entry 1.
[..etc..]
csa$atmaddr.N q octets ATM address of member N.
csa$subaddr.N r octets ATM sub-address of member N.
csa$cmi.N 16 bits Internal MCS ID for entry N.
4.3 CSA_HOST_MAP
This CSA Record carries the list of cluster members who have joined a
specified group using a single-group MARS_JOIN operation. The Cluster
Member IDs are used to represent each group member with each CSA
Record fragment. A recipient MARS uses this CSA in conjunction with
the current Cluster membership list to derive the actual ATM
addresses of group members.
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits Set to 3 (CSA_HOST_MAP).
csa$orig_len 8 bits Length of csa$origin.
csa$group_len 8 bits Length of csa$group.
csa$cnum 16 bits Number of entries in this fragment (N).
csa$origin x octets Originator's NBMA address.
csa$group y octets Multicast group's protocol address.
csa$cmi.1 16 bits Cluster Member ID for entry 1.
csa$cmi.2 16 bits Cluster Member ID for entry 2.
[..etc..]
csa$cmi.N 16 bits Cluster Member ID for entry N.
4.4 CSA_MCS_MAP
This CSA Record carries the list of MCSs who have joined to support a
specified group. The internal MCS IDs from prior CSA_MCS_LIST CSA
Records are used to represent each MCS. A recipient MARS uses this
CSA in conjunction with the current MCS membership list to derive the
actual ATM addresses of group members.
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits Set to 4 (CSA_MCS_MAP).
csa$orig_len 8 bits Length of csa$origin.
csa$group_len 8 bits Length of csa$group.
Armitage Expires July 22nd, 1997 [Page 10]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
csa$cnum 16 bits Number of entries in this fragment (N).
csa$origin x octets Originator's NBMA address.
csa$group y octets Multicast group's protocol address.
csa$cmi.1 16 bits Internal MCS ID for entry 1.
csa$cmi.2 16 bits Internal MCS ID for entry 2.
[..etc..]
csa$cmi.N 16 bits Internal MCS ID for entry N.
4.5 CSA_BLOCK_JOINS
This CSA Record carries the list of Cluster Members who have joined
blocks of the layer 3 group address space. The Cluster Member IDs
from prior CSA_CMI_MAP CSA Records are used to represent each cluster
member and associate it with a specific <min,max> pair.
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits Set to 5 (CSA_BLOCK_JOINS).
csa$orig_len 8 bits Length of csa$origin.
csa$group_len 8 bits Lengths of csa$min and csa$max fields.
csa$cnum 16 bits Number of entries in this fragment (N).
csa$origin x octets Originator's NBMA address.
csa$min.1 y octets <min> group address of block 1.
csa$max.1 y octets <max> group address of block 1.
csa$cmi.1 16 bits Cluster Member ID for block 1.
[..etc..]
csa$min.N y octets <min> group address of block N.
csa$max.N y octets <max> group address of block N.
csa$cmi.N 16 bits Cluster Member ID for block N.
4.6 CSA_REDIRECT_MAP
This CSA Record carries the list the source server is using to
generate MARS_REDIRECT_MAP messages.
csa$fragment 16 bits F/Fragment Number.
csa$ttl 16 bits TTL
csa$sequence 32 bits CSA Sequence Number.
csa$sgid 32 bits Server Group ID.
csa$type 16 bits Set to 6 (CSA_REDIRECT_MAP).
csa$orig_len 8 bits Length of csa$origin.
csa$unused 8 bits unused.
csa$cnum 16 bits Number of entries in this fragment (N).
Armitage Expires July 22nd, 1997 [Page 11]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
csa$thtl 8 bits Type and length of ATM addresses.
csa$tstl 8 bits Type and length of ATM sub-addresses.
csa$origin x octets Originator's NBMA address.
csa$atmaddr.1 q octets ATM address of member 1.
csa$subaddr.1 r octets ATM sub-address of member 1.
[..etc..]
csa$atmaddr.N q octets ATM address of member N.
csa$subaddr.N r octets ATM sub-address of member N.
4.7 Incremental update CSA Records.
The incremental update CSA Records types use the same format as
alignment CSA Records, except that only a single entry (of whatever
information) is passed.
Two examples:
CSA_CMI_MAP_LEAVE is coded as a CSA_CMI_MAP but with csa$type =
129, csa$cnum = 1, and only a single ATM address and CMI pair
provided.
CSA_HOST_MAP_JOIN is coded as a CSA_HOST_MAP but with csa$type =
132, csa$cnum = 1, and only a single CMI is provided (indicating
the specific host that has now become a group member).
The CSA Sequence number space for incremental update CSAs is the same
space used by alignment CSAs for the identfied sub-cache.
Alignment updates (containing a full version of an identified sub-
cache) are always accepted by a server.
Incremental update CSAs are are accepted as updates to the local
server's copy of the specified sub-cache, from the specified
Originator ID, only if they arrive with a larger (newer) CSA Sequence
number than the existing local entry.
Incremental update CSAs are discarded if they arrive with a smaller
(older) CSA Sequence number than the local server already has for the
specified sub-cache, from the specified Originator ID.
[The rest of this explanation is TBD.]
Armitage Expires July 22nd, 1997 [Page 12]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
5. Use of CSA Records.
The most important sub-caches for a MARS to exchange are the
CSA_CMI_MAP and CSA_MCS_LIST. Without alignment of these sub-caches,
members of the Server Group cannot interpret the other CSA Record
types, which identify nodes using ID values supplied in the
CSA_CMI_MAP and CSA_MCS_LIST records.
MARS_JOIN/LEAVE events are propagated by issuing CSA_HOST_MAP_JOIN
and CSA_HOST_MAP_LEAVE CSA Records in CSU messages.
There are no CSAS Record types equivalent to the incremental sub-
cache update CSA Record types. The semantics of the CSAS Record in
the CA message is to indicate the state of an entire sub-cache. It
would make no sense to try and discover (or convey) an 'incremental
state' of a sub-cache.
As a consequence, incremental sub-cache update CSA Record types SHALL
only be sent in un-solicited CSU Request messages. Client State
Update Solicit (CSUS) messages SHALL only trigger the delivery of CSA
Records containing entire sub-caches as atomic units.
Security Consideration
Security consideration are not addressed in this document.
Acknowledgments
To Liptons, for making the tea that keeps me going.
Author's Address
Grenville Armitage
Bellcore, 445 South Street
Morristown, NJ, 07960
USA
Email: gja@bellcore.com
Ph. +1 201 829 2635
References
[1] J. Luciani, G. Armitage, J. Halpern, "Server Cache
Synchronization Protocol (SCSP) - NBMA", INTERNET DRAFT, draft-ietf-
Armitage Expires July 22nd, 1997 [Page 13]
Internet Draft <draft-armitage-ion-distmars-spec-00>January 22nd, 1997
ion-scsp-00.txt, November 1996.
[2] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)",
INTERNET DRAFT, draft-ietf-rolc-nhrp-10.txt, October 1996.
[3] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM
Networks.", Bellcore, RFC 2022, November 1996.
[4] G. Armitage, "Redundant MARS architectures and SCSP.", INTERNET
DRAFT, draft-armitage-ion-mars-scsp-02.txt, November 1996.
Armitage Expires July 22nd, 1997 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 23:05:43 |