SGM Minutes for the 48th IETF
Reported by Dave Oran:
- agenda was bashed with no changes
- purpose is to assess interest in forming a WG to standardize mechanisms to handle small groups.
- contetion is we need methods to deal with a very large number of groups each with few members.
- Dirk Ooms gave introduction showing how SGM fits with existing multicast applications
- Target areas is few-to-few applications- one subset of the very broad classes of multicast (Steve Deering pointed out the application clases are broader than that shown on the slides)
- Believe that routers should not have to keep track of state per multicast flow
- Put up a slide showing two-dimensional space showing "plane of conservation of multicast misery" and putting the variou proposals in different parts of the plane.
- noted issues from the "IESG checklist" for how to constrain the solution space.
- Dirk Oooms presented the connectionless multicast draft
(draft-ooms-cl-multicast-02.txt)
- uses IP option to carry destination list
- no changes to host OS, or APIs (use setsockopt)
- use a session setup protocol like SIP instead of IGMP to handle group membership
- branching routers have to do header manipulation as well as forwarding.
- anonymity bit so receivers don't know who are the other receivers
- Rick Bovie presented his "SGM" draft, draft-bovie-sgm-01.txt
- uses explicit list of addresses in new packet header, existing unicast forwrding talbe
- eliminates per flow state, per flow signaling
- no changes required to hosts, but change to sockets API would be useful.
- no IP header changes, but have a layer 3.5 header which has <IP address, UDPport> pairs. This eliminates the size contstraints on IP options.
- incremental deployment is via tunnels from end hosts to SGM routers, and between SGM routers. This uses a routing protocol (albeit not needed to invent a new one) to establish and maintain the tunnels.
- Steve Deering asked about extra firewall configuration etc. Also pointed out that the extra header or increased header size has to be counted against the savings from eliminating the multicast
- Imai Yuji .. presented the IPv6 multi-destination option draft
- list of desintations in new IPv6 routing header, destination option is for security.
- encoded as a spanning tree of the destination addresses
- Dave Thaler questioned what happened if the packet gets all the way to a host (because no prior router on path understands the packet). Does that mean te end host has to do the splitting? After some confusion, the query was answered yes.
- needs an "exploring ICMP packet" so source hosts know how to encode the spanning tree
- need to have an anti-smurfing mechanism so flood of ICMP unreachables is not unleashed.
- Bart van Doorselaer presented the "xcast with SIP" draft
- SIP with SDP seems natural match for the signaling to establish an xcast-based multicast session.
- Adds a fouth type of multiparty conference scheme to the three already supported by SIP.
- desirable to extend SIP/SDP with UDP port negotiation mechanisms to make xcasr-baset schemes work better.
- O. Paridaens presented the security aspects draft
- membership management and handling of data traffic
- group policy distributed to members, plus receiver can have own policy
- need anti-replay detection - usre source address as well as sequence numbers, or have separate IPSEC SA per sender. This scales OK since groups are small.
- cannot use IKE as is for xcast - 4 altrnatives: manual configuration (ok for small groups), central keyserver with IPSEC tunnel to each member and pushes keying material, distribute keying via SIP or other application protocol, or directly distribute keys via unicast IPSEC.
- Rick Bovie summarized the arguments pro/con.
- seems to be lots of interest based number of drafts and other papers
- application developers have expressed interest
- talked to IBM intranet, AT&T, ITJIT, all say worth pursuing
- what about forwarding performance?
Comments from floor:
- how to deal with SPI lookups which are today based on destination address?
Response: there are techniques to fix this, like by putting dummy address in dest address field.
- Deering: what happens when the n'th person joins and you have to transition between schemes. Hard limit makes applications britle, or do you try to go through a phase shift.
- Maybe best way to get the questions answered is to actually form the working group and have them discussed there.
- Whetten: multicast value proposition is large scale (order of magnitude or more) and auto discuvery. This fails to do either of them, and yet requires changes in hosts (maybe) and routers (maybe).
- Dino: we've been having trouble getting multicast deployed, but it will be
Randy closed the meeting by pointing out that there might be ATM advocates out eating the cookies...
Connectionless Multicast (CLM)
Xcast IPsec and Transport Layer Checksum Considerations
Multiple Destination Option on IPv6
Small Group Multicast (Explicit Multicast) Overview
SIP for Xcast