draft-ietf-pim-sm-v2-new-03.txt

xorp源码hg

In addition we use C-like syntax:

=   denotes assignment of a variable.

==  denotes a comparison for equality.

!=  denotes a comparison for inequality.

Braces { and } are used for grouping.


3.  PIM-SM Protocol Overview

This section provides an overview of PIM-SM behavior.  It is intended as
an introduction to how PIM-SM works, and is NOT definitive.  For the
definitive specification, see Section 4.

PIM relies on an underlying topology-gathering protocol to populate a
routing table with routes.  This routing table is called the MRIB or
Multicast Routing Information Base.  The routes in this table may be
taken directly from the unicast routing table, or it may be different
and provided by a separate routing protocol such as MBGP [1]. In any
event, the routes in the MRIB must represent a multicast-capable path to
each subnet.  The MRIB is used to determine the path that PIM control
messages such as Join messages take to get to the source subnet, and
data flows along the reverse path of the Join messages.  Thus, in
contrast to the unicast RIB where the routes give a path that data
packets take to get to each subnet, the MRIB gives reverse-path
information, and indicates the path that data packets would take from
each subnet to the router that has the MRIB.

Like all multicast routing protocols that implement the service model
from RFC 1112 [2], PIM-SM must be able to route data packets from
sources to receivers without either the sources or receivers knowing a-
priori of the existence of the others.  This is essentially done in
three phases, although as senders and receivers may come and go at any
time, all three phases may be occur simultaneously.

Phase One: RP Tree

In phase one, a multicast receiver expresses its interest in receiving
traffic destined for a multicast group.  Typically it does this using
IGMP [3], but other mechanisms might also serve this purpose.  One of
the receiver's local routers is elected as the Designated Router (DR)
for that subnet.  On receiving the receiver's expression of interest,
the DR then sends a PIM Join message towards the RP for that multicast
group.  This Join message is known as a (*,G) Join because it joins
group G for all sources to that group.  The (*,G) Join travels hop-by-



Fenner/Handley/Holbrook/Kouvelas                    Section 3.  [Page 7]

INTERNET-DRAFT            Expires: January 2002                July 2001


hop towards the RP for the group, and in each router it passes through,
multicast tree state for group G is instantiated.  Eventually the (*,G)
Join either reaches the RP, or reaches a router that already has (*,G)
Join state for that group.  When many receivers join the group, their
Join messages converge on the RP, and form a distribution tree for group
G that is rooted at the RP.  This is known as the RP Tree (RPT), and is
also known as the shared tree because it is shared by all sources
sending to that group.  Join messages are resent periodically so long as
the receiver remains in the group.  When all receivers on a leaf-network
leave the group, the DR will send a PIM (*,G) Prune message towards the
RP for that multicast group. However if the prune message is not sent
for any reason, the state will eventually time out.

A multicast data sender just starts sending data destined for a
multicast group.  The sender's local router (DR) takes those data
packets, unicast-encapsulates them, and sends them directly to the RP.
The RP receives these encapsulated data packets, decapsulates them, and
forwards them onto the shared tree.  The packets then follow the (*,G)
multicast tree state in the routers on the RP Tree, being replicated
wherever the RP Tree branches, and eventually reaching all the receivers
for that multicast group.  The process of encapsulating data packets to
the RP is called registering, and the encapsulation packets are known as
PIM Register packets.

At the end of phase one, multicast traffic is flowing encapsulated to
the RP, and then natively over the RP tree to the multicast receivers.


Phase Two: Register Stop

Register-encapsulation of data packets is inefficient for two reasons:

o Encapsulation and decapsulation may be relatively expensive operations
  for a router to perform, depending on whether or not the router has
  appropriate hardware for these tasks.

o Traveling all the way to the RP, and then back down the shared tree
  may entail the packets traveling a relatively long distance to reach
  receivers that are close to the sender.  For some applications, this
  increased latency is undesirable.

Although Register-encapsulation may continue indefinitely, for these
reasons, the RP will normally choose to switch to native forwarding.  To
do this, when the RP receives a register-encapsulated data packet from
source S on group G, it will normally initiate an (S,G) source-specific
Join towards S.  This join message travels hop-by-hop towards S,
instantiating (S,G) multicast tree state in the routers along the path.
(S,G) multicast tree state is used only to forward packets for group G



