Minutes from the pittsburgh ssm wg meeting

[Hugh Holbrook <holbrook@cisco.com>]

Here are the meeting notes minutes.  We are going to put up the web
site this week, too.

-Hugh and Supratik

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.