Subject: Source-Specific PIM draft

From: Nidhi Bhaskar <[email-masked]>
Date: Wed, 15 Mar 2000 19:42:17 -0800

The following draft has been submitted to the ID directories and will
be presented in the Adelaide IETF.

Thanks,
Nidhi.

----------------------------------------------------------------------

INTERNET-DRAFT                   PIM-SS                    Nidhi Bhaskar
Expires 10 September 2000                                  cisco Systems
                                                         Isidor Kouvelas
                                                           cisco Systems
                                                          10 March, 2000

             Source-Specific Protocol Independent Multicast
                     <draft-bhaskar-pim-ss-00.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

Source-Specific PIM (PIM-SS) is a variant of PIM Sparse-Mode that only
builds source specific shortest path trees. These trees are built
directly on receiving group membership reports that request a given
source. PIM-SS precludes the building of shared trees, effectively par-
titioning the different source trees from one another. For this reason
it is specifically suited for existing multicast applications for which
there is expected and intended to be exactly one source.

Source-Specific PIM can co-exist with PIM-SM. It uses a subset of PIM-SM
messages and lends itself to incremental deployment.

Bhaskar, Kouvelas                                               [Page 1]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

                           Table of Contents

Abbreviations .....................................................    3
1.  Introduction ..................................................    4
2.  Definitions ...................................................    4
3.  Protocol Details ..............................................    5
4.  PIM-SS Packet Formats .........................................    7
5.  Interoperability with legacy routers ..........................    8
6.  Security Considerations .......................................    9
References ........................................................   10

Bhaskar, Kouvelas                                               [Page 2]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

Abbreviations

PIM Protocol Independent Multicast
SSM Source-Specific Multicast [1]
SM  Sparse Mode
SS  Source-Specific
RP  Rendezvous Point
DR  Designated Router

Bhaskar, Kouvelas                                               [Page 3]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

1.  Introduction

PIM Sparse Mode [2] Designated Routers (DR) with local membership rely
on the shared Rendezvous Point (RP) tree to learn about active sources
for a group. In most cases the DR switches to the shortest path tree for
source S when it receives a data packet from S via the shared tree. It
then prunes the source S off the shared tree to eliminate duplicates.
Additional mechanisms, like Register messages/MSDP, are required to
inform the RP of active sources.

Joining the shared tree is important to support the many-to-many multi-
cast model of RFC 1112 where the set of sources can vary during the
lifetime of the session. However, if the application requires that only
a single well-known source be allowed to send to a group, the complexity
of setting up a shared tree to learn about this source is unnecessary.
Even worse, it does not provide the correct service model as it allows
any host to send to the group.

A large portion of existing multicast content has exactly one source
with a well-known address. Clearly, if this source address can be pro-
vided to the last hop DR with the initial group membership request by
the host it would be much more efficient for the DR to immediately build
a shortest path tree to the source. Since source trees for multiple
sources sending to the same group address are independent of each other,
this is especially suited for one-to-many communication.

This document describes a simplified version of PIM-Sparse Mode (PIM-SM)
to support these one-to-many applications. We refer to this variant as
Source-Specific PIM (PIM-SS). PIM-SS in conjunction with the IGMPv3
extensions for Source-Specific Multicast described in [1] provides the
Source-Specific Multicast service model [1] suitable for one-to-many
communication.

The rest of this document in organized into 6 sections. Section 2 has
some Definitions, section 3 describes PIM-SS operation, section 4
details packet formats, section 5 describes interoperability considera-
tions in the presence of legacy routers and finally section 6 discusses
security issues.

2.  Definitions

SSM is the Source-Specific Multicast model described in [1]. The SSM
range refers to any class D address range designated for SSM. Unless
otherwise stated, all PIM-SS protocol actions are used for groups in the
SSM range.

A source specific membership report is a request to join a group G that

Bhaskar, Kouvelas                                               [Page 4]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

also specifies the source the host is interested in. IGMP v3 INCLUDE
{srclist} report is an example.

This document assumes that the reader is familiar with the PIM-SM proto-
col [2]. In particular, the concepts of (S,G) and (*,G) state and their
component fields (olist, iif, ...) are used.

