2.4.10 Source-Specific Multicast (ssm)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 24-Jul-00


Hugh Holbrook <holbrook@cisco.com>
Supratik Bhattacharyya <supratik@sprintlabs.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>

Routing Area Advisor:

Rob Coltun <rcoltun@redback.com>

Mailing Lists:

General Discussion:ssm-interest@external.cisco.com
To Subscribe: mailer@cisco.com
In Body: subscribe ssm-interest
Archive: TBA

Description of Working Group:

The purpose of the SSM working group is to standardize and clearly elucidate the definition of source-specific multicast in such a way as to provide unambiguous semantics to the designers of the protocols and host interfaces used in conjunction with source-specific multicast.

We intend SSM to be a short-lived, highly-focused working group. The working group will handle the following four work items related to SSM:

1) A concise standards-track RFC that clearly defines the source-specific multicast model and its relation to RFC 1112 multicast. This document will specify of the host interfaces to be used for source-specific multicast, the rules that hosts, routers, and protocols must follow when allocating and using source-specific addresses. This document will serve as a reference to RFC authors designing protocols and host interfaces that implement SSM. This document will be parented in the Internet Area, although it will be a product of this working group.

2) A short standards-track RFC that formally allocates the address space to source-specific multicast. (Similar to RFC1918 and to Admin-Scope.), "ratifying" the IANA allocation and referring to the above document for the semantics of the address range.

3) An informational RFC providing an overview of source-specific multicast. This document will serve as a starting point for parties interested in source-specific multicast.

4) SSM can be implemented in routers with slight modifications to the PIM-SM protocol and vendors have implementations in progress. The PIM-SM specification will be rewritten to serve as both a PIM-SM and a "PIM-SSM" specification. The SSM and PIM working groups chairs will jointly submit an IETF last call for this document.

Other SSM-related documents may be taken on as work items by other multicast working groups that have more specific expertise, namely pim, mboned, or idmr. For instance, a document describing IGMPv3 modifications for SSM will (likely) be adopted by IDMR. The SSM working group chairs will cooperate with chairs of the related working groups and the Area Directors to determine the appropriate location of SSM-related documents that arise during the working group's lifetime.

A significant amount of work on SSM has already occurred, therefore we believe that the SSM working group can quickly complete all of its work items.

Goals and Milestones:

Aug 00


First meeting

Aug 00


Submit I-D to alloctate address space to source-specific multicast

Aug 00


Submit source-specific multicast model as internet-draft

Aug 00


Submit I-D for source-specific multicast

Sep 00


Reach consensus on source-specific multicast model and alloctate address space to source-specific multicast

Oct 00


Submit I-Ds on source-specific multicast model and alloctate address space to source-specific multicast to IESG for consideration as RFCs

Mar 01


Submit I-D on source-specific multicast to IESG for consideration as an Informational RFC

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Meeting Notes from SSM working group meeting

scribe: Isidor Kouvelas, edited by Hugh Holbrook

Introduction, Charter, Agenda bashing, (Supratik Bhattacharya)
Two documents as wg drafts:

1) draft-holbrook-ssm-arch-00: Architecture document that describes the SSM service model: This is a standards track RFC.

2) draft-bhattach-ssm-framework-00: Framework document that describes how SSM apps, IGMPv3, PIM-SSM, APIs all fit together to provide source-specific multicast apps. This will be an informational RFC.

They will be resubmitted as working group drafts for the next IETF.

Additionally, the PIM-SSM specification will be submitted jointly with the PIM-WG.

Current working group milestones:

summer 00:

fall 00:

Spring 01:

We have an aggressive schedule!

There are a number of related drafts:

PIM protocol spec. Can serve as a routing protocol that to provide the SSM model. The protocol will, but does not yet, contain a section corresponding to SSM.

The IGMPv3 protocol spec. With minor tweaks, will also be used for SSM.

Describes tweaks to igmpv3 for SSM.

Multicast source filtering API. Describes the source filtering socket APIs that allow a host app to take advantage of source-filtering capability (e.g., IGMPv3).

Describes sdp format for describing source-specific multicast.

An operational doc, will be taken in mboned because it is operational


draft-holbrook-ssm-arch-00.txt (Hugh Holbrook)

Status update on the architecture document. Describes SSM service model. Was previously submitted and presented (in Adelaide) as draft-holbrook-ssm-00.txt.

Changes since last revision (in the meeting I said these had already been done; they are planned, but not in the latest draft):

1) MUSTs downgraded to SHOULD

2) Planning to attempt to move most of Security Considerations to v3 spec, since they are not v3-specific.

3) Split off IGMPv3 SSM section to draft-holbrook-idmr-igmpv4-smm-00.txt


Dave Thaler: Draft will go to proposed standard and must have security consideration section.

