© 2000 [email protected], cadenus.org, 1 Tequila workshop “Internet Design for SLS...

© 2000 [email protected], cadenus.org, 1Tequila workshop “Internet Design for SLS Delivery”, Amsterdam, 25-26.01.01

Service CreationService Creationin SLA Networksin SLA Networks

Michael Smirnov

GMD FOKUS, Global Networking

IST CADENUS - CCreation aand DDeployment of EnEnd-UUser SServices

in Premium IP Networks

.ORGWWW.


OutlineOutline

• IST CADENUS project objectives• Motivation for dynamic Service Creation• midcom and midcom++• Service Creation defined• Scalability, Security• Related work• Open Issues• Conclusions


ObjectivesObjectives

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 architecturesarchitectures coupled to their service surround.

Configuration and provisioning frameworkframework for end-user services with a range of call featurescall features and with

QoS guaranteesQoS guarantees

The CADENUS framework implementationimplementation aiming at enterprises and public operators

Trial and demonstrateTrial and demonstrate end-user services with QoS guarantees implemented via the framework

To disseminate the results in standardsstandards bodies and to the industryindustry in general


MotivationMotivation

• Each new service doublesdoubles the value of the network!• Domains negotiate moderate amountsmoderate amounts of wholesale services

(e.g. flow aggregates) on their boundaries via SLSs;• Each domain can construct manymany 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 pathvirtual 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


ApproachApproach

• 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 boxesmiddle boxes populate the Net (firewalls, NAT/PTs, RSIP gateways, QoS enforcement devices, PEPs, tunnel terminators, proxy servers, BBs, signature management, AAA, multimedia buffer management, application-aware 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 common framework for middlebox communicationframework for middlebox communication is needed.

• we assume a SC layer functionality and focus on fully fully distributed SC environmentdistributed SC environment at Premium IP layer


FocusFocus

CadenusCadenusfocusfocus

Service Creation PlaneService Creation Plane

Premium IP PlanePremium IP Plane

Networking PlaneNetworking Plane

AnalysisAnalysis

ResourcesResources

DesignDesign

SIP AAA

BB

FWNAT/PT RSIP

TT

SLA

SLS

NegotiationNegotiationComponentsComponents PoliciesPolicies

......

ATMATM

MPLSMPLSSONE

T

SONET

WDMWDM......

SLAN“MiddleBoxes”


“Externalised ALG”

“Externalised ALG”

Initial Initial midcommidcom View ViewIESG has approved Middle Box Communication (midcom) IETF working group

Middle boxRequest entity Policy entityProtocol 1 Protocol 2

Middle boxMiddle boxApplication server End entityProtocol 1

Policy entity

Protocol 2

Policy entity is orthogonal to Protocol 1Policy may be set for groups of clients (AS)

•Control of a forwarding engine

Possibly a Resource Manager for loadbalancing between multiple middle boxes

draft-kuthan-midcom-framework-00.txt

draft-tiphon-foglamps-01.txt


Dynamic service creation?Dynamic service creation?

SIP

AAA

BB

FW

NAT

RSIP

TT

...

PT

SIP

AAA

BB

FW

NAT

RSIP

TT

...

PTFull mesh Full mesh (Proto 1) ?(Proto 1) ?

Full mesh Full mesh (Proto 1) ?(Proto 1) ?

...

...

...

...

...

...

...

BB TT...

SIP TT...

SIP TT...

SIP AAA...

...

...

...

...

BB TT...

SIP TT...

SIP TT...

SIP AAA...

...

...

...

...

... ...

Proto 1 Proto 1 clientsclients

Proto 1 Proto 1 clientsclients

Proto 1 Proto 1 serversservers

Proto 1 Proto 1 serversservers


Sample PhasesSample 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*/


Service creation with midcomService 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 asynchronousasynchronous 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 multiplemultiple midboxes event notifications are to be passed to multiple locations

• Each midbox will need to dynamicallydynamically 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) ...


ENS ENS clientsclients


Event NotificationEvent Notification

MB3 MB2

MB1



MB1 MB3

MB2



MB1 MB2

MB3

Subscriber NotifierSubscribe(event)

Ack(Subscribe)

Notify

Notify...

Re-Subscribe(event)...

Unsubscribe(event)

Listen ENS_triggers;Start ENS(MBi, eventj, servicek, ...), Get_policy(ENS, MBi, eventj, servicek, ...)Parse Notify(MBi,...);...


MB3

CATCH solutionCATCH solution

CATCH CATCH

MB2

ENS ENS transporttransport

ENS ENS transporttransport

MB1

CATCH

SCSC_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 andset_policies

• subscribes to needed ENS groupsgroups onset_system

• maintains all ENS dependencies onset_service

get_componentsget_resourcesset_configset_policyset_systemset_service


CATCH Solution (cont-d)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, ...


Service CreationService 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 mediatorsmediators

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 anonymousevent tree - “all children” group - is a result of the service design phase (SC layer)


Provider’ ArchitectureProvider’ Architecture

•AAA•Directory/ yellow page•Preferences List•Service Menu•User Profile•Terminal type

•AAA•Presentation•Subscription

•Traffic Engineering•Terminal localization•Terminal Capability•Network capability

AccessMediator

Access NetworkProvide

r

Access NetworkProvide

rBackbone Network

Provider

Backbone NetworkProvider

Next NetworkProvider

Next NetworkProvider

ResourceMediator

ServiceMediator

GETSETGET


ScalabilityScalability

• 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;


SecuritySecurity

• No experience - focus on security as danger modelsdanger 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.


Related WorkRelated Work

The need for dynamic creation of services is recognised:

• IETF:– DiffServ, – SIP, – SPIRITS, – Midcom, – SLS, ...

• Elsewhere:– NGN, – JAIN, – Parlay, – DCS, ...


Open IssuesOpen 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


ConclusionConclusion

• 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, 1 Tequila workshop “Internet Design for SLS...

Documents

Transcript of © 2000 [email protected], cadenus.org, 1 Tequila workshop “Internet Design for SLS...