Unless otherwise stated, an (S,G) entry in this text refers to (S,G)
state with RP-bit set to 0. I.e., (S,G) state associated with the source
specific shortest path tree. Also, none of the PIM-SM rules for the
SPT-bit associated with an (S,G) entry are applicable to PIM-SS.

In this document "Standard PIM-SM SPT procedures" refers to the subset
of PIM-SM protocol actions that are associated with source trees as
defined in [2]

Unless otherwise stated, (S,G) Join/Prune messages are associated with
the source specific shortest path tree, i.e., have the WC and RPT bits
set to 0.

Finally, default values for relevant timers are the ones given in [2].

3.  Protocol Details

PIM-SS is a sparse mode protocol that ONLY builds source specific shor-
test path trees. PIM-SS uses a subset of standard PIM-SM messages [2] to
set up these distribution trees. A last hop DR is responsible for ori-
ginating (S,G) Join/Prune messages in response to source specific
membership reports. Intermediate PIM-SS routers propagate these (S,G)
Join/Prune messages towards the source.

PIM-SS SHOULD be used for group ranges designated for SSM [1]. In most
deployment scenarios PIM-SS will co-exist with other flavors of PIM
operating in different group address ranges.

3.1.  Tree Building and Maintenance

This section specifies the rules for creation and maintenance of the
shortest path trees.

3.1.1.  Joining the Source Tree

On receiving membership indication for a given source and group the fol-
lowing actions are taken by a last hop DR:

 o If no (S,G) state exists for the source and group, then an (S,G)
   entry is created.

Bhaskar, Kouvelas                                               [Page 5]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

 o The interface on which the membership report was received is added to
   the olist of the (S,G) entry iff it is not the same as the incoming
   interface.

 o A triggered (S,G) Join is sent to the RPF neighbour for the source if
   the olist transitioned from Null to non-Null OR if membership indica-
   tion on the iif for the source resulted in the creation of the (S,G)
   entry.

 o Standard PIM-SM SPT procedures [2] are used to update timers associ-
   ated with the (S,G) entry. Note, that no actions associated with the
   SPT-bit are taken for the route entry.

 o In addition, the (S,G) entry is kept alive as long as there is
   reported membership for that source and group.

A PIM-SS router MUST ignore all non-source-specific membership reports
(such as IGMP v2 host reports) for groups in the SSM range.

On receiving a PIM (S,G) Join for some SSM group G the router takes the
following actions:

 o If no (S,G) entry exists, it creates one.

 o The interface on which the Join was received is added to the olist of
   the (S,G) entry iff it is not the same as the incoming interface.

 o Standard PIM-SM SPT procedures are used for updating timers and ori-
   ginating an (S,G) Join for the upstream PIM neighbour towards the
   source.

3.1.2.  Leaving the Source Tree

On receiving notification that no local members on an interface wish to
receive traffic for a source and group, the DR takes the following
actions:

 o It uses Standard PIM-SM SPT procedures for removing the interface
   from the olist. All actions are associated with the corresponding
   (S,G) entry.

 o Additionally, if the olist for the (S,G) entry goes to NULL AND there
   is no local membership on the RPF interface towards the source, the
   DR triggers an (S,G) Prune towards the upstream PIM neighbour.

On receiving an (S,G) Prune from its downstream neighbour a PIM-SS
router uses Standard PIM-SM SPT procedures for originating (S,G) Prunes,
updating timers and updating the olist of the entry.

Bhaskar, Kouvelas                                               [Page 6]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

3.1.3.  Tree Maintenance

In the steady state all PIM-SS routers follow the standard PIM-SM SPT
maintenance rules. In addition, PIM-SS routers MUST continue to ori-
ginate periodic (S,G) Joins for an (S,G) entry with a NULL olist if
there is local membership on the iif of the entry.

Standard PIM-SM SPT procedures are used in the event of a unicast rout-
ing change. However, any rules associated with the SPT-bit for the (S,G)
route entry do not apply.

3.1.4.  Operation over Multi-Access Networks

DR election procedures are the same as those specified for PIM-SM in
[2].

Standard PIM-SM Join/Prune suppression SHOULD be used for (S,G)
Join/Prune messages.

