1. Future Internet Architecture
Dan LI
CS Department, Tsinghua University
Today we’ll talk about Future Internet Architecture.
2018/9/16

2. Today’s Lecture Background Named Data Networking MobilityFirst NEBULA
eXpressive Internet Architecture
First, I will introduce some background about future Internet architecture, then I will introduce four most important future Internet architecture proposals which are funded by US’National Science Fundation (NSF), namely
Named Data Networking (NDN)
MobilityFirst
NEBULA
eXpressive Internet Architecture
2018/9/16

3. Background
The Internet has created unprecedented opportunities for advancing knowledge across the spectrum of human endeavors.
The Internet has created unprecedented opportunities for advancing knowledge across the spectrum of human endeavors. It has evolved from a small scale network of networks to become integral to our lives and vital to the operation of all critical sectors of our society.
2018/9/16

4. Background
However, it is increasingly threatened by the ever-mounting sophistication of security attacks and by the lack of performance reliability of Internet services.
However, it is increasingly threatened by the ever-mounting sophistication of security attacks and by the lack of performance reliability of Internet services.
2018/9/16

5. Background
It is no longer clear that emerging and future needs of our society can be met by the current trajectory to the current Internet
As our reliance on a secure and highly dependable information technology infrastructure continues to increase, it is no longer clear that emerging and future needs of our society can be met by the current trajectory of incremental changes to the current Internet.
2018/9/16

6. FIA Program
Recognizing the need for a secure and highly dependable information technology, National Science Foundation of US (NSF) has formulated the Future Internet Architectures program.
Recognizing the need for a secure and highly dependable information technology infrastructure and building on NSF's on-going investments in network science and engineering, the Directorate for Computer and Information Science and Engineering (CISE) has formulated this program to stimulate innovative and creative research to explore, design, and evaluate trustworthy future Internet architectures.
2018/9/16

7. About NSF
The National Science Foundation (NSF) is an independent federal agency created by American Congress in 1950 which aims at
promoting the progress of science
advancing the national health, prosperity, and welfare
secure the national defense
…….
Here I will give you a brief introduction of NSF.
2018/9/16

8. FIA Program The objective of the FIA program is to
Engage the research community in collaborative, long-range, transformative thinking- unfettered by the constraints of today's networks
Design and experiment with new network architectures and networking concepts that take into consideration the larger social, economic and legal issues that arise from the interplay between the Internet and society.
Now, back to the FIA Program.
The objective is to engage the research community in collaborative, long-range, transformative thinking - unfettered by the constraints of today's networks yet inspired by lessons learned and promising new research ideas - to design and experiment with new network architectures and networking concepts that take into consideration the larger social, economic and legal issues that arise from the interplay between the Internet and society.
2018/9/16

9. 4 Projects
In the summer of 2010, NSF has funded four projects as a part of this program
Named Data Networking (NDN)
MobilityFirst
NEBULA
eXpressive Internet Architecture
In the summer of 2010, NSF has funded four projects as a part of this program, namely
Named Data Networking (NDN)
MobilityFirst
NEBULA
eXpressive Internet Architecture
I will introduce them one by one.
2018/9/16

10. Today’s Lecture Background Named Data Networking MobilityFirst NEBULA
eXpressive Internet Architecture
First, I will introduce NDN.
2018/9/16

11. Basic Information Principal Investigator: Lixia Zhang, UCLA
Collaborating Institutions: Colorado State University, PARC, University of Arizona, University of Illinois/Urbana-Champaign, UC Irvine, University of Memphis, UC San Diego, Washington University, and Yale University
As a start-up, let’s introduce the basic information of the NDN group.
2018/9/16

12. Communication Models Conversation Content Retrieval
Point-to-point, emphasize the e2e paths or channels.
Packets carrying addresses simply flow in the channel.
IP adopts the same communication model as the telephone service, just the solution is different.
Content Retrieval
Request content from network services.
Emphasize on the content of the packet, not the location of the content or the channel.
Both can probably support all possible services, given enough efforts. The question is which one fits application needs better.
Now, let’s touch the spirit of NDN in a step-by-step manner. First, let’s consider the Communication Models of today’s Internet.

13. The Trend Contents matter more Addresses matter less
Web caching
Multicast, video conferencing
Subscription/publication services
Security and privacy
Addresses matter less
Limited in supply.
Some are non-reachable, e.g., private v4, or isolated v6.
More and more are moving.
Quite a few proposals to make network content centric rather than location centric.
The trend is, we care address less and less, but contents more and more.

14. Named Data Networking (NDN)
Previously known as Content Centric Networking (CCN).
Currently in its very early stage, lots of questions, challenges, and research opportunities.
Key idea:
Give each packet a unique name.
Packets are routed and forwarded based on names.
Other ideas:
Routers cache packets
All communication is receiver-driven, ie. Interest precedes Data.
Evidentiary security
Motivated by the aforementioned issues, the NDN group proposes Named Data Networking.

15. Name the data Hierarchical names
To facilitate aggregation, management, and discovery.
Routers understand that there are different components in the name, but do not care about the actual meaning of each component.
Applications manage their naming conventions and discovery mechanisms.
E.g., the scope of a name; generate dynamic content for certain names.
NDN names the data in a hierarchical way to To facilitate aggregation, management, and discovery.
Routers understand that there are different components in the name, but do not care about the actual meaning of each component
Applications manage their naming conventions and discovery mechanisms

16. What about addresses? Addresses are limited to local links
No need for addresses that are globally unique, globally reachable, and abundant in supply.
The new universal interconnection layer is “named data”.
IP eventually becomes a link layer protocol.
In NDN, Addresses are limited to local links.
The new universal interconnection layer is “named data”

