OASIS TOSCA Report for December ONAP Event OASIS TOSCA - Cloud Portability, Lifecycle Management and more! Presenting on behalf of the TOSCA TC: Alex Vul Chris Lauwers Michael Brenner Shitao Li

Agenda IPR policy Namespace Suggests OASIS and ONAP to collaborate together:

What is OASIS IPR policy At the time a TC is chartered, the proposal to form the TC must specify the IPR Mode under which the Technical Committee will operate: RAND, RF on RAND terms, RF on limited terms or non-assertion. Current DSL is in YAML, legacy is XML

What is OASIS TOSCA IPR Policy TOSCA Charter, RF on Limited Terms: https://www.oasis-open.org/committees/tosca/charter.php#item-5 With TCs operating under the RF on Limited Terms IPR Mode, Obligated Parties may not impose any further conditions or restrictions beyond those specifically mentioned in Section 10.2.1 on the use of any technology or intellectual property rights, or other restrictions on behavior of the Licensee, but may include reasonable, customary terms relating to operation or maintenance of the license relationship, including the following: choice of law and dispute resolution. Current DSL is in YAML, legacy is XML

Agenda IPR policy Namespace Suggests OASIS and ONAP to collaborate together:

TOSCA Namespacing in TOSCA Service Templates In the TOSCA Simple Profile, TOSCA Service Templates MUST always have, as the first line of YAML, the keyword “tosca_definitions_version” with an associated TOSCA Namespace Alias value. This single line accomplishes the following: Establishes the TOSCA Simple Profile Specification version whose grammar MUST be used to parse and interpret the contents for the remainder of the TOSCA Service Template. Establishes the default TOSCA Namespace URI and Namespace Prefix for all types found in the document that are not explicitly namespaced. Automatically imports (without the use of an explicit import statement) the normative type definitions (e.g., Node, Relationship, Capability, Artifact, etc.) that are associated with the TOSCA Simple Profile Specification the TOSCA Namespace Alias value identifies. Associates the TOSCA Namespace URI and Namespace Prefix to the automatically imported TOSCA type definitions.

TOSCA namespace defines the grammar and the normative types Global Namespace URIs with Namespace Prefix mapping Fully Qualifed URI Namespace Prefix Default Namespace http://open.org/tosca/ns/simple/yaml/1.2/ tosca True <others to be added via “import”> Global Namespace – with sampling of v1.2 Types into v1.2 TOSCA Namespace Owning Namespace URI Full Name [http://docs.oasis-open.org/tosca/ns/simple/yaml/1.2/] Short Name Classification http://open.org/tosca/ns/simple/yaml/1.2/ tosca.nodes.Compute Compute nodes “ tosca.nodes.SoftwareComponent SoftwareComponent tosca.nodes.Storage.ObjectStorage ObjectStorage … tosca.relationships.HostedOn HostedOn relationships tosca.relationships.ConnectsTo ConenctsTo tosca.capabilities.Endpoint Endpoint capabilities tosca.capabilities.Container Container capabiltiies tosca.datatypes.Credential Credential datatypes tosca.datatypes.json json

Profiles & Conformance What is intended Approved, TOSCA Namespace URI - define a TOSCA-approved Namespace URI for the Profile’s Types that matches spec. version i.e., for default/target namespace Extensibility via Profile Types - define new Types needed to model the subject area for the Profile These Types would be bound to the TOSCA approved Namespace URI for the Profile Simplified Import – allow profile types to be imported “on-top” of TOSCA Simple Profile base types Ideally, “import” of a Profile’s Types should be accomplished with one (1) line of YAML Namespace Prefix: possible a reserved Namespace Prefix for the Profile Note: TOSCA base profile version compatibility is an issue to discuss What is not intended No new Grammar - Profiles are not allowed to define new grammar Should not define new “keywords” for TOSCA entities Profile WGs should submit uses cases to the Simple Profile WG that express needs in the base profile Limited ability to describe additional Requirements (prose) on individual Types e.g., describe special treatment of property/attribute values Perhaps “constraints” grammar is not expressive enough? or one Property value depends on another? Note: the Profile WG should try to submit uses cases to Simple Profile WG when they find limitations that could be fixed via the core grammar

Agenda IPR policy Namespace Suggests OASIS and ONAP to collaborate together: creation of tosca telco profile： work together with simple yaml term to enhance tosca normative types Work together with NFV adhoc group to establish a set of NFV/SDN normative types and the specification for their use Use OASIS TOSCA as a point of upstream integration with open source communities

what area in ONAP that tosca-nfv-profile wants to address Mainly focus on design time data model for VNF descriptor and NS descriptor. Align with ETSI NFV terminology and information model. Latest draft of tosca-nfv-profile: Tosca-nfv-profile-wd05-rev03 https://www.oasis-open.org/committees/document.php?document_id=62125&wg_abbrev=tosca

Why? Multiple parallel efforts to define information and data models in the telecom space ETSI – IFA011/014 and SOL001 OASIS – Simple YAML and NFV profiles ONAP – based om ECOMP, TOSCA, ETSI, TMF and MEF “Code is King” ONAP models may become defacto standards if enough operators and suppliers endorse them ONAP is moving faster than SDOs Multiple parallel architectural approaches for MANO ETSI ONAP OSM Market desire to reuse and portability of network services and network functions

Proposal for Collaboration Jointly work to enhance and extend the set Simple YAML Profile normative types Jointly work to define a set of SDN/NFV normative types for the telecom space Use TOSCA OASIS as a point of upstream integration for work being done in the open source community (ONAP & OSM)

Questions? Q&A