Professor Hongbin Luo Beijing Jiaotong University CoLoR: An Information-Centric Future Internet...

Professor Hongbin Luo

Beijing Jiaotong

University

CoLoR: An Information-Centric Future

Internet Architecture for Innovation

August 11, 2013

CoLoR: An Information-Centric Future Internet Architecture for Innovation2 Beijing Jiaotong University

Roadmap

1 Background

3 Design details

4 Benefits of CoLoR

5 Feasibility Analysis

Conclusions6

2 Design Goals


1. Background

Internet routerrouter

User A User B

router

router

rouer

router

The current Internet has made great success in the past years. However, it also faces many serious issues, such as:Scalabil

ityThe DFZ routing table size grows

rapidly, the internet faces serious routing

scalability issues.

Security

No inherit security mechanism. There are too many security threats.

Mobility

The Internet Cannot efficiently support mobility.

There is a growing consensus that

these drawbacks cannot be remedied by

incremental changes, and a clean-slate

design of the Internet architecture is

desired.


1. Background

Year

Country Program

2005

USA NSF GENI （ Global Environment for Networking Innovations ）

2006

USA NSF FIND （ Future Internet Design ）

2007

Korea FI (Future Internet)

2007

EU FIRE （ Future Internet Research and Experiment)

2008

Germany G-Lab （ National Platform for Future Internet Studies)

2009

EU SAGN (Smart And Green Networks Fund)

2010

USA NSF FIA （ Future Internet Architecture)

2012

EU FP7 FIRE (in Call 8)

2012

USA NSF CNS （ Computer and Network Systems )

2012

White House

US IGNITE

Because of these drawbacks, many countries have founded many projects to investigate future Internet architecture in recent years.


1. Background

In recent years, China has also founded many projects to investigate future Internet architecture, under its well-known 973 program.

year

Project title Lead Organization

2006

Research on Universal Network and Pervasive Service Internet Architecture

Beijing Jiaotong

University

2010

Model and Basic Theories of Information Services

Tongji University

2011

Research on key mechanisms of a service-oriented Future Internet Architecture

Chinese Academy of

Science

2011

Research on the Architecture of the reconfigurable Fundamental Communication network

PLA Information Technology

Univ.

2012

An Information-Centric Future Internet Architecture for Innovation

Beijing Jiaotong

University

The project lasted five years , from Jan. 2007 to

Aug. 2011. In the final examination made by

the Ministry of Science and Technology of China

in Nov. 2011, the project got the top level

score “excellent”.

The project lasted five years , from Jan. 2007 to

Aug. 2011. In the final examination made by

the Ministry of Science and Technology of China

in Nov. 2011, the project got the top level

score “excellent”.

In Chinese: “ 优秀”；In English: “ Excellent”.


1. Background

China has also founded many projects to investigate future Internet architecture, under its well-known 973 program.

year

Project title Lead Organization

2006

Research on Universal Network and Pervasive Service Internet Architecture

Beijing Jiaotong

University

2010

Model and Basic Theories of Information Services

Tongji University

2011

Research on key mechanisms of a service-oriented Future Internet Architecture

Chinese Academy of

Science

2011

Research on the Architecture of the reconfigurable Fundamental Communication network

PLA Information Technology

Univ.

2012

An Information-Centric Future Internet Architecture for Innovation

Beijing Jiaotong

University

The project was renewed in 2012, from Jan. 2013 to Aug. 2017.


2. Design Goals

We aim at designing a future Internet architecture that satisfies the following design goals:

① Being information centric: While the current Internet was designed centered on hosts, its current majority usage is data retrieval. Accordingly, there is an increasing consensus that the future Internet should be information-centric. That is, content should be addressed independent of its hosted location.

② Efficient support for mobility: With the rapid increase in the number of mobile devices, the future Internet architecture should efficiently support mobility.Until March 2013, the number of mobile users in China is 1.146 billion; 71.34% of them have access to the Internet.Cisco predicted that: “traffic from wireless devices will exceeds traffic wired devices by 2014.


2. Design Goals

③ Efficient support for multi-homing: In multi-homing, a host (or network) is simultaneously attached to multiple networks. While the current Internet is cumbersome to support multi-homing since it causes serious routing scalability issue, the future internet architecture is expected to efficient support multi-homing.

④ Encouraging innovation: The future internet architecture should allow each network to use its preferred network architecture and routing mechanism so that different network technologies can be simultaneously deployed and contest, thus encouraging innovation.

⑤ Enhanced security: The current Internet employs a default-on model and any host is able to send packets to a remote host, which makes the current Internet fragile to distributed denial-of-service attacks. Therefore, the future Internet should offer receivers the ability to control incoming traffic, especially to refuse unwanted traffic.


2. Design Goals

