rfc2121.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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: [e-mail]
   Phone [phone]


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]