1.1 MultiMob BoF 1.1.1 Scope of the BOF Two main items in proposed charter - mobility extensions for group management protocols, and PMIP6 multicast support. 1.1.2 IGMP and MLD Requirements for Mobility Support Difficult to change IGMP because implementations are very widespread. Mobility issues - power, CPU, minimize flooding, support point-to-point IGMP/MLD message transmission. Gorry - have we made the decision to obsolete IGMPv3 for IGMP-lite? No, and we wouldn't make such a decision - this would come from MBONED/MAGMA. Handover is an open issue now. Take IGMPv1 out of the current draft? Can we even consider extensions to IGMPv3/MLDv2 to facilitate fast handovers? Do not have consensus on RF point-to-point and point-to-multipoint links - to we have point-to-multipoint at layer 3? Would like AD guidance on scope and what's realistic. Who has read this document? About 25 percent of the group. Is it a good start? About 90 percent of the people who'd read it. Jari - not sure if we can change things, or are we talking about doing a BCP on the way things are? Need to be guided by deployment, and not sure we have one solution for everything. Gorry - document says what we have, not sure what we're trying to do here - requirements document isn't that mature. Brian - when you talk about changes to IGMP, you need support from everything in the network - including boxes like switches that you didn't know were affected. Juan? - didn't mention DVB? Project in Europe is looking at both wireless lan and wimax. Could you guys look at this? IEEE 802.21 is working on this and has liaisons - we don't think we have one, though. Behcet - could be used with PMIP, our other proposed charter item? Marshall wouldn't be surprised. Rajeev - for mobility aspects, seamless transition, IGMP shouldn't be changed at all, should rely on mobility protocols to carry state across routers. Marshall liked this suggestion. Behcet thinks he's been here before, and ended up looking at IGMP. Hitoshi - this draft is requirements, solution should be discussed separately. Rajeev - remember how hard it is to make changes to IGMP. What's the problem? Running IGMP efficiently over wireless links, doing handoffs is different. Raj - not clear what the problems are. Are people running 802.11/802.16 and reporting problems? Brian hasn't, but this is an open question. 1.1.3 Multicast Support Requirements for PMIPv6 PMIPv6 doesn't support group communication today. This presentation provided specific requirements. Zhang - can the network subscribe on behalf of the mobile node? This is allowed - no conflict. Raj - is this list coming from design team? These are general multicast requirements - is there anything specific to PMIPv6? Jari - thought that everything "just worked" from the mobile node's perspective - is that correct? Jari - if these changes aren't visible to the host, are you suggesting more policy control, different, etc? Want the same policy for PMIP as everything else. PMIP AAA is mostly about access to the network, not at a flow level - should be the same for multicast. Jonne - requirements not depending on mobility? Are you saying all multicast traffic has to go through a policy enforcement point? Agree that some requirements aren't mobility-related. Brian - most mobility AAA is a central enforcement point. Raj - Multicast Bandwidth Control requirement has too many architectural points - not requirements. Jari - just make mobility work, don't worry about AAA, etc. Jonne - question is about AAA for multicast - that's not what we're talking about in multimob. Who has read this draft? About 15. Who thinks it's a good start on multicast support in PMIP6? About 11 or 12. 1.1.4 Consensus and Charter Discussion PMIPv6 support of multicast? Raj - don't see the need for multicast-specific operations, based on deployments so far. Could be interesting, but not yet. Jari - because there's no multicast traffic? Raj - current direction doesn't require enablers, even with PMIPv6. Would work well without this work. Hitoshi - have already done this, need extension for seamless handover. Suresh - don't agree with Raj, think there is a problem if there's multicast traffic (replicated once per listener). Rajeev - what is different here? Can see three problems - changes to IGMP, native multicast, existing subscriptions when routers hand off. These problems aren't in the charter - need to enumerate the problems clearly. Behcet - text we have is correct, MIP6 has text on multicast but PMIPv6 does not, it's unicast-only. Jari - but PMIP is based on MIP6, don't see major problem here. Not optimal. Think presentations have been confusing, too many requirements. Think the two issues identified are key issues, get rid of other requirements. Do we actually want this work done? Rajeev - look at the documents you want to provide, what problems are you solving? Frank - agree with Rajiv and Jari, think we can polish charter text. PMIPv6 was done for unicast, needs optimization for multicast. If we restated charter the way Rajeev was suggesting (eliminate the use of tunnels), who would support that work? Jari - two things going on here, discussion to clarify requirements and asking who wants to do this work. Would people support focusing requirements on handover support and eliminating tunnels? About 15 raised hands. Opposed? 1. Are we missing requirements? Hitoshi Tunnel elimination, but sometimes they are useful. Can't say this now. Vidya - have we established the need for this work? Brian - don't know, would like operational guidance here. Requirements are from IRTF, don't know genesis. Jari - primary reason to be here is to find out who wants to do this work - not overwhelming response, but more than a handful. Don't want to work on theoretical requirements. Jonne - thought question was "if the work goes forward would you narrow it?" Raj - LMA could be part of multicast tree, MAG could be . don't make assumptions about where multicast traffic actually goes. Hitoshi One scenario is that the traffic is not flowing through the LMA. Suresh - MAG can join the tree, but we're trying to solve two problems together. Vidya - have a lot of questions on the charter. Don't know what work we're actually talking about - charter is all over the map. Brian - trying to narrow down to two work areas. Jari - we're going with high-level description, need to focus on that now. Stig - interested in multicast mobility, but PMIPv6 is too restrictive. Greg - seems to be lack of clarity about right-sizing of the charter, could you actually type what you've narrowed down to? OBTW, dormant mode isn't just for handsets any more. infrastructure can also go dormant in order to be more "green". Marshall - does that have implications about timing for these devices? Greg has no idea. Marshall thinks the answer is "no", because the device is self-clocking. ??? - that's normal 802.11 mechanism, can be used by infrastructure with 100-ms delay. Vidya - text assumes that MAG is multicast router, as long as that's true, that's fine, routing is already optimized, unless the multicast is anchored at the LMA. Do we know what unoptimized behavior is now? ??? - optimization of what? We have tunnel between LMA and MAG, you can use it or not, if you're multicast-enabled you don't use the tunnel anyway. Jari - we are confused about what the existing specs say. Optimization may not be protocol work, might be BCP, etc. ??? - efficient multicast state handover is pretty clear, optimization of multicast traffic is less clear. Greg - is LMA to MAG case predominant? We don't know, because specs don't address multicast today. Does the working group need to figure this out? Vidya - we have overall problem defining multicast with mobility, period. Then we can talk about PMIPv6. Rajeev - can still have mobile sending directly to home network. Bill - multicast state handover is at least level 4/5. What level do you think you're working at? Has to be coupled in with AAA. 1.1.5 Summary Should we start with multicast and mobility? Jari - meeting has shown we need discussion, maybe even a document on how we deploy multicast over mobility. That's work that needs to be done. Don't have clear enough problem description to ask questions, need to go back to the list. My sense is that we're looking at informational documents, at least to get started. Does that work for everyone? No objections voiced.