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

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

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

4. What is OASIS TOSCA IPR Policy
TOSCA Charter, RF on Limited Terms:
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 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

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

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

7. TOSCA namespace defines the grammar and the normative types
Global Namespace URIs with Namespace Prefix mapping
Fully Qualifed URI
Namespace Prefix
Default Namespace
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 [
Short Name
Classification
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

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

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

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

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

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

13. Questions?
Q&A