Protocol Design Concept: Soft State vs. Hard State

1
Protocol Design Concept Soft State vs. Hard State

• Soft State
• A state is refreshed periodically, and if it is
  not refreshed it times out and is removed.
• Example
• in PIM-SM a state is created by the receipt of a
  Join message.
• A Join message is not acknowledged, but is sent
  periodically (every minute approx.)

2

• A router maintains an entry timer for every state
  created.
• When a router receives a Join it restarts (or
  refreshes) that timer.
• When a router does not receive a Join for approx.
  3 x Join refresh period (approx 3 min.s) it times
  out the timer and the entry is removed.

3
Hard state

• A state in a router is created once, and it
  remains until another message is sent to remove
  it.
• Usually uses an acknowledged message,
• Simple example
• DVMRP uses a graft message to create a state.

4

• The graft message is acknowledged.
• When a router receives a graft, it creates the
  state, and the state remains until a prune is
  sent to remove the forwarding state in that
  router.

5
Advantages and disadvantages

• For soft state
• Since, in general, it is not acknowledged, it may
  lead to 'join latency'.
• For example, if a receiver joins the group and
  the join is lost, it has to wait until the next
  refresh period to send another join.

6

• In hard state
• Since, in general, it is acknowledged, it incurs
  less join latency (since the ack timer is
  probably 3 seconds while the refresh timer is
  approx 1 min.).
• The main advantage for soft state (vs. hard
  state) is its robustness to failures.

7

• Crash scenarios
• If A sends a graft message, it gets acknowledged,
  and B creates state
• A crashes and loses state
• State will remain permanently in B
• Packets will keep on getting to A unless/until a
  prune is sent

8

• If router B crashes and comes back up again,
  there is no way to recreate the state in B
  (because A already got ack for its graft).
• So DVMRP uses periodic broadcast to take care of
  this situation.
• In PIM-SM, the soft state (periodic refresh)
  mechanisms take care of the above crash scenarios.

