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

xorp源码hg

      router that a Join message for that group would be directed to, in
      the absence of modifying Assert state.

TIB   Tree Information Base.  This is the collection of state at a PIM
      router that has been created by receiving PIM Join/Prune messages,
      PIM Assert messages, and IGMP or MLD information from local hosts.
      It essentially stores the state of all multicast distribution
      trees at that router.

MFIB  Multicast Forwarding Information Base.  The TIB holds all the
      state that is necessary to forward multicast packets at a router.
      However, although this specification defines forwarding in terms
      of the TIB, to actually forward packets using the TIB is very
      inefficient.  Instead a real router implementation will normally
      build an efficient MFIB from the TIB state to perform forwarding.
      How this is done is implementation-specific, and is not discussed
      in this document.

Upstream
      Towards the root of the tree.  The root of tree may either be the
      source or the RP depending on the context.

Downstream
      Away from the root of the tree.

2.2.  Pseudocode Notation

We use set notation in several places in this specification.

A (+) B
    is the union of two sets A and B.

A (-) B
    is the elements of set A that are not in set B.



Fenner/Handley/Holbrook/Kouvelas                  Section 2.2.  [Page 7]

INTERNET-DRAFT             Expires: April 2005              October 2004


NULL
    is the empty set or list.

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 [9]. Regardless
of how it is created, the primary role of the MRIB in the PIM protocol
is to provide the next hop router along a multicast-capable path to each
destination subnet.  The MRIB is used to determine the next hop neighbor
to which any PIM Join/Prune message is sent.  Data flows along the
reverse path of the Join messages.  Thus, in contrast to the unicast RIB
which specifies the next hop that a data packet would take to get to
some subnet, the MRIB gives reverse-path information, and indicates the
path that a multicast data packet would take from its origin 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 [1] or MLD [3], but other mechanisms might also serve this purpose.
One of the receiver's local routers is elected as the Designated Router



Fenner/Handley/Holbrook/Kouvelas                    Section 3.  [Page 8]

INTERNET-DRAFT             Expires: April 2005              October 2004


(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-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 or bandwidth consumption 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



Fenner/Handley/Holbrook/Kouvelas                    Section 3.  [Page 9]

INTERNET-DRAFT             Expires: April 2005              October 2004


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
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 or more efficient bandwidth utilization, a     |
router on the receiver'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.





Fenner/Handley/Holbrook/Kouvelas                   Section 3.  [Page 10]

INTERNET-DRAFT             Expires: April 2005              October 2004


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
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 transit
links.  However, using multi-access LANs such as Ethernet for transit is
not uncommon.  This can cause complications for three reasons:




Fenner/Handley/Holbrook/Kouvelas                   Section 3.  [Page 11]

INTERNET-DRAFT             Expires: April 2005              October 2004


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.

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
automatically (e.g., embedded-RP), through a bootstrap mechanism or
through static configuration.

One dynamic way to do this is to use the Bootstrap Router (BSR)
mechanism [11]. 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



Fenner/Handley/Holbrook/Kouvelas                   Section 3.  [Page 12]

INTERNET-DRAFT             Expires: April 2005              October 2004


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.

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 Designated Router (DR) election and the rules
  for sending and processing Hello messages.

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

o Section 4.5 specifies the PIM Join/Prune generation and processing