The standard PIM-SM Assert mechanism MUST be used to resolve multiple
cases when multiple forwarders send (S,G) traffic to the same LAN. Note,
however, that all Asserts originated by PIM-SS routers are associated
with source trees and MUST always have the MSB of the metric preference
(RPT bit) set to 0.

3.2.  Multicast Data Packet Processing

On receiving a data packet with source address S destination address G,
a PIM-SS router MUST perform an exact-match lookup in its forwarding
database for S and G. If no matching (S,G) entry is found the packet
MUST be dropped. Note that this is different from the longest match
lookup done in PIM-SM.

If a matching (S,G) entry is found a standard PIM iif check MUST be per-
formed. If the packet fails, it MUST be dropped, otherwise the packet
MUST be forwarded out all interfaces in the entry's olist.

3.3.  Inter-Domain Multicast

PIM-SS only builds source-specific shortest-path trees towards the
source.  Therefore, no additional protocol mechanisms, such as MSDP, are
required for inter-domain multicast.

4.  PIM-SS Packet Formats

The following subset of PIM-SM messages defined in [2] is used by PIM-
SS:

Bhaskar, Kouvelas                                               [Page 7]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

 o PIM Hello

 o PIM Join/Prune

 o PIM Assert

The packet formats for these messages are those specified in [2].  In
addition PIM-SS Join/Prune messages MUST have the WC and RP bits set to
0. And PIM-SS Assert messages MUST have the MSB of the metric preference
field, the RPT bit, set to 0.

5.  Interoperability with legacy routers

This section covers the rules for operating in the presence of legacy
PIM routers. In the most common deployment scenario domains will incre-
mentally upgrade routers and run both PIM-SS and other flavors of PIM
but in different group ranges.

For PIM-SS to work in this scenario legacy PIM routers MUST consider the
SSM range to be sparse. This is because PIM-SM routers can understand
the compatible PIM-SS (S,G) Joins/Prune messages and propagate them
upstream. This makes it possible to deploy Source-Specific Multicast by
upgrading only the last hop DRs to be PIM-SS capable.

However, mixed topologies of legacy and upgraded routers may result the
following invalid messages for the SSM range:

 o A legacy first hop DR may send Registers for directly connected
   sources sending to the SSM group range.

 o Legacy routers may originate/propagate (*,G)/(S,G) RP-bit Join/Prune
   messages for the SSM group range.

 o A legacy router may send (*,G) Asserts for groups in the SSM range.

The following interoperability procedures are defined for PIM-SS routers
in mixed networks :

 o A PIM-SS router MUST ignore any shared tree Join/Prune messages that
   are addressed to it. I.e., all (*,G) or (S,G) RP-bit Joins/Prunes.

 o A PIM-SS router SHOULD override all prunes targeted at the RPF neigh-
   bour towards the source with (S,G) Joins to ensure robust forwarding
   of data on the shortest path tree.

 o A PIM-SS router SHOULD respond to (*,G) Assert messages with PIM-SS
   Asserts.

Bhaskar, Kouvelas                                               [Page 8]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

The following configuration or implementation procedures are recommended
for PIM-SM RPs that are SSM aware :

 o A PIM-SS aware RP MUST respond to all Register packets for the SSM
   group range with a Register-Stop message. It SHOULD do no further
   processing of the Register packet.

 o The RP SHOULD not originate or propagate MSDP advertisements for the
   SSM group range.

6.  Security Considerations

All PIM-SS control messages MAY use IPsec to address security concerns.

Bhaskar, Kouvelas                                               [Page 9]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

References

[1] Holbrook, Cain "Source-Specific Multicast", draft-holbrook-ssm-
00.txt, March 2000

[2] Estrin et all.  "Protocol Independent Multicast-Sparse Mode (PIM-
SM): Protocol Specification", draft-ietf-pim-v2-sm-01.txt, October 1999

Bhaskar, Kouvelas                                              [Page 10]

INTERNET-DRAFT                   PIM-SS                    10 March 2000

Authors' Addresses

        Nidhi Bhaskar
        [email-masked]

        Cisco Systems, Inc.
        170 West Tasman Drive,
        San Jose, CA 95134

        Isidor Kouvelas
        [email-masked]

        Cisco Systems, Inc.
        170 West Tasman Drive,
        San Jose, CA 95134

Bhaskar, Kouvelas                                              [Page 11]