Hugh: Yes, the proposed standard will contain a security section.

Tom: Multiple addresses allocated for layered codecs must start allocating at random address.

Hugh: Yes, the draft currently addresses this.

Remaining issues

IGMP document at least should not do that - is reserved (arbitrary selection)

[wg chairs note: The authors have received feedback indicating that it would be better if the document did not address the 232/8 range specifically because a network admin may want to enforce SSM semantics in other parts of the address space. ]

Dave Thaler: Rather not have it explicitly specified but rather reference IANA page. Reserving addresses for link local etc does not belong in 232/8. Avoid colliding with at link layer might be a reason to avoid collisions in this range but cant think of anything else.

Toerless Eckert: Random allocation section was intended to avoid collisions.

Hugh: If no one objects range will be removed from the draft.

someone: AH solves some security issues (denial of service attacks).

Hugh: Good idea, we will mention in the security considerations

draft-bhattach-ssm-framework-00 (Supratik)
Discussion of SSM framework document.

Earlier version of document discussed sprint-specific deployment.



Topics covered:

address allocation, channel discovery, application requirement, modifications to IGMPv3, PIM-SM, interoperability (coexistence with classic multicast)

Dave Thaler:

Should there be discussion on security? YES.

Should the next version have a discussion on Access Control? For example how to disable SSM at a host? (charging for SSM service) Should this be addressed?

The traditional method to provide access control to content is cryptography.

This is more from the point of the ISP who may want to control SSM access from specific receivers.

Dave Thaler:
This is not an SSM-specific problem. It may be the same problem for classic multicast or unicast and hence should not be part of the SSM framework draft.

Jon Crowcroft:
Implications for resource utilisation are different for multicast. ISP may want to think about billing taking into consideration the distribution of receivers...

Access control considerations could be avoided in this document.

Brad Cain:
These issues exist with any service (unicast etc). Only include section if you can find SSM specific issues that differ.

More people agreeing but point out that if no different, then draft should say that the problem is the same as elsewhere.

Issue as informational RFC by spring 2001.

draft-holbrook-idmr-igmpv3-ssm-00.txt (Hugh)
Was previously appendix to draft-holbrook-ssm-00.txt
Contains tweaks to the IGMPv3 protocol for SSM operation.

One primary outstanding issue:

(wg chair note: Brief summary of the IDMR discussion: It was decided to remove the language from the igmpv3 spec that allows hosts to transition to EXCLUDE mode when it no longer has enough memory to maintain all INCLUDE mode requests. The v3 spec will be changed to say that subsequent INCLUDE mode requests must return an error. This solves the problem when all apps perform INCLUDE-mode joins in the SSM address range, but there is still a denial-of-service possible if some other app on the same host does an exclude-mode join in the SSM address range. In IDMR, the consensus was that this was good enough to go ahead with IGMPv3 without causing grief to SSM and that we could investigate flexible host configuration mechanisms that would solve the INCLUDE/EXCLUDE problem later.)

draft-pim-sm-v2-new-00.txt (Hugh)
Update on new PIM SM spec in relation to SSM.

There is not going to be a separate PIM-SSM spec, but rather the SSM specific sections will be pointed out in the pim-sm spec. xItems not needed include: all shared tree (*,G) and (S,G,rpt) processing, bootstrap, RP processing, (*,G) asserts.

Action item for working group (Hugh)
Need to officially define the service provided in 232/8


Mark Handley: This is probably not urgent, though.

Intellectual Property Issue (Hugh)

Apple holds a patents that might possibly cover SSM. We hope Apple will donate the patents to IETF. It is not clear that SSM infringes the patent, but we are letting people know of its existence. So be nice to Apple people :-).

Questions from the field

Dino: Has anyone looked into the implications with BGMP?
Dave: No changes required to BGMP protocol document. Some to SSM docs...

Automatic Tunneling and Multicast on Demand (Doron Rajwan)

o Automatic tunneling

Suggest a simple mechanism using a tunnel so that a host outside an SSM domain can send a UDP packet asking to create a tunnel and receive SSM traffic. Use a mechanism like traceroute to query routers along the path to a source and find the closest one capable of supporting this mechanism.

When multiple clients from a non-SSM domain wish to receive traffic, they hit the same border router in the SSM capable domain which has to replicate the session and unicast it to each receiver.

Dave Thaler:

Someone noted that the IDMF proposal in MSDP WG is similar.

o Multicast on Demand

Summary of the presentation: should we extend IGMP in some way to have the source query the router if there are any receivers before attempting to send, and/or have the router notify the host when there *are* receivers.

Dave Thaler: This is a good idea but we should not slow down IGMPv3 standardisation so we should attempt to work on this independently.

Jon Crowcroft: in favor of this idea.


None received.