17. Receiver-driven data retrieval
Consumer sends an interest carrying the name of the data that it wants to receive.
Routers forwards the interest towards the producer, and remembers the incoming interface of the interest.
The producer sends the data back. The data takes the exact reverse path of the interest to reach the consumer.
Data consumes Interests on the way back.
Routers also cache the data as it arrives.
Consumer sends an interest carrying the name of the data that it wants to receive.
Routers forwards the interest towards the producer, and remembers the incoming interface of the interest.
The producer sends the data back. The data takes the exact reverse path of the interest to reach the consumer.
Data consumes Interests on the way back.
Routers also cache the data as it arrives.

18. NDN node
There are there table in NDN nodes: Content Store (CS), Pending Interest Table (PIT) and FIB. A typical NDN node works as follows:

19. NDN packet processing NDN Retreat May 2011
The packet processing logic of NDN is illustrated by this figure.
NDN Retreat
May 2011

20. Interest Forwarding NDN doesn’t loop.
Each Interest has a random number, nonce, to prevent looping.
Data follows Interest’s trail, so Data doesn’t loop either.
Thus NDN can use multiple paths better than IP.
the extreme is to flood an interest, and data will come back. IP would have to flood the data too.
Lots of choices in where to forward a particular interest: the forwarding strategy.
More details and evaluation later.
There is no loop in NDN. Each Interest has a random number, nonce, to prevent looping. Data follows Interest’s trail, so Data doesn’t loop either.
Thus NDN can use multiple paths better than IP. the extreme is to flood an interest, and data will come back. IP would have to flood the data too.
Lots of choices in where to forward a particular interest: the forwarding strategy.
We will see more details and evaluation later.

21. Routing
Server apps register their name prefixes with the local router.
Routers announce name prefixes into the routing system.
Conventional routing protocol can be used to compute the paths to each name prefixes.
New routing protocols are also possible.
Routing in NDN is as follows:
Server apps register their name prefixes with the local router.
Routers announce name prefixes into the routing system.
Conventional routing protocol can be used to compute the paths to each name prefixes.
New routing protocols are also possible.

22. Caching
Universal caching by routers helps in several different scenarios
multicast
asynchronous retrieval
Congestion control
Mobility support
How much memory/disk does it take?
Routers already use memory for buffering, but not caching since no way to identify the content.
With named data, change MRU to LRU replacement policy.
Possible add-on services by ISPs: selling extra cache for specific contents.
A major feature of NDN is Universal caching
Universal caching by routers helps in several different scenarios
multicast
asynchronous retrieval
Congestion control
Mobility support
How much memory/disk does it take?
Routers already use memory for buffering, but not caching since no way to identify the content.
With named data, change MRU to LRU replacement policy.
Possible add-on services by ISPs: selling extra cache for specific contents. .

23. Transport No need for flow control In-network congestion control
Interest does that.
In-network congestion control
By controlling the number of pending interests to control the data rate.
Quicker local recovery due to cache. Retx doesn’t have to start all over again from the producer.
No transport protocol in the traditional sense.
The apps need naming convention, name discovery, and maybe end-to-end reliability.
The transport in NDN works as follows:
It does not need for flow control
Interest does that.
It uses in-network congestion control
By controlling the number of pending interests to control the data rate.
Quicker local recovery due to cache. Retx doesn’t have to start all over again from the producer.
There is no transport protocol in the traditional sense.
The apps need naming convention, name discovery, and maybe end-to-end reliability.

24. Robust Packet Delivery
The ultimate goal of routing and forwarding is to deliver packets.
The ideal is what Paul Baran called “perfect switching”: be able to deliver packets in the presence of faults as long as the destination is still reachable.
We study:
Evaluate NDN vs. IP
Explore some design choices in NDN forwarding strategies.
without considering the benefits and impact of caching (next step)
The ultimate goal of routing and forwarding is to deliver packets.
The ideal is what Paul Baran called “perfect switching”: be able to deliver packets in the presence of faults as long as the destination is still reachable.
Here we study:
Evaluate NDN vs. IP
Explore some design choices in NDN forwarding strategies.
without considering the benefits and impact of caching (next step)
NDN Retreat
May 2011

25. Data Delivery in IP Routing plane computes the best paths
data plane (packet forwarding) simply follows the paths.
Achieving perfect switching requires perfect routing – reality is far from it, e.g.,
Prefix hijack (routing is fooled)
Link failure (routing convergence is slow)
Congestion (routing is not aware of the problem)
we want to convey the point that it is impossible to make a real routing system to match "perfect switching", due to 
- every router (by all different parties) injects input into the system
- there are physical limitations between convergence delay and scalability
NDN Retreat
May 2011

26. Data Delivery in NDN Routing plane stays the same for now
but data plane has state and in charge now.
Monitor the performance.
Detect problems at the data plane quickly
Explore multiple alternative paths
Routing plane is now a helper, i.e., it’s useful but doesn’t have to be perfect.
E.g., prefix hijack, link failure, congestion.
Routing plane stays the same for now
but data plane has state and in charge now.
Monitor the performance.
Detect problems at the data plane quickly
Explore multiple alternative paths
Routing plane is now a helper, i.e., it’s useful but doesn’t have to be perfect.
E.g., prefix hijack, link failure, congestion.
NDN Retreat
May 2011

