Future Internet Architecture

Future Internet ArchitectureFuture Internet Architecture

CSC/ECE 573, Section 001

Fall 2012

Recent Trend in Internet ResearchRecent Trend in Internet Research “Internet architecture was last visited 40 years ago” Does not necessarily mean it is broken

– In fact it is spectacularly not broken

BUT:– Simplicity– Unified view– Evolvability– Maintainability

NSF-sposored FIND and FIA programs– Quick (partial) tour of some FIND and FIA projects– (Apologies to concerned people for mangling)

Other initiatives elsewhere, e.g. FIRE in Europe

VirtualizationVirtualization Diversified Internet Architecture

– Jon Turner, Patrick Crowley, Sergey Gorinsky, John Lockwood

– Enable diverse metanetworks within common substrate

Objectives– enable diverse metanetworks to co-exist– allow introduction of new network architectures at

any time– stimulate development of applications

Bulk-Data TransferBulk-Data Transfer Within Virtualization

– Sergey Gorinsky

Bottomline - ideal transport layer for bulk-data application is different from established wisdom in transport layer, and cannot be obtained by simple tweaks of current transport layers

Service ArchitecturesService Architectures Services Architectures –Network Intermediaries

and End-to-end Abstractions– Dan Duchamp, Tilman Wolf

Session Layer Management of Network Intermediaries - Dan Duchamp– Bottomline - transport layer connections should be

long-lived, virtual connections, and application flows should be managed as session layer contexts

Foreseen Philosophical Problems Unambitious: just what we don’t need—

another hack to the socket/TCP/IP model Network is still pretty dumb: should know

more about session semantics? If L5 handles end-to-end delivery

semantics, what does L4 do?

Relation to FIND/GENI Yes, it’s true—L5 is just a tweak, not a

new architecture But: gives a concrete base for experiments

with certain architectural issues:What is a service? Where is it implemented?

Who really provides it—network or host?State managementSemantics/protocol for control signaling

between end system & intermediaryMapping of function to layers

Questions What services should the network provide? Should the network offer service at the application level

rather than at the datagram level? Should anybody be allowed to provide services or not

(and thus reduce potential for spam, phishing, spyware, etc.)?

Will ease/speed of new service deployment be as important in the future as it has been in the past? Will the rate increase or decrease?

Questions (cont.) Capitalists would like to know: how should

accounting/billing work? Should we construct a network that could, for example,

bill per page view? Socialists would like to know: how can "undesirable

uses" of the Internet be limited? What is the appropriate position for network architects to

take regarding the design of censor-able, tap-able, spy-able Internet?

What is the right technical tradeoff point between (1) a "civilized" appropriately-governable Internet, and (2) an Internet permitted "free expression"?

End-Middle-EndEnd-Middle-End End-Middle-End, EME IRTF Research group

– Paul Francis Essential idea: E2E model pushes all policy, access,

etc. to the edges, but this is not practical. Sometimes you just have to put some processing in the middle

Need an architecture that allows all stakeholders in a connection to:

– Know what is going on– Assert their policies: Access control, Steering, Security,

Transport

Secure RoutingSecure Routing Threats and lessons

– Z Morley Mao

New routing services could enable network security services

Q & A• Questions to consider

– What role should routing play to mitigate against data-plane attacks?

– How should data plane filtering be better integrated with control plane filtering (packet filters with route filters)?

– What is the role of management plane for routing and data-plane?

– How do we enforce networks to practice good network configurations?

Source Controlled RoutesSource Controlled Routes Security implications of source routing etc.

– Xiowei Yang

Secure routing depends on source routes– But security is the #1 reason to disable source routes– How we can reconcile these two

Conclusion

The desirable goals Byzantine-tolerant, accountability, availability, economic incentives,

overhead, QoS, manageability… The right balance of control and exposure

Source-controlled routing Source routing option in IPv4 or Routing header in IPv6

Deflect without Knowing thepaths

Choose pathsknowing entities on the paths

Explicitly list the routersNocontrol

Market-Enabling ArchitectureMarket-Enabling Architecture John Musacchio, Jean Walrand, Venkat

Ananthram, Galina Schwartz, Shyam Parekh– User should be offered choice between network

services and informed of benefits, then the market can play itself out

– Security could be achieved by “security insurance” provided by Certification Agency

Service Choice

Users offered real-time choice: “red” and “blue”– “Red” and “blue” not specified to users in detail

– ISP incentivized to improve along dimensions that matter

– Unlike ATM, IntServ, DiffServ, service definitions not standardized

