NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Hugh Holbrook <holbrook@cisco.com>
Supratik Bhattacharyya <supratik@sprintlabs.com>
David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>
Rob Coltun <rcoltun@redback.com>
General Discussion:ssm-interest@external.cisco.com
To Subscribe: mailer@cisco.com
In Body: subscribe ssm-interest
Archive: TBA
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 232.0.0.0/8 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.
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 |
SSM working group minutes
March 2001 IETF Minneapolis, MN
-----------------------------
Updates on existing ssm drafts
holbrook-ssm-arch 02
Hugh Holbrook gave update
Addressed ipv6
Added examples and address range
Ready for wg last call for proposed standard
bhattach-pim-ssm
Supratik gave update
Added IPv6 and security discussion
Remaining: conformance with the architecture
Headed for informational
Need comments
holbrook-idmr-igmpv-v3-ssm-01
Hugh Holbrook gave update
New changes
IGMP module should have configuration option for
SSM ranges
Default to IANA range
Must allow for manual config
IGMPv3 hosts MUST not transition to exclude mode when it runs out of resources. Now in base igmpv3 spec.
This doc will move to new MAGMA working group should it be approved.
He-mixed-igmp-proxy
He gave update
Current igmp proxying draft only addresses behavior for same version proxying
With mixed versions, there are some differences :
v3 to v2 - v2 on upstream, v3 on downstream
v3 joins translated to v2 joins forwarding is still done based on v3 info
v2 to v3 - proxy should drop v2 joins in ssm range
Hugh pointed out that faking v3 when you have v2 upstream routers is a configuration bug.
Dave Thaler gave an example of where proxy must look at source address and not just transparently send upstream to router when source is not toward router.
Hal Sandick would like to see transition section updated before last call.
draft-kim-ssm-hierarchical-scheme-00
Myung-ki Shin talked about their draft
SSM ignores deployment issues in inter-domain
Hierarchical considerations should be considered
Automatic tunneling between border gateway and source not on multicast network
Receiver requirements
no changes required
Border gateway router requirements
sends unicast registration to source
Source requirements
source receives registration message and tunnels
ssm data to all border gateway routers
Dave Meyer
Suggested that SSM doesn't have a scaling problem.
Concerned that this draft solves a problem we don't have consensus that this is an incremental deployment solution that should be discussed in MBONED.
DNS for SSM
Hugh summarized discussion on mailing list
Jeff Schoch :
mcast.example.com IN A 10.10.10.42
radio.mcast.example.com IN A 232.1.1.1
Dino :
radio.example.com IN AA
10.1.1.1.232.1.1.1
Toerless :
just use SDP
draft-schoch-dns-ssm :
Jeff Schoch gave a talk on his proposal :
Little change to existing infrastructure, keep it simple
Proposal: group.source.domain-name
Joel objected to this method : doesn't give you the info you really need. SDP does have all the info you need, not just the IP addresses.
Dave Thaler agreed with Joel
Hugh repeated that on the mailing list it was mentioned that this might be useful for debugging.
Dave Meyer did not like the idea of putting semantic context in the DNS.
Off topic, Dave would like us to use ASM (Any source multicast) instead of
ISM (Internet standard multicast)
Ross Finlayson said use
SIM (source independent multicast)
Hugh polled the working group on AA records.
Dave Meyer still objected.
Joel said while people may want a replacement for SDR, we don't really need one. Multicast is no different than unicast in this sense.
Hugh said others thought it might be useful for mtrace
Marshall didn't think it was ever useful to have names to map to group and source.
Jeremy Hall said that people with access to sources aren't the same people with access to DNS.
No conclusion reached, the discussion is to be taken to the mailing list.
Charter Bashing
Charter item have been fulfilled.
There are no new action items
We expect this is the last meeting.