NetInf slides - Department of Information Technology

Information-centric
networking and
NetInf –
An approach to the network of
the future
Bengt Ahlgren
[email protected]
Outline
●
The ICN approach and its motivation
●
Example: basic operation of ICN
●
ICN components
●
NetInf naming
●
NetInf protocol
●
Status of research
www.sics.se
2014-09-02
2
Background
●
●
Various “Future Internet” initiatives, US, EU, etc
–
Motivated from problems with current technology, and the
“ossification” of the Internet architecture
–
Often called “clean-slate” research
At the network infrastructure level, two new approaches
–
Software-defined networking (SDN)
–
Information-centric networking (ICN)
www.sics.se
2014-09-02
3
Information-centric networking
Information-centric
network
Today’s Internet
Host-centric abstraction
Who to communicate with
Information-centric abstraction
What to communicate
Evolution
In today’s Internet,
accessing information is
the dominating use case!
www.sics.se
2014-09-02
4
Host-centric networking
Trusted
Server
Connect to
Server X
and get
object B
Server X
B
Secure
Connection
www.sics.se
2014-09-02
5
Information-centric networking
Trustable
copy of
object B
A
D
B
E
C
Get object B
D
B
B
E
A
B
E
A
A
C
www.sics.se
2014-09-02
Untrusted
connection
A
D
6
Untrusted
host
Problems resulting from host-centric view
 Information is tied to its location
– Moving information = changing it's name (“404 file not found” errors)
– No common persistent naming scheme for information objects
 Information distribution is inefficient
– Can‘t benefit from existing copies (e.g. local copy on client)
●
Also true for Content Delivery Networks (e.g. Akamai)
– No “anycast”: e.g., get “nearest” copy
– Problems like Flash-Crowd effect, Denial of Service, …
 Mobility and disruptions become difficult to handle
– Need to maintain end-to-end connectivity between hosts
 Can’t trust an object copy received from an untrusted server
