<p>Copyright TM Forum 2006-2008<br/></p><p><br/></p><p><b>Overview</b><br/></p><p>The Service Inventory holds the following  types of information<br/></p><p><ol><li>The mapping of Product Specifications to Service Specifications and of Product Instances to Service Instances.</li><br/></p><p><li>The mapping of service to service components. The components being either pure Service Layer features, or the resource features and the resource domain managers used to implement these features.</li><br/></p><p><li>The domain level service implementation in the resource. This is the service, the domain manager that delivers the service and the inter-domain Access Point to Access Point relationships. Note that if the domain manager design decision is based on the network inventory model, then this aspect of the inventory is in the service & resource layer.</li><br/></p><p></ol><br/></p><p><b>Functionality</b><br/></p><p><b>Service Inventory Retrieval</b><br/></p><p>This feature allows for client OSS to retrieve part or all of the service inventory known to the target OSS.<br/></p><p>This feature may allow the following selection criteria:<br/></p><p><ul><li>retrieval based on attribute matching</li><br/></p><p><li>retrieval of only the object instances that have been modified after a provided date and time.</li><br/></p><p></ul>For the selected objects, this feature may allow the client OSS to specify what specific attributes and relationships shall be returned.<br/></p><p><br/></p><p><b>Service Inventory Update Notifications</b><br/></p><p>This feature entails the generation of inventory update notifications based on changes to the inventory known to a given OSS. The notifications concerning object creation, object deletion and attribute value changes.<br/></p><p>Single Entity Notifications - in this variation of the feature, each notification pertains to only one entity, e.g., an IP VPN service instance<br/></p><p>Multi-entity Notifications - in this variation of the feature, a single notification may report on inventory changes for multiple entities. <br/></p><p><br/></p><p><b>Service Inventory Update</b><br/></p><p>This feature entails an OSS requesting that another OSS (referred to as the target OSS) update its inventory based on a provided collection of updates. The expectation is that the target OS update its inventory as requested, but no other side-effects are expected (e.g., creating a service in the network). This is a key point concerning this capability. The inventory update request can involve addition (new object), modification (change to an existing object) or deletion (removal of an object).<br/></p><p><br/></p><p><b>Service Inventory Reconciliation</b><br/></p><p>This feature entails an OSS reconciling its own inventory with inventory discovered from another source. When new service inventory information is discovered, the OSS will try to match the newly discovered information with an entity or entities already known to the OSS.<br/></p><p>If no match is found, the OSS will typically assume that a new entity has been discovered and add this to its inventory. Alternately, as decided by the service provider as part of their procedures, the OSS may record this event as an exception. For example, this may happen if the service provider always expects to have the planned service inventory in their inventory OSS before the actual services are activated.<br/></p><p>If a match is found and there are no unexpected discrepancies, the OSS will update its inventory as needed.<br/></p><p>If a match is found and there are unexpected discrepancies, the OSS will typically raise an exception so that service provider personnel can correct the problem.<br/></p><p><br/></p><p><b>Service Inventory Information Model</b><br/></p><p>This feature is the information model for the services to be managed. Typically, the service provider would need to add a lot of detail concerning the services to be managed. The suggested approach for the service provider is to start with the TM Forum SID service model and then specialize the model for the specific services to be managed. The service model should indicate or point to the supporting resources for each services (the SID model, in fact, does do this).<br/></p><p><br/></p><p><b>Supported Contracts</b><br/></p><p>To Be Added<br/></p>