ECS152BXin Liu Roadmap Routing in the Internet –Routing algorithms –Routing Protocols Intra-AS routing: RIP and OSPF Inter-AS routing: BGP

ECS152B Xin Liu

Roadmap

• Routing in the Internet– Routing algorithms

– Routing Protocols

• Intra-AS routing: RIP and OSPF

• Inter-AS routing: BGP

ECS152B Xin Liu

Routing in the Internet

• The Global Internet consists of Autonomous Systems (AS) interconnected with each other:– Stub AS: small corporation: one connection to other AS’s

– Multihomed AS: large corporation (no transit): multiple connections to other AS’s

– Transit AS: provider, hooking many AS’s together

• Two-level routing: – Intra-AS: administrator responsible for choice of routing

algorithm within network

– Inter-AS: unique standard for inter-AS routing: BGP

ECS152B Xin Liu

Internet AS Hierarchy

Inter-AS border (exterior gateway) routers

Intra-AS interior routers

ECS152B Xin Liu

Intra-AS Routing

• Also known as Interior Gateway Protocols (IGP)• Most common Intra-AS routing protocols:

– RIP: Routing Information Protocol

– OSPF: Open Shortest Path First

– IGRP: Interior Gateway Routing Protocol (Cisco proprietary)

ECS152B Xin Liu

RIP ( Routing Information Protocol)

• Distance vector algorithm• Included in BSD-UNIX Distribution in 1982• Distance metric: # of hops (max = 15 hops)

– Can you guess why?

• Distance vectors: exchanged among neighbors every 30 sec via Response Message (also called advertisement)

• Each advertisement: list of up to 25 destination nets within AS

ECS152B Xin Liu

RIP: Example

Destination Network Next Router Num. of hops to dest. w A 2

y B 2 z B 7

x -- 1…. …. ....

w x y

z

A

C

D B

Routing table in D

ECS152B Xin Liu

RIP: Example

Destination Network Next Router Num. of hops to dest. w A 2

y B 2 z B A 7 5

x -- 1…. …. ....Routing table in D

w x y

z

A

C

D B

Dest Next hops w - - x - - z C 4 …. … ...

Advertisementfrom A to D

ECS152B Xin Liu

RIP: Link Failure and Recovery

If no advertisement heard after 180 sec --> neighbor/link declared dead– routes via neighbor invalidated– new advertisements sent to neighbors– neighbors in turn send out new advertisements (if

tables changed)– link failure info quickly propagates to entire net– poison reverse used to prevent ping-pong loops

(infinite distance = 16 hops)

ECS152B Xin Liu

RIP Table processing

• RIP routing tables managed by application-level process called route-d (daemon)

• advertisements sent in UDP packets, periodically repeated

physical

link

network forwarding (IP) table

Transprt (UDP)

routed

physical

link

network (IP)

Transprt (UDP)

routed

forwardingtable

ECS152B Xin Liu

RIP Table example (continued)

Router: giroflee.eurocom.fr

• Three attached networks (LANs)

• Router only knows routes to attached LANs

• Default router used to “go up”

• Route multicast address: 224.0.0.0

• Loopback interface (for debugging)

Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 127.0.0.1 127.0.0.1 UH 0 26492 lo0 192.168.2. 192.168.2.5 U 2 13 fa0 193.55.114. 193.55.114.6 U 3 58503 le0 192.168.3. 192.168.3.5 U 2 25 qaa0 224.0.0.0 193.55.114.6 U 3 0 le0 default 193.55.114.129 UG 0 143454

ECS152B Xin Liu

OSPF (Open Shortest Path First)

• “open”: publicly available

• Uses Link State algorithm – LS packet dissemination

– Topology map at each node

– Route computation using Dijkstra’s algorithm

• OSPF advertisement carries one entry per neighbor router

