1. IP ANYCAST and MULTICAST;
OVERLAYS and UNDERLAYS READING: SECTION 4.4, 4.5, 9.4.1
COS 461: Computer Networks
Spring 2010 (MW 3:00-4:20 in COS 105)
Mike Freedman

2. Outline today IP Anycast Multicast protocols Overlay networks
IP Multicast and IGMP
SRM (Scalable Reliable Multicast)
PGM (Pragmatic General Multicast)
Overlay networks
Tunnels between host computers
Build networks “on top” of the Internet
Provide better control, flexibility, QoS, isolation, …
Underlay tunnels
Across routers within AS
Build networks “below” IP route

3. Limitations of DNS-based failover
Failover/load balancing via multiple A records
;; ANSWER SECTION:
IN A
IN A
IN A
IN A
If server fails, service unavailable for TTL
Very low TTL: Extra load on DNS
Anyway, browsers cache DNS mappings 
What if root NS fails? All DNS queries take > 3s?

4. Motivation for IP anycast
Failure problem: client has resolved IP address
What if IP address can represent many servers?
Load-balancing/failover via IP addr, rather than DNS
IP anycast is simple reuse of existing protocols
Multiple instances of a service share same IP address
Each instance announces IP address / prefix in BGP / IGP
Routing infrastructure directs packets to nearest instance of the service
Can use same selection criteria as installing routes in the FIB
No special capabilities in servers, clients, or network

5. IP anycast in action Announce 10.0.0.1/32 Announce 10.0.0.1/32
Router 2
Server Instance A
Client
Router 1
Router 3
Router 4
Server Instance B
Announce /32

6. IP anycast in action 192.168.0.1 10.0.0.1 Router 2 Server Instance A
Client
Router 1
Router 3
Router 4
Server Instance B
Routing Table from Router 1:
Destination Mask Next-Hop Distance / / /

7. IP anycast in action 192.168.0.1 10.0.0.1 Router 2 Server Instance A
Client
Router 1
Router 3
Router 4
Server Instance B
DNS lookup for
produces a single answer:
IN A

8. IP anycast in action 192.168.0.1 10.0.0.1 Router 2 Server Instance A
Client
Router 1
Router 3
Router 4
Server Instance B
Routing Table from Router 1:
Destination Mask Next-Hop Distance / / /

9. IP anycast in action 192.168.0.1 10.0.0.1 Router 2 Server Instance A
Client
Router 1
Router 3
Router 4
Server Instance B
Routing Table from Router 1:
Destination Mask Next-Hop Distance / / /

10. IP anycast in action 192.168.0.1 10.0.0.1 Router 2 Server Instance A
Client
Router 1
Router 3
Router 4
Server Instance B
Routing Table from Router 1:
Destination Mask Next-Hop Distance / / /

11. IP anycast in action
From client/router perspective, topology could as well be:
Router 2
Client
Router 1
Server
Router 3
Router 4
Routing Table from Router 1:
Destination Mask Next-Hop Distance / / /

12. Downsides of IP anycast
Many Tier-1 ISPs ingress filter prefixes > /24
Publish a /24 to get a “single” anycasted address: Poor utilization
Scales poorly with the # anycast groups
Each group needs entry in global routing table
Not trivial to deploy
Obtain an IP prefix and AS number; speak BGP
Subject to the limitations of IP routing
No notion of load or other application-layer metrics
Convergence time can be slow (as BGP or IGP convergence)
Failover doesn’t really work with TCP
TCP is stateful; other server instances will just respond with RSTs
Anycast may react to network changes, even though server online
Root name servers (UDP) are anycasted, little else

13. Multicast protocols

