Transcript The TINA is dead, long live the TINA: towards - Tina-C

The TINA is Dead, long Live the
TINA:
towards programmable solutions for Next Generation
Networks
Alberto Cuda
Carlo A. Licciardi
Roberto Minerva
TINA Paris Conference
September 2000
MinervaR 001- 1
The Story of the TINA wine (1)
• The TINA wine was made blending grapes
from all the most important Telecom
Vineyards of the World (i.e., the most important TLC
players were there)
• The TINA winery was working hard on
new techniques to make and store wine
(i.e.,top-notch researchers were working on TINA)
• TINA companies were selling the product
(i.e., each TINA involved company had plans to exploit the
Architecture results)
• … but the market prefers Californian
Wines (i.e., the IP guys worked out their offering faster …)
TINA Paris Conference
September 2000
MinervaR 001- 2
The Story of the TINA wine (2)
• What’s the matter here ?
• TINA wine is for connoisseurs
(i.e., in order to appreciate it, you have to
understand all the technicalities of it: distributed
processing, APIs, layered architecture)
• TINA wine has a strong
character (i.e., it has its own strong vision
of the TLC world: business model and the
Reference Points)
• TINA wine is not cheap and it is
sold in bulk quantities (i.e., try to put
in place a TINA based solution …)
TINA Paris Conference
September 2000
MinervaR 001- 3
The Story of the TINA wine (3)
• … and how full is the TINA glass of
wine ?
• TINA wanted to give a complete (and
complex) solution
• TINA suffered the TLC based
approach for broadband
• TINA was not fully able to ride the
Internet wave
• TINA is not perceived as a currently
available standard solution (e.g., ION and
Forrester)
TINA Paris Conference
September 2000
MinervaR 001- 4
1 ¢ Advice to the future Service Architecture Winemakers:
the TINA Legacy
• Start from service requirements
• Think big (a service architecture), and act locally (a specific business
model and related services)
• Don’t reinvent from scratch when solutions are available
– Reuse existing protocols and APIs (cooperate instead of compete with the
Internet!!!)
– Don’t introduce cumbersome IWUs or Adapters to adapt to something not wholly
implemented yet (TINA)
• Avoid using catch-all call models (there is not such a thing as the
Universal Call Model, seems to be looking for the Graal)
• Have you noticed that signaling protocols are getting more and more
attention from the IP community ?
– The second youth of ISUP and INAP
– SIP
TINA Paris Conference
September 2000
MinervaR 001- 5
The best of TINA
• The TINA Business Model RPs (that should
have been used in order) to identify missing
bits in terms of relevant protocols and related
APIs
• Distribution of Functions (maybe not only CORBA, it’s the
market, baby!)
• Separation of access and usage
– Access Session and User Agent
– User/Service profile
– The Service Session (if only we would have mapped it to the
SIP!!!)
TINA Paris Conference
September 2000
MinervaR 001- 6
Which Control for Next Generation Networks? The
architecture as we know it ...
An NGN Configuration as An
proposed
by MSF
NGN Configuration
as proposed by
Softswitch Consortium
SCP
INAP
SIP Server
SIP
Media Gateway
Controller
SIP, H.323,ISUP +
Media Gateway
Controller
SS.7
PSTN/SS7
Megaco/H.248,
MGCP, IPDC
PSTN/SS7
IP
Network
Media Gateway
TINA Paris Conference
Media Gateway
September 2000
MinervaR 001- 7
TINA Challenge # 1: A Distributed Architecture for NGN (TINA
in the Internet Age)
Controlling Elements interoperate
Existing Services are
through DPE and APIs
Integrated in the
Architecture
Service features are exposed to
external applications through a
secure API
:
SCP
Existing Infrastructure
TINA goes here !
UA
Enterprise / Service
Provider
Service Layer
SSM
CSM
SS.7
PSTN/PLMN
IP
Network
Media Gateway
TINA Paris Conference
Network Elements are
controlled through
existing or under
Media Gateway
definition
protocols
September 2000
MinervaR 001- 8
Internet and Network Intelligence
Intelligence
Intelligence
Client
R
R
R
Server
“Dumb” Network
The IP network is
Internet
a pipe
Virtual
Contact Center
Environments
Trend
towards: Applications
E-commerce
• enrichment...of networking
Ok, the IP network functions
is a Dir
“pipe” …
GK
• SIP
decoupling
but a structured
one!!! of control
Network
Radius
Server
functionsCOPS
DNS
MM
Conferencing
Firewall
R
Multi
cast
TINA Paris Conference
R
Router/
Switch
September 2000
R
Networking
Elements
MinervaR 001- 9
A Distributed Service Architecture for IP
• Hypotheses: it is possible to build up a service layer for IP
Networks
– for new services and applications
– new intelligent functions
•
•
•
•
AAA policies
session control for Data/Voice (by means of SIP, H.323)
personalization by means of User Profile (using LDAP)
dynamic negotiation of QoS in relation to User Profile params (using
new protocols like COPS)
• controlled and secure access to Services (using Diameter, …)
• strong integration with user applications (e.g., Application Servers)
– using both communication models based on protocols and DPEs
– programmability (e.g., API, Scripting Language, CGI, ...)
TINA Paris Conference
September 2000
MinervaR 001- 10
TINA Challenge # 2: A Distributed Architecture
for IP (TINA in the Internet Age)
TINA goes here
IP Network
Applications
Client
Service
“Stub”
QoS
Communication
Services
Accounting
Policy
Directory
Multi-cast
Mobility
Stream
Server
E-commerce
MM
Conference
...
Application
layer
Session Control
User Profile
Security
DNS-DHCP
Service Control
layer
Network
Servers
Service
“Control”
Stream
Networking Elements: router, switch, host, media-gateways, firewall, etc.
Networking Services
TINA Paris Conference
Resource
layer
September 2000
MinervaR 001- 11
A closer Look to PBNs
N.B. Policy Manager is
aka Bandwidth Broker
There could be a
lot of TINA in here ...
User
Profile
SIP Server
LDAP
Policy
Manager
AAA Server
COPS
SIP
Radius
(e.g.,for
authorization)
:
COPS
Policy
Manager
COPS
COPS
or SNMP
MPLS
Policy
Manager
COPS
or SNMP
RSVP
SIP
RSVP
SIP
Policy Enforcement Point
PEP
(e.g., EdgeRouter, Firewall, …)
TINA Paris Conference
:
September 2000
MinervaR 001- 12
Protocols and TINA RPs
Bkr
SIP +RSVP
AAA
Ret
Consumer
(client)
Broker
Retailer
ConS
TCon
Conn.
Provider
RSVP,Q.931, ...
RtR
COPS,
INAP,
SNMP,
Radius, ...
COPS,
SIP, ...
Service
Provider
Consumer
(server)
ConS
FCon Conn.
Provider
P-NNI; BICC; SIP+;
COPS; MPLS;...
Give us APIs and we’ll
program the world (of services)
TINA Paris Conference
September 2000
MinervaR 001- 13
The programmers’ view of Service Layer:
lots of APIs
applications
Programming Libraries
network
capabilities
Client
resource
controllers
Abstraction
network applications
JAIN
Libraries
Service Provider Servers
Granularity (of functions)
client application
Parlay
Network Intelligence Servers
Terminals
Network (PSTN, PLMN, IP) Resources and Special Resources
TINA Paris Conference
September 2000
MinervaR 001- 14
Conclusions
• NGN are not considering Service Requirements
• TINA has acquired a long record of experiences in Service
Architecture, it can play a role in:
– supplying a software architectural rationalization to individual initiatives
from various fora and standardization bodies
• TINA can leverage the development of APIs
• TINA as a software architecture should have been able to
adapt to other Standards (TINA specs without IWUs!) and not
viceversa
• The next steps are to select some TINA solutions that can
promote the development of programmable service
architecture within the industry
TINA Paris Conference
September 2000
MinervaR 001- 15