Multimob (Multicast Mobility) IETF-77 Chairs: Stig Venaas and Behcet Sarikaya Note-taker: Matthias Waehlisch Behcet: Presented the agenda and the IETF Note-Well. Behcet: Presented the WG status. Base Deployment for Multicast Listener Support in PMIPv6 Domains. Thomas: Presented draft-ietf-multimob-pmipv6-base-solution. Raj Patil: Is the aggregated join an optimization? Thomas: No, it is regular MLD proxying. Raj: When MN moves to MAG2. Why do you need a join again? Thomas: Base PMIP provides only unicast attachment. It does not know about mcast context. MAG2 has to learn multicast groups. That is based on standard operations. Raj: OK. Jari: Clarification question: Is the aggregated join inside tunnel. Thomas: Yes. Jari: You are copying within multicast tunnels ... Thomas: Yes, but that follows normal multicasting. Raj: Regarding operations at node arrival: Do you need new functions? Thomas: No, the MAG will query anyway. The question is how fast. However, that is not clear from the MLD specification. Raj: Do you need additional functionalities for the implementation at the MAG. Thomas: No, combine existing technologies, MAG will behave as implementations are (MLD etc.). Stig: It is common to query immediately if the link comes up (with a short delay). Sri Gundavelli: Is a MAG-to-MAG interface assumed here? Thomas: No. Sri: What is the typically cost with respect to data lost? Thomas: We have not done simulations so far. Sri: Is there a context transfer? Just want to understand the costs during handover. Thomas: No, but in general, packet loss depends on the query behaviour and the distance between nMAG and LMA. Stig: The proposed draft is a basic solution and thus has some issues. We hope to improve it later. Stig: Comment on "Capabilites needed at Proxy": It could be different instances for IGMP and MLD, if necessary. Sri: How does the MAG differentiate between local and home networks. Thomas: The current spec does not support local multicast routing. Raj: When does the MN initiate the join: Multicast group available at the MAG and not LMA. Thomas: Multicast behaviour of the MN is totally transparent. Sri: From the network point of view: Local services are remote services. Stig: There is no big deal to choose that all multicast data will be transmitted from LMA. But if you want to get some groups locally and some remotely, it gets harder. Thomas: You need some more functions at PMIP entities. Raj: I do not see special for multihoming. Thomas: Agree, mentioning this is more for completeness, it is more editorial stuff. Susan Hares: What is the status of Linux implementation etc.? Thomas: Mainly tested the behaviour of general MLD and MLD proxy implementations w.r.t. protocol requirements. Susan: There is some MLD benchmarking done. Have you gone beyond interoperability? Thomas: Yes, we have done some measurements on timing behaviour. Time scale is in the appendix in the draft. Behcet: Can you talk about the tunnel convergence problem. Thomas: Summarized the outcome of list discussions. Hitoshi: Can you clarify the idea of proxy instances. Thomas: One proxy instance of a MAG is attached to one LMA. Stig: Hoping to initiate WG last call on the draft before next IETF. Raj: Probably better first to get some simulation results, before thinking about optimization. Tuning the behaviour of IGMP and MLD for mobile hosts and routers. Hitoshi: Presented draft-asaeda-multimob-igmp-mld-optimization-02. Qin Wu: Regarding explicit tracking: Think that is a nice feature, but explicit tracking depends on general query. I am confused about the description in the draft. Explicit tracking and general query can be used together. In your draft, you say explicit tracking must use general queries. Hitoshi: No. Gorry Fairhurst: The draft does not present anything new. Hitoshi: Just giving background information, and describing parameter tuning. Gorry: Yes, but it should be more precise, not only "make general query longer". Stig: PMIP uses point-to-point link, thus, explicit tracking happens implicitly. Gorry: Why you unicast explicit tracking. Qin: Described a use case. Gorry: When do you send a group specific query? Hitoshi: When router and receivers state change. Gorry: If you use explicit tracking, you do not need confirmation. Hitoshi: But packets may be lost. Stig: Agree with Gorry. One of the benefits of explicit tracking is not to send a confirmation. Qin: Regarding parameter tuning: Timer values must be considered in some context. Values depend on the behaviour and environment. It is confusing without scenario descriptions. Thomas: Different wireless link models should be considered. Stig: It is good to have a brief section with timers and mention the obvious, but separate from this it would be good to discuss different link types etc. Gorry: I do not find many useful in the draft, only a lot of background information. IGMP/MLD Tuning for Mobility. Qin: Presented draft-wu-multimob-igmp-mld-tuning-00. Thomas: Different link types are present everywhere. But in wireless, transmission quality etc. are the challenge. Stig: Regarding requirement list: Explicit tracking should not be a requirement. It is a tool to achieve the requirements. Gorry: Agree with Stig comments. "Fast Join and Leave" are different requirements as different mechanisms involved. Stig: Regarding optimization of report messages: Good idea, but seems like change of protocol, at least change of host behaviour. It is more than tuning. Gorry: The proposal is a data driven approach. Is this a protocol change? Stig: It requires C-code changes, not only parameter tuning. It goes a bit outside of tuning. Qin: It is not mandatory. Gorry: Suggest to send multiple unsolicited reports. Hitoshi: It is not possible to disable group/source-group specific queries. Gorry: I do not agree. You can have an explicit list of members. Suresh Krishnan: A query after receiver left is important. Stig: Agree with Gorry, but we run out of time. Move discussion to the list. Hitoshi: Protocol change includes behaviour change. Hitoshi: How do we detect at the router that queries are lost? Stig: You can assume or guess that is lost. A router has to send the general query anyway. Suresh: Regarding Optimization considerations for link type: you assume some implementation at the router for PTMP. Qin: Yes. Marshall: Behcet: Both MLD/IGMP tuning drafts are not in a state to get adopted at the moment. Authors should incorporate comments of the current meeting etc. Stig: Encouraged authors to work together. M-LMA Solution. Akbar Rahman: Presented draft-zuniga-multimob-smspmip-02. Hitoshi: Is the optimization with or without protocol modification? Akbar: It includes protocol modifications. The approach should be considered for future work. Stig: The rest of the meeting is regarding future work. It is out-of-scope of the current charter. Thomas: What do you mean with your multicast entity. Does it maintain MN state or rather is it a dedicated router that operates only multicast states? Akbar: It operates in the sense of a dedicated router. Rajeev Koodli: Why should we introduce functional or logical separate entities. Akbar: In certain traffic scenarios, you will get less replications of packets. Akbar: The scenario of same multicast groups anchored at the same MAG may be a more real deployment scenario. Seil Jeon: One LMA for all multicast groups seem not appropriate. Behcet: Take it to the list due to time constraints. FMIPv6/PFMIPv6 multicast extensions. Thomas: Presented draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01. Hui Deng: Just clarification: Is this WG cover FMIPv6 etc. Stig: Future work. PMIPv6 Fast Handover. Hui Deng: Presented draft-hui-multimob-fast-handover-00. Raj: Do you expect to use a new tunnel between pMAG and nMAG? Hui: We will clarify this. Rajeev: You do not need a separate tunnel. Problem Statement/Requirements Presentation Pierrick Seite: Presented draft-von-hugo-multimob-future-work-01