Download MOSPF and PIM (only PIM/DM) - comp

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Database model wikipedia , lookup

Transcript
Group Communications:
MOSPF and PIM
Dr. Rocky K. C. Chang
19 March, 2002
1
Multicast extension to OSPF (MOSPF)
• MOSPF adds a new group-membership LSA (link
state advertisement) to support IP multicast.
• Given that each MOSPF router has learnt where the
members are, it can make forwarding decision based
on both the source and destination addresses.
– For example, host 2 sends a multicast packet to group B.
RT3 will send a copy to N3 but not to RT6.
• Upon receiving a multicast packet, each MOSPF
router could compute a pruned “shortest-path”
spanning tree rooted at the source network.
– After the computation, the router may or may not be on the
tree.
– For example, host 2 sends a multicast packet to group A. 2
+
| 3+---+
+--+ +--+
N12
N14
N1|--|RT1|\1 |Mb| |H4|
\ N13 /
_| +---+ \ +--+ /+--+
8\ |8/8
| +
\ _|__/
\|/
+--+
+--+
/
\
1+---+8
8+---+6
|Mb|
|Mb|
* N3 *---|RT4|------|RT5|--------+
+--+ /+--+
\____/
+---+
+---+
|
+
/
|
|7
|
| 3+---+ /
|
|
|
N2|--|RT2|/1
|1
|6
|
__| +---+
+---+8
6+---+
|
| +
|RT3|--------------|RT6|
|
+--+
+--+
+---+
+--+
+---+
|
|Ma|
|H3|_
|2
_|H2|
Ia|7
|
+--+
+--+ \
|
/ +--+
|
|
+---------+
|
|
N4
|
|
|
|
|
|
N11
|
|
+---------+
|
|
|
\
|
|
N12
|3
+--+
|
|6 2/
+---+
|Ma|
|
+---+/
|RT9|
+--+
|
|RT7|---N15
+---+
|
+---+ 9
|1
+
|
|1
_|__
|
Ib|5
__|_
+--+
/
\
1+----+2
| 3+----+1
/
\--|Ma|
* N9 *------|RT11|----|---|RT10|---* N6 * +--+
\____/
+----+
|
+----+
\____/
|
|
|
|1
+
|1
+--+
10+----+
N8
+---+
|H1|-----|RT12|
|RT8|
+--+SLIP +----+
+---+ +--+
|2
|4 _|H5|
|
| / +--+
+---------+
+--------+
N10
N7
3
Shortest-path tree rooted at RT3
o RT3 (N4, origin)
/ \
1/
\8
/
\
N3 (Mb) o
o RT6
/
\
0/
\7
/
\
RT2 (Ma,Mb) o
o RT10
/ \
3/
\1
/
\
N8 o
o N6 (Ma)
/
0/
/
RT11 o
/
1/
/
N9 o
/
0/
/
RT9 (Ma) o
4
Router support for intra-area multicasting
• Each MOSPF router is required to keep a local group
database and a forwarding cache.
• A local group database which keep tracks of group
membership on its directly attached networks (through
IGMP). For example,
•
•
•
•
•
Router
RT1
RT2
RT3
RT4
Local Group Database
[Group B, N1]
[Group A, N2], [Group B, N2]
[Group B, N3]
None
– In this example, RT3 is a designated router for N3,
responsible for advertising the multicast membership for
this network.
5
Forwarding cache
• A forwarding cache (only for routers on the multicast
tree).
• For each (source network, destination group, type-ofservice), the router maintains a list of outgoing
interfaces and the number of hops to the destinations.
• Example: source network = N4 and destination =
group A.
•
•
•
•
•
•
•
Router
Upstream Node
RT10
RT11
RT3
RT6
RT2
RT6
N8
N4
RT3
N3
Downstream interface
(interface: hops)
(N6:1) (N8:2)
(N9:1)
(N3:1) (RT6:3)
(RT10:2)
6
(N2:1)
Forwarding cache
• The forwarding cache is computed based on the
source network address, the network topology, and the
group membership information.
– Find the upstream node, and
– the downstream nodes and number of hops.
• The forwarding cache will change when
– the topology of the OSPF network changes, or
– there is a change in the group-membership LSAs.
7
Computing shortest-path trees
• A MOSPF will compute the shortest-path tree for (s,
G) upon receiving the first packet, i.e., data driven.
• Based on a link state database, every MOSPF router
can independently compute shortest-path trees for any
(s, G).
– Need a modified shortest-path algorithm for the
computation?
– The shortest path is truly computed from the source to the
networks with membership.
– Contrary to DVMRP and PIM-DM, MOSPF is not based on
RPF.
8
Joining a multicast group
• When a first member joins a group on a network by
sending an IGMP report message,
– A designated router updates its local group database.
– It then floods a group-membership LSA about this new
membership throughout the area.
– Every MOSPF router, upon receiving this message, updates
its local database.
– An MOSPF router that is on the tree will eventually modify
its forwarding entry to include this new network.
– For example, each of the routers R1, R2, and R3 will
originate a group membership LSA for group B.
9
Leaving a multicast group
• When the last member leaves a group on a network,
– A designated router ages out the corresponding entry in its
local group database.
– It then floods a group-membership LSA throughout the area
to delete this network from the group.
– Every MOSPF router, upon receiving this message, updates
its local database.
– An MOSPF router that is on the tree will modify its
forwarding entry to exclude this new network.
10
Comparison with DVMRP
• Unlike DVMRP and PIM-DM, the first packet from a
(s, G) is not flooded to the entire network.
– In other words, MOSPF uses an explicit join (through the
group-membership LSAs).
– But, all MOSPF routers in an area do need to store all the
group-membership LSAs, whether or not any source is even
sending to this group.
• Like DVMRP and PIM-DM, the creation of the
forwarding table is “driven” by the first packet sent to
the group.
11
Protocol Independent Multicast (PIM)-DM
• PIM is independent of particular unicast routing
protocols.
– It is based on the unicast routing tables, independent of how
those tables are computed.
• PIM-DM also implements RPM, with a few important
differences as compared with DVMRP:
– PIM-DM is not hard-wired into a specific type of topology
discovery protocol, such as RIP.
– The trade-off is that more overhead may be incurred,
because broadcast-and-prune occurs on some links that
could be avoided if topology information is available.
– PIM routers send periodic Hello message out of each
interface and keep track of neighbors based on received
12
Hello messages.
Leaf network detection
• The definition of leaf networks in PIM-DM is
different from that used in DVMRP:
– A network on a router interface is deemed a leaf if there are
no other PIM neighbors on that network (do not receive
Hello messages).
– When there are two routers on a network, and each of them
does not use the other as the next-hop router towards as
source:
• In DVMRP, that network is a leaf to both routers.
• In PIM-DM, that network is not a leaf to both routers.
13
Multicasting on multi-access LAN
• If a router receives a multicast datagram on an
outgoing interface to a multi-access LAN, the
packet must be a duplicate.
• To elect a single forwarder for the LAN, the router
sends out an Assert message addressed to all-PIMrouters group.
– The message contains a metric or a set of metrics with
preferences describing the path from the router to the
source.
– Those routers that have lost the election prune their
interfaces.
– The router that have won the election and there are
members on the LAN, it sends an assert with its own metric
on the LAN so that all other routers know the winner. 14
Pruning of branches
• When a prune message is sent onto an upstream LAN,
it is a data-link multicast addressed to all-PIM-routers
group.
– The router to process the prune will be indicated by
inclusion of its address in the message.
• After receiving the message, the expected router
schedules to delete the interface from the set of
outgoing interfaces by activating a timer.
• Before the timer expiration, if other routers on the
LAN sends a PIM-Join message addressed to all-PIMrouters group,
– the expected router will cancel the scheduled delete request
(prune-override). Otherwise, the interface will be pruned.15
Pruning of branches
• Similar to IGMP, each router that needs to send PIMJoin messages will start a random join message delay
timer.
– A router will cancel its timer if it hears a PIM-Join message.
• PIM messages required for dense mode:
–
–
–
–
–
Hello
Join/Prune (only Prune is used)
Assert
Graft (used only in PIM-DM)
Graft-Ack (used only in PIM-DM)
16
Protocol Independent Multicast (PIM)-SM
• PIM-SM distributes multicast packets through a
shared tree, which is rooted at a pre-determined router
called Rendezvous Point (RP).
– Another well-known multicast routing protocol based on
shared tree is Core Based Tree (CBT).
• PIM-SM is designed for a sparsely distributed group
membership.
• PIM-SM allows also members to receive a source’s
packet from a source-specific tree.
– The shared tree is required to prune away those sources.
• PIM-SM uses soft-state refreshment mechanisms to
achieve reliability.
17
Local hosts joining a group
• When receiving a first IGMP report message for a
group G, the Designated Router (DR) creates a
wildcard multicast route entry (*, G).
– The DR looks up the associated RP for G (through bootstrap
messages).
– The RP’s address is included in periodic upstream
Join/Prune messages.
– The outgoing interface is set to the one receiving the IGMP
report messages.
– The incoming interface is set to the one used to send unicast
packets to the RP.
18
Establishing the RP-rooted shared tree
• Triggered by the (*, G) state, the DR creates a
Join/Prune message with the RP address in its join list.
– The wildcard bit (WC-bit) is set to 1, indicating that the
downstream receivers are expecting to receive packets from
all sources via the shared tree.
– The RP-tree bit (RPT-bit) is set to 1, indicating that this join
is being sent up the shared, RP-tree.
• Each upstream router creates or updates its multicast
route entry for (*,G) when it receives a Join/Prune
with the RPT-bit and WC-bit set.
– The interface on which the Join/Prune message arrived is
added to the list of outgoing interfaces (oifs) for (*,G).
19
Establishing the RP-rooted shared tree
20
Hosts sending to a group
• The sender's DR initially encapsulates each data
packet in a Register message and unicasts it to the RP
for that group.
– The RP decapsulates each Register message and forwards
the enclosed data packet natively to downstream members
on the shared RP-tree.
• If the data rate of the source warrants the use of a
source-specific shortest path tree (SPT),
– the RP may construct a new multicast route entry (S,G), and
send periodic Join/Prune messages toward the source.
• The source's DR must stop encapsulating data packets
in Registers when (and so long as) it receives
Register-Stop messages from the RP.
21
Hosts sending to a group
– The RP triggers Register-Stop messages in response to
Registers, if
• the RP has no downstream receivers for the group (or for that
particular source), or
• if the RP has already joined the (S,G) tree and is receiving the data
packets natively.
– Each source's DR maintains, per (S,G), a RegisterSuppression-timer.
• The Register-Suppression-timer is started by the Register-Stop
message;
• upon expiration, the source's DR resumes sending data packets to
the RP, encapsulated in Register messages.
22
Hosts sending to a group
23
Switching from RP-tree to SP-tree
• A router with directly-connected members first joins
the shared RP-tree.
– The router can switch to a source's shortest path tree (SPtree) after receiving packets from that source over the
shared RP-tree.
– Only the RP and routers with local members can initiate
switching to the SP-tree; intermediate routers cannot.
• When a (S,G) entry is activated (and periodically so
long as the state exists), a Join/Prune message is sent
upstream towards the source, S, with S in the join list.
– The outgoing interface list for (S, G) is copied from (*,G).
24
Switching from RP-tree to SP-tree
• Note that (S,G) state must be maintained in each lasthop router that is responsible for initiating and
maintaining an SP-tree.
– (S,G) state is kept alive by data packets arriving from that
source.
– A timer, Entry-timer, is set for the (S,G) entry.
– This timer is restarted whenever data packets for (S,G) are
forwarded out at least one oif, or Registers are sent.
– When the Entry-timer expires, the state is deleted.
25
Switching from RP-tree to SP-tree
• The (S,G) entry is initialized with the SPT-bit cleared,
indicating
– that the shortest path tree branch from S has not yet been
setup completely, and
– the router can still accept packets from S that arrive on the
(*,G) entry's indicated incoming interface (iif).
• When a router with a (S,G) entry and a cleared SPTbit starts to receive packets from the new source S on
the iif for the (S,G) entry, and that iif differs from the
(*,G) entry's iif (a forked path),
– the router sets the SPT-bit, and sends a Join/Prune message
towards the RP, indicating that the router no longer wants to
receive packets from S via the shared RP-tree.
26
Switching from RP-tree to SP-tree
– The Join/Prune message sent towards the RP includes S in
the prune list, with the RPT-bit set indicating that S's
packets must not be forwarded down this branch of the
shared tree.
• If the router receiving the Join/Prune message has
(S,G) state, it deletes the arriving interface from the
(S,G) oif list.
• If the router has only (*,G) state, it creates an entry
with the RPT-bit flag set to 1 ((S,G)RPT-bit entry).
27
Switching from RP-tree to SP-tree
28
Maintenance of distribution tree
• In the steady state, each router sends periodic
Join/Prune messages for each active PIM route entry.
– The Join/Prune messages are sent to the neighbor indicated
in the corresponding entry.
– These messages are sent periodically to capture state,
topology, and membership changes.
• A Join/Prune message is also sent on an eventtriggered basis each time a new route entry is
established for some new source.
• Join/Prune messages do not elicit any form of explicit
acknowledgment; routers recover from lost packets
using the periodic refresh mechanism.
29
Multicast data packet processing
• A router first performs a longest match on the source
and group address in the data packet.
– A (S,G) entry is matched first if one exists; a (*,G) entry is
matched otherwise.
– If neither matches, drop the packet (we do not consider the
(*, *, RP) entry match).
• If a state is matched, the router compares the interface
from which the packet is received and the incoming
interface in the route entry.
– If not matched, drop the packet.
– Otherwise, the packet is forwarded to the set of outgoing
interfaces.
30
Multicast data packet processing
• Some special actions are needed to deliver packets
continuously while switching from the shared to
shortest-path tree. When a (S,G) entry is matched,
incoming packets are forwarded as follows:
– If the SPT-bit is set, then:
• if the incoming interface is the same as a matching (S,G) iif, the
packet is forwarded to the oif-list of (S,G).
• if the incoming interface is different than a matching (S,G) iif , the
packet is discarded.
– If the SPT-bit is cleared, then:
• if the incoming interface is the same as a matching (S,G) iif, the
packet is forwarded to the oif-list of (S,G). In addition, the SPT bit
is set for that entry if the incoming interface differs from the
incoming interface of the (*,G).
31
Multicast data packet processing
• if the incoming interface is different than a matching (S,G) iif, the
incoming interface is tested against a matching (*,G) entry. If the iif
is the same as one of those, the packet is forwarded to the oif-list of
the matching entry.
• Otherwise the iif does not match any entry for G and the packet is
discarded.
• Data packets never trigger prunes. However, data
packets may trigger actions that in turn trigger prunes.
– For example, when router B in figure 3 decides to switch to
SP-tree at step 3, it creates a (S,G) entry with SPT-bit set to
0.
– When data packets from S arrive at interface 2 of B, B sets
the SPT-bit to 1 since the iif for (*,G) is different than that
for (S,G).
32
– This triggers the sending of prunes towards the RP.
Multicast data packet processing
• Operation over multi-access networks and the pruning
method are the same as the PIM-DM.
33
Acknowledgements
• The notes are based on
– J. Moy, “Multicast Extensions to OSPF,” RFC 1584, March
1994.
– S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy,
D. Meyer, L. Wei, “Protocol Independent Multicast Version
2 Dense Mode Specification,” Internet Draft draft-ietf-pimv2-dm-03.txt, June 1999.
– D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei,
“Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification,” RFC 2362, June 1998.
34