RFC relevance of multicast

As per Relevance of the word multicast, we have this rfc below:

Network Working Group A.
Request for Comments: 2201
Category: Experimental September 1997

Core Based Trees (CBT) Multicast Routing

Status of this

This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited

CBT is a multicast routing architecture that builds a single
tree per group which is shared by all of the group's senders
receivers. Most multicast algorithms build one multicast tree
sender (subnetwork), the tree being rooted at the sender'
subnetwork. The primary advantage of the shared tree approach
that it typically offers more favourable scaling characteristics
all other multicast algorithms

The CBT protocol [1] is a network layer multicast routing
that builds and maintains a shared delivery tree for a
group. The sending and receiving of multicast data by hosts on
subnetwork conforms to the traditional IP multicast service
[2].

CBT is progressing through the IDMR working group of the IETF.
CBT protocol is described in an accompanying document [1]. For this
and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/

TABLE OF

1. Background................................................... 2
2. Introduction................................................. 2
3. Source Based Tree Algorithms................................. 3
3.1 Distance-Vector Multicast Algorithm...................... 4
3.2 Link State Multicast Algorithm........................... 5
3.3 The Motivation for Shared Trees.......................... 5
4. CBT - The New Architecture................................... 7
4.1 Design Requirements...................................... 7
4.2 Components & Functions................................... 8
4.2.1 CBT Control Message Retransmission Strategy........ 10
4.2.2 Non-Member Sending................................. 11
5. Interoperability with Other Multicast Routing Protocols ..... 11

Ballardie Experimental [Page 1]

RFC 2201 CBT Multicast Routing Architecture September 1997

6. Core Router Discovery........................................ 11
6.1 Bootstrap Mechanism Overview............................. 12
7. Summary ..................................................... 13
8. Security Considerations...................................... 13
Acknowledgements ............................................... 14
References ..................................................... 14
Author Information.............................................. 15

1.

Shared trees were first described by Wall in his investigation
low-delay approaches to broadcast and selective broadcast [3].
concluded that delay will not be minimal, as with shortest-
trees, but the delay can be kept within bounds that may
acceptable. Back then, the benefits and uses of multicast were
fully understood, and it wasn't until much later that the
multicast address space was defined (class D space [4]). Deering'
work [2] in the late 1980's was pioneering in that he defined the
multicast service model, and invented algorithms which allow hosts
arbitrarily join and leave a multicast group. All of Deering'
multicast algorithms build source-rooted delivery trees, with
delivery tree per sender subnetwork. These algorithms are
in [2].

After several years practical experience with multicast, we see
diversity of multicast applications and correspondingly, a
variety of multicast application requirements. For example
distributed interactive simulation (DIS) applications have
requirements in terms of join latency, group membership dynamics
group sender populations, far exceeding the requirements of
other multicast applications

The multicast-capable part of the Internet, the MBONE, continues
expand rapidly. The obvious popularity and growth of multicast
that the scaling aspects of wide-area multicasting cannot
overlooked; some predictions talk of thousands of groups
present at any one time in the Internet

We evaluate scalability in terms of network state maintenance
bandwidth efficiency, and protocol overhead. Other factors that
affect these parameters include sender set size, and wide-
distribution of group members

2.

Multicasting on the local subnetwork does not require either
presence of a multicast router or the implementation of a
routing algorithm; on most shared media (e.g. Ethernet), a host

Ballardie Experimental [Page 2]

RFC 2201 CBT Multicast Routing Architecture September 1997

which need not necessarily be a group member, simply sends
multicast data packet, which is received by any member
connected to the same medium

