Figure SO.09 - VPNService – VPNServiceSpecification Example

Let’s now examine a practical example. A ProductSpecification will be used to definea ProductOffering. A ServiceSpecification will define how to build a VPN to implement the defined in the ProductSpecification. Now, there are many different types of VPNs. For example, there are network-based VPNs, VPNs based on tunneling, VPNs based on encryption, hybrid VPNs such as MPLS VPNs, and others. All of these VPNs have certain things in common, which can be represented by a VPNServiceSpecification. <br/>Consider an MPLS VPN built to the RFC2547bis specification. The MPLS VPN is an example of a CustomerFacingService. This particular type of MPLS VPN is characterized by having three different types of routers. Each of these – the CustomerPremise, ProviderEdge, and Provider routers – can run a different set of protocols, perform a different function, and be managed in a different way.<br/>An MPLS VPN is implemented in a significantly different manner than other types of VPNs. Thus, an MPLSVPNService is a different type of object than (for example) an IPsecVPNService. However, they have three important things in common. First, they are both defined through a ProductSpecification and realized as a Product. Second, they can both be related to the same CustomerFacingServiceSpec. This is useful if, for example, the Service Provider is defining multiple types of VPNs that the Customer could use. Third, it is possible that they could both use the same CustomerFacingServices and/or ResourceFacingServices.<br/>Note that a more complete picture would also show that the two VPNs could use the same PhysicalResources and/or LogicalResources as well. However, this complicates the above figure and is out of scope for this Addendum.<br/>The difference between the MPLSVPNService and the IPsecVPNService is in the protocols and architecture used, which in turn cause additional system-specific differences that don’t show up in a business model. Rather, the SID identifies these two CustomerFacingServices and relates them to zero or more ResourceFacingServices through the CFServiceRequiresRFServices association (as well as the RequiresResourceFacingServiceSpec association from the template point-of-view).<br/>A ResourceFacingServiceSpec is related to a ResourceSpecification by the RFServiceSpecHasResourceSpecs association. Furthermore, a ResourceSpecification can be used to define the set of Resources that it requires using the SpecifiesResource association. This combination of associations means that conceivably, the same Resource could be used to support both types of VPNServices, assuming that it has the software and/or hardware to do so.<br/>Note that in the following Figure, the VPNServiceSpecification is an abstract class that contains the basic attributes and relationships and constraints for defining a VPNService without specifying the specific type and technology used (e.g., Ipsec vs. MPLS) to implement the VPNService. For example, the VPNServiceSpecification can be used to define the set of SLSs that will be used to measure performance of the VPN. Both an MPLS VPN as well as an Ipsec VPN specification are derived from the VPNServiceSpecification class.<br/>The MPLSVPNServiceSpecification and IPsecVPNServiceSpecification are related to the MPLSVPNService and the IPsecVPNService through the SpecifiesMPLSVPNServices and the SpecifiesIPsecVPNServices associations, respectively. This enables different MPLSVPNServices (as well as IPsecVPNServices) to be specified by the same MPLSVPNServiceSpecification (or IPsecVPNServiceSpecification, respectively). This enables the Service Provider to define a number of characteristics for each of the CustomerFacingServices and thereby templatize the definition of each. Combined with the LogicalResource and QoS Addenda, a complete roadmap will be developed for configuring this templatized definition.<br/>