Fenner/Handley/Holbrook/Kouvelas                    Section 3.  [Page 8]

INTERNET-DRAFT            Expires: January 2002                July 2001


if those packets come from source S.  Eventually the Join message
reaches S's subnet or a router that already has (S,G) multicast tree
state, and then packets from S start to flow following the (S,G) tree
state towards the RP.  These data packets may also reach routers with
(*,G) state along the path towards the RP - if so, they can short-cut
onto the RP tree at this point.

While the RP is in the process of joining the source-specific tree for
S, the data packets will continue being encapsulated to the RP.  When
packets from S also start to arrive natively at the the RP, the RP will
be receiving two copies of each of these packets.  At this point, the RP
starts to discard the encapsulated copy of these packets, and it sends a
Register-Stop message back to S's DR to prevent the DR unnecessarily
encapsulating the packets.

At the end of phase 2, traffic will be flowing natively from S along a
source-specific tree to the RP, and from there along the shared tree to
the receivers.  Where the two trees intersect, traffic may transfer from
the source-specific tree to the RP tree, and so avoid taking a long
detour via the RP.

It should be noted that a sender may start sending before or after a
receiver joins the group, and thus phase two may happen before the
shared tree to the receiver is built.


Phase 3: Shortest-Path Tree

Although having the RP join back towards the source removes the
encapsulation overhead, it does not completely optimize the forwarding
paths.  For many receivers the route via the RP may involve a
significant detour when compared with the shortest path from the source
to the receiver.

To obtain lower latencies, a router on the sender's LAN, typically the   |
DR, may optionally initiate a transfer from the shared tree to a source- |
specific shortest-path tree (SPT).  To do this, it issues an (S,G) Join
towards S.  This instantiates state in the routers along the path to S.
Eventually this join either reaches S's subnet, or reaches a router that
already has (S,G) state.  When this happens, data packets from S start
to flow following the (S,G) state until they reach the receiver.

At this point the receiver (or a router upstream of the receiver) will
be receiving two copies of the data - one from the SPT and one from the
RPT.  When the first traffic starts to arrive from the SPT, the DR or
upstream router starts to drop the packets for G from S that arrive via
the RP tree.  In addition, it sends an (S,G) prune message towards the
RP.  This is known as an (S,G,rpt) Prune.  The prune message travels



Fenner/Handley/Holbrook/Kouvelas                    Section 3.  [Page 9]

INTERNET-DRAFT            Expires: January 2002                July 2001


hop-by-hop, instantiating state along the path towards the RP indicating
that traffic from S for G should NOT be forwarded in this direction.
The prune is propagated until it reaches the RP or a router that still
needs the traffic from S for other receivers.

By now, the receiver will be receiving traffic from S along the
shortest-path tree between the receiver and S.  In addition, the RP is
receiving the traffic from S, but this traffic is no longer reaching the
receiver along the RP tree.  As far as the receiver is concerned, this
is the final distribution tree.


Source-specific Joins

IGMPv3 permits a receiver to join a group and specify that it only wants
to receive traffic for a group if that traffic comes from a particular
source.  If a receiver does this, and no other receiver on the LAN
requires all the traffic for the group, then the DR may omit performing
a (*,G) join to set up the shared tree, and instead issue a source-
specific (S,G) join only.

The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is
currently set aside for source-specific multicast in IPv4.  For groups
in this range, receivers should only issue source-specific IGMPv3 joins.
If a PIM router receives a non-source-specific join for a group in this
range, it should ignore it, as described in Section 4.8.

Source-specific Prunes

IGMPv3 also permits a receiver to join a group and specify that it only
wants to receive traffic for a group if that traffic does not come from
a specific source or sources.  In this case, the DR will perform a (*,G)
join as normal, but may combine this with an (S,G,rpt) prune for each of
the sources the receiver does not wish to receive.


Multi-access Transit LANs

The overview so far has concerned itself with point-to-point links.
However, using multi-access LANs such as Ethernet for transit is not
uncommon.  This can cause complications for three reasons:

o Two or more routers on the LAN may issue (*,G) Joins to different
  upstream routers on the LAN because they have inconsistent MRIB
  entries regarding how to reach the RP.  Both paths on the RP tree will
  be set up, causing two copies of all the shared tree traffic to appear
  on the LAN.