27. Overview of Forwarding Strategy
Forwarding strategy is to determine which face to use to forward an interest.
Basic process:
Faces are ranked
In general, try higher ranked face(s) first
If data return within a reasonable time, update RTT.
Otherwise, try next face(s).
Different strategies may make different choices.
Ranking is dynamically adjusted.
Details are work in progress.
Forwarding strategy is to determine which face to use to forward an interest.
Basic process:
Faces are ranked
In general, try higher ranked face(s) first
If data return within a reasonable time, update RTT.
Otherwise, try next face(s).
Different strategies may make different choices.
Ranking is dynamically adjusted.
Details are work in progress
NDN Retreat
May 2011

28. Ranking Faces The factors The specific design we simulated
Routing provides the initial and basic information.
Forwarding preference, e.g.,
inter-AS peer relationship, etc.
Performance metrics
Throughput, loss rate, RTT, etc.
The specific design we simulated
Faces are labeled Green (working), Yellow (may work), Red (not working), based on whether data come back.
Within each class, ordered by routing preference.
We rank faces like this:
The factors
Routing provides the initial and basic information.
Forwarding preference, e.g.,
inter-AS peer relationship, etc.
Performance metrics
Throughput, loss rate, RTT, etc.
The specific design we simulated
Faces are labeled Green (working), Yellow (may work), Red (not working), based on whether data come back.
Within each class, ordered by routing preference.
NDN Retreat
May 2011

29. Choosing Faces When no faults, i.e., data return as expected
Use the highest ranked face, but periodically probe other faces by sending interests over.
Or, spread the interests over multiple faces.
When data don’t come back after expected RTT
E.g., hijack, link failure, congestion, etc.
NDN can keep trying different faces without worrying about loops.
What we simulated:
Round-robin based on the ranking
Retransmission plus round-robin
Flooding
Each face also enforce an interest limit
It is available for forwarding only if there’s room for more interests.
We choose faces in the following manner:
When no faults, i.e., data return as expected
Use the highest ranked face, but periodically probe other faces by sending interests over.
Or, spread the interests over multiple faces.
When data don’t come back after expected RTT
E.g., hijack, link failure, congestion, etc.
NDN can keep trying different faces without worrying about loops.
What we simulated:
Round-robin based on the ranking
Retransmission plus round-robin
Flooding
Each face also enforce an interest limit
It is available for forwarding only if there’s room for more interests.
NDN Retreat
May 2011

30. Interest Return
When a node cannot satisfy an interest, it returns the interest to the previous hop
data are ACKs, while returned interests are NACKs.
With error code to indicate the reason
Pro: the downstream node learns the problem quicker and more explicitly.
RTT-based timeout is conservative to avoid false alarms
Con: an extra mechanism
When a node cannot satisfy an interest, it returns the interest to the previous hop
data are ACKs, while returned interests are NACKs.
With error code to indicate the reason
Pro: the downstream node learns the problem quicker and more explicitly.
RTT-based timeout is conservative to avoid false alarms
Con: an extra mechanism
NDN Retreat
May 2011

31. Simulation Setup Simulator Topologies: Abilene and Sprint
Implemented basic NDN forwarding functionality and strategies in QualNet.
Plan to move to ns-3 with full NDN/CCNx functionality.
Topologies: Abilene and Sprint
Routing protocol: OSPF
Scenarios: hijack, link failure, congestion
Comparison: IP vs. NDN
Here I introduce a simulation conducted by the NDN group to evaluation NDN’s performance.
NDN Retreat
May 2011

32. Prefix Hijack (Data Delivery Ratio)
Here is the Data Delivery Ratio under prefix hijack
NDN Retreat
May 2011

33. Prefix Hijack (Data Retrieval Time)
Here is the Data Retrieval Time under prefix hijack
NDN Retreat
May 2011

34. Link Failure (Packet Loss Rate)
And this figure illustrates Packet Loss Rate under link failure.
NDN Retreat
May 2011

35. Congestion Setup Two file downloading sessions: 1-6 and 2-7
RTT (1-6) = 104/106 ms, RTT(2-7) = 202/204 ms.
Buffer size = bw*rtt
To show that NDN is able to use multipath on-demand.
They also setup a congestion environment to To show that NDN is able to use multipath on-demand.
NDN Retreat
May 2011

36. Congestion (Flow Throughput)
Here is Flow Throughput under Congestion.
NDN Retreat
May 2011

37. Congestion (Link Utilization)
And this is Link Utilization under Congestion.
NDN Retreat
May 2011

38. Conclusion and Ongoing Work
Data delivery in NDN is more robust than IP.
able to observe delivery performance and adapt.
Closer look at various design issues, including interest return.
Move simulation to ns-3 and add more functionality.
Further investigation in some scenarios.
e.g., congestion control, DDoS.
Finally we conclude NDN and show some of the ongoing work of the NDN group.
NDN Retreat
May 2011

39. Today’s Lecture Background Named Data Networking MobilityFirst NEBULA
eXpressive Internet Architecture
Next, I will introduce the second FIA project, MobilityFirst.
2018/9/16

40. MobilityFirst Project: Collaborating Institutions
First, let’s see the collaborating institutions
2018/9/16

41. 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 PC’s in 2010
 Mobile data growing exponentially – Cisco white
paper predicts 3.6 Exabytes by 2014, significantly
exceeding wired Internet traffic
 Sensor/IoT/V2V just starting, ~5-10B units by 2020
~2B servers/PC’s, ~10B notebooks, PDA’s,
smart phones, sensors
~1B server/PC’s, ~700M smart phones
Wireles s
Edge
Networ
Historic shift from PC’s to mobile computing and embedded devices
~4 B cell phones vs. ~1B PC’s in 2010
Mobile data growing exponentially – Cisco white paper predicts 3.6 Exabytes by 2014, significantly exceeding wired Internet traffic
Sensor/IoT/V2V just starting, ~5-10B units by 2020
INTERNET k
INTERNET
Wireless
Edge
Network
~2010
~2020
WINLAB

