Jean-Marc Uzé Liaison R&E Networks and Institutions, EMEA Juniper Networks Mission & Concepts Organization & Milestones
Agenda • S ervice Provider Priorities • IPsphere Concepts and Design Goals • IPsphere Framework Overview • IPsphere Forum Organization & Milestones Slide 2
Service Provider Situation Analysis Transformation Yesterday Tomorrow S upport ongoing legacy Consumer $$ engine = Consumer $$ engine = service revenues Voice Content Transition to more flexible Business $$ engine = inter- lower cost infrastructure Business $$ engine = S aaS , office carriage hosting, managed services Proliferate broadband as platform for growth services S carce bandwidth = Time, Bandwidth not a limit = Enable service elements to distance, capacity-based Charge for higher level be contributed from variety charging resources of (internal & external) groups Vertical integration = Resources “ any-sourced” = S upport multi-technology, S ervice specific facilities S ervice agile facilities & multi-vendor resources & practices practices Address, pre-empt public policy Priorities weighted according to specific provider circumstances Slide 3
Requirement for Unprecedented Flexibility • Optical, Ethernet & IP can support almost any customer-facing service • But the conception of service most often supported today reflects Vertically integrated • S ingle-provider • S ingle-technology • • Flexibility demands service conceptualization without such limitations Slide 4
What is the IPsphere Forum? Mission: An enhanced commercial framework - or business layer - for IP services that preserves the fundamental ubiquity of the Internet’ s technical framework and is also capable of supporting a full range of business relationships so that participants have true flexibility in how they add value to upstream outcomes Slide 5
The IPsphere Business View Physical View Business View Inter-Carrier Interface - ICI Connection/ Transport Revenue from sale of Access/ Proj ection services service “ compensates” Buyer services for buyer’ s use of seller & partner resources S eller ( WWW S eller $$ Purple ) Profit Endpoint $$ (Content/ Processing) Buyer services S eller Partner A Endpoint resources EC/ P Resources Resources (Content/ Processing) EC/ P Partner C Resources A/ P C/ T Network resources Partner B (Access/ Proj ection) Resources C/ T (Connection/ Transport) Partner A Resources A/ P C/ T Slide 6
IPsphere Forum Focus IPsphere Forum Focus Business framework to Outcome is an IT Service maximise return from NGN framework; not a capabilities – leverages S OA Structuring set of network work (W3C, OAS IS , etc.) into Stratum specifications Telecom NGN context Network cont rol & Network Policy & intra-operator policy mechanisms; IMS , Control S tratum TIS PAN, TMF etc. “ Bearer” mechanisms Traffic from responsible bodies Handling such as IETF, ITU, MFA, S tratum DS L Forum etc. Slide 7
IPsphere Fundamental Concepts • Business-based service descriptions represent “ external” offerings • Translate descriptions to a set of resource behaviors that fulfill the functional requirements of those external service offerings • Resource behaviors can Represent both traditional network and IT service elements • Be contained completely within a single provider • Extend across provider boundaries • S ingle- or multi-technology • S ingle- or multi-vendor • Slide 8
High Level Roles Customer & order management Provider A e.g. IPTV IPsphere Administrative Owner (AO) S ervice S t ructuring S t ratum IPsphere scope IPsphere Element Owners (EO) Provider B Provider E Provider C Provider D e.g. Access e.g. DRM e.g. Transport e.g. Content Underlying resources Nesting of EOs supported as required Slide 9
EO & Element Nesting Retail relationships AO IPsphere scope EO 3 EO 1 EO 2 EO 2.1 EO 2.2 EO 3.1 EO 3.2 EO 3.1.1 EO 3.1.2 EO 3.1.3 EO 3.1.4 Slide 10
Composition and Decomposition Template-based abstraction ensures: Template representing external • Any service, any resource behavior can S ervice & its constituent Elements be represented • Inherent capability to support blending AO of different technologies, multi-vendor resources to enable a service Templates representing resource behavior of sets of technology resources EO1 EO2 EO3 EOn Enables separation of functionalities to be readily designed and implemented in order to pre-empt or respond to public policy & regulatory imperatives Slide 11
Harmonization of EO-AO Business Imperatives In composing a S ervice, AO selects Elements based on the technical behavior, and – Fields describing Element's technical behavior; where relevant - upon the commercial terms Likely to be the same for many partners offered to AO by the EO AO Commercial terms are never exposed publicly EO1 EO2 EO3 EOn Optional fields describing the commercial terms under which the Element is offered by EO to given AO(s); Likely to be different in order to reflect bilateral or multi-lateral commercial agreements between the EO and specific AOs Slide 12
Agreed Open Standard for Framework and Interfaces to Related Functions Template fields anticipated to leverage Clear interfaces to OS S , BS S systems & process maps per industry standard information models agreements with relevant S DOs (e.g. ITU NGN OS S , TMF eTOM) (e.g TMF S ID) S ervice presentation & order AO management Billing systems Clear interfaces to policy, network, device management systems per agreements with relevant S DOs (e.g. TMF MTOS I) & per EO1 EO2 EO3 EOn vendor-specific implementations Framework itself forms an agreed standard open to implementation by any company Clear, well understood interfaces to critical business functions, technology management systems & related sub-systems such as IMS Slide 13
IPsphere Framework Overview • Framework Context and Components • Element Publishing • S ervice Architecting • Element S election • S ervice/ Element Activation • S ervice Assure Phase Slide 14
Framework in Context Overall business obj ectives Highest Level Technical Framework - S OA scope of Release 1 Technical IPsphere Framework Current focus S pecification Flows Templates Interfaces Extension topics Integration with strata below -Policy & Control via “ xMS ” - Physical resources Slide 15
Decomposed, Non-monolithic Framework • Enables providers to choose best-of-breed components • Lowers barrier to participation > more innovators in IPS F validations, showcases etc. • Facilitates integration of IPsphere framework with other software, hardware systems • Facilitates diagnostics in validations, showcases etc, & enables certification in tests • Allows multiple copies of key functional components to be run on different systems Slide 16
IPsphere Framework Functions User Requests External to IPsphere, Logging of user input presents S ervice to for all S S events to user, handles provides j ournal for requests for S ervice other processes (e.g. Presentation from users TMF eTOM) & Ordering Event Logging Reticulat es versions Decomposes S ervice Publisher of S ervice/ Element Instance Templates SMS Admin. Templates as into Element s, required by other selects optimum obj ects (via a Elements. Manages how Element Alerts registry/ directory) impact specific Architect S ervice(s) Creates Model SMS Parent Alert Client Templat es for all S ervices/ Elements Dispatches scripts – via S S S - to Element Owner in order to Receives Alert validate & invoke S S S Message “ Bus” messages from the S S Elements selected for Clients, dispatches a S ervice Alerts to S S Admin after applying Translates Element- queuing policies relat ed S S S messages into resource SMS Child S hared messaging provisioning environment - any commands platform for secure Generates Alerts if communication: VPN, underlying resource LAN behavior violates To xMS systems agreed metrics Slide 17
Element Publishing and Visibility • EOs publish and/ or update Elements relatively infrequently Element publication is out-of-band – assumed not to traverse S S S • • Elements are selectively visible to specific AO, or groupings of AOs According to EO-AO commercial relationships • • 2 potential approaches to AO Element repositories Distributed registry; e.g. a WS that appears as a directory • Central registry; e.g. directory of Elements maintained by third • party Slide 18
Service Architecting • All presented S ervices and offered Elements are architected pre-order No S ervice Provider interest in automating solicitation of custom • offers AO, EO are therefore always taking a “ proactive” stance • • Possible for AO, EO to take “ reactive” approach (via non-IPS F means) Retail AO could “ solicit” custom Elements from partner EOs • If a solicitation is made & positively responded to • Publication of the resulting custom Element(s) would be IPsphere in- • scope Custom Element should be visible ONLY to the original solicitor • Slide 19
Recommend
More recommend
