1 / 13

Hitoshi Asaeda (Keio University)

78 th IETF, Maastricht, Netherlands, July 2010. IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers draft-asaeda-mboned-explicit-tracking-00. Hitoshi Asaeda (Keio University). Objectives. Problem in bursty IGMP/MLD message transmission

aine
Download Presentation

Hitoshi Asaeda (Keio University)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 78th IETF, Maastricht, Netherlands, July 2010 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routersdraft-asaeda-mboned-explicit-tracking-00 Hitoshi Asaeda (Keio University) 78th IETF, July 2010, Maastricht

  2. Objectives • Problem in bursty IGMP/MLD message transmission • Especially in the recent IGMPv3/MLDv2/LW-IGMPv3/LW-MLDv2 due to elimination of the report suppression mechanism • Requirement to save wireless network resources (in multimob WG) • Requirement of fast leave or shortening leave latency 78th IETF, July 2010, Maastricht

  3. Functions • The explicit tracking function on routers (described in a separate draft) works for: • Per-host accounting • Reducing the number of transmitted Query and Report messages • Shortening leave latencies • Maintaining multicast channel characteristics (or statistics) 78th IETF, July 2010, Maastricht

  4. Objective 1: the Number of Messages Transmission • Whenever a router receives the State-Change Report, it sends the corresponding Group-Specific or Group-and-Source Specific Query messages to confirm whether the Report sender is the last member host or not. 78th IETF, July 2010, Maastricht

  5. Current-State Report – Regular Case • Responses for General Query • Responses for Group- (and-Source) Specific Query 78th IETF, July 2010, Maastricht

  6. Lower Specific Query Transmission • A router enabling the explicit tracking function does not need to always ask Current-State Report message transmission to the member hosts whenever it receives the State-Change Report • Because the explicit tracking function works with the expectation that the State-Change Report sender is the last remaining member of the channel 78th IETF, July 2010, Maastricht

  7. Current-State Report – With Explicit Tracking Function • Responses for General Query • No responses for Group- (and-Source) Specific Query 0h 20m 78th IETF, July 2010, Maastricht

  8. Outdated State Information • When a router expects that the State-Change Report sender was the sole member, but not the one, or when the number of receivers in the state information becomes “0”, but not “0”; • Other members remaining in the same channel will reply with identical Report messages • When a router expects that there are other members, but there isn’t, or when the number of receivers in the state information is not “0”, but it is “0”; • The router sends periodical General Query later but does not receive the corresponding Report; it then starts the leave operation • Will add some intelligence (e.g., send State-Change Report when the number of remaining members is less than “5”, etc.) 78th IETF, July 2010, Maastricht

  9. Objective 2: Leave Latency • [Last Member Query Interval] (LMQI) and [Last Listener Query Interval] (LLQI) • The maximum time allowed before sending a responding Report • [Last Member Query Count] (LMQC) and [Last Listener Query Count] (LLQC) • The number of Group-Specific Queries or Group-and-Source Specific Queries sent before the router assumes there are no local members • [Last Member Query Time] (LMQT) and [Last Listener Query Time] (LLQT) • Total time the router should wait for a report, after the Querier has sent the first query 78th IETF, July 2010, Maastricht

  10. Shortening Leave Latencies • [Last Member Query Timer (LMQT)] and [Last Listener Query Timer (LLQT)] • Default: LMQI/LLQI * LMQC/LLQC (= 2 sec.) • Shorter value contributes to shortening leave latency • Proposal • LMQC/LLQC = 1, thus LMQT/LLQT = 1 sec. • Note, LMQI/LLQI can be shorter, e.g., 0.5 sec. • Note • The risk that a router misses Report messages from remaining members will be increased if the router adopts small LMQC/LLQC • However the wrong expectation would be lower happened for the router enabling the explicit tracking function. 78th IETF, July 2010, Maastricht

  11. Membership State Information • Complete state information • (S, G, number of receivers, (receiver records)) • Minimum state information • (S, G, number of receivers) • Pro.: Minimizing memory usage • Con.: No accounting support • ASM • “S” is with “Null” • EXCLUDE mode • Not integrate state information • Just keep the current state without modification 78th IETF, July 2010, Maastricht

  12. Interoperability and Compatibility • Not work for old IGMP/MLD • Because of Report suppression mechanism • Keep the current state as is • Not work for IGMPv3/MLDv2 router changing its compatibility mode to the older version • Keep the current state as is 78th IETF, July 2010, Maastricht

  13. Next Step • WG document? 78th IETF, July 2010, Maastricht

More Related