42. Vision: Near-term “mobile Internet” usage
scenario – cellular convergence 
~4-5B new cellular devices in just a few years will drive
convergence of technical standards and business models 
Currently involves 2 sets of addresses (cellular number & IP), 2 sets of
protocols (3GPP and IP), and protocol gateways (GGSN, PDN GW, etc.)
 Scalability, performance and security problems when bridging 2 networks
 Cross-layer interaction between PHY/MAC and TCP/IP impacts performance
 Lack of a single unified standard inhibits mobile Internet app development
across diverse networks and platforms
And for near-term “mobile Internet” usage scenario – cellular convergence:
Currently involves 2 sets of addresses (cellular number & IP), 2 sets of protocols (3GPP and IP), and protocol gateways (GGSN, PDN GW, etc.)
Scalability, performance and security problems when bridging 2 networks
Cross-layer interaction between PHY/MAC and TCP/IP impacts performance
 Lack of a single unified standard inhibits mobile Internet app development
across diverse networks and platforms
INTERNET
Cellular –
Internet GW
Cellular –
Internet GW
MOBILE
INTERNET
Radio Access C
Cellular system B
Cellular system A
Radio Access B
WINLAB
Radio Access Net A
Mobility, Security
Varying Access bW
Heterogeneous radio

43. Vision: Near-term “mobile Internet” usage
scenario – Mobile P2P and Infostations 
P2P and Infostations (DTN-like) modes for content delivery
becoming mainstream 
Heterogeneous access; network may be disconnected at times
 Both terminal & network mobility; dynamic trust  identity vs. address
 Requires content caching and opportunistic data delivery
MOBILE INTERNET
Mobile DTN Router
Opportunistic
Now let’s see Mobile P2P and Infostations
P2P and Infostations (DTN-like) modes for content delivery becoming mainstream
Heterogeneous access; network may be disconnected at times
Both terminal & network mobility; dynamic trust  identity vs. address
Requires content caching and opportunistic data delivery
High-Speed Link
(MB/s)
Ad-Hoc
Network
Mobile DTN User/Router
Disconnection
Opportunistic access
Message ferry/DTN
Content delivery/cache
Roadway Sensors
Infostations
Router
WINLAB
Mobile P2P User

44. Vision: Future “mobile Internet” usage scenarios – vehicular networks
100’s of million cars will be equipped with radios by ~2015  
Both V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) modes
Involves capabilities such as location services, georouting, ad hoc networks
Important new trust (security and privacy) requirements in this scenario
V2I
Irrelevant vehicles
in radio range for few seconds
And for vehicular networks:
100’s of million cars will be equipped with radios by ~2015
Both V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) modes
Involves capabilities such as location services, georouting, ad hoc networks
Important new trust (security and privacy) requirements in this scenario
V2V
Following vehicle,
in radio range for
minutes
Passing vehicle,
in radio range for seconds
Geographic routing/multicast
Dynamic network formation, trust
Location & context services
WINLAB

45. Vision: Emerging “mobile Internet” usage scenarios – pervasive/M2M/IoT
The next generation of Internet applications will involve
interfacing human beings with the physical world 
Wide range of usage scenarios including healthcare, smart grids, etc.
Networking requires awareness of location, content and context
Challenges – content/context services, security and robustness
“Cloud computing” models with in-network processing & storage
Ambient interfaces
“Human in the Loop”
“Cloud” Applications
Global Pervasive Network
(Future Internet)
Computation
And pervasive/M2M/IoT:
The next generation of Internet applications will involve interfacing human beings with the physical world
Wide range of usage scenarios including healthcare, smart grids, etc.
Networking requires awareness of location, content and context
Challenges – content/context services, security and robustness
“Cloud computing” models with in-network processing & storage
To Actuators
Protocol
module
& Storage
Network Connectivity
& Computation
Content & Location
Aware Routers
Context- and content-services
In-network computing options
“cloud” computing models
Vehicles with
Sensors & Wireless
WINLAB
Data
From
Sensors
Healthcare
Application
Virtualized physical
world object
Robotics Application
Smart Grids

46. Protocol Design for the future Mobile/Wireless World
MobilityFirst is a clean-slate architecture that directly addresses these requirements while taking into account technology constraints and Moore’s Law advances
Clean-slate architecture is a research methodology to identify useful protocol innovations – in practice, changes to network will be evolutionary
From the Protocol Design for the future Mobile/Wireless World’s point of view:
MobilityFirst is a clean-slate architecture that directly
addresses these requirements while taking into account
technology constraints and Moore’s Law advances
Clean-slate architecture is a research methodology to identify useful
protocol innovations – in practice, changes to network will be evolutionary
2018/9/16

47. Architecture Summary
After defining the requirements, let’s see the architecture of MobilityFirst