14. Multicasting messages
Simple application multicast: Iterated unicast
Client simply unicasts message to every recipient
Pros: simple to implement, no network modifications
Cons: O(n) work on sender, network
Advanced overlay multicast (“peer-to-peer”)
Build receiver-driven tree
Pros: Scalable, no network modifications
Cons: O(log n) work on sender, network; complex to implement
IP multicast
Embed receiver-driven tree in network layer
Pros: O(1) work on client, O(# receivers) on network
Cons: requires network modifications; scalability concerns?

15. IP Multicast Simple to use in applications Receiver-driven membership
Multicast “group” defined by IP multicast address
IP multicast addresses look similar to IP unicast addrs
to (RPC 3171)
265 M multicast groups at most
Best effort delivery only
Sender issues single datagram to IP multicast address
Routers delivery packets to all subnetworks that have a receiver “belonging” to the group
Receiver-driven membership
Receivers join groups by informing upstream routers
Internet Group Management Protocol (v3: RFC 3376)

16. IGMP v1 Two types of IGMP msgs (both have IP TTL of 1)
Host membership query: Routers query local networks to discover which groups have members
Host membership report: Hosts report each group (e.g., multicast addr) to which belong, by broadcast on net interface from which query was received
Routers maintain group membership
Host senders an IGMP “report” to join a group
Multicast routers periodically issue host membership query to determine liveness of group members
Note: No explicit “leave” message from clients
Why no explicit leave? Unwanted packets can just be dropped at client!

17. IGMP IGMP v2 added: IGMP v3 added:
If multiple routers, one with lowest IP elected querier
Explicit leave messages for faster pruning
Group-specific query messages
IGMP v3 added:
Source filtering: Join specifies multicast “only from” or “all but from” specific source addresses
Why no explicit leave? Unwanted packets can just be dropped at client!

18. IGMP Parameters Questions Maximum report delay: 10 sec
Query internal default: 125 sec
Time-out interval: 270 sec
2 * (query interval + max delay)
Questions
Is a router tracking each attached peer?
Should clients respond immediately to membership queries?
What if local networks are layer-two switched?
1. Router not tracking each peer, only each network: because these local networks at broadcast media (e.g., unswitched ethernet).
2. Random delay (from 0…D) in order to minimize responses to queries: Only one response from broadcast domain needed.
3. L2 switches typically broadcast multicast traffic out all ports. Alternatively, IGMP snooping (sneak peek into the layer 3 content of a multicast packet), Cisco’s proprietary, or static forwarding tables…

19. So far, we’ve been best-effort IP multicast…

20. Challenges for reliable multicast
Ack-implosion if all destinations ack at once
Source does not know # of destinations
How to retransmit?
To all? One bad link effects entire group
Only where losses? Loss near sender makes retransmission as inefficient as replicated unicast
Once size fits all?
Heterogeneity: receivers, links, group sizes
Not all multicast applications need reliability of the type provided by TCP. Some can tolerate reordering, delay, etc.

21. Scalable Reliable Multicast
Receives all packets or unrecoverable data loss
Data packets sent via IP multicast
ODATA includes sequence numbers
Upon packet failure:
Receiver multicasts a NAK
… or sends NAK to sender, who multicasts a NAK confirmation (NCF)
Scale through NAK suppression
… if received a NAK or NCF, don’t NAK yourself
What do we need to do to get adequate suppression?
Add random delays before NAK’ing
But what if the multicast group grows big?
Repair through packet retransmission (RDATA)
From initial sender
From designated local repairer (DLR – IETF loves acronyms!)
Grows big: delay needs to grow. Lack of efficiency.

22. Pragmatic General Multicast (RFC 3208)
Similar approach as SRM: IP multicast + NAKs
… but more techniques for scalability
Hierarchy of PGM-aware network elements
NAK suppression: Similar to SRM
NAK elimination: Send at most one NAK upstream
Or completely handle with local repair!
Constrained forwarding: Repair data can be suppressed downstream if no NAK seen on that port
Forward-error correction: Reduce need to NAK
Works when only sender is multicast-able

23. Overlay Networks

24. Overlay Networks

25. Overlay Networks
Focus at the application level

26. IP Tunneling to Build Overlay Links
IP tunnel is a virtual point-to-point link
Illusion of a direct link between two separated nodes
Encapsulation of the packet inside an IP datagram
Node B sends a packet to node E
… containing another packet as the payload A B E F
Logical view:
tunnel A B E F
Physical view:

27. Tunnels Between End Hosts
Src: A
Dest: B
Src: C
Dest: B
Src: A
Dest: B A C
Src: A
Dest: C
Src: A
Dest: B

28. Overlay Networks A logical network built on top of a physical network
Overlay links are tunnels through the underlying network
Many logical networks may coexist at once
Over the same underlying network
And providing its own particular service
Nodes are often end hosts
Acting as intermediate nodes that forward traffic
Providing a service, such as access to files
Who controls the nodes providing service?
The party providing the service
Distributed collection of end users

29. Overlays for Incremental Deployment

30. Using Overlays to Evolve the Internet
Internet needs to evolve
IPv6
Security
Mobility
Multicast
But, global change is hard
Coordination with many ASes
“Flag day” to deploy and enable the technology
Instead, better to incrementally deploy
And find ways to bridge deployment gaps

31. 6Bone: Deploying IPv6 over IP4A B E F
tunnel
Logical view:
IPv6
IPv6
IPv6
IPv6 A B C D E F
Physical view:
IPv6
IPv6
IPv4
IPv4
IPv6
IPv6
Flow: X
Src: A
Dest: F
data
Flow: X
Src: A
Dest: F
data
Src:B
Dest: E
Flow: X
Src: A
Dest: F
data
Src:B
Dest: E
Flow: X
Src: A
Dest: F
data
A-to-B:
IPv6
E-to-F:
IPv6
B-to-C:
IPv6 inside
IPv4
B-to-C:
IPv6 inside
IPv4

32. Secure Communication Over Insecure Links
Encrypt packets at entry and decrypt at exit
Eavesdropper cannot snoop the data
… or determine the real source and destination

33. Communicating With Mobile Users
A mobile user changes locations frequently
So, the IP address of the machine changes often
The user wants applications to continue running
So, the change in IP address needs to be hidden
Solution: fixed gateway forwards packets
Gateway has a fixed IP address
… and keeps track of the mobile’s address changes
gateway

34. MBone: Multicast Backbone
A catch-22 for deploying multicast
Router vendors wouldn’t support IP multicast
… since they weren’t sure anyone would use it
And, since it didn’t exist, nobody was using it
Idea: software implementing multicast protocols
And unicast tunnels to traverse non-participants

35. We saw tunneling “on top of” IP. What about tunneling “below” IP?
Introducing
Multi-Protocol Label Switching
(MPLS)

36. MPLS Overview Main idea: Virtual circuit
Packets forwarded based only on circuit identifier
Source 1
Destination
Source 2
Router can forward traffic to the same destination on different interfaces/paths.

37. MPLS Overview Main idea: Virtual circuit
Packets forwarded based only on circuit identifier
Source 1
Destination
Source 2
Router can forward traffic to the same destination on different interfaces/paths.

38. Circuit Abstraction: Label SwappingD A 2 1
Tag Out New 3 A 2 D
Label-switched paths (LSPs): Paths are “named” by the label at the path’s entry point
At each hop, MPLS routers:
Use label to determine outgoing interface, new label
Thus, push/pop/swap MPLS headers that encapsulate IP
Label distribution protocol: responsible for disseminating signalling information

39. Reconsider security problem

40. Layer 3 Virtual Private Networks
Private communications over a public network
A set of sites that are allowed to communicate with each other
Defined by a set of administrative policies
Determine both connectivity and QoS among sites
Established by VPN customers
One way to implement: BGP/MPLS VPN (RFC 2547)

41. MPLS to forward traffic
Layer 3 BGP/MPLS VPNs
VPN A/Site 1
VPN A/Site 2
VPN A/Site 3
VPN B/Site 2
VPN B/Site 1
VPN B/Site 3
CEA1
CEB3
CEA3
CEB2
CEA2
CE1B1
CE2B1
PE1
PE2
PE3 P1 P2 P3
10.1/16
10.2/16
10.3/16
10.4/16
BGP to exchange routes
MPLS to forward traffic
Isolation: Multiple logical networks over a single, shared physical infrastructure
Tunneling: Keeping routes out of the core

42. High-Level Overview of Operation
IP packets arrive at provider
edge router (PE)
Destination IP looked up in forwarding table
– Multiple “virtual” forwarding tables
Datagram sent to customer’s network using tunneling (i.e., an MPLS label-switched path)

43. Virtual Routing and Forwarding
Separate tables per customer at each router
RFC 2547: Route Distinguishers
Customer 1
/24
/24 RD: Purple
Customer 1
Customer 2
/24
Customer 2
/24 RD: Blue

44. Forwarding in BGP/MPLS VPNs
Step 1: Packet arrives at incoming interface
Site VRF determines BGP next-hop and Label #2
Label 2
IP Datagram
Step 2: BGP next-hop lookup, add corresponding LSP (also at site VRF)
IP Datagram
Label 2
Label 1

45. Forwarding
PE and P routers have BGP next-hop reachability through the backbone IGP
Labels are distributed through LDP (hop-by-hop) corresponding to BGP Next-Hops
Two-Label Stack is used for packet forwarding
Top label indicates Next-Hop (interior label)
Second label indicates outgoing interface / VRF (exterior label)
Corresponds to LSP of BGP next-hop (PE)
Corresponds to VRF/interface at exit
Layer 2 Header
Label 1
Label 2
IP Datagram

46. Forwarding Layer 2 Header Label 1 Label 2 IP Datagram VPN A/Site 1
VPN B/Site 2
VPN B/Site 1
VPN B/Site 3
CEA1
CEB3
CEA3
CEB2
CEA2
CE1B1
CE2B1
PE1
PE2
PE3 P1 P2 P3
10.1/16
10.2/16
10.3/16
10.4/16
Layer 2 Header
Label 1
Label 2
IP Datagram

47. Outline today IP Anycast Multicast protocols Overlay networks
IP Multicast and IGMP
SRM (Scalable Reliable Multicast)
PGM (Pragmatic General Multicast)
Overlay networks
Tunnels between host computers
Build networks “on top” of the Internet
Provide better control, flexibility, QoS, isolation, …
Underlay tunnels
Across routers within AS
Build networks “below” IP route