For multicasts to extend beyond the scope of the local subnetwork
the subnet must have a multicast-capable router attached,
itself is attached (possibly "virtually") to another multicast
capable router, and so on. The collection of these (virtually
connected multicast routers forms the Internet's MBONE

All multicast routing protocols make use of IGMP [5], a protocol
operates between hosts and multicast router(s) belonging to the
subnetwork. IGMP enables the subnet's multicast router(s) to
group membership presence on its directly attached links, so that
multicast data arrives, it knows over which of its links to send
copy of the packet

In our description of the MBONE so far, we have assumed that
multicast routers on the MBONE are running the same multicast
protocol. In reality, this is not the case; the MBONE is a
of autonomously administered multicast regions, each region
by one or more multicast-capable border routers. Each
independently chooses to run whichever multicast routing
best suits its needs, and the regions interconnect via the "
region", which currently runs the Distance Vector Multicast
Protocol (DVMRP) [6]. Therefore, it follows that a region's
router(s) must interoperate with DVMRP

Different algorithms use different techniques for establishing
distribution tree. If we classify these algorithms into source-
tree algorithms and shared tree algorithms, we'll see that
different classes have considerably different
characteristics, and the characteristics of the resulting
differ too, for example, average delay. Let's look at source-
tree algorithms first

3. Source-Based Tree

The strategy we'll use for motivating (CBT) shared tree multicast
based, in part, in explaining the characteristics of source-
tree multicast, in particular its scalability

Most source-based tree multicast algorithms are often referred to
"dense-mode" algorithms; they assume that the receiver
densely populates the domain of operation, and therefore
accompanying overhead (in terms of state, bandwidth usage, and/
processing costs) is justified. Whilst this might be the case in
local environment, wide-area group membership tends to be

Ballardie Experimental [Page 3]

RFC 2201 CBT Multicast Routing Architecture September 1997

distributed throughout the Internet. There may be "pockets"
denseness, but if one views the global picture, wide-area groups
to be sparsely distributed

Source-based multicast trees are either built by a distance-
style algorithm, which may be implemented separately from the
routing algorithm (as is the case with DVMRP), or the multicast
may be built using the information present in the underlying
routing table (as is the case with PIM-DM [7]). The other
used for building source-based trees is the link-state algorithm (
protocol instance being M-OSPF [8]).

3.1. Distance-Vector Multicast

The distance-vector multicast algorithm builds a multicast
tree using a variant of the Reverse-Path Forwarding technique [9].
The technique basically is as follows: when a multicast
receives a multicast data packet, if the packet arrives on
interface used to reach the source of the packet, the packet
forwarded over all outgoing interfaces, except leaf subnets with
members attached. A "leaf" subnet is one which no router would
to reach the souce of a multicast packet. If the data packet does
arrive over the link that would be used to reach the source,
packet is discarded

This constitutes a "broadcast & prune" approach to multicast
construction; when a data packet reaches a leaf router, if
router has no membership registered on any of its directly
subnetworks, the router sends a prune message one hop back
the source. The receiving router then checks its leaf subnets
group membership, and checks whether it has received a prune from
of its downstream routers (downstream with respect to the source).
If so, the router itself can send a prune upstream over the
leading to the source

The sender and receiver of a prune message must cache the group> pair being reported, for a "lifetime" which is at
granularity of minutes. Unless a router's prune information
refreshed by the receipt of a new prune for
its "lifetime" expires, that information is removed, allowing data
flow over the branch again. State that expires in this way
referred to as "soft state".

Interestingly, routers that do not lead to group members are
the state overhead incurred by prune messages. For wide-
multicasting, which potentially has to support many thousands
active groups, each of which may be sparsely distributed,
technique clearly does not scale

Ballardie Experimental [Page 4]

RFC 2201 CBT Multicast Routing Architecture September 1997

3.2. Link-State Multicast

Routers implementing a link state algorithm periodically
reachability information to their directly attached neighbours,
flood this throughout the routing domain in so-called link
update packets. Deering extended the link state algorithm
multicasting by having a router additionally detect group
changes on its incident links before flooding this information
link state packets

Each router then, has a complete, up-to-date image of a domain'
topology and group membership. On receiving a multicast data packet
each router uses its membership and topology information to
a shortest-path tree rooted at the sender subnetwork. Provided
calculating router falls within the computed tree, it forwards
data packet over the interfaces defined by its calculation. Hence
multicast data packets only ever traverse routers leading to members
either directly attached, or further downstream. That is,
delivery tree is a true multicast tree right from the start

However, the flooding (reliable broadcasting) of group
information is the predominant factor preventing the link
multicast algorithm being applicable over the wide-area. The
limiting factor is the processing cost of the Dijkstra calculation
compute the shortest-path tree for each active source

3.3. The Motivation for Shared

The algorithms described in the previous sections clearly
the need for a multicast algorithm(s) that is more scalable. CBT
designed primarily to address the topic of scalability; a shared
architecture offers an improvement in scalability over source
architectures by a factor of the number of active sources (
source is usually a subnetwork aggregate). Source trees scale O(S *
G), since a distinct delivery tree is built per active source.
trees eliminate the source (S) scaling factor; all sources use
same shared tree, and hence a shared tree scales O(G).
implication of this is that applications with many active senders
such as distributed interactive simulation applications,
distributed video-gaming (where most receivers are also senders),
have a significantly lesser impact on underlying multicast routing
shared trees are used

Ballardie Experimental [Page 5]

RFC 2201 CBT Multicast Routing Architecture September 1997

In the "back of the envelope" table below we compare the amount
state required by CBT and DVMRP for different group sizes
different numbers of active sources

|--------------|---------------------------------------------------|
| Number of | | | |
| groups | 10 | 100 | 1000 |
====================================================================
| Group size | | | |
| (# members) | 20 | 40 | 60 |
-------------------------------------------------------------------|
| No. of srcs | | | | | | | | | |
| per group |10% | 50% |100% |10% | 50% |100% |10% | 50% | 100% |
--------------------------------------------------------------------
| No. of DVMRP | | | | | | | | | |
| router | | | | | | | | | |
| entries | 20 | 100 | 200 |400 | 2K | 4K | 6K | 30K | 60K |
--------------------------------------------------------------------
| No. of CBT | | | |
| router | | | |
| entries | 10 | 100 | 1000 |
|------------------------------------------------------------------|

Figure 1: Comparison of DVMRP and CBT Router

Shared trees also incur significant bandwidth and state
compared with source trees; firstly, the tree only spans a group'
receivers (including links/routers leading to receivers) -- there
no cost to routers/links in other parts of the network. Secondly
routers between a non-member sender and the delivery tree are
incurred any cost pertaining to multicast, and indeed, these
need not even be multicast-capable -- packets from non-member
are encapsulated and unicast to a core on the tree

Ballardie Experimental [Page 6]

RFC 2201 CBT Multicast Routing Architecture September 1997

The figure below illustrates a core based tree

b b b-----
\ | |
\ | |
b---b b------
/ \ / KEY....
/ \/
b X---b-----b X =
/ \ b = on-tree
/ \
/ \
b b------
/ \ |
/ \ |
b b

Figure 2: CBT

4. CBT - The New

4.1. Design

The CBT shared tree design was geared towards several
objectives

o scalability - the CBT designers decided not to sacrifice CBT'
O(G) scaling characteric to optimize delay using SPTs, as
PIM. This was an important design decision, and one, we think
was taken with foresight; once multicasting becomes ubiquitous
router state maintenance will be a predominant scaling factor
It is possible in some circumstances to improve/optimize
delay of shared trees by other means. For example, a broadcast
type lecture with a single sender (or limited set
infrequently changing senders) could have its core placed in
locality of the sender, allowing the CBT to emulate a shortest
path tree (SPT) whilst still maintaining its O(G)
characteristic. More generally, because CBT does not
source-specific state, it is particularly suited to many
applications

o robustness - source-based tree algorithms are clearly robust;
sender simply sends its data, and intervening routers "conspire
to get the data where it needs to, creating state along the way
This is the so-called "data driven" approach -- there is
set-up protocol involved

Ballardie Experimental [Page 7]

RFC 2201 CBT Multicast Routing Architecture September 1997

It is not as easy to achieve the same degree of robustness
shared tree algorithms; a shared tree's core router
connectivity between all group members, and is thus a
point of failure. Protocol mechanisms must be present
ensure a core failure is detected quickly, and the
reconnected quickly using a replacement core router

o simplicity - the CBT protocol is relatively simple compared
most other multicast routing protocols. This simplicity can
to enhanced performance compared to other protocols

o interoperability - from a multicast perspective, the Internet
a collection of heterogeneous multicast regions. The
interconnecting these multicast regions is currently DVMRP [6];
any regions not running DVMRP connect to the DVMRP "backbone"
stub regions. CBT has well-defined interoperability
with DVMRP [15].

4.2. CBT Components &

The CBT protocol is designed to build and maintain a shared
distribution tree that spans only those networks and links leading
interested receivers

To achieve this, a host first expresses its interest in joining
group by multicasting an IGMP host membership report [5] across
attached link. On receiving this report, a local CBT aware
invokes the tree joining process (unless it has already)
generating a JOIN_REQUEST message, which is sent to the next hop
the path towards the group's core router (how the local
discovers which core to join is discussed in section 6). This
message must be explicitly acknowledged (JOIN_ACK) either by the
router itself, or by another router that is on the unicast
between the sending router and the core, which itself has
successfully joined the tree

The join message sets up transient join state in the routers
traverses, and this state consists of incoming interface
outgoing interface>. "Incoming interface" and "outgoing interface
may be "previous hop" and "next hop", respectively, if
corresponding links do not support multicast transmission. "
hop" is taken from the incoming control packet's IP source address
and "next hop" is gleaned from the routing table - the next hop
the specified core address. This transient state eventually times
unless it is "confirmed" with a join acknowledgement (JOIN_ACK)
upstream. The JOIN_ACK traverses the reverse path of
corresponding join message, which is possible due to the presence
the transient join state. Once the acknowledgement reaches

Ballardie Experimental [Page 8]

RFC 2201 CBT Multicast Routing Architecture September 1997

router that originated the join message, the new receiver can
traffic sent to the group

Loops cannot be created in a CBT tree because a) there is only
active core per group, and b) tree building/maintenance
which may lead to the creation of tree loops are avoided.
example, if a router's upstream neighbour becomes unreachable,
router immediately "flushes" all of its downstream branches,
them to individually rejoin if necessary. Transient unicast loops
not pose a threat because a new join message that loops back
itself will never get acknowledged, and thus eventually times out

