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: - Initial presentations of architecture and framework fall 00: - Advance architecture to proposed - Revisions of the framework document - Get IANA to bind 232/8 to architecture document Spring 01: - Framework document ready to go to Informational We have an aggressive schedule! There are a number of related drafts: draft-ietf-pim-sm-v2-new 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. draft-ietf-idmr-igmp-v3 The IGMPv3 protocol spec. With minor tweaks, will also be used for SSM. draft-holbrook-idmr-igmpv3-ssm-00: Describes tweaks to igmpv3 for SSM. draft-ietf-idmr-msf-api-01: 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). draft-mmusic-sdp-srcfilter-00: describes sdp format for describing source-specific multicast. draft-shepherd-ssm232-00: An operational doc, will be taken in mboned because it is operational Agenda: - Architecture draft - Framework draft - IGMPv3 mods for SSM - PIM-SSM - Binding 232/8 to SSM - Automatic tunneling and multicast on demand 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 - drop data if not (S,G) - ignore (*,G) joins - use random allocation 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 Comments -------- 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 - Consensus in the room was that the document should be adopted by the working group. - Document refers explicitly to 232/8 IGMP document at least should not do that 232.0.0.0 - 232.0.0.255 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 224.0.0.1 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. Changes: - Cleaned up writing - Rewritten as a general framework (removed spring dependencies) Goal: - Provide overview of SSM - Starting point for deployment Topics covered: - Classic multicast and some problems - SSM and its benefits - Elements in an end-to-end SSM framework: address allocation, channel discovery, application requirement, modifications to IGMPv3, PIM-SM, interoperability (coexistence with classic multicast) Dave Thaler: - Framework should not specifically reference IGMPv3 and PIM-SM and should be generic enough (e.g. usable with IPv6 equivalents). 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? SMUG: The traditional method to provide access control to content is cryptography. Supratik: 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... Supratik: 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. Plans: 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: - If a host transitions to EXCLUDE mode in 232/8 applications will stop receiving traffic. - Several proposed solutions which may impact v3 implementations - Will be presented at IDMR as solutions impact IGMPv3 implementations. (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 Proposal: - Get IANA to bind 232/8 to draft-holbrook-ssm-arch-00.txt 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: - You cannot just modify the destination of data packets so you have to encapsulate (especially with IPSEC) - Main issue with arbitrary tunneling is access control. Alternative used in IP6bone is tunnel broker which can be located through some mechanism other than traceroute (not a router). - NGtrans WG has similar issues... 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.