48. Architecture: MobilityFirst Network Overview
MobilityFirst key protocol
features:
Computing Blade
Buffer Storage
Forwarding Engine 
Separation of naming & addressing
Public-key globally unique identifier
(GUID) and flat network address (NA)
Storage-aware (GDTN) routing
MobilityFirst
Router with
Integrated
Computing &
Storage
Hop-by-Hop
Transport 
Multicast, multipath, anycast services
Flexible inter-domain boundaries and
aggregation level
Core Network
(flat label routing)
Base Station
GDTN
Routing
Router 
Early binding/late binding options
Data 
Hop-by-hop (segmented) transport
Data block AP
Plane
MobilityFirst has the following key protocol features
Separation of naming & addressing, Public-key globally unique identifier (GUID) and flat network address (NA), Storage-aware (GDTN) routing, Multicast, multipath, anycast services, Flexible inter-domain boundaries and aggregation level, Early binding/late binding options, Hop-by-hop (segmented) transport, Support for content & context, Strong security and privacy model and Separate mgmt & computing layers
It has Several new protocol components, very distinct from today’s TCP/IP 
Support for content & context
Strong security and privacy model
Separate mgmt & computing layers
Wireless Router
Global Name
Resolution Service
Name <-> PKI
address mapping
Control &
Management Plane 
Several new protocol
components, very distinct from
today’s TCP/IP ….
WINLAB

49. Architecture Concepts: Name-Address Separation
Separation of names (ID) from
Sue’s_mobile_2
network addresses (NA)
Server_1234
Media File_ABC
Taxis in NB 
Globally unique name (GUID)
John’s _laptop_1
for network attached objects 
User name, device ID, content, context,
AS name, and so on
Host
Naming
Service
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
 Multiple domain-specific naming
services
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service 
Global Name Resolution Service
It proposes the concept of Name-Address Separation:
Separation of names (ID) from network addresses (NA)
It uses globally unique name (GUID) for network attached objects
It has global Name Resolution Service for GUID NA mappings
It uses Hybrid GUID/NA approach
for GUID  NA mappings
Network 
Hybrid GUID/NA approach 
Both name/address headers in PDU
 “Fast path” when NA is available
 GUID resolution, late binding option
Net2.local_ID
Network address
Net1.local_ID
WINLAB

50. Architecture Concepts: Global Name Resolution
Service for Dynamic Name <-> Address Binding 
Fast Global Name Resolution a central feature of architecture 
GUID <-> network address (NA) mappings 
Distributed service, possibly hosted directly on routers 
Fast updates ~ ms to support dynamic mobility
 Service can scale to ~10B names via P2P/DHT techniques, Moore’s law
Host GUID
Registration
update
NA2
Network – NA2
Mobile node
trajectory
Data Plane AP
Network – NA1
Let’s see the Global Name Resolution Service for Dynamic Name and Address Binding
Fast Global Name Resolution a central feature of architecture
Distributed service, possibly hosted directly on routers
Initial
registration
Global Name-
Address Resolution
Service
Host GUID
Decentralixed name services
Hosted by subset of ~100,000+
Gatway routers in network
NA1
Host Name, Context_ID or Content_ID
Network Address
WINLAB

51. Protocol Design: Direct Hash GNRS
Fast GNRS implementation based on DHT between routers 
GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID)
 Results in distributed in-network directory with fast access (~100 ms) 1
0.9
0.8
K = 5,
95th Percentile
at 91 ms
Cumulative Distribution Function (CDF)
K = 1,
0.7
95th Percentile
at 202 ms
0.6
0.5
0.4
MobilityFirst developed the technic of Direct Hash GNRS, that is
Fast GNRS implementation based on DHT between routers
GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID)
Results in distributed in-network directory with fast access (~100 ms) 1
0.3
0.2
0.1 K = 1 2 3 4 5 10 20 50
100
1,000
Round Trip Query Latency in milliseconds (log scale)
Internet Scale Simulation Results
Using DIMES database
WINLAB

52. Architecture Concepts: MobilityFirst Routing Design Goals
Routing protocol should seamlessly support a wide range of
usage scenarios, from wired  mobile  ad hoc  DTN 
Device, content and network mobility
 Heterogeneous devices and radio access
 Robustness to varying BW, disconnection
 Dynamic network formation & flexible boundaries
Core 4G
Connectivity
And for its Routing Design Goals:
Routing protocol should seamlessly support a wide range of usage scenarios, from wired to mobile to ad hoc and finallyDTN
Device, content and network mobility
Heterogeneous devices and radio access
Robustness to varying BW, disconnection
Dynamic network formation & flexible boundaries
Wired
Wireless Mesh/ Cellular
MobileAd-Hoc
DTN
WINLAB

53. Architecture Concepts: Exploiting In- Network Storage for Routing
~100MB, data in transit
~10GB, in-network storage
~1TB, content caching
Take advantage of cheap
storage in the network
(storage-aware routing) 
Expands routing options 
Store and/or replicate as
feasible routing options
Generalized Storage-Aware Routing
 Enables “late binding” routing
algorithms
• Actively monitor link qualities of network
• Router store or forward decision based on:
MobilityFirst also exploite In-Network Storage for Routing, which is a little bit like NDN:
Take advantage of cheap storage in the network (storage-aware routing) 1. 2.
Short and long term link qualities
Available storage along path 
Hop-by-hop transport 
Large blocks reliably 3.
Connectivity to destination
transferred at link layer
 Entire block can be stored or
cached at each router

54. Protocol Design: 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/short disconnection) to
DTN (longer disconnections)
Storage has benefits for wired networks as well..
Temporary
Storage at
Router
Initial Routing Path
Low BW
cellular link
Mobile
Device
trajectory
Now let’s see the Storage-Aware Routing in detail
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/short disconnection) to
DTN (longer disconnections)
Storage has benefits for wired networks as well
Re-routed path
For delivery
PDU
Storage
Router
High BW
WiFi link
Sample CNF routing result
WINLAB

55. Protocol Design: 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.
PDU
Segmented (Hop-by-Hop TP)
Hop #3 BS
Hop #1
Hop #2
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.
Hop #4
Temporarily
Stored PDU
Low BW
cellular link
Storage
Router
Optical
Router
(no storage)
Hop-by-Hop
Transport
GID/Service Hdr
Mux Hdr
More details of
TP layer fragments
with addl mux header
Data
Frag 1
Data
Frag 2 ……
Data
Frag n
Net Address Hdr
WINLAB

56. Architecture Concepts: MobilityFirst Interdomain Routing
Requirements include: flexible network boundaries, dynamic
formation, virtual nets, network mobility, DTN mode, support for
path selection, multipath, multi-homing, improved security, etc.
Motivates rethinking of today’s 2-tier IP/BGP architecture (inter-
AS, intranet)
MobilityFirst interdomain approach uses GNRS service +
enhanced path vector routing to achieve design goals – still
evaluating multiple design options….
Let’s talk about the Interdomain Routing of MobilityFirst:
Requirements include: flexible network boundaries, dynamic formation, virtual nets, network mobility, DTN mode, support for path selection, multipath, multi-homing, improved security, etc
Motivates rethinking of today’s 2-tier IP/BGP architecture (inter-AS, intranet)
MobilityFirst interdomain approach uses GNRS service + enhanced path vector routing to achieve design goals – still evaluating multiple design options
Core Net 17
Access Net 200
Path Vector+
Routing Plane Provides reachability
& path info between
networks
GNRS provides
Core Net 23
Routing protocol
Access Net 500
Global GNRS Net name <-> addr
directory mapping
WINLAB
Mobile
Net 1
Mobile
Net 2

57. Protocol Design: MobilityFirst Interdomain Routing
One approach under consideration is to enhance BGP-like
protocols with summary node/link info (“Vnode graph”) 
Summary knowledge of access net properties (Mbps, % avail, etc.), ingress/egress
points and alternate paths exchanged between networks/AS’s
 Network topology information for identifying multiple paths, storage points, etc.
Inspired by “Vnode” concept in “Pathlet” routing (Godfrey, 2008)
Support for multicast, anycast, multihoming and multipath
Edge Network 
V74
V73
Example of dual=homing route
Supported by routing protocol
V71
Transit Network
Now let’s see the Interdomain Routing
One approach under consideration is to enhance BGP-like protocols with summary node/link info (“Vnode graph”)
This is Inspired by “Vnode” concept in “Pathlet” routing (Godfrey, 2008)
It supports for multicast, anycast, multihoming and multipath
V21
V22
V72
V23
Aggregated Vnode
properties & path info
V11
V12
WINLAB
V13

58. Protocol Design: Virtual Routing Domains
Virtual network domains can be created by combining Vnodes
and/or networks into logical aggregates 
Vnodes and networks can form VN’s without having to be physically contiguous –
GNRS provides membership list & trust relationships
 Virtual networks share fine-grain intra-domain routing information & expose multiple
ingress and egress points to the inter-domain protocol
 Can be used to aggregate disjoint wireless access networks (e.g. “NJfreeWiFi”) or set
up a “mobile cloud service” with improved routing visibility; many other uses ….
Virtual Net ABC
Intra-domain
Routing tunnel
Ad Hoc Net
Virtual Routing Domains:
Virtual network domains can be created by combining Vnodes and/or networks into logical aggregates
Vnodes and networks can form VN’s without having to be physically contiguous –GNRS provides membership list & trust relationships
Virtual networks share fine-grain intra-domain routing information & expose multiple ingress and egress points to the inter-domain protocol
Can be used to aggregate disjoint wireless access networks (e.g. “NJfreeWiFi”) or set up a “mobile cloud service” with improved routing visibility; many other uses ….
Vnode 22
Vnode 21
(may be disconnected
at times)
Vnode 11
Net A
Net C
Net B
WINLAB

59. Protocol Design: Content Delivery in MobilityFirst
Content delivery handled efficiently by proposed MF architecture 
“Content objects” identified by unique GUID
 Multiple instances of content file identified by GNRS via GUID to NA mapping
 Routing protocol used for “reverse anycast” to nearest content object 
Approach differs from NDN/CCN, where content attributes are
carried in packet headers
MF uses content GUID naming service & GNRS to keep things
interpreting content semantics inside network
Content
general and avoid Store #2
NA43
GUID=
GUID=
NA99
GUID=
Content cache at mobile
Operator’s network – NA99
NA31
Now let’s investigate Content Delivery in MobilityFirst:
Content delivery handled efficiently by proposed MF architecture
Approach differs from NDN/CCN, where content attributes are carried in packet headers
MF uses content GUID naming service & GNRS to keep things interpreting content semantics inside network
Data fetch from
GNRS query
NA99
GNRS
Query
Returns list:
NA99,31,22,43
NA29
GUID=
NA22
Data fetch from
NA43
Get (content_GUID)
Get (content_GUID)
User mobility
WINLAB
Content Store #1
(owner)

60. Protocol Design: 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 to mechanism used to handle named content
Context = geo-coordinates & first_responder
Send (context, data)
Context
Naming
Service
Global Name
Resolution service
NA1:P7, NA1:P9, NA2,P21, ..
Context-based
Multicast delivery
Context
GUID
ba123
341x
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 to mechanism used to handle named content
Mobile
Device
trajectory
WINLAB