John Musacchio

Internet Today – Security Inadequacy

Users do not bear full cost of poor computer maintenance

Drivers do not bear full cost of reckless driving.

Liability insurance incentivizes drivers to be careful.

ANALOGY

John Musacchio

Zzzz

Markets for Security

Example:– Users pay to be certified by a Certification Agency (CA)

– CA takes on liability for attacks traced back to user

– CA incentivized to encourage users to take due care

$

Zzzz

John Musacchio

OS UpdateAntivirus Update

User Controlled RoutesUser Controlled Routes Economic implications, this time

– Xiaowei Yang

User choice in routing stimulates competition and competition fosters innovation– User choice may preserve the competitiveness in the

backbone market, and reward innovative providers

Effectively, similar to Market-Enabling Architecture proposal

Contract SwitchingContract Switching A “paradigm shift” from packet-switching

– Aparna Gupta, Shivkumar Kalyanaraman, Murat Yuksel

Contracts formed, create labels– Incentives compared at switching points– Appropriately switched

Effectively, virtual ckt-switching with attached financial / economic information– (caveat: over-simplification?)

Also, provide user with techno-economic choice– In this case, also providers

Postcards from the EdgePostcards from the Edge Roy Yates, Dipankar Raychaudhuri, Sanjoy

Paul, James Kurose Cache-and-forward

– Reliable hop-by-hop transport of large files– Push-pull architecture for opportunistic delivery of

files both to and from the wired network– Enhanced naming to provide location information for

mobile terminals– Distributed caching of popular content to make peer-

to-peer file sharing a first-class service and to enable efficient reliable multicast.

Architectural Support for Selectively-Architectural Support for Selectively-Connected End SystemsConnected End Systems Mark Allman, Vern Paxson, Ken Christensen,

Bruce Nordman Enable an energy-efficient future Internet Baked-in assumption of always-on

– Fate sharing– Soft-state– E2E

Study how architecture should change for real current devices– Proxy, “limbo”, assistant

Economic ViabilityEconomic Viability On the Economic Viability of Network

Architectures– Roch Guerin, Kartik Hosanagar, Andrew Odlyzko,

Zhi-Li Zhang Focus: what will happen to the Internet and its

economics while clean-slate architectures are being deployed? Assess chances of success, economic impact of various architectures

Background and Motivation• We are embarking in far-reaching explorations of new

technology alternatives for tomorrow’s Internet– But clean-slate does not mean “green field”

• There is a behemoth of an incumbent to deal with, and it’s far from standing still

• The eventual relevance and success of new alternatives is not just a function of technical superiority– Economic aspects are likely to be equally, if not more important

• What can we do to explore the economic viability of emerging “Next Generation Internet” alternatives?

24

Project Scope• Three main thrust areas for assessing the economic viability of

new network architectures1. Investigate and quantify the potential benefits of key proposed

architectural features– Virtualization, integration, diversity

2. Explore when and why the existence of a formidable incumbent can affect the emergence of new technologies

3. Develop models that account for how the openness and flexibility of an architecture can foster the adoption of new technology, and its ultimate success

25

SILO: A Reconstructed Protocol SILO: A Reconstructed Protocol StackStack

TransportTransport

NetworkNetwork

Data LinkData Link

PhysicalPhysical

Physical Channels

App App App

TransportTransport

Tuningstrategies,

hints

App App App

Physical Channels

m11m11

m31m31

m21m21

m42m42

m62m62

m11m11 m13

m13

m21m21 m21

m21

m31m31 m31

m31

m43m43

m62m62 m61

m61

Cross-ServiceTuning

silo &servicemgmt

ComposabilityConstraints

Presentation to NSF Oct 07 by SILO Team 27

A Big PictureA Big PictureStratified Network - Graded Entry

Composable Service with Control Interface

Need-basedper-flow stacks

Smooth integration of evolving security

Generic Authentication

Portable Configuration

Redundant Path Delivery

??? (Future Service)

“Transport in layers, control and secure across layers”

Con

trol

Age

nt

Single Point of Policy and Certification

Things Not Discussed Much

• Billing & accountability:– Future network could have forms of billing that tie

fine-grained user actions to $$• E.g., QoS, services accessed

– This will necessarily drive notions of identity, accountability

– DoS becomes $$ from end sources

– Is there anything we can assume (or anti-assume) in this regard?

Things Not Discussed Much, con’t

• DRM:– Inevitable this will spill over into the network?

– Implications for content inspection, caching?

