As per Relevance of the word establish, we have this rfc below:
Network Working Group G.
Request for Comments: 2191 Lucent
Category: Informational September 1997
VENUS - Very Extensive Non-Unicast
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The MARS model (RFC2022) provides a solution to intra-LIS
multicasting over ATM, establishing and managing the use of ATM pt
mpt SVCs for IP multicast packet forwarding. Inter-LIS
forwarding is achieved using Mrouters, in a similar manner to
the "Classical IP over ATM" model uses Routers to inter-connect
for unicast traffic. The development of unicast IP
mechanisms (e.g. NHRP) has led some people to request
development of a Multicast equivalent. There are a number
different approaches. This document focuses exclusively on
problems associated with extending the MARS model to cover
clusters or clusters spanning more than one subnet. It describes
hypothetical solution, dubbed "Very Extensive NonUnicast Service
(VENUS), and shows how complex such a service would be. It is
noted that VENUS ultimately has the look and feel of a single,
cluster using a distributed MARS. This document is being issued
help focus ION efforts towards alternative solutions for
ATM level multicast connections between LISes
1.
The classical model of the Internet running over an ATM
consists of multiple Logical IP Subnets (LISs) interconnected by
Routers [1]. The evolving IP Multicast over ATM solution (the "
model" [2]) retains the classical model. The LIS becomes a "
Cluster", and Clusters are interconnected by conventional
Multicast routers (Mrouters).
The development of NHRP [3], a protocol for discovering and
unicast forwarding paths that bypass IP routers, has led to
calls for an IP multicast equivalent. Unfortunately, the
multicast service is a rather different beast to the IP
service. This document aims to explain how much of what has
learned during the development of NHRP must be carefully
Armitage Informational [Page 1]
RFC 2191 VENUS September 1997
before being re-applied to the multicast scenario. Indeed,
service provided by the MARS and MARS Clients in [2] are
orthogonal to the IP unicast service over ATM
For the sake of discussion, let's call this hypothetical
shortcut discovery protocol the "Very Extensive Non-Unicast Service
(VENUS). A "VENUS Domain" is defined as the set of hosts from two
more participating Logical IP Subnets (LISs). A multicast
connection is a point to multipoint SVC whose leaf nodes
scattered around the VENUS Domain. (It will be noted in section 2
that a VENUS Domain might consist of a single MARS Cluster
multiple LISs, or multiple MARS Clusters.)
VENUS faces a number of fundamental problems. The first is
the scope over which individual IP/ATM interfaces must track
react to IP multicast group membership changes. Under the
IP routing model Mrouters act as aggregation points for
traffic flows in and out of Clusters [4]. They also act
aggregators of group membership change information - only the IP/
interfaces within each Cluster need to know the specific
of their local (intra-cluster) group members at any given time
However, once you have sources within a VENUS Domain
shortcut connections the data and signaling plane aggregation
Mrouters is lost. In order for all possible sources throughout
VENUS Domain to manage their outgoing pt-mpt SVCs they must be
aware of MARS_JOINs and MARS_LEAVEs occuring in every MARS
that makes up a VENUS Domain. The nett effect is that a VENUS
looks very similar to a single, large distributed MARS Cluster
A second problem is the impact that shortcut connections will have
IP level Inter Domain Multicast Routing (IDMR) protocols.
groups have many sources and many destinations scattered amongst
participating Clusters. IDMR protocols assume that they can
efficient inter-Cluster multicast trees by aggregating
sources or group members in any given Cluster (subnet) behind
Mrouter serving that Cluster. If sources are able to simply bypass
Mrouter we introduce a requirement that the existence of each
every shortcut connection be propagated into the IDMR decision
processes. The IDMR protocols may need to adapt when a source'
traffic bypasses its local Mrouter(s) and is injected into
at more distant points on the IP-level multicast distribution tree
(This issue has been looked at in [7], focussing on
forwarding trees within networks where the termination points
small in number and sparsely distributed. VENUS introduces
requirements by assuming that multicast group membership may be
across the region of interest.)
Armitage Informational [Page 2]
RFC 2191 VENUS September 1997
This document will focus primarily on the internal problems of
VENUS Domain, and leave the IDMR interactions for future analysis
2. What does it mean to "shortcut" ?
Before going further it is worth considering both the definition
the Cluster, and two possible definitions of "shortcut".
2.1 What is a Cluster
In [2] a MARS Cluster is defined as the set of IP/ATM interfaces
are willing to engage in direct, ATM level pt-mpt SVCs to perform
multicast packet forwarding. Each IP/ATM interface (a MARS Client
must keep state information regarding the ATM addresses of each
node (recipient) of each pt-mpt SVC it has open. In addition,
MARS Client receives MARS_JOIN and MARS_LEAVE messages from the
whenever there is a requirement that Clients around the Cluster
to update their pt-mpt SVCs for a given IP multicast group
It is worth noting that no MARS Client has any concept of how big
local cluster is - this knowledge is kept only by the MARS that
given Client is registered with
Fundamentally the Cluster (and the MARS model as a whole) is
response to the requirement that any multicast IP/ATM interface
pt-mpt SVCs must, as group membership changes, add and drop
nodes itself. This means that some mechanism, spanning all
group members within the scopes of these pt-mpt SVCs, is required
collect group membership information and distribute it in a
fashion to those interfaces. This is the MARS Cluster, with
scaling limits described in [4].
2.2 LIS/Cluster boundary "shortcut
The currently popular definition of "shortcut" is based on
existence of unicast LIS boundaries. It is tied to the notion
LIS boundaries have physical routers, and cutting through a
boundary means bypassing a router. Intelligently bypassing
that sit at the edges of LISs has been the goal of NHRP.
the ATM level identity of an IP endpoint in a different LIS allows
direct SVC to be established, thus shortcutting the logical
topology (and very real routers) along the unicast path from
to destination
For simplicity of early adoption RFC2022 recommends that a Cluster'
scope be made equivalent to that of a LIS. Under these
the "Classical IP" routing model places Mrouters at LIS/
boundaries, and multicast shortcutting must involve bypassing
Armitage Informational [Page 3]
RFC 2191 VENUS September 1997
same physical routing entities as unicast shortcutting. Each
Cluster would be independent and contain only those IP/ATM
that had been assigned to the same LIS
As a consequence, a VENUS Domain covering the hosts in a number
LIS/Clusters would have to co-ordinate each individual MARS from
LIS/Cluster (to ensure group membership updates from around the
Domain were propagated correctly).
2.3 Big Cluster, LIS boundary "shortcut
The MARS model's fundamental definition of a Cluster was
created to be independent of unicast terminology. Although
currently well understood, it is possible to build a single
Cluster that encompasses the members of multiple LISs. As expected
inter-LIS unicast traffic would pass through (or bypass, if
NHRP) routers on the LIS boundaries. Also as expected, each IP/
interface, acting as a MARS Client, would forward their IP
packets directly to intra-cluster group members. However, because
direct intra-cluster SVCs would exist between hosts from
different LISs making up the cluster, this could be considered
"shortcut" of the unicast LIS boundaries
This approach immediately brings up the problem of how the
protocols will react. Mrouters only need to exist at the edges
Clusters. In the case of a single Cluster spanning multiple LISs
each LIS becomes hidden behind the Mrouter at the Cluster's edge
This is arguably not a big problem if the Cluster is a stub on
IDMR protocol's multicast distribution tree, and if there is only
single Mrouter in or out of the Cluster. Problems arise when two
more Mrouters are attached to the edges of the Cluster, and
Cluster is used for transit multicast traffic. Each Mrouter'
interface is assigned a unicast identity (e.g. that of the
router containing the Mrouter). IDMR protocols that filter
based on the correctness of the upstream source may be confused
receiving IP multicast packets directly from another Mrouter in
same cluster but notionally "belonging" to an LIS multiple unicast
hops away
Adjusting the packet filtering algorithms of Mrouters is
that needs to be addressed by any multicast shortcut scheme. It
been noted before and a solution proposed in [7]. For the sake
argument this document will assume the problem solvable. (However,
is important that any solution scales well under general
and group membership densities.)
Armitage Informational [Page 4]
RFC 2191 VENUS September 1997
A multi-LIS MARS Cluster can be considered a simple VENUS Domain
Since it is a single Cluster it can be scaled using the
MARS solutions currently being developed within the IETF [5,6].
3. So what must VENUS look like
A number of functions that occur in the MARS model are fundamental
the problem of managing root controlled, pt-mpt SVCs. The
setup of the forwarding SVC by any one MARS Client requires
query/response exchange with the Client's local MARS,
who the current group members are (i.e. what leaf nodes should be
the SVC). Following SVC establishment comes the management phase -
MARS Clients need to be kept informed of group membership
within the scopes of their SVCs, so that leaf nodes may be added
dropped as appropriate
For intra-cluster multicasting the current MARS approach is
solution for these two phases
For the rest of this document we will focus on what VENUS would
like when a VENUS Domain spans multiple MARS Clusters. Under
circumstances VENUS is a mechanism co-ordinating the MARS entities
each participating cluster. Each MARS is kept up to date
sufficient domain-wide information to support both phases of
operation (SVC establishment and SVC management) when the SVC'
endpoints are outside the immediate scope of a client's local MARS
Inside a VENUS Domain a MARS Client is supplied information on
members from all participating clusters
The following subsections look at the problems associated with
of these phases independently. To a first approximation the
identified are independent of the possible inter-MARS mechanisms.
reader may assume the MARS in any cluster has some
mechanism for communicating with the MARSs of clusters
adjacent to its own cluster (i.e. connected by a single Mrouter hop).
3.1 SVC establishment - answering a MARS_REQUEST
The SVC establishment phase contains a number of inter-
problems
First, the target of a MARS_REQUEST (an IP multicast group) is
abstract entity. Let us assume that VENUS does not require every
to know the entire list of group members across the
clusters. In this case each time a MARS_REQUEST is received by
MARS from a local client, the MARS must construct a sequence
MARS_MULTIs based on locally held information (on intra-
members) and remotely solicited information
Armitage Informational [Page 5]
RFC 2191 VENUS September 1997
So how does it solicit this information? Unlike the
situation, there is no definite, single direction to route
MARS_REQUEST across the participating clusters. The only "right
approach is to send the MARS_REQUEST to all clusters, since
members may exist anywhere and everywhere. Let us allow one
optimization - the MARS_REQUEST is propagated along the IP
forwarding tree that has been established for the target group
whatever IDMR protocol is running at the time
As noted in [4] there are various reasons why a Cluster's scope
kept limited. Some of these (MARS Client or ATM NIC limitations
imply that the VENUS discovery process not return more group
in the MARS_MULTIs that the requesting MARS Client can handle.
provides VENUS with an interesting problem of propagating out
original MARS_REQUEST, but curtailing the MARS_REQUESTs
when a sufficient number of group members have been identified
Viewed from a different perspective, this means that the scope
shortcut achievable by any given MARS Client may depend greatly
the shape of the IP forwarding tree away from its location (and
density of group members within clusters along the tree) at the
the request was issued
How might we limit the number of group members returned to a
MARS Client? Adding a limit TLV to the MARS_REQUEST itself
trivial. At first glance it might appear that when the limit is
reached we could summarize the next cluster along the tree by the
address of the Mrouter into that cluster. The nett effect would
that the MARS Client establishes a shortcut to many hosts that
inside closer clusters, and passes its traffic to more
clusters through the distant Mrouter. However, this approach
works passably well for a very simplistic multicast topology (e.g.
linear concatenation of clusters).
In a more general topology the IP multicast forwarding tree away
the requesting MARS Client will branch a number of times,
the MARS_REQUEST to be replicated along each branch. Ensuring
the total number of returned group members does not exceed
client's limit becomes rather more difficult to do efficiently
(VENUS could simply halve the limit value each time it split
MARS_REQUEST, but this might cause group member discovery on
branch to end prematurely while all the group members along
branch are discovered without reaching the subdivided limit.)
Now consider this decision making process scattered across all
clients in all participating clusters. Clients may have
limits on how many group members they can handle - leading
situations where different sources can shortcut to
(sub)sets of the group members scattered across the
Armitage Informational [Page 6]
RFC 2191 VENUS September 1997
clusters (because the IP multicast forwarding trees from senders
different clusters may result in different discovery paths
taken by their MARS_REQUESTs.)
Finally, when the MARS_REQUEST passes a cluster where the
group is MCS supported, VENUS must ensure the ATM address of the
is collected rather than the addresses of the actual group members
(To do otherwise would violate the remote cluster's intra-
decision to use an MCS. The shortcut in this case must be content
directly reach the remote cluster's MCS.)
(A solution to part of this problem would be to ensure that a
Domain never has more MARS Clients throughout than the clients
capable of adding as leaf nodes. This may or may not appeal
people's desire for generality of a VENUS solution. It also
appear to beg the question of why the problem of multiple-
multicasting isn't solved simply by creating a single big
Cluster.)
3.2 SVC management - tracking group membership changes
Once a client's pt-mpt SVC is established, it must be kept up
date. The consequence of this is simple, and
devastating: The MARS_JOINs and MARS_LEAVEs from every MARS Client
every participating cluster must be propagated to every
sender in every participating cluster (this applies to groups
are VC Mesh supported - groups that are MCS supported in some or
participating clusters introduce complications described below).
Unfortunately, the consequential signaling load (as all
participating MARSs start broadcasting their MARS_JOIN/
activity) is not localized to clusters containing MARS Clients
have established shortcut SVCs. Since the IP multicast model is
to Multipoint, and you can never know where there may be source
Clients, the JOINs and LEAVEs must be propagated everywhere, always
just in case. (This is simply a larger scale version of sending
and LEAVEs to every cluster member over ClusterControlVC, and
exactly the same reason.)
The use of MCSs in some clusters instead of VC Meshes
complicates the situation, as does the initial scoping of a client'
shortcut during the SVC establishment phase (described in
preceding section).
In Clusters where MCSs are supporting certain groups, MARS_JOINs
MARS_LEAVEs are only propagated to MARS Clients when an MCS comes
goes. However, it is not clear how to effectively accommodate
current MARS_MIGRATE functionality (that allows a previously VC
based group to be shifted to an MCS within the scope of a
Armitage Informational [Page 7]
RFC 2191 VENUS September 1997
cluster). If an MCS starts up within a single Cluster, it is
to shift all the intra-cluster senders to the MCS using MARS_
as currently described in the MARS model. However, MARS Clients
remote clusters that have shortcut SVCs into the local cluster
need some signal to shift (otherwise they will continue to send
packets directly to the group members in the local cluster).
This is a non-trivial requirement, since we only want to force
remote MARS Clients to drop some of their leaf nodes (the ones
clients within the Cluster that now has an MCS), add the new MCS as
leaf node, and leave all their other leaf nodes untouched (the cut
through connections to other clusters). Simply broadcasting
MARS_MIGRATE around all participating clusters would certainly
work. VENUS needs a new control message with semantics of "
leaf nodes {x, y, z} with leaf node {a}, and leave the rest alone".
Such a message is easy to define, but harder to use
Another issue for SVC management is that the scope over which a
Client needs to receive JOINs and LEAVEs needs to respect
Client's limited capacity for handling leaf nodes on its SVC. If
MARS Client initially issued a MARS_REQUEST and indicated it
handle 1000 leaf nodes, it is not clear how to ensure that
joins of new members wont exceed that limit. Furthermore, if the
establishment phase decided that the SVC would stop at a
Mrouter (due to leaf node limits being reached), the Client
should not be receiving direct MARS_JOIN or MARS_LEAVE
pertaining to activity in the cluster "behind" this Mrouter. (To
otherwise could lead to multiple copies of the source client'
packets reaching group members inside the remote cluster -
version through the Mrouter, and another on the direct SVC
that the source client would establish after receiving a subsequent
global MARS_JOIN regarding a host inside the remote cluster.)
Another scenario involves the density of group members along the
multicast tree increasing with time after the initial MARS_REQUEST
answered. Subsequent JOINs from Cluster members may dictate that
"closer" Mrouter be used to aggregate the source's outbound
(so as not to exceed the source's leaf node limitations). How
dynamically shift between terminating on hosts within a Cluster,
terminating on a cluster's edge Mrouter, is an open question
To complicate matters further, this scoping of the VENUS domain-
propagation of MARS_JOINs and MARS_LEAVEs needs to be on a per
source- cluster basis, at least. If MARS Clients within the
cluster have different leaf node limits, the problem worsens.
such circumstances, one client may have been able to establish
shortcut SVC directly into a remote cluster while a second client -
in the same source cluster - may have been forced to terminate
Armitage Informational [Page 8]
RFC 2191 VENUS September 1997
shortcut on the remote cluster's Mrouter. The first client
needs to know about group membership changes in the remote cluster
whilst the second client does not. Propagating these JOIN/
messages on ClusterControlVC in the source cluster will not work -
the MARS for the source cluster will need to explicitly send
of the JOIN/LEAVE messages only to those MARS Clients whose prior
establishment phase indicates they need them. Propagation of
to indicate a VC Mesh to MCS transition within clusters may also
to take account of the leaf node limitations of MARS Clients.
scaling characteristics of this problem are left to the
imagination
It was noted in the previous section that a VENUS domain could
limited to ensure there are never more MARS Clients than any
client's leaf node limit. This would certainly avoid the need to
complicated MARS_JOIN/LEAVE propagation mechanisms. However, it
the question of how different the VENUS domain then becomes from
single, large MARS Cluster
4. What is the value in bypassing Mrouters
This is a good question, since the whole aim of developing a
connection mechanism is predicated on the assumption that
IP level entities is always a "win". However, this is arguably
true for multicast
The most important observation that should be made about
connection scenarios is that they increase the exposure of any
IP/ATM interface to externally generated SVCs. If there are
potential 1000 senders in a VENUS Domain, then you (as a
member) open yourself up to a potential demand for 1000 instances
your re-assembly engine (and 1000 distinct incoming SVCs, when
get added as a leaf node to each sender's pt-mpt SVC, which
local switch port must be able to support).
It should be no surprise that the ATM level scaling limits
to a single MARS Cluster [4] will also apply to a VENUS Domain.
we're up against the question of why you'd bypass an Mrouter.
noted in [4] Mrouters perform a useful function of data
aggregation - 100 senders in one cluster become 1 pt-mpt SVC out
the Mrouter into the next cluster along the tree. They also hide
signaling activity - individual group membership changes in
cluster are hidden from IP/ATM interfaces in surrounding clusters
The loss of these benefits must be factored into any network
to utilize multicast shortcut connections
Armitage Informational [Page 9]
RFC 2191 VENUS September 1997
(For the sake of completeness, it must be noted that extremely
mismatches of IP and ATM topologies may make Mrouter
attractive if it improves the use of the underlying ATM cloud.
may also be benefits in removing the additional re
assembly/segmentation latencies of having packets pass through
Mrouter. However, a VENUS Domain ascertained to be small enough
avoid the scaling limits in [4] might just as well be constructed
a single large MARS Cluster. A large cluster also avoids
topological mismatch between IP Mrouters and ATM switches.)
5. Relationship to Distributed MARS protocols
The ION working group is looking closely at the development
distributed MARS architectures. An outline of some issues is
in [5,6]. As noted earlier in this document the problem space
very similar that faced by our hypothetical VENUS Domain.
example, in the load-sharing distributed MARS model
- The Cluster is partitioned into sub-clusters
- Each Active MARS is assigned a particular sub-cluster, and
its own sub-ClusterControlVC to propagate JOIN/LEAVE messages
members of its sub-cluster
- The MARS_REQUEST from any sub-cluster member must
information from all the sub-clusters, so as to ensure that all
group's members across the cluster are identified
- Group membership changes in any one sub-cluster must
immediately propagated to all the other sub-clusters
There is a clear analogy to be made between a distributed
Cluster, and a VENUS Domain made up of multiple single-MARS Clusters
The information that must be shared between sub-clusters in
distributed MARS scenario is similar to the information that must
shared between Clusters in a VENUS Domain
The distributed MARS problem is slightly simpler than that faced
VENUS
- There are no Mrouters (IDMR nodes) within the scope of
distributed Cluster
- In a distributed MARS Cluster an MCS supported group uses
same MCS across all the sub-clusters (unlike the VENUS Domain
where complete generality makes it necessary to cope with
of MCS and VC Mesh based Clusters).
Armitage Informational [Page 10]
RFC 2191 VENUS September 1997
6. Conclusion
This document has described a hypothetical multicast
connection scheme, dubbed "Very Extensive NonUnicast Service
(VENUS). The two phases of multicast support - SVC establishment
and SVC management - are shown to be essential whether the scope is
Cluster or a wider VENUS Domain. It has been shown that once
potential scope of a pt-mpt SVC at establishment phase has
expanded, the scope of the SVC management mechanism must similarly
expanded. This means timely tracking and propagation of
membership changes across the entire scope of a VENUS Domain
It has also been noted that there is little difference in
between a VENUS Domain and a large MARS Cluster. Both suffer from
same fundamental scaling limitations, and both can be arranged
provide shortcut of unicast routing boundaries. However, a
general multi-cluster VENUS solution ends up being more complex.
needs to deal with bypassed Mrouter boundaries, and
changing group membership densities along multicast
trees established by the IDMR protocols in use
No solutions have been presented. This document's role is to
context for future developments
This document was prepared while the author was with
Internetworking Research group at Bellcore
Security
This memo addresses specific scaling issues associated with
extension of the MARS architecture beyond that described in RFC 2022.
It is an Informational memo, and does not mandate any
protocol behaviors beyond those described in RFC 2022. As such,
security implications are no greater or less than the
inherent in RFC 2022. Should enhancements to security be required
they would need to be added as an extension to the base
in RFC 2022.
Armitage Informational [Page 11]
RFC 2191 VENUS September 1997
Author's
Grenville
Bell Labs, Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ, 07733
EMail: gja@dnrc.bell-labs.
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett
Packard Laboratories, December 1993.
[2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks.", Bellcore, RFC 2022, November 1996.
[3] Luciani, J., et al, "NBMA Next Hop Resolution Protocol (NHRP)",
Work in Progress, February 1997.
[4] Armitage, G., "Issues affecting MARS Cluster Size", Bellcore,
2121, March 1997.
[5] Armitage, G., "Redundant MARS architectures and SCSP", Bellcore
Work in Progress, November 1996.
[6] Luciani, J., G. Armitage, J. Jalpern, "Server
Synchronization Protocol (SCSP) - NBMA", Work in Progress, March 1997.
[7] Rekhter, Y., D. Farinacci, " Support for Sparse Mode PIM
ATM", Cisco Systems, Work in Progress, April 1996.
Armitage Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
