OPEN NETWORKING IN THE INTERNET AGE Stephen B. Weinstein

1. OPEN NETWORKING IN THE INTERNET AGE Stephen B. Weinstein NEC USA C&C Laboratories Princeton, N.J., USA sbw@ccrl.nj.nec.com OpenSig ‘97 Cambridge, England April 17, 1997

2. POSSIBLE INTERPRETATIONS OF “OPEN NETWORKING” - A meaningless term. - Open to everyone in the sense of Universal Service(s). - Accepting a wide range of end devices. - Interoperability of services between networks. - Modular architecture with standard interfaces facilitating “mix and match” of network components. - Readily accommodates changes in technologies and how they are used. - Components accessible for direct end-user control.

3. ALTERNATIVE VIEWS OF “OPENNESS” INTERNET OPENNESS: - Attach any network using IP. - Attach any user and any number of users (not constrained by switch ports or access lines). - Join any multicast session you like (receiver-initiated). - “Intelligence” largely in attachments, at user discretion.

4. ALTERNATIVE VIEWS OF “OPENNESS” - Nonproprietary protocols and services . - Experimental environment for protocol/service/application development. An open API. Ref: M. Decina & V. Trecordi, “Convergence of Telecommunications and Computing on Networking Models for Integrated Services & Applications”, to appear in Proc. IEEE. - “Free for all” for resources.

5. MBone RTP/TCP/IP NAP LAN LAN ISP Internet telephony ISP Proxy/ relay server Browser/virtual machine ISP Web server “Push” server Applets, agents, ... TCP, IP, Telnet, FTP, HTTP, ...

6. PUBLIC NETWORK OPENNESS: - Universal telephone service. -Standard interfaces and protocols for interoperability of virtually all telephone systems and devices. Support of simple terminals by “intelligence” in the network (switching software, Intelligent Network Service Control Point, etc.). - Limited programmability for large customers (e.g. Virtual Private Network). - Protection of network integrity and quality of service by limiting openness to services tightly controlled in network entities.

7. LIMITED OUTSIDE PROGRAMMABILITY AND CONTROL: AIN AND VPN Advanced Intelligent Network scripts for number translation and peripheral processing Service control point Portion of voice switch capacity dedicated to Virtual Private Network customer. Customer control of trunk group cross connect.

8. ATTACHMENT OPENNESS FOR VOICEBAND SERVICES modem Local company Wireless carrier Long-distance carrier Internet real- times services gateway (e.g. Internet telephony/PSTN) Local company Internet ISP

