towards an evolvable internet architecture

AUEB MSc Computer Science Information Centric Networks Panagiotidis Ionathan Giannis

introduction
internet evolution
at first optimism now deep pessimism

ISPs have little incentives

no competitive advantage immense deploying cost

the need for evolution is more apparent than ever

two main community reactions

1. augment internet architecture through overlay networks
pros: mask some deficiencies cons: no radical changes in architecture

2. overlays to undermine current ISPs

pros: deployment of radical architectures cons: revolution, not evolution

their approach
when a new version of IP, call it IPvN, becomes standardized or otherwise defined, what conditions would lead ISPs to deploy it?
this question is primarily one of incentives and mechanisms needed to support them encourage competition by: advantage to early adopting ISPs foster independent innovation enable customer choice allow ISPs some degree of control

assumptions of internet evolvability

a1. assume partial ISP deployment a2. assume partial ISP participation a3. assume existing market structure and contractual agreements a4. assume revenue flow

technical requirements
universal access
no ISP can block use of IPvN (fosters innovation) customer choice positive feedback cycle for evolution (application demand and service demand) balances between the competing needs of users choice and ISP control

redirection
not application specific, nor manual configuration two main approaches (application-level and networklevel)

redirection approaches
application level redirection lookup service for finding nearby IPvN routers who runs this lookup service?
ISPs themselves
no incentive for no participating ISPs interferes with universal access requirement

third party brokers

alters the current state of the market dependent on ISPs for information

network level redirection every router can forward an IPvN packet to an IPvN router it works within the current market structure

routing schemes

unicast

broadcast

multicast

anycast

anycast today
routes anycast addresses using the unicast protocols no scalable design (routing tables grow proportionally to the number of all global anycast groups) it is used in DNS configuration, server selection

IP anycast as network level redirector

how it works there is a well known IPv(N-1) anycast address AN any IPvN router accepts packets destined to AN any endhost can encapsulate an IPvN packet into an IPv(N-1) packet with destination AN anycast ensures this packet will be delivered to the closest IPvN router

anycast advantages
reasons of anycast choice seamless spread of deployment because of anycast address abstraction highly decentralized control structure of IP routing because of the reuse of the existing unicast infrastructure incentives and technical requirement addressed universal access is achieved under partial deployment the existing ISP control structure is preserved operation is not dependent on all ISPs participating through peering policies ISPs can control but not gate deployment control is decentralized and shared across ISPs

intra-domain anycast routing

distance-vector
requires that an IPvN router advertises a distance zero to its anycast address an IPvN router cannot easily identify other IPvN routers (a slight modification is needed)

link-state
requires that an IPvN router advertises a high cost distance to its anycast address (in order to avoid topology misinterpretations, example in the next slide) an IPvN router can easily identify other IPvN routers

an alternative
each IPvN router advertises its anycast address applies to both distance-vector and link-state algoriths requires small modifications to existing intra domain algorithms

link-state topology misinterpretation

inter-domain anycast routing option 1

designate a portion of the regular unicast address space and require that ISPs propagate route advertisements in their inter-domain routing protocols this approach is implementable even today change in policy not mechanism lacks scalability, however scalability is unlikely to be a concern requirement for anycast routes propagation from all ISPs

inter-domain anycast routing option 2

anycast addresses allocated from the unicast space of a default ISP the default ISP advertises the anycast address ISPs that adopt IPvN also set their IPvN routers to advertise internally the anycast address standard unicast routing will deliver anycast packets to closest IPvN router along the path from the source to the default ISP

inter-domain anycast routing option 2 (continued)

additionally non-default ISPs can peer with neighboring domain to advertise their anycast route similar to option 1 but with optional and independent participation of ISPs a disadvantage is that the default ISP receives a larger than normal IPvN traffic this option is adopted for the rest of the discussion

vN-Bone formation
vN-Bones are implemented entirely by participant ISPs virtual networks that span multiple ISPs are not new many other techniques from the bibliography could be adopted two main components to a virtual network virtual topology construction routing over the virtual network

topology construction
constructed mainly from the connectivity information revealed by the underlying IPv(N-1) routing protocols intra-domain
every IPvN router has complete knowledge of the set of IPvN routers within its domain every IPvN router picks its k nearest IPvN routers

