VoCCN: Voice-over Content-Centric Networks

Van Jacobson
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  VoCCN: Voice-over Content-Centric Networks Van Jacobson Diana K. Smetters Nicholas H. Briggs Michael F. PlassPaul Stewart James D. Thornton Rebecca L. Braynard Palo Alto Research CenterPalo Alto, CA, USA { van,smetters,briggs,plass,stewart,jthornton,rbraynar } ABSTRACT A variety of proposals call for a new Internet architecturefocused on retrieving content by name, but it has not beenclear that any of these approaches are general enough to sup-port Internet applications like real-time streaming or email.We present a detailed description of a prototype implemen-tation of one such application – Voice over IP (VoIP) – ina content-based paradigm. This serves as a good exampleto show how content-based networking can offer advantagesfor the full range of Internet applications, if the architecturehas certain key properties. Categories and Subject Descriptors C.2.1 [ Computer Systems Organization ]: NetworkArchitecture and Design; C.2.2 [ Computer SystemsOrganization ]: Network Protocols General Terms Design, Experimentation, Performance, Security 1. INTRODUCTION There is widespread agreement that  content   – whata user wants – should have a more central role in fu-ture network architectures than it does in the Internet’scurrent host-to-host conversation model [9, 5, 23, 4, 2,15, 6, 19, 20, 22, 7, 3, 8, 16, 17, 18]. But while itis clear that architectures based on Pub-Sub and simi-lar data-oriented abstractions provide a good fit to themassive amounts of static content exchanged via theWorld Wide Web and various P2P overlay networks, itis less clear how well they fit more conversational trafficsuch as email, e-commerce transactions or VoIP. Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.  ReArch’09,  December 1, 2009, Rome, Italy.Copyright 2009 ACM 978-1-60558-749-3/09/12 ... $ 10.00. Internet IP Alice IP Bob Alice's VoIP ProviderBob's VoIP ProviderRouter ARouter B 2 Media Path 1 Signaling Path Figure 1: Voice-over-IP data flows To investigate this question we have implementedVoCCN — a real-time, conversational, telephony ap-plication over Content-Centric Networking (CCN) [16,17, 18] and found it to be simpler, more secure and morescalable than its VoIP (Voice-over-IP) equivalent. Ourimplementation uses standard SIP [11] and RTP [10]payloads which gives it complete  and secure   interop-erability with standard-conforming VoIP implementa-tions via a simple, stateless, IP-to-CCN gateway.This paper describes how to map the existing VoIParchitecture into CCN while preserving security, inter-operability, and performance. The mapping techniquesare not unique to VoIP, but are examples of generaltransformations that we believe can be applied to al-most any conversational Internet protocol. Through theexample of VoCCN we explore the properties that canenable networking models focused on content to be moregeneral than traditional conversational models. Thesenew architectures can therefore deliver benefits for bothstatic content and the full range of conversational com-munication applications that are important in the In-ternet today. 2. VOIP BACKGROUND Voice over Internet Protocol (VoIP) is the dominantopen protocol for Internet telephony. Figure 1 depicts 1  the components of a standard VoIP exchange. WhenAlice and Bob wish to make a phone call, their VoIPphones set up an audio link using the Session InitiationProtocol (SIP) [11] via what is termed the  signaling path  . As VoIP endpoints are often mobile or locatedon dynamic IP addresses, signaling path exchanges aremediated by  proxies   – service providers or corporateVoIP signaling gateways that receive and forward mes-sages on behalf of their client endpoints. To place a callto Bob, Alice’s endpoint first contacts her SIP proxywho forwards the call invitation to Bob’s SIP proxy, asonly Bob’s proxy knows the current IP address of Bob’sendpoint. The body of the invitation contains both in-formation about Alice and the RTP [10] address whereshe expects to receive audio (or other media streams)from Bob, should he accept the call. Bob’s accept of the invite contains the RTP address of where he ex-pects to receive audio from Alice which allows a direct,bi-directional  media path   between their endpoints.VoIP media (voice, video, etc.) can be secured andauthenticated using either an encrypted form of RTP(SRTP [12]), or by tunneling RTP inside another se-cure network protocol ( e.g.,  DTLS [14]). The encryp-tion keys are either set up via the signaling path, whichmust then itself be encrypted, or in-band in the me-dia path (ZRTP [24]). Signaling path authenticationand encryption can be done via wrapping the signalingexchange in DTLS and relying on a Public Key Infras-tructure (PKI) to authenticate the exchange, or usinga key agreement protocol such as Multimedia InternetKeying (MIKEY [13]) embedded in the signaling mes-sages. MIKEY has the advantage of providing end-to-end security and authenticating its own messages whileminimizing signaling path roundtrips, but does not it-self provide confidentiality of the signaling pathway. Inpractice, however, the perceived difficulty and cost of configuring cryptographic keys and establishing a PKImeans that VoIP traffic is almost always unencryptedand unauthenticated. 3. ARCHITECTURE The complex data paths of Figure 1 result from a mis-match between the user’s goal and the network’s meansof achieving it: Alice simply wants to talk to Bob butthe network requires that the communication be ad-dressed to the IP address of Bob’s phone. All the in-frastructure in the Figure, together with the several ser-vices, devices and DNS name registrations that are notshown, exist solely to map from the user/application’sworld view into the network’s world view. One strongdriver for content-oriented networking is that this trans-lation (typically referred to as  middleware  ) is not needed.Data should instead ideally flow directly from producerto interested consumer, as shown in Figure 2. OurVoCCN prototype achieves this. Internet CCN  CCN  Router ARouter BSignaling & Media Path Figure 2: Voice-over-CCN data flows There are a couple of problems that must be solved inorder to map conversational protocols like SIP and RTPinto a content-oriented model. First, we must support service rendezvous  . To initiate a call, the caller’s phonemust be able to request a connection with the callee,and get a confirmation response. This requires thecallee’s phone to offer a service contact point. In stan-dard IP, a port number serves as such a point where aprocess receives requests to which it dynamically gener-ates responses. To translate this into a content-orientedmodel, we need  on-demand publishing  : the ability torequest content that has not yet been published, routethat request to potential publishers, and have them cre-ate, and then publish, the desired content in response.Second, we must have a way to transition from thisinitial rendezvous to a bi-directional flow of conversa-tional data. In standard IP, there are packets (eitherdesignated packets in the rendezvous sequence, or allTCP or UDP packets) that contain the informationneeded to name the destination to which replies shouldbe sent. For example, a TCP packet header containsa source IP address and port plus a protocol identifier.In a SIP exchange, the SDP content of the SIP message(shown in Figure 3) identifies the address to use for themedia conversation. To translate this into a content-oriented model, we need  constructable names  : it mustbe possible to construct the name of a desired piece of content  a priori  , without having been given the nameup front or having previously seen the content – theservice consumer must be able to figure out how to for-mulate a request that will reach the service provider.This can be done if: ã  There is a deterministic algorithm by which thedata provider and consumer arrive at the same(routable) name based on data available to both. ã  Consumers can retrieve content based on partially-specified names.The former requirement guarantees that consumerand producer will arrive at the same name, and that 2  INVITE SIP/2.0Via: SIP/2.0/CCN Alice Briggs <>To: Bob Jacobs <>Call-ID: 1911287229CSeq: 20 INVITEContent-Type: application/sdpMax-Forwards: 70User-Agent: Linphone/3.0.0 (eXosip2/3.1.0)Subject: Phone callExpires: 120Content-Length: 1477[...o=alice 123456 654321 IN IP4 IP4 mikey AQQFgE3dV+ACAA... m=audio 7078 RTP/AVP 111 110 0 3 8 101...] Figure 3: Example of SIP INVITE message names will not depend on data not available to both(such as the cryptographic digest of the content, impos-sible for data that does not yet exist and will be gen-erated on demand). The latter deals with the fact thatwithout significant prearrangement to allow for a sourceof shared randomness, such constructed names will notbe unique. By allowing flexibility in the query mecha-nism, we can allow for uniquely named content, whilematching it to deterministically generated queries. Forexample, allowing a query for a structured name thatmatches only the prefix of that name.In CCN, each fragment of content that may be pub-lished in the network has a hierarchically structuredname. Requests for content are expressed in  Interest  packets, which specify the prefix of the name of the de-sired content and a set of rules by which to determinewhat of the content under that prefix to return. CCNrouting tables use prefix matching to directly route in-terests based on their name prefixes towards contentsources that have registered availability of content byprefix. CCN does not require that data be publishedand registered with the infrastructure before it can beretrieved; a request merely needs to start with a pre-fix registered with intervening routers for delivery to aninterested publisher. Such a publisher can then look atthe request and create named content, or Data packets,dynamically in response. The network forwards match-ing Data packets back along the path taken by the In-terests that requested them, so content reaches the re-quester and is never sent where it was not requested.For a detailed description of CCN and its current im-plementation, please see [18].We map a SIP rendezvous onto CCN as shown in Fig-ure 4. Each phone endpoint is configured at provision-ing time with an identity ( e.g., ), andregisters to offer data in a namespace derived from thatidentity and the name of the SIP service ( / ). A caller maps a SIP INVITE (ex-ample shown in Figure 3) into an Interest packet askingfor new content from the callee. The network routesthe Interest to the callee, which generates a piece of Data with the requested name containing the SIP re-sponse, thus completing SIP signaling in a single roundtrip. The use of structured names in CCN allows asimple mapping of the callee identity and service nameinto the first part of the content name (used for hierar-chical, prefix-based routing) while unique identifiers forthe request are added to distinguish the desired contentfrom any pre-existing content. Note that the entire SIPINVITE message is included in the requested contentname (potentially in encrypted form). The callee re-ceiving this Interest can unpack the name and generatea SIP response as the content of the Data packet thatwill satisfy the Interest.To transition from the SIP rendezvous into the mediaconversation with RTP, each phone takes informationexchanged in the rendezvous and uses it to construct asequence of names for the individual packets of mediadata. This is also illustrated in Figure 4, where we seethat the  call-id  from the SIP exchange, together withthe identity of the other party and a sequence numberis used to construct the name of each fragment of me-dia. Sequence numbering provides a simple way for dataprovider and consumer to arrive at the same uniquename for each piece of content. These names can becryptographically anonymized to unlink them from theSIP exchange and provide user privacy.In the content delivery architecture of CCN, Inter-ests and Data flow in lock-step, each Interest retrievinga single data packet. In a dispersed or high-latency net-work, the round-trip latency can easily be large enoughto delay reception times of media packets to the pointwhere they become unplayable. To solve this problem,we employ pipelining by sending Interests for multiplefuture media packets. The CCN media receiver main-tains some number of outstanding Interests in a mediastream; when the stream is opened (or as network con-ditions change) it generates a number of Interests. Eachtime it receives content for that stream, it produces anew Interest, thereby maintaining the number of out-standing Interests in the pipeline. 3.1 Advantages Our approach adds appealing properties beyond sim-ply supporting an existing conversational protocol: ã  Content networking infrastructures support multi-point routing – for example, automatically routinga call request to all likely places where it might beanswered. This direct infrastructure support for 3  Name:   / domain / bob / call-id  /rtp/ seq-no Signature Info: <metadata>, <signature> Content: SRTP packet (encrypted audio) Caller (Alice) Callee (Bob) <registers a desire to see interests asking for content beginning with / domain /sip/ bob /invite>   / domain /sip/ bob /invite/ E pkB (sk) / E sk ( SIP INVITE message)                                                                             Name:   / domain /sip/ bob /invite/ E pkB (sk) / E sk ( SIP INVITE message) Signature Info: <metadata>, <signature> Content: E sk ( SIP response message )   Interest:   Data:   / domain / bob / call-id  /rtp/ seq-no Interest:   Data:   Name:   / domain / alice / call-id  /rtp/ seq-no Signature Info: <metadata>, <signature> Content: SRTP packet (encrypted audio) / domain / alice / call-id  /rtp/ seq-no Interest:   Data:   Figure 4: Protocol exchange. multipoint calling removes the requirement thatendpoints register their IP address every time theymove, at least within the routing domain. ã  The “identity” of a content infrastructure endpointis represented by credentials located on that end-point –  i.e.,  a signing key, identifying content ( e.g., voice packets) that it creates. Management in avoice content system is minimized, as provisioninga new endpoint consists only of giving that end-point a credential. In contrast, VoIP configurationrequires setting the mapping from callee identityto endpoint IP address at multiple points in thenetwork, each time that IP address changes. ã  Advanced services (voicemail, conference calling,call logging and recording) can be easily built ontop of a content-based voice system as additionalcomponents utilizing multipoint routing to followcall requests or copy and process call contents. 3.2 VoCCN/VoIP Interoperability We have chosen to implement standard VoCCN byencapsulating standard VoIP protocols (SIP, SRTP), toenable direct interoperability between VoCCN and un-modified legacy VoIP implementations. Such interoper-ability can be achieved using a stateless VoCCN-VoIPgateway. 1 Such a gateway allows an organization to in- 1 We present the design of such a gateway here, but have notyet implemented one. crementally deploy a VoCCN-based infrastructure, in-teroperating with VoIP calls coming in from or going tothe outside world and internal legacy VoIP phones.In this model, the VoCCN/VoIP proxy serves as theSIP proxy for external (and internal) inbound VoIPcalls, and translates from VoIP packets (SIP and SRTP)to VoCCN packets (which again merely encapsulate SIPand SRTP for this application), and vice versa.On receiving a SIP or SRTP packet, the proxy merelyexamines that packet and generates a correspondingCCN Data packet whose name is determined based oninformation in the srcinal inbound packet header (seebelow). It then forwards it into the CCN routing fabricin response to an Interest from the other (CCN-aware)endpoint involved in the call. The proxy then performsthe CCN-specific parts of the call on behalf of the legacyVoIP client – generating and sending an Interest in thenext packet of the exchange, where the name used in theInterest is also computed as a function of informationin the inbound VoIP packet.The proxy retains no state about the call but re-sponds only to received (CCN or VoIP) packets – thecall “state” is contained at the endpoints and in the In-terests noted in the forwarding tables along the path tothe content source. The proxy also has limited par-ticipation in call security. Key exchange and mediapath encryption (if supported by the VoIP client) isend-to-end, provided by standard MIKEY and SRTP.SIP signaling security for the VoIP portion of the call, if  4
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks