Technical Information
State-of-the-art Survey of Multicast Routing
Authors:
Noël Cantenot (editor)
France Telecom (FT)
Christophe Proust
France Telecom (FT)
Christian Jacquenet
France Telecom (FT)
Annick Plouhinec
France Telecom (FT)
Loris Marchetti
Telecom Italia (IT)
Constantinos Boukouvalas
OTE (OG)
Carla Paiva
Portugal Telecom (PT)
Dorota Witaszek
GMD Fokus (DT)
Abstract
This technical document deals with multicast routing specifications. Inter domain and intra domain
routing specifications are described, as well as manufacturers’ implementations.
EDIN
0054-1010
Project
P1010
For full publication
December 2000
Disclaimer
This document contains material which is the copyright of certain EURESCOM PARTICIPANTS,
and may not be reproduced or copied without permission.
All PARTICIPANTS have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the
proprietor of that information.
Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report
is capable of use, or that use of the information is free from risk, and accept no liability for loss or
damage suffered by any person using this information.
EURESCOM Technical Information
page 1 (38)
Table of contents
1
2
Introduction................................................................................................................................................ 3
Intra-domain Multicast Routing Protocols ................................................................................................. 4
2.1
PIM-SM Version 2 and Anycast-RP Feature ..................................................................................... 4
2.1.1
PIM-SM New Features .............................................................................................................. 4
2.1.1.1 DR Election ............................................................................................................................ 4
2.1.1.2 Security Features .................................................................................................................... 5
2.1.1.3 Bi-directional Mode of Operation .......................................................................................... 5
2.1.1.4 Generation Identifier .............................................................................................................. 6
2.1.1.5 Anycast-RP Feature ............................................................................................................... 6
2.1.2
PIM-DM New Features .............................................................................................................. 7
2.1.2.1 State Refresh .......................................................................................................................... 7
2.1.2.2 Generation Identifier .............................................................................................................. 7
2.2
Existing PIM-SM Implementations ................................................................................................... 7
2.2.1
NORTEL NETWORKS ............................................................................................................. 7
2.2.2
LUCENT .................................................................................................................................... 8
2.2.2.1 IP Navigator MPLS ................................................................................................................ 8
2.2.2.2 Cajun P550 ............................................................................................................................. 8
2.2.2.3 MAX4000/MAX6000 ............................................................................................................ 8
2.2.3
ALCATEL ................................................................................................................................. 8
2.2.4
HUGHES NETWORK SYSTEMS............................................................................................ 8
2.2.5
CABLETRON............................................................................................................................ 8
2.2.6
CISCO ........................................................................................................................................ 8
2.2.7
Ericsson ...................................................................................................................................... 9
2.2.8
SIEMENS .................................................................................................................................. 9
2.2.9
3COM ........................................................................................................................................ 9
2.2.10
Juniper Networks ....................................................................................................................... 9
2.2.11
Avici Systems .......................................................................................................................... 10
2.2.12
PIM and UNIX ......................................................................................................................... 10
2.3
Intra-domain Multicast Routing Policy (e.g. security) Description ................................................. 10
3
Inter-domain Multicast Routing Protocols ............................................................................................... 12
3.1
Address Allocation/Management : The “malloc” Architecture ....................................................... 12
3.2
Border Gateway Multicast Protocol (BGMP) .................................................................................. 13
3.2.1
Join Processing......................................................................................................................... 13
3.2.2
Prune Processing ...................................................................................................................... 14
3.2.3
Multicast Data Packet Processing ............................................................................................ 14
3.2.4
Route Change Notification....................................................................................................... 15
3.2.5
Interaction With PIM-SM ........................................................................................................ 15
3.3
MBGP .............................................................................................................................................. 15
3.3.1
The MP_REACH_NLRI Attribute .......................................................................................... 16
3.3.2
The MP_UNREACH_NLRI Attribute ..................................................................................... 17
3.4
Multicast Source Discovery Protocol (MSDP) ............................................................................... 18
3.4.1
Overview .................................................................................................................................. 18
3.4.2
Procedure ................................................................................................................................. 18
3.5
PIM-SO ............................................................................................................................................ 21
3.5.1
Source Specific Multicast Model Internet Drafts ..................................................................... 21
3.5.2
Source Specific Multicast Model and PIM-SO ........................................................................ 22
3.5.3
Sprint Plans for PIM-SO Deployment ..................................................................................... 23
3.6
Interoperability Rules for Multicast Routing Protocols (RFC 2715) ............................................... 23
3.7
Internet Group Management Protocol Version 3 (IGMPv3) ............................................................ 24
3.7.1
Filters ....................................................................................................................................... 24
3.7.2
Multicast Router Behaviour ..................................................................................................... 25
3.7.3
Multicast Host Behaviour ........................................................................................................ 25
3.7.4
Backward Compatibility with Version 1 and Version 2 .......................................................... 25
3.8
Existing MBGP, MSDP, BGMP, PIM-SSM and IGMPv3 Implementations .................................. 26
3.8.1
MBGP IMPLEMENTATIONS ............................................................................................... 26
3.8.1.1 CISCO SYSTEMS ............................................................................................................... 26
3.8.1.2 ERICSSON .......................................................................................................................... 27
3.8.1.3 Juniper Networks ................................................................................................................. 28
3.8.1.4 Avici Systems ...................................................................................................................... 28
3.8.2
MSDP IMPLEMENTATIONS ................................................................................................ 28
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 2 (38)
EURESCOM Technical Information
3.8.2.1 CISCO SYSTEMS ............................................................................................................... 28
3.8.2.2 Juniper Networks ................................................................................................................. 28
3.8.2.3 MERIT GATED Consortium ............................................................................................... 28
3.8.2.4 Avici Systems ...................................................................................................................... 28
3.8.3
BGMP IMPLEMENTATIONS ............................................................................................... 29
3.8.3.1 MERIT GATED Consortium ............................................................................................... 29
3.8.4
PIM-SSM IMPLEMENTATIONS .......................................................................................... 29
3.8.5
IGMPv3 IMPLEMENTATIONS ............................................................................................. 29
3.8.6
SSM/IGMPv3 Applications ..................................................................................................... 30
3.9
Inter-domain Multicast Routing Policy (e.g. security) Description ................................................. 30
4
Quality of Service Components in Multicast Routing Protocols ............................................................. 32
4.1
QoS for PIM-SM ............................................................................................................................. 32
4.2
QoS Extensions to CBT ................................................................................................................... 33
4.3
QoS Impact on Multicast Routing ................................................................................................... 33
5
Outlook and Conclusion .......................................................................................................................... 36
6
References ............................................................................................................................................... 37
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
1
page 3 (38)
Introduction
Multicast services are based on the deployment of specific routing protocols in the
network. The aims of these multicast protocols are to build diffusion trees (shared or not) or to
advertise active multicast sources. The hottest topic concerning multicast routing is inter-domain
routing. Several architectures are proposed in IETF specification groups, using different protocols
(MSDP and MBGP, BGMP, DVMRP, …). Concerning intra-domain routing, PIM (using SM, DM,
SO) and IGMP protocols are de facto standards. Some of these protocols implement some quality
of service features.
Mulitcast address allocation is also a hot topic. Short-term solutions are static allocation solutions,
whereas a long-term solution (the malloc architecture) is a dynamic allocation solution.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 4 (38)
EURESCOM Technical Information
2
Intra-domain Multicast Routing Protocols
2.1
PIM-SM Version 2 and Anycast-RP Feature
Protocol Independent Multicast is an IP multicast routing protocol that has been designed to cope
with multicast groups featuring both sparse and dense types.
When operating in dense mode, the protocol is known as PIM-DM, and its algorithm is very similar
to the one used in DVMRP ([DVMRP]), that is the so-called flood-and-prune technique.
When processing multicast datagrams that pertain to sparse groups, the PIM-SM architecture relies
on the identification of one or several meeting point router(s) in the domain. These routers are
called the RP (Rendezvous Point) routers. They are used as the root of unidirectional distribution
shared trees. The information that relates to their localisation and the range of multicast addresses
they are able to process is distributed throughout the domain using a bootstrap mechanism. Thanks
to the involvement of this third party (the RP) in the communication, senders and receivers are able
to communicate without the need of knowing each other.
According to this feature, the PIM protocol is a new approach compared to the inefficient floodand-prune algorithm, which is a basic feature of the DVMRP protocol. Another major advantage of
PIM-SM consists in its ability to switch from an RP-centered shared tree (called the RPT – Rendezvous Point Tree) to a source-centered tree (called the SPT – Shortest Path Tree). For several years,
the PIM-SM protocol specification has dramatically evolved, because of retrieving an operational
deployment experience in the MBone, among other reasons.
MBone was designed at the beginning of the 90s to be a proof-of-concept platform for the
deployment of large scale IP multicast networks. It is an overlay network built over the Internet;
multicast enabled Internet routers with directly connected multicast capable local networks are
linked together by means of IPv4 tunnels, therefore resulting in an multicast capable internetwork.
Nowadays, due to its superiority in terms of efficiency and scaling properties, PIM has been largely
deployed over the MBone in place of DVMRP.
Jointly, a new working group, called PIM, has been created at the IETF with the objective to make
PIM protocol specifications fully qualified as Internet standards.
The objective of this review is to describe the new features that have been recently published at the
IETF. For further detail on the basics of PIM-SM, please refer to the review [EURESCOM-P911Deliverable1-Annex A] that was published in the context of the PIR2.1 of EURESCOM P911
Project. These features mainly relate to the security, the DR (Designated Router) identification
process, the advantages of running PIM in a bi-directional mode1, a state-refresh mechanism
designed to optimise the efficiency of the flood-and-prune algorithm, and recovery mechanisms.
2.1.1
PIM-SM New Features
2.1.1.1
DR Election
According to the PIM-SM specification [RFC-2362], the DR election process is defined to be
triggered only on multi-access network link types (such as broadcast environments, like an Ethernet
segment). This DR election process is very simple and based upon the highest IP address used by
one of the competing PIM routers. PIM neighbouring relationships are discovered by means of a
Hello protocol, that is, PIM Hello messages are periodically sent over every interface of a PIM
router where the PIM traffic can be forwarded.
Although it is very efficient, it lacks some flexibility in its ability to easily configure the location of
the DR routers. To say it differently, the fact that the traditional DR election process is only based
1
Traditional PIM sparse mode protocol is able to only build unidirectional distribution trees rooted
at the RP routers.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 5 (38)
upon the value of the IP address of the different PIM routers can be seen as a constraint.
Consequently, to remedy this lack of flexibility, a simple mechanism based upon a priority
parameter has been specified in an Internet Draft. Since the PIM working group has approved it,
this evolution has been directly incorporated (see §3.1.1) in the current PIM-SM specification
[DRAFT-PIM-SMv2]. In this specification, Hello messages might carry optional priority values.
On a multi-access link, where every PIM router has enabled that optional feature, the DR election
process is based upon the highest priority. In the other case, that is, if only one of the PIM
neighbours does not exhibit that optional feature, the DR election process remains based upon the
highest IP address.
2.1.1.2
Security Features
Recently, two drafts that relate to security concerns within a PIM domain have been published:
[DRAFT-PIM-AUTH] and [DRAFT-PIM-SMKEY]. The former describes a way to make use of
IPsec authentication header2 in PIM control messages. The objective consists in protecting the PIM
domain from disruptive behaviours due to unauthorized or damaged PIM control messages. This
authentication header would take place between the IP header and the PIM header. When such a
security mechanism is enabled it should apply to every PIM control messages.
The latter describes a method by which keys that are widely used for security concerns as well as
for authentication purposes are going to be distributed throughout a PIM domain. It uses a
combination of public and private keys. This Internet Draft defines a new entity within a PIM
domain called the Domain Key Distributor, which is in charge of the initial dissemination of the
keys. It allows the re-keying of the keys on a periodic basis. Therefore the use of those two
security-related specifications should be complementary.
2.1.1.3
Bi-directional Mode of Operation
This feature is described in [DRAFT-PIM-BIDIR]. It is a variant of PIM-SM that allows bidirectional shared distribution trees to be built. In this architecture, there is a new entity called the
Designated Forwarder (DF) that operates on each link of the multicast topology, whatever the link
type (NBMA or not). When dealing with downstream multicast flows, the Designated Forwarder
behaves like the DR router according to the PIM-SM terminology. On the other hand, when
receiving multicast flows that need to be sent upwards, the extended forwarding capability of DF
routers allow them to forward these flows upwards to the RP router.
The DF is defined per RP router, i.e. for a range of multicast group addresses that should be
forwarded along bi-directional trees. Therefore, there could be several legitimate DF routers on a
link for different multicast groups. The DF router election process occurs at RP discovery time.
The information of RP-mapping to multicast group ranges is disseminated throughout the entire
domain using the PIM Bootstrap mechanism.
The DF election process is fundamental to the efficiency of the bi-directional architecture. Since
the DF router that is elected on a link is the one that exhibits the best unicast route towards the
related RP router, it is therefore necessary for every router to share a coherent unicast view of the
domain. If it is not the case, it might occur that multiple routers on the same link could end-up
acting as the DF router, hence, leading to unwanted behaviours or the generation of forwarding
loops. Hence it is the reason why an important part of the specification focuses on defining a failsafe DF election procedure. This election procedure makes use of four new PIM messages - Offer,
Winner, Pass and Backoff messages, and four new timers.
Unidirectional trees and bi-directional trees can coexist within a PIM domain. The bi-directional
PIM specification [DRAFT-PIM-BIDIR] provides the necessary extensions of the current PIM-SM
specification. In particular, it describes a new bit called the B-bit that stands for „Bi-directional“ bit
in the Encoded-Group Address field of PIM bootstrap and Candidate-RP Advertisement messages.
2
Also known as AH in the IPsec terminology
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 6 (38)
EURESCOM Technical Information
It is the will of the network administrator of the domain to decide which multicast groups are using
the bi-directional trees or not. Moreover, like in the classical unidirectional mode, it is possible to
distribute multicast group ranges over several RP routers when building bi-directional trees for
such groups.
One direct benefit provided by this bi-directional flavour of the PIM-SM protocol relies upon the
relief of the needs for maintaining source-specific states in PIM routers. This kind of architecture is
suitable for groups where the number of sources might be important. For instance an ISP could
benefit from such an architecture to deploy audio/video forwarding services over an IP multicast
network. It would allow receivers to be able to interact in multicast mode more efficiently with the
main audio/video server or even with receivers.
On the other hand, when deploying an IP multicast network based upon bi-directional shared trees
only, and since the requirements for (S, G) state processing and storing in the corresponding PIM
routers are significantly reduced, the multicast paths may be sub-optimised with regard to the
multicast paths that would result in using source-based trees. Therefore the multicast network
might experience higher latency and less efficient bandwidth utilisation.
At last, a general property of the PIM-BIDIR specification compared to the traditional PIM-SM
operation lies in its ability to completely separate the triggering of PIM control messages from
multicast data flows. In PIM-BIDIR, every multicast-forwarding path is set up before any multicast
flow starts being forwarded along the shared tree.
2.1.1.4
Generation Identifier
This feature was first presented in [DRAFT-PIM-GENID] before being ultimately incorporated in
paragraph 3.1.1 of [DRAFT-PIM-SMv2]. It describes a recovery mechanism that reduces the delay
from which the router is anew up to date with regard to the status of its multicast forwarding table
and has fully recovered its place within the multicast domain topology.
Every time a router reboots or in case one of its interfaces goes back and forth between up and
down states, this router should randomly determine a new identifier and announce it in subsequent
Hello messages. Therefore, a router that receives a Hello message from a PIM neighbour could
determine if it has rebooted or not.
In case the reboot of a router is detected, the currently elected DR router should unicast to that
router its latest PIM Bootstrap message. Furthermore if that router is an upward router with regard
to some multicast route entries, the downward DR router should immediately re-send to it all
Join/Prune PIM messages that pertain to those multicast route entries.
2.1.1.5
Anycast-RP Feature
Although PIM-SM allows for multiple Rendezvous Points to be defined for a given group in a
PIM-SM domain, only a single RP per group can be active at a given time. Therefore, the
forwarding of multicast packets is not optimal (the joins are sent to the RP regardless of the
topological distance between the RP, the sources and the receivers), the distributing encapsulation
load among RPs covering the multicast group space needs manual configuration, the convergence
delay involved in switching to the backup RP is not optimal.
The any cast-RP feature is a mechanism to allow an arbitrary number of RPs per group in a single
shared-tree PIM-SM domain. The set of RP routers serving the multicast group (or groups) are
configured with a common unicast IP address (such as a loopback interface). This address is used
to advertise the group(s). Thanks to the unicast routing, the join/register messages will be sent to
the topologically closest RP, thereby distributing the load among RPs.
Note that MSDP speakers must use globally unique addresses to peer each other.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
2.1.2
PIM-DM New Features
2.1.2.1
State Refresh
page 7 (38)
Recently a new Internet Draft [DRAFT-PIM-REFRESH] has been published by the PIM working
group, and this specification aims at extending the PIM-DM protocol efficiency over large IP
multicast enabled internetworks. This Internet Draft provides the requirements for both a new timer
that is called the SRT – State Refresh Timer - and the related PIM control message that is called the
State-Refresh message.
The SRT timer is associated with any (S, G) entry; upon expiration, a State Refresh message is sent
one hop downwards the forwarding tree which causes downstream SRT (S, G) timers to be reset to
their initial value (Refresh Interval). Furthermore when this State Refresh message is received on
the right incoming interface, it causes any outgoing interfaces that are in a prune state to have their
(S, G) prune timers be refreshed; therefore preventing the need for this multicast flow to be
reflooded on these interfaces.
There are only the first-hop routers (i.e. the routers which are directly connected to the source(s))
that originate PIM State Refresh messages; when the (S, G) route entry timer expires they no
longer originate them; therefore State Refresh periodical control mechanism is conditioned by the
receipt of multicast data flow at first-hop routers.
2.1.2.2
Generation Identifier
This feature is described in paragraph 6 of [DRAFT-PIM-DMv2]. In its purpose, this GenID
mechanism is very similar to the one that applies to PIM-SM: it aims at reducing the delay from
which a multicast router recovers from a shutdown. Though it uses PIM Hello messages to convey
the GenID identifier associated with each interface, this feature differs completely from the way
PIM-SM processes them. Two main processing are defined depending on which type of interface 3
the new GenID is received.
When a router receives a new GenID on one of its outgoing interfaces from a downstream router
with respect to a (S, G) distribution tree, the former should turn the interface into forward state and
should possibly send a Graft message upwards.
When a router receives a new GenID on an incoming interface from an upstream router with
respect to a (S, G) forwarding tree, and if its (S, G) route entry is inactive 4, the former should
immediately send a (S, G) Prune message to the upstream router.
2.2
Existing PIM-SM Implementations
This report contains information about intra-domain IP multicast solutions provided by some of the
major network equipment vendors. Our research concerns the traditional host-router protocols
(IGMP) and the intra-domain multicast routing (router-router) protocols: PIM is today the standardde-facto, but also DVMRP and MOSPF are considered.
IP multicast switching protocols like CGMP (Cisco Group Management Protocol), LGMP (Lucent
Group Management Protocol), IGMP snooping and GMRP (GARP Multicast Registration
Protocol) are outside the scope of this document.
2.2.1
NORTEL NETWORKS
BayRS (Bay Routing Services) is a comprehensive suite of routing /switching protocols running on
the entire line of Nortel Networks routers, routing hubs, routing/switches, and related network
devices. BayRS 13.20 supports IGMP and PIM-SM.
3
Incoming or outgoing interface with regard to any (S, G) route entries of the multicast routing table
that is, all outgoing interfaces are pruned but the global timer of the route entry has not yet
expired
4
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 8 (38)
EURESCOM Technical Information
DVMRP and MOSPF are also supported.
2.2.2
LUCENT
2.2.2.1
IP Navigator MPLS
IP Navigator MPLS provides a full range of IP services to the carrier-class B-STDX 8000/9000,
CBX 500, and GX 550 WAN switches. IP Multicast protocols - Internet Group Multicast Protocol
(IGMP), Distance Vector Multicast Routing Protocol (DVMRP) and Multicast OSPF (MOSPF) are being added to the IP Navigator software for the core switching products. Protocol Independent
Multicast (PIM) will be supported in a next release.
2.2.2.2
Cajun P550
The Cajun P550 Routing Switch supports the full suite of intra-domain multicast protocol including
PIM.
2.2.2.3
MAX4000/MAX6000
MAX 4000 and MAX 6000 are Multiprotocol WAN Access Switches and they are ideal for
International Internet Service providers and large companies that have large numbers of
predominantly analog dial-in users.
These equipment supports “IGMPv2 forwarder (or proxy)” functionalities (software release
7.0.22). This means that the clients connected (via dial-up links) to MAX4000 (6000) can be only
receivers. MAX equipment are only enabled to forward IGMP messages coming from clients; vice
versa they can forward (to the registered receivers) IP multicast packets coming from multicast
routers.
2.2.3
ALCATEL
Alcatel PowerRailTM 5200 Routing Switch, designed to meet the demands of large-scale network
backbones and ISPs, supports IGMP, DVMRP and PIM-SM.
2.2.4
HUGHES NETWORK SYSTEMS
The IXR5000 is a full-featured router. The software suite delivers a complete set of routing
protocols including IGMP, DVMRP (v1 and v3) and PIM (Sparse and Dense).
2.2.5
CABLETRON
SmartSwitch Routers supports IGMP, DVMRP, PIM-DM and PIM-SM.
2.2.6
CISCO
Cisco IOS 12.0, supported for all router platforms, is recommended for all multicast environments.
IOS 12.0 has the status of General Deployment (GD) since IOS 12.0(9). It is thus applicable for all
environments.
IOS 12.0 includes all multicast features previously available with IOS releases up to 11.3. This set
includes:

