OPEN NETWORKING IN THE INTERNET AGE Stephen B. Weinstein NEC USA C&C Laboratories Princeton, N.J., USA [email protected] OpenSig ‘97 Cambridge, England.

OPEN NETWORKING IN THE INTERNET AGE

Stephen B. Weinstein NEC USA C&C Laboratories Princeton, N.J., USA

[email protected]

OpenSig ‘97

Cambridge, England

April 17, 1997

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.

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.

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.

LANNAP

ISP

MBone

TCP, IP, Telnet, FTP, HTTP, ...

Proxy/relayserver

Web server

“Push” server

Internet telephony

Applets, agents, ...

Browser/virtual machine

ISP

ISP

LAN

RTP/TCP/IP

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.

Portion of voice switch capacity dedicated to Virtual Private Network customer.Customer control of trunk group cross connect.

Servicecontrol point

Advanced Intelligent Networkscripts for number translationand peripheral processing

LIMITED OUTSIDE PROGRAMMABILITY AND CONTROL: AINAND VPN

Local company

ISP

Long-distancecarrier

Local company

modem

Wirelesscarrier

Internet real-times servicesgateway (e.g. Internet telephony/PSTN)

Internet

ATTACHMENT OPENNESS FOR VOICEBAND SERVICES

END SYSTEMProprietary

NETWORK SYSTEMS

Switch and/orrouter

Applications

Commun. API

Signalingentity

Controlentity

NMapplications

Signalingentity

Managementagent

CMIP Q3

connection OA&Mor routing table

data

Proprietary

Measuringentity

admisspolicy

Call state

Proprietary

STANDARD CONTROL AND MANAGEMENT INTERFACES

UNI signaling:Dialing tones,Q.2931

NNIsignaling(e.g. ss#7)

& MIB

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.

CONTROL

ITU, ATMF

IETF

MANAGEMENT

Public NetworkingCommunity

Enterprise NetworkingCommunity

- Different opinions about who should control networks.

- Difficulty in reconciling public network security and QoS with Internet experimentation.

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).

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.

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”

OPENNESS TO CHANGES IN TECHNOLOGY UTILIZATION:

Example: routing and switching for Internet traffic.

Router Router

PSTN/ISDN switchToday:

Core Internet

ATMswitch

Router

Tomorrow:

Core Internet

Example: “Negroponte inversion”, compounded

TRADITIONAL MORE RECENT NEW

Video

CATVTo ISP

Someintelligence

DIGITALCABLE

Voice CO

cellular

Digitalbroadcast

to ISP

PCSInternet telephony

Web TV

NETWORK SOFTWARE ARCHITECTURE: AN OPPORTUNITY FOR A COMMON PERSPECTIVE

PSTNEnterprise

Internet

API

Distributed Processing

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.

edge switch

RSVP

SNMP

Q.2931

CMIP agent

Call admission control

GOALS FOR NETWORK SOFTWARE ARCHITECTURE

3. Support mobility of persons, terminals, and services.

SubscriberprofileHome Away

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”.

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

Middleware

call processing computing resources

Bandwidth resources

5.Make joint allocation of computing and communications 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)

6. Define open interfaces to switches and other network elements.

Control Administrate Observe

QoS informationResourceallocation

Managementqueries/responses

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.)

WHY INTEGRATE NETWORK CONTROL AND MANAGEMENT?

- Time scales are beginning to overlap.

- Functions are beginning to overlap.

A. Management of control policies and rapid changing of policies.

sec.001 .01 .1 1 10 100 1000

control

management

ControlPolicy Mngmnt

control

networkconditions

user/applicationrequirements

B. Reconfiguration tightly coupled to call admission/QoS renegotiation

Example: Reconfiguration of passband channel assignment to HFC customer (from channel “A” to channel “B”)

tunerA channel

MUX

....................

New servicerequest

existing

to headend

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.

Reconfiguration:-Reassign subscriber to. channel B.-Move existing session and new session to channel B

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. A

OS #1

OS #2

OS#3

ORB

ORB: Object Request Broker

App. B

App.C

- Location transparency and (when needed for mobility) location awareness.

“Connect me to the nearest pharmacy”

- 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 setof session objects

videophone Web browse Movie

Persistence service

Movie

Saved session state

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.

Ref: “CORBA services: common object services specification, revised ed., OMG, July, 1996. See http://www.omg.org.

App. A

JavaIDL

App. B

C

WHY CAN’T JAVA APPLETS BE USED INSTEAD OF CORBA FOR INTEROPERABILITY?

....................

Javavirtual machine

Java applet

....................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.

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/

CONCEPTUAL CORBA-BASED DISTRIBUTED OBJECT NETWORKARCHITECTURE

Distributed Object Environment

Network Resources

Abstract Interface

multimediaapplication

multimediaapplication abstract

serviceabstractservice object

serviceobjectservice

Monitoringobject

Monitoringobject

Controlobject

Controlobject

Administrativeobject

Administrativeobject

Library of helperapplications

Find service objects.Remote procedure call

Runs on TCP/IP

END SYSTEM

NMapplications

admiss/QoS policy

Applications

Abstract services(include functions of UNI signaling entity)

CORBA

domain re-sources mgr

Control entity Monitoringentity

Administrativeagent

connection OA&Mor routing

data

Proprietary

NETWORK SYSTEMS

Switch and/orrouter

Network(s)

POTENTIAL CORBA INTERFACES

CORBAwrapper

CMIPinterface

TCP/IP

WirelessATM net

NEC C&C RESEARCH LABS INTEGRATED ATM TESTBED*(Princeton, N.J.)

NEC Model 5 switches

PortablePC Wireless ATM

functions

155Mbps

initially 8Mbps

MCCP

....................

Display/camera/storage devices

MUX

To Germany (MAY project)

initially T1

....................

....................

NIC

objectservices

WinNT

MM applic.

....................

abstractservices

CORBA-based distributedobject system under development

MCCP: Multimedia C&C Prototype (ATM and media distribution functions)* Directed by D. Raychaudhuri

Solaris

Control

MM applic.

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.