Towards an Evolvable Internet

8/3/2019 Towards an Evolvable Internet

http://slidepdf.com/reader/full/towards-an-evolvable-internet 1/32

towards an evolvable

internet architecture

AUEB MSc Computer ScienceInformation 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, becomesstandardized or otherwise defined, what conditions would lead ISPs to deploy it?”

this question is primarily one of incentives andmechanisms 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 andcontractual 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 (applicationdemand and service demand)

– balances between the competing needs of userschoice and ISP control

redirection – not application specific, nor manual configuration

– two main approaches (application-level and network-level)



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 IPvNrouter

• it works within the current market structure



routing schemes

unicast

multicast anycast

broadcast



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 addressAN

•any IPvN router acceptspackets destined to AN

• any endhost canencapsulate an IPvNpacket into an IPv(N-1)

packet with destination AN

• anycast ensures thispacket will be delivered tothe closest IPvN router



anycast advantages

reasons of anycast choice

• seamless spread of deployment because of anycastaddress abstraction

• highly decentralized control structure of IP routingbecause 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 gatedeployment

•

control is decentralized and shared across ISPs



intra-domain anycast routing

• distance-vector

– requires that an IPvN router advertises a distance zero to itsanycast 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 toits anycast address (in order to avoid topologymisinterpretations, 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 addressspace and require that ISPs propagate routeadvertisements 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




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




option 2 (continued)

• additionally non-defaultISPs can peer withneighboring domain toadvertise their anycast

route• similar to option 1 but with

optional and independentparticipation of ISPs

•

a disadvantage is that thedefault ISP receives a largerthan normal IPvN traffic

• this option is adopted forthe 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 couldbe 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 IPvNrouters within its domain

– every IPvN router picks its k nearest IPvN routers

• inter-domain

–

ISPs will set-up inter domain tunnels based on their peeringpolicies 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 addressusing a special address bit and his uniqueIPv(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 appropriateingress router is resolved bythe use of anycast forredirection

• the main question is thefinding of an egress IPvN routerif the endhost’s ISP doesn’tsupport IPvN

• destination’s IPv(N-1) addresscould be

– inferred from its temporary IPvNaddress

– carried in a separate option fieldin the IPvN header




• 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 borderrouters




advertise by proxy (BGPvN rule)

an IPvN border router advertisesan IPv(N-1) destination prefix if it is the only IPvN domain alongthe BGPv(N-1) path from itself tothe destination domain

the IPvN border router adds a list toits advertisement of additionalIPv(N-1) domains for which itserves 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 host’s IPv(N-

1) address or the header should allow thatinformation 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 R13. R1 strips off the IPv(N-1) header, processes the packet as

needed, looks up the next hop (R2) to the destinationusing the vN-Bone forwarding tables, and forwards thepacket to R2, once again encapsulating the packet in an

IPv(N-1) header if required4. this is repeated until the packet reaches the engress IPvN

router which tunnels the packet through to thedestination



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

Bone 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 theendhosts 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 S’s 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 architecturaltransitions 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 widespreadsupport for anycast service

• no per client state within network

• no assistance to architectures that requiresupport from every router along the path

• it is unclear if the potential routing

inefficiencies (early stages) due to anycastmight diminish the usefulness of certain IPvNarchitectures

Documents

Towards an Evolvable Internet