The state created in routers by the sending or receiving of
JOIN_ACK is bi-directional - data can flow either way along a
"branch", and the state is group specific - it consists of the
address and a list of local interfaces over which join messages
the group have previously been acknowledged. There is no concept
"incoming" or "outgoing" interfaces, though it is necessary to
able to distinguish the upstream interface from any
interfaces. In CBT, these interfaces are known as the "parent"
"child" interfaces, respectively

With regards to the information contained in the multicast
cache, on link types not supporting native multicast transmission
on-tree router must store the address of a parent and any children
On links supporting multicast however, parent and any
information is represented with local interface addresses (or
identifying information, such as an interface "index") over which
parent or child is reachable

When a multicast data packet arrives at a router, the router uses
group address as an index into the multicast forwarding cache. A
of the incoming multicast data packet is forwarded over
interface (or to each address) listed in the entry except
incoming interface

Each router that comprises a CBT multicast tree, except the
router, is responsible for maintaining its upstream link, provided
has interested downstream receivers, i.e. the child interface list
not NULL. A child interface is one over which a member host
directly attached, or one over which a downstream on-tree router
attached. This "tree maintenance" is achieved by each
router periodically sending a "keepalive" message (ECHO_REQUEST)
its upstream neighbour, i.e. its parent router on the tree.
keepalive message is sent to represent entries with the same parent
thereby improving scalability on links which are shared by
groups. On multicast capable links, a keepalive is multicast to
"all-cbt-routers" group (IANA assigned as 224.0.0.15); this has

Ballardie Experimental [Page 9]

RFC 2201 CBT Multicast Routing Architecture September 1997

suppressing effect on any other router for which the link is
parent link. If a parent link does not support
transmission, keepalives are unicast

The receipt of a keepalive message over a valid child
immediately prompts a response (ECHO_REPLY), which is either
or multicast, as appropriate

The ECHO_REQUEST does not contain any group information;
ECHO_REPLY does, but only periodically. To maintain
information between parent and child, the parent
reports, in a ECHO_REPLY, all groups for which it has state,
each of its child interfaces for those groups. This group-
echo reply is not prompted explicitly by the receipt of an
request message. A child is notified of the time to expect the
echo reply message containing group information in an echo
prompted by a child's echo request. The frequency of parent
reporting is at the granularity of minutes

It cannot be assumed all of the routers on a multi-access link have
uniform view of unicast routing; this is particularly the case when
multi-access link spans two or more unicast routing domains.
could lead to multiple upstream tree branches being formed (an
condition) unless steps are taken to ensure all routers on the
agree which is the upstream router for a particular group.
routers attached to a multi-access link participate in an
election mechanism that elects a single router, the designated
(DR), as the link's upstream router for all groups. Since the
might not be the link's best next-hop for a particular core router
this may result in join messages being re-directed back across
multi-access link. If this happens, the re-directed join message
unicast across the link by the DR to the best next-hop,
preventing a looping scenario. This re-direction only ever
to join messages. Whilst this is suboptimal for join messages,
are generated infrequently, multicast data never traverses a
more than once (either natively, or encapsulated).

In all but the exception case described above, all CBT
messages are multicast over multicast supporting links to the "all
cbt-routers" group, with IP TTL 1. When a CBT control message is
over a non-multicast supporting link, it is explicitly addressed
the appropriate next hop

4.2.1. CBT Control Message Retransmission