⑥ Enhanced scalability: The future Internet should provide better routing scalability over the current Internet. The routing table size should be significantly less than that in the current Internet.

⑦ Ease of traffic matrix estimation: It is difficult to estimate traffic matrices in the current Internet. However, since traffic matrices are critical inputs to many aspects of network management such as traffic engineering and network provisioning, the future Internet should makes it easy to precisely estimate traffic matrices in real time.

⑧ Deployability: Although we aim at a clean-slate design, the

future Internet architecture should be deployed without

incurring significant cost.


3. Design details

Basic ideas:I. Using four namespaces:

Service identifiers (SIDs): used to name contents. They are flat, self-certifying.

Node identifiers (NIDs): used to identify the identity of network nodes. They are flat, self-certifying and 128 bits long.

Intra-domain routing locators: used for intra-domain routing. Every domain can choose its preferred intra-domain routing architecture and routing locators.

Path identifiers (PIDs): used for inter-domain routing. Two domains can negotiate a set of PIDs, as long as the PIDs are unique in each domain. PIDs are not advertised throughout the Internet, but are local to the two domains.


3. Design details

Basic ideas:II. Using name-based routing for service location.

III. Inter-domain routing for data packet forwarding is determined during the service location process.

IV. Intra-domain routing may or may not be determined during the service location process. We leave this for domains’ local policy.

V. End-to-end data packet forwarding is based on loose source routing.

While some of the ideas are borrowed from existing literature, we believe that: one can see further by standing on the shoulders of giants.


3. Design details

D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12

As the current Internet, CoLoR assumes that the future Internet will still centered around domains.

Network topology

Domains have the AS-level provider/ customer/peer relationship.


3. Design details

D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12

A domain can freely choose its preferred intra-domain routing architecture, without considering other domains.

Domain 3 uses MPLS for intra-domain routing.

Domain 1 uses IPv6 for intra-domain routing.

Domain 4 uses OpenFlow for intra-domain routing.

Intra-domain routing


3. Design details

D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12

P1P5

P6

P4P7

Inter-domain routing relies on paths negotiated by two neighbor domains.

Inter-domain routing

Nodes in a domain maintains the end point of every path that connects the domain to a neighboring domain.

P7 R4

P6 R2 D1

D2

P5 R5 D6


3. Design details

D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12RM1

Service registration

P1P5

P6

P4P7

A

Every domain has a logical resource manager.

RM6

RM5

RM4

RM3

RM2

Content sources register SIDs to their local RMs, which registers the SID to their peers or provider RMs.

The service registration process is similar to that in DONA.


3. Design details

D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12RM1

Service location and inter-domain routing

P1

P5

P6

P4P7

A

Users send requests to their local RMs when they want a content represented by an SID.

RM6

RM5

RM4

RM3

RM2

RMs forward requests to either the closest copy of the content, or their provider RMs.

C

(i)

(ii)

(iii)

(iv)

(v)

(vi)


3. Design details

D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12RM1

Service location and routing

P1

P5

P6

P4P7

A

Every time a RM forwards a request to a neighboring RM, it appends the path between the two domains onto the request.

RM6

RM5

RM4

RM3

RM2

C

(i)

(ii)

(iii)

(iv)

(v)

(vi)

SID1 C(i)

(ii) SID1 C P4

(iii) SID1 C P4 P1

(iv) SID1 C P4 P5P1

(v) SID1 C P4 P5P1 P6

(vi) SID1 C P4 P5P1 P6


3. Design details

Packet forwarding

AD1

D3RM1RM3

R1

R4R2

R5

P6

P5

IP2

IP1

SID1CP4P5 P1P6 dataIP2IP1(a)

SID1CP4P5 P1P6 data(b)

SID1CP4P5 P1 dataMPLS LSP1(c)

SID1CP4P5 P1 data(d)

(d)

(c)(b)

(a)

Inter-domain packet forwarding is based on PIDs that are determined during the service location process.

Intra-domain packet forwarding is based on the routing mechanism of each domain.

Every time a border router receives an incoming packet, it strips out the outer most PID in the packet header.


Content caching

D5

D6

R6

R10R9

R7

R8

R11

A domain can freely choose whether or not to cache a content, based on its local policy and network status.

In addition, caching may or may not be en-route. For example, domain D5 can cache a content at R9 instead of R10, though R10 is en-route.

For example, if D5 uses LIPSIN for local routing, we may compute a zFilter including the red links.

3. Design details


Content caching

D5

D6

R6

R10R9

R7

R8

R11

The node caching the content should register the cached content to its local RM.

register

RM5

When the local RM receives requests for the content, it forwards the requests to the node caching the content, thus improving resource and energy efficiency.

requests

RM6

We leave it as local policy that whether or not a RM registers a cached content to its provider or peer RMs.