61. Protocol Design: Management Plane
Separate mgmt plane designed into MF architecture 
Provides visibility into key mobile network aspects such as name
resolution, disconnected operation, wireless access quality, context-
aware services, location, privacy, …
Includes mechanism for network-assisted dynamic spectrum
assignment (DSA) as a basic capability
Intended to improve transparency and support add-on mgmt services
Data Plane
Let’s see MobilityFirst’s Management Plane:
MobilityFirst separates mgmt plane designed into MF architecture
Provides visibility into key mobile network aspects such as name resolution, disconnected operation, wireless access quality, context-aware services, location, privacy,
Includes mechanism for network-assisted dynamic spectrum assignment (DSA) as a basic capability
Intended to improve transparency and support add-on mgmt services
Data packets AP
Control &
Net Mgmt
Interface
(performance
Management
Plane
queries,
configuration, faults,
security, ..)
WINLAB

62. Protocol Design: Management Plane (cont.)
Support for dynamic spectrum assignment (DSA) 
Given that the majority of end-user devices are wireless, Internet spectrum
should be assigned on demand
 Management plane mechanism for exchange of spectrum use data
Distributed Spectrum Coordination
Region B
Radio Coverage
Algorithm Software (runs on all radio
devices)
Region C
Region A
Geo-cast Spectrum
Update Service
Mobility First Control
& Management Plane
Continue our discussion of Management Plane
Support for dynamic spectrum assignment (DSA)
Given that the majority of end-user devices are wireless, Internet spectrum should be assigned on demand
Management plane mechanism for exchange of spectrum use data
Region D
Aggregate Spectrum
Updates Between Routers
Spectrum Use Update (from Radios)
Spectrum Occupancy Map (from Routers)
WINLAB AP

63. Protocol Design: Computing Layer
Programmable computing layer provides
service flexibility and evolution/growth path 
Routers include a virtual computing layer to support new network services
 Packets carry service tags and are directed to optional services where applicable
 Programming API for service creation provided as integral part of architecture
 Computing load can be reasonable with per-file (PDU) operations (vs. per packet)
Virtual
Service
Provider
Content
Caching
Privacy
routing
Now let’s see Computing Layer:
In MobilityFIrst, programmable computing layer provides service flexibility and evolution/growth path
Routers include a virtual computing layer to support new network services
Packets carry service tags and are directed to optional services where applicable
Programming API for service creation provided as integral part of architecture
Computing load can be reasonable with per-file (PDU) operations (vs. per packet)
Computing layer
CPU
Storage
Packet forwarding/routing
anony
anony
......
......
WINLAB

64. Protocol Design: Packet Headers and
Forwarding with Hybrid GIUD/NetAddr 
Hybrid scheme in which packet headers contain both the object name (GUID)
and topological address (NA) routing
NA header used for “fast” path, with fallback to GUID resolution where needed
Enables flexibility for multicast, anycast and other late binding services
GUID –based forwarding
Optional list of NA’s
(slow path)
Name-GID Mapping
Name GUID
xy17519bbd -
Destination NA
Source route
Intermediate NA
Partial source route
GID-Address Mapping
GUID NA
xz Net 1194
GID/Service
Header
GUID/Service
Header
NA Header
PDU with GUID
and NA headers
NA Header
GUID/Service
Header
PDU with GUID
Header only
Packet Headers and Forwarding with Hybrid GIUD/NetAddr:
Hybrid scheme in which packet headers contain both the object name (GUID) and topological address (NA) routing
NA header used for “fast” path, with fallback to GUID resolution where needed
Enables flexibility for multicast, anycast and other late binding services
Data Object
(100B-1GB)
GUID Header Components
Routing Table
Dest NA
Net 123
Path
Net11, net2, ..
GUID/Public Key
Hash
SID
(Service
Identifier)
Network Address Based Routing
(fast path)
WINLAB

65. Use Cases: GUID/Address Routing Scenarios – Dual Homing
The combination of GUID and network address helps to support new mobility
related services including multi-homing, anycast, DTN, context, location …
Dual-homing scenario below allows for multiple NA:PA’s per name
DATA
GUID
NA1:PA22; NA7:PA13
Router bifurcates PDU to NA1 & NA7
(no GUID resolution needed)
GUID
DATA
NetAddr= NA1.PA22
Net 1
Alice’s laptop
GUID = xxx
GUID/Address Routing Scenarios – Dual Homing:
The combination of GUID and network address helps to support new mobility related services including multi-homing, anycast, DTN, context, location …
Dual-homing scenario below allows for multiple NA:PA’s per name
Data Plane
Net 7
Dual-homed
mobile device
DATA
DATA
GUID
NetAddr= NA7.PA13
GUID/SID
NA1:PA22; NA7:PA13
DATA
Current network addresses provided by GNRS;
NA1:PA22 ; NA7:PA13
GUID & SID
Send data file to “Alice’s laptop”
WINLAB

66. Use Cases: GUID/Address Routing Scenarios – Handling Disconnection
Intermittent disconnection scenario below uses GUID based redirection (late
binding) by router to new point of attachment
DATA
PDU Stored in router
- GUID resolution for redirection
DAT
GUID
NetAddr= NA1.PA9
- Delivery failure A
GUID
Mobility
Trajectory
Disconnected
Region
Net 1
Net 7
Let’s see how MobilityFirst handles disconnection:
Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment
Data Plane
DATA
GUID
DATA
GUID/SID
Send data file to “Alice’s laptop”
DATA
NetAddr= NA7.PA3
Successful redelivery after connection
WINLAB
NetAddr= NA1.PA7
GUID
Current network address provided by GNRS;
NA1 – network part; PA9 – port address

67. Use Cases: GUID/Address Routing Scenarios – Multicast/Anycast/Geocast
Multicast scenario below also uses GUID <-> Network Address resolution (late-
binding) at a router closer to destination (..GUID tunnel)
DATA
NetAddr=NA1,PA1
GUID
NetAddr=NA1:PA1,PA2,PA9; NA7,PA22
NetAddr=NA1,PA2
Late GUID <-> addr
Port 1
Binding at NA1
Port 2
Net 1
Net 7
Port 22
And how it supports Multicast/Anycast/Geocast:
Multicast scenario below also uses GUID <-> Network Address resolution (late-binding) at a router closer to destination (..GUID tunnel)
DATA
NetAddr=NA7,PA22
GUID
= mcast
group
DATA
GUID/SID
Send data file to “WINLAB students”
NetAddr= NA1
Intermediate network address NA1
provided by GNRS
WINLAB

68. Security Considerations:
Public keys names for hosts & networks; forms basis for 
Ensuring accountability of traffic
Ubiquitous access-control infrastructure
Secure routing; no address hijacking 
Emphasis on achieving robust performance under network
stress or failure 
Byzantine fault tolerance as a goal
Transform malicious attacks into benign failure
Performance observability (in management plane)
Security Considerations:
Public keys names for hosts & networks;
Emphasis on achieving robust performance under network stress or failure
Intentional receipt policies at networks and end-user nodes
No globally trusted root for naming or addressing 
Intentional receipt policies at networks and end-user nodes 
Every MF node can revert to GUID level to check authenticity, add filters, .. 
No globally trusted root for naming or addressing 
Opens naming to innovation to combat naming-related abuses
Removes obstacles to adoption of secure routing protocols
WINLAB

69. Security Considerations: Trust Model
Name assignment
& certification
services (..can
incorporate
various kinds of
Host
Naming
Service X
Network
Naming
Service B
Network
Naming
Service A
Content
Naming
Service Y
Context
Naming
Service Y
Other
Naming
Services
TBD
trust including
CA, group
membership,
reputation, etc
GNRS
GUID = public Key
Secure
Network
Name
Service
Lookup
GUID <-> NA
binding
Secure
Host
Name
Service
Secure
GNRS
Update
NET NA7
Lookup
Secure InterNetwork
Routing Protocol
Here is MobilityFirst’s Trust Model
NET NA1
NET NA33
Aggregate NA166:
NA14, NA88, NA 33
NA 88
NA 14
NA 51
Secure
Data Path
Protocol
NA 99
WINLAB
Public Key object and network names enable us to build secure protocols for each interface shown

70. Privacy Considerations:
Public keys as addresses enable their use as pseudonyms 
Can be changed frequently by end-users to interfere with profiling
 Flat-label PKI addresses provide an additional layer of routing privacy 
Openness in naming & addressing introduces competition
on grounds of privacy 
E.g., enable retrieval of mappings in a privacy-preserving way 
Virtual service provider framework can optionally provide
enhanced support for privacy
Privacy Considerations:
Public keys as addresses enable their use as pseudonyms
Openness in naming & addressing introduces competition on grounds of privacy
Virtual service provider framework can optionally provide enhanced support for privacy
Route transparency and selection supports user choice on privacy grounds
So far we have finished our topic about MobilityFirst. 
E.g., constant-rate traffic between routers to defeat traffic analysis 
Route transparency and selection supports user choice on
privacy grounds
WINLAB

71. Today’s Lecture Background Named Data Networking MobilityFirst NEBULA
eXpressive Internet Architecture
Next, I will introduce the third FIA project, NEBULA.
2018/9/16

72. It has the following collaboration institutions
2018/9/16

73. First, background of Nebular
2018/9/16

74. Here is its motivation
2018/9/16

75. Thus we need a new architecture to efficiently support availability, security and consistency.
2018/9/16

76. Here is Nebular’s architecture and principles
2018/9/16

77. Nebular gives very much attention to network security
2018/9/16

78. 2018/9/16

79. Here let’s have a glance at Nebular’s NDP
2018/9/16

80. Well, let’s see Nebular virtual and extensible network techniques
2018/9/16

81. Nebular’s core
2018/9/16

82. Here is Nebular’s architectural criteria
2018/9/16

83. And finally Nebular’s comprehensive team.
2018/9/16

84. Today’s Lecture Background Named Data Networking MobilityFirst NEBULA
eXpressive Internet Architecture (XIA)
Fianlly, let’s see the last FIA project, eXpressive Internet Architecture (XIA).
2018/9/16

85. XIA: An Architecture for a Trustworthy and Evolvable Internet
2018/9/16

86. Outline
Here is an outline of XIA
2018/9/16

87. Also, background again
2018/9/16

88. And here is XIA’s proposal
2018/9/16

89. And to investigate XIA a bit more detail…
2018/9/16

90. So what about dynamic content?
2018/9/16

91. P1: Evolvable set of principals
2018/9/16

92. P2: Security as Intrinsic as Possible
2018/9/16

93. And here is other XIA principles

94. Each communication operation expresses the intent of the operation
XIA is a single inter-network in which all principals are connected

95. So you may wonder, what application does XIA support?

96. Now let’s answer the question: what do we mean by evolvability.

97. It is claimed by the XIA group that it is not just about architecture.

98. An let’s go a little bit future, to answer the question, what about the real world?
2018/9/16

99. Here is XIA components and interactions
2018/9/16

100. Here is current development process of XIA
2018/9/16

101. Muliple principal types of XIA
2018/9/16

102. Let’s use this figure to illustrate the idea.
2018/9/16

103. Security in XIA is intrinsic
2018/9/16

104. This figure shows the example of secure mobile service access
2018/9/16

105. And how does XIA achieve evolvability?
2018/9/16

106. Generalizing evolvable address format
2018/9/16

107. 2018/9/16 And finally, here is the prototype implementation of XIA.
That’s all for today’s talk, thanks for coming!
2018/9/16