Fenner/Handley/Holbrook/Kouvelas                   Section 3.  [Page 10]

INTERNET-DRAFT            Expires: January 2002                July 2001


o Two or more routers on the LAN may issue (S,G) Joins to different
  upstream routers on the LAN because they have inconsistent MRIB
  entries regarding how to reach source S.  Both paths on the source-
  specific tree will be set up, causing two copies of all the traffic
  from S to appear on the LAN.

o A router on the LAN may issue a (*,G) Join to one upstream router on
  the LAN, and another router on the LAN may issue an (S,G) Join to a
  different upstream router on the same LAN.  Traffic from S may reach
  the LAN over both the RPT and the SPT.  If the receiver behind the
  downstream (*,G) router doesn't issue an (S,G,rpt) prune, then this
  condition would persist.

All of these problems are caused by there being more than one upstream
router with join state for the group or source-group pair.  PIM does not
prevent such duplicate joins from occurring - instead when duplicate
data packets appear on the LAN from different routers, these routers
notice this, and then elect a single forwarder.  This election is
performed using PIM Assert messages, which resolve the problem in favor
of the upstream router which has (S,G) state, or if neither or both
router has (S,G) state, then in favor of the router with the best metric
to the RP for RP trees, or the best metric to the source to source-
specific trees.

These Assert messages are also received by the downstream routers on the
LAN, and these cause subsequent join messages to be sent to the upstream
router that won the Assert.

RP Discovery

PIM-SM routers need to know the address of the RP for each group for
which they have (*,G) state.  This address is obtained either through a
bootstrap mechanism or through static configuration.

One dynamic way to do this is to use the Bootstrap Router (BSR)
mechanism [4]. One router in each PIM domain is elected the Bootstrap
Router through a simple election process.  All the routers in the domain
that are configured to be candidates to be RPs periodically unicast
their candidacy to the BSR.  From the candidates, the BSR picks an RP-
set, and periodically announces this set in a bootstrap message.
Bootstrap messages are flooded hop-by-hop throughout the domain until
all routers in the domain know the RP-Set.

To map a group to an RP, a router hashes the group address into the RP-
set using an order-preserving hash function (one that minimizes changes
if the RP set changes).  The resulting RP is the one that it uses as the
RP for that group.




Fenner/Handley/Holbrook/Kouvelas                   Section 3.  [Page 11]

INTERNET-DRAFT            Expires: January 2002                July 2001


4.  Protocol Specification

The specification of PIM-SM is broken into several parts:

o Section 4.1 details the protocol state stored.

o Section 4.2 specifies the data packet forwarding rules.

o Section 4.3 specifies the PIM Register generation and processing
  rules.

o Section 4.4 specifies the PIM Join/Prune generation and processing
  rules.

o Section 4.5 specifies the PIM Assert generation and processing rules.

o Designated Router (DR) election is specified in Section 4.6.

o Section 4.7 specifies the RP discovery mechanisms.

o The subset of PIM required to support Source-Specific Multicast, PIM-
  SSM, is described in Section 4.8.

o PIM packet formats are specified in Section 4.9.

o A summary of PIM-SM timers and their default values is given in
  Section 4.10.

4.1.  PIM Protocol State

This section specifies all the protocol state that a PIM implementation
should maintain in order to function correctly.  We term this state the
Tree Information Base or TIB, as it holds the state of all the multicast
distribution trees at this router.  In this specification we define PIM
mechanisms in terms of the TIB.  However, only a very simple
implementation would actually implement packet forwarding operations in
terms of this state.  Most implementations will use this state to build
a multicast forwarding table, which would then be updated when the
relevant state in the TIB changes.

Although we specify precisely the state to be kept, this does not mean
that an implementation of PIM-SM needs to hold the state in this form.
This is actually an abstract state definition, which is needed in order
to specify the router's behavior.  A PIM-SM implementation is free to
hold whatever internal state it requires, and will still be conformant
with this specification so long as it results in the same externally
visible protocol behavior as an abstract router that holds the following
state.



Fenner/Handley/Holbrook/Kouvelas                 Section 4.1.  [Page 12]