Skip to main content

4. Guidelines for Defining New Subservice Types

4. Guidelines for Defining New Subservice Types​

The base YANG module defined in Section 3.3 only defines a single type of subservice that represent service instances. As explained above, this model is meant to be augmented so that a variety of subservices can be used in the assurance graph. In this section, we propose some guidelines for specifying such extensions at IETF.

The mechanism to add a new subservice type is to define a new module for that subservice. The module name should start with "ietf-service-assurance-". The namespace of the module should start with "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". The prefix of the module should start with "sain-". For instance, the subservice type representing the assurance of a device should have:

  • the name "ietf-service-assurance-device",

  • the namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", and

  • the prefix "sain-device".

The new module should define:

  • a new identity to represent the new type and

  • the parameters fully specifying an instance of the new subservice type.

The new identity should be based on the "subservice-base" identity. The name of the identity should end with "-type", for instance, "device-type".

The parameters should be defined in a container named "parameters" that augments the choice "/subservices/subservice/parameter" from the main module. The augmentation should be restricted to cases where the type of the subservice matches the identity representing the new service type.

We define two subservice types in the next sections: the "device" subservice type is defined in Section 5 and the "interface" subservice type is defined is Section 6. These subservices can be taken as examples of the rules defined in this section.

Vendors can specify their own subservices types by defining the corresponding modules in their own namespace. An example of such a vendor-specific module is specified in Appendix A. Vendors can also augment existing IETF-specified subservices to add their own vendor-specific information.

Last updated on