se a common set of inter- faces to a diverse set of measurement agents, enables AT&T to select from the best of breed vendor solutions for measurement agent instrumentation. This in-turn allows for minimizing, and eventu- ally eliminating the need to build measurement vendor proprietary configuration and collection solutions. As mentioned earlier, the SDN-Mon VM will look very similar to any other managed network element as far as ONAP is concerned, as shown in Figure 16.11. Comparing the SDN-Mon solution in Figure 16.11, with the component measurement framework outlined in Figure 16.8, one can easily observe that the interfaces to ONAP are identical in both LMAP YANG CONFIGURATION POLLED STATE STREAMING CONNECTIVITY YANG (NETCONF/RESTCONF/ (NETCONF/RESTCONF/ TELEMETRY YANG) YANG) (APACHE AVRO/YANG) CFM YANG TWAMP YANG YANG MODELS (Configuration and State) SDN-Mon VM FIGURE 16.11 Interfacing the SDN-Mon framework to ONAP. Building the Network of the Future cases. The only difference in the interface is the YANG models that are used to structure the data for interfacing to ONAP, since the list of YANG models will be dependent on the set of managed functions. 16.5.1 NETWORK DEPLOYMENT EXAMPLE FOR THE SDN-MON FRAMEWORK There are several deployment scenarios possible with SDN-Mon, but we have chosen only two of them to illustrate the utility value of this framework. Figure 16.12 illustrates two methods used to implement an SDN-Mon VM for measuring path performance, which is in-turn utilized for SLA compliance measurements: 1. SDN-Mon is service function chained through adjunct network elements. In this scenario, the SDN-Mon VMs generate a representative measurement packet stream between them- selves, traversing the corresponding network elements. This deployment scenario could be used to validate SLA compliance for a pair of communicating network elements. In past implementations, one would expect the network elements to embed interoperable protocols to generate such measurements, complicating network element develop