1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 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]
|