Transcript Open Networking in the Internet Age

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.
MBone
LAN
RTP/TCP/IP
NA
P
LAN
ISP
Internet telephony
ISP
Proxy/
relay
server
Browser/virtual machine
ISP
Web server
“Push” server
TCP, IP, Telnet, FTP, HTTP, ...
Applets, agents, ...
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.
LIMITED OUTSIDE PROGRAMMABILITY AND CONTROL: AIN
AND VPN
Service
control point
Advanced Intelligent Network
scripts for number translation
and peripheral processing
Portion of voice switch capacity dedicated to Virtual Private
Network customer.
Customer control of trunk group cross connect.
ATTACHMENT OPENNESS FOR VOICEBAND SERVICES
modem
Local company
Wireless
carrier
Long-distance
carrier
Internet realtimes services
gateway (e.g. Internet telephony/PSTN)
Local company
Internet
ISP
STANDARD CONTROL AND MANAGEMENT INTERFACES
END SYSTEM
Applications
NETWORK SYSTEMS
Proprietary
admiss
policy
Commun. API
Proprietary
Signaling
Signaling
Control
entity
entity
entity
UNI signaling:
Dialing tones,
NNI
Q.2931
signaling
(e.g. ss#7)
Call state
NM
applications
CMIP Q3
Management
agent & MIB
Measuring
entity
data
connection OA&M
or routing table
Proprietary
Switch and/or
router
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.
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
email
RSVP
“Esperanto”
CMIP
fax, voice messaging
Q.2931
OPENNESS TO CHANGES IN TECHNOLOGY UTILIZATION:
Example: routing and switching for Internet traffic.
Today:
PSTN/ISDN switch
Router
Router
Core Internet
Tomorrow:
Router
ATM
Core Internet
switch
Example: “Negroponte inversion”, compounded
TRADITIONAL
MORE RECENT
NEW
Digital
broadcast
Video
Some
intelligence
To ISP
CATV
Web TV
DIGITAL
CABLE
to ISP
Voice
CO
cellular
PCS
Internet telephony
NETWORK SOFTWARE ARCHITECTURE: AN OPPORTUNITY FOR
A COMMON PERSPECTIVE
API
PSTN
Enterprise
Internet
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.
Call admission control
Q.2931
CMIP
agent
edge switch
RSVP
SNMP
GOALS FOR NETWORK SOFTWARE ARCHITECTURE
3. Support mobility of persons, terminals, and services.
Home
Subscriber
profile
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
Middleware
Legacy network elements and technologies
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)
6. Define open interfaces to switches and other network elements.
Resource
allocation
Management
queries/responses
QoS information
Control Administrate Observe
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.
control
management
sec
.001
.01
.1
1
10
100
1000
user/application
requirements
- Functions are beginning to overlap.
A. Management of control policies and rapid changing of policies.
Control
Policy Mngmnt
control
network
conditions
B. Reconfiguration tightly coupled to call admission/QoS renegotiation
Example: Reconfiguration of passband channel assignment to HFC customer
(from channel “A” to channel “B”)
M
U
X
to headend
New service
request
existing
tuner
A channel
Downstream spectrum
..........
..........
Reconfiguration:
-Reassign subscriber to.
channel B.
-Move existing session and new
session to channel B
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.
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
App. A
..........
..........
ORB
OS #1
App.C
..........
..........
..........
..........
OS #2
ORB: Object Request Broker
- 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 set
of session objects
videophone Web browse
Movie
Persistence service
Saved session state
Movie
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
App. A
IDL
C
App. B
Ref: “CORBA services: common object services specification, revised ed., OMG, July, 1996. See
http://www.omg.org.
WHY CAN’T JAVA APPLETS BE USED INSTEAD OF CORBA FOR
INTEROPERABILITY?
Java applet
Java
virtual machine
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 NETWORK
ARCHITECTURE
multimedia multimedia
application application
Library of helper
applications
abstract
service
abstract
service
object
service
object
service
Find service objects.
Remote procedure call
Runs on TCP/IP
Distributed Object Environment
Abstract Interface
Monitoring
object
Control
object
Administrative
object
Monitoring
object
Network Resources
Control
object
Administrative
object
POTENTIAL CORBA INTERFACES
Abstract services
END SYSTEM
Applications
(include functions of
UNI signaling entity)
NETWORK SYSTEMS
CORBA
wrapper
NM
applications
domain resources mgr
admiss/
QoS policy
CMIP
interface
CORBA
Control entity
Monitoring
entity
Administrative
agent
TCP/IP
Proprietary
Network(s)
data
connection
or routing
OA&M
Switch and/or
router
NEC C&C RESEARCH LABS INTEGRATED ATM TESTBED*
(Princeton, N.J.)
MM applic.
MM applic.
MCCP
NEC Model 5 switches
155Mbps
abstract
services
Control
..........
..........
..........
..........
Solaris
MUX
Wireless
ATM net
initially
T1
object
services
Display/camera/
storage devices
NIC
WinNT
..........
..........
initially 8Mbps
Portable
PC
..........
..........
To Germany
(MAY project)
Wireless ATM
functions
* Directed by D. Raychaudhuri
CORBA-based distributed
object system under development
MCCP: Multimedia C&C Prototype
(ATM and media distribution functions)
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.