inter-domain
ISPs will set-up inter domain tunnels based on their peering policies with other ISPs a newly joined ISP could use the anycast mechanism as bootstrap

routing vN-Bones
addressing three aspects
format of structured addresses address allocation advertising addresses into the routing fabric

if endhosts ISP doesnt support IPvN then he could assign to himself a temporary address using a special address bit and his unique IPv(N-1) address

routing vN-Bones
two levels
routing between IPvN routers on the vN-Bone routing between any two IPvN endhosts

routing between IPvN routers establishing routes between IPvN routers is achieved by IPvN routing protocols and will thus depend on the specifics of a particular IPvN

routing between endhosts

the finding of an appropriate ingress router is resolved by the use of anycast for redirection the main question is the finding of an egress IPvN router if the endhosts ISP doesnt support IPvN destinations IPv(N-1) address could be
inferred from its temporary IPvN address carried in a separate option field in the IPvN header

routing between endhosts

IPvN border routers must be aware of the

IPv(N-1) domain-level path between current ISP and targets ISP IPv(N-1) domain associated with the different IPvN border routers

routing between endhosts

advertise by proxy (BGPvN rule) an IPvN border router advertises an IPv(N-1) destination prefix if it is the only IPvN domain along the BGPv(N-1) path from itself to the destination domain the IPvN border router adds a list to its advertisement of additional IPv(N-1) domains for which it serves as proxy

summary of design requirements

1. hosts must be able to create temporary and unique IPvN addresses 2. a temporary address should reveal the hosts IPv(N1) address or the header should allow that information to be carried 3. IPvN routers should be able to annotate their route advertisements with IPv(N-1) topology information

forwarding
steps 1. the source encapsulates the IPvN packet in an IPv(N-1) header with destination AN 2. using anycast the packet is forwarded over legacy IPv(N-1) routers to the closest IPvN router R1 3. R1 strips off the IPv(N-1) header, processes the packet as needed, looks up the next hop (R2) to the destination using the vN-Bone forwarding tables, and forwards the packet to R2, once again encapsulating the packet in an IPv(N-1) header if required 4. this is repeated until the packet reaches the engress IPvN router which tunnels the packet through to the destination

IPvN routers
requirements
participate in the IPv(N-1) unicast and anycast routing algorithms perform IPv(N-1) forwarding participate in the construction of the virtual vNBone network participate in IPvN unicast and anycast routing perform IPvN routing

source specific multicast

restricted form of the any source multicast one to many packet delivery between a designated source and zero or more receivers steps
through IGMP a designated router (DR) on a local network tracks group membership and participates in the wide area multicast routing on hehalf of the endhosts on its network PIM-SSM is then used to construct a tree rooted at the source to all receivers DRs

source specific multicast

(S,G) a multicast group called
a multicast group address (G) the unicast address (S) of the source

joining a channel:
a join message being routed toward S setting up routing state for the new receiver at every point along the path until the join message hits a router on the distribution tree

deploying source specific multicast

client C checks if its ISP supports IPvM client C transmits a join message (packet P1)

anycast routing delivers this PIM JOIN message to R1 R1 adds (G,S,C) to its multicast forwarding table.
If R1 already on delivery tree then join is finished If not then unicasts P2 to R2

deploying source specific multicast

the above is repeated until the packet hits an IPvM router already on the distribution tree for (G, S), or the egress IPvM router Rn who unicast packet P3 to S

to multicast to group G, S transmits a data packet to group G. The packet is picked up by Ss DR and forwarded through the (S, G) tree

discussion on related work

does not search for an ideal next generation architecture, instead it focus on how one architecture might transition between architectures evolvability in the sense of repeated architectural transitions and the economic and technical issues it raises not a succession of revolutions but a gradual process le by incumbent ISPs incented to evolve main contribution in relating technical mechanisms to the question of incentives

discussion on the framework

one big requirement: at least widespread support for anycast service no per client state within network no assistance to architectures that require support from every router along the path it is unclear if the potential routing inefficiencies (early stages) due to anycast might diminish the usefulness of certain IPvN architectures