Re: PIM : detecting duplicate packet
John Zwiebel <[email protected]>
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
On Dec 9, 2006, at 9:27 PM, tajay wrote: > Hi, > Most of the opimization algorithms in PIM depends on detecting > duplicate packets. > e.g > (1) sending register stop once RP starts receiving duplicate packets > (2) DR @ source sends prunes (S,G) from RPTree whenever it receives > duplicate > packets from source. > > Is there any specific way to identify duplicate packets? And how > feasible it > is to detect duplicate packets at very high rate traffic? To correct a slight misunderstanding, it isn't "duplicate" packets that are being detected, but the arrival of packets on an alternate network path. It is 'assumed' that this will ensure there is no loss of data when switching from the RP-tree to the shortest-path, or from pim registration to the shortest-path. And you have #2 wrong, it isn't the DR at the source, but it is the last-hop router, which may or may not be the DR, that joins to the spt. To be honest, it has never been clearly shown that the complications of such a data-path switch are really useful. In fact, some applications have been shown to croak (or at least not handle well) reception of duplicate packets. You might consider: -- On the last hop router, as soon as receipt of a mpacket down the shared-path creates (S,G) state, immediately sending (S,G,R) prunes while at the same time sending (S,G) joins for the SPT. You will lose some mpackets, but your application probably hasn't had the chance to figure out that there really is data available. -- On the RP, as soon as a PIM-register is received sending a register-stop at the same time you send an (S,G) join. Again, you will lose some mpackets, but it hasn't been shown that applications would recognize this loss. These two suggestions do not comply with the PIM RFC. Its your choice whether or not you think its important enough. z