2.5.9 Protocol Independent Multicast (pim)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-26


Tom Pusateri <pusateri@juniper.net>
Mike McBride <mcbride@cisco.com>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: pim@ietf.org
To Subscribe: http://www1.ietf.org/mailman/listinfo/pim/
Archive: http://www.ietf.org/mail-archive/web/pim/index.html

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
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
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:

Done  Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.
Done  Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard.
Done  Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC
Done  Submit PIM-SM Applicability Statements
Aug 04  Submit PIMv2 MIB to IESG for consideration as proposed standard.
Done  Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts.
Done  Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards.
Mar 05  Submit PIMv2 MIB to IESG for consideration as draft standard.


  • draft-ietf-pim-bidir-07.txt
  • draft-ietf-pim-sm-v2-new-11.txt
  • draft-ietf-pim-sm-bsr-05.txt
  • draft-ietf-pim-anycast-rp-02.txt
  • draft-ietf-pim-proposed-req-01.txt
  • draft-ietf-pim-proxy-00.txt
  • draft-ietf-pim-rpf-vector-00.txt

    Request For Comments:

    RFC3973 E Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)

    Current Meeting Report

    Protocol Independent Multicast WG (pim)

    Wednesday, March 9 at 1530-1730

    CHAIRS: Mike McBride <mmcbride@cisco.com>
    Tom Pusateri <pusateri@juniper.net>


    update on drafts/charter Tom/Mike
    draft-ietf-pim-sm-bsr-05 James
    draft-ietf-pim-proxy-00 Arjen
    draft-ietf-pim-rpf-vector-00 Ice
    draft-savola-pim-lasthop-threats-01 Pekka
    pim refresh reduction design team progress Albert/Venu


    James Lingard


    BSR specified in RFC 2117/RFC 2362
    Work for draft since 2001
    New author team produced revision 04 last year

    Major changs
    support for admin scoped zones
    generalization to bidir-poim as well as pim-sm

    other goals
    backwards compat with rfc2362
    remove genuine errors
    improve clarity and precision of specs

    compat with previous revisions of the draft
    adding extra enhancements and optimizations

    Major changes in 05 rev

    Admin Scoping

    change to handling of ipv6 scopes
    clarification to descrioption of admin scoping

    Minor technical fixes

    fixes to unicast bsm sending/receivpt
    fix to checking of ip router alert ptioon
    fix to rand_override algorithm
    clarification to use of hash mask length

    lots of editorial changes

    Remaing work

    we have made progress

    were approx 70 items on issues list
    now about 30 remaining

    still much to be done

    finalize iw/ew issues
    issues with the bootstrap fsm
    issues with semantic fragmentation
    various other minor problems
    further editorial work

    plan for completion

    resolve all remaining known isues

    produce one more draft with all known issues resolved
    need wg input on certain tech points
    recommend to wait for this draft before detailed review
    should be ready by may

    incorporate wg feedback
    one or two further drafts

    wg last call

    shortly after ietf63


    Venu: what are the compatibility issues

    James: None that would break

    Stig: Scoping is different esp for IPv6

    Venu: could these compat issues be sent to the mailing list

    PIM Proxy

    initial draft submited june 2004
    presented at San Diego and dc ietf
    draft spplit into two parts
    generic encoding fromat
    use of single rpf vector
    removed rd+vector and vector stack


    5 bits for tlv does not give enough room. Other usage.. should not use all 5

    You have the hello option routers understand source encoding format. In case of vector proxy..upsteam might not understand.. it does not guarantee compatibilty..

    Move things that do not belong here to the other draft.

    Generic encoding .. so proxy does not belong here.

    Fenner: Is it enought to change proxy to..

    Venu: Is it only for proxy source and is it for any type of source encoding.. can this be of any encoding type.. There other thing is .. if you make this generic field..
    fenner: one bit indicating

    Vector proxy...

    edge routers have bgp router to source
    bgp next-hop is present in the igp in the core routers
    edge router add bgp next-hop in the pim jp message
    core routers rpf using the vector
    receiving edge router removes vector

    Discussion pts

    name proxy will be changed
    f-bit good or bad thing to have
    use of reserved field to indicate the number of tlvs
    in other words there is no reserved field anymore in the new source
    iana consideration.. who assigns tlv numbers

    Tom: new source encoding type.. will it affect pim snooping switches....

    Venu: is this used only for rpf attribute..given that it might break pim snooping..

    Tom: Past year work has been done. NMS ppl have been using this mib. They have been asked to do IPV6 changes. People doing ipv6 have been asked to do IPv6 mib.


    Define addr family independent
    tables using inetaddress data-type
    similar objects for v4 and v6 defined in common tables
    common updates to both ipv4 and ipv6 mibs
    conversion of ipmroute-mib fulfills need for a mcast routing table mib for
    currently dependency against ipmroute-mib not removed

    represent new protocol features - bidir-pim, new grp-rp mapping, hello
    options et all

    fenner: Coupling of mibs was a mistake. Removing dependency makes sense
    Dave thaler did a draft for ipmroute v6 mib. long expired. no wg. no
    pursuing for it.
    can ask dave to resurrect that work.

    pimnbr entry to have type and address for v4 and v6

    represent neadd additional info to the source encoding
    no room in current source encoding for additional info
    add new source encoing type add info us put in tlv
    this is descrived generic

    protocol features

    grp to rp mapping extended for static, embedded, autorp

    new pim hello options

    addr family independent ip-mroute-mib
    need to enhance iana ipmrouteproto textual convention
    split pim sparsemode into pimssm, pim asm and pim bidir
    add mld
    add in/out pkt stats

    plan of action

    sync up with discussion in the pi-mib list address any other suggestions
    ordering of mib obj
    mib compilation issues
    send mib for review

    Tom: Coming straight to the wg is disappointing before even going to the list

    James: No messages on the mailing list?

    Fenner:There was one in feb.. where is the mib?

    stig: Draft is available?

    Fenner: Captured in archives around sept..

    Tom: I am happy not if you want to get into the main mailing list. Bharath has not sent his changes. So they might get lost.

    Tom is going to do the driving.

    PIM Last Hop Threats


    draft-mboned-mroutesec does not talk about last hop threats.

    There has not been an analysis on last-hop mcast threats.

    These issues deserved to be spelled out.


    Nodes may send unauthorized register messages
    Nodes may become unauthorixed pim nbrs
    Router may accept pim messages from unknown-nbrs
    The spec should probably be tightened here.
    An unauthorized node may be elected as the pim dr.
    A node may become an unauhorized asserted forwarder

    Threats attacks
    Dos on the link
    Dos on the outside
    Confidentiality, integrity and authorization violations

    Mitigation methods

    Pim passive mode
    Using ipsec among the valid routers on a link
    IP filtering of pim messages

    Main issues are with multiple valid pim routers on a link

    you will have to use ipsec betwen them to be secure with just one router, filtering pim messages is a good method

    Now what:

    What is the contribution of this draft?

    Explicit threat vulnerablity analysis and speclling out more elabore description compared to the pim spec section 6.1

    more extensive discussion of non-ipsec countermeasures


    Make this an info rfc of its own

    Merge it with pim-sm spec security consideration section.

    Wait until IESG evaluates the pim spec, ask/see how they react.

    Make this dormant until the pim-sm spec is revised.

    Drop the project completly.

    Bill Fenner: Should not be merged. Spec has been given to iesg. wait and see.

    Tom/Mike: agreed with point 3.

    Bill Fenner: Can be made as an informational rfc

    PIM Refresh Reduction
    pim refresh reduction design team progress

    In the last ietf l3vpn requested PIM WG to come up with pim messaging in the
    context of scalability.

    The PIM WG created a design team to address it. Several solutions were discussed. Tom/Mike working with l3vpn wg to get a requirement. Discussed with l3vpn. Such a doc maybe in the works.

    Regardless of that request it is probably not a bad idea to work on this in this WG.

    As multicast vpn grows there is a possiblity of scaling issues.. years down the line.. more specific number might be required..

    Reduce PIM JP messages. There are no problems currently. But definitely beneficial to reduce the PIM JP messages.

    Thomas Morin: About requirement docs. There will be in the mcast requirement in l3vpn. The draft on mcast vpn described two options: pim and bgp. One or both not decided. We are not clear if this is needed or not.

    Tom: independent of the vpn case.. in case of large nbrs.. large numer of sources/joins.. this is required in those cases..

    Y Cai: How far do we want to go with existing pim. New version of pim(pimv3) or just this draft??

    ??: what is the improvement needed elsewhere? What are the priorities?

    Venu Hemige: scaling for l3vpn and l2vpn

    Tom: We should get a picture if other wg's have this issue.

    ?: We are not making any assertion to fix pim. we are pursuing both options. pim and bgp.. regardless of the outcome.. There is a case scenario.. without improvements.. wrong impression should not be given to l3vpn that this is some kind of a fix.

    Albert Presentation

    JP ack scheme

    Problem and motivation

    Too much processing overhead related to the periodic refresh

    several bgp impl can suport over one million routes, but pim impl cannot support even half

    mvpns and many apps are capable of generating lage stats


    Liming and Albert took this work in 2004 summer.

    Joined force with Dino and Yiqun Cai in Nov 2004 and focused on ack based approach.

    Yiqun/Liming mentioned checksum based solution.

    Suresh's scheme.

    Highlights of JP ack

    Introduce JP ack message to achieve reliable JP message delivery.

    Adding sequence number to PIM JP to achieve in-order delivery.

    Handle other failures such as losing pim nbr and one way failure.

    Disable join suppression and enable explicit member tracking.

    Reliable JP delivery

    Intrduce reliable JP message that is same as regular JP but added sequence numbers.

    Intruduce ack message which is same as reliable JP except message type.

    Use Join-Timer as retranmission timer.

    Stop the join timer when acked.

    Holdtime in reliable join set to oxffff

    Possible to still have low frequence refesh

    In-order message delivery

    A tranmit seq number is maintained seperately for each upstream nbr.

    The transmit seq number is incremented each time a JP message is sent to that nbr.

    Each upstream keeps track of the max sequence number received from a downstream, only accept higher sequence number than the max.

    Encode sequence number as options at the beginning of the reliable JP message.

    Using sequence numbers

    Each PIM entry on the downstream nbr must keep track of the seq no of the lst outbound pim JP message that contained the pim entry.

    And entry is considered acked only when the seq number in the ack mathches the seq number in the pim entry.

    Retransmit method 2

    Use separate retransmission q and receive q for each nbr(sliding window or the like).

    Essentially builds a reliable transmission layer inside pim.

    Pros: no need to maintain seq# in each pim entry, easier in handling rpf change

    Cons: more work and more memory in retransmission q and receive q.

    Prune override no longer works:

    One solution is to use explicit tracking.
    Explicit tracking

    JP and ack can be sent unicast

    Don't have to process JP not intended for you
    Less backward compatible concerns and we have more flxibity and how to encode sequence numbers.


    More code changes and more memory consumption:requires one extra bit per group per nbr

    Recovery from nbr failure?:

    All pim entries learned from the failed nbr must be removed.

    The upstream can either immdeiatedly remove the pim entries or start the expiry timer for those entries and let the timeout handle the removal.

    Recovery from one way failure

    Two nbrs x and y and if x to y direction is failing, y could timeout and
    remove all pim entries,
    learned from x, without x knowing about it.

    Need a way for y to inform x that it has lost the nbr and request a refresh.

    one solution from Dino is to let y to send a unicast hello with genid 0 to x.

    Another: three way hellos

    Issues with TCP based solution?

    In mvpn appl, each pim peering between c instance would require a seperate TCP connection.

    Vpn address family can be introduced to mcast to allow tcp cnnections betwen P-instances to be shared among C-instances but that requires more change in the protocol.

    Venu's Presentation

    Albert has presented beyond what was agreed on the PIM state mailing list. He had given 4 slides but has presented things that I was supposed to present.

    Any questions?

    ?? : Message based ACK seems more complex and not sure what it achieves.

    Bob Kebler: It is more optimal to do ACKs per message - lesser processing. It may not be very intuitive to explain that it is not that complex, but it is.

    Albert: There are reordering issues with the current approaches. And there is complexity and a lot of memory requirements to keep retransmission state. So why not use TCP?

    Venu: We cannot use TCP because snooping will not work. And there are no reordering issues with the current approaches. If it is designed right, the complexity and memory requirements for retransmission state is almost the same as what we need with the current PIM.

    Cisco guy#2: Who said snooping is a requirement? This is news to me.

    Venu: There are two drafts in the l2vpn WG on vpls-multicast. Both rely on snooping.

    Cisco guy#2: But that does not mean snooping is a requirement for pim refresh reduction.

    Venu: Ok, so I guess what is missing is a formal requirement doc from the l2vpn wg, just like one from the l3vpn WG is also missing.

    Mike McBride: Yes, we have not received any requirements from them.

    Yiqun Cai: Maybe we need to take a step back and see how far we want to take PIM. If the goal is to take a big step than just refresh reduction, then we really should be thinking of TCP.

    A few other guys came up and spoke on how we should not be thinking about snooping without any requirements.

    Tom Pusateri: Even for refresh reduction, it seems to me that the joins will have to be unicast. Then why not simply use TCP.

    Mike McBride: Running out of time, so ended the meeting.


    Last-hop Threats to PIM