1. Towards an Evolvable Internet Architecture
Ben Heruska and Mike Sabot
ECE 4605
28 November 2006

2. Introduction
We have discussed many different protocols but none of them are in use
How to transition to next generation of protocols?
Use overlay networks as a transition device

3. Background and Motivation
Revolution vs. Evolution
ISPs are reluctant to upgrade to new protocols due to the expense
ISP support for IPv6, IP Multicast, IntServ, etc. is almost nonexistent
Two sides to this argument and the use of Overlay networks
Revolution vs. Evolution of the Internet:
Says incumbent ISPs will never change
Revolution calls for a new generation of ISP to implement new services that users will switch to and the incumbent ISP will fall as the new ISPs grow
Creates Repeated market/internet destabilization but allows fro greater changes
Says incumbent ISPs will change when given the right incentives
Evolution calls for gradual change to provide additional service. More limited in nature though.
Much more limited in scope and speed.
Evolvable meaning cabable of gradual (but unlimited) change within the current market structure

4. The Problem “When a new version
of IP, call it IPvN, becomes standardized or otherwise defined, what conditions would lead ISPs to deploy it?”
Answer: Encourage Competition
Foster independent innovation
Enable customer choice
Allow ISPs some degree of control
Foster independent innovation – an ISP should not be able to block innovation by others
Enable customer choice – ISPs will then have to compete for customers
Allow ISPs some degree of control – if ISPs have no control, then they cannot recoup their expenses and are unlikely to deploy

5. The Assumptions The following assumptions are made by the authors:
Assume partial ISP deployment
Assume partial ISP participation
Assume the existing market structure and contractual agreements
Assume revenue flow
Assume partial ISP deployment
ISPs may only test deploy the new service.
Assume partial ISP participation
That some ISP will be to try and deploy IPvN if there is a possibility of some benefit
Assume the existing market structure and contractual agreements
No need to switch to a new ISP to use these services
Assume revenue flow
ISP will have a way to make money by attracting usage

6. Universal Access Key Tenet: Require Universal Access
The most important technical requirement
Key to encouraging competition
Allows anyone to use the service
Requires the use of Redirection
ISPs cannot block access to the service

7. Redirection
How can someone use this new protocol without full ISP support?
Application-Level
Use a lookup service
Who would run and control this?
Network-Level
Every router would need to know where forward the IPvN packet

8. Key Term Definitions IPv(N-1) IPvN Anycast Address IP Anycast vN-Bone
Outdated IP version used (think IPv4)
IPvN
Improved version of IP used (think IPv6)
Anycast Address
Generic predefined address for a specific service
IP Anycast
Broadcast protocol at the IP level using anycast addressing
vN-Bone
Overlay network consisting of only IPvN routers

9. IP Anycast Like a broadcast protocol: Two key reasons:
A packet is transmitted with an anycast address, and the network is responsible for getting it to the closest router that works in the same version of IP as that address
Two key reasons:
Abstraction on this level allows seamless spread of deployment
ISPs can independently configure and control the routing process without adverse effect

10. Anycast Routing Intra-Domain
Current routing algorithms are amenable to anycast, but require large-scale reconfiguration
Proposed method: explicitly broadcast anycast addresses
Easy discovery of other IPvN routers
Smaller-scale reconfiguration

11. Anycast Routing Inter-Domain Option 1: Non-aggregatable addresses
Use a block of addresses for anycast addresses
Relies on ISP cooperation
Option 2: Aggregatable addresses
Domain-assigned anycast addresses
Routing tables need not support IPvN
Will not necessarily choose the closest router
Proposed: Option 2 w/o “special” addresses
Anycast addresses assigned homogenously
Or higher-level enforcement
Default routing tables

12. vN-Bone Formation
Overlay network of IPvN routers that also deploys IPv(N-1)
Composed of
Virtual topology
Routing over virtual network

13. Forwarding
Source S encapsulates the IPvN packet in an IPv(N-1) header

14. Forwarding
Using anycast, the packet is forwarded over legacy IPv(N-1) routers to closest IPvN router

15. Forwarding
Router strips IPv(N-1) header, processes packet, checks next hop in vN-Bone forwarding tables, and re-encapsulates the packet in a new IPv(N-1) packet if necessary

16. Related Work IPv6 Bone based networks (MBone, XBone) Active Networks
How do you ease the deployment of IPv6?
Lack of ISP motivation in deployment
Bone based networks (MBone, XBone)
Similar in idea but not in practice
Active Networks
Recognized the need to innovation in network structure
End host control vs. ISP control

17. Critique
Supposed to be capable of unlimited evolution – what about the increasing use of mobile and wireless technology?
When do you get rid of the old services?
Vast resources used, inefficient
Should have covered the phasing out of old systems
The authors needs to define how IPvN is “better”

18. Summary and Conclusions
ISPs need a reason to deploy new services so give them one
Use IP Anycast and Overlay Networks to transition to new services
Questions?