Download No Slide Title

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Telecommunication wikipedia , lookup

Transcript
WWW.
.ORG
Service Creation
in SLA Networks
Michael Smirnov
GMD FOKUS, Global Networking
IST CADENUS Creation and Deployment of End-User Services
in Premium IP Networks
© 2000 [email protected], cadenus.org,
1
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Outline
•
•
•
•
•
•
•
•
IST CADENUS project objectives
Motivation for dynamic Service Creation
midcom and midcom++
Service Creation defined
Scalability, Security
Related work
Open Issues
Conclusions
© 2000 [email protected], cadenus.org,
2
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Objectives
To develop, implement, validate and demonstrate a framework for the
configuration and provisioning of end-user services with QoS
guarantees in Premium IP networks
Premium IP transport architectures coupled to
their service surround.
Configuration and provisioning framework for
end-user services with a range of call features and
with QoS guarantees
The CADENUS framework implementation aiming
at enterprises and public operators
Trial and demonstrate end-user services with QoS
guarantees implemented via the framework
To disseminate the results in standards bodies
and to the industry in general
© 2000 [email protected], cadenus.org,
3
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Motivation
• Each new service doubles the value of the network!
• Domains negotiate moderate amounts of wholesale services
(e.g. flow aggregates) on their boundaries via SLSs;
• Each domain can construct many retail services conforming to
negotiated wholesale SLSs
• Dynamic service creation fits best services with call features and
service bundles:
– e.g.#1: IP Telephony based on SIP uses the same virtual path
between Src and Dst but
• SIP signalling data is mapped to wholesale BE PHB
• Media (VoIP) data is mapped to wholesale EF PHB
– e.g.#2: Packaged service offers (~VPN):
• many service components are provided independently
• => need for a complex service composition
• Binding of service components per SLA
© 2000 [email protected], cadenus.org,
4
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Approach
• Intelligent Networks Service creation (SC): interrupting the basic
call chain and consulting with additional [remote] intelligence, which
resolves the signalling request in question and returns a routable entry
thus enabling the call chain to be completed.
• No straightforward mapping to IP
• New IP services are created on a per service basis - more and
more middle boxes populate the Net (firewalls, NAT/PTs, RSIP
gateways, QoS enforcement devices, PEPs, tunnel terminators, proxy servers,
BBs, signature management, AAA, multimedia buffer management, applicationaware caching, load balancers, third-party SA provisioning, SMTP relays, ...)
• middle boxes comprise a Premium IP layer.
There is no way to
achieve service guarantees without middle boxes, however a common
framework for middlebox communication is needed.
• we assume a SC layer functionality and focus on fully distributed
SC environment at Premium IP layer
© 2000 [email protected], cadenus.org,
5
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Focus
Analysis
SLA
Design
Components
Negotiation
Policies
Resources
Service Creation Plane
SLS
Cadenus
focus
SLAN
NAT/PT
...
FW
RSIP
...
SIP
AAA
BB
MPLS
Premium IP Plane
TT
SONE
T
Networking Plane
ATM
...
WD
M
© 2000 [email protected], cadenus.org,
6
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
“Middle
Boxes”
Initial midcom View
IESG has approved Middle Box Communication (midcom) IETF working group
draft-kuthan-midcom-framework-00.txt
Protocol 1
Request entity
“Externalised
ALG”
Protocol 2
Middle box
draft-tiphon-foglamps-01.txt
Policy entity is orthogonal to Protocol 1
Policy may be set for groups of clients (AS)
Policy entity
Protocol 2
Protocol 1
Application server
Policy entity
Middle
box
Middle
box
Possibly a Resource Manager for load
balancing between multiple middle boxes
End entity
•Control of a forwarding engine
© 2000 [email protected], cadenus.org,
7
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Dynamic service creation?
BB ...
SIP ...
SIP ...
TT
SIP
TT
BB
TT
NAT
...
Proto 1
...
clients
PT
FW
...
RSIP
...
AAA
TT
SIP ... AAA
...
...
...
...
...
...
...
Full mesh
(Proto 1) ?
SIP
BB ...
TT
BB
SIP ...
TT
NAT
SIP ...
TT
PT
...
FW
Proto 1
servers
...
RSIP
...
...
AAA
...
...
TT
...
© 2000 [email protected], cadenus.org,
8
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
SIP ... AAA
...
Sample Phases
A service request pertaining to SLA_ID# arrives:
¿ Do I have corresponding service instantiated?
No  /*Yes  proceed with regular invocation */
¿ Do I know how to create the service(SLA_ID#) instance?
Yes  get_components(); /*No  e.g. error condition handling*/
¿ Do I have all needed service components?
Yes  /*No  e.g. relaxed service offer*/
¿ Do I know how to configure all components?
Yes  set_config(); get_resources();
/*No  e.g.request a repository and cache the result*/
¿ Do I have enough resources?
Yes  set_policies(); /*No  e.g.offer relaxed service guarantees*/
set_system(); /*establish “communicate with” relation between midboxes*/
set_service(); /*establish “dependency” relation between midboxes*/
© 2000 [email protected], cadenus.org,
9
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Service creation with midcom
• Dynamic service creation requires that SC layer communicates
to network middle boxes (service components) how should they
properly inter-work with each other during service delivery
(additionally to their legacy communication)
• Services which do NOT require this can be created on e2e basis
and are, probably, not composite services
• Composite services require asynchronous actions in different
locations along a virtual path (e.g. following phases of signalling)
 distributed state maintenance  Event Notification Service is
needed (Proto 1 above is ENS protocol)
• Composite services involve multiple midboxes  event
notifications are to be passed to multiple locations
• Each midbox will need to dynamically activate many ENS
clients, and correlate many events and message formats
• ... too complex to be realistic (next slide is for 3 boxes and a
single service) ...
© 2000 [email protected], cadenus.org,
10
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Event Notification
MB3
ENS
clients
MB1
MB3
ENS
clients
MB1
Subscribe(event)
Ack(Subscribe)
Notify
Notify
...
MB2
MB1
MB2
ENS
clients
Notifier
Subscriber
MB2
Re-Subscribe(event)
...
Unsubscribe(event)
MB3
Listen ENS_triggers;
Start ENS(MBi, eventj, servicek, ...),
Get_policy(ENS, MBi, eventj, servicek, ...)
Parse Notify(MBi,...);
...
© 2000 [email protected], cadenus.org,
11
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
CATCH solution
SC_Request(SLA)
SC environment in Premium IP
layer is a set of SC aware middle
boxes, i.e. those with CATCH CAdenus Transaction Chorus.
CATCH:
• assists midboxes involved in SC;
• is transparent for legacy midcom
communication
• configures ENS on set_config and
set_policies
• subscribes to needed ENS groups on
set_system
• maintains all ENS dependencies on
set_service
SC
get_components
get_resources
set_config
set_policy
set_system
set_service
MB1
MB2
CATCH
CATCH
ENS
transport
CATCH
MB3
© 2000 [email protected], cadenus.org,
12
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
CATCH Solution (cont-d)
• All communications in SC are group communications
• SC groups:
– functional groups of middle boxes:
• e.g. all NAT/PT of a domain
– service specific groups of middle boxes
• e.g. all FWs and all BBs involved in SIP based call
• ENS in SC provides only atomic communication, while SC itself
is a transaction
• Each ENS atomic communication (group) triggers next ENS
communication (group)  SC is a recursive group
communication
• CATCH modules are mediators and may be of different types
– access mediator, service mediator, resource mediator, ...
© 2000 [email protected], cadenus.org,
13
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Service Creation
The service creation in our approach is based on event notification
system which merges disjoint distributed states maintained on a
per-protocol and on per-service basis in many network nodes by
means of group communication between mediators
Event E = {A, B, T°, a, t},
T° - denotes a set of post conditions produced by action A at midbox B;
a - denotes ageing condition which is to be used by mediators to define the
validity period of the event E,
t - a timestamp of A.
Features:
an event (action + all its post-conditions) is temporarily not
anonymous
event tree - “all children” group - is a result of the service design
phase (SC layer)
© 2000 [email protected], cadenus.org,
14
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Provider’ Architecture
Service
Mediator
Access
Mediator
•AAA
•Directory/ yellow page
•Preferences List
•Service Menu
•User Profile
•Terminal type
Resource
Mediator
GET
GET
Access
Network
Provide
r
•AAA
•Presentation
•Subscription
•Traffic Engineering
•Terminal localization
•Terminal Capability
•Network capability
SET
Backbone Network
Provider
© 2000 [email protected], cadenus.org,
15
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Next
Network
Provider
Scalability
• Not to compare with technologies uncapable of dynamic service
creation,
• To compare with:
– Centralised solutions,
– Per-service solutions
• Our solution scales, because of:
– substitution of session based coupling of network components by
event-based coupling;
– independence of service components (middle boxes) from service
creation components (CATCH, ENS);
– separation of levels (AM, SM, RM, and further retail and
wholesale);
– inherit easiness to introduce a hierarchy of catch modules and load
balancing;
© 2000 [email protected], cadenus.org,
16
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Security
• No experience - focus on security as danger models
identification at run-time
• we try to show how we can build a system which has a security
features inherited from the system design:
– not to have any central entity responsible for a service creation; this
entity could be easily identified and attacked;
– all atomic communications comprising a service creation
transaction are group communications which will always have
• silent receivers providing on-line auditing of atomic transactions (by this
a very early detection of attack, learning and self-configuring secure
groups are possible) and event correlation;
• - group membership information (e.g. conveyed in a group address)
protected by e.g. private group address management.
– to use the encryption, which is for further study.
© 2000 [email protected], cadenus.org,
17
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Related Work
The need for dynamic creation of services is
recognised:
• IETF:
–
–
–
–
–
DiffServ,
SIP,
SPIRITS,
Midcom,
SLS, ...
• Elsewhere:
–
–
–
–
NGN,
JAIN,
Parlay,
DCS, ...
© 2000 [email protected], cadenus.org,
18
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Open Issues
• It is hard to design
– a new design paradigm and design tools will be helpful
• 3rd party SC components
– we shall define a CATCH interface for third party event notifications
and, maybe, for third party service components
• ENS with untrusted boxes
– establishment of trust relationship between entities not always can
be synchronised with availability of a distributed state information
(event)
• Danger models
– a brand new area
• Performance
– shall define special purpose experiments
© 2000 [email protected], cadenus.org,
19
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01
Conclusion
• Dynamic creation of new services will be an enabling technology
for many end-user services and applications including those
accessible from lightweight Internet terminals (PDA, handy, etc.)
• A fully distributed service creation framework based on recursive
group event notification is proposed for dynamic creation of
premium IP services out of existing network elements -middle
boxes - which are assembled in a service system and
configured in a SLA/SLS conformant way
• We distribute complexity between processing in nodes and
communication in such a way that existing network elements
and service creation environment can evolve independently
© 2000 [email protected], cadenus.org,
20
Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01