• Advertisements disseminated to entire AS (via flooding)– Carried in OSPF messages directly over IP (rather than TCP or UDP

ECS152B Xin Liu

OSPF “advanced” features (not in RIP)

• Security: all OSPF messages authenticated (to prevent malicious intrusion)

• Multiple same-cost paths allowed (only one path in RIP)

• For each link, multiple cost metrics for different TOS (e.g., satellite link cost set “low” for best effort; high for real time)

• Integrated uni- and multicast support:

– Multicast OSPF (MOSPF) uses same topology data base as OSPF

• Hierarchical OSPF in large domains.

ECS152B Xin Liu

Hierarchical OSPF

ECS152B Xin Liu

Hierarchical OSPF

• Two-level hierarchy: local area, backbone.– Link-state advertisements only in area – each nodes has detailed area topology; only know

direction (shortest path) to nets in other areas.• Area border routers: “summarize” distances to nets in

own area, advertise to other Area Border routers.• Backbone routers: run OSPF routing limited to

backbone.• Boundary routers: connect to other AS’s.

ECS152B Xin Liu

Inter-AS routing in the Internet: BGP

Figure 4.5.2-new2: BGP use for inter-domain routing

AS2 (OSPF

intra-AS routing)

AS1 (RI P intra-AS

routing) BGP

AS3 (OSPF intra-AS

routing)

BGP

R1 R2

R3

R4

R5

ECS152B Xin Liu

Internet inter-AS routing: BGP

• BGP (Border Gateway Protocol): the de facto standard• Path Vector protocol:

– similar to Distance Vector protocol– each Border Gateway broadcast to neighbors

(peers) entire path (i.e., sequence of AS’s) to destination

– BGP routes to networks (ASs), not individual hosts– E.g., Gateway X may send its path to dest. Z:

Path (X,Z) = X,Y1,Y2,Y3,…,Z

ECS152B Xin Liu

Internet inter-AS routing: BGP

Suppose: gateway X send its path to peer gateway W

• W may or may not select path offered by X– cost, policy (don’t route via competitors AS), loop prevention reasons .

• If W selects path advertised by X, then:

Path (W,Z) = w, Path (X,Z)

• Note: X can control incoming traffic by controlling it route advertisements to peers:

– e.g., don’t want to route traffic to Z -> don’t advertise any routes to Z

ECS152B Xin Liu

BGP: controlling who routes to you

Figure 4.5-BGPnew: a simple BGP scenario

A

B

C

W X

Y

legend:

customer network:

provider network

• A,B,C are provider networks• X,W,Y are customer (of provider networks)• X is dual-homed: attached to two networks

– X does not want to route from B via X to C– .. so X will not advertise to B a route to C

ECS152B Xin Liu

BGP: controlling who routes to you

Figure 4.5-BGPnew: a simple BGP scenario

A

B

C

W X

Y

legend:

customer network:

provider network

• A advertises to B the path AW

• B advertises to X the path BAW

• Should B advertise to C the path BAW?– No way! B gets no “revenue” for routing CBAW since neither W nor C

are B’s customers

– B wants to force C to route to w via A

– B wants to route only to/from its customers!

ECS152B Xin Liu

BGP operation

Q: What does a BGP router do?• Receiving and filtering route advertisements from

directly attached neighbor(s). • Route selection.

– To route to destination X, which path (of several advertised) will be taken?

• Sending route advertisements to neighbors.

ECS152B Xin Liu

BGP messages

• BGP messages exchanged using TCP.• BGP messages:

– OPEN: opens TCP connection to peer and authenticates sender

– UPDATE: advertises new path (or withdraws old)– KEEPALIVE keeps connection alive in absence of

UPDATES; also ACKs OPEN request– NOTIFICATION: reports errors in previous msg;

also used to close connection

ECS152B Xin Liu

Why different Intra- and Inter-AS routing ?

Policy: • Inter-AS: admin wants control over how its traffic routed, who

routes through its net.

• Intra-AS: single admin, so no policy decisions needed

Scale:• hierarchical routing saves table size, reduced update traffic

Performance:

• Intra-AS: can focus on performance

• Inter-AS: policy may dominate over performance

ECS152B Xin Liu

ICMP: Internet Control Message Protocol

• used by hosts, routers, gateways to communication network-level information

• network-layer “above” IP:– ICMP msgs carried in IP datagrams

• Two types:– error reporting

• unreachable host, network, port, protocol, • fragment needed by DF bit set• Time exceeded (TTL)• etc.

– Query/response• Echo request/reply• Timestamp request/reply• Address mask request/reply

ECS152B Xin Liu

ICMP

Type Code description Query Error0 0 echo reply (ping) x3 0 dest. network unreachable x3 1 dest host unreachable x3 2 dest protocol unreachable x3 3 dest port unreachable x3 6 dest network unknown x3 7 dest host unknown x4 0 source quench (congestion x control - not used)8 0 echo request (ping) x9 0 route advertisement x10 0 router discovery x11 0 TTL expired x12 0 bad IP header x

ECS152B Xin Liu

ICMP

IP header ICMP message

IP datagram

8-bit type 8-bit code 16-bit checksum

Contents depends on type and code

ECS152B Xin Liu

Error message

• ICMP error message: – ICMP header:

• type, code, checksum,– ICMP message

• IP header plus first 8 bytes of IP datagram causing error

• To prevent broadcast storm: NOT generate ICMP in response to– ICMP error message– Dest=IP broadcast address– Link layer broadcast– A fragment other than the first– Source address not defined as a single host

ECS152B Xin Liu

Ping

• Basic connectivity test

• uses ICMP eco request/reply messages instead of UDP/TCP.

• Client/server paradigm

• Usually implemented in the kernel.

• “man ping”

ECS152B Xin Liu

Format

type (0) code(0) 16-bit checksum

Optional data

identifier sequence no.

ECS152B Xin Liu

Ping

bread% ping -s shannon.cs.ucdavis.eduPING shannon.cs.ucdavis.edu: 56 data bytes64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=0. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=1. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=2. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=3. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=4. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=5. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=6. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=7. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=8. time=0. ms64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=9. time=0. ms…----shannon.cs.ucdavis.edu PING Statistics----30 packets transmitted, 30 packets received, 0% packet lossround-trip (ms) min/avg/max = 0/0/0

ECS152B Xin Liu

Ping

bread% ping -s mark.ecn.purdue.eduPING mark.ecn.purdue.edu: 56 data bytes64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=0. time=66. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=1. time=64. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=3. time=64. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=4. time=65. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=5. time=64. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=8. time=65. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=10. time=65. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=11. time=65. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=12. time=65. ms64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=15. time=64. ms^C----mark.ecn.purdue.edu PING Statistics----18 packets transmitted, 10 packets received, 44% packet lossround-trip (ms) min/avg/max = 64/65/66

ECS152B Xin Liu

Traceroute

• By Van Jacobson• See route that IP datagram follow• Use ICMP and TTL

– A router gets an IP datagram with TTL 0/1, discards the packet and sends back an ICMP to the source “time exceeded”.

– Source sends UDP fragment with 1,2,3, TTL values

– IP packet contains an UDP with unused post #. dest. Replies “port unreachable” ICMP message.

ECS152B Xin Liu

Traceroutebread% traceroute ector.cs.purdue.edutraceroute: Warning: Multiple interfaces found; using 169.237.6.16 @ qfe0traceroute to ector.cs.purdue.edu (128.10.2.10), 30 hops max, 40 byte packets 1 169.237.5.254 (169.237.5.254) 0.594 ms 0.337 ms 0.298 ms 2 169.237.246.238 (169.237.246.238) 0.533 ms 0.479 ms 0.474 ms 3 128.120.2.49 (128.120.2.49) 0.547 ms 0.475 ms 0.475 ms 4 core0.ucdavis.edu (128.120.0.30) 0.616 ms 0.671 ms 0.642 ms 5 area0-area14p.ucdavis.edu (128.120.0.222) 0.570 ms 0.468 ms 0.821 ms 6 area14p-border20.ucdavis.edu (128.120.0.250) 1.149 ms 0.691 ms 3.132 ms 7 dc-oak-dc2--ucd-ge.cenic.net (137.164.24.225) 4.751 ms 2.434 ms 4.521 ms 8 dc-oak-dc1--oak-dc2-ge.cenic.net (137.164.22.36) 2.394 ms 4.217 ms 2.452 ms 9 dc-svl-dc1--oak-dc1-10ge.cenic.net (137.164.22.30) 201.245 ms 5.091 ms 183.393 ms10 dc-sol-dc1--svl-dc1-pos.cenic.net (137.164.22.28) 13.421 ms 11.258 ms 11.155 ms11 hpr-lax-hrp1--dc-lax-dc1-ge.cenic.net (137.164.22.13) 11.571 ms 14.390 ms 11.809 ms12 abilene-LA--hpr-lax-gsr1-10ge.cenic.net (137.164.25.3) 13.431 ms 11.417 ms 11.289 ms13 snvang-losang.abilene.ucaid.edu (198.32.8.95) 19.141 ms 20.516 ms 19.117 ms14 kscyng-snvang.abilene.ucaid.edu (198.32.8.103) 54.300 ms 53.943 ms 53.998 ms15 iplsng-kscyng.abilene.ucaid.edu (198.32.8.80) 64.783 ms 68.220 ms 63.659 ms16 ul-abilene.indiana.gigapop.net (192.12.206.250) 63.567 ms 63.381 ms 63.025 ms17 tel-210-m10-01-gp.tcom.purdue.edu (192.5.40.9) 65.017 ms * 64.982 ms18 cs-2u01-c3550-01-242.tcom.purdue.edu (128.210.242.51) 65.527 ms 65.282 ms 65.083 ms19 * ector.cs.purdue.edu (128.10.2.10) 65.528 ms *

ECS152B Xin Liu

DHCP: Dynamic Host Configuration Protocol

Goal: allow host to dynamically obtain its IP address from network server when it joins networkCan renew its lease on address in use

Allows reuse of addresses (only hold address while connected an “on”

Support for mobile users who want to join network (more shortly)

DHCP overview:– host broadcasts “DHCP discover” msg– DHCP server responds with “DHCP offer” msg– host requests IP address: “DHCP request” msg– DHCP server sends address: “DHCP ack” msg

ECS152B Xin Liu

DHCP client-server scenario

223.1.1.1

223.1.1.2

223.1.1.3

223.1.1.4 223.1.2.9

223.1.2.2

223.1.2.1

223.1.3.2223.1.3.1

223.1.3.27

A

BE

DHCP server

arriving DHCP client needsaddress in thisnetwork

ECS152B Xin Liu

DHCP client-server scenarioDHCP server: 223.1.2.5 arriving

client

time

DHCP discover

src : 0.0.0.0, 68 dest.: 255.255.255.255,67yiaddr: 0.0.0.0transaction ID: 654

DHCP offer

src: 223.1.2.5, 67 dest: 255.255.255.255, 68yiaddrr: 223.1.2.4transaction ID: 654Lifetime: 3600 secs

DHCP request

src: 0.0.0.0, 68 dest:: 255.255.255.255, 67yiaddrr: 223.1.2.4transaction ID: 655Lifetime: 3600 secs

DHCP ACK

src: 223.1.2.5, 67 dest: 255.255.255.255, 68yiaddrr: 223.1.2.4transaction ID: 655Lifetime: 3600 secs

ECS152B Xin Liu

NAT: Network Address Translation

10.0.0.1

10.0.0.2

10.0.0.3

10.0.0.4

138.76.29.7

local network(e.g., home network)

10.0.0/24

rest ofInternet

Datagrams with source or destination in this networkhave 10.0.0/24 address for

source, destination (as usual)

All datagrams leaving localnetwork have same single source

NAT IP address: 138.76.29.7,different source port numbers

ECS152B Xin Liu


• Motivation: local network uses just one IP address as far as outside word is concerned:

– no need to be allocated range of addresses from ISP: - just one IP address is used for all devices

– can change addresses of devices in local network without notifying outside world

– can change ISP without changing addresses of devices in local network

– devices inside local net not explicitly addressable, visible by outside world (a security plus).

ECS152B Xin Liu

NAT: Network Address TranslationImplementation: NAT router must:

– outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #)

. . . remote clients/servers will respond using (NAT IP address, new port #) as destination addr.

– remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair

– incoming datagrams: replace (NAT IP address, new port #) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table

ECS152B Xin Liu


10.0.0.1

10.0.0.2

10.0.0.3

S: 10.0.0.1, 3345D: 128.119.40.186, 80

1

10.0.0.4

138.76.29.7

1: host 10.0.0.1 sends datagram to 128.119.40, 80

NAT translation tableWAN side addr LAN side addr

138.76.29.7, 5001 10.0.0.1, 3345…… ……

S: 128.119.40.186, 80 D: 10.0.0.1, 3345

4

S: 138.76.29.7, 5001D: 128.119.40.186, 80

2

2: NAT routerchanges datagramsource addr from10.0.0.1, 3345 to138.76.29.7, 5001,updates table

S: 128.119.40.186, 80 D: 138.76.29.7, 5001

3

3: Reply arrives dest. address: 138.76.29.7, 5001

4: NAT routerchanges datagramdest addr from138.76.29.7, 5001 to 10.0.0.1, 3345

ECS152B Xin Liu


• 16-bit port-number field: – 60,000 simultaneous connections with a single

LAN-side address!

• NAT is controversial:– routers should only process up to layer 3– violates end-to-end argument

• NAT possibility must be taken into account by app designers, eg, P2P applications

– address shortage should instead be solved by IPv6

ECS152B Xin Liu

IPv6• Initial motivation: 32-bit address space completely

allocated by 2008. • Additional motivation:

– header format helps speed processing/forwarding

– header changes to facilitate QoS

– new “anycast” address: route to “best” of several replicated servers

• IPv6 datagram format: – fixed-length 40 byte header

– no fragmentation allowed

ECS152B Xin Liu

IPv6 Header (Cont)

Priority: identify priority among datagrams in flowFlow Label: identify datagrams in same “flow.” (concept of“flow” not well defined).Next header: identify upper layer protocol for data

ECS152B Xin Liu

Other Changes from IPv4

• Checksum: removed entirely to reduce processing time at each hop

• Options: allowed, but outside of header, indicated by “Next Header” field

• ICMPv6: new version of ICMP– additional message types, e.g. “Packet Too

Big”– multicast group management functions

ECS152B Xin Liu

Transition From IPv4 To IPv6

• Not all routers can be upgraded simultaneous– no “flag days”

– How will the network operate with mixed IPv4 and IPv6 routers?

• Two proposed approaches:– Dual Stack: some routers with dual stack (v6, v4) can

“translate” between formats

– Tunneling: IPv6 carried as payload in IPv4 datagram among IPv4 routers

ECS152B Xin Liu

Dual Stack Approach

A B E F

IPv6 IPv6 IPv6 IPv6

C D

IPv4 IPv4

Flow: XSrc: ADest: F

data

Flow: ??Src: ADest: F

data

Src:ADest: F

data

A-to-B:IPv6

Src:ADest: F

data

B-to-C:IPv4

B-to-C:IPv4

B-to-C:IPv6

ECS152B Xin Liu

TunnelingA B E F

IPv6 IPv6 IPv6 IPv6

tunnelLogical view:

Physical view:A B E F

IPv6 IPv6 IPv6 IPv6

C D

IPv4 IPv4


data


data


data

Src:BDest: E


data

Src:BDest: E

A-to-B:IPv6

E-to-F:IPv6

B-to-C:IPv6 inside

IPv4

B-to-C:IPv6 inside

IPv4

ECS152B Xin Liu

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.

ECS152B Xin Liu

Mobility: Vocabulary

home 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

home agent: entity that will perform mobility functions on behalf of mobile, when mobile is remote

wide area network

correspondent

ECS152B Xin Liu

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

ECS152B Xin Liu

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 friend frequently changing addresses, how do you find her?

ECS152B Xin Liu

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

• 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

ECS152B Xin Liu

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

• 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

ECS152B Xin Liu

Mobility: registration

End result:

• Foreign agent knows about mobile

• Home agent knows location of mobile

wide area network

home network

visited network

1

mobile contacts foreign agent on entering visited network

2

foreign agent contacts home agent home: “this mobile is resident in my network”

ECS152B Xin Liu

Mobility via Indirect Routing

wide area network

homenetwork

visitednetwork

3

2

41

correspondent addresses packets using home address of mobile

home agent intercepts packets, forwards to foreign agent

foreign agent receives packets, forwards to mobile

mobile replies directly to correspondent

ECS152B Xin Liu

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

• foreign agent functions may be done by mobile itself

• triangle routing: correspondent-home-network-mobile

– inefficient when

correspondent, mobile

are in same network

ECS152B Xin Liu

Forwarding datagrams to remote mobile

Permanent address: 128.119.40.186

Care-of address: 79.129.13.2

dest: 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

ECS152B Xin Liu

Indirect Routing: moving between networks

• suppose mobile user moves to another network– registers with new foreign agent

– new foreign agent registers with home agent

– home agent update care-of-address for mobile

– packets continue to be forwarded to mobile (but with new care-of-address)

• Mobility, changing foreign networks transparent: on going connections can be maintained!

ECS152B Xin Liu

Mobility via Direct Routing

wide area network

homenetwork

visitednetwork

4

2

41correspondent requests, receives foreign address of mobile

correspondent forwards to foreign agent

foreign agent receives packets, forwards to mobile

mobile replies directly to correspondent

3

ECS152B Xin Liu

Mobility via Direct Routing: comments

• overcome triangle routing problem

• non-transparent to correspondent: correspondent must get care-of-address from home agent– What happens if mobile changes networks?

ECS152B Xin Liu

Mobile IP

• RFC 3220• 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

ECS152B Xin Liu

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

ECS152B Xin Liu

Mobile IP: registration example

visited network: 79.129.13/ 24 home agent

HA: 128.119.40.7 f oreign agent

COA: 79.129.13.2 COA: 79.129.13.2

….

I CMP 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

ECS152B Xin Liu

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

ECS152B Xin Liu

Multicast: one sender to many receivers • Multicast: act of sending datagram to multiple receivers with

single “transmit” operation



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

ECS152B Xin Liu

Multicast: one sender to many receivers • Multicast: act of sending datagram to multiple receivers

with single “transmit” operation



Application-layer multicast• end systems involved in

multicast copy and forward unicast datagrams among themselves

ECS152B Xin Liu

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

ECS152B Xin Liu

Multicast groups

class D Internet addresses reserved for multicast:

host group semantics:

o anyone can “join” (receive) multicast group

o anyone can send to multicast group

o no network-layer identification to hosts of members needed: infrastructure to deliver mcast-addressed datagrams to

all hosts that have joined that multicast group

ECS152B Xin Liu

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

ECS152B Xin Liu

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

ECS152B Xin Liu

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

• 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



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



prune message

LEGENDS: source

links with multicastforwarding

P

P

P

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 example

Suppose R6 chosen as center:

R1

R2

R3

R4

R5

R6 R7



path order in which join messages generated

LEGEND

21

3

1

Documents

ECS152BXin Liu Roadmap Routing in the Internet –Routing algorithms –Routing Protocols Intra-AS routing: RIP and OSPF Inter-AS routing: BGP