towards an evolvable internet architecture

AUEB MSc Computer Science Information Centric Networks Panagiotidis Ionathan Giannis

• 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

becomes standardized or otherwise defined.their approach “when a new version of IP. call it IPvN. 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 revenue flow . assume partial ISP deployment a2. assume existing market structure and contractual agreements a4. assume partial ISP participation a3.

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 .

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 .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.

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 endhost’s ISP doesn’t 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 endhost’s ISP doesn’t support IPvN • destination’s 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 target’s 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 .

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

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

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 .

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 .source specific multicast • (S.

C) to its multicast forwarding table.S.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. – If R1 already on delivery tree then join is finished – If not then unicasts P2 to R2 .

The packet is picked up by S’s DR and forwarded through the (S. S). or the egress IPvM router Rn who unicast packet P3 to S • to multicast to group G.deploying source specific multicast • the above is repeated until the packet hits an IPvM router already on the distribution tree for (G. S transmits a data packet to group G. G) tree .

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 related work • does not search for an ideal next generation architecture.

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 .