IGMPv1 / IGMPv2

PIMv1

DVMRP interoperability

Stub IP Multicast routing
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 9 (38)
In addition, 12.0 supports:

PIMv2 PIM sparse mode version 2
(introduced in 11.3T)
There are minor but partly unavoidable interoperability restrictions between PIMv1 and PIMv2 in
IOS.
When using IOS to inter-operate with other vendor products, PIM-SM v2 is almost always required
because other vendors only started out with PIM-SM v2 and will not inter-operate with a pre IOS
12.0 release fully on PIM-SM.
PIM-SM v2 main (realized) features include:

PIM-SM v2 with single RP statically assigned.

PIM-SM v2 with Auto-RP configuration.

PIM-SM v2 with two (or more) RPs using the “Anycast RP“ mechanism (the two RPs have
the same IP address configured) and MSDP protocol for the RPs synchronization.
2.2.7
Ericsson
The AXI540 Edge Aggregation router and the AXI520 Core Router, running the IPaction software,
support IGMP, DVMRP v3, PIM Dense Mode, PIM Sparse Mode (v2).
The software of the AXI510 Edge router (ADSL Service Solution) will be enhanced to support
IGMP and PIM-SM.
2.2.8
SIEMENS
The MainStreetExpress 36190 Core Services Switch supports PIM-SM.
2.2.9
3COM
Enterprise OS Software Version 11.4 supports PIM-SM and IGMPv2.
2.2.10
Juniper Networks
Juniper Networks provides high-performance IP networking systems that enable service providers
to meet the demands of the rapidly growing Internet. Juniper comprises a product portfolio given
by three “Internet Backbone routers” called M20, M40 and M160. These platforms run the JunOS
Internet Software (last available release is 4.0).
Junos software supports a comprehensive suite of Internet-scale routing protocols including the
following IP Multicast routing protocols:

IGMP (version 1 and 2)

DVMRP

PIM (both dense and sparse mode are supported)

MSDP

MBGP
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 10 (38)
2.2.11
EURESCOM Technical Information
Avici Systems
Avici, founded in 1996, provides TSR (Terabit Switch Router) to be used by carriers as equipment
for backbone core networks.
TSR equipment supports PIM-SM (v2). At the moment they do not support IGMP.
2.2.12
PIM and UNIX
The available implementations of PIM (v2) for UNIX platforms are:
2.3

The pimd USC FTP site
(http://catarina.usc.edu/pim/pimd/)

The PIM-SM GateD implementation from ISI (http://www.isi.edu/~eddy/pim/pim.html ).

The PIM-DM GateD implementation
(http://www.antc.uoregon.edu/GATED/ ).

The pimd-dense (http://www.antc.uoregon.edu/PIMDM/pimd-dense.html )University of
Oregon standalone implementation.
Intra-domain
Description
(stand-alone
Multicast
PIM-SM
from
Routing
the
+
kernel
University
Policy
(e.g.
patches)
of
Oregon
security)
Multicast routing decisions are based on the source and not on the destination (like unicast). Each
router looks at the source of the traffic and determines the closest interface to it (RPF check) and
performs RPF checks to obtain the best path to the source. Multicast routing protocols can be
classified in dense mode and sparse mode.
Dense mode use a flood and prune mechanisms to build a multicast distribution tree rooted at the
source (a source-based tree), giving the shortest and most efficient path from source to receiver.
However, the use of flooding across the Internet will not scale.
Sparse mode protocols implement a shared distribution tree, rooted at a core router in the network
called a rendezvous point (RP). RP entity will keep information of all active sources in a domain.
Only network segments that have active receivers, which have explicitly requested the data, will be
forwarded the traffic. If a router is connected to a host that wants to receive data, it need to use
RPFs to obtain the shortest path to the RP and all the receivers join the tree at the RP.
Since the RP will be the root of the shared tree, it is obvious that RP placement will be a critical
decision in an implementation of PIM-SM environment. The RP need to be located in a good
position of the core of a network to minimize routing on the shared tree. Also, the requirement of
single RP for a given group is insufficient in the world of intra-domain routing as well as in interdomain area. A single RP has several implications, including traffic concentration, slow
convergence when an active RP fails and distant RP dependencies.
MSDP (Multicast Source Discovery Protocol) [DRAFT-MSDP] provides the solution in the intradomain space with a technique called Anycast RP [DRAFT-Anycast-RP], where multiple routers
can be configured with the same IP address on loopback interfaces. With this configuration,
network provides fault tolerance and a load sharing within a single multicast domain. A set of
mechanisms can be done to implement a good solution for the configuration with multiple RPs per
group. With MSDP, the anycast RPs are able to exchange information regarding active sources
registered to each other. All the RPs is configured to be MSDP peers to each other.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 11 (38)
Suppose that we have some anycast RPs in our network. The users are routed to the topologically
nearest RP; if that router fails, they would be routed to the next closest RP. This provides a scalable
way for delivery multicast information.
The authentication of PIM control messages exchanged among the entities (such as routers), that
define the routing infrastructure, is the core of the problem. The information of this messages must
be allowed to transit unmodified from the sender to the destination and inform entities about the
state of the network.
All PIM control messages use IPSec to provide protocol message integrity protection and will carry
an IPSec authentication header that would take place between IP header and PIM header [DRAFTPIM-AUTH]. The use of methods for authentication can protect routers from altered and/or
unauthorized PIM messages. Where there is a breach in security, those messages that travel only
one hop may affect a small number of routers or multicast groups while other multi-hop messages,
such as the bootstrap messages, may affect a larger number of routers. Some controls of unicast
protocol may be desired for different PIM messages types.
Two message authentication methods based on manual key distributions may be used to preventing
unauthorized routers from participating in protocol actions. In “Equal Opportunity“ Method, all
routers within the domain use the same key and the router that gained the shared secret, gains the
ability to conduct any action of the protocol. The “Differentiated Capabilities“ Method, adds
additional securities that some PIM routers requiring (Candidate RPs routers and bootstrap routers
(BSR)). The difference from the above method is that the candidate BSRs and RPs use two more
keys to protect their messages.
The messages integrity protection and origin authentication depends on the policy used on the
security transformations that we use in PIM-SM environment.
This proposal suggests a key management of the authentication keys used by the routing entities
but don’t specify how the keys must be delivered to the relevant network entities in the domain. A
new document was produced by pim IETF working group [DRAFT-PIM-SMKEY] to cover a key
distribution method based on the combination of public key and private key cryptography and a
Domain Key Distributor (DKD) entity. The Rendezvous Point, the BootStrap Router, the
Designated Router and the others PIM routers are identifies as elements that require a specific key.
The public key is defined and delivered only for some entities and used in a ‘closed’ system, where
only certain designated entities know the public key of others entities. All the keys are limited to a
simple PIM domain.
The key management process may be initialising using: a manual configuration of the keys into the
corresponding entities and a dynamic configuration that requires a global public key pair in each
router, which may be manually configured or loaded. In this case a router establishes a secure
channel with the DKD of the domain.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 12 (38)
EURESCOM Technical Information
3
Inter-domain Multicast Routing Protocols
3.1
Address Allocation/Management : The “malloc” Architecture
Given that the address space of multicast addresses is limited, (224.0.0.0/4 ~ 228 ~ 256M individual
addresses), any wide range deployment of multicast services and applications worldwide, needs to
take into account the scarcity of this resource. Towards this purpose, the MALLOC IETF working
group was established with the objective to define protocols for the dynamic allocation of IP
multicast addresses.
A draft overview of the proposed architecture is as follows. Components in this are explained
underneath:
To Other Prefix coordinators in other peers
LAYER3 (MASC)
Domain
Prefix
coordinator
Prefix
coordinator
Layer2
(AAP)
MAAS1
1
MAAS2
1
MAAS3
1
Client3
Client4
Layer1
(MADCAP)
Client1
Client2
Fig. 1: The malloc architecture The "malloc" architecture consists of 3 layers:
1.A host-to-server communication layer, wherein a host can request the allocation of one or more
multicast addresses from a Multicast Address Allocation Server (MAAS). The server allocates the
requested addresses, or not, according to whether it has available addresses to allocate, and whether
the specifications from the client fit the available addresses (e.g. expiration time, address grouping,
etc.). For this first layer, there is an implementation in RFC 2730 (Multicast Address Dynamic
Client Allocation Protocol – MADCAP). This protocol was based on ideas from the
implementation of DHCP, which is its equivalent for unicast addresses.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 13 (38)
2. A MAA server-to-server communications protocol within a domain that has a single
administrative authority. This domain could be identified with an existing Autonomous System
(AS). MAA Servers communicate within the domain, to inform each other of allocated addresses
under their constituency, so that there is no collision of allocated addresses, and allocation
efficiency is achieved. For this second layer, an internet draft has been produced, with a proposed
implementation [draft-ietf-malloc-aap-04]. The proposed AAP protocol (Multicast Address
Allocation Protocol) also defines ways for MAASs to communicate with entities called Prefix
Coordinators in Layer 3 below.
3. An inter-domain communications protocol that will coordinate the allocation of addresses in a
global scope. The central entity in this protocol is a Prefix Coordinator for each domain, which is
implemented within a border router of a domain (or AS, as mentioned above). Prefix coordinators
communicate between them, to ensure that each has a reserved address space that it is allowed to
allocate. Prefix coordinators can request allocation of more addresses, if the MAASs in their
constituency request more addresses than are available at any given time. Addresses are allocated
in groups that carry a common prefix (hence Prefix Coordinators), in order to integrate with
existing multicast inter-domain routing protocols (MBGP and BGMP). For this third layer, an
internet draft has been produced, with a proposed implementation [draft-ietf-malloc-masc-06]. The
proposed MASC protocol (Multicast Address Set Claim) does not allocate addresses unless there is
a request for them, meaning that a Prefix Coordinator might not have any address available for
allocation if its underlying constituency (domain) has not requested addresses. However, as soon as
an address request is made (from Layer 1 through Layer 2 above, this request can be served
through MASC communications between the Prefix Coordinator and its neighbouring peers.
Overall, standardization in this area is still on going, and it is expected that available commercially
implementations for the whole architecture will be in place during mid 2001.
3.2
Border Gateway Multicast Protocol (BGMP)
BGMP is a protocol for inter-domain multicast routing. It allows to build bi-directional interdomain shared trees (and source-specific when explicitly required by the multicast IGP). In BGMP,
the root of a multicast shared tree is the entire domain that advertises the corresponding group
prefix. BGMP assumes that those group prefixes have been previously assigned to specific
domains (using the MASC protocol, for instance).
In order to implement bi-directional trees, a BGMP router must maintain a multicast routing
information base. Such a RIB is created by running an EGP able to carry multicast prefixes (MBGP, for instance). Each BGMP router also maintains a tree state table composed of <Sourceprefix, Group-prefix> entries that have been explicitly joined by a set of targets. Each entry stores a
list of such targets.
BGMP has to co-operate with the multicast IGP running inside the domain. BGMP may have to
create a source specific entry if it is asked for by the multicast IGP. The BGMP target list may be
made up of external BGMP peers or internal multicast IGP peers. When the multicast IGP receives
a Join/Prune packet, it processes the packet according to its own rules before notifying BGMP if
necessary.
3.2.1
Join Processing
When a BGMP router receives a <*,G> (or <S,G>) Join from another BGMP peer or from the
multicast IGP, it checks for a matching tree state entry:
If a matching entry is found and the peer is already listed in the target list, no further actions are
taken.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 14 (38)
EURESCOM Technical Information
If neither <S,G> entry nor <*, G> entry are found, a new entry is created. For a <S,G> entry, the
associated target list is made up of the target from which the Join was received. For a <*,G> entry,
the target list is made up of the target from which the Join was received, plus the next-hop towards
G, thereby creating a bi-directional tree in which the root domain works as a rendezvous point
domain.
Once the entry has been created, a Join message may be sent to the corresponding peer according to
the new entry in order to build the tree:
If the new entry is a <*,G>, a BGMP <*,G> Join is sent to the next-hop towards G according to the
multicast RIB if this next-hop is an external peer.
If the new entry is a <S,G>, a BGMP <S,G> Join is sent to the next-hop towards S according to the
EGP RIB if this next-hop is an external peer and the router doesn’t have any active <*,G> entry.
If the next-hop is an internal peer, a Join <*,G> (or <S,G>) is sent to the Multicast IGP.
If there is no next-hop peer (no next-hop for G in the multicast RIB and no next-hop for S in the
EGP RIB), a Join <*,G> (or <S,G>) is sent to S or G using the IGP RIB.
3.2.2
Prune Processing
When a BGMP router receives an <S,G> or <*,G> Prune message from another BGMP peer or
from the multicast IGP, it checks for a matching tree state entry:
If a matching entry is found, the peer from which the Prune is received is removed from the target
list.
If no <S,G> entry is found for an <S,G> Prune, but a <*,G> entry exists, a <S,G> entry is created
with the target list copied from the <*,G> entry minus the peer from which the Prune was received.
If, after the removal of a peer from a target list, this target list becomes empty, a Prune message
must be sent to the next-hop peer towards G (for a <*,G> entry), or towards S (for an <S,G> entry,
and only if the router doesn’t have a <*,G> entry with non empty target list):
The BGMP Prune message is sent to the next-hop if it is an external peer.
The BGMP Prune is relayed by the Multicast IGP if the next-hop is an internal peer.
If there is no next-hop peer (no next-hop for G in the multicast RIB and no next-hop for S in the
EGP RIB), a Join <*,G> (or <S,G>) is sent to S or G using the IGP RIB.
3.2.3
Multicast Data Packet Processing
When a BGMP router receives a multicast data packet with multicast prefix G from the source S,
no RPF check is done, and the router checks for a matching entry:
If a matching (S,G) BGMP tree state entry is found and the packet is received from the next hop
towards S, the router forwards the packet to the set of targets according to the matching (S,G)
BGMP entry. If the packet is received from another neighbour, the packet is dropped.
If a matching (S,G) BGMP entry doesn’t exist, the router checks for a matching (*,G) BGMP tree
state entry, and forwards the packet according to the set of targets of this entry.
If no (*,G) state entry exists, then the packet is sent to the next-hop EGP peer for G, according to
the multicast RIB.
Thanks to the multicast RIB, the shared tree is bi-directional and allows a non-member source to
send traffic to the group.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
3.2.4
page 15 (38)
Route Change Notification
When the multicast RIB changes (route change, addition of a new prefix, withdrawal of an existing
route) on a border router, BGMP must be notified. A new prefix can be added in the multicast RIB
because of the reception of a multicast EGP notification (M-BGP, for instance) or because of a new
association of a class-D prefix with the domain the border router belongs to (using the MASC
protocol, for instance).
There are two possible changes:

A group prefix change. All the involved <*,G> target lists must be updated. The router
sends a <*,G> Join to the new next-hop target, or a <*,G> Prune to the old next-hop target.

A source prefix change. All the involved <S,G> target lists must be updated. The router
sends a <S,G> Join to the new next-hop target, or a <S,G> Prune to the old next-hop target.
3.2.5
Interaction With PIM-SM
On a border router, changes about internal membership can be learnt by the Multicast IGP. If no
source is specified, the M-IGP must notify BGMP by sending a <*,G> Join or a <*,G> Prune, as
appropriate. If the M-IGP of a border router that is the next-hop router for a particular source S
learns that a receiver wants to join this specific source S, the M-IGP sends an <S,G> Join to
BGMP. If, afterwards, such a receiver no longer exists, the M-IGP sends an <S,G> Prune to
BGMP.
In order to minimize the number of encapsulations/decapsulations, BGMP border routers to a PIMSM domain should be candidate to the Rendezvous Point election.
When a border router receives an external packet, there are 2 possibilities:
The border router is the RP for the group. The router must forward the packet according to the
PIM-SM shared-tree outgoing interface list.
The border router is not the RP for the group. If the router does not have an <S,G> entry for the
group, it creates it and encapsulates the packet in PIM-SM register and unicasts it to the RP, which
is one of the other border routers.
3.3
MBGP
The BGP-IV protocol, as it is specified by [RFC-1771], allows only the propagation of IPv4specific ([RFC-791]) information in unicast transmission mode. This is due to the restriction on the
type of the addresses that can be carried in the NLRI field. Taking into account the massive
deployment of the BGP protocol in the current Internet, and the huge amount of applications that
rely on other communication protocols (other than the IPv4-unicast protocol), it has seem
favourable to use the resources of the BGP protocol to carry routing information that is specific to
other communication protocols, and more specifically to the multicast-IPv4 protocol and IPv6.
According to the actual specifications ([RFC-1771]), only three types of information carried by the
BGP protocol are specific to the IPv4 protocol (in unicast transmission mode):

The NEXT_HOP attribute (as this attribute carries an IPv4 address);

The AGGREGATOR attribute (also carrying IPv4 addresses);

The NLRI field in the UPDATE messages, consisting of address-prefixes conforming the
IPv4 format.
In the (realistic) assumption that the entire collection of BGP routers from one autonomous system
are characterized by at least one IPv4 address, the capacity of the protocol to carry routing
information that is specific to other protocols (other than unicast IPv4) is reduced to:
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 16 (38)
EURESCOM Technical Information

the ability of the protocol to associate a certain communication protocol with an
information of the type “next hop” (eventually encoded according to the addressing format
associated with the concerning communication protocol);

the ability of the protocol to associate a certain communication protocol with the
information inserted in the NLRI field that is eventually carried by an UPDATE message.
Moreover, the information carried in the NEXT_HOP attribute has only significance if it is
associated with a set of address prefixes as given for example in the NLRI field of an UPDATE
message - address prefixes that are accessible through the router defined by that NEXT_HOP
attribute. This observation suggests that the advertisements of routes leading to effectively
accessible prefixes should be separated from the advertisements of no longer accessible routes
(unreachable prefixes).
This is why [RFC-2283] defines two supplementary attributes: the attributes MP_REACH_NLRI
(MultiProtocol REACHable NLRI, carrying the information related to the entire set of destinations
reachable through the “next hop” - the “next hop” itself being also identified in the attribute), and
MP_UNREACH_NLRI (MultiProtocol UNREACHable NLRI, carrying the specific information
related to the set of newly unreachable destinations). These both attributes are of the type “optional
and non-transitive”; this means that a router that does not recognize the BGP extensions will ignore
the information carried in these attributes and will not propagate it to its BGP peers.
3.3.1
The MP_REACH_NLRI Attribute
The MP_REACH_NLRI attribute consists of one ore more <Address Family Information, Next
Hop Information, NLRI> triplets according to the following format (figure 2):
+---------------------------------------------------------+
| Address Family Identifier (2 octets)
|
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet)
|
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet)
|
+---------------------------------------------------------+
| Network Address of Next Hop (variable)
|
+---------------------------------------------------------+
| Number of SNPAs (1 octet)
|
+---------------------------------------------------------+
| Length of first SNPA(1 octet)
|
+---------------------------------------------------------+
| First SNPA (variable)
|
+---------------------------------------------------------+
| Length of second SNPA (1 octet)
|
+---------------------------------------------------------+
| Second SNPA (variable)
|
+---------------------------------------------------------+
| ...
EDIN 0054-1010
|
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 17 (38)
+---------------------------------------------------------+
| Length of Nth SNPA (1 octet)
|
+---------------------------------------------------------+
| Nth SNPA (of Next Hop) (variable)
|
+---------------------------------------------------------+
| ...
|
+---------------------------------------------------------+
| Length of Last SNPA (1 octet)
|
+---------------------------------------------------------+
| Last SNPA (variable)
|
+---------------------------------------------------------+
| Network Layer Reachability Information (variable)
|
+---------------------------------------------------------+
- Fig. 2: the MP_REACH_NLRI attribute format -
The AFI (Address Family Identifier) identifies the communication protocol used, and therefore also
the type of the address in the next field (field “Network Address of Next Hop”). The communication
protocol is identified according to the definitions in [RFC-1700];
The field sub-AFI (Subsequent Address Family Identifier) supplies information that is
complementary to the information in the NLRI field of the attribute. Three values have been
defined in [RFC-2283]:

Type 1: the information inserted in the NLRI field is related to a unicast transmission
mode;

Type 2: the information inserted in the NLRI field is related to a multicast transmission
mode;

Type 3: the information inserted in the NLRI field is related to the transmission modes
unicast and multicast.
The field “Nth SNPA of Next Hop” is a variable length field that contains a SNPA (SubNetwork
Point of Attachment) from the router from which the network address is inserted in the “Network
Address of Next Hop” field of the attribute;
The information related to the “next hop” through which the entire set of destinations inserted in
the NLRI field is accessible, defines the network address from the router that should be used to
reach that entire set of destinations
An UPDATE message containing the MP_REACH_NLRI attribute must also contain the ORIGIN
and the AS_PATH attributes, whether the communication is of the eBGP or the iBGP type.
Moreover, within the eBGP communication context, the receiver of an advertisement containing
the MP_REACH_NLRI attribute must verify that the first Autonomous System identifier included
in the AS_PATH attribute effectively identifies the Autonomous System to which the announcer of
the advertisement belongs. If that Autonomous System identifier does not match the announcer,
then the receiver must send a NOTIFICATION message indicating that the AS_PATH attribute is
erroneous.
3.3.2
The MP_UNREACH_NLRI Attribute
The MP_UNREACH_NLRI Attribute consists of one or more <Address Family Information,
Unfeasible Routes Length, Withdrawn Routes> triplets, encoded in the following way (figure 3):
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 18 (38)
EURESCOM Technical Information
+---------------------------------------------------------+
| Address Family Identifier (2 octets)
|
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet)
|
+---------------------------------------------------------+
| Withdrawn Routes (variable)
|
+---------------------------------------------------------+
- Fig. 3: the MP_UNREACH_NLRI attribute format –
An UPDATE message carrying the MP_UNREACH_NLRI attribute must not contain any other
attributes.
3.4
Multicast Source Discovery Protocol (MSDP)
Multicast Source Discovery Protocol (MSDP) is a protocol that allows connecting multiple PIM
Sparse-Mode (SM) domains [RFC-2362]. MSDP allows multicast sources for a group to be known
by Rendezvous Point(s) (RPs) which would be located in different domains.
3.4.1
Overview
A RP within a PIM domain will have a MSDP peering relationship with a RP in another domain,
which will be established over a TCP connection (well-known port 639) between the two peers.
The purpose of this mechanism is to allow domains discover multicast sources from other domains.
Each domain will have one or more connections. If the multicast sources are of interest to a domain
that has receivers, multicast data is delivered over the normal, source-tree building mechanism in
PIM-SM.
The TCP connections between MSDP peers may be congruent to the BGP connections, but the
MSDP protocol can be activated within a single autonomous system.
3.4.2
Procedure
In a given SM domain, a source generates traffic towards a multicast group. The DR (Designated
Router) which is directly connected to the source will send a “Register” message to the RP which
happens to be a MSDP peer. From that perspective, the MSDP peer knows if there are active
sources within the domain. On the other hand, any RP within a SM domain knows if there are
receivers, thanks to the reception of “join” messages.
Thus, any MSPD-enabled RP of a given SM domain, can tell its MSDP peers what are the active
sources, therefore indicating such peers that they can actually join the corresponding source trees.
The corresponding information is sent over the TCP connection that has been established between a
pair of MSDP peers, and it consists in generating a “Source Active” (SA) message that contains the
following fields:

source address of the multicast data source;

group address this data source sends to;

IP address of the RP which sends the SA message.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 19 (38)
Each MSDP peer that receives such SA messages will forward them according to what the
[DRAFT-MSDP] specification calls a “peer-RPF flooding” kind of forwarding, to prevent looping.
When an SA message is received, the “peer-RPF flooding” mechanism is run upon the following
rules:

Determine which peer is the next hop towards the originating RP of the SA message. Such
a peer is called an “RPF neighbour”. Such a peer is determined as follows:

If the receiving router has a MSDP peering with the SA originator, the originator is
the RPF neighbour .

If the receiving router has a MSDP peering with the external Next-Hop towards
which the router is poison-reversing the MBGP route towards the SA originator,
this Next-Hop is the RPF neighbour .

If the receiving router has any MSDP peerings with neighbours in the AS from
which it received the SA message, but no external MBGP peering with them, the
neighbours with the highest IP address is the RPF neighbour.

If the SA message was received from an internal MSDP peer, and this peer is the
internal MBGP advertiser of the route towards the SA originator, this internal peer
is the RPF neighbour.

If none of the above match, and the receiving router has a default-peer configured,
the MSDP default-peer if the RPF neighbour. Note that a default-peer should not
be configured on routers that run BGP or MBGP in order to avoid loops or blackholes.

If the MSDP peer receives the SA from a non-RPF neighbour towards the originating RP,
it will drop the message.

Otherwise, the message will be forwarded to all its MSDP peers (except the one from
which it received the SA message).
When each MSDP peer of a given SM domain receives a SA message, it determines (according to
the PIM-SM procedure) if there are receivers that may be interested in the group G that is described
in the SA message. If the corresponding (*, G) state exists (in the receiving MSDP peer) while the
outgoing interface list (oif list) is not empty, then the RP will trigger an (S, G) join towards the
source. This sets up a branch of the source-tree, and the corresponding multicast datagrams that
arrive at the RP (of the domain where the source does not reside) will be forwarded down the
shared tree of the corresponding domain.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 20 (38)
EURESCOM Technical Information
This procedure is illustrated by figure 1:
MSDP peering
State (S, G) created
RP1
RP2
Sends (S, G) register to RP2
Sends (S,G) SA mesage DR
(*, G) Joins towards RP1
SM domain #2
SM domain #1
Source S
(S, G) joins
Fig. 4: MSDP procedure Comments related to figure 4:

SA message receivers are not supposed to keep a (S, G) state, but if they do (thanks to the
activation of a SA caching state in the router), newly formed MSDP peers can get MSDP
(S, G) state sooner and therefore reduce join latency for new members ;

The SA messages will be sent periodically as long as at least one source of a given domain
is active, but the MSDP peers must not send more than one SA message (for a given (S, G)
state) within a 1-minute interval ;

Intermediate MSDP peers should not originate SA messages for sources that belong to
other domains (they do generate SA messages for the sources they are « responsible of »
within their domain) ;

For performance and security purposes, a SA message filtering capability can be activated
by the MSDP peers which are located in the domain where the sources (to be described in
the corresponding SA messages) reside The other RPs should not filter such messages,
because the so-called flood-and-join model could therefore be broken (loss of
connectivity);

SA messages have the ability to encapsulate multicast data for bursty sources.
While RPs that receive SA messages are not required to keep MSDP (S,G) state, n RP should cache
SA messages by default. One of the main advantage of caching is that since the RP has MSDP
(S,G) state, join latency is greatly reduced for new receivers of G.
MSDP is not limited to the deployment across different (BGP) domains. It can be used within an
autonomous system when it is desired to deploy multiple RPs for the same group ranges. As long
as all RPs have established a MSDP peering relationship with each other, each of these RPs can
learn about active sources as well as RPs in other domains.
Data packets may be encapsulated in UDP, GRE and TCP. Encapsulation type is a configuration
option.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 21 (38)
A MSDP implementation may use IPSec or keyed MD5 to secure control messages. When
encapsulating SA data in GRE, security should be relatively similar to security in a normal IPv4
network, as routing using GRE follows the same routing that IPv4 uses natively.
3.5
PIM-SO
This report collects some information concerning the recently proposed “Source Specific Multicast
model“ and suggested implementations. In particular the protocol PIM-SO (PIM-Source Only) is
going to be developed by slightly modifying the existing PIM-SM protocol.
The report consists of two parts; the first one lists the Internet Drafts related to the topic and shortly
describes the contents. The second part inspects more deeply the SSM model paying particular
attention to the PIM-SO proposed solution.
The innovative ideas of the model, whose main goal is the realization of a commercially available
IP multicast service, and the importance of the players who are supporting this model (Sprint,
Nortel, Cisco) justify the growing interest of the Internet multicast community.
3.5.1
Source Specific Multicast Model Internet Drafts
The SSM model is described in the following recently posted internet-drafts:
C. Diot, and others: “Deployment of PIM-SO at Sprint”
<draft-bhattach-diot-pimso-00.txt>
This document considers the requirements for implementing PIM-SO which will allow the creation
of source-based multicast trees across multiple domains in the Internet. PIM-SO realizes the
EXPRESS multicast service model in which there is a single source for every multicast group, and
group membership and addressing is based on a multicast group address (G) as well as the source’s
unicast address (S).
Implementation by August 2000 in Sprintlab’s experimental network.
By the end of the year it will be ready to be incorporated in Sprint’s multicast backbone.
N. Bhaskar, I. Kouvelas: “Source-Specific Protocol Independent Multicast”
<draft-bhaskar-pim-ss-00.txt>
PIM-SS is a variant of PIM-SM that only builds source specific shortest path trees.
These trees are built directly on receiving group membership reports that request a given source.
It is specifically suited for existing multicast applications for which there is expected and intended
to be exactly one source.
PIM-SS in conjunction with the IGMPv3 extensions for Source-Specific Multicast provides the
Source-Specific Multicast service model suitable for one-to-many communication.
H. Sandick, B. Cain: “PIM-SM rules for support of single-source multicast
<draft-sandick-pimsm-ssmrules-00.txt>
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 22 (38)
EURESCOM Technical Information
The document describes the minor changes in PIM-SM rules to support SSM routing semantics.
H. Holbrook, B. Cain: “Source-Specific Multicast for IP”
<draft-holbrook-ssm-00.txt>
IP addresses in the 232/8 range are designated as SSM destination addresses and reserved for use
by source-specific applications and protocols. This document describes the semantics of SSM
addresses and specifies the policies governing their use.
3.5.2
Source Specific Multicast Model and PIM-SO
Traditional IP multicast model, supporting many-to-many communication, is very difficult to
realize over Wide Area Networks especially in an inter-domain environment. Too many issues are
putting off the commercial deployment of IP multicast based applications and services.
The consideration that today most of the existing multicast applications are based on one-to-many
communication convinced part of the Internet multicast community (ISPs in particular) to converge
towards single-source multicasting as a simplification of the multicast paradigm and, above all, an
immediately deployable inter-domain solution.
It is very important to notice that the SSM model represents a significant rethinking about the
separation of functionality between the Routing Layer and the Application/Control Layer for widearea multicasting. Specifically, it aims to restrict the role of a multicast routing protocol to building
a multicast tree, and forwarding the data packets along that tree. The responsibility of discovering
the identity of a multicast source (or equivalently, a multicast service) is left to the
application/control layer.
As an example, this can be achieved through a session advertisement tool such as SDR, which
would have to announce a source address and an SSM group address. This announcement could be
identified by a logical name and not by (S,G). This would imply the introduction of a new network
element capable of realizing “multicast name server” functions. This name server maps the name to
the pair (S,G). An immediate exploitation of this solution is to allow to offer the same service (e.g.
content) using different sources (the same logical name is mapped by different multicast name
servers running in different locations to different sources).
This new architectural element (the multicast name server) could also be used to support other
policy functions not yet covered like authentication server, description key distributor, billing,
access control etc.
SSM model implies the definition of new host-router and router-router multicast protocols.
When an end-host is interested in a single-source multicast session, it joins the source-based tree of
the session by using the pair (S,G). Two groups (S1,G) and (S2,G) are completely unrelated, even
though they have the same multicast group address.
The host-router multicast protocol is IGMPv3 which include the possibility for a host to join to a
multicast group identified by the pair (Source, Group). IGMPv3 supports “source filtering” i.e., the
ability of an end-system to express interest in receiving data packets sent only by specific sources
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 23 (38)
or from all but some specific sources. This functionality of IGMPv3 is a superset of the capabilities
required to realize the SSM model.
PIM-SO is a proposal for an SSM based inter-domain multicast routing protocol. It allows the
creation of source-based multicast trees across multiple domains in the Internet. PIM-SO realizes
the EXPRESS multicast service model in which there is a single source for every multicast group,
and group membership and addressing is based on a multicast group address (G) as well as the
source’s unicast address (S).
PIM-SO (referred as PIM-SS by Cisco people) is proposed as a variant of PIM-SM that only builds
source specific shortest path trees. These trees are built directly on receiving group membership
reports that request a given source.
This two new protocols (PIM-SO and IGMPv3) have to be realized with obvious impacts on endhosts, edge and core routers. Changes are also required for applications that must evolve to be
“IGMPv3 aware”.
An important issue in the deployment of SSM model is given by the impact of the new model into
the current multicast infrastructure deployed by large ISP and based on IGMPv2 for end-hosts
memberships, PIM-SM for intra-domain routing and MSDP for inter-domain-routing. The
coexistence of the “new“ and “old“ multicast protocols must be guaranteed.
A possible temporary solution for the provision on the same network of the two multicast service
models can be made easier by the assumption of a strict partition of multicast addresses divided
between PIM-SM and PIM-SO addresses. The IANA has already allocated the address range 232/8
for experimentation with a single-source multicast service.
3.5.3
Sprint Plans for PIM-SO Deployment
Sprint aims to evaluate the protocol functionality in Sprintlab’s experimental network by August
2000. During NGC2000 Workshop early in November 2000, Sprint for the first time demonstrated
the usage of PIM-SO on their IP backbone. The purpose is to provide a commercial point-tomultipoint service.
3.6
Interoperability Rules for Multicast Routing Protocols (RFC
2715)
The aim of [RFC-2715] is to describe rules that allow efficient interoperation among
multiple independent multicast routing domains. These domains are interconnected via multicast
border routers (MBR). MBRs consist of two or more active multicast routing components, each
running an instance of some multicast routing protocol. All components share a common
forwarding cache of (S,G) entries. The 6 rules are :

All components must agree on which component owns the incoming interface for a
forwarding cache entry. The way to choose owner depends of the inter-domain routing
protocol.

The component owning an interface specifies the criteria for which packets received on
that interface are to be accepted or dropped (RPF check, scoped boundaries).

Whenever a new (S,G) forwarding cache entry is to be created, all components must be
alerted so that they can set the forwarding state on their own outgoing interfaces before the
packet is forwarded.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 24 (38)
EURESCOM Technical Information

When a component removes the last outgoing interface from an (S,G) forwarding cache
entry whose incoming interface is owned by another component, or when such an (S,G)
forwarding cache entry is created with an empty outgoing interface list, the component
owning the incoming interface must be alerted.

When the first outgoing interface is added to an (S,G) forwarding cache entry whose
incoming interface is owned by another component, the component owning the incoming
interface must be alerted.

For a component, an “externally-reached” source is a source whose RPF interface is owned
by another component. An “internally-reached” source is a source whose RPF interface is
owned by that component.
Unless a component reports the aggregate group membership in the direction of its interfaces, it
must be a “wildcard receiver” for all “externally-reached” sources. A component must be a
“wildcard receiver” for all “internally-reached” sources if any other component of the MBR is a
“wildcard receiver” for “externally-reached” sources.
The way to apply these rules depends of the routing protocols used in the network.
3.7
Internet Group Management Protocol Version 3 (IGMPv3)
The first version of IGMP is specified by [RFC-1112], the version 2 is specified by [RFC-2236].
The state of the version 3 specification is an Internet draft [draft-ietf-idmr-igmp-v3-02.txt]. This
version allows a system to filter the sources it is interested in, that is, for a host to select the sources
whose packets it is interested in receiving, and for a router to select the sources whose packets it
has to forward on. Hosts define the states of their interfaces (i.e. sources desired/non–desired from
these interfaces) and send messages to the neighbouring multicast routers, which apply filters to
their own interfaces to filter outgoing multicast packets.
3.7.1
Filters
A filter can be expressed in two ways:

To select only the sources a system is interested in. Such a filter is called an INCLUDE
filter. A host sends a list including only the sources it is interested in, and the receiving
router only forwards the packets coming from sources in that list.

To select the sources a system is not interested in. Such a filter is called an EXCLUDE
filter. A host sends a list including the sources it is not interested in, and the receiving
router forwards the packets coming from all the sources not in that list.
On a router, only one filter can be applied to the couple <outgoing interface, multicast group>.
Therefore, the issue is for a router (and for a specific group) to forward the right packets onto an
interface according to the filters it received from all the hosts of the LAN that this interface is
connected to. The router has to calculate the filter to be applied to its outgoing interface in order to
satisfy all the host subscribers to that group.
There are two possibilities:

If the router receives at least one EXCLUDE message from a host, the corresponding
outgoing interface filter for the LAN that the interface is connected to is EXCLUDE. The
list of the sources to exclude (i.e. packets not to forward on the LAN) is made up of the
sources that are in the intersection of all the EXCLUDE message lists, minus the sources
that are in the INCLUDE message lists.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information

3.7.2
page 25 (38)
If the router receives only INCLUDE messages, the corresponding outgoing interface filter
for the LAN that the interface is connected to is INCLUDE. The list of the sources to
include (i.e. packets to forward on the LAN) is made up of the union of the sources that are
in the INCLUDE message lists.
Multicast Router Behaviour
A multicast router periodically sends membership query messages to build and refresh its
membership tables. There are three types of queries:

General query. Such a query is sent by a router to learn the complete states of all
neighbouring hosts. Those queries are sent to the All-Hosts IP destination address
(224.0.0.1).

Group-Specific query. Such a query is sent by a router to learn the states of all
neighbouring hosts for a specific multicast group address. Those queries are sent with the
IP destination address equal to the corresponding multicast group address.

Group-and-Source-Specific query. Such a query is sent by a router to learn the states of all
neighbouring hosts for a specific couple <multicast address group, list of sources for that
group>. Those queries are sent with the IP destination address equal to the corresponding
multicast group address.
In order to receive IGMPv3 hosts’ reports, the multicast router must listen to the destination
address 224.0.0.22. It has to modify the filters on its interfaces according to the reports. It may need
to forward new sources, or drop packets from former forwarded sources. Usually, a multicast router
doesn’t store the states of its neighbouring hosts in memory. In order to avoid dropping wanted
packets, the router must send queries in order to be sure that no host is still interested in that source
before dropping all packets from a specific source.
From the router performance and bandwidth management point of view, the fewer forwarded
sources the better. That’s why the router tries to switch, as soon as possible, in an INCLUDE mode
filter, thereby forwarding only explicitly wanted sources instead of forwarding all but unwanted
sources. In order to do that, the router uses some timers about the EXCLUDE reports it received,
and when these timers expire, it checks the possibility of switching to an INCLUDE mode.
3.7.3
Multicast Host Behaviour
Two events can trigger an IGMPv3 action on an interface:

The state of the interface has changed. The host has to send a report to its neighbouring
multicast router to inform it of the change and of the host’s new needs.

A query is received. According to the type of the query (general, group-specific, groupand-source-specific), the host sends a report describing its state concerning the involved
groups and/or sources.
3.7.4
Backward Compatibility with Version 1 and Version 2
IGMPv3 is fully compatible with version 1 and version 2, so routers have to listen to All-Routers
IP multicast address (224.0.0.2). The issue is to decide which version to use between routers and
hosts.
The length and the Max-Response-Time field of query messages sent by the router define the
IGMP version used. According to these characteristics, the host knows which version is used by the
router. The router must be able to manage lower IGMP version messages, so hosts that use such
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 26 (38)
EURESCOM Technical Information
versions can operate normally. Hosts that can use a higher IGMP version must not use it and adapt
themselves to the router’s IGMP version.
A host stores which IGMP version is used for each of its interfaces in memory. A router stores
which IGMP version is used for each couple <multicast group, interface>. If several hosts run
different IGMP versions for the same couple <multicast group, interface>, the router must use the
lower version, so that all hosts can understand the IGMP messages.
If several multicast routers are used on the same LAN, the lowest available version of IGMP must
be used, but the administrator is in charge of ensuring such a configuration.
3.8
Existing MBGP, MSDP, BGMP, PIM-SSM and IGMPv3
Implementations
3.8.1
MBGP IMPLEMENTATIONS
3.8.1.1
CISCO SYSTEMS
MBGP support was introduced in the following versions of Cisco IOS: 11.1(20)CC, 12.0(2)S,
12.0(7)T.
MBGP stands for “Multiprotocol extensions for BGP-4” and realizes the features as specified in
RFC2283.
MBGP offers the following benefits:

A network can support incongruent unicast and multicast topologies.

A network can support congruent unicast and multicast topologies that have different
policies (BGP filtering configurations).

All of the routing policy capabilities of BGP can be applied to MBGP.

All of the BGP commands can be used with MBGP.
The most recent versions of CISCO IOS supporting MBGP are:
IOS 120-10.S1 – refer to: ftp://ftpeng.cisco.com/isp/12.0S/120-10.S1/ (ISP early deployment
release)
IOS 120-10.3.S – refer to: ftp://ftpeng.cisco.com/isp/12.0S/120-10.3.S/ (ISP early deployment
release)
IOS 12.1.T - (technology early deployment release). You need a CCO account (i.e.: service
contract) to access it.
12.0S is targeted for Internet Service Provider (ISP) type applications. It is supported ONLY for
Cisco-12000/7500/7200. However unsupported images for other platforms may also be found via
the ftpeng web page.
IOS 12.0S is considered to be more stable than IOS 12.0T.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 27 (38)
Changed BGP/MBGP syntax for newer 12.0T, 12.1 versions of IOS:
It is important to say that MBGP syntax differs between 12.0S versions and newest 12.1T versions
of IOS. Here in the following is given an example of how the configuration automatically changes
when you upgrade from 12.0(8.1)S to 12.0(8.0.2)T. More detailed information can be accessed to:
ftp://ftpeng.cisco.com/ipmulticast/config-notes/MBGP_120T.txt
EP1-75a's MBGP configuration with 12.0(8.1)S:
router bgp 5
no synchronization
network 171.69.214.0 mask 255.255.255.0 nlri unicast multicast
neighbour 171.69.214.34 remote-as 5
neighbour 171.69.214.38 remote-as 2 nlri unicast multicast
neighbour 171.69.214.42 remote-as 5
neighbour 171.69.214.59 remote-as 5
no auto-summary
Reload EP1-75a with 12.0(8.0.2)T, and the config magically
changes to:
router bgp 5
no synchronization
network 171.69.214.0 mask 255.255.255.0
neighbour 171.69.214.34 remote-as 5
neighbour 171.69.214.38 remote-as 2
neighbour 171.69.214.42 remote-as 5
neighbour 171.69.214.59 remote-as 5
no auto-summary
!
address-family ipv4 multicast
neighbour 171.69.214.38 activate
network 171.69.214.0 mask 255.255.255.0
exit-address-family
If there has been no previous MBGP configuration you will need to configure the address-family
manually. MBGP works correctly between a router configured with an address-family (12.0T) and
one which uses the nlri multicast configuration.
3.8.1.2
ERICSSON
The AXI540 Edge Aggregation router, running the IPaction software, supports MBGP.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 28 (38)
3.8.1.3
EURESCOM Technical Information
Juniper Networks
Juniper Networks provides high-performance IP networking systems that enable service providers
to meet the demands of the rapidly growing Internet. Juniper comprises a product portfolio given
by three “Internet Backbone routers” called M20, M40 and M160. These platforms run the JunOS
Internet Software (last available release is 4.0).
Junos software supports a comprehensive suite of Internet-scale routing protocols including the
following IP Multicast routing protocols:

IGMP (version 1 and 2)

DVMRP

PIM (both dense and sparse mode are supported)

MSDP

MBGP
3.8.1.4
Avici Systems
The support of MBGP has been announced by first quarter of 2001.
3.8.2
MSDP IMPLEMENTATIONS
3.8.2.1
CISCO SYSTEMS
MSDP support was introduced in the following versions of Cisco IOS: 11.1(22)CC, 12.0(2)S,
12.0(7)T.
MSDP stands for “Multicast Source Discovery Protocol” and realizes the features as specified in
the Internet Draft “draft-ietf-msdp-spec-01.txt”.
The current specification is “draft-ietf-msdp-spec-05.txt”, but its features are not yet realized by
any vendor.
For information related to the most recent versions of CISCO IOS supporting MSDP refer to
MBGP section.
3.8.2.2
Juniper Networks
See section 3.8.1.3.
3.8.2.3
MERIT GATED5 Consortium
GateD MSDP is part of the GateD Multicast 1.0 Package and support the Internet Draft [draft-ietfmsdp-spec-01.txt].
3.8.2.4
Avici Systems
The support of MSDP has been announced by first quarter of 2001.
5
GateD (or "GateDaemon") software is based on Unix Operating System and can be considered
as a research and prototyping platform for routing protocols.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 29 (38)
3.8.3
BGMP IMPLEMENTATIONS
3.8.3.1
MERIT GATED Consortium
GateD BGMP is part of the GateD Multicast 1.0 Package.
3.8.4
PIM-SSM IMPLEMENTATIONS
SSM with IGMPv3, IGMP v3lite and URD will be supported in Cisco releases beginning with the
following maintenance versions:

Cisco IOS 12.1(5)T
- available on CCO End of Nov. '00.

Cisco IOS 12.1(5)E
- available on CCO Dec. '00.

Cisco IOS 12.0(15)S
- No finalized schedule yet.

Cisco IOS 12.2
- Q1'2001
Pre-builds of EFT and beta images for SSM are already available to Beta and EFT customers.
3.8.5
IGMPv3 IMPLEMENTATIONS
An host Implementation of IGMPv3 on FreeBSD (FreeBSD IGMPv3 stack) is available from
http://home.hetnet.nl/~wilbertdg/igmpv3.html
An host Implementation of IGMPv3 on Linux (Linux IGMPv3 stack) is available from:
http://www.sprintlabs.com/Department/IP-Interworking/multicast/linux-igmpv3/
It has been announced that a next release of Windows (codename Whistler) will have IGMPv3
support. Rumour has it that Whistler is scheduled for release in 2001 at the earliest.
IGMP v3lite is the Cisco transition solution for application developers to support SSM in
applications with an IGMP v3 API even if the host’s operating system does not yet support IGMP
v3. In addition, compiling an application with IGMP v3lite will allow an application to utilize
IGMP v3 in the host operating system if it is available, and to use the IGMP v3lite transition
mechanism otherwise.
To use IGMP v3lite, you need the host operating system Host Side IGMP Library (HSIL) available
for free downloads from Talarian: http://www.talarianmulticast.com/cgi-bin/igmpdownld
For information refer to: http://www.talarian.com/products/multicastlite/index.shtml
The HSIL is available for Microsoft Windows (95*,98*,NT,...) operating systems.
Cisco IOS in addition to IGMPv3 and IGMPv3 lite also provides for an additional interim solution
to signal source specific membership:
URD ("URL Rendezvous Directory") allows to enable existing applications to be SSM capable
without modifying any receiver host software (application nor operating system) - as long as the
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 30 (38)
EURESCOM Technical Information
application is started via a web browser. URD relies on the last-hop router towards a SSM receiver
host to intercept URLs from a webserver to detect the source address of the SSM channel.
3.8.6
SSM/IGMPv3 Applications
The standard MBone tools (VIC & VAT) to operate with SSM under FreeBSD 4.0 are available at:
ftp://ftp.net.ohio-state.edu/users/maf/mcast
If you need to build from source, the vic/vat IGMPv3 patches should be applied to the following
source:
MASTER_SITES= ftp://ftp.ee.lbl.gov/conferencing/vic/
DISTFILES= vicsrc-2.8.tar.gz
MASTER_SITES= ftp://ftp.ee.lbl.gov/conferencing/vat/alpha-test/
DISTFILES= vatsrc-4.0b2.tar.gz
3.9
Inter-domain
Description
Multicast
Routing
Policy
(e.g.
security)
Multicast solutions in a single multicast domain and on the Internet have significant differences
when we consider the inter-domain routing.
The requirement of PIM-SM that there can only be one active RP for a given group is a problem in
inter-domain environment. Different RPs in a different domain needs to exchange information
about the active sources in their domains and a mechanism was needed to do this. It also requires
that the RP be well-connected in the core of the network. MSDP was developed to provide this
mechanism. MSDP create peerings between RPs and the peering relationship will be made up of a
TCP connection in which control information was exchanged. Through these peerings, RPs
exchange Source Active (SA) messages, which described all of the registered sources within their
respective domains. RPs learns all of the active sources from other domains, in addition to the
sources from their own domain.
A further requirement of multicast inter-domain routing was the ability to support incongruent
unicast and multicast routing topologies. It’s necessary to be able to create different routing
policies for unicast and multicast. MBGP (Multiprotocol Border Gateway Protocol) creates
extensions to the widely-used BGP (Border Gateway Protocol) to support this requirement. MBGP
adds a multicast-only reachability table to the existing unicast reachability table of BGP. With
MBGP, a router can effectively have two BGP tables, one for multicast and one for unicast.
[MBGP establish a tree of domains or a routing hierarchy].
The key management describe above is limited to a single domain due to the use of public keys
where are made known only to a limited number of entities. To allow an inter-domain control
message authentication, the DKD (Domain Key Distributor), in the respective domains, must be
assigned global public keys. The DKDs can negotiate an intermediate key used by an entity in
domain A to communicate with another entity in domain B, with authentication and/or
confidentiality. Each PIM entity can have assign a global public key pair that allows a confidential
communication router-to-router across domain boundaries. The DKD of a domain can carry-out
key management in the routers in its domain using a secure channel.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
page 31 (38)
Internet Group Management Protocol version 3 [draft-ietf-idmr-igmp-v3-02], the protocol used to
report the IP Multicast membership to neighbouring routers needs some security policies. This
version adds the capability for a system to report interest in receiving packets only from specific
source addresses. The information is very important to multicast routing protocols. These messages
can be forged and a policy is needed. If a forged query message was from a machine with a lower
IP address than the actual Querier, the Querier duties was assigned to the entity that generate this
message. These messages can be easily traced from the local network; the routers should not
forward Queries and hosts should ignore IGMP v3 queries that don’t have the Router-Alert option.
A forged report message implies that some multicast routers think that are members of a group on
a network where don’t exist any entity. Defences can be created to this situations and the report that
we cannot identify the source address and without Router Alert options must be ignored.
Multicast routing policies are in a state of evolution and the information is very poor.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 32 (38)
EURESCOM Technical Information
4
Quality of Service Components in Multicast Routing
Protocols
4.1
QoS for PIM-SM
PIM-SM attempts to incorporate most of the desirable features of multicast routing. This is its
ability to support receiver-initiated join, both shared and source-specific trees and its independence
from the underlying unicast routing protocol. Due to the PIM-SM independence from the
underlying unicast routing protocol one is free to choose a unicast protocol that is specifically
designed and suited for routing with QoS constraints.
A paradigm for QoS based multicast is provided where a receiver can initially join the shared tree
when it does not have any QoS requirements. Later, if and when the receiver decides about its
specific QoS parameters, it can join the individual source-specific trees one at a time. This
paradigm can allow multiple receivers, with heterogeneous QoS requirements, to join a single
source-specific tree.
Two algorithms are proposed in [DRAFT-PIM-QOS] for the constructing of QoS-aware multicast
trees that can be applied to both source specific and shared trees.
QoS multicast route computation
The Tree Information Based QoS Multicast (TIQM) algorithm provides QoS-aware multicast route
computation in the presence of both network-specific and tree-specific link state information.
Availability of global information ensures that when enough bandwidth is available to
accommodate a new receiver, TIQM does so with very low join-rejection probability. The
algorithm has the disadvantages relying on group and tree-specific link state information, which
may be of scalability concern [ICCCN94].
NUQM provides multicast routing with heterogeneous and receiver-oriented QoS support. While
using the same join and prune protocols, NUQM differs from TIQM in that it computes a QoSaware unicast route based only on network link-state information. NUQM keeps the control and
storage overheads low. For instance, NUQM can easily scale for inter-domain multicast, provided
there exists a QoS-extended inter-domain unicast routing protocol. The downside of NUQM is its
high receiver join-rejection probability in certain scenarios.
Extensions for PIM-SM
Although both NUQM and TIQM can work hop-by-hop or explicitly routed, the latter is preferred
for its better loop-prevention capabilities. Also, for explicit routing, only the joining receiver has to
compute the route whereas for hop-by-hop routing every intermediate router needs to compute a
QoS-aware route. For standard PIM-SM, however, routing is performed in a hop-by-hop mode. For
better integration of the QoS-aware routing mechanisms, it is proposed that an explicit-routing
option for PIM-SM be adopted.
It is proposed that control messages are sent over TCP. A confirmation of a join (join-ack) is
needed to activate a reservation to a new receiver. The format of multicast routing table entries has
to take into account reserved bandwidth information.
The Reverse Path Forwarding (RPF) checks [S-PAUL] is not feasible for forwarding with QoS
constraints. So the loop prevention has to be performed at the NUQM (or TIQM) route
computation level.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
4.2
page 33 (38)
QoS Extensions to CBT
CBT does not support source-based trees. CBT core selection for a group is not based on
the QoS requirements of the receivers of that group. Once a core is selected, the CBT tree
gradually grows around it.
To support QoS [DRAFT-CBT-QoS] proposes the following QoS extension to the current CBT
specification: each join-request message carries, in addition to the interface information, the QoS
parameters of interest along the route. When a join-request message reaches the core or an on-tree
router, the core/router performs a set of eligibility tests. Although it is preferable that eligibility
tests be conducted locally at the on-tree router, the on-tree router may not be able to approve a joinrequest only based on its local state, and may have to collaborate with other on-tree routers to
conduct the eligibility tests. Moreover, the state kept at some other on-tree routers may have to be
changed because of the member join. That is, collaboration among on-tree routers is sometimes
inevitable in approving a join request. Only after the branch survives the eligibility tests, it will be
eligible to join the multicast tree (under which case a join-acknowledgment message is then sent
back). In the case of member leave, the state kept at the other on-tree routers may have to be
updated and proper procedures be taken to notify on-tree routers of the need to update their states.
While changes to the current CBT protocol specification seem unavoidable, they should be kept as
small as possible.
4.3
QoS Impact on Multicast Routing
IP multicast routing protocols construct best-effort multicast trees based on the unicast routing
tables. Even unicast QoS routing, is still a research topic; it involves taking into consideration
constrains on loss, delay, jitter or on other dynamic metrics. QoS multicast routing will clearly not
be addressed more easily than a unicast one.
QoS routing allows the determination of a path that has adequate resources to accomodate the
requested QoS, but it does not include a mechanism to reserve the required resources. Thus the
QoS routing is usually used together with some form of resource reservation or resource allocation.
Another option might be to use traffic engineering methods for traffic separation based on QoS
requirements to be routed on a best effort or on a constrained basis.
Requirement 1:
In QoS routing a path for a flow is to be determined on some knowledge of resource availability in
the network and on the QoS requirements of the flow.
Requirement 2:
Additionally to general issues which have to be considered in QoS routing, “like how do routers
determine the QoS capability of each ongoing link and reserve link resources ?”, “what is the
granularity of routing decision and what routing metrics are used ?”, multicast routing raises an
additional problem of QoS-accommodating paths computed for multicast flows with different
reservation styles and receiver heterogeneity.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 34 (38)
EURESCOM Technical Information
Requirement 3:
Thus, specific to the IP multicast routing is the need to allow for heterogeneous receivers, i.e.
receivers with different service requirements.
This requires either:

a construction of different multicast trees associated with a certain type of service,

a differentiation of service in certain multicast tree branches.
Requirement 4:
It is important to determine what resources have already been allocated to a multicast flow, what
improves the chances of finding a path to add a new receiver to a multicast flow. Membership
dynamics of a multicast session introduces additional problems. A join of a new member at an ontree router may affect the state information kept at other on-tree routers. A join of a new receiver
could lead to a reconstruction of the whole multicast tree in order to get a more efficient tree, but
because the reconstruction may cause service disruptions for the existing receivers, the
reconstruction of the existing tree should be avoided.
Requirement 5:
Multicast admissions control must be introduced to prevent excessive resource consumption by
flows. It should be based on required incremental resource allocation for the receiver and on the
total resource consumption of a multicast tree.
QoS-based multicast source routing (multicast trees are computed by the first-hop router from the
source) is suited when receiver reservations are homogeneous and the same as the maximum
reservation derived from sender advertisement. Therefore in general a receiver-oriented multicast
routing model seems preferable. In this model sender traffic advertisements can be multicast over a
best-effort tree. Each receiver-side router independently computes a QoS-path from the source
based on receiver QoS preferences, routers in a multicast tree can aggregate resources requested
from different receivers. The path computation can base on unicast routing information, or with
additional multicast flow-specific state information (should be limited due to scalability problems).
The problem with this approach is the usage of reverse paths method (Reverse Path Forwarding
RPF - assumes symetrical paths between two nodes) in many multicast routing protocols. When
routing contrains are introduced in such protocols, there is no guarantee that the forwarding will
occur on an optimal path. The both described above models, i.e. source and receiver oriented
routing, compute QoS trees per-source. Another possibility is the utilization of shared per-group
trees. This model has to consider the facts that the shared trees causes traffic concentration, and a
separate bandwidth reservations on the links are needed for traffic from different senders.
Therefore source specific trees seems more efficient than shared trees for optimal QoS
provisioning.
Consideration of QoS requirements adds additional complexity and overhands to multicast routing.
Important aspects in a developement of QoS multicast routing is to make the solution scalable to
multicast groups of large sizes and to a large number of multicast groups with dynamic
membership, and to make the solution robust in the presence of topological changes.
Summary on engineering requirements:

Knowledge of resource availability in the network and on the QoS requirements of the flow

General issues in QoS routing: QoS capability and resource reservation in each ongoing
link in a node, determination of routing metrics and granularity of routing decision
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information

Consideration of receiver heterogeneity

Dealing with membership dynamics

Introduction of multicast admission control
 2000 EURESCOM Participants in Project P1010
page 35 (38)
EDIN 0054-1010
page 36 (38)
5
EURESCOM Technical Information
Outlook and Conclusion
MSDP has been deployed for more than a year in operational networks, but the MSDP network
engineers have encountered difficulties related to the RPF (Reverse Path Forwarding) election
procedure. From this standpoint, the current version of the MSDP specification is not satisfactory
(at least from a developer’s perspective). This is why it was been decided to produce a new version
of the specification. This yet-to-be published specification should conclude the work of the msdp
working group, which is expected to be disbanded after the first IETF meeting of year 2001.
During the 48th IETF meeting, the main subject of idmr working group was now regarding
IGMPv3. IGMP v3 is necessary for PIM-SO, but along with IGMP, all applications need to be
modified.
The most important part of the PIM meeting focused on the presentation of the new version of the
specification. This new specification fits pretty well with the emerging PIM-SO effort. The PIMSM (Sparse Mode) protocol appears to be the de facto standard as far as intra-domain multicast
routing design is concerned, and one can expect an easier deployment of the above-mentioned
multicast services (one-to-many) because of the simplifying routing scheme of PIM-SO, provided
IGMPv3-aware applications.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010
EURESCOM Technical Information
6
page 37 (38)
References
EURESCOM :