?

3. Design details


Inter-domain traffic engineering

D5

D6

R6

R10R9

R7

R8

R11

RM6

RM5

(iii)

Inter-domain traffic engineering is easy to implement.

When the RM5 in D5 forwards requests to the RM6 in D6, RM5 can choose the preferred path (e.g., P1 or P2) to carry packets corresponding to the request, based on domain D5’s local policy.

P1

P2

Inter-domain traffic engineering could be done at fine granularity (e.g., per-request level), which makes it easier to achieve better load balancing.

4. Benefits of CoLoR


Intra-domain traffic engineering

D5

D6

R6

R10R9

R7

R8

R11

RM6

RM5

CoLoR makes it easier to achieve fine-grained intra-domain traffic engineering.

For example, when RM5 forwards request A and B to RM6, it assigns intra-domain path P and P’ for transmitting data packets corresponding to requests A and B, respectively. PNote that intra-domain traffic engineering could be implemented at per-request level, or some coarse granularity, depending the domain’s local policy.

RequestsA and B

P’



Multi-homing

In the current Internet, Multi-homing often accompanies with prefix deaggregation, affecting the DFZ routing table size.

D2

D3D5

R2

R4

R2

R5

R10R9

R8

R11

D2

D3D5

R2

R4

R2

R5

R10R9

R8

R11

10.10.3.0/23

10.10.3.0/2310.10.3.0/24

By contrast, multi-homing in CoLoR only increases one or several local inter-domain paths and does not affect other domains.

Add an inter-domain path

Add an inter-domain path



Precise Estimation of Traffic Matrices


An ingress border router (IBR) knows the egress border router (EBR) of a data packet when the IBR forwards the data packet.

AD1

D3RM1RM3

R1

R4R2

R5

P6

P5

IP2

IP1

P7 R4

P6 R2 D1

D2

P5 R5 D6

packet

To estimate the traffic matrix from the IBR to the EBR, the IBR only needs to count the number of packets (or bytes) when it forwards packets to the EBR, which could be implemented in real time at line rate.


Multicast Support


D5

D6

R6

R10R9

R7

R8

R11

register

RM5

requests

RM6

The content

caching mechanism

and the content

registration primitive

make CoLoR efficient

in supporting

multicast.



D1 D2

D3

D4

D5

D6

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11R12

AS D3 uses MPLS.

AS D2 uses IPv6 AS D4 uses IPv4

AS D5 uses OPENFLOW

Encouraging Innovation

Every domain is free to choose its preferred network architecture. This encourages domains to adopt novel networking technologies if they feel that the new solution is significantly better than the one in use, without caring whether the new one is almost perfect.


Mobility Support


D5

D6

R6

R10R9

R7

R8

R11

register

RM5

requests

RM6

Intra-domain movement: addressed by using identifier/locator split.

Inter-domain movement: with the content caching and content registration primitives, a mobile host can re-request a content, which will be routed to a nearby copy of the content.

AA movement


Middleboxes


D5

D6

R6

R10R9

R7

R8

R11

RM6

RM5

PP’

When the RM in a domain forwards GET messages, it may also assign the intra-domain path for the flow corresponding to the GET message.Accordingly, the RM can direct different flows to different middleboxes, based on its local policy, which makes CoLoR efficient in support middleboxes.


Efficient support for SDNIn existing Internet architectures with SDN, the flow entry is setup when the border router receives the first data packet of a flow.

There is a flow setup delay of about 10 ms at an SDN domain, which will add delay to the flow.


R1 R2

RM1 RM2controller controller

S

C Data packets

requestsForwarding

rules


Efficient support for SDNIn CoLoR, when a RM forwards a GET message to a next hop domain, the border router in the same domain with the RM will receive the corresponding data packets after a certain period.

The controller can use this period to setup flow entries onto the switches for the flow, thus reducing (avoiding) the flow setup delay.


R1 R2

RM1 RM2NC1 NC2

S

C

(1)(2)

(5)(4)(3)

t

How Long is it?


Efficient support for SDN


10-1

100

101

102

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

millisecond (ms)

Em

piri

cal c

um

ula

tive

de

nsi

ty fu

nct

ion

(C

DF

)

mean = 24.5 ms, min = 0.21 ms

The cumulative probability density function of t

Mean = 24.5 ms


Routing scalability

The inter-domain routing tables size depends on the number of neighboring domains and the number of paths between them.

Assuming that the number of paths between two neighboring domains is 10, the maximum inter-domain routing table size is less than 40,000 ( > 3777 * 10).

The intra-domain routing table size depends on the routing mechanism of the domain and should be within control of the domain.



Security

1. Receiver controls incoming traffic by sending out GET messages.

3. However, path identifiers are local to neighboring domains