• Infrastructure threats beyond DoS:– Theft-of-service, theft-of-customer


• For new services, how to validate/audit that it’s fully/correctly provided?– …. in the presence of adversaries

• For both this and forms of network inspection, how to conduct these– At varying semantic levels

– With non-global knowledge?


• Interdependence between security and management– What sort of security can management services

themselves draw upon …

– … given that they have to work when things (including security mechanisms) are broken?


• What about leveraging mutual aid and the fact that there are many more benign actual users than malicious ones?– E.g., collaborative filtering, aggregated/shared

analysis– E.g., mechanisms for our friends / social networks to

help us in times of overload or uncertainty

– “In the real world, selective trust is what makes society work”

Things That Gave Me Pause

• Some assumptions that security issues could be addressed external to an effort– True: for pinpoint crypto ~ securing a session– False: for system properties / vulnerabilities– How do we best address this division?

• Distributed algorithms for which– Adversarial inputs not under consideration

• These differ from failures / misconfigurations

– Or assumed readily thwarted (e.g., crypto)

Things We Should Work Out Soon

• Identity building blocks

• Assumptions about trusted hardware

• Maybe: role of billing / accountability

• Capture:– Spectrum of properties being assumed

– Spectrum of properties being provided

– And for these, what “buy-in” costs / assumptions do they entail?

Summary• 1.5 day Meeting at WINLAB, Rutgers University, May 29-30

• 5 groups: 3 FIND projects and 2 external groups with projects in related space– Transient Network Architecture (TNA) -- CNRI/UNM: Henry Jerez– Day After Network (DAN) --- UIUC: Robin Kravets– Postcards from the Edge: A Cache and Forward Architecture – Rutgers & UMASS: Roy Yates,

Sanjoy Paul, Dipankar Raychoudhuri and Jim Kurose– SPINDLE/DTN – BBN: Rajesh Krishnan– Ambient Networks – EU (Ericsson): Lars Lundgren

• Goal: explore synergies, identify gaps, define a comprehensive project in the area

• Agenda:– 20-30 min talk from each of the 5 groups– Look for Similarities and Synergies– Use of GENI: What kind of experimental facility (say in GENI) be most valuable to instantiate

the specific research project – Identify open issues/"holes"

• Summary of results to be presented at FIND meeting

• Detailed agenda, slides, etc. posted at:– http://gaia.cs.umass.edu/rutgers_FIND_meeting

FIND

http://gaia.cs.umass.edu/rutgers_FIND_meeting

ChoiceNet Architecture

Introspection

End-system

Setup

End-system

Setup

Alternatives

Path alternatives

control

In-network services control

Protocol alternatives

control

Payment verification

Manage-ment

MarketplaceService negotiation /

paymentTrust/

reputationEconomy

plane

Con

trol

pla

neD

ata

plan

e

Alternatives for protocol

stacks, paths, and in-network services

Router

Router

Router w/ service

Router

Router

Router

Router

Router w/ service

AdvertisementAlternative selection

Service proofs

Use plane

Composed service offerings

EncourageAlternativesEncourage

Alternatives

Know WhatHappened

Know WhatHappened

Vote withYour WalletVote with

Your Wallet

Measurement plane relevant for wireless Richer measurement in network than typical netw. management Network itself can be sensor for CPS Location, timestamp enriched, correlated information All become more difficult, yet more necessary, for networks with large number of moving nodes

Envisions new fundamental high-level entities and interactions “Economy Plane” to allow alternative representation at all levels Direct to consumer: funnel reward to each actual provider Coarse grain: service/transport/path choices Fine grain: modulation / transcoding algorithm choices innovation “Use Plane” for actually using/running purchased service “Measurement Plane” creating third-party verification opportunities

MobilityFirst Summary May 2011

INTERNET INTERNET

MobilityFirst Vision: Mobility as the key driver for the future Internet

Historic shift from PC’s to mobile computing and embedded devices… ~4 B cell phones vs. ~1B Internet-connected PC’s in 2010 Mobile data growing exponentially – Cisco white paper predicts >1exabyte

per month (surpassing wired PC traffic) by 2012 Sensor deployment just starting, ~5-10B units by 2020

WirelessEdge Network


INTERNET INTERNET

~1B server/PC’s, ~700M smart phones

~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors

~2010~2020




MobilityFirst : High-Level Design Goals

Mobility-centric design Migration of 10B network-attached objects (devices, content, users, …) Robustness in presence of channel impairments & disconnections Support for network mobility & dynamic network-of-networks formation Socket API’s designed explicitly for mobility use cases: multicast, anycast,

