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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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”

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?