Th Realizaon of Name Lookup Table in Routers Towards ...

[Pages:1]... ...

7th Interna*onal Conference on Network and Service Management (CNSM 2011) October 24~28 Paris, France

Realiza*on of Name Lookup Table in Routers Towards Content-centric Networks

Research Background

Communica*on model of Internet

Emphasis on who (iden*fier) and where (physical adachment point)

Emphasis on what (informa*on/content/resource itself)

Route on IP address

Route on what

Route on what (content-centric networking) Does not know nor care on which node the desired data or service resides. Network with high intelligence would look at the content of the message from the source and route it to the appropriate des*na*on.

Mo*va*on

Hardware in Network Layer should support this paradigm shin from `who and where' to `what' Name lookup table in routers should have a structure to manage and search a large-scaled informa*on of named content and subscribers

Research at a Glance

Propose a hardware architecture where the network layer routers behave as the brokers in publish/subscribe that can perform well even when the number of the subscribers increases dras*cally

Publish/subscribe (pub/sub) model

No*fica*on Service

P1

S1

...

P2 Publish

Pn

B1 B2

Bn

Subscribe/ Unsubscribe

S2

No*fy Sn

Publisher: Generates events Subscriber: Registers interest in an event, or a padern of events No*fica*on Service:

Stores and manages subscrip*ons

Types of pub/sub model - Topic-based: Events are grouped by topic names. Subscribers receive all events published by the subscribing topic name - Content-based: Events are described by data adribute and meta data. Subscribers selec*vely receive events by specifying detailed condi*ons.

Brokers (no*fica*on service) are typically overlay nodes Problem: (i) Mul*ple overlay edge crossing the same physical links, genera*ng redundant traffic

(ii) Reliability of the network depends on end nodes (peers)

Implementa*on of pub/sub model in Network Layer

Pro: (i) Effec*ve usage of physical topology (ii) "Network Layer service", not a service of a specific applica*on

Con: Requires a new mechanism to store and manage published event and subscrip*ons in hardware in Network Layer, i.e., routers

Utilization (%) Latency (?s) Utilization (%)

Proposal of Name Lookup Table

Output Topic interface

... ...

Apple Apple Apple Apple

fa0 fa1 fa2 fa3 fa4 fa5 fa6 fa7

Apple fa8 fa9

(a) Ac*ve TCAM,

passive SRAM

Network

Pro: High search speed using TCAM and parallel process of searching the next key using the latency

Con: Number of keys that can be searched simultaneously depends on the number of FNH bits

Topic

Output interface

...

...

Apple fa0 fa1 fa2 fa3 fa4 Apple fa5 fa6 fa7 fa8 fa9

...

...

(b) Passive TCAM,

ac*ve SRAM

Network

Pro: U*lizes cheaper memory (SRAM:TCAM 1:5) and minimizes the number of mul*match, reducing the need for many FNH bits

Con: Reserving too many lateral SRAM bits for popular topics may cause wasted bits for other topics

Topic EN Out BL Output interface

...

0 eth1 0 Apple 1 100 10

0 eth2 0

fa0 fa1 fa2 fa3 fa4 fa5 fa6 fa7 fa8 fa9

...

(c) Passive SRAM,

ac*ve DRAM

Network

Pro: Reduces memory cost by u*lizing DRAM to the maximum (DRAM: SRAM1:1000)

Con: Higher latency compared to SRAM and TCAM

Evalua*on

Actual cost and latency using real-life database

A

104

B

104

104

Latency and u*liza*on using real-life database with cost limita*on

C

B

104

105

A

102

105

C

102

Cost ($) Latency (?s)

Cost ($)

103

103

103

103

104

101

104

101

Latency (?s) Latency (?s)

103

100

103

100

102

102

102

102

102

10-1

102

10-1

101 100100

Actual Cost Approx. Cost

Latency

101 102 103 104 105

Row length of SRAM (bit)

101 106100

101 100100

Actual Cost Approx. Cost

Latency

101 102 103 104 105

Row length of DRAM (bit)

101 106100

101 100

0

Latency Utilization

2

4

6

8

Number of TCAMs in a router

10-2 10-3 10

101 100

0

Latency Utilization

2 4 6 8 10 Number of SRAMs in a router

10-2 10-3 12

When only the cost is considered, it seems that the Scenario C is the best solu*on since the informa*on of subscribers is stored in the most inexpensive DRAM. However, the overall processing speed is affected by the slow SRAM and DRAM With cost limita*on: Latency for Scenario A and B ranges from 75 to 510 s whereas for Scenario C the range is from 8.5 to 45 ms.

Conclusion

Router's Name lookup structure should be designed according to the database of topic names and users having Zipf distribu*on as well as the latency of each memory

Future Work

Evaluate the effect of placing mul*ple rendezvous points for a topic name (+Network) Propose a full implementa*on of content-centric network in the network layer

UPQJD 5 5 5 5

SFDFJWFS 5@V 5@V 5@V 5@V

TPVSDF

3FOEF[WPVT 1PJOU 31

DMVTUFS

SFDFJWFS

5 5@V 5 5@V

5 5@V 5 5@V

Haesung Hwang (h-hwang@ist.osaka-u.ac.jp), Shingo Ata?, and Masayuki Murata Graduate School of Informa*on Science and Technology, Osaka University, Japan ?Graduate School of Engineering, Osaka City University, Japan

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download