context- or location-aware delivery, etc. (…service innovation at the edge) Strong security and privacy

Standard security services (authentication, secrecy, confidentiality, non-repudiation, ..) built into architecture

Resistance to common IP network attacks, e.g. address hijacking, DDoS, .. Network protocols designed to be resilient against failures/attacks No single root of trust, flexible trust domains/mechanisms

No per-flow state, low control overhead No signaling, reduced end-to-end chatter (back to packet switching basics..)


MobilityFirst Summary: Protocol Highlights

Separation of naming and addressing Clear distinction between identify of network-attached endpoint and net addr Name (GUID) = “self-certifying” public key; address = flat NA

Multiplicity of name assignment and trust management services – encourages specialization & competition High-level services for managing content, context, network trust, etc

Fast global name resolution service (GNRS) Integral part of network protocol, resolves GUID NA in ~100 ms

Hybrid GUID/NA routing with self-defining packets NA routing for fast path; late binding GUID routing for advanced services Multicast/anycast as the norm with unicast as special case

In-network storage and computing options at routers Seamless integration of switching, storage and DTN modes Hop-by-hop (or segment-by-segment) transport vs. end-to-end TCP


Architecture Concepts: Name-Address Separation

Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects

User name, device ID, content, context, AS name, and so on Multiple domain-specific naming services

Global Name Resolution Service for GUID NA mappings Hybrid GUID/NA approach

Both name/address headers in PDU “Fast path” when NA is available GUID resolution, late binding option

Globally Unique Flat Identifier (GUID)

John’s _laptop_1

Sue’s_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

Host NamingService

Network

SensorNamingService

ContentNamingService

Global Name Resolution Service

Network addressNet1.local_ID

Net2.local_ID

ContextNamingService

Taxis in NB


Architecture Concepts: Global Name Resolution Service

Fast Global Name Resolution a central feature of architecture GUID <-> network address & port number (also called “locator”) mappings

Distributed service, possibly hosted directly on routers Fast updates ~50-100 ms to support dynamic mobility Service can scale to ~10B names via P2P/DHT techniques, Moore’s law

AP

Global Name-Address Resolution

Service

Data Plane

Host GUID

Network – NA2

Network – NA1

NA1

Registrationupdate

Mobile nodetrajectory

Initialregistration

Name, Context_ID or Content_ID Network Address

Host GUID

NA2

Decentralixed name servicesHosted by subset of ~100,000+ Gatway routers in network


Architecture Concepts: Storage-Aware Routing (GSTAR)

Storage aware (CNF, generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnection

Routing algorithm adapts seamlessly adapts from switching (good path) to store-and-forward (poor link BW/disconnected)

Storage has benefits for wired networks as well..

Storage Router

Low BW cellular link

MobileDevicetrajectory

High BW WiFi link

TemporaryStorage atRouter

Initial Routing Path

Re-routed pathFor delivery

Sample CNF routing result

PDU


Architecture Concepts: Segmented Transport Segment-by-segment transport between routers with storage,

in contrast to end-to-end TCP used today Unit of transport (PDU) is a content file or max size fragment Hop TP provides improved throughput for time-varying

wireless links, and also helps deal with disconnections Also supports content caching, location services, etc.

Storage Router

Low BW cellular link

Segmented (Hop-by-Hop TP)

Optical Router

(no storage)

PDU

Hop #1 Hop #2

Hop #3

Hop #4TemporarilyStored PDU

BS

GID/Service Hdr

Mux Hdr

Net Address Hdr

Data Frag 1

Data Frag 2

Data Frag n

……

Hop-by-HopTransport

More details ofTP layer fragmentswith addl mux header


Architecture Concepts: Context Aware Delivery Context-aware network services supported by MF architecture

Dynamic mapping of structured context or content label by global name service Context attributes include location, time, person/group, network state Context naming service provides multicast GUID – mapped to NA by GNRS Similar mechanism used to handle named content

MobileDevicetrajectory

Context = geo-coordinates & first_responder

Send (context, data)

Context-basedMulticast delivery

ContextGUID

Global Name Resolution service

ba123341x

ContextNamingService

NA1:P7, NA1:P9, NA2,P21, ..

SummarySummary Many threads of research focusing on

architectural issues– “Architecture” at various levels and granularities

Some common concerns recur– Security, accountability– Economics, non-monopoly, choice– Wireless, mobility– Aggregation, scalability

Consensus on problems that need to be dealt with, if not solutions

Documents

Future Internet Architecture