9
Receivers Joining the Shared Tree
3. Create (,G) entry Multicast
addressG RP-addressC,WC1,RP1 outgoing
interface list1 incoming interface2
D
7. Create (,G) entry Multicast
addressG RP-addressC,WC1,RP1 outgoing
interface list1 incoming interfaceNull
2. IGMP Host- Membership Report for G
4. Send Join/Prune message to B Multicast
addressG JoinC,WC,RP PruneNull
Host
2
1
2
1
3
1
Receiver
...
A
B
C
LAN
PIM DR/IGMP Querier for LAN
Rendezvous Point (RP) for group G
1. IGMP Host- Membership Query
6. Send Join/Prune message to C Multicast
addressG JoinC,WC,RP PruneNull
5. Create (,G) entry Multicast
addressG RP-addressC,WC1,RP1 outgoing
interface list1 incoming interface3
10
Host Sending to the Group
1. Data packets for G
Host
2. Create (S,G) entry incoming interface1
DR for LAN(B)
1
A
Receiver
LAN(B)
1
2
D
Host
3. Encapsulate Data packets in Register messages
and unicast to RP(C)
Source
2
12. When receiver Register-Stop stop
encapsulating packets
4. Initiate (S,G) packet counter
5. If (,G) state exists then decapsulate
Registers and forward packets to oiflist (,G)
10. Update (S,G) entry add 2 to
outgoing interface list
Rendezvous Point (RP for group G
2
1
1
C
X
2
9. Send Join/Prune message to D Multicast
addressG JoinS,PruneNull
6. If Register data rate gt Threshold then create
(S,G) entry outgoing listoiflist
(,G)-2 incoming interface2 RP0,SPT0
7. Send Join/Prune message to X Multicast
addressG JoinS, PruneNull
8. Create (S,G) entry outgoing list1 incoming
interface2
11. When receive (S,G) native packets set SPT bit
for (S,G) entry, trigger Register-Stop message
to D
11
Switching to the Shortest Path Tree
1. Receive Ss packets on shared RP tree Initiate
packet count If data rate gt Threshold
then Create (S,G) entry outgoing interface
list1 incoming interface2 RP0,WC0,SPT0
5. Add interface 2 to the outgoing interface list
of (S,G) entry
First Hop Router for S
4. Send Join/Prune message to D Multicast
addressG JoinS PruneNull
D
Host
1
2
Source (S)
2. Send Join/Prune message to B Multicast
addressG JoinS PruneNull
7. Create (S,G) entry oif listoif(,G)-1 RP-bi
t1
Host
2
2
1
2
1
3
1
Receiver
A
B
C
LAN
PIM DR/IGMP Querier for LAN
Rendezvous Point (RP) for group G
6. After receiving packets from D Set (S,G)s
SPT-bit1 and, send Join/Prune message to
C Multicast addressG JoinNull PruneS,RP-bit
3. Create (S,G) entry outgoing interface
list1 incoming interface2 RP0,WC0,SPT0
12
The RP Bootstrap Problem

• Which router to use as RP for a group?
• A set of well-connected routers are configured as
  Candidate-RPs for group(s) per domain
• A manageable number of RPs is chosen
• RPs advertise candidacy for group-prefix (not per
  group), for scalability
• Periodic advertisement of candidacy to capture
  dynamics and unreachability
• Who maintains/updates/distributes this info?

13
RP Bootstrap Design Rationale

• Host model
• hosts need only logical multicast group address
  to send or receive
• RP address is network (not logical) address
• Routers should map group address to RP address
  and adapt to unreachability/change of RP

14
RP Bootstrap Design Rationale

• No on-demand retrieval of RP info to avoid
  start-up phase
• cant join or send until DR gets RP address
• bursty source problem
• packets are lost until DR identifies active RP
• global distribution of explicit group to RP
  mapping and reachability not scalable
• Use a-priori status distribution
• like unicast routing, periodic liveness tracking
• distribute RP-list throughout the domain

15
Choosing RPs The Bootstrap Mechanism

• PIMv2 has a Bootstrap router election procedure
• The Bootstrap router receives Candidate-RP
  messages from potential RPs
• Bootstrap router sends Bootstrap messages which
  contain a list of reachable Candidate-RPs
• All PIM routers receive these Bootstrap messages
• DRs obtain group-to-RP mapping (when hosts join
  or send to the group) through a hash algorithm

16
RP Bootstrap Mechanism

• RP location need not be optimized, but consistent
  RP mapping and adaptation to failures is
  criticial
• all routers (within PIM domain) must associate a
  single active RP with a multicast group
• Routers use algorithmic mapping of Group
  address to RP from manageably-small set of RPs
  known throughout domain

17
RP Booststrap Mechanism

• Each candidate RP indicates liveness to the
  Bootstrap Router in the PIM domain
• Bootstrap Router distributes set of reachable
  candidate RPs to all PIM routers in domain.
• Each PIM router uses the same hash function and
  set of RPs to map a particular multicast group
  address to that groups RP.

18
Dynamic Bootstrap Router Election

• Simple bridge-like spanning-tree election
  algorithm
• A set of well-connected routers are configured as
  Candidate Bootstrap Routers (C-BSRs) per domain
• C-BSRs originate PIM hop-by-hop Bootstrap
  messages with IP address and preference value.
• Bootstrap messages are exchanged by all PIM
  routers within domain (flooded with RPF check)
• Most preferred (or highest numbered) reachable
  C-BSR is elected

19
Routers use hash function to mapGroup address to
RP

• Hash function
• input group address G and address of each
  candidate RP in RP set (with optional Mask)
• output Value computed per candidate RP in RP set
• RP with highest value is the RP for G
• Desirable characteristics
• minimize remapping when RP reachability changes
  remap only those that lost RP
• load spreading of groups across RPs

20
Adaptation to RP Unreachability

• When Candidate RP fails/unreachable
• Bootstrap Router times it out
• Bootstrap message distributed with updated RP set
• Routers hash affected groups to different RP

21
References

• RFC 2362/2117
• http//catarina.usc.edu/pim

22
Multicast and the Internet

• Initially there was the MBONE
• Short-term inter-domain solution based on PIM-SM,
  MBGP and MSDP
• Longer-term architecture BGMP

23
The Internet's Multicast Backbone (MBONE)

• The MBONE is an interconnect of subnets and
  routers that support IP-multicast.
• The goal of the MBONE was
• initially to construct an IP multicast test-bed
• as it became popular gradual deployment of
  multicast applications without waiting for the
  ubiquitous Internet multicast deployment

24

• The MBONE is rapidly growing
• 40 subnets in 4 countries in 92
• gt 2800 subnets in over 25 countries in April 96
• The MBONE is a virtual network layered on top of
  a subset of the Internet.
• It is composed of islands of multicast-capable
  routers connected to other islands by virtual
  point-to-point links called tunnels.

25
Tunneling

• Tunnels allow multicast traffic to pass through
  the non-multicast-capable parts of the Internet.
• Multicast packets are encapsulated as IP-in-IP,
  so they look like normal unicast packets to
  intermediate routers.
• Encapsulation is added on entry to a tunnel and
  stripped off on exit from a tunnel.

26
Multicast islands connected through tunnels
27

• The MBONE and the Internet have different
  topologies, so
• multicast routers execute a separate routing
  protocol to forward multicast packets.
• Much of the MBONE routers run DVMRP
• Portions of the MBONE run
• MOSPF
• Protocol-Independent Multicast (PIM)

28
(No Transcript)
29
MBONE Limitations

• Mbone currently using DVMRP, which was never
  intended for, and is ill-suited to, this task
• known problems of DV with large networks
• broadcast prune approach undesirable for
  interdomain routing, S. Deering.
• Suggested solution
• Use sparse-mode concepts
• Use 2-level hierarchy (as in unicast)

30
Recent Deployment

• Use PIM-SM as intra-domain multicast routing
  protocol
• Use MBGP (Multicast BGP) to distribute
  inter-domain multicast routes
• Use MSDP (Multicast Source Discovery Protocol)
  between RPs in different domains

31
MBGP

• BGP (RFC 1771) used for unicast routing to
• aggregate and abstract routes for scalability
• provide inter-domain routing policies
• BGP4 (RFC 2283) can carry multicast routes
• multicast routers need only know
• - internal topology and - paths to reach other
  domains
• provides topology info for multicast routes that
  may be different than unicast routes

32
Problem Connecting PIM-SM domains
Sources register with RP in their domain and
receivers join towards the RP in their domain
S
R
RPB
RPA
Domain A (PIM-SM)
Domain B (PIM-SM)
No way for receiver in domain B to know
about sources in domain A and vice versa
33
MSDP

• To tie PIM-SM trees in different domains
• every RP has MSDP peers (RPs in other domains)
• when a source registers to the RP it conveys this
  info to its MSDP peers through TCP and SA
  messages
• this info is RPF-flooded to other domains
• an RP with members in its domain joins towards
  src

34
Normal SM
35
Peering
MSDP Peering
MSDP Peering o Between RPs o Over TCP
36
Sending SA Msgs
RP1 Sends (S,G) SA message
RP1 Creates State
(S,G) Joins towards RP2
MSDP Peering
Last hop router sends (S,G) Register to RP1
37
Joining the Source Tree
38
Forwarding Packets
39
Limitations

• Short-term solution that doesnt scale well!

40
New Developments in Inter-Domain Multicast Routing

• BGMP (Border Gateway Multicast Protocol)
• PIM-SM-like inter-domain multicast routing
  protocol
• builds bi-directional shared trees of domains
• each tree has a root domain (like an RP)
• MASC (Multicast Address Set Claim)
• mechanism to associate addresses with root
  domains
• MBGP
• extends BGP to convey address-range to root
  mapping to border routers

41
BGMP

• Bi-directional shared trees rooted at domains
• Border routers send joins and data toward root
  domain for mcast address in packet
• Mapping of multicast address to root domain
  obtained from BGP4 MRIB
• Source specific branches only where needed

42
AS1
ISP 1
Sender/Rcvr Group Initiator BGMP tree
43
BGMP Reference

• For more references
• Sigcomm 99 Kumar et al.
• The PIM project
• http//www.cise.ufl.edu/helmy/projects.htmlpim