[Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries.

[shamita pisal]

>Hence, each (*,G) entry needs to have a flag indicating whether it
>is in PIM-SM mode or PIM-Bidir mode.

>Regards,
>Pavlin


hi all,

First of all thanks a lot for your precious guidance for our project.

As per your reply regarding setting the bidir-bit so as to differentiate
between the PIM-SM and PIM-Bidir (*,G) entries ,we are not very clear about
how the (*,G) entries are stored in PIM_SM as per your implementation.(We
tried searching for those in PIM_MRE.hh ,PIM.h,IPv4.h.)So we are unable to
decide the setting of the Bidir-bit for (*,G) entries.

Can we use a flag along with the (*,G) entries and store both of them
together in the templates????

2.)Also as per the PIM-SM RFC (Protocol Independent multicast-Sparse
mode(PIM-SM):Protocol specification(Revised))
Encoded-Group addresses take the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

[B]idirectional PIM
     indicates the group range should use Bidirectional PIM [12]. For
     PIM-SM defined in this specification, this bit MUST be zero.

We have a doubt as how the bidirectional bit is handled in PIM_SM and where
exactly is it handled.

3.)Could we use the same templetes(MRT and MRE)as used in PIM-SM  for
storing the Tables for PIm-Bidir,or do you feel that writing our own
templates would be easier????

4.)Could you also elucidate the implementation of the Packet
headers.(i.eplz tell the files in which we should be looking for it).

Thanking you in anticipation,
Shamita P.


On 2/16/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > hi all,
> > we are implementing the PIM-Bidir in Xorp.we have decided to implement
> > bidir-flag per vif as suggested by Pavlin Sir in his last reply.
>
> To clarify: I didn't suggest that the flag has to be per vif, but
> let you decide that :)
> I intentionally didn't recommend whether the flag to be per vif or
> per PIM instance, because it has been a while since I read the
> PIM-Bidir spec and didn't remember what the spec said about
> incremental PIM-Bidir deployment.
>
> Anyway, I just had a quick look in the latest PIM-Bidir spec
> (draft-ietf-pim-bidir-08.txt), and it doesn't seem that the spec
> allows incremental PIM-Bidir deployment. The following email from
> one of the PIM-Bidir spec authors confirms that:
>
> http://www1.ietf.org/mail-archive/web/pim/current/msg00182.html
>
> Actually, an earlier version of the PIM-Bidir spec
> (draft-ietf-pim-bidir-04.txt) had a section about incremental
> deployment, but this has been removed in -05:
>
> ====================================================
> 5.2.  Appendix B: Interoperability with legacy code
>
> The rules provided in [10] for interoperating between legacy PIM-SM
> routers and new bi-directional capable routers change only slightly to
> support this new proposal. The only difference is in the definition of a
> boundary between a bi-directional capable area and a legacy area of the
> network.  In [10], a bidir capable router forwarding upstream, register
> encapsulates the data packet to the RP if its RPF neighbor is not bidir
> capable.
>
> In our proposal, since all the routers on a link need to co-operate to
> elect the Designated Forwarder, if even one of the routers on the link
> is a legacy router, the election cannot take place. As a result register
> encapsulation is necessary if one or more routers on the RPF interface
> are not bi-directional capable.
>
> As in [10], a Hello option must be used to differentiate between bi-
> directional capable and legacy routers, and (S,G) state must be created
> on the router doing the register encapsulation to prevent loops.
> ====================================================
>
> The newer model seems to be that each multicast group is forwarded
> in PIM-SM or PIM-Bidir mode (see below).
>
> This suggests that a PIM router has to run in PIM-Bidir mode on all
> interfaces (or no interfaces), hence it makes more sence to have a
> single bidir-mode flag per PIM instance.
> It also seems consistent with the Cisco's "ip pim bidir-enable"
> configuration per PIM instance:
>
>
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca796.html
>
> I couldn't find anything about PIM-Bidir in the Juniper
> documentation.
>
> > For bidir mode we have to store only (*,G) entries.So after studying
> > the following classes
> >
> > 1.PimMre  (Pim_Mre.hh),
> > 2.PimMribtable (Pim_Mrib_table),
> > 3.PimMrt.
> >
> > Now as we are implementing the pim_bidir flag per "vif" then that
> > perticular vif can be used for forwarding both type of packets i.e.
> > pim sm and bidir.
> >
> > Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for
> the SM
> > But as we are using same vif for both we need to know weather these
> > entries are same for both?  If they differ then How can we
> > differentiate between them.?
>
> Section "4.  RP Discovery" in the PIM-Bidir spec
> (draft-ietf-pim-bidir-08.txt) says:
>
> ====================================================
> 4.  RP Discovery
>
> Routers discover that a range of multicast group addresses operates in
> bi-directional mode and the address of the Rendezvous-Point address
> (RPA) serving the group range either through static configuration or
> using an automatic RP discovery mechanism like the PIM Bootstrap
> mechanism (BSR) [9] or Auto-RP.
> ====================================================
>
> Hence, each (*,G) entry needs to have a flag indicating whether it
> is in PIM-SM mode or PIM-Bidir mode.
>
> Regards,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070218/52e6be24/attachment.html