n or set of technologies used and the application must also change its rules accordingly. This coupling between application and network design and infrastructure capabilities result in dependencies across application and controller product releases and version incompatibilities, complicating SDN network management by customers. Ecosystem: When SDN applications need to comprehend the network design and infrastructure capabilities, the applications are more complicated and the people required to write them must have knowledge of networking technology and operation. These factors make it hard to write SDN applications, resulting in slow 4 Software-Defined Networks Principles and Applications application development, sparse application offerings, a small SDN ecosystem, and limited value proposition for customers. The fundamental problem facing such a deployment is that each app has its own objectives and may conflict with other apps over proposed changes to shared network infrastructure. These conflicts include competing for limited switch resources such as flow table entries, competing for network bandwidth, or powering on/off network devices. Addressing this problem poses a threefold challenge: (1) resource conflicts are dynamic and cannot always be determined a priori; (2) choice of how to resolve a conflict directly impacts global network objectives; (3) conflicts might actually be avoidable, and alternative allocations not initially expressed by apps may allow both intended requests to be satisfied. There has been a lot of research in this space in SDN controller debugging, policy management, and conflict resolution. Statesman [82] automatically merges nonconflicting changes and relies on manually tuned priorities to resolve conflicts. OpenDaylight Network Intent Composition (NIC) [83] allow users and operators to describe high-level policy/intent rather than low-level device instructions. One recent approach is to explicitly model the policy of each SDN App and then use game theory approach to resolve conflicts