LSO Hackathon Summary Charles Eckel, Cisco DevNet.

Slides:



Advertisements
Similar presentations
SDP Value Add in a Cloud Web 2.0 World Eric G Troup CTO, WW Communications & Media Industry Microsoft Corporation ITU Workshop on “Service Delivery Platforms.
Advertisements

1 Introducing the Specifications of the MEF MEF 50: Carrier Ethernet Service Lifecycle Process Model.
Cloud Management Challenge Human experts in specific IT infrastructure and business domains possess substantial knowledge about prevention, remediation,
This document is an OASIS SAF TC Working Draft. It does not reflect the views of the OASIS SAF TC or of OASIS Cloud Management Challenge Human experts.
TOSCA Monitoring Reference Architecture Straw-man Roger Dev CA Technologies March 18, 2015 PRELIMINARY.
JEMMA: an open platform for a connected Smart Grid Gateway GRUPPO TELECOM ITALIA MAS2TERING Smart Grid Workshop Brussels, September Strategy &
1 Light Reading Ethernet Europe – Frankfurt – April 2013 Ralph Santitoro MEF Director and Co-chair of CE4Cloud/SDN Project Director of Strategic Market.
Objective: Enable portability and semi-automatic management of applications across clouds regardless of provider platform or infrastructure thus expanding.
IP Offices and the Implementation of the WIPO Development Agenda: Challenges and Opportunities September 18, 2009 Geneva Irfan Baloch World Intellectual.
GEN15 LSO Hackathon. Session Topics LSO Hackathon vision (GEN15 and beyond) GEN15 LSO/CE 2.0 oriented scope (review of the diagram) and defined outputs.
Independent Insight for Service Oriented Practice Summary: Service Reference Architecture and Planning David Sprott.
GRID ANATOMY Advanced Computing Concepts – Dr. Emmanuel Pilli.
Charles Eckel, Cisco DevNet WELCOME TO THE Agenda and Code Contributions.
Open Source and Info Models 17 Dec 2015 Bryan Sullivan, AT&T.
Dynamic APIs for the Connected Carrier Catalyst Co-Leads Dave Duggal, EnterpriseWeb, CloudNFV Greg Tilton, DGIT, Agile Markets.
OUTCOMES OBJECTIVES FUNCTIONS ACTIONS TERRITORIES LOCATIONS MARKET SEGMENTS TIME LINESCHALLENGE IMPACT RESOURCESACTIVITIESCHANNELS RELATIONS PARTNERS CUSTOMERS.
14 March 2016 Bryan Sullivan, AT&T Artur Tyloch, Canonical
Some considerations and ideas for the (next) future Roberto Barbera University of Catania and INFN IWSG’10.
Integrated ALM with Cross-Tool Reporting Kovair Marketing Kovair Software Copyright ©
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
ONAP and MEF LSO External API Framework Functional Reference Architecture 12 July 2017 Andy Mayer, Ph.D. © 2016 AT&T Intellectual Property. All rights.
Rationalizing ONAP Architecture for R2 and Beyond Vimal Begwani – AT&T
LSO Innovation Platform
Euro17 LSO Hackathon Open LSO Analytics
ONAP layering/MEF alignment
Defining ONAP APIs With BSS/OSS
MEF Modeling Activities
ONAP Architecture Meeting 8/8
Instructor Materials Chapter 7: Network Evolution
LSO Hackathon Kickoff Charles Eckel.
14 April 2016 Bryan Sullivan, AT&T
Lifecycle Service Orchestration (LSO) Models in context
LSO Innovation Platform Micro-Services
Multi-layer software defined networking in GÉANT
Service Orchestration Functionality- Service Decomposition
MEF Common Information Model Overview
AT&T Marketplace for Enterprise MEF Hackathon
OPEN-O Modeling Directions (DRAFT 0.6)
Current Framework and Fundamental Concepts
ONAP Architecture Meeting 8/8
Building Custom Workflows
MEF Modeling Activities
LSO Hackathon Kickoff Charles Eckel.
MEF Q2, April Frankfurt, Germany
Goals and Objectives Project(s): Technical Specification for SD-WAN Service Definition Purpose of the contribution: To describe the proposal and have an.
MEF LSO Legato SDK 24 October 2017 Andy Mayer, Ph.D. Tara Cummings.
ONAP Integration to External Domain Management Systems (DMS)
Distribution and components
Goals and Objectives Project(s): Technical Specification for SD-WAN Service Definition Purpose of the contribution: To describe the proposal and have an.
17 Dec 2015 Bryan Sullivan, AT&T
IMTC SIP Interconnect and SuperOp
IMTC SIP Interconnect and SuperOp
Using the MEF Core Model in ONAP John Strassner, Ph. D. Andy Mayer, Ph
Use Cases and Requirements for I2NSF_
Intent Based Orchestration for Applications
ONAP APIs Andrew Mayer, AT&T
MEF 3.0.
ONAP Amsterdam Architecture
Consideration of Modeling Evolution in ONAP Michela Bevilacqua Peter Wörndle and Tara Cummings 13 December , 2017.
MEF API Development Approach
ETSI Multi-access Edge Computing:
ONAP Beijing Architecture Chris Donley 1/9/18
Phaethon: a lightpath provisioning adapter for LightSoft
ATIS’ Cloud Activity Andrew White Nokia Siemens Networks
Introduction to SOA Part II: SOA in the enterprise
System architecture, Def.
Test Domain and Description Language Recommendations
ONAP Architecture Principle Review
Karthik Sethuraman, NEC
Presentation transcript:

LSO Hackathon Summary Charles Eckel, Cisco DevNet

Series of events facilitated by MEF to: Accelerate pace and relevance of MEF APIs and standards Catalyst for use of APIs in OpenLSO and OpenCS projects Provide feedback into technical committees Create open source reference implementations, libraries, tools Collaboration across SDOs and Open Source communities Increase awareness, promote open discussions Add support for LSO APIs in relevant open source projects Contribute upstream More running code! Next Hackathon

MEF Open Initiative Open Initiative MEF Committees MEF Agile Development Lifecycle ACCELERATOR NORMATIVE SPECS, CERTIFICATIONS & MARKETING Steering Group RULES, TOOLS, IPR, GOVERNANCE Informative Reference Implementations Liaisons to SDOs Open Source Projects PLATFORM Services Operations Orchestration Collaboration LSO Hackathon + prep + follow-up move OpenLSO and OpenCS projects forward, result in upstream contributions to open source and feedback to MEF committees

Spirit of the Hackathon Collaborative Friendly competition, Break down silos Sharing Exchange insights, tips, ideas Joint effort to increase pace and quality of LSO APIs and implementations Open Non MEF members can participate Specs made available Free No fee, no prize $$$

Business Applications History Customer Domain SP Domain Partner Domain Cantata (CUS:BUS) Business Applications Sonata (BUS:BUS) Business Applications Customer Application Coordinator LEGATO (BUS:SOF) LEGATO (BUS:SOF) Service Orchestration Functionality Service Orchestration Functionality Allegro (CUS:SOF) Interlude (SOF:SOF) GEN15, Nov ‘15 PRESTO Euro16, April ‘16 PRESTO, SONATA MEF16, Nov ‘16 PRESTO, SONATA, LEGATO, and more Presto (SOF:ICM) Presto (SOF:ICM) Infrastructure Control and Management Infrastructure Control and Management ADAGIO (ICM:ECM) ADAGIO (ICM:ECM) Element Control and Management Element Control and Management Definition of LSO Ecosystem Components (From Section 9.1 of MEF 55) Business Applications (BUS): The Service Provider functionality supporting Business Management Layer functionality (e.g., product catalog, ordering, billing, relationship management, etc.).  Service Orchestration Functionality (SOF): The set of service management layer functionality supporting an agile framework to streamline and automate the service lifecycle in a sustainable fashion for coordinated management supporting design, fulfillment, control, testing, problem management, quality management, usage measurements, security management, analytics, and policy-based management capabilities providing coordinated end-to-end management and control of Layer 2 and Layer 3 Connectivity Services.  Infrastructure Control and Management (ICM): The set of functionality providing domain specific network and topology view resource management capabilities including configuration, control and supervision of the network infrastructure. ICM is responsible for providing coordinated management across the network resources within a specific management and control domain. For example, a system supporting ICM capabilities provides connection management across a specific subnetwork domain. Such capabilities may be provided within systems such as subnetwork managers, SDN controllers, etc. Section 9.1.1 provides some ICM implementation examples.  Element Control and Management (ECM): The set of functionality supporting element management layer capabilities for individual network elements. While a system supporting ECM capabilities provides for the abstraction of individual infrastructure elements, it may reflect the element view for multiple elements, but not provide coordinated management across the set of elements.  Customer Application Coordinator (CUS): A functional management entity in the Customer domain that is responsible for coordinating the management of the various service needs (e.g., compute, storage, network, etc.) of specific applications. The AC may be responsible for the harmonization of cloud services on behalf of multiple applications. The AC supports Customer interactions with the Service Provider to request, modify, manage, control, and terminate Products or Services. Definition of interface reference points (From Section 9.2 of MEF 55) CANTATA (CUS:BUS): The Management Interface Reference Point that provides a Customer Application Coordinator (including enterprise Customers) with capabilities to support the operations interactions (e.g., ordering, billing, trouble management, etc.) with the Service Provider’s Business Applications for a portion of the Service Provider service capabilities related to the Customer’s Products and Services (e.g., Customer Service Management interface). Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  ALLEGRO (CUS:SOF): The Management Interface Reference Point that allows Customer Application Coordinator supervision and control of dynamic service behavior (see Section 8.2.3) of the LSO service capabilities under its purview through interactions with the Service Orchestration Functionality. When a Customer exercises dynamic service behavior via Allegro, the Service Orchestration Functionality must validate each request using the Service specific policies that govern such dynamic behavior. Such dynamic behavior and associated constraints are defined based on the Product Specification implemented by the Service. For example, a Service specific dynamic service policy may describe the range of bandwidth in which the Customer is permitted to throttle. Allegro may also be used to share service level fault information with the Customer. Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  LEGATO (BUS:SOF): The Management Interface Reference Point between the Business Applications and the Service Orchestration Functionality needed to allow management and operations interactions supporting LSO connectivity services. For example, the Business Applications may, based on a Customer order, use Legato to request the instantiation of a Connectivity Service. Legato may also allow the SOF to describe Services and capabilities it is able to instantiate. Also, the Service Orchestration Function may use Legato to ask the Business Applications to place an order to a Partner provider for the access service needed as a Service Component of an end-to-end Connectivity Service.  SONATA (BUS:BUS): The Management Interface Reference Point supporting the management and operations interactions (e.g., ordering, billing, trouble management, etc.) between two network providers (e.g., Service Provider Domain and Partner Domain). For example, the Service Provider Business Applications may use Sonata to place an order to a Partner provider for an access service that is needed as a part of an end-to-end Connectivity Service. Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  INTERLUDE (SOF:SOF): The Management Interface Reference Point that provides for the coordination of a portion of LSO services within the partner domain that are managed by a Service Provider’s Service Orchestration Functionality within the bounds and policies defined for the service. Through Interlude, the Service Orchestration Functionality may request initiation of technical operations or dynamic control behavior associated with a Service with a partner network domain (see Section 8.2.3). Such requests must be within the constraints set forth in the policies associated with established Services and performed without impacting business applications. For example, to satisfy a Customer request, the Service Orchestration Functionality may request changes to a CE-VLAN ID mapping at a UNI that resides in a partner domain. Interlude may also be used to share service level fault information with the partner domain. Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  PRESTO (SOF:ICM): The resource Management Interface Reference Point needed to manage the network infrastructure, including network and topology view related management functions. For example, the Service Orchestration Function will use Presto to request ICM to create connectivity or functionality associated with specific Service Components of an end-to-end Connectivity Service within the domain managed by each ICM. Presto may also allow the ICM to describe Resources and capabilities it is able to instantiate.  ADAGIO (ICM:ECM): The element Management Interface Reference Point needed to manage the network resources, including element view related management functions. For example, ICM will use Adagio to implement cross-connections or network functions on specific elements via the ECM functionality responsible for managing the element. Network Infrastructure

Euro17 Hackathon Mark your calendar MEF Q2 Meeting April 24-27, 2017 Europe, exact location tbd

LSO Hackathon Project Results