endpoint vs network services n.
Skip this Video
Loading SlideShow in 5 Seconds..
Endpoint vs. Network Services PowerPoint Presentation
Download Presentation
Endpoint vs. Network Services

Endpoint vs. Network Services

1 Vues Download Presentation
Télécharger la présentation

Endpoint vs. Network Services

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Endpoint vs. Network Services Henning Schulzrinne (with Xiaotao Wu) Columbia University Siemens ICN Innovation Symposium Munich – December 16, 2003

  2. Adding value through applications • What are services? • will focus on VoIP • difference most obvious • applies also to video-on-demand • Where can services reside? • Who can create services? • Preventing user service creation

  3. small number of well-defined (named) services, e.g., CLASS call return caller ID calling number blocking call trace repeat dialing call block … widely used charged by the month high initial cost (e.g., for switch generic) but pure profit once amortized stimulus interface end system does not know service almost no user customization partially caused by poor UI hardware model: push button to get feature expectation of “killer service” “content is king” vertical integration Old service model

  4. New service model • Provide protocol and API building blocks • service ingredients • (Mostly) open interfaces • protocol specifications • API specifications • common OS platforms (Symbian, Java, WinCE/Win32, Palm, Linux) • Works best if very narrow interfaces • IP, HTTP • Posix API

  5. New service model • Don’t expect a single killer service or application • except at large scale: web, email, IM, VoIP (eventually…)  • don’t expect the carrier to come up with one • users create their own services • users not just consumers • vertical niche applications • requires domain knowledge • encourages experimentation • risk is borne by those needing service the most • no infrastructure changes required • “connectivity is king” • slicing of service provision

  6. Push services content delivery streaming media inter-machine communications RPC (Corba, web services, …) games asynchronous messaging email synchronous messaging SMS, IM general event delivery (SIP) Pull services content retrieval ftp  gopher  web peer-to-peer IMAP, POP Aside: Internet services

  7. IP “hourglass” email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio... Steve Deering, IETF Aug. 2001

  8. The real Internet hourglass (slightly simplified) p2p (port 80) web web services HTTP TCP IP Ethernet

  9. VoIP: What are services? • Call routing services  subset of CLASS services • name/number translation • terminal, user mobility • call forward busy/no answer • call forward conditional (time-of-day, call center) • Directory services • white and yellow pages • global and corporate • Media services • media encoding translation for bandwidth • media type conversion: language, speech-to-text • media combining: conferencing • Identity services • identity assertion (“Columbia attests that Joe Smith, an employee, is calling”) • identity hiding (“ is calling”) • configuration repository • media preferences • address book and speed dial

  10. PSTN vs. Internet Telephony Internet Telephony end system PSTN Number of lines or pending calls is virtually unlimited More (per-user) processing power than most network servers Single line, 12 buttons and hook flash to signal

  11. PSTN vs. Internet Telephony PSTN: Signaling & Media Signaling & Media can be far away from either user Internet Telephone: Signaling Signaling Media

  12. PSTN vs. VoIP • PSTN: only carriers can get full signaling functionality (SS7) • UNI vs. NNI signaling • VoIP: same signaling, same functionality

  13. Network vs. end system services • Really two meanings: • services implemented in user agent (instead of proxy) • services implemented in server run by end user (instead of by carrier or equipment vendor)  • business • residential • Variation on old Centrex vs. PBX argument • except that media routing no longer an issue • Often, services require or can use both: • e.g., the history of speed dial • CLASS service: translation in CO • (semi)intelligent end systems: locally, possibly with hotsync to PC • intelligent end system, but network-synchronized

  14. End system vs. network trade-offs

  15. Network services PSTN gateway multiplexing gain SS7 access Backup services e.g., no answer from enterprise due to failure no permanent connectivity for residential users Large-scale conferences for residential users bandwidth availability End system/user services media processing distinctive ringing programmable services user control but: security maintenance End system vs. Network services – the easier cases

  16. Network service: call routing services • Outsourcing allows temporarily disconnected end users • Staged service: carrier proxy user proxy basic call routing personal preferences

  17. Peer-to-peer call routing H(aor) = node supernode REGISTER

  18. Network service: identity and trust management • Identity assertion (notary) services • best done by larger organization • server certificates • name recognition • recourse • Anonymity services • needs to have large user population to provide effective hiding • Portable services • high availability and universal reachability

  19. False either/or choice See email and web for precedent carrier-provided (ISPs) basic transport service name portability issues enterprise provide and manage own infrastructure only purchase “raw bits” home user albeit actively discouraged hosting companies = bandwidth + service shared and dedicated facilities but not an ISP in the traditional sense service-only companies web mail mail forwarding Internet service ecology

  20. The vanishing phone company • Old model: • explicit, user-visible signaling  dialing, ringing • small number of phone lines, (mostly) each with one E.164 identifier • New model: • session initiation from • IM session  no dialing and ringing • game session  proximity triggers conversation • event based  connect if event occurs • no notion of lines • teenager (or telemarketer…) may have dozens of chat windows open • some identifiers may make no PSTN calls at all • from monthly service  calling card-like • any number of identifiers • one per wire or device  multiple per person (role-based)

  21. The PTT approach stimulus signaling only force congruent media and signaling path limit vendor choices for end systems The Microsoft approach hidden APIs baroque interfaces, subject to change The WAP approach require new content restrictive technology licensing The cell phone approach cell phones not programmable restrict to certain cell phone models (US) air interface regulation and licensing The ISP approach port blocking NATs restrict upstream bandwidth The lawyer approach patents and trade secrets How to prevent user service creation

  22. Conclusions • VoIP enables, but does not force, end point services • separation of data and control planes • Move service location decision to end user, with trade-offs in • cost • control • availability • functionality • technical sophistication needed • Carriers and vendors have vital role: • service creation environments • reliable network service • trust and identity • service hosting

  23. Annex: technical backgroundon service creation

  24. Service location examples (*) = with information provided by end system

  25. Example: VoIP embedded in VR

  26. Network service: service mobility • Network server acts as repository for user cross-device configuration • address book • caller preferences (media, carrier, …) • authentication information • Devices can update user configuration • Automatically propagates to all other devices at next opportunity • not just explicit sync’ing (Palm-style)

  27. Example: user-adaptive device configuration “all devices that are in the building” RFC 3082? SLP 802.11 signal strength  location device controller REGISTER To: 815cepsr Contact: alice@cs PA HTTP SUBSCRIBE to each room tftp • discover room URI • REGISTER as contact for room URI SIP SUBSCRIBE to configuration for users currently in rooms room 815

  28. Service architectureProgramming language model Service Logic Programming Interface Requests Requests SIP Server Function Responses Responses

  29. Service creation • Few common service creation styles • extend base language with domain APIs (OO  Java) • create domain-specific or domain-tuned language • specific: CPL, voiceXML • tuned: PHP • C-like: • programming: C  C++  Java  C# • web: PHP (with built-in web abstractions) • For auto-generation (“wizard”): • programming: spread sheets • web: HTML, XML • VoIP, IM, presence: CPL, LESS, voiceXML

  30. Service creation: encouraging re-use • Web: client-side code available • Encourages learning and imitation • PHP, Perl, ASP, …: lots of common libraries Example: Yahoo calendar code

  31. Service creation • Promise of faster service creation • traditionally, only vendors (and sometimes carriers) • learn from web models

  32. Service creation – a comparison

  33. Example: LESS service generation Columbia sipc SIP user agent

  34. LESS service creation

  35. CPL example: anonymous call screening <cpl> <incoming> <address-switch field="origin" subfield="user"> <address is="anonymous"> <reject status="reject" reason="I don't accept anonymous calls" /> </address> </address-switch> </incoming> </cpl>

  36. Feature interaction • Undesirable interaction of services • Some causes avoidable in Internet environment: • lack of expressiveness (“what’s the # do here?”) • no prioritization (“call blocking precedes call forwarding”) • Some issues harder: • distribution of services • routing loops • how to anticipate problems  service testing

  37. The impact of regulations • Phone (service) companies are not required any more, but may be useful • don’t have (many) email companies, either • Regulation should not bias technical and business decisions on in-house vs. out-sourcing • Avoid conflicts of interest for ISPs that provide phone service: • no port blocking except by user request • traffic neutrality  provide differentiated services to all • provide externally routable addresses • address shortage excuse  NAT  difficult to have inbound connections • distinguish residential / business via application-neutral measures, e.g., bandwidth or availability • Goal: • ensure “transparent Internet” + service providers for added value • encourages service innovation • encourages service competition