Certain CBT control messages illicit a response of some sort. Lack
response may be due to an upstream router crashing, or the loss
the original message, or its response. To detect these events,

Ballardie Experimental [Page 10]

RFC 2201 CBT Multicast Routing Architecture September 1997

retransmits those control messages for which it expects a response
if that response is not forthcoming within the retransmission
interval, which varies depending on the type of message involved
There is an upper bound (typically 3) on the number
retransmissions of the original message before an exception
is raised

For example, the exception procedure for lack of response to
ECHO_REQUEST is to send a QUIT_NOTIFICATION upstream and a FLUSH_
message downstream for the group. If this is router has group
attached, it restarts the joining process to the group's core

4.2.2. Non-Member

If a non-member sender's local router is already on-tree for
group being sent to, the subnet's upstream router simply forwards
data packet over all outgoing interfaces corresponding to
group's forwarding cache entry. This is in contrast to PIM-SM [18]
which must encapsulate data from a non-member sender, irrespective
whether the local router has joined the tree. This is due to PIM'
uni-directional state

If the sender's subnet is not attached to the group tree, the
DR must encapsulate the data packet and unicast it to the group'
core router, where it is decapsulated and disseminated over all
interfaces, as specified by the core's forwarding cache entry for
group. The data packet encapsulation method is IP-in-IP [14].

Routers in between a non-member sender and the group's core need
know anything about the multicast group, and indeed may even
multicast-unaware. This makes CBT particulary attractive
applications with non-member senders

5. Interoperability with Other Multicast Routing

See "interoperability" in section 4.1.

The interoperability mechanisms for interfacing CBT with DVMRP
defined in [15].

6. Core Router

Core router discovery is by far the most controversial and
aspect of shared tree multicast architectures, particularly in
context of inter-domain multicast routing (IDMR). There have
many proposals over the past three years or so, including
core addresses in a multicast session directory like "sdr" [11],
manual placement, and the HPIM [12] approach of strictly dividing

Ballardie Experimental [Page 11]

RFC 2201 CBT Multicast Routing Architecture September 1997

the multicast address space into many "hierarchical scopes" and
explicit advertising of core routers between scope levels

There are currently two options for CBTv2 [1] core discovery;
"bootstrap" mechamism, and manual placement. The bootstrap
(as currently specified with the PIM sparse mode protocol [18])
applicable only to intra-domain core discovery, and allows for
"plug & play" type operation with minimal configuration.
disadvantage of the bootstrap mechanism is that it is much
difficult to affect the shape, and thus optimality, of the
distribution tree. Also, it must be implemented by all CBT
within a domain

Manual configuration of leaf routers with mappings
the other option (note: leaf routers only); this imposes a degree
administrative burden - the mapping for a particular group must
coordinated across all leaf routers to ensure consistency. Hence
this method does not scale particularly well. However, it is
that "better" trees will result from this method, and it is also
only available option for inter-domain core discovery
available

6.1. Bootstrap Mechanism

It is unlikely at this stage that the bootstrap mechanism will
appended to a well-known network layer protocol, such as IGMP [5]
ICMP [13], though this would facilitate its ubiquitous (intra-domain
deployment. Therefore, each multicast routing protocol requiring
bootstrap mechanism must implement it as part of the
routing protocol itself

A summary of the operation of the bootstrap mechanism follows. It
assumed that all routers within the domain implement the "bootstrap
protocol, or at least forward bootstrap protocol messages

A subset of the domain's routers are configured to be CBT
core routers. Each candidate core router periodically (default
60 secs) advertises itself to the domain's Bootstrap Router (BSR),
using "Core Advertisement" messages. The BSR is itself
dynamically from all (or participating) routers in the domain.
domain's elected BSR collects "Core Advertisement" messages
candidate core routers and periodically advertises a candidate
set (CC-set) to each other router in the domain, using
hopby-hop unicast forwarding. The BSR uses "Bootstrap Messages"
advertise the CC-set. Together, "Core Advertisements" and "
Messages" comprise the "bootstrap" protocol

Ballardie Experimental [Page 12]

RFC 2201 CBT Multicast Routing Architecture September 1997

When a router receives an IGMP host membership report from one of
directly attached hosts, the local router uses a hash function on
reported group address, the result of which is used as an index
the CC-set. This is how local routers discover which core to use
a particular group

Note the hash function is specifically tailored such that a
number of consecutive groups always hash to the same core
Furthermore, bootstrap messages can carry a "group mask",
limiting a CC-set to a particular range of groups. This can
reduce traffic concentration at the core

If a BSR detects a particular core as being unreachable (it has
announced its availability within some period), it deletes
relevant core from the CC-set sent in its next bootstrap message
This is how a local router discovers a group's core is unreachable
the router must re-hash for each affected group and join the new
after removing the old state. The removal of the "old" state
the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE
downstream

7.

This document presents an architecture for intra- and inter-
multicast routing. We motivated this architecture by describing
an inter-domain multicast routing algorithm must scale to
numbers of groups present in the internetwork, and discussed why
other existing algorithms are less suited to inter-domain
routing. We followed by describing the features and components
the architecture, illustrating its simplicity and scalability

8. Security

Security considerations are not addressed in this memo

Whilst multicast security is a topic of ongoing research,
applications (users) nevertheless have the ability to take
of security services such as encryption or/and
provided such services are supported by the applications

RFCs 1949 and 2093/2094 discuss different ways of
multicast key material, which can result in the provision of
layer access control to a multicast distribution tree

[19] offers a synopsis of multicast security threats and
some possible counter measures

Ballardie Experimental [Page 13]

RFC 2201 CBT Multicast Routing Architecture September 1997

Beyond these, little published work exists on the topic of
security

Special thanks goes to Paul Francis, NTT Japan, for the
brainstorming sessions that brought about this work

Clay Shields' work on OCBT [17] identified various failure
with a multi-core architecture, resulting in the specification of
single core architecture

Others that have contributed to the progress of CBT include
Carlberg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy
Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman,
Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson,
White, and other participants of the IETF IDMR working group

Thanks also to 3Com Corporation and British Telecom Plc for
this work

[1] Ballardie, A., "Core Based Trees (CBT version 2)
Routing: Protocol Specification", RFC 2189, September 1997.

[2] Multicast Routing in a Datagram Internetwork; S. Deering,
Thesis, 1991; ftp://gregorio.stanford.edu/vmtp/sd-thesis.ps

[3] Mechanisms for Broadcast and Selective Broadcast; D. Wall;
thesis, Stanford University, June 1980. Technical Report #90.

[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.

[5] Internet Group Management Protocol, version 2 (IGMPv2); W
Fenner; Work In Progress

[6] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri
Work In Progress

[7] Protocol Independent Multicast (PIM) Dense Mode Specification; D
Estrin et al; ftp://netweb.usc.edu/pim, Work In Progress

[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.

[9] Reverse path forwarding of broadcast packets; Y.K. Dalal
R.M. Metcalfe; Communications of the ACM, 21(12):1040--1048, 1978.

Ballardie Experimental [Page 14]

RFC 2201 CBT Multicast Routing Architecture September 1997

[10] Some Issues for an Inter-Domain Multicast Routing Protocol; D
Meyer; Work In Progress

[11] SDP: Session Description Protocol; M. Handley and V. Jacobson
Work In Progress

[12] Hierarchical Protocol Independent Multicast; M. Handley, J
Crowcroft, I. Wakeman. Available from
http://www.cs.ucl.ac.uk/staff/M.Handley/hpim.ps
ftp://cs.ucl.ac.uk/darpa/IDMR/hpim.ps Work done 1995.

[13] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5,
RFC 792, September 1981.

[14] Perkins, C., "IP Encapsulation within IP", RFC 2003,
1996.

[15] CBT - Dense Mode Multicast Interoperability; A. Ballardie;
In Progress

[16] Performance and Resource Cost Comparisons of Multicast
Algorithms for Distributed Interactive Simulation Applications; T
Billhartz, J. Bibb Cain, E. Farrey-Goudreau, and D. Feig.
from: http://www.epm.ornl.gov/~sgb/pubs.html; July 1995.

[17] The Ordered Core Based Tree Protocol; C. Shields and J.J
Garcia- Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan
April 1997; http://www.cse.ucsc.edu/research/ccrg/publications/info
comm97ocbt.ps.

[18] Estrin, D., et. al., "Protocol Independent Multicast-Sparse
(PIM-SM): Protocol Specification", RFC 2117, June 1997.

[19] Multicast-Specific Security Threats and Counter-Measures; A
Ballardie and J. Crowcroft; In Proceedings "Symposium on Network
Distributed System Security", February 1995, pp.2-16.

Author

Tony Ballardie
Research

EMail: ABallardie@acm.

Ballardie Experimental [Page 15]

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