Service Creation in SLA Networks

1. WWW. .ORG Service Creationin SLA Networks Michael Smirnov GMD FOKUS, Global Networking IST CADENUS - Creation and Deployment of End-User Services in Premium IP Networks

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

3. 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 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

4. 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

5. 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, 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 framework for middlebox communication is needed. • we assume a SC layer functionality and focus on fully distributed SC environment at Premium IP layer

6. SLA SLS Focus Analysis Design Components Policies Resources Negotiation Service Creation Plane Cadenus focus NAT/PT FW RSIP ... ... “Middle Boxes” SLAN SIP AAA Premium IP Plane BB TT MPLS SONET Networking Plane ATM WDM ...

7. Initial midcom View IESG has approved Middle Box Communication (midcom) IETF working group draft-kuthan-midcom-framework-00.txt Protocol 1 Protocol 2 Request entity Middle box Policy entity “Externalised ALG” draft-tiphon-foglamps-01.txt Policy entity Policy entity is orthogonal to Protocol 1 Policy may be set for groups of clients (AS) Possibly a Resource Manager for load balancing between multiple middle boxes Protocol 2 Middle box Application server Protocol 1 Middle box End entity • Control of a forwarding engine

8. BB ... TT SIP SIP SIP ... TT ... BB BB SIP ... TT ... NAT NAT ... ... PT PT Full mesh (Proto 1) ? ... ... FW FW ... ... RSIP RSIP ... AAA ... AAA SIP ... AAA TT ... TT ... ... Dynamic service creation? BB ... TT SIP ... TT SIP ... TT ... Proto 1 servers Proto 1 clients ... ... ... SIP ... AAA ... ...

9. 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*/

10. 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) ...

11. Notifier Subscriber Subscribe(event) Ack(Subscribe) Notify Notify ... Re-Subscribe(event) ... Unsubscribe(event) Event Notification MB3 MB2 ENS clients MB1 MB3 ENS clients MB1 MB2 MB1 MB2 ENS clients MB3 Listen ENS_triggers; Start ENS(MBi, eventj, servicek, ...), Get_policy(ENS, MBi, eventj, servicek, ...) Parse Notify(MBi,...); ...

12. CATCH solution get_components get_resources set_config set_policy set_system set_service SC 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 midcomcommunication • configures ENS on set_config andset_policies • subscribes to needed ENS groups onset_system • maintains all ENS dependencies onset_service MB2 MB1 CATCH CATCH ENS transport CATCH MB3

13. 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, ...

14. 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 actionA atmidboxB; a - denotes ageing condition which is to be used by mediators to define the validity period of the eventE, 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)

15. Provider’ Architecture Service Mediator • AAA • Presentation • Subscription • AAA • Directory/ yellow page • Preferences List • Service Menu • User Profile • Terminal type • Traffic Engineering • Terminal localization • Terminal Capability • Network capability Resource Mediator Access Mediator SET GET GET Access Network Provider Next Network Provider Backbone Network Provider

16. 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;

17. 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.

18. Related Work The need for dynamic creation of services is recognised: • IETF: • DiffServ, • SIP, • SPIRITS, • Midcom, • SLS, ... • Elsewhere: • NGN, • JAIN, • Parlay, • DCS, ...

19. 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

20. 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