– Security is host-centric – no notion of publisher of information
– Mainly based on securing channels (encryption) and trusting servers (authentication)
Problems can be solved in a consistent manner
via an information-centric architecture
www.sics.se
2014-09-02
7
ICN communication model
●
●
●
●
Clients (C) send requests asking for named data
Routers (R) in the network routes requests towards
publishers (P)
Any node with a cached copy can provide the
corresponding named data object (NDO)
Remark:
–
On the surface, this is exactly the function of HTTP,
–
but, the HTTP request is always addressed to a particular host
www.sics.se
2014-09-02
8
ICN communication model
C1
R1
R2
P
A
C2
www.sics.se
2014-09-02
R3
9
ICN communication model
C1
A?
R1
R2
P
A
C2
www.sics.se
2014-09-02
R3
10
ICN communication model
C1
R1
A?
R2
P
A
C2
www.sics.se
2014-09-02
R3
11
ICN communication model
C1
R1
R2
A?
P
A
C2
www.sics.se
2014-09-02
R3
12
ICN communication model
C1
R1
R2
A
P
A
C2
www.sics.se
2014-09-02
R3
13
ICN communication model
C1
R1
A
R2
A
C2
www.sics.se
2014-09-02
R3
14
P
A
ICN communication model
C1
A
R1
A
R2
A
C2
www.sics.se
2014-09-02
R3
15
P
A
ICN communication model
C1
A
R1
A
R2
A
C2
www.sics.se
2014-09-02
R3
16
P
A
ICN communication model
C1
R1
A
A
R2
A
A?
C2
www.sics.se
2014-09-02
R3
17
P
A
ICN communication model
C1
A
R1
A
R2
A
A?
C2
www.sics.se
2014-09-02
R3
18
P
A
ICN communication model
C1
A
R1
A
R2
A
A
C2
www.sics.se
2014-09-02
R3
19
P
A
ICN communication model
C1
R1
A
A
R2
A
A
C2
www.sics.se
2014-09-02
R3
A
20
P
A
ICN communication model
C1
A
R1
A
R2
A
C2
A
www.sics.se
2014-09-02
R3
A
21
P
A
ICN main components
Security
Security
Name
Nameresolution/routing
resolution/routing
--tied
tiedto
tothe
theobjects
objects
--and
andthe
thenames
names
--scalability
scalabilitymain
mainconcern
concern
Naming
Namingscheme
schemefor
forobjects
objects
--flat
flator
orhierarchical
hierarchical
Forwarding/transport
Forwarding/transport
--with
within-network
in-networkcaching
caching
www.sics.se
2014-09-02
22
NetInf – Networking of Information
●
ICN architecture developed mainly in the SAIL EU project
–
●
●
Naming scheme for data:
–
ni://example.com/sha256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
–
Taken up as standards track RFC in the IETF (RFC 6920)
–
Provides name-data integrity (above with content hash as part of the name)
Http-based convergence layer (= transport protocol) using http POST
–
●
Several prototype implementations exists
I-D draft-kutscher-icnrg-netinf-proto
Name resolvers and routing scheme for named data
www.sics.se
2014-09-02
23
NetInf naming scheme
ni://<authority>/<alg>;<val>
●
●
URI-style format where:
–
<authority>: publisher or other origin making the object available
–
<alg>: digest algorithm (cryptographic hash) used for <val>
–
<val>: digest value
Example (for the string “Hello World !”):
–
●
ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
Signature-based <authority> also possible
–
needed for dynamic objects
●
Provides name-data integrity without consulting a third party
●
Specified in RFC 6920 (Naming Things with Hashes) which is on IETF standards track
www.sics.se
2014-09-02
24
NetInf abstract protocol
●
NetInf GET / GET-RESP
–
●
NetInf PUBLISH / PUBLISH-RESP
–
●
requesting named data and transporting data in response
making named data available, creating NRS entry or
pushing the complete object
NetInf SEARCH / SEARCH-RESP
–
querying a NetInf node for available data objects
www.sics.se
2014-09-02
25
Example: NetInf GET / GET-RESP
●
Abstract syntax
–
get-req = GET msg-id URI [ ext ]
–
get-resp = status msg-id [1*URI ] [ ext ] [ object ]
–
ext = json-coded-string
www.sics.se
2014-09-02
26
HTTP convergence layer
●
Purpose: provide reliable transport and easy prototyping
–
●
NetInf request messages are encoded as a HTTP POST
–
●
(yes, there are better ways of implementing this!)
NetInf request message parameters are encoded as a form fields
in the POST
NetInf response messages are encoded as a HTTP
response with a mime-encoded body
www.sics.se
2014-09-02
27
Example: NetInf GET
●
HTTP URI: /netinfproto/get
●
URI, msg-id and ext parameters encoded as HTTP POST form data
●
GET
–
●
http://example.com/netinfproto/get?URI=ni://example2.com/sha256;XYZ&msg-id=1&ext={}
GET-RESP
–
multipart/mixed – with two parts:
●
application/json – with object metadata
●
foo/bar – whatever mime-type is appropriate for the data object
www.sics.se
2014-09-02
28
NetInf HTTP CL “protocol stack”
NetInf message (abstract)
HTTP convergence layer encoding
HTTP
TCP/IP
www.sics.se
2014-09-02
29
Two modes of operation
●
Request forwarding
–
●
Each request is forwarded hop-by-hop until the
corresponding object is found (cached or publisher)
Name resolution
–
Objects are registered in a name resolution service (NRS)
when published
–
Clients first consults the NRS to get location information,
then sends the request to the obtained location
www.sics.se
ICN Status
●
●
Prototype code being released, for example
–
SAIL/NetInf: http://sourceforge.net/projects/netinf/
–
CCN: http://www.ccnx.org/
ICN community is forming
–
Workshops arranged and journal special issues dedicated to ICN
●
–
●
●
SIGCOMM ICN 2011, 2012, 2013, 2014, NOMEN at Infocom 2012, 2013,
Dagstuhl seminars 2010, 2012 and 2014, IEEE Comm Mag, etc
Standardisation presence: IRTF ICN RG, contributions to existing IETF WGs
Expected deployment
–
Short term: adoption of the general idea of named data, and of specific pieces, e.g., the naming scheme, in
particular for specific applications
–
Long term: completely replacing current IP infrastructure unlikely – as an overlay for the forseeable future
Projects
–
SAIL EU project: http://www.sail-project.eu/
–
EFRAIM: http://www.acreo.se/efraim
www.sics.se
2014-09-02
31
Summary
●
Communication based on named data
–
●
●
Request-driven, publish-subscribe-like interaction model
–
Publishers make named data available
–
Clients ask for named data
Location of data is secondary – any node can satisfy a request
–
●
Data is directly named independent of its container
Unifies P2P with server-based delivery using same network mechanism
Caching integrated in the network service
–
But ICN is not a replacement of CDN! ICN is protocols and mechanisms, while
CDN is a business role
www.sics.se
2014-09-02
32
References
●
●
●
●
B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman. A Survey of
Information-Centric Networking. IEEE Communications Magazine, 50(7), 2012.
ISSN 0163-6804
C. Dannewitz, D. Kutscher, B. Ohlman, S. Farrell, B. Ahlgren, and H. Karl, Network
of Information (NetInf) – An information-centric networking architecture,
Computer Communications, 36(7), 2013. ISSN 0140-3664.
D. Kutscher, S. Farrell, and E. Davies. The NetInf Protocol. IETF Internet-Draft
draft-kutscher-icnrg-netinf-proto, Oct 4, 2012, work in progress.
V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L.
Braynard, Networking named content. In Proc. CoNEXT ’09, Rome, Italy, Dec
2009.
www.sics.se
2014-09-02
33
www.sics.se

Download Report