Current Meeting Report
Jabber Logs

2.5.6 Protocol Independent Multicast (pim)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/30/2002

T. Pusateri <>
L. Wei <>
Routing Area Director(s):
Bill Fenner <>
Alex Zinin <>
Routing Area Advisor:
Alex Zinin <>
Mailing Lists:
General Discussion:
To Subscribe:
Description of Working Group:
The Protocol Independent Multicast (PIM) Working Group is chartered to standardize and promote the Protocol Independent Multicast Version 2 (PIMv2), Sparse Mode and Dense Mode, as a scalable, efficient and robust multicast routing protocol, capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. The working group will decide if there is a need for any follow on work or version 3 of the protocol.

This working group will act as a consultant to any PIM-over-Foo proposals, including but not limited to PIM-over-ATM, using PIM for multiprotocol label switching, and PIM-over-UDLR links.


1) PIM-SM v2 specification (standards track)

This document is a specification for Sparse Mode Protocol Independent Multicast.

2) PIM-DM v2 speficication (standards track)

This document is a specification for Dense Mode Protocol Independent Multicast.

3) PIM MIB (standards track)

This document contains the MIB definitions for PIMv2.

Goals and Milestones:
AUG 98  Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.
AUG 98  Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard.
AUG 98  Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC
DEC 98  Submit Internet-Draft describing use of IP security with PIM.
DEC 98  Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts.
APR 99  Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards.
APR 99  Submit PIM-SM and PIM-DM Applicability Statements
APR 99  Submit PIMv2 MIB to IESG for consideration as proposed standard.
NOV 99  Submit PIMv2 MIB to IESG for consideration as draft standard.
  • - draft-ietf-pim-bidir-04.txt
  • - draft-ietf-pim-sm-v2-new-05.txt
  • - draft-ietf-pim-dm-new-v2-01.txt
  • - draft-ietf-pim-mib-v2-00.txt
  • No Request For Comments

    Current Meeting Report

    Salon II RTG	pim	Protocol Independent Multicast WG *
    PIM-DM - 
    No one had reviewed the draft !!!
    Review by the group is badly needed !!!!
    Discussion about whether this should be experimental, 
    informational or standards track.
    Seemed to be no consensus.
    Radia Pearlman
    PIM Host extensions
    the end nodes do PIM
    intended to work for SSM
    SSM now requires IGMPv3 support in the Host and the First Hop router.
    PIM-HE - creates a unicast PIM Host Join message - destination of this 
    packet is S Uses the IP router alert option on the IP header so that 
    compliant routers can trap and process. If the router that receives this 
    message is not first hop then the router Creates a tunnel fo the 
    Process/demon is downloadable
    Host-leave prune message needed as well
    If first hop router receives, then just join the group. If not, then Have to 
    worry about DOS attacks, so need to limit numbers of tunnels
    Need to authenticate 
    Q. How is this different from Ross Finlayson's automatic UDP encoding ?
    A. Conceptually not very different - just one is UDP based and this one 
    uses PIM.
    Q. What if the tunnel connects two PIM domains ?
    Dino F. - the difference is that the host just accepts multicast data  when 
    it comes while a router does RPF checks. 
    Mark Handley - I think that tunnels  between PIM clouds could create all 
    sorts of problems and you might want to avoid this.
    A. Solving the first mile problem is what we were focusing on here.
    Mark Handley. I am worried about implosion problems. What if this gets 
    really popular.
    A. This allows some people to join, whereas before they couldn't get 
    traffic at all.
    Q. Dino F. - why make joins periodic ?
    A. (to make them soft state)
    Q. Liming W - Packets with Router alert may be blocked for, e.g., Cisco 
    A.  I believe that this is not the case for all Cisco routers. 
    A. Dino F.
    If the a packet of a given protocol comes with a router alert, three 
    things could happen
    - - - if the protocol is unknown, forward
    - - - if the protocol is PIM, gets sent to the PIM module, which will drop 
    - - - to do the right thing would require a new implementation, and old 
    implementations would not do the right thing.
    Q. Mark Handley Once the script kiddies discover router alerts, then 
    everyone will stop forwarding them.
    Bill Fenner - A useful thing would be to send packets with router alerts 
    across real networks and see what happens,
    Dino F. IGMPv2 and RSVP are the most common users of router alerts.
    Beau Williamson - In my opinion, most of these tunneling ideas are 
    something we can do technically, the real problems are getting it done from a 
    business standpoint.
    Tom P. Should this be a part of the working group charter ? Or MboneD
    <Consensus seemed to be no, it should be in MBoneD>
    Mark Handley
    The PIM-SM spec has timed out. The spec is in good shape though.
    IP Sec AH has been added. This is exactly what was done for IGMPv3 spec, and 
    the IESG passed that.
    Dave Thaler - I was just at the SEND WG and they have the exact same 
    Mark Handley - The other spec is the BSR spec.
    Tom P. Does the PIM spec depend on the BSR spec ?
    Mark Handley - It is not totally clear if it does. Certainly 
    That leaves the BiDir Spec
    Isadore K. The BiDir spec is coming. It can maybe submitted at the same 
    time Tom. P. So we need to do one more rev of that ?
    Isadore K. - And also of the PIM spec.


    None received.