slide1
Download
Skip this Video
Download Presentation
Hitoshi Asaeda (Keio University)

Loading in 2 Seconds...

play fullscreen
1 / 13

Hitoshi Asaeda (Keio University) - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Hitoshi Asaeda (Keio University)' - aine


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

objectives
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

functions
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

objective 1 the number of messages transmission
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

current state report regular case
Current-State Report – Regular Case
  • Responses for General Query
  • Responses for Group- (and-Source) Specific Query

78th IETF, July 2010, Maastricht

lower specific query transmission
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

current state report with explicit tracking function
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

outdated state information
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

objective 2 leave latency
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

shortening leave latencies
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

membership state information
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

interoperability and compatibility
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

next step
Next Step
  • WG document?

78th IETF, July 2010, Maastricht

ad