OPEN NETWORKING IN THE INTERNET AGE Stephen B. Weinstein NEC USA C&C Laboratories Princeton, N.J., USA firstname.lastname@example.org OpenSig ‘97 Cambridge, England April 17, 1997. POSSIBLE INTERPRETATIONS OF “OPEN NETWORKING” - A meaningless term.
Stephen B. Weinstein
NEC USA C&C Laboratories
Princeton, N.J., USA
April 17, 1997
- 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.
- Attach any network using IP.
- Attach any user and any number of users (not constrained by switch ports or
- Join any multicast session you like (receiver-initiated).
- “Intelligence” largely in attachments, at user discretion.
- 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.
Applets, agents, ...
TCP, IP, Telnet, FTP, HTTP, ...
- 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.
Advanced Intelligent Network
scripts for number translation
and peripheral processing
Portion of voice switch capacity dedicated to Virtual Private
Customer control of trunk group cross connect.
gateway (e.g. Internet telephony/PSTN)
or routing table
STANDARD CONTROL AND MANAGEMENT INTERFACES
- Different philosophies for transport service (e.g. IP vs. ATM).
- Different communities developing standards.
- Different opinions about who should control networks.
- Difficulty in reconciling public network security and QoS
with Internet experimentation.
- Need to interoperate, especially for real-time services (e.g. Internet 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).
- Internet becoming performance-oriented.
* Developing consortium of ISPs to define performance measurement
- Telco implementation of data services (many becoming ISPs).
- Technologies facilitating openness to end-user control (transportable software,
- Potential common concepts of network software architecture.
AND TELEPHONE NETWORKS FOR OPENNESS IN SERVICES
email fax, voice messaging
Example: routing and switching for Internet traffic.
TRADITIONAL MORE RECENT NEW
NETWORK SOFTWARE ARCHITECTURE: AN OPPORTUNITY FOR
A COMMON PERSPECTIVE
1. Be simple and logical enough for reasonably intelligent people to understand.
2. Accomodate heterogeneity and programmability in equipment, policies, and
Example: Control and management of a switch under either ISO or IETF
Call admission control
3. Support mobility of persons, terminals, and services.
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
call processing computing 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)
Control Administrate Observe
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.
B. Reconfiguration tightly coupled to call admission/QoS renegotiation
Example: Reconfiguration of passband channel assignment to HFC customer
(from channel “A” to channel “B”)
-Reassign subscriber to.
-Move existing session and new
session to channel B
Digital passband channels (30Mbps each)
A B C D ........
Ref: Kolarov & Weinstein, “Flexible bandwidth allocation in hybrid fiber/coax distribution
networks”, Proc. IEEE Globecom ‘95, Nov., 1995.
App. A creation.
DISTRIBUTED OBJECT ARCHITECTURE CAN HELP
- Services abstractions hiding irrelevant details.
- Interoperability between applications written in different programming languages
and running on different computing platforms.
ORB: Object Request Broker
- Location transparency and (when needed for mobility) location awareness.
“Connect me to the
- 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
Saved session state
App. A over existing infrastructure.
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
Java applet over existing infrastructure.
WHY CAN’T JAVA APPLETS BE USED INSTEAD OF CORBA FOR
- 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? over existing infrastructure.
- TINA-C* is a distributed object network architecture addressing the objectives
- 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.
CONCEPTUAL CORBA-BASED DISTRIBUTED OBJECT NETWORK over existing infrastructure.
Library of helper
Find service objects.
Remote procedure call
Distributed Object Environment
Runs on TCP/IP
POTENTIAL CORBA INTERFACES over existing infrastructure.
(include functions of
UNI signaling entity)
MM applic. over existing infrastructure.
NEC C&C RESEARCH LABS INTEGRATED ATM TESTBED*
NEC Model 5 switches
object system under development
MCCP: Multimedia C&C Prototype
(ATM and media distribution functions)
* Directed by D. Raychaudhuri
CONCLUDING OBSERVATIONS over existing infrastructure.
- A unifying software architecture can integrate diverse application and
- 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.
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