and it is difficult to guess the PID between two neighboring

domains. If PIDs are 32-bit long, the probability to correctly

guess a PID between two domains is ½^{32}.


2. Packets from a source node can be sent to a destination

node only if the inter-domain path identifiers carried in the

packet header are correct.


Security

In summary, CoLoR is significantly more secure than the

current Internet. [3] reports a preliminary analysis on

CoLoR’s security.

[3] Z. Chen, H. Luo, J. Cui, M. Jin, “Security analysis of a

future Internet architecture,” in Proc. 8th Workshop on

Secure Network Protocols (NPSec’13), Oct. 2013, Gottingen,

Germany.

4. A node receiving a request can send plenty of packets to a

destination node. But this could be dealt with by using

mechanisms such as TVA [2].

[2] X. Yang, D. Wetherall, T. Anderson, “TVA: a DoS-limiting

network architecture,” IEEE/ACM Transactions on

Networking, vol. 16, no. 6, Dec. 2008, pp. 1267 – 1280.



Deployment1. CoLoR may not be incrementally deployable as

end hosts need to be updated in order to send

registration and GET messages.


2. Existing networks are only required to update

their border routers and build a RM in order to

accommodate CoLoR, thus significantly reducing

the cost in deploying CoLoR.


5. Feasibility Analysis

We have implemented CoLoR’s basic features in the prototype shown above. The implementation demonstrates that CoLoR’s is feasible.

Prototype RM1 RM2

Client Server1 Server2

R1

R2

R3 R4

R5

R6

D1 D2

10.0.1.1

IP3

IP2

IP1IP4

10.0.3.1

10.0.3.2

IP2: 10.0.2.2

IP3: 10.0.5.1

IP4: 10.0.5.2

10.0.1.210.0.6.2

10.0.6.1

IP1: 10.0.2.1

10.0.4.2

10.0.4.1

2000:3000::2

2000:3000::1

2000:1000::12000:1000::2

2000:2000::1

2000:2000::2

IP5: 1000:4000::1

IP5

IP8

IP7IP6

IP6: 1000:4000::2

IP8: 1000:5000::2

IP7: 1000:5000::1

PID1

PID2

1000 GET messages per second

50% 50%

30%

70%



Click modules of RMs

SID table

PID table

routing tablePacket Processing

Data Packets Data Packets

registration /unregister

Process GET

Click modules of RMs



File store

print

routing tablePacket Processing


Registration/ unregister

GETsend data

Click modules of the client and the servers

Click modules of the client and the servers



Click modules of routers

Click modules of routers

PID tablerouting table

Packet Processing




The delay of processing GET messages at RM1

The processing delay of GET messages

350 400 450 500 550 600 6500

0.02

0.04

0.06

0.08

0.1

0.12

0.14

The delay for processing GET messages at a RM1 (microseconds)

Th

e e

mp

iric

al p

rob

ab

ility

mean = 529 smedian = 426 s



The estimated traffic matrices

Traffic Matrices

0 100 200 300 400 500 600 700 800 900 10000

100

200

300

400

500

600

700

800

900

1000

time (s)

rate

(p

k/s)

R3 - R

1

R6 - R

4

R6 - R

5

R2 - R

1

R3 – R1

R6 – R4

R2 – R1

CoLoR: An Information-Centric Future Internet Architecture for Innovation

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300

350

400

450

500

time (s)

rate

(p

k/s)

PID2

PID1

42 Beijing Jiaotong University


The effect of load balancing

Load balancing

PID1, 70%

PID2, 30%



Large scale deploymentThe RMs in tier-1 network needs to deal with the GET messages, which may limit the performance of CoLoR.

1. Resource handlers (RHs) in DONA are capable of processing REGISTER messages and FIND messages if DONA is deployed at the scale of the current Internet. Since RM in CoLoR is similar to RHs in DONA, RMs in CoLoR is also able to deal with GET messages.2. Dannewitz et al. [1] pointed out that it is possible to design a distributed hash table based name resolution system for flat SIDs, with an average resolution delay below 100 ms. Therefore, CoLoR is feasible at the scale of the current Internet. [1] C. Dannewitz, M. D’Ambrosio, V. Vercellone, “Hierarchical DHT-based name resolution for information-centric networks,” Computer Communications, vol. 36, no. 7, April 2013, pp. 736 – 749.


6. Conclusions

We have proposed CoLoR that couples service location with inter-domain routing while decoupling from forwarding.

Our implementation and analysis demonstrates that CoLoR has many benefits and is feasible.


Thanks!

Professor Hongbin Luo Beijing Jiaotong University CoLoR: An Information-Centric Future Internet...

Documents

Transcript of Professor Hongbin Luo Beijing Jiaotong University CoLoR: An Information-Centric Future Internet...