VoCCN: Voice Over Content-Centric Networks
Paulo Mendes
(paulo.mendes@ulusofona.pt)
March 3rd, 2011
IAN meeting, SITI, Lisbon
Voice Over Content-Centric Networks
Agenda
1.
Brief Introduction to Named Data Networking
2.
Focus on Content-Centric Networking
3.
Study of Voice over Content-centric Networking
Van Jacobson, D. Smetters, Nick Briggs, Michael Plass, Paulo Stewart, James Thornton, Rebecca Braynard.
“VoCCN: Voice over Content-Centric Networks”, in Proc of ACM Reach, Rome, Italy, Dec 2009
V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard (PARC) Networking Named
Content, CoNEXT 2009, Rome, December, 2009.
2
Brief View on Networking
Historic Appointment

Since the invention of the telephone, communications have been related with a
“conversation” between two hosts

For the Internet generation, the Web just changed everything

And now the Internet of the things is placing an extra effort in host-to-host
communications


The “circuit” model of communications requires Spanning Trees

Introduces global dependencies that remove local choice.

Makes load near source scale with popularity.
Today’s view of communications

Wires move information in space.

Memories move information in time.
What do we need?
An architecture that merges both views of the
same problem
3
Name Data Networking
General Motivation and Design
For sharing, packets must describe what you want, not the process of getting it.
An address has to name data, not conversation endpoints.
For asynchrony (time-shifting, intermittent connectivity, mobility, ...)
Memory has to be explicit in the communication model.
Have to stop pretending container-based security can work
Start securing data.
Communication paradigm based on controlling named-content in the network, instead of host-to-host communication as
in today's Internet.
Note: Publish-Subscribe paradigm is just a possible way to realize a data-centric network.
4
Data-Named Networks
Major Efforts
Projects
  Named Data Networking (UCLA, PARC, University of Arizona, University of California, Irvine, University of
California, San Diego, Colorado State University, University of Illinois, Urbana-Champaign, University of
Memphis, Washington University, Yale University)
  MobilityFirst Future Internet Architecture Project (Rutgers, UMASS, U. Michigan, U. Duke, MIT, UNC, U.
Winconsin, U. Nebraska) - http://mobilityfirst.winlab.rutgers.edu/
  Nebula: A Future Internet Architecture that Supports Trustworthy Coud Computing (Cornell Univ, U. Texas, U.
Washington, Purdue Univ., U. Illinois, U.Pennsylvania, MIT) - http://nebula.cis.upenn.edu/
  Expressive Internet Architecture (Boston Univ., CMU, U. Wisconsin) - http://www.cs.cmu.edu/~xia/
  NetInf (http://www.netinf.org/home/home/)
  Haggle (U. Cambridge, Thompson, Uppsala U., EPFN, CNR, .. ) - http://code.google.com/p/haggle/
  PSIRP – Publish/subscribe Interdomain Routing Paradigm: system based on brokers to match cryptographicbased flat identifiers to application data names (Data must be publish forehand)
People:
  Scott Shenker, Deborah Estrin, Ion Stoica, Lixia Zhang, Van Jacobson, Jim Kurose, Don Towsley,
Dipankar Raychaudhuri. Peter Steenkiste
5
Data-Named Networks
CCN aims to ….

(provably) optimal content distribution

Painless mobility

Same efficiency as TCP/IP

Simple, secure, robust configuration

An easy, incremental, evolutionary path

Much better security

Greater scalability and a more dynamic network topology.
Fundamentals:
  Replace Packets with Data Objects and Interests
  Replace Addresses with Object Names
6
Data-Named Networks
Host vs Data communications
  Path determined by global routing, not
local choice.
  Structural asymmetry precludes market
mechanisms and encourages monopoly
formation.
  Packets say ‘what’ not ‘who’ (no src or dst)
  Forwarding decision is local
  Upstream performance is measurable.
7
VoCCN
Motivation and Major Goals
  Fact: Architectures based on data-oriented abstractions provide a good fit to the massive amounts of static content
exchanged via the World Wide Web and various P2P overlay networks.
  Doubts: How well they fit more conversational traffic such as email, e-commerce transactions or VoIP?
  Goal: To investigate Voice Over CCN in terms of simplicity, security and more scalability.
  Requires   Separate signalling and data paths.
  Requires regular updates of topologic locations
  VoIP is secured by:
  Encrypted form RTP (SRTP)
  Tunneling RTP with secure protocol (e.g., DTLS).   Encryption keys are set up via:
  encrypted signaling path or   in-band in the media path (ZRTP).
8
VoCCN
Architecture and Advantages
  Motivation: VoIP signalling and data paths result from a mismatch between the user’s goal and the network’s means
of achieving it.
  Alice simply wants to talk to Bob but the network requires that the communication be addressed to the IP
address of Bob’s phone.
  Goal: Remove the “translation” from real life to network control.
  Challenges:
  Support service rendezvous: request a connection and get a
confirmation response.
  On-demand publishing is needed: request data that was
not published yet.
  Transition phase: from rendezvous to a bi-directional
conversation.
  Constructable names are needed: construct name a priori:
  Deterministic algorithm to get to the same routable
name (providers & consumers)
  Consumer retrieve content based on partial names.
9
VoCCN
Implementation and Security
  Inline message security:
  Caller: encrypt and authenticate SIP invite using random-Inline message encriptation generated
symmetric key (sk)
Components of
Interest
  Caller: encrypt sk using callee’s public key (pk B)
  Calle: decrypt interest using his/her private key
  Calle: uses sk to verify and decrypt SIP invite, which includes first MIKEY key exchane message
10
VoCCN (and CCN)
Advantages and Major Limitations
  Proof-of-concept of real-time CCN
  Extension of Linux VoIP phone (libeXoSIP, liboRTP)
  Open CCN toolkit (CCNx): routers run on endpoints.
  Support multi-point routing (mobility and multi-homing)
  “Identity” of an endpoint represented by credentials
  Easy to build advanced services (e.g. conference calls)
  Performance for a 10 minutes conversation:
  More packets below the expected inter-packet interval
  Small number of long-interval packets.
  No packets loss for both cases

Constructable names: flexibility may require partial names that are not unique


Pipeline of Interest packets: not proved to perform
Working scenarios: The use of hierarchical names poses difficulties in dynamic graphs

Performance studies based on fast workstations and high-speed networks (100 Mbps and 1Gbps)
11
12