[EURESCOM-P911-Deliverable1-Annex A] : Technical review of the PIM-SM protocol;
PIR 2.1 of the P911 EURESCOM Project; 1999.
RFCs :

[RFC-791] : Internet Protocol – September 1981

[RFC-1112] : Host extensions for IP multicasting. S.E. Deering - August 1989.

[RFC-1700] : Assigned Numbers – October 1994

[RFC-1771] : A Border Gateway Protocol 4 – March 1995

[RFC-2236] : Internet Group Management Protocol, Version 2. W. Fenner - November
1997.
[RFC-2283] : Multi-protocol Extensions for BGP-4 – February 1998


[RFC-2362] : Protocol Independent Multicast-Sparse Mode v2 (PIM-SM): Protocol
Specification, L Wei, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P. Sharma, RFC-2362, June 1998.

[RFC-2365] : Administratively Scoped IP Multicast, D. Meyer, BCP-23, July 1998.

[RFC-2784] : "Generic Routing Encapsulation (GRE)“, D. Farinacci, T. Li, S. Hanks, D.
Meyer, P. Traina, RFC 2784, March 2000 (Proposed Standard).
Drafts :

[DRAFT-Anycast-RP] “Anycast RP mechanism using PIM and MSDP”, draft-ietfmboned-anycast-rp-05.txt, D.Kim, D.Meyer, H. Kilmer, D. Farinacci – January 2000.

[DRAFT-BGMP] : Border Gateway Multicast Protocol (BGMP) – draft-ietf-bgmp-spec01.txt – March 2000.

[DRAFT-CBT-QoS] : J. Hou, H.-Y. Tyan, B. Wang, Y.-M. Chen ”QoS Extension to
CBT”, INTERNET DRAFT, draft-hou-cbt-qos-00.txt, February 1999.

[DRAFT-IETF-IDMR-IGMP-V3-02] : Internet Group Management Protocol, Version 3,
Brad Cain, Steve Deering, Isidor Kouvelas, Ajit Thyagarajan, - June 2000.
[DRAFT-IETF-MALLOC-AAP-04] : “Multicast Adress Allocation Protocol (AAP)”,
draft-ietf-malloc-aap-04.txt, M. Handley, Stephen R. Hanna, June 2000.


[DRAFT-IETF-MALLOC-MASC-06] : “The Multicast Address-Set-Claim Protocol”,
draft-ietf-malloc-masc-06.txt, D.Estrin, R. Govindan, M. Handley, S. Kumar, P.
Radoslavov, D. Thaler, July 2000.

[DRAFT-IETF-MSDP-SPEC-01] : "Multicast Source Discovery Protocol (MSDP)", Dino
Farinacci, Peter Lothberg, David Meyer, Y Rekhter, Hank Kilmer, Jeremy Hall.

[DRAFT-IGMPv3]
B. Cain, Steve Deering,.., “Internet Group Management Protocol,
version 3 “, draft-ietf-idmr-igmp-v3-04.txt, June 2000, expires in December 2000

[DRAFT-MASC] : The Multicast Address-Set Claim (MASC) Protocol – draft-ietf-mallocmasc-05.txt – January 2000

[DRAFT-MSDP] : “Multicast Source Discovery Protocol (MSDP)”, draft-ietf-msdp-spec06.txt, D. Farinacci, Y. Rekhter, D. Meyer, P. Lothberg, H. Kilmer, J.Hall - April 2000.

[DRAFT-PIM-AUTH] : Authenticating PIM version 2 messages, L. Wei, draft-ietf-pimv2-auth-01.txt, May 1999, expired.
 2000 EURESCOM Participants in Project P1010
EDIN 0054-1010
page 38 (38)
EURESCOM Technical Information

[DRAFT-PIM-BIDIR] : Bi-directional Protocol Independent Multicast, M. Handley, I.
Kouvelas, L. Vicisano, draft-ietf-pim-bidir-00.txt, march 1, 2000, work in progress.

[DRAFT-PIM-DMv2] : Protocol Independent Multicast Version 2 Dense Mode
Specification, L Wei, D. Estrin, D. Farinacci, A. Helmy, D. Meyer, S. Deering, V.
Jacobson, draft-ietf-pim-v2-dm-03.txt, June 1999 (expired).

[DRAFT-PIM-GENID] : PIM Neighbour Hello GenID Option, Y. Li, B. Ng, draft-ietfpim-hello-genid-01.txt, june 1999, expired.

[DRAFT-PIM-QOS] Internet Engineering Task Force<. Subir Biswas, Rauf Izmailov, Bala
Rajagopalan. INTERNET DRAFT Expires November, 1999. A QoS-Aware Routing
Framework for PIM-SM Based IP-Multicast <draft-biswas-pim-sm-qos-00.txt>.

[DRAFT-PIM-REFRESH] : State Refresh in PIM-DM, D. Farinacci, I. Kouvelas, K.
Windisch, draft-ietf-pim-refresh-01.txt, october 1999.

[DRAFT-PIM-SMKEY] : Simple Key Management Protcol for PIM, T. Hardjono, draftietf-pim-simplekmp-01.txt, February 2000, work in progress.

[DRAFT-PIM-SMv2] : Protocol Independent Multicast-Sparse Mode v2 (PIM-SM):
Protocol Specification“, L Wei, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, draft-ietf-pim-v2-sm-01.txt, November 1999.
Miscellaneous :

[ICCCN94] L. Wei et al,The Trade-offs of Multicast Trees and algorithms,Proceedings of
ICCCN'94, San Francisco, September 1994.

[MASC/BGMP] : The MASC/BGMP Architecture for Inter-domain Multicast Routing –
Satish Kumar, Pavlin Radoslavov, David Thaler, Cengiz Alaettinoglu, Deborah Estrin,
Mark Handley.

[S-PAUL] S. Paul, Multicasting on Internet and Its Applications, Book published by
Kluwer Academic Publishers, 1998.
EDIN 0054-1010
 2000 EURESCOM Participants in Project P1010