Entity Catalog ABE

The Entity Catalog ABE represents specifications and entities and their attributes, and associations for EntityCatalogSpecification, FederatedCatalogSpecification, EntityCatalog, and FederatedCatalog<br/><br/><font color="#e0121d"><b>Entity Catalog and Federated Catalog</b></font><br/><font color="#29313b">There are many cases when the specialization of the Catalog entities into ones for Product, Service, and Resource is not appropriate. Here are some examples below:</font><br/><ul>
<li><font color="#29313b">UC1: A wholesale SP organization wants to define a catalog of Price Condition specifications, so that the marketing department can assign Price Conditions to new product offerings in a consistent manner.</font></li><li><font color="#29313b">UC2: A fieldforce organization requires a catalog of Job Plan specifications, which they may use to define and allocate Job Plans to their internal and external subcontractors when they undertake infrastructure tasks.</font></li><li><font color="#29313b">UC3: A Catalog designer is in charge of specifying the TOSCA node templates, the TOSCA relationship templates and the TOSCA capability templates that will be available to build topology templates for the services in a SP organization. He requires to define a catalog to contain such kind of entities.</font></li></ul>
<font color="#29313b">It is clear, from the use cases above, that the corresponding entities cannot be categorised as Resource, Service or Product.</font><br/><font color="#29313b">For this reason, there is a need to introduce catalogs that could contain any specification and any entity and combine (federate) them in any way and to be able to create them dynamically at run time. </font><br/><font color="#e0121d"><b>Examples</b></font><br/><font color="#29313b">The following examples illustrate these requirements.</font><br/><font color="#29313b"><b>Creating a VNFCatalog</b></font><br/><font color="#29313b">A VNFCatalog is a fundamental requirement of ETSI NFV compliance. However, the ETSI NFV definition of a VNF Catalog is not specific, so vendor and provider implementations vary widely. Specifically:</font><br/><ul>
<li><font color="#29313b">VNF is not always offered as a Product</font></li><li><font color="#29313b">A VNF typically consumes Resources, but does not have to expose them</font></li></ul>
<font color="#29313b">A VNF typically produces Services but does not have to expose them. </font><br/>Therefore, a VNFCatalog can be something else than a ProductCatalog, ResourceCatalog or ServiceCatalog.<br/><b>Dynamic NFV Catalog Federation</b><br/>The capability to define and federate dynamically generic catalogs containing items belonging to both Service and Resource domains is illustrated in the Dynamic NFV Catalog Federation User Stories developed in ZOOM. Additional examples can be found in the Digital Services Reference Architecture Guide / Catalog Federation Direction tab.<br/><b>Catalog of atomic TOSCA Templates (Nodes and Capabilities)</b><br/>A Supplier builds atomic and composite value-added functions (aka. Topology Templates in TOSCA) that are ultimately sold to Service Providers. This Supplier has decided to use TOSCA to build the specifications of these functions.<br/>The first important internal step is for the Supplier to create a Catalog of Node Types, Node Templates and Capability Types and Capability Templates that will be available to his team of designers when building the functions.<br/>This Use Case is extensively developed in section 2.26 of the GB 978 document. It uses some of the key concepts of the TOSCA OASIS standard mapped to Entity Specification of the SID Information Model.<br/><b>Catalog of composite TOSCA Templates (Topologies)`</b><br/>Atomic TOSCA Templates (Nodes and Capabilities) can be assembled in a graph structure to form a composite Template (aka Service Template in TOSCA language).To be further studied.<br/><br/>