doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc2121.txt b/doc/rfc/rfc2121.txt
new file mode 100644
index 0000000..4cf509c
--- /dev/null
+++ b/doc/rfc/rfc2121.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      G. Armitage
+Request for Comments: 2121                                    Bellcore
+Category: Informational                                     March 1997
+
+
+                   Issues affecting MARS Cluster Size
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   IP multicast over ATM currently uses the MARS model [1] to manage the
+   use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope
+   of any given MARS services is the MARS Cluster - typically the same
+   as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are
+   usually architected with unicast routing and forwarding issues
+   dictating the sizes of individual LISes. However, as IP multicast is
+   deployed as a service, the size of a LIS will only be as big as a
+   MARS Cluster can be. This document provides a qualitative look at the
+   issues constraining a MARS Cluster's size, including the impact of VC
+   limits in switches and NICs, geographical distribution of cluster
+   members, and the use of VC Mesh or MCS modes to support multicast
+   groups.
+
+1. Introduction
+
+   A MARS Cluster is the set of IP/ATM interfaces that are willing to
+   engage in direct, ATM level pt-mpt SVCs to perform IP multicast
+   packet forwarding [1]. Each IP/ATM interface (a MARS Client) must
+   keep state information regarding the ATM addresses of each leaf node
+   (recipient) of each  pt-mpt SVC it has open. In  addition, each MARS
+   Client receives MARS_JOIN and MARS_LEAVE messages from the MARS
+   whenever there is a requirement that Clients around the Cluster need
+   to update their pt-mpt SVCs for a given IP multicast group.
+
+   The definition of Cluster 'size' can mean two things - the number of
+   MARS Clients using a given MARS, and the geographic distribution of
+   MARS Clients. The number of MARS Clients in a Cluster impacts on the
+   amount of state information any given client may need to store while
+   managing  outgoing  pt- mpt SVCs. It also impacts on the average rate
+   of JOIN/LEAVE traffic that is propagated by the MARS on
+   ClusterControlVC, and the number of pt-mpt VCs that may need
+   modification each time a MARS_JOIN or MARS_LEAVE appears on
+   ClusterControlVC.
+
+
+
+Armitage                     Informational                      [Page 1]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+   The geographic distribution of clients affects the latency between a
+   client issuing a MARS_JOIN, and it finally being added onto the pt-
+   mpt VCs of the other MARS Clients transmitting to the specified
+   multicast group. (This latency is made up of both the time to
+   propagate the MARS_JOIN, and the delay in the underlying ATM cloud's
+   reaction to the subsequent ADD_PARTY messages.)
+
+   When architecting an IP/ATM network it is important to understand the
+   worst case scaling limits applicable to your Clusters. This document
+   provides a primarily qualitative look at the design choices that
+   impose the most dramatic constraints on Cluster size. Since the focus
+   is on worst-case scenarios, most of the analysis will assume
+   multicast groups that are VC Mesh based and have all cluster members
+   as sources and receivers. Engineering using the worst-case boundary
+   conditions, then applying optimisations such as Multicast Servers
+   (MCS), provides the Cluster with a margin of safety.  It is hoped
+   that more detailed quantitative analysis of Cluster sizing limits
+   will be prompted by this document.
+
+   Section 2 comments on the VC state requirements of the MARS model,
+   while Sections 3 and 4 identify the group change processing load and
+   latency characteristics of a cluster as a function of its size.
+   Section 5 looks at how Multicast Routers (both conventional and
+   combination router/switch architectures) increase the scale of a
+   multicast capable IP/ATM network. Finally, Section 6 discusses how
+   the use of Multicast Servers (MCS) might impact on the worst case
+   Cluster size limits.
+
+
+2. VC state limitations.
+
+   Two characteristics of ATM NICs and switches will limit the number of
+   members a Cluster may contain. They are:
+
+      The maximum number of VCs that can be originated from, or
+      terminate on, a port (VCmax).
+
+      The maximum number of leaf nodes supportable by a root node
+      (LEAFmax).
+
+   We'll assume that the MARS node has similar VCmax and LEAFmax values
+   as Cluster members.  VCmax affects the Cluster size because of the
+   following:
+
+      The MARS terminates a pt-pt control VC from each cluster member,
+      and originates a VC for ClusterControlVC and ServerControlVC.
+
+
+
+
+
+Armitage                     Informational                      [Page 2]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+      When a multicast group is VC Mesh based, a group member terminates
+      a VC from every sender to the group, per group.
+
+      When a multicast group is MCS based, the MCS terminates a VC from
+      every sender to the group.
+
+   LEAFmax affects the Cluster size because of the following:
+
+      ClusterControlVC from the MARS. It has a leaf node per cluster
+      member (MARS Client).
+
+      Packet forwarding SVCs out of each MARS Client for each IP
+      multicast group being sent to. It has a leaf node for each group
+      member when a group is VC Mesh based.
+
+      Packet forwarding SVCs out of each MCS for each IP multicast group
+      being sent to. It has a leaf node for each group member when a
+      group is MCS based.
+
+   If we have N cluster members, and M multicast groups active (using VC
+   Mesh mode, and densely populated - all receivers are senders), the
+   following observations may be made:
+
+      ClusterControlVC has N leaf nodes, so
+            N <= LEAFmax.
+
+      The MARS terminates a pt-pt VC from each cluster member, and
+      originates ClusterControlVC and ServerControlVC, so
+            (N+2) <= VCmax.
+
+      Each Cluster Member sources 1 VC per group, terminates (N-1) VC
+      per group, originates a pt-pt VC to the MARS, and terminates 1 VC
+      as a leaf on ClusterControlVC, so
+            (M*N) + 2 <= VCmax.
+
+      The VC sourced by each Cluster member per group goes to all other
+      cluster members, so
+            (N-1) <= LEAFmax.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Armitage                     Informational                      [Page 3]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+   Since all the above conditions must be simultaneously true, we can
+   see that the most constraining requirement is either:
+
+      (M*N) + 2 <= VCmax.
+
+   or
+
+      N <= LEAFmax.
+
+   The limit involving VCmax is fundamentally controlled by the VC
+   consumption of group members using a VC Mesh for data forwarding,
+   rather than the termination of pt-pt control VCs on the MARS. (It is
+   in practice going to be very dependent on the multicast group
+   membership distributions within the cluster.)
+
+   The LEAFmax limit comes from ClusterControlVC, and is independent of
+   the density of group members (or the ratios of senders to receivers)
+   for active multicast groups within the cluster.
+
+   Under UNI 3.0/3.1 the most obvious limit on LEAFmax is 2^15 (the leaf
+   node ID is 15 bits wide).  However, the signaling driver software for
+   most ATM NICs may impose a limit much lower than this - a function of
+   how much per-leaf node state information they need to store (and are
+   capable of storing) for pt-mpt SVCs.
+
+   VCmax is constrained by the ATM NIC hardware (for available
+   segmentation or reassembly instances), or by the VC capacity of the
+   switch port that the NIC is attached to.  VCmax will be the smaller
+   of the two.
+
+   A MARS Client may impose its own state storage limitations, such that
+   the combined memory consumption of a MARS Client and the ATM NIC's
+   driver in a given host limits both LEAFmax and VCmax to values lower
+   than the ATM NIC alone might have been able to support.
+
+   It may be possible to work around LEAFmax limits by distributing the
+   leaf nodes across multiple pt-mpt SVCs operating in parallel.
+   However, such an approach requires further study, and doesn't solve
+   the VCmax limitation associated with a node terminating too many VCs.
+
+   A related observation can also be made that the number of MARS
+   Clients in a Cluster may be limited by the memory constraints of the
+   MARS itself. It is required to keep state on all the groups that
+   every one of its MARS Clients have joined. For a given memory limit,
+   the maximum number of MARS Clients must drop if the average number of
+   groups joined per Client rises. Depending on the level of group
+   memberships, this limitation may be more severe than LEAFmax.
+
+
+
+
+Armitage                     Informational                      [Page 4]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+3. Signaling load.
+
+   In any given cluster there will be an 'ambient' level of
+   MARS_JOIN/LEAVE activity. The dynamic characteristics of this
+   activity will depend on the types of multicast applications running
+   within the cluster. For a constant relative distribution of multicast
+   applications we can assume that, as the number of MARS Clients in a
+   given cluster rises, so does the ambient level of MARS_JOIN/LEAVE
+   activity. This increases the average frequency with which the MARS
+   processes and propagates MARS_JOIN/LEAVE messages.
+
+   The existence of MARS_JOIN/LEAVE traffic also has a consequential
+   impact on signaling activity at the ATM level (across the UNI and
+   {P}NNI boundaries). For groups that are VC Mesh supported, each
+   MARS_JOIN or MARS_LEAVE propagated on ClusterControlVC will result in
+   an ADD_PARTY or DROP_PARTY message sent across the UNIs of all MARS
+   Clients that are transmitting to a given group. As a cluster's
+   membership increases, so does the average number of MARS Clients that
+   trigger ATM signaling activity in response to MARS_JOIN/LEAVEs.
+
+   The size of a cluster needs to be chosen to provide some level of
+   containment to this ambient level of MARS and UNI/NNI signaling.
+
+   Some refinements to the MARS Client behaviour may also be explored to
+   smooth out UNI signaling transients. MARS Clients are currently
+   required to initiate revalidation of group memberships only when the
+   Client next sends a packet to an invalidated group SVC. A Client
+   could apply a similar algorithm to decide when it should issue
+   ADD_PARTYs. For example, after seeing a MARS_JOIN, wait until it
+   actually has a packet to send, send the packet, then initiate the
+   ADD_PARTY. As a result actively transmitting Clients would update
+   their SVCs sooner than intermittently transmitting Clients.
+
+
+4. Group change latencies
+
+   The group change latency can be defined as the time it takes for all
+   the senders to a group to have correctly updated their forwarding
+   SVCs after a MARS_JOIN or MARS_LEAVE is received from the MARS. This
+   is affected by both the number of Cluster members and the
+   geographical distribution of Cluster members. (Groups that are MCS
+   based create the lowest impact when new members join or leave, since
+   only the MCS needs to update its forwarding SVC.) Under some
+   circumstances, especially modelling or simulation environments, group
+   change latencies within a cluster may be an important characteristic
+   to control.
+
+
+
+
+
+Armitage                     Informational                      [Page 5]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+   As noted in the previous section, the ADD_PARTY/DROP_PARTY signaling
+   load created by membership changes in VC Mesh based groups goes up as
+   the number of cluster members rises (assuming worst case scenario of
+   each cluster member being a sender to the group). As the UNI load
+   rises, the ATM network itself may start delivering slower processing
+   of the requested events.
+
+   Wide geographic distribution of Cluster members also delays the
+   propagation of MARS_JOIN/LEAVE and ATM UNI/NNI messages. The further
+   apart various members are, the longer it takes for them to receive
+   MARS_JOIN/LEAVE traffic on ClusterControlVC, and the longer it takes
+   for the ATM network to react to ADD_PARTY and DROP_PARTY requests. If
+   the long distance paths are populated by many ATM switches,
+   propagation delays due to per-switch processing will add
+   substantially to delays due to the speed of light.
+
+   (Unfortunately, mechanisms for smoothing out the transient ATM
+   signaling load described in section 3 have a consequence of
+   increasing the group change latency, since the goal is for some of
+   the senders to deliberately delay updating their forwarding SVCs.
+   This is an area where the system architect needs to make a
+   situation-specific trade-off.)
+
+   It is not clear what affect the internal processing of the MARS
+   itself has on group change latency, and how this might be impacted by
+   cluster size.  A component of the MARS processing latency will depend
+   on the specific database implementation and search algorithms as much
+   as on the number of group members for the group being modified at any
+   instant. Since the maximum number of group members for a given group
+   is equal to the number of cluster members, there will be an indirect
+   (even if small) relationship between worst case MARS processing
+   latencies and cluster size.
+
+
+5. Large IP/ATM networks using Mrouters
+
+   Building a large scale, multicast capable IP over ATM network is a
+   tradeoff between Cluster sizes and numbers of Mrouters. For a given
+   number of hosts, the number of clusters goes up as individual
+   clusters shrink. Since Mrouters are the topological intersections
+   between clusters, the number of Mrouters rises as the size of
+   individual clusters shrinks. (The actual number of Mrouters depends
+   largely on the logical IP topology you choose to implement, since a
+   single physical Mrouter may interconnect more than two Clusters at
+   once.) It is a local deployment question as to what the optimal mix
+   of Clusters and Mrouters will be.
+
+
+
+
+
+Armitage                     Informational                      [Page 6]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+   Currently two broad classes of Mrouters may be identified:
+
+      Those that originate unique VCs into target Clusters, and
+      forward/interleave data at the IP packet level (the Conventional
+      Mrouter).
+
+      Those that originate unique VCs into target Clusters, but create
+      internal, cell level 'cut through' paths between VCs from
+      different Clusters (e.g. the Cell Switch Router).
+
+   How these Mrouters establish and manage the associations of VCs to IP
+   traffic flows is beyond the scope of this document.  However, it is
+   worth looking briefly at their impact on VC consumption and ATM
+   signaling load.
+
+5.1 Impact of the Conventional Mrouter
+
+   A conventional Mrouter acts as an aggregation point for both
+   signaling and data plane loads. It hides host specific group
+   membership changes in one cluster from senders within other clusters,
+   and protects group members (receivers) in one cluster from having to
+   be leaf nodes on SVCs from senders in other Clusters.
+
+   When acting as an ingress point into a cluster, a conventional
+   Mrouter establishes a single forwarding SVC for IP packets.  This
+   single SVC carries data from other clusters interleaved at the IP
+   packet level. Only this single SVC needs to be modified in response
+   to group memberships changes within the target cluster.  As a
+   consequence, there is no need for sources in other clusters to be
+   aware of, or react to, MARS_JOIN/LEAVE traffic in the target cluster.
+   (The consequential UNI signaling load identified in section 3 is also
+   localized within the target Cluster.)
+
+   MARS Clients within the target cluster also benefit from this data
+   path aggregation because they terminate only one SVC from the Mrouter
+   (per group), rather than multiple SVCs originating from actual
+   senders in other Clusters.
+
+   Conventional Mrouters help control the limiting factors described in
+   sections 2, 3, and 4.  A hypothetical 10000 node Cluster could be
+   broken into two 5000 node Clusters, or four 2500 node Clusters, etc,
+   to reduce VC consumption. Or you might have 200 nodes of the overall
+   10000 that are known to join and leave groups rapidly, whilst the
+   other 9800 are fairly steady - so you deploy clusters of 200, 2500,
+   2500, 2500, 2300 hosts respectively.
+
+
+
+
+
+
+Armitage                     Informational                      [Page 7]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+5.2. Impact of the Cell Switch Router (CSR).
+
+   Another class of Mrouter, the Cell Switch Router (CSR) attempts to
+   utilize IP level flow information to dynamically manage the switching
+   of data through the device below the IP level.  Once the CSR has
+   identified a flow of IP traffic, and associated it with an inbound
+   and outbound SVC, it begins to function as an ATM cell level device
+   rather than a packet level device.
+
+   Even when operating in this mode the CSR isolates attached Clusters
+   from each other's MARS_JOIN/LEAVE activities, in the same manner as a
+   conventional Mrouter. This occurs because the CSR manages its
+   forwarding SVCs just like a normal MARS Client - responding to
+   MARS_JOIN/LEAVE messages within the target cluster by updating the
+   pt-mpt trees rooted on its own ATM ports.
+
+   However, since AAL5 AAL_SDUs cannot be interleaved at the cell level
+   on a single SVC, a CSR cannot simultaneously perform cell level cut-
+   through and aggregate the IP packet flows from multiple senders onto
+   a single SVC into a target Cluster. As a result, the CSR must
+   construct a separate forwarding SVC into a target cluster for each
+   SVC it is a leaf of in a source Cluster (to to ensure that cells from
+   individual sources are not interleaved prior to reaching the re-
+   assembly engines of the group members in the target cluster).
+
+   Interestingly, the UNI signaling load offered within the target
+   Cluster by the CSR is potentially greater than that of a conventional
+   Mrouter. If there are N senders in the source Cluster, the CSR will
+   have built N identical pt-mpt SVCs out to the group members within
+   the target Cluster. If a new MARS_JOIN is issued within the target
+   Cluster, the CSR must issue N ADD_PARTYs to update the N SVCs into
+   the target Cluster. (Under similar circumstances a conventional
+   Mrouter would have issued only one ADD_PARTY for its single SVC into
+   the target Cluster.)
+
+   Thus, without the ability to provide internal cut-through forwarding
+   with AAL_SDU boundaries intact, the CSR only provides for the
+   isolation of MARS_JOIN/LEAVE traffic within clusters. It cannot
+   provide the data path aggregation of a conventional Mrouter.
+
+
+
+
+
+
+
+
+
+
+
+
+Armitage                     Informational                      [Page 8]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+6. The impact of Multicast Servers (MCSs)
+
+   Since the focus of this document is on worst-case scenarios, most of
+   the analysis has assumed multicast groups that are VC Mesh based and
+   have all cluster members as sources and receivers. The impact of
+   using an MCS to support a multicast group can be dramatic in the
+   context of the group's resource consumption, but less so in the
+   over-all context of cluster size limits.
+
+   The intra-cluster, per group impact of an MCS is somewhat analogous
+   to the inter-cluster impact of a conventional Mrouter. The MCS
+   aggregates the data flows (only 1 SVC terminates on each group
+   member, independent of the number of senders), and isolates
+   MARS_JOIN/LEAVE traffic (which is shifted to ServerControlVC rather
+   than ClusterControlVC). The resulting UNI signaling traffic and load
+   is reduced too, as only the forwarding SVC out of the MCS needs to be
+   modified for every membership change in the MCS supported group.
+
+   Deploying a mixture of MCS and VC Mesh based groups will certainly
+   improve resource utilization. However, the actual extent of the
+   improvements (and consequently how large the cluster can be made)
+   will depend greatly on the dynamics of your typical applications and
+   which characteristics from sections 2, 3, and 4 are your primary
+   limitations.
+
+   For example, if VCmax or LEAFmax (section 2) are primary limitations,
+   one must keep in mind that each MCS itself suffers the same NIC
+   limits as the MARS and MARS Clients. Even though using an MCS
+   dramatically reduces the number of VCs per MARS Client per group,
+   each MCS still needs to terminate 1 SVC per sender - potentially up
+   to 1 SVC from each Cluster member.  (This may become 1 SVC per member
+   per group if the MCS supports multiple groups simultaneously.)
+
+   Assume we have a Cluster where every group is MCS based, each MCS
+   supports only one group, and both VCmax and LEAFmax apply equally to
+   MCS nodes as MARS and MARS Clients nodes.  If we have N cluster
+   members, M groups, and all receivers are senders for a given MCS
+   supported group, the following observations may be made:
+
+      Each MCS forwarding SVC has N leaf nodes, so
+            N <= LEAFmax.
+
+      Each MCS terminates an SVC from N senders, originates 1 SVC
+      forwarding path, originates a pt-pt control SVC to the MARS, and
+      terminates 1 SVC as a leaf on ServerControlVC, so
+            N + 3 <= VCmax.
+
+
+
+
+
+Armitage                     Informational                      [Page 9]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+      MARS ClusterControlVC has N leaf nodes, so
+            N <= LEAFmax.
+
+      MARS ServerControlVC has M leaf nodes, so
+            M <= LEAFmax.
+
+      The MARS terminates a pt-pt VC from each cluster member, a pt-pt
+      VC from each MCS, originates ClusterControlVC, and originates
+      ServerControlVC, so
+            N + M + 2 <= VCmax.
+
+      Each Cluster Member sources 1 VC per group, terminates 1 VC per
+      group, originates a pt-pt VC to the MARS, and terminates 1 VC as a
+      leaf on ClusterControlVC, so
+            2*M + 2 <= VCmax.
+
+   Since all the above conditions must be simultaneously true, we can
+   see that the most constraining requirements are:
+
+      N + M + 2 <= VCmax (if M <= N)
+
+      2*M + 2 <= VCmax (if M >= N)
+   or
+      N <= LEAFmax.
+
+   (Assuming that in general M+2 > 3, so the VCmax constraint at each
+   MCS is not a limiting factor.)
+
+   We can get a feel for the relative impacts of VC Mesh groups vs MCS
+   based groups by considering a cluster where M1 represents the number
+   of VC Mesh based groups, and M2 represents the number of MCS based
+   groups. Again we assume worst case group density (all N cluster
+   members are group members, all receivers are also senders).
+
+   As noted in section 2, the VCmax constraint in VC Mesh mode comes
+   from each MARS Client, and is:
+
+      N*M1 <= VCmax - 2
+
+   For the MCS case we have two scenarios, M2 <= N and M2 >= N.
+
+   If M2 <= N we can see the VC consumption by VC Mesh based groups will
+   become the applicable constraint on cluster size N when:
+
+      N + M2 <= N*M1
+   i.e.
+      M1 >= 1 + (M2/N)
+
+
+
+
+Armitage                     Informational                     [Page 10]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+   Thus, if there is more than 1 VC Mesh based group, and less MCS based
+   groups than cluster members (M2 < N), the constraint on cluster size
+   is dictated by the VC Mesh characteristics: N*M1 <= VCmax - 2. (If M2
+   == N, then there may be 2 VC Mesh based groups before the VC Mesh
+   characteristics are the dictating factor.)
+
+   Now, if M2 > N (more MCS based groups, and hence MCSes, than cluster
+   members) the calculation is more complex since in this case VCmax at
+   the MARS Client is the limiting parameter for both VC Mesh and MCS
+   cases. The limit becomes:
+
+      N*M1 + 2*M2 <= VCmax - 2
+
+   However, on face value this is an odd situation anyway, since it
+   implies more MCS entities than hosts or router interfaces into the
+   cluster (given the assumption of one group per MCS).
+
+   The impact of MCS entities that simultaneously support multiple
+   groups is left for future study.
+
+
+7. Open Issues
+
+   There is a wide range of qualitative analysis that can be extracted
+   from typical MARS deployment scenarios. This document does not
+   attempt to develop any numerical models for VC consumptions, end to
+   end latencies, etc.
+
+
+8. Conclusion
+
+   This document has provided a high level, qualitative overview of the
+   parameters affecting the size of MARS Clusters.  Limitations on the
+   number of leaf nodes a pt-mpt SVC may support, sizes of the MARS
+   database, propagation delays of MARS and UNI messages, and the
+   frequency of MARS and UNI control messages are all identified as
+   issues that will constrain Clusters.  Conventional Mrouters are
+   identified as useful aggregators of IP multicast traffic and
+   signaling information.  Cell Switch Routers are noted to offer only
+   some of the aggregation attributes of conventional Mrouters.  Large
+   scale IP multicasting over ATM requires a combination of Mrouters and
+   appropriately sized MARS Clusters. Finally, it has been shown that in
+   a simple cluster where there are less MCS based groups than cluster
+   members, two or more VC Mesh based groups are sufficient to render
+   the use of Multicast Servers irrelevant to the worst case cluster
+   size limit.
+
+
+
+
+
+Armitage                     Informational                     [Page 11]
+
+RFC 2121           Issues affecting MARS Cluster Size         March 1997
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Acknowledgments
+
+   Thanks must go to Rajesh Talpade (Georgia Tech) for specific input on
+   aspects of the VC Mesh vs MCS tradeoffs, and Joel Halpern (Newbridge)
+   for general input on the document's focus.
+
+
+Author's Address
+
+   Grenville Armitage
+   Bellcore, 445 South Street
+   Morristown, NJ, 07960
+   USA
+
+   EMail: gja@thumper.bellcore.com
+   Phone +1 201 829 2635
+
+
+References
+
+   [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
+   Networks.", Bellcore, RFC 2022, November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Armitage                     Informational                     [Page 12]
+