9. Signaling entity Signaling entity Control entity Management agent data connection OA&M or routing table STANDARD CONTROL AND MANAGEMENT INTERFACES END SYSTEM NETWORK SYSTEMS Proprietary Applications Call state NM applications admiss policy Commun. API CMIP Q3 Proprietary & MIB Measuring entity UNI signaling: Dialing tones, Q.2931 NNI signaling (e.g. ss#7) Proprietary Switch and/or router

10. WHY IS IT DIFFICULT TO MERGE THE INTERNET AND TELCO CONCEPTS OF OPENNESS? - Different philosophies for transport service (e.g. IP vs. ATM). - Different communities developing standards. MANAGEMENT CONTROL ITU, ATMF Public Networking Community IETF Enterprise Networking Community - Different opinions about who should control networks. - Difficulty in reconciling public network security and QoS with Internet experimentation.

11. CONVERGENCE TRENDS BETWEEN INTERNET AND TELCO OPENNESS - Need to interoperate, especially for real-time services (e.g. Internet telephony/ PSTN telephony). - Movement and conversion of technologies blurring ideological boundaries. - ATM switching in core network. - IP switching using ATM fabric. - Internet implementing QoS services (with at least statistical guarantees).

12. CONVERGENCE TRENDS BETWEEN INTERNET AND TELCO OPENNESS - Internet becoming performance-oriented. * Developing consortium of ISPs to define performance measurement and control. - Telco implementation of data services (many becoming ISPs). - Technologies facilitating openness to end-user control (transportable software, active network). - Potential common concepts of network software architecture.

13. INTERWEAVING MANAGEMENT AND CONTROL BETWEEN INTERNET AND TELEPHONE NETWORKS FOR OPENNESS IN SERVICES Internet PSTN Examples: SNMP CMIP email fax, voice messaging RSVP Q.2931 “Esperanto”

14. OPENNESS TO CHANGES IN TECHNOLOGY UTILIZATION: Example: routing and switching for Internet traffic. Today: PSTN/ISDN switch Router Router Core Internet Tomorrow: Router ATM switch Core Internet

15. Example: “Negroponte inversion”, compounded TRADITIONAL MORE RECENT NEW Some intelligence Digital broadcast Video To ISP CATV Web TV DIGITAL CABLE to ISP Voice CO PCS cellular Internet telephony

16. Internet PSTN Enterprise NETWORK SOFTWARE ARCHITECTURE: AN OPPORTUNITY FOR A COMMON PERSPECTIVE API Distributed Processing

17. GOALS FOR NETWORK SOFTWARE ARCHITECTURE 1. Be simple and logical enough for reasonably intelligent people to understand. 2. Accomodate heterogeneity and programmability in equipment, policies, and protocols. Example: Control and management of a switch under either ISO or IETF protocols. Call admission control Q.2931 RSVP agent SNMP CMIP edge switch

18. GOALS FOR NETWORK SOFTWARE ARCHITECTURE 3. Support mobility of persons, terminals, and services. Subscriber profile Away Home Resources Transparency: Access to distant resources without having to know where they are. Location awareness: Awareness of and access to local resources, e.g. “nearest printer”.

19. Middleware GOALS FOR NETWORK SOFTWARE ARCHITECTURE 4. Create new, reasonably efficient services in the short term without having to wait for changes in standardized signaling and management protocols. Newly created service Legacy network elements and technologies

20. 5.Make joint allocation of computing and communications resources. call processing computing resources Bandwidth resources (Mobility and/or dynamic QoS services may place a large burden on call processing, so that computing, rather than bandwidth, could become the bottleneck)

21. 6. Define open interfaces to switches and other network elements. Management queries/responses Resource allocation QoS information Control Administrate Observe

22. 7. Integrate network control, management, and services creation. 8. Be evolutionary, not revolutionary. (Communication operators must accommodate legacy systems while implementing new ones, and must generate revenues from new technology in order to extend it.)

23. control WHY INTEGRATE NETWORK CONTROL AND MANAGEMENT? - Time scales are beginning to overlap. control management sec .01 .1 1 1000 .001 10 100 user/application requirements - Functions are beginning to overlap. A. Management of control policies and rapid changing of policies. Control Policy Mngmnt network conditions

24. M U X .......... .......... B. Reconfiguration tightly coupled to call admission/QoS renegotiation Example: Reconfiguration of passband channel assignment to HFC customer (from channel “A” to channel “B”) New service request to headend existing Reconfiguration: -Reassign subscriber to. channel B. -Move existing session and new session to channel B tuner A channel Downstream spectrum Digital passband channels (30Mbps each) A B C D ........ congested Ref: Kolarov & Weinstein, “Flexible bandwidth allocation in hybrid fiber/coax distribution networks”, Proc. IEEE Globecom ‘95, Nov., 1995.

25. App. A .......... .......... .......... .......... .......... .......... DISTRIBUTED OBJECT ARCHITECTURE CAN HELP - Services abstractions hiding irrelevant details. - Interoperability between applications written in different programming languages and running on different computing platforms. App. B OS#3 ORB OS #1 App.C ORB: Object Request Broker OS #2 - Location transparency and (when needed for mobility) location awareness. “Connect me to the nearest pharmacy”

26. - Relatively simple object (and abstract service) creation, over existing infrastructure. + Possible help in detecting feature interaction problems. - Libraries of Object Services and Facilities: Naming, life cycle management, persistence, etc., ease application programming. + Maintain relationships among objects, such as overall resource constraints. + Persistence supports recovery after outages or other interruptions. XCMF bandwidth management over set of session objects Persistence service Saved session state videophone Web browse Movie Movie

27. App. A CANDIDATE DISTRIBUTED OBJECT SYSTEM: CORBA (Common Object Request Broker Architecture), standardized by the OMG (Object Management Group) - Widely accepted, in both computer and communications industries, for networked environments and heterogeneous computing platforms. - Pursuing a high level of interoperability between ORBs from different vendors (version 2.0), but not there yet! - Offers IDL (Interface Definition Language) for standard object interfaces, an “Esperanto” that translates into many computer languages. Java C IDL App. B Ref: “CORBA services: common object services specification, revised ed., OMG, July, 1996. See http://www.omg.org.

28. Java applet Java virtual machine .......... .......... .......... .......... WHY CAN’T JAVA APPLETS BE USED INSTEAD OF CORBA FOR INTEROPERABILITY? OS #1 OS #2 - They can be, if new applications are written for a virtual machine. - CORBA is appropriate when legacy applications, in different languages and on different machines, must be included in the system, or where large applications are best written in a native computing environment. - Joint use of Java applets and CORBA is possible, e.g. for conveying alterations to CORBA objects via Java applets.

29. WHAT IS THE RELATIONSHIP OF CORBA TO TINA-C? - TINA-C* is a distributed object network architecture addressing the objectives described earlier. - The TINA-C Consortium appears to be considering CORBA as the foundation ORB for its architecture, and is suggesting appropriate new features in CORBA. - CORBA offers a fresh opportunity to deploy a widely accepted and conceptually simple distributed object architecture in which many TINA functions can be realized in the ORB or in Object Services. * http://www.tinac.com/

30. CONCEPTUAL CORBA-BASED DISTRIBUTED OBJECT NETWORK ARCHITECTURE Library of helper applications multimedia application multimedia application abstract service abstract service object service object service Find service objects. Remote procedure call Distributed Object Environment Runs on TCP/IP Abstract Interface Control object Control object Administrative object Monitoring object Monitoring object Administrative object Network Resources

31. POTENTIAL CORBA INTERFACES Abstract services (include functions of UNI signaling entity) END SYSTEM NETWORK SYSTEMS CORBA wrapper Applications NM applications domain re- sources mgr admiss/ QoS policy CMIP interface CORBA Monitoring entity Control entity Administrative agent TCP/IP Proprietary Network(s) data Switch and/or router connection OA&M or routing

32. MM applic. MM applic. .......... .......... Control .......... .......... .......... .......... object services NIC WinNT .......... .......... Portable PC Wireless ATM functions NEC C&C RESEARCH LABS INTEGRATED ATM TESTBED* (Princeton, N.J.) MCCP NEC Model 5 switches 155Mbps abstract services Solaris MUX Display/camera/ storage devices Wireless ATM net initially T1 initially 8Mbps To Germany (MAY project) CORBA-based distributed object system under development MCCP: Multimedia C&C Prototype (ATM and media distribution functions) * Directed by D. Raychaudhuri

33. CONCLUDING OBSERVATIONS - A unifying software architecture can integrate diverse application and networking worlds. - The conceptual simplification of distributed object architecture may have performance costs that need to be addressed. Existing work suggests that good performance is possible with implementation care. Refs: 1) A. Lazar, S. Bhonsle, & K-S. Lim, “A binding architecture for multimedia networks”, J. Parallel & Distrib. Computing, vol. 30, 1995, pp. 204-216. 2) D. Schmidt, A. Gokhale, T. Harrison, & G. Prulkar, “A high performance endsystem architecture for real-time CORBA”, IEEE Commun. Mag., Feb., 1997. - Multimedia QoS-based services in broadband networks will be easier to realize and control with a distributed object architecture and libraries of object services and utilities.