Upload
simon-butler
View
223
Download
1
Tags:
Embed Size (px)
Citation preview
CS 5565Network Architecture and
Protocols
Godmar Back
Lecture 22
Announcements
• Project 2B due in 2 parts• Extra Credit Opportunities:
– Expand simulator (and your implementation) to introduce multiple link failures and link resurrection
CS 5565 Spring 2012
CS 5565 Spring 2012
Other Routing Protocols
• Ad-hoc Routing • Broadcast Routing• Multicast Routing
AODV
CS 5565 Spring 2012
Ad Hoc Routing
• Suppose routers can join & leave network at will
• Example: multiple wireless PCs with no base station
• AODV (Ad-Hoc On-Demand Distance Vector) Routing– “on-demand” compute routes only when
needed
CS 5565 Spring 2012
AODV
• Suppose A wants to know route to I– Starts broadcasting route requests
CS 5565 Spring 2012
AODV: Packet Types
• Sequence numbers used to weed out duplicates & decide on age of routes
• Hop counts to learn length of routes
Route Request
Route Reply
CS 5565 Spring 2012
AODV (cont’d)
• To limit load, broadcast scope is limited– Using IP TTL (AODV runs over IP!)
• To keep up with changes, nodes monitor traffic passing through them and inform neighbors (back-propagate) when links fail
• Difference to classic DV routing:– No periodic DV broadcasts to neighbors –
routes are learned only when needed
CS 5565 Spring 2012
(a) (b)
R1
R2
R3 R4
R1
R2
R3 R4
duplicatecreation/transmissionduplicate
duplicate
Broadcast Routing
• Motivation:– Use in-network duplication (b) rather than
source-duplication (a)
CS 5565 Spring 2012
Broadcast Routing (2)
• Simplest approach: simple flooding– Forward every packet from every link to all
other links every time– Inefficient, loops, “broadcast storms”
• Sequence-number controlled flooding– Only forward new packets to all other links
CS 5565 Spring 2012
A
B
G
D
E
C
F
Reverse Path Forwarding
• Only forward packets from link that lies on shortest path to the source– Assume unicast
routing has run & every node knows shortest path to source
CS 5565 Spring 2012
A
B
G
D
E
C
F
A
B
G
D
E
C
F
Broadcast using spanning tree
• Same spanning tree can be used for all sources!
CS 5565 Spring 2012
A
B
G
D
E
C
F1
2
3
4
5
A
B
G
D
E
C
F
Spanning Tree Construction
• Center-based: all nodes send “tree-join” message to known or elected center node
Multicast Routing
• Goal: find a tree (or trees) connecting routers having local mcast group members – tree: not all paths between routers used– source-based: different tree from each sender to rcvrs– shared-tree: same tree used by all group members
Shared tree Source-based trees
CS 5565 Spring 2012
Shortest Path Tree• mcast forwarding tree: tree of shortest
path routes from source to all receivers– Dijkstra’s algorithm
R1
R2
R3
R4
R5
R6 R7
21
6
3 4
5
i
router with attachedgroup member
router with no attachedgroup member
link used for forwarding,i indicates order linkadded by algorithm
LEGENDS: source
CS 5565 Spring 2012
Reverse Path Forwarding
• result is a source-specific reverse shortest path tree (SPT) – unless costs are asymmetric
router with attachedgroup member
router with no attachedgroup member
datagram will be forwarded
LEGEND
R1
R2
R3
R4
R5
R6 R7
S: source
datagram will not be forwarded
CS 5565 Spring 2012
Reverse Path Forwarding: Pruning
• no need to forward datagrams down subtrees with no group members
• “prune” msgs sent upstream by router with no downstream group members
router with attachedgroup member
router with no attachedgroup member
prune message
LEGEND
links with multicastforwarding
R1
R2
R3
R4
R5
R6 R7
S: source
P
P
P
CS 5565 Spring 2012
Shared-Tree: Steiner Tree
• Steiner Tree: minimum cost tree connecting all routers with attached group members
• problem is NP-complete (if intermediate nodes must be found)– excellent heuristics exists
• not used in practice:– computational complexity– information about entire network needed– monolithic: rerun whenever a router needs to
join/leave
CS 5565 Spring 2012
Center-Based trees
• single delivery tree shared by all• one router identified as “center” of tree• to join:
– edge router sends unicast join-msg addressed to center router
– join-msg “processed” by intermediate routers and forwarded towards center
– join-msg either hits existing tree branch for this center, or arrives at center
– path taken by join-msg becomes new branch of tree for this router
CS 5565 Spring 2012
Center-based Trees
Suppose R6 chosen as center:
router with attachedgroup member
router with no attachedgroup member
path order in which join messages generated
LEGEND
1
R1
R2
R3
R4
R5
R6 R7
2
3
1
CS 5565 Spring 2012
Internet Multicasting Routing: DVMRP
• DVMRP: distance vector multicast routing protocol, RFC1075
• flood and prune: reverse path forwarding, source-based tree– RPF tree based on DVMRP’s own routing tables
constructed by communicating DVMRP routers – no assumptions about underlying unicast– initial datagram to mcast group flooded everywhere
via RPF– routers not wanting group: send upstream prune
msgs
CS 5565 Spring 2012
DVMRP: continued…• soft state: DVMRP router periodically (1 min.)
“forgets” branches are pruned: – mcast data again flows down unpruned branch– downstream router: reprune or else continue to
receive data
• routers can quickly regraft to tree – following IGMP join at leaf
• odds and ends– commonly implemented in commercial routers– Mbone routing done using DVMRP
CS 5565 Spring 2012
CS 5565 Spring 2012
IGMP• Internet Group Management Protocol• Local protocol used by hosts to inform
their routers that they’d like to join a mcast group– MCast addresses are 224.x.x.x
• 28bits for groups, address indirection
• Simple protocol– Join– Leave (optional)– Membership Query (still interested?)
Tunneling
Q: How to connect “islands” of multicast routers in a “sea” of unicast routers?
mcast datagram encapsulated inside “normal” (non-multicast-addressed) datagram
normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router which undoes encapsulation
physical topology logical topology
CS 5565 Spring 2012
CS 5565 Spring 2012
Status of IP Multicast
• MBone exists• PIM: ‘Protocol Independent Multicast’
protocol– alternative to DVMRP
• Sporadically deployed• Has not taken off
– Despite need (?)