will include some mini- mum data set of network information from the customer because all customer ordered parameters/ options must come in at the service model layer. One of the most important aspects of the service data model is that it will be used to auto- generate the REST API northbound to the OSS/ONAP systems that initiate the RPC requests into the network controller. Adding a new parameter to the YANG model and adding it to the system through the compiler causes it to be instantly available on the NBI, available to logic in processing events and added to persistent storage module vpn-network { namespace opendaylight:vpn"; prefix vpn; import ietf-inet-types {prefix inet; Software-Defined Networking revision "2014-06-03" description "Example VPN Service Module"; rpc create-vpn { description "Create VPN request"; input leaf custId{ type uint32; leaf vpnName { type string; leaf topology { type string; // hub&spoke; any-to-any -> could do as ENUM output { leaf vpnId { type uint32; 6.6 YANG NETWORK MODEL EXAMPLE The network model augments the data from the service request with the resources and attributes needed for a vendor agnostic network implementation. It includes the identification of resources needed for the implementation, the relationship of the resources, and their grouping where it impacts the network resource assignments. For example, in the VPN case, the assignment of VRFs is only needed once per PE because all access connections on that PE can share the same VRF definition. Similarly, route targets for any-to-any VPNs do not need to be unique, however, for hub-and-spoke VPNs the route targets have to be unique for hubs and spokes. Network models do not need to have RPC definitions, but there needs to be a mapping between the service model and the network model that applies to the RPC. The YANG standards do not define this mapping, and SO various mechanisms are used. In the AT&T Network Controller either a YANG extension to map a container (grouping of elements in a YANG model) to a service model R