Date post: | 28-Dec-2015 |
Category: |
Documents |
Upload: | oswin-chandler |
View: | 222 times |
Download: | 3 times |
Chapter 4Network Layer
Computer Networking: A Top Down Approach Featuring the Internet,
2nd edition. Jim Kurose, Keith RossAddison-Wesley, July
2002.
A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in powerpoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2002J.F Kurose and K.W. Ross, All Rights ReservedMaterial modified by MLH, AK, AHR 3/03*Last 3 slides from: http://www.csd.uwo.ca/faculty/hanan/Perv/ Presentations/wirelesstech3.ppt
Chapter 4 roadmap4.1 Introduction and Network Service Models
4.2 Routing Principles
4.3 Hierarchical Routing
4.4 The Internet (IP) Protocol
4.5 Routing in the Internet
4.6 What’s Inside a Router?
4.7 IPv6
4.8 Multicast Routing
4.9 Mobility
Multicast: one sender to many receivers • Multicast: act of sending datagram to multiple
receivers with single “transmit” operation– analogy: one teacher to many students
• Question: how to achieve multicast
Multicast via unicast• source sends N
unicast datagrams, one addressed to each of N receivers
multicast receiver (red)
not a multicast receiver (red)
routersforward unicastdatagrams
Multicast: one sender to many receivers • Multicast: act of sending datagram to multiple
receivers with single “transmit” operation– analogy: one teacher to many students
• Question: how to achieve multicast
Network multicast• Router actively participate in
multicast, making copies of packets as needed and forwarding towards multicast receivers
Multicastrouters (red) duplicate and forward multicast datagrams
Multicast: one sender to many receivers • Multicast: act of sending datagram to multiple
receivers with single “transmit” operation– analogy: one teacher to many students
• Question: how to achieve multicast
Application-layer multicast• end systems involved in
multicast copy and forward unicast datagrams among themselves
Internet Multicast Service Model
multicast group concept: use of indirection– hosts addresses IP datagram to multicast group– routers forward multicast datagrams to hosts
that have “joined” that multicast group
128.119.40.186
128.59.16.12
128.34.108.63
128.34.108.60
multicast group
226.17.30.197
Multicast groups class D Internet addresses reserved for multicast:
host group semantics:o anyone can “join” (receive) multicast groupo anyone can send to multicast groupo no network-layer identification to hosts of members
needed: infrastructure to deliver mcast-addressed datagrams to all hosts that have joined that multicast group
Joining a mcast group: two-step process
• local: host informs local mcast router of desire to join group: IGMP (Internet Group Management Protocol)
• wide area: local router interacts with other routers to receive mcast datagram flow– many protocols (e.g., DVMRP, MOSPF, PIM)
IGMPIGMP
IGMP
wide-areamulticast
routing
IGMP: Internet Group Management Protocol
• host: sends IGMP report when application joins mcast group– IP_ADD_MEMBERSHIP socket option– host need not explicitly “unjoin” group when
leaving • router: sends IGMP query at regular intervals
– host belonging to a mcast group must reply to query
query report
IGMPIGMP version 1• router: Host Membership
Query msg broadcast on LAN to all hosts
• host: Host Membership Report msg to indicate group membership– randomized delay before
responding– implicit leave via no
reply to Query
• RFC 1112
IGMP v2: additions include• group-specific Query• Leave Group msg
– last host replying to Query can send explicit Leave Group msg
– router performs group-specific query to see if any hosts left in group
– RFC 2236
IGMP v3: under development as Internet draft
Multicast Routing: Problem Statement• 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
Approaches for building mcast trees
Approaches:• source-based tree: one tree per source
– shortest path trees– reverse path forwarding
• group-shared tree: group uses one tree– minimal spanning (Steiner) – center-based trees
…we first look at basic approaches, then specific protocols adopting these approaches
Shared-Tree: Steiner Tree
• Steiner Tree: minimum cost tree connecting all routers with attached group members
• problem is NP-complete• excellent heuristics exists• not used in practice:
– computational complexity– information about entire network needed– monolithic: rerun whenever a router needs to
join/leave
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
Center-based trees: an exampleSuppose R6 chosen as center:
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
path order in which join messages generated
LEGEND
21
3
1
Multicast Routing: Problem Statement
• 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
Approaches for building mcast trees
Approaches:• source-based tree: one tree per source
– shortest path trees– reverse path forwarding
• group-shared tree: group uses one tree– minimal spanning (Steiner) – center-based trees
…we first look at basic approaches, then specific protocols adopting these approaches
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
Reverse Path Forwarding
if (mcast datagram received on incoming link on shortest path back to center)
then flood datagram onto all outgoing links else ignore datagram
rely on router’s knowledge of unicast shortest path from it to sender
each router has simple forwarding behavior:
Reverse Path Forwarding: example
• result is a source-specific reverse SPT– may be a bad choice with asymmetric links
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
datagram will be forwarded
LEGENDS: source
datagram will not be forwarded
Reverse Path Forwarding: pruning• forwarding tree contains subtrees with no mcast
group members– no need to forward datagrams down subtree– “prune” msgs sent upstream by router with
no downstream group members
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
prune message
LEGENDS: source
links with multicastforwarding
P
P
P
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
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
TunnelingQ: 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
receiving mcast router unencapsulates to get mcast datagram
physical topology logical topology
PIM: Protocol Independent Multicast
• not dependent on any specific underlying unicast routing algorithm (works with all)
• two different multicast distribution scenarios :
Dense: group members
densely packed, in “close” proximity.
bandwidth more plentiful
Sparse: # networks with group
members small wrt # interconnected networks
group members “widely dispersed”
bandwidth not plentiful
Consequences of Sparse-Dense Dichotomy:
Dense• group membership by
routers assumed until routers explicitly prune
• data-driven construction on mcast tree (e.g., RPF)
• bandwidth and non-group-router processing profligate
Sparse:• no membership until
routers explicitly join• receiver- driven
construction of mcast tree (e.g., center-based)
• bandwidth and non-group-router processing conservative
PIM- Dense Mode
flood-and-prune RPF, similar to DVMRP but
underlying unicast protocol provides RPF info for incoming datagram
less complicated (less efficient) downstream flood than DVMRP reduces reliance on underlying routing algorithm
has protocol mechanism for router to detect it is a leaf-node router
PIM - Sparse Mode• center-based approach• router sends join msg to
rendezvous point (RP)– intermediate routers
update state and forward join
• after joining via RP, router can switch to source-specific tree– increased performance:
less concentration, shorter paths
R1
R2
R3
R4
R5
R6R7
join
join
join
all data multicastfrom rendezvouspoint
rendezvouspoint
PIM - Sparse Mode
sender(s):• unicast data to RP,
which distributes down RP-rooted tree
• RP can extend mcast tree upstream to source
• RP can send stop msg if no attached receivers– “no one is listening!”
R1
R2
R3
R4
R5
R6R7
join
join
join
all data multicastfrom rendezvouspoint
rendezvouspoint
Chapter 4 roadmap4.1 Introduction and Network Service Models4.2 Routing Principles4.3 Hierarchical Routing4.4 The Internet (IP) Protocol4.5 Routing in the Internet4.6 What’s Inside a Router?4.7 IPv64.8 Multicast Routing4.9 MobilityBut first! Merrie’s Spring Break!
What is mobility?• spectrum of mobility, from the network perspective:
no mobility high mobility
mobile user, usingsame access point
mobile user, passing through multiple access point while maintaining ongoing connections (like cell phone)
mobile user, connecting/ disconnecting from network using DHCP.
Mobility: Vocabularyhome network: permanent “home” of mobile(e.g., 128.119.40/24)
Permanent address: address in home network, can always be used to reach mobilee.g., 128.119.40.186
wide area network
Correspondent;IM, email, web browsing
McConnellNetwork
home agent: entity that will perform mobility functions on behalf of mobile, when mobile is remote; not necessarily a router. Can be a server/host on network.
Mobility: More Vocabulary
Care-of-address: address in visited network.(e.g., 79,129.13.2)
wide area network
visited network: network in which mobile currently resides (e.g., 79.129.13/24)
Permanent address: remains constant (e.g., 128.119.40.186)
foreign agent: entity in visited network that performs mobility functions on behalf of mobile.
correspondent: wants to communicate with mobile
McConnellNetwork Autobahn
Network
How do you contact a mobile friend:
• search all phone books?
• call her parents?• expect her to let you
know where he/she is?
I wonder where Alice moved to?
Consider a friend frequently changing addresses, how do you find her?
I hopeI hope Bob doesn’t find me!
Question: How do you think a correspondent contacts a mobile user?
Mobility: approaches• Let routing handle it: routers advertise permanent address of
mobile-nodes-in-residence via usual routing table exchange.– routing tables indicate where each mobile located– no changes to end-systems– Routers, potentially, would have to maintain forwarding table
entries for millions of mobile nodes• Let end-systems handle it:
– indirect routing: communication from correspondent to mobile goes through home agent, then forwarded to remote
– direct routing: correspondent gets foreign address of mobile, sends directly to mobile
Mobility: approaches• Let routing handle it: routers advertise permanent address of
mobile-nodes-in-residence via usual routing table exchange.
– routing tables indicate where each mobile located
– no changes to end-systems
– Routers, potentially, would have to maintain forwarding table entries for millions of mobile nodes
• let end-systems handle it:
– indirect routing: communication from correspondent to mobile goes through home agent, then forwarded to remote
– direct routing: correspondent gets foreign address of mobile, sends directly to mobile
not scalable
to millions of mobiles
Mobility: registration
End result:• Foreign agent knows about mobile• Home agent knows location of mobile
wide area network
McConnell NetworkAutobahn Network
1
Merrie contacts foreign agent on entering Autobahn network
2
Autobahn agent contacts McConnell agent: “This Merrie is a resident in my network”
Mobility via Indirect Routing
wide area network
McConnellNetwork
AutobahnNetwork
3
2
41
correspondent addresses packets using McConnell (home) address of mobile
McConnell agent intercepts packets, forwards to foreign agent, using the COA
Autobahn agent receives packets, forwards to Merrie
Merrie replies directly to correspondent
Forwarding datagrams to remote mobile
McConnell Permanent address: 128.119.40.186 Merrie’s
Care-of address: 79.129.13.2dest: 128.119.40.186
packet sent by correspondent
dest: 79.129.13.2 dest: 128.119.40.186
packet sent by home agent to foreign agent: a packet within a packet
dest: 128.119.40.186
foreign-agent-to-mobile packet
Leaving the Autobahn
AutobahnNetwork
Bye-bye Autobahn agent!On to France!
Upon leaving the Autobahn, Merrie will deregister with the Autobahn agent.
The foreign agent does not necessarily deregister Merrie’s Care of Address.
When Merrie applies for a new COA, the old one is dropped as the Autobahn agent no longer receives encapsulations from McConnell network. Essentially, a time out process.
As long as time between Autobahn and French Network is short, very few datagrams are lost; therefore a continuous connection. Those datagrams lost will be resent via transport protocols.
French Network
Indirect Routing: comments• Mobile uses two addresses:
– permanent address: used by correspondent (hence mobile location is transparent to correspondent)
– care-of-address: used by home agent to forward datagrams to mobile• Routing is based on tunneling• Question: When is this inefficient?
•Triangle Routing Problem:–inefficient when correspondent and mobile are in same network
Other problems:
•Delay
•Burdens networks
Mobility via Direct Routing
wide area network
McConnellNetwork
AutobahnNetwork
4
2
41correspondent requests, receives Merrie’s COA
correspondent forwards to Autobahn agent
Autobahn agent receives packets, forwards to Merrie
Merrie replies directly to correspondent
3
Mobility via Direct Routing: comments
• overcome triangle routing problem• non-transparent to correspondent: correspondent
must get care-of-address from home agentWhat happens if mobile changes networks?
• Need protocol to notify correspondent of changing COA
• Chaining: Autobahn forwards to France, forwards to England, forwards . . . Etc
What about security? This approach not considered secure by the IETF (Internet Engineering Task Force)
Mobile IP
• RFC 3220 http://www.ietf.org/rfc/rfc3220.txt• has many features we’ve seen:
– home agents, foreign agents, foreign-agent registration, care-of-addresses, encapsulation (packet-within-a-packet)
• three components to standard:– agent discovery
– registration with home agent
– indirect routing of datagrams
Mobile IP: agent discovery• agent advertisement: foreign/home agents advertise
service by broadcasting ICMP messages (typefield = 9)
RBHFMGV bits reserved
type = 16
type = 9 code = 0 = 9
checksum = 9
router address
standard ICMP fields
mobility agent advertisement
extension
length sequence #
registration lifetime
0 or more care-of-addresses
0 8 16 24
R bit: registration required
H,F bits: home and/or foreign agent
Functions of Agent Advertisement
• Allow for the detection of mobility agents• Let the mobile node (MN) know whether the agent is a
host or foreign agent• List one or more available care-of addresses• Inform the MN about special features provided by FA
– Example: Alternative encapsulation techniques• MN compares the network portion of the agent’s IP
address with the network portion of its home address. If the network portion do not match, then the MN is on a foreign network.
Mobile IP: registration example
visited network: 79.129.13/24 home agent
HA: 128.119.40.7 foreign agent
COA: 79.129.13.2 COA: 79.129.13.2
….
ICMP agent adv. Mobile agent
MA: 128.119.40.186
registration req.
COA: 79.129.13.2 HA: 128.119.40.7 MA: 128.119.40.186 Lifetime: 9999 identification:714 ….
registration req.
COA: 79.129.13.2 HA: 128.119.40.7 MA: 128.119.40.186 Lifetime: 9999 identification: 714 encapsulation format ….
registration reply
HA: 128.119.40.7 MA: 128.119.40.186 Lifetime: 4999 Identification: 714 encapsulation format ….
registration reply
HA: 128.119.40.7 MA: 128.119.40.186 Lifetime: 4999 Identification: 714 ….
time
Mobile IP: Registration
• The registration process involves 4 steps:– The MN requests the fowarding service by sending a
registration request to the foreign agent that the mobile node wants to use.
– The FA relays this request to the mobile node’s home agent.
– The HA either accepts or denies the request and sends a registration reply to the FA.
– The FA relays this reply to the MN.
Mobile IP: Registration• Registration fields include:
– Lifetime: The number of seconds before the registration is considered expired. A value of 0 is a request for deregistration.
– Home address: The home IP address of the mobile node.– Home agent: The IP address of the mobile node’s home
agent.– Care of Address: The home agent should forward IP
datagrams that it receives with MN’s home address to this destination address.
– Identification: Generated by MN; used for matching registration requests to registration replies (for security). Should be unique for each registration request.
Mobile IP: Registration
• The registration reply message includes the following fields:– Home address: The home IP address of the
mobile node.– Home agent: The IP address of the MN’s home
agent.– Lifetime: Number of seconds before registration
expires– Identification: Used for matching registration
requests to registration replies.
Ad-hoc Networks
• RFC 2501 http://www.ietf.org/rfc/rfc2501.txt• No routing infrastructure: two users establish a network
between themselves (think peer-to-peer)• Problems:
– Unreliable links can be jammed(Denial of Service attacks)/someone can listen in
– What if a node signs off (to save battery power)?– How to authenticate?– How to control access?– Need way to multihop
The Future?