Patent Publication Number: US-2023148301-A1

Title: Systems and methods for micro network segmentation

Description:
RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 16/664,657, filed Oct. 25, 2019. U.S. application Ser. No. 16/664,657, is a continuation in part of U.S. application Ser. No. 16/576,747, filed Sep. 19, 2019. U.S. application Ser. No. 16/576,747 is a continuation in part of U.S. application Ser. No. 16/556,219, filed Aug. 29, 2019. U.S. application Ser. No. 16/556,219 is a continuation in part of U.S. application Ser. No. 16/120,063, filed Aug. 31, 2018. U.S. application Ser. No. 16/120,063 is a continuation in part of U.S. application Ser. No. 15/443,855, filed Feb. 27, 2017. U.S. application Ser. No. 15/443,855 claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 62/300,641, filed Feb. 26, 2016. U.S. application Ser. No. 16/120,063 also claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 62/553,216, filed Sep. 1, 2017. U.S. application Ser. No. 16/556,219 also claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 62/724,454, filed Aug. 29, 2018. U.S. application Ser. No. 16/576,747 also claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 62/733,183, filed Sep. 19, 2018. U.S. application Ser. No. 16/664,657 also claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 62/750,558, filed Oct. 25, 2018. The disclosures of all of these applications are incorporated herein by reference in their entireties. 
    
    
     BACKGROUND 
     Network operators have been dealing with infected subscriber&#39;s devices for more than 15 years. Many operators have botnet notification and remediation systems in place to identify and mitigate infected devices on their network. A description of such systems is described in RFC 6561 on Recommendations for the Remediation of Bots in ISP Networks. Such systems have been in production since 2005. One patent for identifying infected devices is described in U.S. Pat. No. 9,027,138. 
     SUMMARY 
     Dynamic Software Defined Networking (DSDN) can be used to provide network level security protections for different types of devices, such as a network of Internet of Things (IoT) devices or other systems of wired and or wirelessly interconnected devices. 
     Devices that no longer have security patches or are infected with malware can be either quarantined, or their network traffic can be limited to only approved network destination points. 
     For devices with strong security, DSDN can be used to create VPN tunnels to add a layer of defense. For example, DSDN could be used to identify a network connected insulin pump with an embedded Public Key Infrastructure (PKI) certificate, look up the appropriate network connects (doctor&#39;s office and/or medical cloud), and create a VPN tunnel to the approved network locations. 
     In an embodiment, a wireless communication system includes an external provider subsystem and an electronic network subsystem in operable communication with the external provider subsystem. The electronic network subsystem is configured to provide a first microservice and a second microservice different from the first microservice. The wireless communication system further includes an in-home subsystem (i) separate from the external provider subsystem, (ii) in operable communication with the electronic network subsystem, and (iii) including a first micronet and a second micronet different from the first micronet. The first micronet is configured to operably interact with the first microservice, and the second micronet is configured to operably interact with the second microservice. The wireless communication system further includes at least one electronic device configured to operably connect with one of the first micronet and the second micronet. 
     In an embodiment, a wireless communication network includes a first micronetwork, a second micronetwork, and a software defined network controller configured to (i) operate according to a data model application, and (ii) enable communication packets from a first device configured within the first micronetwork to be delivered to a second device configured within the second micronetwork according to the data model application. 
     In an embodiment, a micronet communication system includes a micronet infrastructure configured to receive advance service information from, and arrange traffic routing and connectivity of, the system. The system further includes a micronet manager in operable communication with the micronet infrastructure and configured to orchestrate service delivery to the system, and a user network in operable communication with the micronet manager and the micronet infrastructure. The user network includes a gateway and a plurality of micronets. The gateway is configured to implement software defined networking (SDN) to automatically segment the plurality of micronets into at least one system-managed micronet and at least one user-managed micronet separate from the system-managed micronet. 
     In an embodiment, a micronet-enabled network communication system is provided. The system has a micronets platform for automatically organizing a plurality of connected devices within a plurality of trust domains. The system includes a system operator network including (i) an intelligent services business logic layer to serve as an interface for the micronets platform, and (ii) a micronet manager in operable communication with the intelligent services business logic layer and configured to orchestrate service delivery to the system. The system further includes an on-premises network including (i) a gateway in operable communication with the micronet manager, and (ii) a plurality of micronets. The gateway is configured to implement a software defined networking (SDN) switch automatically segment the on-premises network into the plurality of micronets. 
    
    
     
       BRIEF DESCRIPTION 
       These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein: 
         FIG.  1 A  shows one exemplary Dynamic Software Defined Network (DSDN) connected to the internet, including exemplary subnetworks, and representing primary device communications, in an embodiment. 
         FIG.  1 B  shows the DSDN of  FIG.  1    with secondary device communication connections represented after the provisioning of a secondary device, in an embodiment. 
         FIG.  1 C  shows the DSDN of  FIG.  1    with guest device communication connections represented after the provisioning of a guest device into the DSDN, in an embodiment. 
         FIG.  2    shows a medical subnetwork in communication with a residence subnetwork, which utilizes a partial isolation protocol, in an embodiment. 
         FIG.  3    shows one exemplary provisioning process, in an embodiment. 
         FIG.  4    shows another exemplary provisioning process, in an embodiment. 
         FIG.  5    shows one exemplary remediation process, in an embodiment. 
         FIG.  6    shows one exemplary process for the provisioning of a headless device onto a DSDN, in an embodiment. 
         FIG.  7    is a schematic illustration of an exemplary micronetwork management system, in an embodiment. 
         FIG.  8    is a schematic illustration of an exemplary architecture for the micronetwork management system depicted in  FIG.  7   . 
         FIG.  8 A  is a close-up view of the home network of the architecture depicted in  FIG.  8   . 
         FIG.  9    is a schematic illustration of an alternative architecture for the micronetwork management system depicted in  FIG.  7   . 
         FIG.  10    is a schematic illustration of an exemplary micronets flow table architecture, in an embodiment. 
         FIG.  11    is a schematic illustration of an exemplary software defined network control architecture, in an embodiment. 
         FIG.  12    is a schematic illustration of an alternative software defined network control architecture, in an embodiment. 
         FIG.  13    is a schematic illustration of an exemplary testing system that may be implemented with one or more of the embodiments described herein. 
         FIG.  14    is a schematic illustration of an exemplary Micronets-enabled communication system, in an embodiment. 
         FIG.  15    is a schematic illustration of an exemplary Micronets architecture, in an embodiment. 
         FIG.  16    is a schematic illustration depicting an exemplary operation principle of the Micronets architecture depicted in  FIG.  15   . 
         FIG.  17    is a schematic illustration of an alternative Micronets-enabled communication system, in an embodiment. 
     
    
    
     Unless otherwise indicated, the drawings provided herein are meant to illustrate features of embodiments of this disclosure. These features are believed to be applicable in a wide variety of systems including one or more embodiments of this disclosure. As such, the drawings are not meant to include all conventional features known by those of ordinary skill in the art to be required for the practice of the embodiments disclosed herein. 
     DETAILED DESCRIPTION 
     In the following specification and claims, reference will be made to a number of terms, which shall be defined to have the following meanings. 
     The singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. 
     “Optional” or “optionally” means that the subsequently described event or circumstance may or may not occur, and that the description includes instances where the event occurs and instances where it does not. 
     As used further herein, “CA” may refer to a certificate authority hosting a root certificate, and may further include, without limitation, one or more of a CA computer system, a CA server, a CA webpage, and a CA web service. 
     Approximating language, as used herein throughout the specification and claims, may be applied to modify any quantitative representation that could permissibly vary without resulting in a change in the basic function to which it is related. Accordingly, a value modified by a term or terms, such as “about,” “approximately,” and “substantially,” are not to be limited to the precise value specified. In at least some instances, the approximating language may correspond to the precision of an instrument for measuring the value. Here and throughout the specification and claims, range limitations may be combined and/or interchanged; such ranges are identified and include all the sub-ranges contained therein unless context or language indicates otherwise. 
     The present invention utilizes a subnetwork organization and isolation system and method for protecting computer systems, computing capable devices, and computer networks. This system and method prevents the infections of susceptible devices, dynamically isolates infected devices for administrator notification and manual or automated remediation, and provides for infected devices to remain in use, albeit in a limited fashion, without significant impact to the operator or other devices on the network. Providing for infected devices to remain in use is accomplished by isolating the infected or otherwise vulnerable devices into an isolation subnetwork. One exemplary isolation subnetwork is a limited access subnetwork which only provides for a narrow selection of communications or amount of data to transfer to and/or from the device. Another exemplary isolation subnetwork is a complete isolation subnetwork, which effectively walls of the device from the rest of the network and subnetworks until remediation may occur. 
     Dynamic Software Defined Networking (DSDN) system can be used to provide bot network level and device level security protections for a wide array of devices and systems, including but not limited to IoT devices, mobile devices, computers, routers, extenders, etc. Devices for which security patches are no longer available or devices that are infected with malicious software, such as malware or botnet software, may be either quarantined or isolated. Alternatively, such devices mayor have their network traffic controlled by the DSDN system, for example, limited to only approved network and subnetwork destination points, to approved network traffic types and/or flows, or by capping the amount of data flow for a predetermined period. 
     For devices with strong security, DSDN system can be used to create VPN tunnels to add a layer of protection to a devise and devices to which they are connected. In one example, DSDN system identifies a network connected medical device, such as an insulin pump configured with an embedded PKI certificate. The DSDN system determines the appropriate network connects (e.g., a doctor&#39;s office and/or a medical cloud), and creates a Virtual Private Networking (VPN) tunnel to the approved network location(s). 
     In an embodiment, the present DSDN system may create layers of protection for devices by configuring dynamic VPNs to stop malicious traffic from connecting to DSDN system protected devices. Furthermore, privacy is enhanced when utilizing the present DSDN system to preventing the theft of data from snooping devices listening to network traffic. This is accomplished, for example, by isolating devices in a home Wi-Fi environment and by utilizing VPN Tunnels (e.g., GRE or IPSEC). These snooping devices may be standalone devices put in place by a third party or may have been installed by the owner of the network but taken over (e.g., infected with snooping software) by a malicious third party. Such infected devices may be quarantined by the present DSDN systems and methods such that the device&#39;s network traffic is partially or completely separated or otherwise isolated from that of other devices on the network and potentially the internet. 
     If a network operator maintains a botnet notification and remediation system any infected device traffic may be tunneled for an administrator (also called here, “a user”) notification and remediation. For infection susceptible devices, for example, that are no longer supported with security patches, the device&#39;s network traffic may be dynamically configured to only route to approved locations, one example of which is an over-the-top video provider, the device&#39;s manufacturer, etc. 
     The present technology is not limited to the home use and may also be applied by any network operator and their operation. 
     The present invention may also provide a customer of a video network operator with an improved broadband experience. For example, for IPTV or over-the-top video services, the present system and method provides functionality to minimize the impact that home network traffic has on the video experience. It may also reduce operating costs associated with infected devices providing a network environment which they may exist in while protecting the rest of the network from infection. 
       FIG.  1 A  shows a DSDN  100  (also call “network  100 ” herein) connected to the internet  190  and including exemplary subnetwork  120 —subnetwork  180  (also called “limited access networks”), a router  106 , a primary interconnected device  102 , and a secondary interconnected device  104 . Primary device  102  is pictorially represented as connected to subnetwork  120 —subnetwork  160  via router  106 . Subnetwork  120  includes four computer systems  121 - 124 . Subnetwork  130  includes a smart thermostat  131 , a smart AC unit  132 , a smart furnace  133 , and a smart hot water heater  134 . Intelligence in these (and any other) devices may be integrated upon manufacture or may be added as an add-on post manufacture. Subnetwork  140  includes a smart TV  141 , an A/V receiver  142 , and an amplifier  143 . Subnetwork  150  includes smart light bulbs  151  and a smart hub  152 . Subnetwork  160  shares smart hub  152  with subnetwork  150  and includes IoT enabled door  161 , and window  162 . Any of these devices may include a plurality of IoT or smart devices, for example door  161  may include a smart lock, a smart doorbell, and a smart door opening sensor. Subnetwork  150  and/or subnetwork  160  may also include other smart or IoT devices such as smart light and fan switches, motion detectors, security cameras, moisture detectors, window shades, weather stations, etc., all of which are not shown but are contemplated. Subnetwork  170  includes a computer system  171 . Subnetwork  180  includes a guest device  181 , such as but not limited to a guest smart phone, guest computer system, or guest tablet. 
     Communication may come directly from primary device  102  to a subnetwork or a member of a subnetwork, or may be facilitated by networks  100 &#39;s router  106 . In the example of  FIG.  1 A , DSDN  100  is configured such that primary device  102  may access subnetwork  120 — subnetwork  160  via router  106 . Secondary device  104  has not been provisioned into network  100 , and therefore is not in communication with any device or subnetwork within network  100 . Subnetwork  170 — subnetwork  180  are shown isolated from all other subnetworks/devices in network  100 . That is, there is no communication between isolated subnetworks  170  and  180  and any other device or the internet  190 . In one example, for subnetwork  170  this may be that computer device  171  is infected with malicious software. In another example, for subnetwork  180  this may be because guest device  181  is currently not trusted. 
     In the embodiment of network  100 , all devices within a subnetwork may intercommunicate with other devices in the same subnetwork, but are partially or wholly isolated from devices outside their respective subnetwork, unless device or subnetwork is specifically configured to communicate with a device or subnetwork outside the respective subnetwork. One example of a cross subnetwork communication is subnetworks  150  and  160 , which share smart hub  152 . In this embodiment, smart light bulbs  151  may communicate with smart hub  152  and door  161  and window  162  may communicate with smart hub  152 , but smart bulb  151 , door  161  and window  162  may not communicate with each other. In a separate embodiment smart hub  152  (or router  106 ) may act as a policy enforcing intermediary which only allows certain communications between devices in subnetwork  150  and subnetwork  160 . Such communications may be maintained in a list of allowed communications on smart hub  152  or router  106  or enforced utilizing known techniques. Another example of cross subnetwork communication is between subnetwork  160  and subnetwork  130 . For example, if door  161  and window  162  are open, communication and coordination between subnetworks  160  and  130  may be initiated to heat or cool a home in which network  100  exists. For example, hub  152  may communicate with primary device  102  to notify the user that heating is not optimized due to open windows and or doors. 
     It will be understood that subnetworks may be organized by device type such that only devices that should communicate with one another do so and device that are not design to communicate with one another do not. For example, subnetwork  130  may be considered an HVAC subnetwork which supports heating and air conditioning smart devices and subnetwork  140  may be considered an Audio/Video subnetwork which supports only AV equipment. If, for example, smart furnace  133  were infected with foreign or malicious software which tried to duplicate itself throughout DSDN  100  the subnetwork structure of DSDN  100  would limit the malicious software to only subnetwork  130 . Furthermore, if furnace  133  tried to communicate with receiver  142  for purposes of duplicating itself, then DSDN  100  would note the unusual communication attempt and may initiate an analysis of furnace  133 , which may result in further isolation and remediation prior to incorporating furnace  133  back into subnetwork  130 . 
     It will be understood that the present system and method may be implemented on a service provider (e.g., Comcast) implemented DSDN capable system or in a DSDN cloud. DSDN functionality may also be distributed between a service provider the service provider implemented system, the DSDN cloud and the DSDN capable router. 
       FIG.  1 B  shows DSDN  100  of  FIG.  1    with communication connections for secondary device  104  after device  104  is provisioned into network  100 . DSDN  100  provides device  104  with communication to computer  122  of subnetwork  120 , to subnetworks  140  and  150 , and the internet all via router  106 . Secondary device  104  may be, for example, a child who lives in the home in which DSDN  100  in implemented. Because of this, device  104  is not provided access to house hold systems such as the HVAC system supported by subnetwork  130 . Furthermore, device  104  is only provided access to computer  122 , which may be, for example, the child&#39;s computer. It will be understood that DSDN  100  is a dynamic network such that access for device  104  may be changed and that change may be DSDN  100  implemented or may be manually configured by an administrator, for example by the user of primary device  102 . 
     Dynamic reconfiguration of DSDN  100 , subnetworks  120 - 180 , and communication access may be triggered by a DSDN operated scheduler. One example of this type of scheduling is primary device  102  programming device  104 &#39;s access to devices or subnetworks within DSDN  100 . This may include restricting device  104 &#39;s access to AV subnetwork  140  on school nights to after 6 PM. Alternatively, or additionally, device  104 &#39;s access to devices or subnetworks within DSDN  100  may be event driven. One example of such an event driven control is the submission or upload of the child&#39;s homework via device  104  or computer  122  to a homework submission website or server which may cause DSDN  100  to provide device  104  access to AV subnetwork and optionally to provide computer  122  broader access to the internet and access to e-mail, text, etc. Another example is the detection of malicious software on one or more devices of DSDN  100  or within a subnetwork  120 - 180 . Another example is the notification by a trusted source, e.g., manufacturer of thermostat  131 , that a software update is available. 
       FIG.  1 C  shows DSDN  100  of  FIG.  1    with communication connections for guest device  181  after guest device  181  on subnetwork  180  is provisioned into DSDN  100 .  FIG.  1 C  also includes a symbolically represented switch  190 , discussed further below. Because device  181  is a guest device it is provided limited access to DSDN  100  support devices and subnetworks. This is to protect DSDN  100  devices and subnetworks from potential infection that may be introduced by guest device  181 . This also protects guest device  181  from any viruses or malicious software that may be on a DSDN  100  device, for example furnace  133 . 
     In  FIG.  1 C  guest device  181  is provided access to the internet  190  and access to AV subnetwork  140 . Guest device  181  is provided primary device  102  controlled access to subnetwork  140 . Control by primary device  102  is symbolically represented by device  102  controlling switch  190 . Switch  190  may be implemented as a physical switch, as software within router  106 , or by another system or method that would be apparent to one skilled in the art after reading the present disclosure. 
       FIG.  2    shows two subnetworks, subnetworks  200  and  250 , which are examples of subnetworks forming communication subnetworks, such as subnetwork  250 , and an isolation subnetworks, such as subnetwork  200 . 
     Both subnetworks  200  and  250  are formed of devices which are in communication via router  254 , but are not co-located. In the example of subnetwork  250  a device  252  is in communication with a medical cloud  260 , a doctor office  270 , a hospital  280 , device manufacturer  290 , and service provider (e.g., Comcast) via a router  254  and switches  256 - 258 , which together form an isolated subnetwork  250 . Such a connection may utilize a VPN to connect a computer  202  and doctor&#39;s office  270 , thereby forming a new network, not shown. This new network may include medical devices, such as an insulin pump (not shown), which may be controlled or monitored from one or both of medical cloud  260  and doctor&#39;s office  270 . The present system and method provides for spatially distributed devices to exist on the same secure network (and in some case on different networks) with limited to no risk of the system being compromised by at least reducing the network attack surface. 
     Subnetwork  200  forms one embodiment of an isolate subnetwork, formed of a computer  202 , a switch  210 , computer  220 , and router  254 , which is share with subnetwork  250 . Subnetwork  200  is shown with a symbolic disconnect  230  between switch  210  and router  254 , which isolates computer  220  from computer  202  and subnetwork  250 . This may be a physical disconnect, for example implemented by a switch like switch  210 , or may be implemented in software, for example within router  254 , a DSDN orchestration, by a VPN tunneling, or by a combination of any of these. 
     In an alternative embodiment (not shown), computer  220  may be placed in an isolation subnetwork that is separate from one or both of computer  202  and switch  210  and subnetwork  250 . 
       FIG.  3    shows one exemplary provisioning process  300  for provisioning a new device onto a DSDN. 
     In step  302  of method  300  a device to be provisioned (hereinafter, “the device”) is connected to the network via a wireless or wired connection. One example of step  302  is guest device  181  of  FIG.  1 C  wireless connection to router  106  of DSDN  100 . 
     In step  304  of method  300  authentication data from the device is transferred to a DSDN capable system. 
     This step may be the transfer of a strong authentication via a cert or may be accomplished by a manual process performed by the administrator of the DSDN. One example of step  304  is transmitting a strong authentication via a certificate or SIM card or user name and password to router  106 , the user&#39;s service provider, or a DSDN cloud service. In step  306  of method  300  step  304  data is utilized to authenticate the device. One example of step  306  is DSDN capable router  106  connecting to internet  190  to authenticate guest device  181  via the provided cert. 
     In step  308  of method  300  the security/authentication data is forwarded to a network application management environment for processing. One example of step  306  is guest device  181 &#39;s cert, username and password data, or SIM card data being forwarded to router  106 , the use&#39;s service provider, or a DSDN cloud service. 
     In step  310  of method  300  the management environment applies network security and routing rules to guest device  181  based on the provided data. One example of step  308  is router  106 , the use&#39;s service provider, or a DSDN cloud service generating instructions for guest device  181  within network  100  to limit access by guest device  181  to network  100  resources. 
     In step  312  of method  300  instructions are provided to DSDN controller based on the data provided and processed in the above steps. One example of step  308  is router  106 , the use&#39;s service provider, or a DSDN cloud service providing the generated instructions to network  100  to implement the instructions. 
     In step  314  of method  300  a DSDN controller configures a flow table at a switch, e.g., in a gateway or a router. One example of step  312  is a DSDN controller within DSDN capable router  106  configures a flow table within router  106  to control data flow to and from guest device  181 . 
     In step  316  of method  300  the device is authorized. One example of step  316  is guest device  181  being authorized by DSDN capable router  161 , the user&#39;s service provider, or a DSDN cloud service. 
       FIG.  4    shows another exemplary provisioning process, process  400 , for provisioning a new device into a DSDN such as DSDN  100  of  FIGS.  1 A-C . The bulk of the examples here are directed to a wireless door lock. 
     In step  402  of method  400  a device to be provisioned (hereinafter, “the device”) is connected to the network via a wireless or wired connection. One example of step  402  is connecting a wireless door lock associated with door  161  of  FIG.  1 A  to router  106  of DSDN  100 . 
     In step  404  of method  400  authentication data from the device is transferred to the DSDN system, where the authentication data is processed. Transferring authentication data may be automatically or manually transferring a strong authentication via a cert or may be accomplished by an automatic or manual process performed by the administrator of the DSDN, for example, relying on user name and password, MAC address, or some other mechanism known in the art. One example of step  304  is the device transmitting its cert. to the router which in turn forwards the cert to the user&#39;s service provider, where the cert is processed and the device is authenticated. 
     In step  406  of method  400  the user&#39;s service provider, a gateway, or some other DSDN capable device determines which limited access subnetwork the new device will exist in. One example of step  306  is DSDN capable router  106  or user&#39;s service provider determining that a new door  161  associated door lock will exist within subnetwork  160 . 
     In step  408  of method  400  the DSDN capable device dynamically provisions the device into the step  406  determined limited access subnetwork. One example of step  408  is DSDN capable router  106  associating door  161  associated door lock with subnetwork  160 . 
     In optional step  410  of method  400  the association is given a temporal limitation, for example, the association expires after a predetermined amount of time or can only be accessed by designated devices or user during predetermined time periods. One example of optional step  410  is providing guest device  181  with a time based expiring access to DSDN  100 . In another example of step  410 , DSDN capable router  106  provides access to AV subnetwork  140  only between 6:00 PM and 7:00 PM on week nights. 
     In optional step  412  of method  400  the device is provisioned while the device is remote from DSDN  100  and router  106 . This provides for the device to have immediate access to resources within DSDN  100  when it is within wireless communication distance from router  106  or when it is plugged into router  106 . Examples of optional step  412  include remotely accessing router  106  and/or DSDN  100  to provision door  161  associated wireless door lock at time of purchase or guest device  181  in DSDN  100  or an appropriate subnetwork. 
     In step  414  of method  400  DSDN dynamically monitor s traffic amount and/or patterns to predetermined connections to ensure proper functioning and to determine the presence of undesired software within the DSDN. One example of step  414  is DSDN capable router  106  monitoring all traffic within DSDN  100  to if traffic amounts and patterns vary that that expected the be DSDN configured devices. If it is determined that traffic amounts and/or patterns do vary from that expected, DSDN capable router  106  may initiate an analysis of the infringing device to confirm the presence of malicious software. If malicious software is found, remediation process are activated, such as isolating the device to an newly generated isolation subnetwork, which restricts or eliminates traffic flow depending on the necessity of the device. Malicious software removal steps may also be taken. 
       FIG.  5    shows one exemplary remediation process  500 , for remediating a device within the DSDN that is determined to have been infected by malicious software. 
     In step  502  of method  500  initiates a detection process to determine if a device is infected. One example of step  502  is router or service provider implemented DSDN system initiates a scan or monitoring of a device, subnetwork or network. 
     In detection step  504 , method  500  utilizes third party data to determine if the device is infected. Third party data may include, but is not limited to, a report of DDOS involved computers, a report Spam involved computers, third party notifications, and computers identified during a Darknet monitoring process. One example of step  504  is a user&#39;s service provider comparing the device to one or more of the above described lists. 
     In detection step  506 , method  500  monitors and attempts to determine if the device is infected by comparing a devices traffic and operating characteristics with a predetermined baseline device, monitoring traffic for comparison to the traffic signature of known malicious software, and/or to determine if the device is acting outside it characteristic traffic. One example of step  506  is router  106  or a service provider determining if the device is infected by comparing a device&#39;s traffic and operating characteristics with a predetermined baseline device, monitoring traffic for comparison to the traffic signature of known malicious software. 
     In mitigation step  508  of method  500  places the device in a limited traffic or isolation subnetwork. One example of step  508  is the router of the service provider forming and placing a smart TV with malicious software into a limited access subnetwork such that the smart TV may only access Netflix and the smart TV manufacturer. 
     In mitigation step  510  of method  500  rate limits the device. One example of step  510  is the DSDN capable router or service provider placing a smart light bulb into a traffic rate limited subnetwork such that a minimal amount of data can be sent from the smart light bulb. 
       FIG.  6    shows a method for the provisioning of a headless device onto a DSDN. The headless device described in  FIG.  6    is a medical device, such as a wirelessly capable insulin pump. It will be understood that the medical device described here is only meant to be one example of one possible headless device and not limiting in any way. Other headless devices may also be provisioned utilizing method  600  without departing from the scope herein. 
     In step  602  of method  600  a headless medical device enters a patient&#39;s home which is enabled with a DSDN. One example of step  602  is a patient bringing a wireless capable insulin pump into their home and powering the device on. 
     In step  604  of method  600  the medical device automatically connects to the DSDN. One example of step  604  is the insulin pump wirelessly connecting to the patient&#39;s DSDN. 
     In step  606  of method  600  the medical device utilizes a digital cert to connect to the application layer. One example of step  606  is the medical device transmitting its digital cert to router  106  of  FIG.  1 A  or the user&#39;s service provider for processing. 
     In step  607  of method  600  one or more of the device, the service provider, and the medical cloud provides data regarding the endpoints for the distributed network. One example of step  607  is the router, service provider, or medical cloud identifying the patient&#39;s hospital, the patient&#39;s doctor&#39;s office, and the medical device&#39;s manufacturer as the only endpoints within the distributed network. 
     In step  608  of method  600  the application layer signals the control layer of the DSDN capable router to dynamically provision a limited access network or subnetwork, for example with a secure channel and/or with a secure subnetwork, in the patient&#39;s home and outside the patient&#39;s home. That is a subnetwork is formed between two remote networks such that they operate as a single network, in this example as a medical network which includes an insulin pump in a patient&#39;s home and a medical facility or monitoring service, for example at a doctor&#39;s office, that monitors and send and transmits data to the insulin pump. This medical network may also include a medical cloud service, similar to that shown in  FIG.  2   , and the manufacturer of the medical device. This greatly reduces the attack surface of the insulin pump and provides important information to a medical monitoring service or doctor&#39;s office. 
     In step  610  method  600  the insulin pump connects to the patient&#39;s doctor&#39;s office and/or the medical monitoring service, and potentially the manufacture of medical device. One example of step  610  is the insulin pump connecting to the patient&#39;s doctor&#39;s office such that the doctor may have real time information about the patient, to a medical monitoring service such that the patient may be monitored 24 hours a day, and to the manufacturer of the insulin pump such that any patches or updates may be timely provided, all over a secure network formed by the DSDN systems and method described herein. 
     In step  612  of method  600  the application layer provides context to the user, e.g., the patient, and any associated device. Providing context to the user may be providing information regarding the device&#39;s endpoints, traffic limitations, etc. 
     Micro Network Segmentation and Extension for Security and Service Enablement 
     The isolation network systems and methods described above thus represent particular embodiments within the larger context of the innovative micro network systems described herein, also referred to as micronetworks or micronets. The rapid growth in the number of connected devices (e.g., the IoT) has created new security risks for the networks (both wired and wireless) with which the devices seek connection. In particular network, for example, might not be put at risk to allow the device access some network services (e.g., public open Internet), but not other services (e.g., subscriber private, Enterprise secure, etc.). Accordingly, the embodiments herein describe innovative creation and management of micronets within a greater multi-level network system. The micronets establish and maintain different levels of access for a device that it is connected, or is seeking connection, to the system based on the trust level for the device. 
     Micronet operation is thus different from conventional network access techniques that simply function as gatekeepers for allowing/disallowing devices to connect with a network. In these conventional systems, devices are either entirely allowed, or completely disallowed, access to the network based on whether can pass through the security “gate” of the network, whether virtually (e.g., password credentials) or physically (e.g., locally connected within a given server system). Some such conventional techniques are able to dynamically limit the number of devices that access the network, and restrict access to fewer devices when the network resources become overloaded, but these techniques are not known to be able to limit the level of access by a device that is already connected to the network. This all-or-nothing approach fails to address the complexities of the present rapidly-increasing world of connected devices and overlapping networks. 
     For example, some electronic connected devices are general purpose devices (e.g., smart phones, tablets, personal computers, etc.), which have advanced user interface capability that allows network selection and credential input (e.g., as username and password) to be made manually. Other electronic connected devices are purpose-built devices (e.g., medical devices) which may not have user interface capability for network selection or entering credentials for secure authentication. Where a connected electronic device is a purpose-built medical device, and located in a clinical setting (e.g., a hospital), the device may not be considered sufficiently trusted to access certain portions of the clinical network (e.g., secure Enterprise services, private hospital records, medical service applications), but may nevertheless need to connect with other portions of the clinical network to upload vital patient health information recorded by the device. If such a device is infected with malware, for example, it is important to prevent that devices from accessing secure portions of the network, but it is still critical that the network be able to access the vital health records recorded by the device. 
     The mobility of many connected devices creates additional security concerns to present networking architectures and techniques. In the case of medical devices, many such devices may be considered secure and trusted when initially provisioned in the clinical setting, but may become less secure, or even untrusted, when brought into a home network environment. Devices connected to a home network were considered significantly more vulnerable once they are connected to the Internet. Furthermore, home networking systems are becoming increasingly more complex, and many users do not, or are unable to, manage their own home network. Indeed, the typical user of a home network is not aware of what, or how many, devices are connected to the Internet through home network of the user. 
     Selecting which, and/or how many, devices connect to a network is rarely organized as an automated process, and the selection process is often manually intensive. Furthermore, it is particularly challenging for the typical home user to provide secure connectivity to providers of critical exterior services (e.g., healthcare, automotive, etc.). The consequence thereof, the remote services delivered by exterior service providers do not often result in a good user experience. 
     According to the innovative systems and methods described herein, home networks are automatically and dynamically segmented into the trust domains of micronets in order to provide automatic secure connections to services outside of the home settings. In an exemplary embodiment, individual devices may be identified using certificates, dynamic certificates, heuristics, and/or analytics, and then correspondingly put into one or more trust domains appropriate for the device use. As described above, when individual device need not be restricted to use within only one network, subnetwork, or micronet. In some embodiments, a home user is prompted for permission for a device to connect, to ensure controlled by the home user. In other embodiments, home network attachment may occur automatically, according to the trust conveyance techniques described herein, including without limitation, certificates and dynamic certificates to automatically assign home devices into trust domains. 
     In an exemplary embodiment, SDN and/or DSDN is implemented to establish the secure connection to services exterior to the home network. In at least one embodiment, the SDN/DSDN further utilizes a registry service. Through these advantageous systems and methods, a device may connect to various micronets within a home environment according to a level of trust associated with the device itself, and/or security levels of the exterior services with which the device may be used. The present embodiments are therefore advantageously useful with respect to conventional networks, structured Cloud-based networks, and multi-level networks (e.g., containing public-open, provider-secure, subscriber-private, etc. access levels). 
       FIG.  7    is a schematic illustration of an exemplary micronet management system  700 . In an exemplary embodiment, system  700  includes an electronic device  702  configured to be capable of connecting with one of an external service provider subsystem  704  and an in-home subsystem  706 . In the exemplary embodiment, in-home subsystem  704  is configured to access virtualized microservices (described further below with respect to  FIG.  8   ) from a Cloud-based subsystem  708 , which is configured to interact with external service provider subsystem  704  through a micronet application programming interface (API) subsystem  710 . In the example illustrated in  FIG.  7   , external service provider subsystem  704  represents a medical or clinical setting, an electronic device  702  is a remote patient monitoring (RPM) device. These examples are provided though, for purposes of illustration, and are not intended to be limiting. As described above, the embodiments herein are applicable to other types of external service providers and connected electronic devices (e.g., general-purpose, purpose-built, etc.). 
     Although not illustrated in  FIG.  7   , micronet API subsystem  710  may, for example, include one or more of an application server, an authentication, authorization, and accounting (AAA) server, and a Wi-Fi core unit with online signup (OSU) and an access point (AP). In some embodiments, micronet API subsystem  710  is associated with a multiple-system operator (MSO), and may represent API protocols and/or functionality for client-server or socket programming, remote procedure calls, Simple Object Access Protocol (SOAP), REpresentational State Transfer (REST), and/or other Web service APIs. Cloud-based subsystem  708  may, for example, include or connect with an electronic network, such as the Internet, a Cloud-based network, or another form of electronic network, such as a local area network (LAN) or wide area network (WAN), and in some embodiments, the Wi-Fi core unit may be configured to communicatively connect with the AAA server in the electronic network. Communicative connections from the Wi-Fi core unit may be wireless, or wired, e.g., fiber, cable, or Ethernet. Additionally, as described above with respect to the preceding embodiments, and further below with respect to  FIGS.  8 - 9   , in the exemplary embodiment, in-home subsystem  706  further includes SDN capability. 
     In exemplary operation of system  700 , device  702  may be subject to an original provisioning operation  712  by, or at the location of, external service provider subsystem  704 , and then later subject to an installation or in connection operation  714  with, or at the location of, in-home subsystem  706 . Alternatively, device  702  is initially provisioned or re-purposed by/at in-home subsystem  706 . In either case, system  700  enables device  702  to be assigned, using certificates/dynamic certificates through in-home subsystem  706 , to a trust domain of one or more microservices provided by Cloud-based subsystem  708 . By this innovative use of certificates, in-home use of device  702  may be securely assigned to the trust domain(s) automatically, without requiring any active input from the home user. Conventional device attachment techniques do not use certificates to automatically assign home devices into trust domains. Furthermore, conventional network architectures are not configured to implement SDN to dynamically organize the trust domains for home networks in particular. 
       FIG.  8    is a schematic illustration of an exemplary architecture  800  for micronetwork management system  700 ,  FIG.  7   . In an exemplary embodiment, architecture  800  includes a Cloud infrastructure  802 , which enables in-home service for electronic device  702  (not shown in  FIG.  8   ) by in-home subsystem  706 . Cloud infrastructure  802  includes one or more customer APIs  804  and a server  805  configured to authenticate device  702  through in-home subsystem  706 . Server  805  may, for example, be a Wi-Fi Protected Access 2 (WPA2) Enterprise server, using an IEEE 802.1X protocol, enterprise-grade authentication, and pre-shared keys (PSK) for use by in-home subsystem  706 . In some embodiments, server  805  enables authentication to either a wired or wireless network, and may further implement Temporal Key Integrity Protocol (TKIP) and/or Advanced Encryption Standard (AES) encryption. 
     In an embodiment, customer APIs  804  are configured to interface with respective server components and/or API protocols of micronet API subsystem  710 . Accordingly, in an exemplary embodiment, Cloud infrastructure  802  further includes respective modules for one or more of a dynamic identity microservice  806 , an AAA microservice  808 , an SDN controller microservice  810 , and a network component(s) microservice  812 , and in-home subsystem  706  is enabled to access one or more of these respective microservices upon authentication. In the example illustrated in  FIG.  8   , infrastructure  802  is shown to be Cloud-based, and microservices  806 ,  808 ,  810 ,  812  are shown to be virtualized. In alternative embodiments, infrastructure  802  operates according to similar functional principles, but need not be Cloud-based, and the respective microservices need not be virtualized, depending on the particular hardware versus software structure of the architecture. 
     In-home subsystem  706  includes a home network  814  having a modem  816 , an SDN switch  818 , and an AP  820 . In an exemplary embodiment, SDN switch  818  enables a gateway  822  between modem  816  and AP  820 , and AP  820  is configured to access one or more micronets  824  established within, or accessible by device  702  within the operation of in-home subsystem  706  (e.g., one or more isolated networks, as described above). Through the SDN switching techniques described above, gateway  822  advantageously enables home network to operably communicate with Cloud infrastructure  802  through SDN switch  818  and  820 , or with a headend  826  (including, for example, a modem termination system (MTS) through modem  816  by way of a communication network  828 . Communication network  828  may be a cable network, a fiber optic passive optical network (PON), or a hybrid fiber coaxial (HFC) network. 
       FIG.  8 A  is a close-up view of home network  814  of architecture  800 ,  FIG.  8   .  FIG.  8 A  illustrates an exemplary embodiment in which, according to operation of SDN switch  818  and gateway  822 , SDN switch  818  is enabled to operably communicate (e.g., directly) with SDN controller microservice  810  of Cloud infrastructure  802 , and a AP  820  is enabled to similarly operably communicate with AAA microservice  808  (and/or dynamic identity microservice  806 ) of Cloud infrastructure  802 . 
     According to the exemplary embodiments illustrated in  FIGS.  8  and  8 A , an innovative combination of different technologies is advantageously enabled to identify devices, such as through use of dynamic certificates, and automatically Matt the identified device(s) into one or more appropriate trust domains. As described herein, implementation of the trust domain utilizes SDN, which further advantageously provides the agile infrastructure (e.g., cloud infrastructure  802 ), which in turn secure connectivity both within and outside of home network  814 . In at least one embodiment, an architecture  800  further includes an SDN controller (e.g., DSDN capable router  106 ,  FIGS.  1 A-C , step  314 ,  FIG.  3   ) located in a cable network (e.g., communication network  828 ), within home network  814 , within headend  826  (e.g., associated with a hub), or as a portion of Cloud infrastructure  802 . 
     In some embodiments, the SDN switch is a standalone device or software module. In other embodiments, the SDN switch is an integral component of a Data over Cable Service Interface Specification (DOC SIS) device or network. In the exemplary embodiment, at least one API of micronet API subsystem  710  is configured to enable external service provider subsystem  704  to register device  702  (e.g., in processing  712 ) to users such that onboarding service within in-home subsystem  706  may be automated, and also automatically establish secure connectivity to external service provider subsystem  704 . As described above, conventional techniques for managing trust within home networks typically require, for electronic devices utilizing an API, the device users to actively placed the device into the trust domain. According to the innovative systems and methods described herein though, user activity is greatly reduced or eliminated, through a novel use of certificates and dynamic certificates that automatically assign the home device into the respective trust domain, and particularly through use of SDN to organize the trust domains dynamically. 
     In at least some embodiments the certificates/dynamic certificates described above may include secure credentials, such as, X.509 certificates, which may be used for device authentication for both general purpose devices (e.g., smart phones, tablets, personal computers, etc.) and purpose-built devices (e.g., medical devices) which may not have user interface capability for making manual network selection and for manually entering credentials (such as username and password) for secure authentication. 
     A detailed description of schemes for automated network discovery and attachment of an external provider network by an electronic device are described in greater detail in co-pending U.S. patent application Ser. No. 15/419,853 filed Jan. 30, 2017, the disclosure of which is incorporated herein by reference in its entirety. However, where this previous application described novel two-stage authentication techniques for a multi-level network, the present embodiments feature innovative techniques for segregating the connected device into one or more micronets, we are each micronet may have own level of security access. Whereas this previous application describes device discovery of and attachment to existing multi-level external provider networks, the present embodiments describe the creation multiple micronets within a single home network environment. In this respect, the present systems and methods are fully compatible and complementary with this previous application. 
     In some embodiments, electronic device  702  includes an integral Wi-Fi module (not shown) having an embedded Wi-Fi chip, or alternatively, a separate and/or removable Wi-Fi module having a standard interface (e.g., USB, Ethernet, compact flash, etc.). In at least one embodiment, in the case where device  702  is a medical device, both an X.509 certificate, and additionally a medical device functionality certificate conforming to C4MI requirements for interoperability, may be used for authenticating device  702  either at external provider subsystem  704 , or at in-home subsystem  706 . The embodiments described above may also utilize Wi-Fi certificates (e.g., provisioned at manufacture of device  702 , or by external provider subsystem  704 ) such as those compatible with Hotspot 2.0 or Passpoint implementations. Credential sets that may be compatible some or all of the embodiments described herein include, without limitation, device or user certificates such as Extensible Authentication Protocol (EAP), EAP Transport Layer Security (EAP-TLS), EAP-TTLS Password Authentication Protocol (PAP), Subscriber Identity Module (SIM) based credentials for mobile operators, such as EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and EAP Authentication and Key Agreement prime (EAP-AKA′). 
     At least some of the certificates described herein may be obtained from a Certificate Authority (CA) before device  702  may be certified to the trust domain of the respective micronet. Alternatively, a certificate may be pre-installed on device  702  at the time of manufacture (or provisioned by external service provider  704 ), and authentication of device  702  in use at in-home subsystem  706  includes a step of verifying the pre-installed certificate with the CA. Utilization of credential sets from a CA may advantageously further enable the system to mitigate “man-in-the-middle” attacks and malicious APs. CA utilization ensures that the device does not allow a user to bypass network authentication, or to accept an unknown CA certificate if compliant with the specifications of the trust domain. In some cases, certificates may also be authenticated using such protocols as Protocol for Carrying Authentication for Network Access (PANA), Hypertext Transfer Protocol (HTTP) over TLS (HTTPS), or Internet Protocol Security (IPsec), etc. 
     In some embodiments, the involvement of home deployment  4  purpose-built devices, when implemented according to an 802.11 specification, standard 802.11 MAC signaling protocols might support only one security paradigm per SSID. Accordingly, multiple SSIDs may be implemented to allow a combination different security paradigms. In other embodiments, reserved vendor proprietary fields are utilized to construct an equivalent scheme, which is then either standardized, or involves vendor proprietary procedures at the device and AP. 
       FIG.  9    is a schematic illustration of an alternative architecture  900  for micronetwork management system  700 ,  FIG.  7   . Architecture  900  is similar to architecture  800 ,  FIG.  8   , and may be implemented with respect to device  702 ,  FIG.  7   , except that architecture  900  is illustrated for a subscriber-based microservice paradigm, which need not include a separate communication network. Authentication and trust domain assignment of the device within architecture  900  may otherwise functions similarly to equivalent operations within architecture  800 . 
     In an exemplary embodiment, architecture  900  includes a Cloud infrastructure  902 , which enables in-home service for electronic device  702  (not shown in  FIG.  9   ), through a modem/gateway  904 , by a micronets-based home network  906 . Home network  906  may be, for example, similar in structure and function to in-home subsystem  706 ,  FIG.  7   . Cloud infrastructure  902  includes one or more micronet APIs  908  configured to interface with respective server components and/or API protocols of micronet API subsystem  710 . Accordingly, in an exemplary embodiment, Cloud infrastructure  802  further includes respective modules for one or more of a Dynamic Host Configuration Protocol (DHCP) microservice  910 , an AAA microservice  912 , an SDN controller microservice  914 , a public key infrastructure (PKI) microservice  916 , a provider microservice  918 , and a network component(s) microservice  920 . Similar to the embodiments described above, home network  906  is enabled to access one or more of these respective microservices upon authentication of device  702 . This exemplary architecture is particularly useful in the case where a home network may be a private network, is not connected to the Internet, or is isolated or separate in at least some respects from the Internet or other electronic networks (e.g., cable or satellite service to a home). 
     Micronetworks Modeling, Data Structures, and SDN Controller 
     Further to the micronetworks embodiments described above, additional embodiments are described herein for organizing networks into micronetworks, as well as systems and methods for controlling the segmentation and operation thereof. More particularly, the following embodiments describe flow table structures for organizing a network into segmented trust domains in SDN controlled switches (bridges), and also logical architectures and implementations of associated SDN controllers. 
     For illustrative purposes, and not in a limiting sense, the following controller embodiments are described in the context of the OpenDayLight (ODL) modular platform for SDN and network functions virtualization (NFV). The person of ordinary skill in the art though, will understand that the techniques and structures herein are applicable to other open source platforms and/or different proprietary controllers. The following examples are additionally described in the context of the OpenFlow communications protocol, however, the person of ordinary skill in the art will further understand that other protocols (e.g., P4, Netconf, or similar) may also be used without departing from the scope herein. 
     In an exemplary embodiment, an SDN-controlled switch is configured to dynamically implement flow tables (such as those implemented by an Open vSwitch (OVS) bridge) to establish micronetworks, or micronets/Micronets. SDN controllers manage OVS bridges and control the routing of devices connected to the bridges by writing flows (e.g., OpenFlow, Netconf, P4, etc.) to the bridges. In the following embodiments, a Micronets controller application is illustrated as being controlled Northbound by a Micronets manager. In some embodiments, flows may be defined using IP layer information, such as destination and ordination IP addresses, as well as packet type. In other embodiments, flow tables may be established using packet or frame layer information, including payload level data. In at least one embodiment, external service logic may be further implemented to analyze complex data, and thus define flow table entries according to the needs of supported services. 
     For the purposes of the following description, a “Micronet” may refer to an IP subnetwork, or subnet, to which devices are assigned. The assigned devices may be identified by a variety of processes (e.g., MAC address, PKI certificate, IP addresses, etc.). In an exemplary embodiment, when a new device is connected to an OVS bridge, a Micronets ODL application is configured to detect the OVS port up notification, and then send a notification Northbound to the Micronets manager. The Micronets manager may then in-turn configure a DHCP server to offer IPs for the relevant Micronet subnet. In some instances. the Micronets manager may further configure the Micronets ODL application with pertinent information about the newly connected device(s), such that the new device may be placed within the corresponding Micronet, at which time any needed or desired OpenFlow flows may be written. 
     In an embodiment, a Micronets model is written for the Micronets ODL application according to a data modeling language (e.g., described further herein with respect to a YANG data modeling language model). This model is configured to enable the Micronets ODL application to manage devices, and also to allow for configuration from the Micronets Manager. In some embodiments, this configuration is received from the Micronets Manager, and may include Micronets create, read, update, and delete (CRUD) messages, as well as capabilities for moving a device from one Micronet to another (described below in relation to a Micronet device “delete” and/or “add”), and also for configuring inter-Micronet routing that has been allowed. 
     In an exemplary embodiment, a Micronets OpenDaylight data model defines elements necessary for the management of the Micronets, as well as the devices connected to each Micronet. The OpenDaylight data model may utilize different data models, however, for ease of explanation, three exemplary data models are described below: (1) a Micronets OpenDaylight YANG model; (2) a Micronets Northbound Notification data model; and (3) a Micronet device filtering data model. In an exemplary embodiment, the OpenDaylight includes an OpenDaylight Model-driven Service Abstraction Layer (MD-SAL) data store (described further below with respect to  FIG.  12   ). In this example, the MD-SAL data store has a tree-like logical structure, and includes at least two sub-stores: (i) a Configuration data sub-store; and (ii) an Operational data sub-store. In this example, the Configuration data sub-store maintains the configuration intent, while the Operational data sub-store maintains the system state. Therefore, the exemplary Micronets data model embodiments herein are described to maintain Micronet data as received by way of RESTCONF Northbound in the Configuration data sub-store, and to store information about the devices connected to Micronets in the Operational data sub-store. 
     In an exemplary embodiment, the Micronets OpenDaylight YANG model may be defined according to a Yang data modeling language of computer code or executable instructions, for example, as shown below with respect to the executable code listed in Computer Program Listing 1. Further to this example, an exemplary coding scheme for configuration data in the Micronets Configuration Data sub-store is provided in Computer Program Listing 2, below, and an exemplary coding scheme for operational data in the Micronets Operational Data sub-store is provided in Computer Program Listing 3, below. It may be noted that the operational data shown in Computer Program Listing 3 includes additional fields that are not present in a configuration data shown in Computer Program Listing 2. 
     In an exemplary embodiment, the Micronets Northbound Notification data model is configured for Northbound Asynchronous notifications originating in ODL, and sent to the Micronets Manager. These notifications may be used to notify the Micronets Manager of particular occurrences or events, including without limitation: (i) an ODL start; (ii) an OVS manager connected to or disconnected from ODL; (iii) an OVS bridge created or deleted; (iv) an OVS bridge port up; (v) an unknown device; (vi) an unknown device MAC; (vii) an unknown device Subnet IP; (viii) packets received on unknown bridge port; (ix) forbidden device inter-micronet-routing; and/or (x) forbidden device internet-routing. An exemplary coding scheme for notifications of this model is provided below in Computer Program Listing 4. 
     In an exemplary embodiment, the Micronet device filtering data model is configured to enable the Micronets Manager to determine whether a device packet should be dropped or passed. For example, packets may occasionally be received from unknown devices. In such circumstances, the OVS bridge may be programmed to send a PacketIn to the Micronets ODL Application, which thereby results in the occurrence of a related PacketIn event that may be translated to an Unknown Device Notification (e.g., according to the Micronets Northbound Notification data model, described above), which then may be written to the data store. Upon receipt of this event, the Micronets Manager may then instruct the Micronets ODL Application to either drop subsequent device packets or to let them pass. That is, the Micronets Manager is configured to instruct the Micronets ODL Application via the Micronet device filtering data model. An exemplary device filtering data model coding scheme is provided below in Computer Program Listing 5. 
       FIG.  10    is a schematic illustration of an exemplary micronets flow table architecture  1000 . In an embodiment, architecture  1000  represents a Micronets ODL OpenFlow pipeline flow table structure, including the introduction of flows for a Micronet Mapper (described further below), as well as subsequent tables for individual micronets. In the example illustrated in  FIG.  10   , only four micronets are depicted for ease of explanation, and not in a limiting sense. The person of ordinary skill in the art will understand that greater or fewer micronets may be supported by the present systems and methods. 
     In an exemplary embodiment, the logical structure of architecture  1000  includes a port security table  1002  (Table 0), and address resolution protocol (ARP) handler table  1004  (Table 5), an MAC security table  1006  (Table 10), a source Micronet Mapper table  1008  (Table 20), a destination Micronet Mapper table  1010  (Table 30), a Micronet-to-Micronet routing security table  1012  (Table 40), a Micronet-to-device routing security table  1014  (Table 50), a device-to-Micronet routing security table  1016  (Table 60), a device-to-device routing security table  1018  (Table 70), a Micronet egress table  1020  (Table 80), an Internet filter table  1022  (Table 90), and an Internet egress table  1024  (Table 100). 
     In the exemplary embodiment, port security table  1002  is configured to allows only packets from expected OVS bridge ports (e.g., all device ports, DHCP pass-through port, internet ingress port), and also allow DHCP requests to pass-through. In the case of a match on a port or protocol, port security table  1002  may be further configured for execution of the following actions: (i) for a match on an OVS bridge in-port, an action goto MAC security table  1006 ; (ii) for a match on an Internet ingress port, an action push a virtual local area network (VLAN) goto MAC security table  1006 ; (iii) for a match on an ARP protocol, an action goto ARP handler table  1004 ; and (iv) for a match on a DHCP protocol (e.g., UDP port 67), an action output to a DHCP pass-through port or device depending on DHCP ingress or egress. In the case where there is no match, port security table  1002  may be configured to send packets received on unknown ports to ODL and then drop the packets, also referred to herein as Packet-In-and-Drop (PktIn/Drop). 
     In similar manner, ARP handler table  1004  configured to handle all ARP packets on the bridge. For each device, ARP handler table  1004  may be further configured to: (i) upon a match on ARP requests (e.g., arp_op=1) and ARP Target Protocol Address (TPA)=device IP, an action output to the device bridge port (i.e., this flow may handle ARP requests sent to devices, such as in the case of device-to-device communication, and output ARP packets to the respective device bridge port); and (ii) upon a match on ARP responses (e.g., arp_op=2) and MAC destination=device MAC, an action output to respective device bridge port (i.e., this flow may handle ARP responses sent back to devices). In the case of other ARP requests (e.g., arp_op=1), an action output to a LOCAL port (i.e., this flow may send out all other ARP requests). In the case where there is no match, ARP handler table  1004  may be configured to drop the packets. 
     In an exemplary embodiment, the flow of MAC security table  1006  may be configured to only allow packets with expected MAC addresses and, for packets that do not match, a Packet-In notification may be sent, and the Micronets Manager may then send a message to either allow or block these packets (i.e., and reflected in MAC security table  1006 ). In the case of a match on source (Src)-MAC, the flow from table  1006  may further an action goto source Micronet Mapper table  1008 . In the case of no match, packets received with MACs unknown to ODL may be dropped. 
     In an exemplary embodiment, the flow of source Micronet Mapper table  1008  may be configured to a simple IP Access Control List (ACL) to map packets to the Micronet. This flow is of particular use in the determination of inter-micronet routing. In the case of a packet that does not match, and a Packet-In is sent, the Micronets Manager may send a message to either allow or block the non-matching packets, and the status thereof may then then be reflected in table  1008 . Accordingly, for a match on a Src IP subnet, this flow may result in an action store MicronetId in reg0, and an action goto destination Micronet Mapper table  1010 . In the case of no match, packets that are received with IP Subnets unknown to ODL may be dropped. 
     In an exemplary embodiment, the flow of destination Micronet Mapper table  1010  may also be configured according to a simple IP ACL to determine if the packets in question should go to another Micronet on that particular bridge. This flow is also useful in the determination of inter-micronet routing. In the case of a match on a destination (Dst) IP subnet, this flow may result in an action Set DstVlanID, an action store Dest MicronetId in reg1, and an action goto Micronet-to-Micronet routing security table  1012 . In the case of no match, with Internet traffic, and no inter-micronet routing necessary, this flow may result in an action goto Internet filter table  1022 . 
     In an exemplary embodiment, the flow of Micronet-to-Micronet routing security table  1012  is configured to enable all devices on this Micronet to communicate with any device on the destination Micronet. In an embodiment, this flow may be based on both the source and the destination Micronets, and is advantageously used to determine if the packets at issue in the flow are allowed to be routed to the intended destination. In at least one embodiment, this determination includes source and destination routing within the same Micronet. Thus, in the case of a match on a Src MicronetId (reg0) and a Dst MicronetId (reg1), this flow may result in an action goto Micronet egress table  1020 . Alternatively, in the case of no match, this flow may instead result in an action goto Micronet-to-device routing security table  1014 . 
     In an exemplary embodiment, the flow of Micronet-to-device routing security table  1014  is configured such that all devices on this Micronet are enabled to communicate with a particular device on the destination Micronet. In an embodiment, this flow may be based on both the source and the destination Micronets, and also on the destination MAC. This flow may also be advantageously used to determine if the packets are allowed to be routed to the intended destination. In the case of a match on a Src MicronetId (reg0), a Dst MicronetId (reg1), and a Dst MAC, this flow may result in an action goto Micronet egress table  1020 . Alternatively, in the case of no match, this flow may instead result in an action goto device-to-Micronet routing security table  1016 . 
     In an exemplary embodiment, the flow of device-to-Micronet routing security table  1016  is configured such that a particular device on this Micronet is enabled to communicate with all devices on the destination Micronet. In an embodiment, this flow may be based on both the source and the destination Micronets, and also on the source MAC. This flow may also be advantageously used to determine if the packets are allowed to be routed to the intended destination. In the case of a match on a Src MicronetId (reg0), a Dst MicronetId (reg1), and a Src MAC, this flow may result in an action goto Micronet egress table  1020 . Alternatively, in the case of no match, this flow may instead result in an action goto device-to-device routing security table  1018 . 
     In an exemplary embodiment, the flow of device-to-device routing security table  1018  is configured such that a particular device on this Micronet is enabled to communicate with a particular device on the destination Micronet. In an embodiment, this flow may be based on both the source and the destination MAC. This flow may represent a further security level to advantageously determine if some packet routing is allowed to the intended destination, even where the source and destination Micronets do not themselves allow such routing with one another as a whole, or with particular devices in one of the Micronets. Accordingly, in the case of a match on a Src MAC and a Dst MAC, this flow may result in an action goto Micronet egress table  1020 . Alternatively, in the case of no match, this flow will instead result in a PktIn/Drop, since there was not a match in any of the inter-micronet routing tables  1012 ,  1014 ,  1016 ,  1018 . 
     In an exemplary embodiment, the flow of Micronet egress table  1020  is configured such that, upon a match in one of the inter-micronet routing tables  1012 ,  1014 ,  1016 ,  1018 , this flow may be used to determine if the packets may be output to the port that the destination device is on. Accordingly, the case of a match on a Dst MAC, this flow may output to the OVS bridge port of the device. Alternatively, in the case of no match, the packets are dropped. 
     In an exemplary embodiment, the flow of Internet filter table  1022  is configured to control which devices are enabled to navigate to the Internet, and in some embodiments, how the navigation is performed. In an embodiment, in the case where no filters are configured for a device, this flow may result in a default status that the device enabled to freely navigate to the Internet. In other embodiments, for each device having an Internet filter, this flow may create a filter, and for a match on device SrcIp and available 5-tuple fields, result in an action goto Internet egress table  1024 . Alternatively, for a device having an Internet filter but no match for the device SrcIp 5-tuple, this flow may instead result in a PktIn/Drop action. 
     In an exemplary embodiment, the flow of Internet egress table  1024  may be configured to (i) strip the VLAN (if present), and (ii) output the packet(s) to the relevant Internet OVS bridge port. The visualization of architecture  1000  of the Micronets OpenFlow pipeline illustrated in  FIG.  10    is described further below with respect to the following examples. These examples are provided by way of illustration, and not in a limiting sense. 
     For example, for the Micronets configuration embodiments described above, the several flows may be created according to a scheme similar to that listed below in Computer Program Listing 6. In the exemplary flow scheme shown in Computer Program Listing 6, it may be noted that, for ease of explanation, fields for the duration, the n_packets, and the n_bytes fields are not shown. Further to this example, exemplary coding schemes for the created flows (and flow replies) are provided further below in Computer Program Listing 7. The several tables of architecture  1000  are described further below in greater detail. 
     In an exemplary embodiment, a primary role of port security table  1002  is to only allow packets to enter the bridge on expected bridge ports. Since table  1002  is the first table encountered by all packets entering the bridge, the innovative logical structure of architecture  1000  may be further configured to advantageously implement a number of additional flows, or sub-flows, within port security table  1002 , such that basic Micronets communication may be more easily and more efficiently controlled. In the following examples, the several flows are described in a particular order of flow priority, but the person of ordinary skill in the art will understand that some flows may occur in a different order without departing from the scope herein. 
     In an exemplary embodiment, the first two port security sub-flows are referred to herein as “DHCP pass-through flows.” The DHCP pass-through flows may, for example, be expressed as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=0, priority=195,udp,tp_src=67 
               
               
                   
                 actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=195,udp,tp_dst=67 
               
               
                   
                 actions=LOCAL 
               
               
                   
                   
               
            
           
         
       
     
     According to these DHCP pass-through flows, packets originating from a DHCP server will match “udp,tcp_src=67”, whereas packets sent to a DHCP server will match “udp,tcp_dst=67”. In this example, the Micronet configuration value “dhcp-server-port” may be used to output packets that are destined to the DHCP server. All ARP packets may then be processed by ARP handler table  1004  according to the following sub-flow: 
     cookie=0xba5eba11, table=0, priority=195,arp actions=goto_table:5 
     In an embodiment, additional port security sub-flows are referred to herein as “Port Security Trunk Micronet flows.” The Port Security Trunk Micronet flows are configured to ensure that only those packets coming from the “trunk-gateway-ip” (nw_src), and destined for a “micronet-subnet” (nw_dst), are allowed from the bridge LOCAL port. The Port Security Trunk Micronet flows may be expressed as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=0, 
               
               
                  priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.250.0/24 
               
               
                  actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=0, 
               
               
                  priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.251.0/24 
               
               
                  actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=0, 
               
               
                  priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.252.0/24 
               
               
                  actions=goto_table:20 
               
               
                   
               
            
           
         
       
     
     In an embodiment, further port security sub-flows are referred to herein as “Port Security Trunk Loopback flows.” The Port Security Trunk Loopback flows are configured such that any other packets that ingress from the LOCAL port from the “trunk-gateway-ip” (nw_src) will be egressed to the “trunk-gateway-port”. Conversely, the Port Security Trunk Loopback flows are additionally configured such that any other packets that ingress from the “trunk-gateway-port” from the “trunk-gateway-ip” (nw_src) will be egressed to the LOCAL port. The Port Security Trunk Loopback flows may be expressed as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=0, 
               
               
                 priority=110,ip,in_port=LOCAL,nw_src=10.36.32.55 actions=output:1 
               
               
                 cookie=0xba5eba11, table=0, 
               
               
                 priority=110,ip,in_port=1,nw_dst=10.36.32.55 actions=LOCAL 
               
               
                   
               
            
           
         
       
     
     The following port security sub-flows may be configured to control ingress packets for all created Micronets devices and, in an exemplary embodiment, one of these flows is provided for each Micronet device: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=4 
               
               
                   
                 actions=goto_table:10 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=3 
               
               
                   
                 actions=goto_table:10 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=2 
               
               
                   
                 actions=goto_table:10 
               
               
                   
                   
               
            
           
         
       
     
     It may be noted, that for these sub-flows, the “in_port” field is taken from the “device-openflow-port” field from the “connected-devices” Micronets container. 
     In an embodiment, still further port security sub-flows, referred to herein as “Trunk Port Ingress flows,” may be provided to allow packets to ingress from the bridge trunk port. Accordingly, in the case where a VLAN is not configured, a Trunk Port Ingress flow may be created according to: 
     cookie=0xba5eba11, table=0, priority=100,in_port=1 actions=goto_table:20 
     Alternatively, in the case where a VLAN is configured, a Trunk Port Ingress may instead be created as follows: 
     cookie=0xba5eba11, table=0, priority=100,in_port=1 actions=push_vlan:0x8100,goto_table:20 
     In this exemplary embodiment, any other packets from the bridge LOCAL port may then be handled by a port security sub-flow referred to herein as a “Port Security Local flow,” which may be expressed according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=0, 
               
               
                   
                  priority=100,in_port=LOCAL 
               
               
                   
                  actions=load:0−&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                   
               
            
           
         
       
     
     In this example, may be noted that the Source Micronet is set to the default source micronet (0), and that these packets are sent on to destination Micronet Mapper table  1010  for continued processing. Any remaining packets may then be sent to the controller as a PacketIn according to the following flow: 
     cookie=0xba5eba11, table=0, priority=5 actions=CONTROLLER:40 
     The final port security sub-flow described herein is referred to as a “Port Security Quench flow.” Packets that are received on unknown bridge ports are sent to the controller as a PacketIn, and the controller may then create a Port Security Quench flow to drop all subsequent packets of the same type. An exemplary Port Security Quench flow may be represented according to: 
     cookie=0xf005ba11, table=0, idle_timeout=120, priority=150,in_port=5 actions=drop 
     In this example, it may be noted that the Port Security Quench flows may all have the cookie set to “foosball” (i.e., f005ba11), for easy identification. Additionally, each cookie may further include an inactivity timeout, such that they will be automatically deleted when they timeout. 
     In an exemplary embodiment, ARP handler table  1004  is configured to handle all ARP packets on the bridge. In an embodiment, an ARP handler sub-flow for handling ARP requests (arp_op=1) sent to the Micronet devices may be expressed according to: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=110,arp,arp_tpa=192.168.250.2,arp_op=1 actions=output:2 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=110,arp,arp_tpa=192.168.252.3,arp_op=1 actions=output:4 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=110,arp,arp_tpa=192.168.251.2,arp_op=1 actions=output:3 
               
               
                   
               
            
           
         
       
     
     The ARP requests, for example, may typically be sent for device-to-device communication, and there may be one of these flows for each Micronet device. In this example, the ARP TPA is shown in the “device-ip” field, and the output is shown in the “device-openflow-port” field, with both fields from the “connected-devices” Micronets container. The handling of ARP responses (arp_op=2) that are sent back to the devices, on the other hand, may be represented according the following exemplary ARP handler sub-flows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=100,arp,dl_dst=b8:27:eb:ab:41:12,arp_op=2 actions=output:4 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=100,arp,dl_dst=b8:27:eb:19:11:87,arp_op=2 actions=output:4 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=100,arp,dl_dst=b8:27:eb:df:ae:a7,arp_op=2 actions=output:3 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                 priority=100,arp,dl_dst=b8:27:eb:8d:30:27,arp_op=2 actions=output:2 
               
               
                   
               
            
           
         
       
     
     In this example, the source mac (dl_dst) is the “device-mac”, and the output is the “device-openflow-port” field, and both are taken from the “connected-devices” Micronets container. These ARP handler sub-flows may be created, for example, in the case where no VLAN is configured. However, in the case where a VLAN is configured (i.e., and the VLAN tag is set from the Micronet configuration), exemplary ARP handler sub-flows may be created according the following flow examples: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=100,arp,vlan_tci=0x1000/0x1000,dl_dst=b8:27:eb:ab:41:12,arp_op=2 
               
               
                  actions=push_vlan:0x8100,set_field:4196−&gt;vlan_vid,output:4 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=100,arp,vlan_tci=0x1000/0x1000,dl_dst=b8:27:eb:19:11:87,arp_op=2 
               
               
                  actions=push_vlan:0x8100,set_field:4196−&gt;vlan_vid,output:4 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=100,arp,vlan_tci=0x1000/0x1000,dl_dst=b8:27:eb:df:ae:a7,arp_op=2 
               
               
                  actions=push_vlan:0x8100,set_field:4196−&gt;vlan_vid,output:2 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=100,arp,vlan_tci=0x1000/0x1000,dl_dst=b8:27:eb:8dS0:27,arp_op=2 
               
               
                  actions=push_vlan:0x8100,set_field:4296−&gt;vlan_vid,output:2 
               
               
                   
               
            
           
         
       
     
     Further to this ARP handler example, any other ARP request (arp_op=1) may be sent to the bridge LOCAL port according to the following exemplary flow: 
     cookie=0xba5eba11, table=5, priority=100,arp,arp_op=1 actions=LOCAL 
     However, if a VLAN is configured, then an additional flow may be created as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=5, 
               
               
                   
                  priority=105,arp,vlan_tci=0x1000/0x1000,arp_op=1 
               
               
                   
                  actions=pop_vlan,LOCAL 
               
               
                   
                   
               
            
           
         
       
     
     Accordingly, all other ARP packets may be dropped according to the following exemplary flow: 
     cookie=0xba5eba11, table=5, priority=5 actions=drop 
     In an exemplary embodiment, a primary role of MAC security table  1006  is to only allow packets with known MAC addresses. In one example, MAC security sub-flows may be expressed as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:df:ae:a7 
               
               
                 actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:8d:30:27 
               
               
                 actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:19:11:87 
               
               
                 actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:ab:41:12 
               
               
                 actions=goto_table:20 
               
               
                   
               
            
           
         
       
     
     In this example, each of the MAC addresses in these MAC security sub-flows have been taken from the “device-mac” field from the “connected-devices” Micronets container. Accordingly, any remaining packets may be sent to the controller as a PacketIn according to the following exemplary flow: 
     cookie=0xba5eba11, table=10, priority=5 actions=CONTROLLER:40 
     As described above, packets that are received with unknown MAC addresses may be sent to the controller as a PacketIn, such the controller is enabled to create a Quench flow to drop all subsequent packets of the same type. In one example, a MAC Security Quench sub-flow may be expressed as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xf005ba11, table=10, idle_timeout=120, 
               
               
                   
                  priority=250,dl_src=00:11:22:33:44:66 
               
               
                   
                  actions=drop 
               
               
                   
                   
               
            
           
         
       
     
     Further to this example, all such Quench sub-flows may have the cookie thereof set to “foosball,” for easy identification, and also include the inactivity timeout for automatically deletion capability. In some instances, it is possible for certain devices to be either explicitly dropped or allowed via the DeviceMac and DeviceIP flows in MAC security table  1006 . Accordingly, an exemplary MAC security sub-flow of a DeviceMac filter, for explicitly allowing matching packets by sending the packets to source Micronet Mapper table  1008 , may be expressed as follows: 
     cookie=0xba5eba11, table=10, priority=275,dl_src=11:22:33:44:55:88 actions=goto_table:20 
     In contrast, an exemplary sub-flow for a DeviceIp filter configured to explicitly drop matching packets may be expressed as follows: 
     cookie=0xba5eba11, table=10, priority=175,ip,nw_src=192.168.5.2 actions=drop 
     In an exemplary embodiment, exemplary sub-flows of source Micronet Mapper table  1008  may be expressed according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                  priority=300,ip,nw_src=192.168.250.0/24 
               
               
                   
                  actions=load:0x5b686f2d−&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                  priority=300,ip,nw_src=192.168.251.0/24 
               
               
                   
                  actions=load:0x5b686f2e−&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                  priority=300,ip,nw_src=192.168.252.0/24 
               
               
                   
                  actions=load:0x5b686f2f−&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                   
               
            
           
         
       
     
     In this example, these Source Micronet sub-flows match on the “device-ip” field from the “connected-devices” Micronets container, and map the corresponding MicronetId to Nicira Register 0, which stores the source MicronetId. An additional Source Micronet sub-flow is referred to herein as the “Source Micronet Trunk Gateway flow,” and is configured to allow packets from the Trunk Gateway to be processed, by setting the default MicronetId in Nicira Register 0, which holds the Source Micronet. An exemplary Source Micronet Trunk Gateway flow may be expressed according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                  priority=300,ip,nw_src=10.36.32.55 
               
               
                   
                  actions=load:0−&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                   
               
            
           
         
       
     
     Accordingly, any remaining packets of source Micronet Mapper table  1008  may be sent to the controller as a PacketIn with, for example, the following exemplary sub-flow: 
     cookie=0xba5eba11, table=20, priority=5 actions=CONTROLLER:40 
     As described above, packets that are received with unknown Source addresses may be sent to the controller as a PacketIn, such the controller is enabled to create a Quench flow to drop all subsequent packets of the same type. In one example, a Source Micronet Security Quench sub-flow may be expressed as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xf005ba11, table=20, idle_timeout=120, 
               
               
                   
                  priority=350,ip,nw_src=192.168.1.2 
               
               
                   
                  actions=drop 
               
               
                   
                   
               
            
           
         
       
     
     Further to this example, all such Quench sub-flows also have the cookie set to “foosball” for easy identification, and also include the inactivity timeout. 
     In an exemplary embodiment, ARP handler destination Micronet Mapper table  1010  may be configured, in the case where no VLAN has been configured, to include the following Destination security sub-flows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                  priority=500,ip,nw_dst=192.168.252.0/24 
               
               
                   
                  actions=load:0x5b686f2f−&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                  priority=500,ip,nw_dst=192.168.250.0/24 
               
               
                   
                  actions=load:0x5b686f2d−&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                  priority=500,ip,nw_dst=192.168.251.0/24 
               
               
                   
                  actions=load:0x5b686f2e−&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                   
               
            
           
         
       
     
     These Destination security sub-flows match on the “device-ip” field from the “connected-devices” Micronets container, and map the corresponding MicronetId to Nicira Register 1, which stores the destination MicronetId. However, in the case where a VLAN is configured, exemplary Destination security sub-flows may be created as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=30, 
               
               
                  priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=192.168.252.0/24 
               
               
                  actions=load:0x5b686f2f−&gt;NXM_NX_REG1[ ],set_field:4196−&gt;vlan_vid,goto_table:40 
               
               
                 cookie=0xba5eba11, table=30, 
               
               
                  priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=192.168.250.0/24 
               
               
                  actions=load:0x5b686f2d−&gt;NXM_NX_REG1[ ],set_field:4196−&gt;vlan_vid,goto_table:40 
               
               
                 cookie=0xba5eba11, table=30, 
               
               
                  priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=192.168.251.0/24 
               
               
                  actions=load:0x5b686f2e−&gt;NXM_NX_REG1[ ],set_field:4196−&gt;vlan_vid,goto_table:40 
               
               
                   
               
            
           
         
       
     
     In an embodiment, destination Micronets Mapper table  1010  may include an additional sub-flow referred to herein as a “Destination Micronet Trunk Gateway flow”, which is configured to allow packets destined for the Trunk Gateway to be processed, by setting the default MicronetId in Nicira Register 1, which holds the Destination Micronet. An exemplary Destination Micronet Trunk Gateway flow may be expressed according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                  priority=500,ip,nw_dst=10.36.32.55 
               
               
                   
                  actions=load:0−&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                   
               
            
           
         
       
     
     The preceding sub-flow may, for example, be created in the case where no VLAN is configured. However, in the case where a VLAN is configured, an exemplary Destination Micronet Trunk Gateway flow may instead be expressed as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=30, 
               
               
                  priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=10.36.32.55 
               
               
                  actions=load:0−&gt;NXM_NX_REG1[ ],set_field:4196−&gt;vlan_vid,goto_table:40 
               
               
                   
               
            
           
         
       
     
     In the case of packets having a Destination IP that does not map to a Micronet, the exemplary embodiments herein make the assumption that such packets are to be destined for the Internet. These packets thus may be sent to Internet Filter table  1022  according to the following exemplary sub-flow: 
     cookie=0xba5eba11, table=30, priority=6 actions=goto_table:90 
     The preceding exemplary flow schemes advantageously utilize easily-identifiable cookies (i.e., in the exemplary embodiments) that enable simple assignment for a given system table, of the several potential resulting actions and the destination tables to which such actions apply, as well as various IDs, addresses, and/or data storage registers. The person of ordinary skill in the art will understand that the particular coding schemes illustrated herein are provided by way of example, and are not intended to be limiting. Other programming schemes, languages, and/or protocols may be used without departing from the scope herein. 
     According to the examples described above, tables  1002 ,  1004 ,  1006 ,  1008 ,  1010  (i.e., Tables 0 through 30, respectively) are deployed in a series of ordered priority to enable initial security determinations of whether packets are dropped or sent to the Internet. In this sense, this first series of tables may be referred to as the “security tables.” Remaining packets (i.e., not dropped or sent to the Internet) may then be further scrutinized according to the ordered series of prioritized tables  1012 ,  1014 ,  1016 ,  1018  (i.e., Tables 40, 50, 60, 70, respectively), to determine whether devices in a first Micronet may be allowed to communicate with other devices in a second Micronet. In this sense, this second series of tables may be referred to as the “routing tables.” In an exemplary embodiment, the routing table determinations may be based on the Source and Destination MicronetIds, and also on the Source and Destination MAC addresses. In some instances, the first and second Micronets may be the same Micronet (i.e., intra-micronet routing). 
     In an exemplary embodiment, a first routing table priority determination may be made at the Micronet-to-Micronet level. That is, a first priority level may determine whether all devices in the first Micronet may be allowed to communicate with all devices in the second Micronet. Accordingly, Micronet-to-Micronet table  1012  may include the following exemplary sub-flows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=40, 
               
               
                 priority=400,reg0=0x5b686f2f,reg1=0x5b686f2f actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=40, 
               
               
                 priority=400,reg0=0x5b686f2d,reg1=0x5b686f2d actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=40, 
               
               
                 priority=400,reg0=0x5b686f2e,reg1=0x5b686f2e actions=goto_table:80 
               
               
                   
               
            
           
         
       
     
     For these sub-flows, it may be noted that the reg0 and reg1 values are the same for the each of the three exemplary flows. According to this technique, intra-micronet routing may be allowed for devices on the same micronet. In the exemplary embodiment, each Micronet that is created will include one of these flows. 
     In order for packets originating from, or destined to, the Trunk Gateway to continue to be processed, Micronet-to-Micronet table  1012  may further include sub-flows for handling the default Source and Destination Micronet IDs, and also for sending the packets to Micronet egress table  1020 . Accordingly, Micronet-to-Micronet table  1012  may include the following sub-flows for such purposes: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=40, priority=400,reg0=0 actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=40, priority=400,reg1=0 actions=goto_table:80 
               
               
                   
               
            
           
         
       
     
     In this example, packets that do not match in Micronet-to-Micronet table  1012  may be sent to Micronet-to-device table  1014  (i.e., allowed micronet2device routing) for continued processing according to the following exemplary sub-flow: 
     cookie=0xba5eba11, table=40, priority=5 actions=goto_table:50 
     In an exemplary embodiment, a second level of routing priority may be determined at the Micronet-to-device level within Micronet-to-device table  1014 , which may include the following exemplary sub-flow: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=50, 
               
               
                   
                  priority=400,reg0=0x5ae9db67,dl_dst=b8:27:eb:df:ae:a7 
               
               
                   
                  actions=goto_table:80 
               
               
                   
                   
               
            
           
         
       
     
     In this example, Micronet-to-device table  1014  is illustrated to use the Source Micronet ID (reg0) and the destination MAC address to determine whether any device in the Source (i.e., first) Micronet may communicate with the destination device (e.g., in the second, Destination Micronet). Accordingly, packets that do not match in this table may be sent to device-to-Micronet table  1016  (i.e., allowed device2micronet routing) for continued processing according to the following exemplary sub-flow: 
     cookie=0xba5eba11, table=50, priority=5 actions=goto_table:60 
     In an exemplary embodiment, a third level of routing priority may be determined at the device-to-Micronet level within device-to-Micronet table  1016 , which may include the following exemplary sub-flow: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=60, 
               
               
                   
                  priority=400,reg1=0x5ae9db68,dl_src=11:22:33:44:55:11 
               
               
                   
                  actions=goto_table:80 
               
               
                   
                   
               
            
           
         
       
     
     In this example, device-to-Micronet table  1016  is illustrated to use the Source MAC address and the Destination Micronet ID (reg1) to determine whether a particular device in the Source Micronet may communicate with any device in the Destination Micronet. Accordingly, packets that do not match in this table may be sent to device-to-device table  1018  (i.e., allowed device2device routing) for continued processing according to the following exemplary sub-flow: 
     cookie=0xba5eba11, table=60, priority=5 actions=goto_table:70 
     In an exemplary embodiment, a fourth level of routing priority may be determined at the device-to-device level within device-to-device table  1018 , which may include the following exemplary sub-flow: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=70, 
               
               
                  priority=400,dl_src=11:22:33:44:55:11,dl_dst=11:22:33:44:55:11 
               
               
                  actions=goto_table:80 
               
               
                   
               
            
           
         
       
     
     In this example, device-to-device table  1018  is illustrated to use the Source MAC address and the Destination MAC address to determine whether two particular devices (e.g., from the Source Micronet and the Destination Micronet, respectively) may be allowed to communicate with each other. In this manner, to individual devices may be enabled to communicate with each other in different Micronets, even in the case where the security levels of the Micronets do not otherwise permit such communication. Accordingly, packets that do not match in this table (i.e., the device is trying to perform some sort of forbidden routing) may be sent to the controller as a PacketIn according to the following exemplary sub-flow: 
     cookie=0xba5eba11, table=70, priority=5 actions=CONTROLLER:40 
     In the case of such forbidden routing, device-to-device table  1018  may be further configured to include a sub-flow referred to herein as a “Forbidden Routing Quench flow.” In the exemplary embodiment, the controller is enabled to create Forbidden Routing Quench flows to drop all subsequent packets of the same type. In this example, all such Quench flows, similar to the examples described above, may have the respective cookie set to “foosball” and include an inactivity timeout, which may be expressed as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xf005ba11, table=70, idle_timeout=120, 
               
               
                   
                  priority=350,ip,nw_src=192.168.1.2 
               
               
                   
                  actions=drop 
               
               
                   
                   
               
            
           
         
       
     
     In an exemplary embodiment, Micronet egress table  1020  may be configured to include one flow for each device in the table, and also to send the packets to the relevant device via the bridge port of that device. In this example, the “device-ip” field and the “device-openflow-port” field are taken from the “connected-devices” Micronets container. In an embodiment, these fields may then be used to populate the following exemplary flows for Micronet egress table  1020 : 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.252.3 
               
               
                 actions=output:4 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.252.2 
               
               
                 actions=output:4 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.251.2 
               
               
                 actions=output:3 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.250.2 
               
               
                 actions=output:2 
               
               
                   
               
            
           
         
       
     
     Additionally, Micronet egress table  1020  may be further configured to include additional sub-flows to allow packets to be sent to the Micronet Gateway IP (e.g., one such sub-flow created per Micronet), which may be expressed as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.252.1 
               
               
                 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.251.1 
               
               
                 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.250.1 
               
               
                 actions=LOCAL 
               
               
                   
               
            
           
         
       
     
     Micronet egress table  1020  may be further configured to include sub-flows referred to herein as “Micronet Egress Trunk Source flows” and “Micronet Egress Trunk Destination flows,” respectively. In the exemplary embodiment, these Trunk sub-flows enable packets to egress from the Trunk Gateway IP, and may be expressed according to the following exemplary flows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=80, priority=610,ip,in_port=1,nw_src=10.36.32.55 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=80, priority=600,ip,nw_dst=10.36.32.55 actions=LOCAL 
               
               
                   
               
            
           
         
       
     
     Additionally, any other packets that do not match in Micronet egress table  1020  may be dropped with the following exemplary sub-flow: 
     cookie=0xba5eba11, table=80, priority=5 actions=drop 
     In an exemplary embodiment, Internet filter table  1022  may be configured to control if and how devices may navigate the Internet. The following description enumerates, by way of example and not in a limiting sense, several navigation options. In each exemplary option though, it may be noted that the nw_src field of the following Internet filter sub-flows is taken from the “device-ip” field from the “connected-devices” Micronets container. 
     Include one flow for each device in the table, and also to send the packets to the relevant device via the bridge port of that device. In this example, the “device-ip” field and the “device-openflow-port” field are taken from the “connected-devices” Micronets container. In in the case where only an IP filter is specified, the following exemplary sub-flow for Internet filter table  1022  may be created with all layer 4 (L4) port filter protocols being allowed to the specified IP filter: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=90, 
               
               
                   
                  priority=705,ip,nw_src=192.168.1.3,nw_dst=192.168.100.50 
               
               
                   
                  actions=goto_table:100 
               
               
                   
                   
               
            
           
         
       
     
     However, in the case where both an IP filter and an L4 port filter are specified, the following exemplary sub-flows for Internet filter table  1022  may be created: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=90, 
               
               
                  priority=710,icmp,nw_src=192.168.1.3,nw_dst=192.168.200.60 
               
               
                  actions=goto_table:100 
               
               
                 cookie=0xba5eba11, table=90, 
               
               
                  priority=710,udp,nw_src=192.168.1.3,nw_dst=192.168.200.60,tp_dst=8000 
               
               
                  actions=goto_table:100 
               
               
                 cookie=0xba5eba11, table=90, 
               
               
                  priority=710,tcp,nw_src=192.168.1.3,nw_dst=192.168.200.60,tp_dst=8000 
               
               
                  actions=goto_table:100 
               
               
                   
               
            
           
         
       
     
     In this example, it may be noted that individual sub-flows are created for each of ICMP, UDP, and TCP. In the case though, where only an L4 port filter is specified, the following exemplary sub-flows for Internet filter table  1022  may be created to allow L4 traffic to any IP: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=90, 
               
               
                   
                  priority=710,icmp,nw_src=192.168.2.2 
               
               
                   
                  actions=goto_table:100 
               
               
                   
                 cookie=0xba5eba11, table=90, 
               
               
                   
                  priority=710,udp,nw_src=192.168.2.2,tp_dst=8080 
               
               
                   
                  actions=goto_table:100 
               
               
                   
                 cookie=0xba5eba11, table=90, 
               
               
                   
                  priority=710,tcp,nw_src=192.168.2.2,tp_dst=8080 
               
               
                   
                  actions=goto_table:100 
               
               
                   
                   
               
            
           
         
       
     
     However, in the case where a filter is specified without either an IP or L4 port, then Internet filter table  1022  may be configured such that all Internet traffic will be blocked for the relevant device according to the following exemplary sub-flow: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=90, 
               
               
                   
                  priority=700,ip,nw_src=192.168.1.2 
               
               
                   
                  actions=CONTROLLER:40 
               
               
                   
                   
               
            
           
         
       
     
     Accordingly, all other Internet-bound traffic may be allowed with the following exemplary sub-flow: 
     cookie=0xba5eba11, table=90, priority=5 actions=goto_table:100 
     In an exemplary embodiment of Internet filter table  1022 , an additional sub-flow may be created that is referred to herein as an “Internet Filter Quench flow.” In this example, the controller is enabled to create the Internet Filter Quench flows to drop all subsequent packets of the same type. Accordingly, all such Quench flows, similar to the above examples, may have the respective cookie set to “foosball” and include an inactivity timeout, which may be expressed as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xf005ba11, table=90, idle_timeout=120, 
               
               
                   
                  priority=350,ip,nw_src=192.168.1.2, nw_dst=8.8.8.8 
               
               
                   
                  actions=drop 
               
               
                   
                   
               
            
           
         
       
     
     In an exemplary embodiment, Internet egress table  1024  may be configured, in the case where a Micronet has been configured with a VLAN, to create the following exemplary Internet egress sub-flows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=100, 
               
               
                   
                  priority=800,vlan_tci=0x1000/0x1000 
               
               
                   
                  actions=pop_vlan,LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=100, priority=5 actions=LOCAL 
               
               
                   
                   
               
            
           
         
       
     
     However, in the case where a Micronet has not been configured with a VLAN, Internet egress table  1024  may be configured such that only the following exemplary flow is created: 
     cookie=0xba5eba11, table=100, priority=5 actions=LOCAL 
     According to the present systems and methods, techniques are also provided for tracking and control of Micronets OpenDaylight Northbound interactions. For example, as described further below in greater detail, the present embodiments enable the creation of, for example, OpenFlow flows for the Northbound configurations that are expected to be received from the Micronets Manager. The following embodiments are therefore described with respect to: (1) creation of Micronets, devices, and routing rules; (2) queries for the Micronets, devices, and routing rules; (3) deletions of Micronets, devices, and routing rules; and (4) Micronets notifications. For ease of explanation, it is assumed that, for the REST PUT messages described below, the HTTP return code is 201, which indicates that an entity has been successfully created. 
     In an exemplary embodiment, a Micronet may be created with a REST JSON message, such as that listed below in Computer Program Listing 8. It may be noted that, in Computer Program Listing 8, the “micronet-vlan” and “micronet-subnet-id” fields are considered optional. In this example, the “connected-devices” field, as well as the several different types of inter-micronet routing indicated in Computer Program Listing 8, may also be considered optional. Additionally, in this case, the “ovs-manager-port” is also optional, and may default to a value of 6640 if not present. 
     In an exemplary embodiment, a Micronets OVS bridge may be created using the OVS manager. That is, the OVS manager may be configured to allow the micronets application to connect, and also to create the bridge as necessary, according to the following exemplary coding scheme: 
     $ sudo ovs-vsctl set-manager “ptcp:6640” 
     In the case where the Micronet at issue is the first Micronet configured on the OVS Manager, then the Micronets application may be further configured to create the bridge and the controller connection (e.g., OpenFlow protocol), as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 $ sudo ovs-vsctl show 
               
               
                   
                 d3f5a271-c5d0-45c1-bfde-8f0a78e28a09 
               
               
                   
                  Manager “ptcp:6640” 
               
               
                   
                   is_connected: true 
               
               
                   
                  Bridge “brmn001” 
               
               
                   
                   Controller “tcp:192.168.86.25:6653” 
               
               
                   
                    is_connected: true 
               
               
                   
                   Port “brmn001” 
               
               
                   
                    Interface “brmn001” 
               
               
                   
                     type: internal 
               
               
                   
                  ovs_version: “2.9.1” 
               
               
                   
                   
               
            
           
         
       
     
     Accordingly, in some cases, the creation of subsequent Micronets toward the same OVS manager may result in the creation of additional bridges. In other cases, the same bridge may be used that has been already created. 
     In an exemplary embodiment, Micronet OpenFlow flows may be created as a result of the JSON configuration described above with respect to Computer Program Listing 8. In an embodiment, these Openflow flows may be created according to the exemplary flow scheme listed below in Computer Program Listing 9. Similarly, the Micronets Manager may be configured to create Micronets devices using the “connected-devices” element according to the coding scheme listed below in Computer Program Listing 10. In Computer Program Listing 10, it may be noted that the “device-id” field is optional in this example, and shown to be set and read by the Micronets Manager. Further to this example, the creation of Micronets devices may include the following additional exemplary flows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=0, priority=100,in_port=2 actions=goto_table:10 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=110,arp,arp_tpa=192.168.250.2,arp_op=1 
               
               
                  actions=output:2 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=100,arp,vlan_tci=0x1000/0x1000,dl_dst=b8:27:eb:8d:30:27,arp_op=2 
               
               
                  actions=push_vlan:0x8100,set_field:4196−&gt;vlan_vid,output:2 
               
               
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:8d:30:27 actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.250.2 actions=output:2 
               
               
                   
               
            
           
         
       
     
     In an exemplary embodiment, Micronet device internet filtering may be performed, and Micronet device routing to the Internet may be controlled, using an additional “internet-filters” element added to the “connected-devices” device definition. In an embodiment, such Internet filters may include without limitation one or more of the following types: (1) no filter, for which all device traffic is allowed to go to the Internet; (2) empty filter, for which no device traffic is allowed to go to the Internet (e.g., “internet-filters”: [{“filter-name”: “No device internet”}]); (3) IP filter, for which a device may only navigate to certain IP addresses (e.g., “internet-filters”: [{“filter-name”: “IP filter”, “filter-ip”: “192.168.1.2”}]); (4) L4 filter, for which a device may navigate to all IP addresses, but only to certain L4 ports (e.g., “internet-filters”: [{“filter-name”: “L4 filter”, “filter-14-port”: “80”}]); and (5) IP and L4 filter, for which a device may only navigate to certain IP addresses and L4 ports. In an embodiment, the respective internet filter types may be created according to the exemplary scheme listed below in Computer Program Listing 11. 
     In an exemplary embodiment, the created Micronet device Internet filter OpenFlow flows may include the following additional exemplary flows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=90, 
               
               
                  priority=710,icmp,nw_src=192.168.250.2,nw_dst=192.168.100.50 
               
               
                  actions=goto_table:100 
               
               
                 cookie=0xba5eba11, table=90, 
               
               
                  priority=710,udp,nw_src=192.168.250.2,nw_dst=192.168.100.50,tp_dst=8000 
               
               
                  actions=goto_table:100 
               
               
                 cookie=0xba5eba11, table=90, 
               
               
                  priority=710,tcp,nw_src=192.168.250.2,nw_dst=192.168.100.50,tp_dst=8000 
               
               
                  actions=goto_table:100 
               
               
                   
               
            
           
         
       
     
     In an exemplary embodiment, as described above with respect to  FIG.  10   , allowable Micronet inter-micronet routing may include without limitation one or more of the following types: (1) Micronet-to-Micronet, for which any device on a first Micronet (e.g., the present Micronet) is allowed to communicate with any device on a second Micronet; (2) Micronet-to-Device, for which any device on the first Micronet is allowed to communicate with a particular device on the second Micronet; (3) Device-to-Micronet, for which a particular device on the first Micronet is allowed to communicate with any device on the second Micronet; and (4) Device-to-Device, for which a particular device on the first Micronet is allowed to communicate with a particular device on the second Micronet. In an embodiment, all four types of exemplary inter-micronet routing may be created in a REST JSON message, such as the message listed in Computer Program Listing 12, below. 
     Accordingly, in the case of a Micronet-to-Micronet inter-micronet routing configuration (Micronet2Micronet), an exemplary flow may be according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=40, 
               
               
                   
                  priority=400,reg0=0x5ae9db68,reg1=0x5ae9db67 
               
               
                   
                  actions=goto_table:80 
               
               
                   
                   
               
            
           
         
       
     
     In this example, all traffic is allowed from Src Micronet (reg0) to Dst Micronet (reg1), with an action goto the MicronetEgress table (e.g., Micronet egress table  1020 ) to egress to the device. 
     Similarly, in the case of a Micronet-to-Device inter-micronet routing configuration (Micronet2Device), an exemplary flow may be according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=50, 
               
               
                   
                  priority=400,reg0=0x5ae9db67,dl_dst=00:11:22:33:44:77 
               
               
                   
                  actions=goto_table:80 
               
               
                   
                   
               
            
           
         
       
     
     In this example, all traffic is allowed from Src Micronet (reg0) to Dst Device Mac (dl_dst), with an action goto the MicronetEgress table to egress to the device. 
     In the case of a Device-to-Micronet inter-micronet routing configuration (Device2Micronet), an exemplary flow may be according to: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 cookie=0xba5eba11, table=60, 
               
               
                   
                  priority=400,reg1=0x5ae9db67,dl_src=11:22:33:44:55:11 
               
               
                   
                  actions=goto_table:80 
               
               
                   
                   
               
            
           
         
       
     
     In this example, all traffic is allowed from Src Device MAC (dl_src) to Dst Micronet (reg1), with an action goto the MicronetEgress table to egress to the device. 
     In the case of a Device-to-Device inter-micronet routing configuration (Device2Device), an exemplary flow may be according to: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=70, 
               
               
                  priority=400,dl_src=11:22:33:44:55:11,dl_dst=11:22:33:44:55:11 
               
               
                  actions=goto_table:80 
               
               
                   
               
            
           
         
       
     
     In this example, all traffic is allowed from Src Device MAC (dl_src) to Dst Device MAC (dl_dst), with an action goto the MicronetEgress table to egress to the device. 
     In an exemplary embodiment, Micronet device filters may be created according to the REST JSON scheme listed below in to Computer Program Listing 13. In an embodiment, the device filters may be generic, that is, the filters need not be specific to any particular Micronet. Additional exemplary OpenFlow flows for this Micronet device filters configuration may be created according to the following flows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 cookie=0xba5eba11, table=10, priority=275,dl_src=11:22:33:44:55:88 
               
               
                 actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=10, priority=175,ip,nw_src=192.168.5.2 
               
               
                 actions=drop 
               
               
                   
               
            
           
         
       
     
     With respect to queries of the created Micronets, devices, and routing rules, in an exemplary embodiment, the expected HTTP GET result for all of the queries described herein is, for ease of explanation, set to “200 OK”. Accordingly, an appropriate HTTP GET URL may be encoded, for example, in a manner similar to that listed below in Computer Program Listing 14. In the manner, the HTTP GET URL is enabled to query all Micronets in the operational data store. Thus, in the case of an OVS connection problem, the Micronets would not be created in the Operational data sub-store of the data store, but instead would be available in the Configuration data sub-store. IN some embodiments, the term “operational” in may be replaced with “config” in the URL (e.g., shown in Computer Program Listing 14) to query the Micronets created in the Configuration data sub-store. 
     In an embodiment, a particular Micronet may be queried by name (e.g., Micronet_Wired_250) using a URL according to the coding scheme listed in Computer Program Listing 15, below. Therefore, in this manner, all of the devices in a particular Micronet may be queried by querying either the particular Micronet, or by querying all of the Micronets in the network. In at least one embodiment, a specific device in a Micronet may be individually queried, such as according to the exemplary querying scheme listed in Computer Program Listing 16, below. In the example listed in Computer Program Listing 16, the MAC address of the device is used as the device key. 
     In a similar manner, in an exemplary embodiment, the Internet filters of a device may be queried by querying the Micronet to which the device belongs. An exemplary Micronets device internet filtering query is shown below in Computer Program Listing 17. 
     In an exemplary embodiment, the inter-micronet routing of a Micronet may be queried by querying either the particular Micronet, or by querying all of the Micronets in the network. The query may focus on the Micronet inter-micronet routing entries according to the particular routing table level desired. For example, the key for a Micronet-to-Micronet routing entry may be the dst-micronet parameter, as shown below in the exemplary querying scheme listed in Computer Program Listing 18, whereas the key for a Micronet-to-Device routing entry may be the dst-mac parameter, as shown below in the exemplary querying scheme listed in Computer Program Listing 19, the keys for a Device-to-Micronet routing entry may be the dst-micronet and src-mac parameters, as shown below in the exemplary querying scheme listed in Computer Program Listing 20, and the keys for a Device-to-Device routing entry may be the src-mac and dst-mac parameters, as shown below in the exemplary querying scheme listed in Computer Program Listing 21. 
     In an embodiment, Micronets device filters queries may be implemented for both MAC device filters and IP device Filters. In some embodiments, all device filters may be queried according to a URL, such as the exemplary URL listed in Computer Program Listing 22, below. In other embodiments, a specific MAC device filter may be queried according to the exemplary URL listed in Computer Program Listing 23, below. To query a specific IP device filter, a URL may be used according to the exemplary URL listed in Computer Program Listing 24, below. 
     With respect to deletions of the Micronets, devices, or routing rules, in an exemplary embodiment, all entities may be deleted from the Configuration data sub-store, and the expected HTTP GET result may again be set to 200 OK. Accordingly, in some embodiments, all of the Micronets may be deleted using a URL according to the exemplary URL listed in Computer Program Listing 25, below, a specific Micronet may be deleted using a URL according to the exemplary URL listed in Computer Program Listing 26, below, a device may be deleted from a Micronet using a URL according to the exemplary URL listed in Computer Program Listing 27, below, and an Internet filter may be deleted from a device, for example, using the exemplary URL listed in Computer Program Listing 28, below. 
     Micronet inter-micronetwork routing deletions may be performed similarly. For example, Micronet-to-Micronet routing entries in a Micronet may be deleted according to the exemplary URL listed in Computer Program Listing 29, below, Micronet-to-Device routing entries in a Micronet may be deleted according to the exemplary URL listed in Computer Program Listing 30, below, Device-to-Micronet routing entries in a Micronet may be deleted according to the exemplary URL listed in Computer Program Listing 31, below, and Device-to-Device routing entries in a Micronet may be deleted according to the exemplary URL listed in Computer Program Listing 32, below. 
     Micronet device filters deletions may also be performed in a similar manner. For example, all of the device filters may be deleted according to the exemplary URL listed in Computer Program Listing 33, below, a MAC device filter may be deleted according to the exemplary URL listed in Computer Program Listing 34, below, and an IP device filter may be deleted according to the exemplary URL listed in Computer Program Listing 35, below. 
     In an exemplary embodiment, Micronets Notifications may be queried in a manner similar to other queries described above. For example, all of the Micronets Notifications (i.e., all of the currently defined Micronets Notifications) may be queried according to the exemplary URL listed in Computer Program Listing 36, below. To query a specific Micronets Notification though, a URL may alternatively conform to the exemplary URL listed in Computer Program Listing 37, below, using, for example, the notification-id as a key. 
       FIG.  11    is a schematic illustration of an exemplary SDN control architecture  1100 . In an exemplary embodiment, architecture  1100  represents a system level architecture specific to implementation using an ODL-based SDN controller for an ODL application  1102 . This system specific architecture though, is provided by way of example, and is not intended to be limiting. The person of ordinary skill in the art will understand how other controller solutions may be implemented without departing from the scope herein. In the exemplary embodiment depicted in  FIG.  11   , ODL control is uniquely implemented in the several interfaces in ODL application  1102  between a Micronets manager  1104  and the controller of ODL application  1102 , an OVS switch  1106  in communication with devices  1108 , and an external DHCP support server  1110 . 
     In an exemplary embodiment, ODL application  1102  may further include an MD-SAL  1112  in communication with Micronets manager  1104  through a NorthBound API  1114 . In an embodiment, ODL application  1102  may also communicate with OVS switch  1106  through a SouthBound OVSDB  1116  and an OpenFlow plugin  1118 . A communication loop between MD-SAL  1112  and OpenFlow plugin  1118  may be realized using a Micronets ODL application data model listener  1120  in communication with a Micronets OpenFlow renderer  1122 . An interface between MD-SAL  1112  and Micronets manager  1104  may be achieved using a NorthBound asynchronous notifications module  1124  in communication with Micronets manager  1104 . A layer between MD-SAL  1112  and NorthBound asynchronous notifications module  1124  may include a PacketIn Handler  1126 , an OVSDB switch creation listener  1128 , and an OVSDB switch port-up listener  1130 . In at least one embodiment, additional areas  1132  (Inocybe) for ODL application  1102  may be further included. In the exemplary embodiment, architecture  1100  further includes a pass-through port  1134  between OVS switch  1106  and DHCP support server  1110 . 
     In exemplary operation of architecture  1100 , ODL application  1102  functions to monitor and control Micronets ODL Application events. For example, architecture  1100  may advantageously handle both active and passive OVS Manager connections and create OVS bridges. Accordingly, when ODL application  1102  detects that a new OVS bridge has been created, it will send a message Northbound to Micronets manager  1104 . That is, when ODL application  1102  detects that a new OVS bridge port has been created (e.g., OVS bridge port up), ODL application may send an asynchronous Northbound Notification to Micronets manager  1104 , which in this example, is assumed to be for a new device connection. 
     In this example, non-DHCP packets received on the new OVS bridge port may then be dropped. Additionally, the ODL application  1102  may send an asynchronous Northbound Notification to Micronets Manager  1104  in the case where the OVS port has not been configured as a Micronets device. In the case where a device  1108  connects to an OVS bridge, the particular device  1108  may soon-after start sending DHCP messages, which may be forwarded to DHCP server  1110  via DHCP pass-through OVS port (i.e., pass-through port  1134 ), as configured in the Micronet creation. 
     Upon receiving the OVS bridge port up event, Micronets Manager  1104  may notify DHCP server  1110  with the MAC address of the particular device  1108 , such that the particular device  1108  may obtain an IP address. In this example, Micronets manager  1104  may also send a configuration message to ODL application  1102  to add the newly connected device  1108  to a Micronet. The several monitoring units may then listen for testing results (e.g., a “still pending” status) that: (i) checks if a device connection is the same as an “OVS bridge port up” event; and/or (ii) verifies that new Wi-Fi connections trigger an “OVS bridge port up” event. 
     In further operation of architecture  1100 , to remove a device from a Micronet, the Micronet ODL operational configuration may be updated. In some embodiments, the particular device  1108  may still need to obtain a new IP address. In this case, the “still pending” status may wait for testing results relevant to triggering a device  1108  to obtain a new IP address from DHCP server  1110 . In some embodiments, the triggering action is handled by Micronets manager  1104  and the DHCP server  1110 , where DHCP server  1110  acts to “revoke” the IP address of the particular device  1108 , which in turn causes device  1108  to request a new IP address. In other embodiments, the triggering action is accomplished by bringing the OVS port down and back up, if possible, from ODL application  1102 . 
     Also in an exemplary operation, to add a device to a Micronet, the adding event may result from the connection of a particular device to the OVS bridge, as described above. In this case, the particular device  1108  may have already obtained an IP address from DHCP server  1110 , and ODL application  1102  may then need only update the Micronets connected-device configuration in the Operational data sub-store. To change a Micronet IP Subnet though, all connected devices may have already been removed from the Micronet, which event may result in a need for only a simple Configuration data sub-store update. 
     In the case where an unknown device is detected, either by an unknown MAC or unknown IP address, ODL application  1102  may send an Asynchronous Northbound Notification to Micronets manager  1104 , and the relevant packets may be dropped until instructed to the contrary. In the case where it may be desired to allow some or all of the packets to pass for the unknown devices, Micronets manager  1104  may alternatively inform ODL application  1102  using the relevant Device Filtering data model. 
       FIG.  12    is a schematic illustration of an alternative SDN control architecture  1200 . In an exemplary embodiment, architecture  1200  includes an MD-SAL  1202  similar to MD-SAL  1112 ,  FIG.  11   , and thus represents a more detailed MD-SAL implementation for an ODL-based SDN controller to support Micronets. Similar to the systems and methods described above with respect to  FIG.  11   , both the particular structure and the associated interfaces of architecture  1200  represent innovative improvements to SDN-controlled networks. In the example depicted in  FIG.  12   , MD-SAL  1202  is shown twice as a logical illustrative device. In actual implementation though, MD-SAL  1202  may be only a single device or structural element having the several interfaces described herein. 
     In an exemplary embodiment, architecture  1200  may include a first interface layer  1204 , a second interface layer  1206 , and a third interface layer  1208 . First interface layer  1204  may include one or more of an OVSDB Node Listener module  1210 , a PacketIn Listener module  1212 , a Device Filter Listener module  1214 , and a Micronets Listener Configuration module  1216 . 
     Second interface layer  1206  may include one or more of a first Micronets Handler Configuration module  1218 , a Notification Handler module  1220 , a Micronets Device Filter Handler module  1222 , a Micronets Handler Operations module  1224 , and a second Micronets Handler Configuration module  1226 . Similar to the illustrative device used in  FIG.  12    to show a single instance of MD-SAL  1202  twice, in some embodiments, for illustrative purposes first Micronets Handler Configuration module  1218  and second Micronets Handler Configuration module  1226  may be the same module. 
     Third interface layer  1208  may include one or more of and OVSDB Provider  1228 , a Notifications Provider  1230 , and am OpenFlow Renderer  1232 . In at least one embodiment a Micronets Listener Operations module  1234  may be further included between first interface layer  1204  and second interface layer  1206 , and more particularly, between Micronets Listener Configuration module  1216  and Micronets Handler Operations module  1224 . An exemplary flow diagram of the various flows described above is depicted between the several interface layers and the respective modules thereof. 
       FIG.  13    is a schematic illustration of an exemplary testing system  1300  that may be implemented with one or more of the embodiments described herein. In the exemplary embodiment, testing system  1300  was deployed for three separate Micronet devices  1302 ( 1 ),  1302 ( 2 ), and  1302 ( 3 ), distributed among two separate Micronets  1304 ( 1 ) and  1304 ( 2 ). The devices were in operable communication with an OVS bridge  1306 , which was itself in operable communication (e.g., receiving OVSDB OpenFlow communication) with an ODL application  1308  configured to receive RESTconf communication from a postman  1310 . As illustrated in the exemplary configuration depicted in  FIG.  13   , intra-micronet routing was allowed between first Micronet device  1302 ( 1 ) and second Micronet device  1302 ( 2 ) within the same first Micronet  1304 ( 1 ). In contrast inter-micronet routing was not allowed between second Micronet device  1302 ( 2 ) in first Micronet  1304 ( 1 ) and third Micronet device  1302 ( 3 ) in separate Micronet  1304 ( 2 ), at least until proper Micronet configurations are established, for example, according to the embodiments described above. 
     In exemplary operation of testing system  1300 , the following configuration schemes were utilized: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 createMicronetDevice.sh 
               
               
                 sudo ip link add ${device_port} type veth peer name ${bridge_port} 
               
               
                 sudo ovs-vsctl add-port ${bridge} ${bridge_port} 
               
               
                 sudo vconfig add ${device_port} ${vlan_id} 
               
               
                 sudo ip link set dev ${bridge_port} up 
               
               
                 sudo ip netns add ${device_namespace} 
               
               
                 sudo ip link set ${device_port} netns ${device_namespace} 
               
               
                 sudo ip link set ${device_vlan_port} netns ${device_namespace} 
               
               
                 sudo ip netns exec ${device_namespace} ifconfig ${device_vlan_port} 
               
               
                 ${device_ip} 
               
               
                 sudo ip netns exec ${device_namespace} ip link set dev ${device_port} 
               
               
                 addr ${device_mac} 
               
               
                 sudo ip netns exec ${device_namespace} ip link set dev ${device_port} 
               
               
                 up 
               
               
                 sudo ip netns exec ${device_namespace} ip link set dev lo up 
               
               
                 sudo ip netns exec ${device_namespace} ifconfig ${device_port} 
               
               
                 mtu 1400 
               
               
                   
               
            
           
         
       
     
     The present embodiments are described above with respect to several components of a conventional cable and/or wireless/Wi-Fi networks. Optical networks though, are also contemplated within the scope of the present embodiments. Such optical networks may include, without limitation, an Optical Network Terminal (ONT) or Optical Line Termination (OLT), and an Optical Network Unit (ONU), and may utilize optical protocols such as EPON, RFOG, or GPON. Other types of communication systems our further contemplated, including communication systems capable of x-hauling traffic, satellite operator communication systems, MIMO communication systems, microwave communication systems, short and long haul coherent optic systems, etc. 
     X-hauling is defined herein as any one of or a combination of front-hauling, backhauling, and mid-hauling. In these additional embodiments, the MTS may include, without limitation, a termination unit such as an ONT, an OLT, a Network Termination Unit, a Satellite Termination Unit, a Cable MTS (CMTS), or other termination systems collectively referred to herein as “Modem Termination Systems (MTS)”. Similarly, the modem described above may include, without limitation, a cable modem (CM), a satellite modem, an Optical Network Unit (ONU), a DSL unit, etc., which are collectively referred to herein as “modems.” Furthermore, the DOCSIS protocol may be substituted with, or further include protocols such as EPON, RFoG, GPON, Satellite Internet Protocol, without departing from the scope of the embodiments herein. 
     Micronet Infrastructure for Delivering Intelligent Services to Broadband End-Points 
     The micronet principles described above, which are enabled by SDN, establish a foundation for innovative security systems and methods based on the enhanced capabilities of network segmentation and secure network extension. Using these enhanced capabilities, the present embodiments further enable the delivery of intelligent services and business logic, including artificial intelligence (AI)-based services, using SDN (e.g., SDN controllers and SDN switches, described above) to provide new and advanced routing and security services. 
     In an exemplary embodiment, micronets automatically organize networks into trust domains, that is, without requiring manual configuration or limited SSIDs. The present micronet platform further enables the adaptive use of known identification techniques (e.g., addressing, fingerprinting, PKI certificates, etc.) to identify devices and dynamically segment the network location of such devices. SDN may be additionally implemented to not only identify devices, but also to collect traffic to and/or program rules into a router or AP for how the traffic should flow. As described further below, micronet implementations advantageously enable operators to provide remote end points (e.g., home owners/users) visibility and control to the dynamic network segmentation of the micronets paradigm. Moreover, use of SDN further enables opportunities to add advanced services on the Cloud. 
     Exemplary micronet architectural structures and system implementations are described further below with respect to  FIGS.  14 - 17   . For ease of explanation, the following embodiments refer to the networks of end point users as a “home network.” The person of ordinary skill in the art will understand that this terminology is provided by way of example, and not in a limiting sense. 
       FIG.  14    is a schematic illustration of an exemplary micronet-enabled communication system  1400 . In an exemplary embodiment, system  1400  includes a micronet infrastructure  1402 , a micronet manager  1404 , and a home network  1406  including a gateway  1408 , one or more managed services micronets  1410 , and one or more home owner micronets  1412 . In the example depicted in  FIG.  14   , micronet infrastructure  1402  and micronet manager  1404  are illustrated as being contained within an operator network  1414  (e.g. an MSO, cable operator, etc.), which is in operable communication with one or more partner/service provider subsystems  1416 , and also in operable communication with home network  1406  directly, or through an access and core network  1418 . 
     In at least one embodiment, gateway  1408  of home network  1406  is configured for operable communication with micronet infrastructure  1402  over a direct service information link  1420 , with micronet manager  1404  over a first service management link  1422  through access and core network  1418 . A second service management link  1424  connects micronet infrastructure  1402  and micronet manager  1404 . In an embodiment, partner/service provider subsystems  1416  may operably communicate with micronet infrastructure  1402  over a third service management link  1426 , and with micronet manager  1404  over a fourth service management link  1428 . One or more of service management links  1422 ,  1424 ,  1426 ,  1428 , may include an API. In at least one embodiment, partner/service provider subsystems may further be an operable communication with managed services micronets  1410  over a secure link  1430  passing through gateway  1408  in home network  1406 , access and core network  1418 , and possibly through operator subsystem  1414 . 
     In the example depicted in  FIG.  14   , the micronets may be considered, at a high level, to structurally include several distinct architectural components, such as micronet infrastructure  1402 , micronet manager  1404 , and home network  1406  with gateway  1408 . In exemplary operation of system  1400 , micronet infrastructure  1402 , which in this example is deployed by operator network  1414 , includes infrastructure-oriented microservices and an intelligence layer where intelligent services and business logic are applied, which may further include AI-based services. 
     In an embodiment, micronet manager  1404  is the primary element of system  1404  orchestrating all micronet activities, most particularly the creation of flow rules that control switching within home network  1406  and operator network  1414  to deliver services. Home network  1406  is constituted of trust domains that are used to deliver managed services  1410  or by the owner of home network  1406  to interconnect their customer owned and managed devices or services (not shown in  FIG.  14   ). In an embodiment, home network  1406  is further configured such that AI technologies, such as machine learning and/or neural networks, may be applied at scale, using the SDN infrastructure, to provide additional adaptive routing and security solutions. 
     In an embodiment, managed services micronets  1410  represent those managed services of home network  1406  that are automatically organized into appropriate micronets. The microservices of managed services micronets  1410  interact with home network  1406  through gateway  1408 . Gateway  1408  may be, for example, a modem, a cable modem, a router, an LTE hub/femtocell, etc. Partner/service provider subsystems  1416  may include, for example, partners of operator network  1414  and/or third party service operators that interact with micronet manager  1404  over an API of fourth service management link  1428 . In some embodiments, partner/service provider subsystems  1416  are further enabled to interact with micronet infrastructure  1402  over an API of third service management link  1426 , such that partners/service provider subsystems  1416  interface with the micronets environment of operator network  1414  through the respective APIs to either or both of the intelligent services layer of micronet infrastructure  1402  and the micronets controller of micronet manager  1404 . 
     In an embodiment, micronet infrastructure  1402  includes an intelligent services and business logic layer. The intelligent services and business logic layer may, for example, include advanced services that are enabled using cloud resources. The intelligent services and business logic layer interacts with the various elements of system  1400  through micronet manager  1404  to arrange traffic routing and connectivity. In an exemplary embodiment, micronet infrastructure  1402  is further configured to receive, e.g., through the SDN controller, information from various micronet microservices including without limitation IoT fingerprinting, AI-based traffic routing or malware detection, and mobility service management. 
     In an embodiment, micronet manager  1404  is configured to be responsible for orchestration and performance of overall services delivery. In at least one embodiment, the functionality of micronet manager  1404  resembles the execution of a state machine that ensures all the various system components stay synchronized. In an exemplary embodiment, micronet manager is configured to engage and manage a plurality of microservices, including without limitation the SDN controller, the DHCP server, a domain name system (DNS) server, and the AAA server. 
     In an embodiment, home network  1406  is configured such that the SDN switch may automatically create micronets for managed services micronets  1410 , home owner micronets  1412 , or for unmanaged networks or devices within home network  1406 . In an exemplary embodiment, home network  1406  includes an interactive interface that enables a home user to manage network  1406 , subnetworks, and micronets, which may include capabilities for manually overriding automatically created or joined networks. 
     In an embodiment, managed services micronets  1410  are configured such that operator network  1414  is enabled to leverage micronets of devices for managed services. Managed services micronets  1410  may therefore include organic service offerings of operator network  1414  (e.g., security services), or support services for a third party operator (e.g., a health care operator/network implementing remote patient monitoring within home network  1406 ). In some cases, permission(s) from the owner/user of home network  1406  may be established or required for some services of managed services micronets  1410 . 
     In an embodiment, home owner micronets  1412  represent micronets formed in the case where, for example, home owners acquire and connects their own customer-owned and customer-managed devices. In some cases, such customer-managed devices may be integrated into complete service-oriented networks, such as a smart home lighting system. In some embodiments, these home owner networked devices may be authenticated (or fingerprinted) using an ecosystem certificate, as described above, and then automatically placed into an appropriate micronet, as described above. In at least one embodiment, the home owner is enabled to manually create a subnetwork within home network  1406  for the networked device(s). In the exemplary embodiment, connectivity is explicitly allowed by owner/authorized user of a network  1406 . 
     In an embodiment, gateway  1408  represents a core networking component of the micronet operation. In an exemplary embodiment, gateway  1408  implements an SDN-controlled virtual switch that implements a flow table pipeline. Gateway  1408  may be further configured to support either or both of a wired and a wireless environment. Exemplary implementations of SDN control are described above. 
     According to the exemplary embodiment depicted in  FIG.  14   , the innovative micronet configuration of system  1400  provides unique interfaces to third parties, such as doctors and hospitals, to provision devices (i.e., medical devices) from the separate third party provider subsystem  1416  for home use within home network  1406 , but without risking compromise to the provisioned medical device from less secure intelligent devices operating within home network  1406 . In this example, the third party medical provider of the particular subsystem  1416  utilizes an API (e.g., service management links  1426 ,  1428 ) to associate a device to a client. When that client takes the device home (i.e., the location of home network  1406 ), the device may automatically join home network  1406  (e.g., which may include a prompt for user permission), and then automatically and securely connect to the third party provider of that subsystem  1416  over a secure connection  1430 . 
     According to this example, the automatically joined and connected medical device may operate within home network  1406  as a secure network extension of the particular third party provider subsystem  1416 , but in a segmented managed services micronet  1410  within home network  1406 . Therefore, enabled by SDN, these two basic capabilities—network segmentation and secure network extension—establish the foundation of the innovative and enhanced security paradigm provided by micronets. 
       FIG.  15    is a schematic illustration of an exemplary micronets architecture  1500 . In an exemplary embodiment, architecture  1500  may be implemented within the context of a larger networking system such as system  1400 ,  FIG.  14   , and therefore may further include several elements that have similar structure and functionality, such as a micronet infrastructure  1502 , a micronet manager  1504 , a home network  1506  including a gateway  1508 , managed services micronets  1510 , and home owner micronets  1512 . Also similar to system  1400 , architecture  1500  functions with respect to an access and core network  1514  and partner/service provider subsystems  1516 . 
     In an exemplary embodiment, architecture  1500  further includes a service API layer  1518  and a virtualized microservices layer  1520  between micronet infrastructure  1502  and access/core network  1514 , and an MSO API layer  1522  for interfacing with partner/service provider subsystems  1516 . 
     In the exemplary embodiment, micronet infrastructure  1502  represents an intelligent services layer configured to provide service information and/or guidance to the SDN or micronet controller to establish flow rules dynamically at the SDN switch. The intelligent services layer may include one or more advanced services  1524 , such as machine learning (ML) or neural network (NN) powered applications, business logic (e.g., conditional billing), AI-enabled services, security services, and/or device (e.g., IoT) fingerprinting. These services are described by way of example, and are not intended to represent an exhaustive list. 
     In the exemplary embodiment, virtualized microservices layer  1520  represents a virtualized control layer for the microservices of one or more of an SDN controller  1526 , a DHCP server  1528 , an identity server  1530 , and an AAA server  1532 . In at least one embodiment, one or more of the microservices of virtualized microservices layer  1520  may be cloud services, or operate from the cloud. Gateway  1508  may thus include one or more of a modem  1534 , a virtual switch  1536 , a micronet application layer  1538 , an AP  1540 , a router  1542 , and an ethernet  1544 . In the example depicted in  FIG.  15   , the several managed services micronets  1510  of home network  1506  correspond to the respective environments of the several third party providers of partner/service provider subsystems  1516 . 
       FIG.  16    is a schematic illustration depicting an exemplary operation principle  1600  of micronet architecture  1500 ,  FIG.  15   . In an exemplary embodiment, operation principle  1600  illustrates a dynamic flow configuration between the several layers, networks, managed services and micronets of architecture  1500 . More specifically, according to operation principle  1600 , SDN is implemented to dynamically configure flow rules and security controls (e.g., from micronet infrastructure  1502 ) in switches. This SDN implementation may further include providing service information (e.g., traffic information, identity information, etc.) from the network being operated (e.g., operator network  1414 ,  FIG.  14   ) to advanced service processors at the business and service intelligence layer of micronet infrastructure  1502 . 
     As further illustrated in  FIG.  16   , micronet infrastructure  1502  interfaces with virtualized microservices layer  1520  through service API  1518 , similar to second service management link  1424 ,  FIG.  14   , and virtualized microservices layer  1520  interfaces with gateway  1508  through access/core network  1514 , similar to first service management link  1422 ,  FIG.  14   . Different though, from system  1400 , partners/service providers  1516  need not establish a direct service management link to each of micronet infrastructure  1502  and micronet manager  1504 , but may instead communicate directly through MSO API layer  1522 , and MSO API layer  1522  may then individually communicate with micronet infrastructure  1502 , and also with micronet manager  1504  (e.g., through virtualized micro services layer  1520 ). 
       FIG.  17    is a schematic illustration of an alternative Micronets-enabled communication system  1700 . Communication system  1700  is similar to system  1400 ,  FIG.  14   , and includes similar components and functionality thereto, but is viewed from the perspective of an SDN router and AP  1702 . In the exemplary embodiment, SDN router/AP  1702  is a central communication  nexus  of a home network (not shown in  FIG.  17   ), and is configured for operable functionality with one or more of an access network  1704 , micronet controllers/intelligent services  1706 , a plurality of ecosystems  1708 , and a plurality of connected devices  1710 . For the several ecosystems  1708  and devices  1710  illustrated in  FIG.  17   , the descriptive labels therein are provided for purposes of illustration, and are not intended to be limiting. 
     In exemplary operation of system  1700 , router/AP  1702  is configured to, in step S 1712  receive a certificate (or another identity measure) from at least one ecosystem  1708 . In an exemplary embodiment of step S 1712 , certificates from a variety of ecosystems  1708  provide identities and usage descriptors of one or more devices  1710  within system  1700 , which information may provide valuable insight into desirable network configurations. In step S 1714 , router/AP  1702  captures the traffic and forwards the received certificate/identity information to the business and intelligent services layer of micronet controllers/intelligent services  1706  (e.g., micronet infrastructure). 
     In step S 1716 , micronet controllers/intelligent services  1706  interprets the forwarded information (e.g., by advanced services or AI processes, such as machine learning) and communicates to the SDN controller the network configuration to implement through router/AP  1702 . In an exemplary embodiment of step S 1716 , micronet controllers/intelligent services  1706  are further figured to interpret the information to identify devices without certificates, validate known devices, and/or monitor devices and system elements for abnormal behaviors. 
     In further operation of system  1700 , the capture and forwarding of packets be performed using a standard API, along with other security reporting, and provided to the business and intelligent service layer to dynamically change flows, according to one or more of the embodiments described above. In some embodiments, the captured/forwarded information is communicated directly between the gateway and the business and services layer. In other embodiments, the information is provided through the SDN and management interfaces/APIs. In at least one embodiment, the information is provided through a combination of direct communication and indirect SDN interfacing. 
     Accordingly, in the exemplary embodiment depicted in  FIG.  17   , in step S 1718 , upon identification of an abnormal or known bad behavior by micronet controllers/intelligent services  1706  in step S 1716 , router/AP  702  may be further configured to dynamically place a suspect device  1710  (device  1710 ( 2 ), in this example) into a special, segregated network  1720  namely, a micronet, to create a more granular “walled garden” that allows the suspect device  1710 ( 2 ) to continue to operate within the network, but with a virtual wall  1722  that prevents device  1710 ( 2 ) from harming other elements of the system  1700  by its continued operation therein. 
     Accordingly, the innovative micronet embodiments described herein enable the automatic organization of networks and subnetworks into trust domains without requiring manual configuration or limited SSIDs. The present micronet platform applies adaptive use of such advanced services as addressing, fingerprinting, and PKI certificates, to identify devices and dynamically segment the network location of such devices. Using SDN, the present systems and methods are further enabled to collect traffic to identify devices, and also to program rules into a router or AP regarding how that traffic should flow. 
     The present micronet embodiments further advantageously enable operators to provide home users visibility and control to the dynamic network segmentation, while also providing seamless interfaces to third-party providers to provision devices for home use, such as an API to associate a device to a client. The present embodiments therefore realize a significantly advanced network segmentation capability, along with enhanced secure network extensions, which are able to leverage still further advanced services through the micronet infrastructure and/or cloud services. 
     Micronet-Based Secure Home Networks 
     As discussed above, the increasing proliferation of Internet-connected devices in the IoT may potentially transform and enrich the lives of users, enabling increased efficiencies and productivity gains across the broader economy. However, the IoT brings with it a new set of challenges related to security, scalability, management, and ease of use. These challenges pose critical security and privacy risks to consumers, and also to the basic functionality of the Internet. Conventional consumer and small business networking technologies are not well suited to meet these challenges, which increasingly threaten to undermine the benefits provided by the IoT. 
     At present, the IoT industry and the broader Internet ecosystem share responsibility for addressing the security challenges posed by the proliferation of IoT endpoints, both by proactively preventing new vulnerabilities, and through mitigation of vulnerabilities as they are discovered. The IoT industry, for example, has established the Open Connectivity Foundation (OCF) to develop standards for improving the security of IoT devices and services. 
     The embodiments described herein thus represent a new and improved approach for securing the increasingly complex “home network” of individual users, residential homes, small business networks, etc. The present Micronets systems and methods provide a next-generation device and network management platform that addresses the IoT challenges relating to the organization of connected devices on the network into trust domains, through the creation of separate micro-networks/micronets. The present Micronets platform further provides dynamic and adaptive SDN—driven control for delivering advanced and secure services to the home networks. Implementation of the Micronets further enables dynamic and managed routing between the trust domains, while also enabling both detection and handling of compromised devices using advanced security techniques (e.g., AI, ML, etc.). 
     According to the embodiments herein, the benefits of enterprise security may be provided to home networks, but without the typical complexity associated such enterprise networks. The recent proliferation of connected devices in homes and small businesses has rendered it necessary for the home network to have advanced capabilities that were only conventionally available to large enterprises. Thus, for modern and future networks to be viable in the home or small business environmental setting, it is becoming more necessary that the networks may be automatically established and easily maintained thereafter, such that consumers have control of their networks and data. The present Micronet systems and methods enable consumers to maintain control of their devices in a simple, straightforward, secure, and transparent manner. 
     The present systems and methods further provide an innovative platform that dynamically improves the security of the home network over time, based on the experience of the home network user. The focus on the user&#39;s experience is unique. By automatically segregating the network into trust domains, when one device in the network is compromised, other devices in different trust domains of the network may remain secure. Subsequently, infected devices within one trust domain may be dynamically quarantined or restricted to minimize the impact of the infection on the consumer, third parties, and/or the broader Internet ecosystem. 
     The micronets described herein still further enable enhanced protection for particular high-value devices and services. For example, in the case of a user bringing an IoT medical device within a network, by establishing the network as Micronet-based, the network operator is enabled to provision an end-to-end secure micro-network between the medical device and the healthcare provider of the network user and/or the manufacturer of the medical device. The Micronets-enabled network thus provides a standardized approach to identifying and limiting the impact of infected devices, but while enabling consumer control. The present Micronet systems and methods thereby eliminate the need for security vendors to deploy custom software on the gateway of the network, which actually increases the available scale for vendors, while also broadening the range of solutions available to network operators. 
     As described above with respect to the several embodiments herein, “Micronets” refers to the present platform that is configured to automatically organize connected devices on a home network (e.g., consumer and small business networks, etc.) into trust domains, and then to manage the connectivity of those trust domains. The platform may advantageously apply adaptive uses of identification techniques (e.g., addressing, fingerprinting, strong credentials such as PKI certificates, etc.) to identify and dynamically segment connected devices. The implementation of SDN with the platform enables both the isolation of traffic between the various trust domains, and also the management of the traffic flow. The present Micronets platform thus leverages a variety of techniques in an innovative manner to uniquely identify devices and authenticate each device that connects to the network. The platform is further versatile; the platform enables the application of appropriate policies and access control based on the device profile, credentials, and traffic profiles. 
     In just the last several years, with the increasing prevalence and adoption of IoT devices, home networks are seeing significantly greater numbers of devices connecting to the networks. A typical home network includes a cable operator—provided modem or gateway, an integrated or standalone 802.11 Wi-Fi router or access point, and often several ethernet-connected devices. In most home networks, the traffic from all connected devices (e.g., IoT devices, personal computers, smart phones, tablets, etc.) transits a single network enabled by a residential or small office/home office (SOHO) gateway. This type of single, flat network architecture has heretofore been ill suited to the rapidly evolving nature of the use of these networks. 
     The conventional home network architecture poses several limitations: (i) by connecting all devices through a single network, a compromise of one connected device may impact the security of all devices on the network; (ii) when a single connected device is compromised, home users have little to no ability to manage the security risk across all devices in the network; (iii) conventional network management tools are complex, with non-standard configurations, which thereby magnify the risk at points of vulnerability; and (iv) network operators have limited ability to assist home network users with security of the home network or other local network issues. The present Micronets platform approach solves these challenges, while also providing home network users a network that is both more secure, and also easier for the user to manage. 
     the systems and methods described herein effectively establish and manage micronets to effectively redesign the user experience with respect to: (1) security, network management, and security management; (2) ease of use and transparency; (3) simplification of operator services; (4) equivalency of experience using wired or wireless connectivity; and (5) mobility. 
     With respect to security and security management, security is built fundamentally into the Micronets platform, as described above with respect to the several embodiments. That is, the Micronets architecture supports connected devices having strong security controls, and protects devices having weaker security controls. The present platform thus takes a pragmatic approach to security, recognizing that not all devices will have the same security capabilities, and there will likely always be legacy devices in or connecting to the network that may not be able to support stronger security controls described herein. According to the embodiments described above though, the Micronets-enabled network provides for easy onboarding and identification of such legacy devices, and also for their configuration into an appropriate trust domain. For example, a user may obtain an older, but functional legacy device having unpatched vulnerabilities (e.g., an old smart TV at a garage sale. The present systems and methods enable this user to still use the legacy device within the user&#39;s home network by provisioning the device into a separate trust domain from which the device would not be allowed to communicate with other connected devices in the network, such as a home security system. 
     With respect to ease of use and transparency, the Micronets manager may be configured to automatically manage devices and continually fine-tune security settings for the home network without burdening the user. The Micronets manager is configured to focus on executing the intent of the user, while providing a mechanism to ensure that home users may nevertheless review and audit actions taken by the Micronets manager. 
     With respect to simplification of operator services, through the implementation of SDN, the Micronets platform may be employed to simultaneously support many types of on-premises networks (e.g., homes and small businesses, collectively referred to herein as “home networks” for ease of explanation). 
     With respect to the equivalency of experience using wired vs. wireless connectivity, connecting devices within the on-premises network are enabled, according to the embodiments herein, to connect over any access mechanism to the network, but still receive the same level of services and security provided by the Micronets-enabled network. 
     With respect to mobility, the present systems and methods advantageously may further leverage the ubiquitous 4G/5G mobility, and thus provide an integrated connectivity experience to the users and their many connected devices. The Micronets platform further enables the respective services to operate seamlessly across both mobile (e.g., 5G) and/or fixed (e.g., Wi-Fi) networks. 
     As described above, the present systems and methods enable a transformative user experience by further providing such features and capabilities as: (i) network segmentation (i.e., into micro-networks); (ii) separate trust domains; (iii) extended secure connectivity outside of the home network; (iv) leveraged AI and ML, (v) privacy protection; (vi) dynamic rules and policy management, (vii) identification of each device or endpoint connecting to the network, and (viii) standardized interfaces. 
     Network segmentation, for example, may be realized according to the present embodiments by enabling the home network (i.e., at the user/customer premises) to be logically segmented based on a single device, a group of devices, or a particular service being delivered. Furthermore, this network segmentation may be configured to be dynamic, thereby supporting a relatively simplified introduction of new devices to the network, as well as the easy migration of connected devices between micronets (i.e., trust domains) in the network, or simply a change of user/consumer requirements of the network. 
     Separate trust domains may be realized, according to the embodiments described above, because the Micronets segmentation is policy-based and enables the creation of trust domains that are based on individual user needs. That is, as described herein, the Micronets platform advantageously is able to treat each network segment as a distinct trust domain within a single network. Accordingly, each such trust domain may be established with its own set of functional or business policies, as well as the associated security policies used for managing the connectivity to and from devices and the trust domains. 
     As described above (e.g.,  FIG.  14   ), the present embodiments further enable extension of secure connectivity beyond the home network, and also secure network extensions of devices from third-party networks while operating in or connecting to the local home network. That is, as described above, the present Micronets segmentation capabilities and trust domains may extend outside the on-premises network through the utilization of SDNs, VPNs, and/or other such solutions, thereby enabling the system operator (e.g., a cable operator) to connect specific devices to protected cloud services, or to be part of a larger SD-WAN. 
     The systems and methods herein may further leverage artificial intelligence and machine learning according to the above-described Micronets platform capability (e.g., micronet infrastructure  1402 ) to integrate AI/ML systems, and to consume a set of rules or policies for each trust domain, thereby guiding what devices and micro-networks may be interconnected. According to this innovative platform, the policies are enabled to dynamically evolve by adding, changing, or deleting rules based on the real time user actions or network traffic behaviors detected by the relevant AI/ML systems. These capabilities are considerably advantageous over conventional networks, which are not adaptive. These leveraging capabilities in turn gave rise to a number of additional capabilities, including without limitation, (i) the identification of devices with strong credentials for automatic assignment to existing or new trust domains, (ii) the integration of fingerprinting solutions to permit adaptive identification of devices and their purpose or function, which enables trust domains to be created based on context, and also provides a baseline for normal device behavior, and (iii) the identification of infected or compromised devices to dynamically separate such devices into their own trust domain(s), thereby preventing or limiting the ability of the compromised/infected device to connect to other devices on the local network (as well as on the broader Internet). 
     Privacy protection may be realized according to the present systems and methods due to the mechanisms provided by the above Micronets platform that are capable of analyzing readily visible attributes and patterns of network traffic to help identify anomalous device behavior, which anomalous behavior may be indicative of a compromise or infection. The present platform enables the quarantining of such devices into an isolated trust domain, thereby limiting the ability of the device to exfiltrate sensitive data or otherwise harm the user or the home network thereof. The present Micronets platform may further analyze the metadata of connected devices, as well as network traffic such as IP addresses and MAC addresses, which provides the consumers with increased ability to manage and control their own local networks, and which provides the network operator with increased ability to assist consumers with local network issues. Within this paradigm, the Micronets platform is further advantageous in that the platform itself does not examine the content of encrypted network traffic. 
     The Micronets platform described herein realizes dynamic rules and policy management by applying business rules and policies to specific devices, or to groups of devices, to enable the specific service traffic thereof to be treated more securely. These rules and policies may optimally be set to a default configuration based on a desired practice, but may also be advantageously configured to evolve over time as the user requirements change, or as the relevant services recognize device behaviors and anomalies. Furthermore, as external threat and attack information becomes known/available, the network operators may be further enabled to provide new rules or policies to better protect consumers and their devices from these known external security threats. 
     As described above, the Micronets platform is advantageously able to allow each device or endpoint to have its own unique identity that is leveraged to connect to the network, which in turn enables transparent, fine-grained control over network connectivity on a per-device basis. In some embodiments, the devices/endpoint identity may be certificate-based (e.g., in the case of devices participating in a PKI ecosystem). In such cases, the systems and methods herein may be further configured such that dynamic certificates may be provisioned to supporting devices. The present Micronets platform is still further capable of leveraging, and also improving upon, WFA standards to provide frictionless onboarding of new devices by a user/consumer. The platform may still further utilize usage descriptors, such as Manufacturer Usage Description (e.g., an IETF draft RFC) for additional device information useful for determining how the relevant devices should be connected. The present platform still further advantageously enables, in the case where identity or usage descriptors are not created, the creation of a synthetic identity for the device to ensure that uniqueness of the device within the network. 
     The systems and methods described above still further advantageously provide standardized interfaces that are particularly useful across a wide variety of larger networks to which the home networks connect, as well as the many device manufacturers and service providers to any or all of the many such networks. As described above, many AI-based services are being developed for home networks, and many vendors are providing a variety of capabilities that require integration directly into a home gateway or cable modem. However, such approaches are not scalable, nor are they extensible, both of which limit the consumer and the operator to having to choose one immediate solution that will likely be installed for a considerable length of time before the chosen solution can or will be changed. 
     The Micronets platform described herein though, provides an innovative approach that advantageously leverages flow-based switching capability in the gateway, and which provides a common, standardized interface that the network operator may leverage to enable a wide variety of cloud-based capabilities from various AI vendors. This advanced solution further enables the potential for a wide, technologically-competitive mix of advanced services across multiple vendors, such as advanced fingerprinting, anomaly detection, per-device granular walled garden malware management, etc. 
     The following example use cases are provided for purposes of illustration, and not in a limiting sense. These illustrative cases describe some of the many examples in which a system operator may utilize a Micronets-enabled home network to provide a more secure and easy-to-use consumer experience for the home network user(s). 
     The following examples are described with respect to a user having a well-networked smart home, namely, a residence having a home network to which is connected a plurality of home automation IoT devices, a smart car, several mobile devices, at least one connected healthcare device (e.g., a glucose tester for a resident of the smart home) that transmits regular test results to a third-party medical provider outside the home network (e.g., a doctor&#39;s office or clinical setting). In this example, one or more of the home residents are minor children having access to one or more of the connected devices, as well as online Internet content. 
     Use Case 1: Micronets Segmentation of the Home Network 
     In this example, the Micronets manager enables the automatic organization of the home network into several trust domains. Thus, even though user has full visibility into how the home network is set up, the user may might not have the time or ability to watch or manage the home network. Accordingly, this exemplary use case, the Micronets manager may automatically organize the home network into (i) a home automation micro-network, (ii) a home security micro-network, (iii) a micro-network for updating the smart car, (iv) a micro-network for a minor child of one age (e.g., a teenager) (v) a micro-network for a minor child of another age (e.g., a preteen or younger child), and (vi) a separate-secure network segment for the medical device in communication with a third-party provider. 
     This type of segmentation of the user&#39;s home network provides important security features that are conventionally only on well-designed enterprise networks. That is, this type of segmented home network advantageously enables rules to be applied against each micro-network according to the needs of that micro-network or the user(s) thereof, while also segmenting respective data and devices to minimize intrusions. 
     Use Case 2: Network Security 
     Further to this example, the Micronets platform may be configured to automatically provide notifications to the user (e.g., on a Micronets application connected to the user&#39;s smart phone) that a particular connected device (e.g., a smart appliance) is exhibiting abnormal or strange behavior, and may require repair. The observable operation of the particular connected device though, may appear normal, in the user may not immediately address/fix the problem for which the notification was received. In this scenario, the Micronets-enabled home network may temporarily place the affected connected appliance into a new micro-network/trust domain specially created to keep the affected device from impacting other devices in the home automation micro-network. 
     In some cases, such notifications may be received as result of the particular smart appliance merely requiring a security update, which may be learned, for example, upon examining a user interface of the appliance and finding a warning to perform the security update. Upon installation of the update, the home network is enabled to automatically place the affected appliance back into its previous trust domain without further intervention by the user. In other cases, the connected appliance may be infected with malware, which may not easily corrected by a simple security update. In such scenarios, the home network is enabled to permanently place the appliance within its own isolated trust domain. 
     Use Case 3: Micronets Home Extension 
     The smart home of the user in this example includes a considerable variety of connected devices providing a wide range of services that may be maintained and updated remotely. In comparison with conventional home automation products that may require hours for the user to connect the product on a conventional local network (and which may have to be performed again each time the home router is upgraded or even reset), the present Micronets-enabled home network provides a much more direct, friendly user experience. Partners are able to work with the system operator of the home user to maintain a secure ecosystem that allows the gateway of the user&#39;s home network to identify devices, and then automatically and securely connect the identify devices to their third-party service providers, but while still enabling the user to have full control over which providers (i.e., within the relevant ecosystem) and what devices the user seeks to connect with the home network. 
     Use Case 4: Remote Patient Monitoring 
     As described above, remote patient monitoring is considered to be a special case for home health care. In this particular example, a medical device (e.g., a glucose monitor, in this example) may be required to carefully monitor a particular health condition (e.g., blood glucose) for a specific health condition (e.g., severe diabetes). According to the present embodiments, the particular monitoring device may be provisioned at a remote doctor&#39;s office using an interface that is integrated with the system operator (e.g. a cable operator) of the user. In this example, the user may take a provisioned monitoring device into the smart home, and the Micronets manager may then immediately prompt the user to confirm that the device should connect to the home network. The Micronets-enabled home network may then require no more user intervention other than an assent to the prompt. The home network may then create a secure channel, as described above, over which the monitoring healthcare device may periodically report results to the remote provider periodically, or as provisioned by the provider. The monitoring device though is fully authenticated using a dynamic trusted identity for leveraging secure communications channels. 
     Use Case 5: Adaptable Security and Network Protection 
     For each of the use cases described above, the particular solutions that are described may be successful at a given time, but might not be effective in the case of future security threats that continuously evolve. The present Micronets platform though, is enabled to advantageously adapt its security capabilities in a seamless manner as security threats develop, and without requiring additional user intervention for the adaptation. As described in the embodiments above, a Micronets-enabled home network may advantageously employ a variety of complementary technologies (e.g., ID management supporting multiple ecosystem certificates, manufacture usage descriptors, synthetic device profiles, fingerprinting, etc.) to detect threats, identify compromised or infected devices, and adaptively create “walled gardens” to ensure that such compromises are contained. The enabled home network may further utilize such technologies used for the determination of security permissions, traffic capture, and forwarding to high-performance scanners that scan for compromise/infection indicators. Where desired, ML and neural network technologies may also be applied in the cloud to provide advanced intelligence to render some or all of such enhanced capabilities as dynamically adaptable as possible. 
     In an exemplary embodiment, the architectural topology of the Micronets-enabled network allows the network to read and establish a variety of specialized micro-networks to, and within, the home network. As described in the above embodiments, these micro-networks are subnetworks of the home network, and defined and managed by flow-based SDN switching, and rules may be based on frame or packet information at Layer 2 (e.g., MAC addresses, or certificates and unique device credentials), Layer 3 (e.g., IP address, protocol, or network-level authentication), or higher (e.g., ports, device signatures). Using these flow rules, the Micronets platform is enabled to interconnect devices, or resources such as virtualized storage/compute, within the home network, the infrastructure of the system operator, and/or the Internet. 
     Referring back to  FIG.  14   , Micronets may be viewed at a high level as having four distinct architectural components: (1) an intelligent services and business logic layer (e.g., at the system operator level); (2) a Micronets manager; (3) an on-premises/“home” network; and (4) a Micronets gateway. 
     As described in greater detail above, the system operator (e.g., operator network  1414 ) deploys the Micronets platform, which includes infrastructure-oriented micro services and an intelligence layer (e.g., micronet infrastructure  1402 ) where intelligent services and business logic is applied. The Micronets manager (e.g., micronet manager  1404 ) orchestrates all Micronets activities, most notably the creation of rules that manage device connectivity within the home network (e.g. home network  1406 ) and operator network (e.g., operator network  1414 ) to deliver services. The Micronets-enabled home network is thus composed of trust domains that are used to deliver managed services (e.g., managed services micronets  1410 ) to user-owned and user-managed devices and services. The managed services may then be automatically organized into appropriate network segments, and the micro-services interact with the network through a gateway (e.g., gateway  1408 ). Operator partners and third-party service operators (e.g., subsystems  1416 ) may interact with the Micronets manager through various APIs. 
     As described above, the intelligent services and business logic layer of the Micronets infrastructure serves as the interface for the Micronets platform to interact with the rest of the world. This layer may be configured to function as the receiver to combine user intent with business rules of the user services to perform operational decisions that may be handed over to the Micronets lowercase for execution. The intelligent services and business logic layer may further host various advanced services that may be enabled using cloud resources, and also receive information from various micro-services (e.g., from the SDN controller) and use this received information to dynamically update the operational decisions. Exemplary services include without limitation IoT fingerprinting for detection of devices in the network, third-party AI/ML-based systems that may be integrated with the intelligent services and business logic layer for malware detection and abnormal behavior, and mobility service management. 
     As described above, the Micronets manager is advantageously configured to coordinate the entire state of the Micronets-enabled on-premises/home network. The Micronets manager may be further configured to orchestrate the overall delivery of the various services to the plurality of devices, and then ultimately to the user. Microservices that may be are engaged and managed by the Micronets manager include without limitation the SDN controller, as well as the DHCP, DNS, and AAA/identity servers. 
     In the exemplary embodiment the home/on-premises network may be automatically set up by the SDN switch, which is responsible for creating the micro-networks. Intervention by or interaction with individual users or customers is not needed. Users of the home network may instead be advantageously enabled to interact with the network through a simplified interface, such as a smart phone application, to input the intentions of the user, which then may be automatically implemented by the Micronets platform without further intervention by or attention from the user. 
     In some embodiments, the home network may further include either or both of managed services (e.g., managed services micronets  1410 ) and customer micro-networks (e.g., home owner micronets  1412 ). In the case of managed services, operators are enabled to leverage the Micronets platform to implement micro-networks of devices for managed services, such as in the case for the operator&#39;s own organic service offerings (e.g., security services), or to support a third-party operator (e.g., a health care operator using remote patient monitoring). In either case, the Micronets platform enables the user to control what services are allowed or enabled. In the case of customer micro-networks, individual users are enabled to acquire and connect their own devices, and may be further enabled to integrate entire service-oriented networks (e.g., smart home lighting systems, etc.). In some cases, such customer-networked devices may be fingerprinted or authenticated using an ecosystem certificate and automatically placed into an appropriate micro-network, or a customer may manually request the creation of a new micro-network. 
     The Micronets gateway thus remains a core networking component of the Micronets platform. The Micronets gateway implements a software-managed switch that is controlled using the SDN paradigm. In an exemplary embodiment, Gateway supports connectivity for both wired and wireless components, with an equivalency in user experience a respective of whether the connectivity is wired or wireless. 
     As described above, the several exemplary Micronets APIs described herein are particular useful for partners and service providers to interface with the the particular Micronets environment of the customer or home network user to provision and deliver specific services requested by, or prescribed for, the user. 
     The present systems and methods are therefore of particular usefulness to collaborative operators and the vendors by providing standardized Micronets architectures and interfaces that may be easily adapted to different access configurations without requiring individual customization. In some cases, the present embodiments may be configured to utilize a reference code that integrates into common gateway development kits (e.g., OpenWRT and RDK). The present Micronets platform enables porting of SDN concepts, as well as easier development of technology to address particular needs of on-premise networks. The embodiments herein further enable the development of standardized APIs having requisite security controls, which thereby allow intelligent services to interact with the respective gateways. For example, instead of a dedicated, vendor-specific AI-enabled gateway, the new API may be used to provide a standard approach for AI solution providers to deliver advanced services using ML and neural network capabilities in the cloud. Furthermore, the present embodiments enable the development of yet additional APIs to enable third parties (e.g., health care providers) to securely interface with operators. 
     According to the present embodiments, the introduction of SDN capability in the home network enables a more secure and simple consumer experience. Additionally, the leveraging of a strong identity management and heuristic-based analysis provides capability to the core for automating the set up of subscriber networks, but without sacrificing privacy or increasing complexity. This automatic set up capability thereby advantageously enables the introduction of advanced machine learning or neural network capabilities without the need to deploy additional platforms. 
     Exemplary embodiments of systems and methods for establishing and managing micro nets for electronic devices are described above in detail. The systems and methods of this disclosure though, are not limited to only the specific embodiments described herein, but rather, the components and/or steps of their implementation may be utilized independently and separately from other components and/or steps described herein. 
     Although specific features of various embodiments of the disclosure may be shown in some drawings and not in others, this convention is for convenience purposes and ease of description only. In accordance with the principles of the disclosure, a particular feature shown in a drawing may be referenced and/or claimed in combination with features of the other drawings. 
     Some embodiments involve the use of one or more electronic or computing devices. Such devices typically include a processor or controller, such as a general purpose central processing unit (CPU), a graphics processing unit (GPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic circuit (PLC), a field programmable gate array (FPGA), a digital signal processing (DSP) device, and/or any other circuit or processor capable of executing the functions described herein. The processes described herein may be encoded as executable instructions embodied in a computer readable medium, including, without limitation, a storage device and/or a memory device. Such instructions, when executed by a processor, cause the processor to perform at least a portion of the methods described herein. The above examples are exemplary only, and thus are not intended to limit in any way the definition and/or meaning of the term “processor.” 
     This written description uses examples to disclose the embodiments, including the best mode, and also to enable any person skilled in the art to practice the embodiments, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the disclosure is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal language of the claims. 
     Changes may be made in the above methods and systems without departing from the scope hereof. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall therebetween. 
     
       
         
           
               
               
             
               
                   
               
               
                    
                 Computer Program Listing 1 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                   
                 module micronets { 
               
               
                   
                  namespace “urn:inocybe:params:xml:ns:yang:micronets”; 
               
               
                   
                  prefix micronets; 
               
               
                   
                  import ietf-inet-types { 
               
               
                   
                    prefix inet; 
               
               
                   
                    revision-date 2013-07-15; 
               
               
                   
                  } 
               
               
                   
                  import ietf-yang-types { 
               
               
                   
                    prefix yang; 
               
               
                   
                    revision-date 2013-07-15; 
               
               
                   
                  } 
               
               
                   
                  import ovsdb { 
               
               
                   
                   prefix ovsdb; 
               
               
                   
                   revision-date 2015-01-05; 
               
               
                   
                  } 
               
               
                   
                  organization “Inocybe Technologies, Inc”; 
               
               
                   
                  contact “Brady Johnson &lt;bjohnson@inocybe.com&gt;”; 
               
               
                   
                  description “Model definition for the Micronets project”; 
               
               
                   
                  revision 2018-02-01 { 
               
               
                   
                   description “Initial revision”; 
               
               
                   
                  } 
               
               
                   
                  grouping ip-filter-grouping { 
               
               
                   
                   description 
               
               
                   
                     “IP and Layer 4 white list filter. Possible options are: 
               
               
                   
                     - Only specify a filter IP. All layer 4 protocols will 
               
               
                   
                      be allowed to the specified IP 
               
               
                   
                     - Specify both filter IP and 14 port. 3 flows will be 
               
               
                   
                      created: one for TCP, UDP, and ICMP. 
               
               
                   
                     - Only specify 14 port. Layer 4 traffic will be allowed 
               
               
                   
                      to any IP. 
               
               
                   
                     - No filter IP nor 14 port. All Internet traffic will 
               
               
                   
                      be blocked.”; 
               
               
                   
                   leaf filter-name { 
               
               
                   
                    description “Filter name, used as filter key.”; 
               
               
                   
                    type string; 
               
               
                   
                    mandatory true; 
               
               
                   
                   } 
               
               
                   
                   leaf filter-ip { 
               
               
                   
                    description “IP address version-neutral filter.”; 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                   } 
               
               
                   
                   leaf filter-14-port { 
               
               
                   
                     description “Optional layer 4 port to filter on.”; 
               
               
                   
                     type inet:port-number; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping micronet-grouping { 
               
               
                   
                   description “Micronet definition”; 
               
               
                   
                   leaf name { 
               
               
                   
                    type string; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “The name of the service node”; 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-subnet { 
               
               
                   
                    type inet:ip-prefix; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “IP version neutral subnet of the form 192.168.1.0/24”; 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-subnet-id { 
               
               
                   
                    type string; 
               
               
                   
                    description “Set and used externally by orchestration systems.”; 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-gateway-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “The IP address of the micronet gateway.”; 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-vlan { 
               
               
                   
                    type uint16 { 
               
               
                   
                     range “1..4094”; 
               
               
                   
                    } 
               
               
                   
                    description “Micronet VLAN ID”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-manager-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description 
               
               
                   
                     “The IP address of the OVS Manager where this OVS bridge resides.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-manager-port { 
               
               
                   
                    type inet:port-number; 
               
               
                   
                    description “The TCP port of the OVS Manager where this 
               
               
                   
                         OVS bridge resides, default 6640.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-name { 
               
               
                   
                    type string; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “The OVS Bridge name to be used for this Micronet.”; 
               
               
                   
                   } 
               
               
                   
                   leaf trunk-gateway-port { 
               
               
                   
                    type string; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “OVS bridge port used for the trunk gateway.”; 
               
               
                   
                   } 
               
               
                   
                   leaf trunk-gateway-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “IP version neutral address of the trunk gateway.”; 
               
               
                   
                   } 
               
               
                   
                   leaf dhcp-server-port { 
               
               
                   
                    type uint16; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “OVS bridge port the DHCP server is connected to”; 
               
               
                   
                   } 
               
               
                   
                   leaf dhcp-zone { 
               
               
                   
                    type inet:ip-prefix; 
               
               
                   
                    mandatory true; 
               
               
                   
                    description “IP version neutral DHCP server zone”; 
               
               
                   
                   } 
               
               
                   
                   list allowed-micronet2micronet-routing { 
               
               
                   
                    description “A list of which Micronets this Micronet can communicate with”; 
               
               
                   
                    key “dst-micronet”; 
               
               
                   
                    leaf dst-micronet { 
               
               
                   
                     type string; 
               
               
                   
                    } 
               
               
                   
                   } 
               
               
                   
                   list allowed-inter-micronet2device-routing { 
               
               
                   
                    description “A list of which external devices all devices on 
               
               
                   
                         this Micronet can communicate with”; 
               
               
                   
                    key “dst-mac”; 
               
               
                   
                    leaf dst-mac { 
               
               
                   
                     type yang:mac-address; 
               
               
                   
                    } 
               
               
                   
                   } 
               
               
                   
                   list allowed-device2micronet-routing { 
               
               
                   
                    description “A list of allowed device to Micronet communications”; 
               
               
                   
                    key “dst-micronet src-mac”; 
               
               
                   
                    leaf dst-micronet { 
               
               
                   
                     type string; 
               
               
                   
                    } 
               
               
                   
                    leaf src-mac { 
               
               
                   
                     type yang:mac-address; 
               
               
                   
                    } 
               
               
                   
                   } 
               
               
                   
                   list allowed-device2device-routing { 
               
               
                   
                    description “A list of allowed device to device communications”; 
               
               
                   
                    key “src-mac dst-mac”; 
               
               
                   
                    leaf src-mac { 
               
               
                   
                     type yang:mac-address; 
               
               
                   
                    } 
               
               
                   
                    leaf dst-mac { 
               
               
                   
                     type yang:mac-address; 
               
               
                   
                    } 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-id { 
               
               
                   
                    config false; 
               
               
                   
                    type uint32; 
               
               
                   
                    description “A unique Micronet ID, to be used in the OpenFlow tables”; 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-bridge-nodeid { 
               
               
                   
                    config false; 
               
               
                   
                    type inet:uri; 
               
               
                   
                    description “Open vSwitch bridge Nodeld for this Micronet”; 
               
               
                   
                   } 
               
               
                   
                   leaf micronet-bridge-openflow-node-id { 
               
               
                   
                    config false; 
               
               
                   
                    type string; 
               
               
                   
                    description “Openflow Nodeld for this Micronet”; 
               
               
                   
                   } 
               
               
                   
                   list connected-devices { 
               
               
                   
                    config false; 
               
               
                   
                    key “device-mac”; 
               
               
                   
                    leaf device-mac { 
               
               
                   
                     type yang:mac-address; 
               
               
                   
                    } 
               
               
                   
                    leaf device-ip { 
               
               
                   
                     type inet:ip-address; 
               
               
                   
                    } 
               
               
                   
                    leaf device-name { 
               
               
                   
                     type string; 
               
               
                   
                    } 
               
               
                   
                    leaf device-id { 
               
               
                   
                     type string; 
               
               
                   
                    } 
               
               
                   
                    leaf device-openflow-port {  
               
               
                   
                     type uint32; 
               
               
                   
                     description “OpenFlow port device is connected to”; 
               
               
                   
                    } 
               
               
                   
                    list internet-filters { 
               
               
                   
                     description “White list of IP filters for device outgoing internet 
               
               
                   
                 traffic”; 
               
               
                   
                     key “filter-name”; 
               
               
                   
                     uses ip-filter-grouping; 
               
               
                   
                    } 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  container micronets { 
               
               
                   
                   list micronet { 
               
               
                   
                    key “name”; 
               
               
                   
                    uses micronet-grouping; 
               
               
                   
                    description “List containing all defined micronetes”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
               
             
               
                   
                   
               
               
                   
                   
                 Computer Program Listing 2 
               
               
                   
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 { 
               
               
                   
                   
                  “micronets” : [ 
               
               
                   
                   
                   { 
               
               
                   
                   
                    “name” : “unet1”, 
               
            
           
           
               
               
               
               
            
               
                   
                   
                    “micronet-subnet” 
                 : “192.168.1.0/24”, 
               
               
                   
                   
                    “micronet-gateway-ip”  
                 : “192.168.1.1”, 
               
               
                   
                   
                    “micronet-vlan” 
                 : “500”, 
               
               
                   
                   
                    “dhcp-server-port” 
                 : “1”, 
               
               
                   
                   
                    “dhep-zone” 
                 : “192.168.1.0/24”, 
               
               
                   
                   
                    “trunk-gateway-port”  
                 : “1”, 
               
               
                   
                   
                    “trunk-gateway-ip” 
                 : “10.36.32.55”, 
               
               
                   
                   
                    “ovs-bridge-name” 
                 : “brmn001”, 
               
               
                   
                   
                    “ovs-manager-ip” 
                 : “10.36.32.55”, 
               
            
           
           
               
               
               
            
               
                   
                   
                    “allowed-micronet2micronet-routing” : [ 
               
               
                   
                   
                     { 
               
               
                   
                   
                      “name” : “unet2” 
               
               
                   
                   
                     } 
               
               
                   
                   
                    ] 
               
               
                   
                   
                   }, 
               
               
                   
                   
                   { 
               
               
                   
                   
                    “name” : “unet2”, 
               
            
           
           
               
               
               
               
            
               
                   
                   
                    “micronet-subnet” 
                 : “192.168.2.0/24”, 
               
               
                   
                   
                    “micronet-gateway-ip”  
                 : “192.168.2.1”, 
               
               
                   
                   
                    “micronet-vlan” 
                 : “600”, 
               
               
                   
                   
                    “dhcp-server-port” 
                 : “1”, 
               
               
                   
                   
                    “dhcp-zone” 
                 : “192.168.1.0/24”, 
               
               
                   
                   
                    “trunk-gateway-port”  
                 : “1”, 
               
               
                   
                   
                    “trunk-gateway-ip” 
                 : “10.36.32.55”, 
               
               
                   
                   
                    “ovs-bridge-name” 
                 : “brmn001”, 
               
               
                   
                   
                    “ovs-manager-ip” 
                 : “10.36.32.55”, 
               
            
           
           
               
               
               
            
               
                   
                   
                    “allowed-micronet2micronet-routing” : [ 
               
               
                   
                   
                     { 
               
               
                   
                   
                      “name” : “unet1” 
               
               
                   
                   
                     } 
               
               
                   
                   
                    ] 
               
               
                   
                   
                   } 
               
               
                   
                   
                  ] 
               
               
                   
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 3 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 { 
               
               
                  “micronets” : [ 
               
               
                   { 
               
               
                    “name” : “unet1”, 
               
            
           
           
               
               
            
               
                    “micronet-subnet” 
                 : “192.168.1.0/24”, 
               
               
                    “micronet-gateway-ip”  
                 : “192.168.1.1”, 
               
               
                    “micronet-vlan” 
                 : “500”, 
               
               
                    “dhcp-server-port” 
                 : “1”, 
               
               
                    “dhep-zone” 
                 : “192.168.1.0/24”, 
               
               
                    “trunk-gateway-port”  
                 : “1”, 
               
               
                    “trunk-gateway-ip” 
                 : “10.36.32.55”, 
               
               
                    “ovs-bridge-name” 
                 : “brmn001”, 
               
               
                    “ovs-manager-ip” 
                 : “10.36.32.55”, 
               
               
                    “micronet-id“ 
                 : “1533570861”, 
               
            
           
           
               
            
               
                    “micronet-bridge-nodeid” : “Some-Bridge-NodeID”, 
               
               
                    “micronet-bridge-openflow-node-id” : “openflow: 2945788526319” , 
               
               
                    “allowed-micronet2micronet-routing” : [ 
               
               
                     { 
               
               
                      “name” : “unet2” 
               
               
                     } 
               
               
                    ] 
               
               
                   }, 
               
               
                   { 
               
               
                    “name” : “unet2”, 
               
            
           
           
               
               
            
               
                    “micronet-subnet” 
                 : “192.168.2.0/24”, 
               
               
                    “micronet-gateway-ip”  
                 : “192.168.2.1”, 
               
               
                    “micronet-vlan” 
                 : “600”, 
               
               
                    “dhcp-server-port” 
                 : “1”, 
               
               
                    “dhcp-zone” 
                 : “192.168.1.0/24”, 
               
               
                    “trunk-gateway-port”  
                 : “1”, 
               
               
                    “trunk-gateway-ip” 
                 : “10.36.32.55”, 
               
               
                    “ovs-bridge-name” 
                 : “brmn001”, 
               
               
                    “ovs-manager-ip” 
                 : “10.36.32.55”, 
               
               
                    “micronet-id“ 
                 : “1533570862”, 
               
            
           
           
               
            
               
                    “micronet-bridge-nodeid” : “Some-Bridge-NodeID”, 
               
               
                    “micronet-bridge-openflow-node-id” : “openflow: 2945788526319” , 
               
               
                    “allowed-micronet2micronet-routing” : [ 
               
               
                     { 
               
               
                      “name” : “unet1” 
               
               
                     } 
               
               
                    ] 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
             
               
                   
               
               
                   
                 Computer Program Listing 4 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                   
                 module micronets-notifications { 
               
               
                   
                  namespace “urn:inocybe:params:xml:ns:yang:micronets-notifications”; 
               
               
                   
                  prefix micronets-notifications; 
               
               
                   
                  import ietf-inet-types { 
               
               
                   
                    prefix inet; 
               
               
                   
                    revision-date 2013-07-15; 
               
               
                   
                  } 
               
               
                   
                  import ietf-yang-types { 
               
               
                   
                    prefix yang; 
               
               
                   
                    revision-date 2013-07-15; 
               
               
                   
                  } 
               
               
                   
                  organization “Inocybe Technologies, Inc”; 
               
               
                   
                  contact “Brady Johnson &lt;bjohnson@inocybe.com&gt;”; 
               
               
                   
                  description “Model definition for Micronets Notifications”; 
               
               
                   
                  revision 2018-02-01 { 
               
               
                   
                   description “Initial revision”; 
               
               
                   
                  } 
               
               
                   
                  grouping notification-odl-started { 
               
               
                   
                   description “Notification that the ODL controller has started”; 
               
               
                   
                  } 
               
               
                   
                  grouping notification-ovs-manager-connected { 
               
               
                   
                   description “Notification that an OVS manager connected”; 
               
               
                   
                   leaf ovs-mgr-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    description “The OVS Manager IP that connected.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-mgr-port { 
               
               
                   
                    type inet:port-number; 
               
               
                   
                    description “The OVS Manager TCP port that connected.”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-ovs-manager-disconnected { 
               
               
                   
                   description “Notification that an OVS manager disconnected”; 
               
               
                   
                   leaf ovs-mgr-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    description “The OVS Manager IP that disconnected.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-mgr-port { 
               
               
                   
                    type inet:port-number; 
               
               
                   
                    description “The OVS Manager TCP port that connected.”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-ovs-bridge-created { 
               
               
                   
                   description “Notification that an OVS bridge was created”; 
               
               
                   
                   leaf ovs-mgr-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    description “The OVS Manager IP where the bridge was created.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-name { 
               
               
                   
                    type string; 
               
               
                   
                    description “The name of the newly created bridge”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-ovs-bridge-deleted { 
               
               
                   
                   description “Notification that an OVS bridge was deleted”; 
               
               
                   
                   leaf ovs-mgr-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    description “The OVS Manager IP where the bridge was deleted.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-name { 
               
               
                   
                    type string; 
               
               
                   
                    description “The name of the newly deleted bridge”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-ovs-bridge-port-change { 
               
               
                   
                   description “Micronet definition”; 
               
               
                   
                   leaf ovs-mgr-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    description “The OVS Manager IP where the bridge is located.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-name { 
               
               
                   
                    type string; 
               
               
                   
                    description “The name of the OVS bridge the port is on.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-port-name { 
               
               
                   
                    type string; 
               
               
                   
                    description “The OVS bridge port name”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-port-of-port-number { 
               
               
                   
                    type string; 
               
               
                   
                    description “The OVS bridge port OpenFlow port number.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-port-mac { 
               
               
                   
                    type yang:mac-address; 
               
               
                   
                    description “The OVS bridge port MAC address.”; 
               
               
                   
                   } 
               
               
                   
                   leaf is-port-up { 
               
               
                   
                    type boolean; 
               
               
                   
                    description “True if the port was brought up, False if it went down.”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-unknown-device { 
               
               
                   
                   leaf device-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-mac { 
               
               
                   
                    type yang:mac-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-switch-port { 
               
               
                   
                    type uint32; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-unknown-bridge-port { 
               
               
                   
                   leaf ovs-mgr-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                    description “The OVS Manager IP where the bridge is located.”; 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-name { 
               
               
                   
                    type string; 
               
               
                   
                    description “The name of the OVS bridge the port is on.”; 
               
               
                   
                   } 
               
               
                   
                   leaf bridge-port { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-forbidden-inter-micronet-routing { 
               
               
                   
                   leaf device-src-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-src-mac { 
               
               
                   
                    type yang:mac-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-src-id { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                   leaf device-src-name { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                   leaf device-dest-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-dest-mac { 
               
               
                   
                    type yang:mac-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-dest-id { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                   leaf device-dest-name { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  grouping notification-forbidden-internet-routing { 
               
               
                   
                   leaf device-src-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-src-mac { 
               
               
                   
                    type yang:mac-address; 
               
               
                   
                   } 
               
               
                   
                   leaf device-src-id { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                   leaf device-src-name { 
               
               
                   
                    type string; 
               
               
                   
                   } 
               
               
                   
                   leaf dest-ip { 
               
               
                   
                    type inet:ip-address; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  container micronets-notifications { 
               
               
                   
                   list micronet-notification { 
               
               
                   
                    ordered-by user; 
               
               
                   
                    key “notification-id”; 
               
               
                   
                    description “List containing all Micronets notifications.”; 
               
               
                   
                    leaf notification-id { 
               
               
                   
                     type uint64; 
               
               
                   
                     description “A unique notification identifier.”; 
               
               
                   
                    } 
               
               
                   
                    leaf timestamp { 
               
               
                   
                     type uint64; 
               
               
                   
                     mandatory true; 
               
               
                   
                     description 
               
               
                   
                       “The difference, measured in milliseconds, between the current 
               
               
                   
                       local time and the epoch at midnight, January 1, 1970 UTC.”; 
               
               
                   
                    } 
               
               
                   
                    container odl-started { 
               
               
                   
                     uses notification-odl-started; 
               
               
                   
                    } 
               
               
                   
                    container ovs-manager-disconnected { 
               
               
                   
                     uses notification-ovs-manager-disconnected; 
               
               
                   
                    } 
               
               
                   
                    container ovs-manager-connected { 
               
               
                   
                     uses notification-ovs-manager-connected; 
               
               
                   
                    } 
               
               
                   
                    container ovs-bridge-created { 
               
               
                   
                     uses notification-ovs-bridge-created; 
               
               
                   
                    } 
               
               
                   
                    container ovs-bridge-deleted { 
               
               
                   
                     uses notification-ovs-bridge-deleted; 
               
               
                   
                    } 
               
               
                   
                    container ovs-bridge-port-change { 
               
               
                   
                     uses notification-ovs-bridge-port-change; 
               
               
                   
                    } 
               
               
                   
                    container unknown-device { 
               
               
                   
                     uses notification-unknown-device; 
               
               
                   
                    } 
               
               
                   
                    container unknown-bridge-port { 
               
               
                   
                     uses notification-unknown-bridge-port; 
               
               
                   
                    } 
               
               
                   
                    container forbidden-inter-micronet-routing { 
               
               
                   
                     uses notification-forbidden-inter-micronet-routing; 
               
               
                   
                    } 
               
               
                   
                    container forbidden-internet-routing { 
               
               
                   
                     uses notification-forbidden-internet-routing; 
               
               
                   
                    } 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
             
               
                   
               
               
                   
                 Computer Program Listing 5 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                   
                 module micronets-device-filter { 
               
               
                   
                  namespace “urn:inocybe:params:xml:ns:yang:micronets-device-filter”; 
               
               
                   
                  prefix micronets-device-filter; 
               
               
                   
                  import ietf-inet-types { 
               
               
                   
                    prefix inet; 
               
               
                   
                    revision-date 2013-07-15; 
               
               
                   
                  } 
               
               
                   
                  import ietf-yang-types { 
               
               
                   
                    prefix yang; 
               
               
                   
                    revision-date 2013-07-15; 
               
               
                   
                  } 
               
               
                   
                  organization “Inocybe Technologies, Inc”; 
               
               
                   
                  contact “Brady Johnson &lt;bjohnson@inocybe.com&gt;, Ryan Goulding 
               
               
                   
                 &lt;rgoulding@inocybe.com&gt;”; 
               
               
                   
                  description “Model definition for Micronets Device Filtering”; 
               
               
                   
                  revision 2018-02-01 { 
               
               
                   
                   description “Initial revision”; 
               
               
                   
                  } 
               
               
                   
                  grouping ovs-bridge-details { 
               
               
                   
                   leaf ovs-manager-ip { 
               
               
                   
                     type inet:ip-address; 
               
               
                   
                     description “The IP address of the OVS Manager for this OVS bridge.” 
               
               
                   
                   } 
               
               
                   
                   leaf ovs-bridge-name { 
               
               
                   
                    type string; 
               
               
                   
                    description “The OVS Bridge name to be used for this filter.”; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                  container device-filters { 
               
               
                   
                   list device-filter-mac { 
               
               
                   
                    key device-mac; 
               
               
                   
                    leaf device-mac { 
               
               
                   
                     type yang:mac-address; 
               
               
                   
                    } 
               
               
                   
                    leaf drop-device-packets { 
               
               
                   
                     type boolean; 
               
               
                   
                     description “Drop packets if true, otherwise let them pass.” 
               
               
                   
                    } 
               
               
                   
                    uses ovs-bridge-details; 
               
               
                   
                   } 
               
               
                   
                   list device-filter-ip { 
               
               
                   
                    key device-ip; 
               
               
                   
                    leaf device-ip { 
               
               
                   
                     type inet:ip-address; 
               
               
                   
                    } 
               
               
                   
                    leaf drop-device-packets { 
               
               
                   
                     type boolean; 
               
               
                   
                     description “Drop packets if true, otherwise let them pass.” 
               
               
                   
                    } 
               
               
                   
                    uses ovs-bridge-details; 
               
               
                   
                   } 
               
               
                   
                  } 
               
               
                   
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 6 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 bridge:brmn001 
               
               
                 ovshost:10.36.32.55 
               
               
                 port_trunk:1 
               
               
                 port_wired:2 
               
               
                 port_wired2:3 
               
               
                 port_wireless:4 
               
               
                 port_bridge:LOCAL 
               
               
                 device_pia_mac:b8:27:eb:8d:3 
               
               
                 PUT http://{{odl_host}}:{{odl_port}}/restconf/config/micronets:micronets 
               
               
                 { 
               
               
                  “micronets” : { 
               
               
                   “micronet” : [ 
               
               
                    { 
               
               
                     “name” : “Micronet_Wired 250”, 
               
               
                     “micronet-subnet-id” : “WIRED_enp4s0”, 
               
               
                     “micronet-subnet” : “192.168.250.0/24”, 
               
               
                     “micronet-gateway-ip” : “192.168.250.1”, 
               
               
                     “trunk-gateway-port” : “{{port_trunk}}”, 
               
               
                     “trunk-gateway-ip” : “{{ovshost}}”, 
               
               
                     “dhcp-server-port” : “{{port_bridge}}”, 
               
               
                     “dhcp-zone” : “10.36.32.0/24”, 
               
               
                     “ovs-bridge-name” : “{{bridge}}”, 
               
               
                     “ovs-manager-ip” : “{{ovshost}}”, 
               
               
                     “connected-devices” : [ 
               
               
                       { 
               
               
                        “device-name” : “pia”, 
               
               
                        “device-id” : “Raspberry-Pi3-Model-B-v1.2”, 
               
               
                        “device-mac” : “b8:27:eb:8d:30:27”, 
               
               
                        “device-ip” : “192.168.250.2”, 
               
               
                        “device-openflow-port” : “{{port_wired}}“ 
               
               
                       } 
               
               
                     ] 
               
               
                    }, 
               
               
                    { 
               
               
                     “name” : “Micronet_Wired 251”, 
               
               
                     “micronet-subnet-id”: “WIRED_enp4s0”, 
               
               
                     “micronet-subnet” : “192.168.251.0/24”, 
               
               
                     “micronet-gateway-ip” : “192.168.251.1”, 
               
               
                     “trunk-gateway-port” : “{{port_trunk}}”, 
               
               
                     “trunk-gateway-ip” : “{{ovshost}}”, 
               
               
                     “dhcp-server-port” : “{{port_bridge}}”, 
               
               
                     “dhcp-zone” : “192.168.251.0724”, 
               
               
                     “ovs-bridge-name” : “{{bridge}}”, 
               
               
                     “ovs-manager-ip” : “{{ovshost}}”, 
               
               
                     “connected-devices” : [ 
               
               
                       { 
               
               
                        “device-name”: “pib”, 
               
               
                        “device-id”: “Raspberry-Pi3-Model-B-v1.2”, 
               
               
                        “device-mac” : “b8:27:eb:df:ae:a7”, 
               
               
                        “device-ip” : “192.168.251.2”, 
               
               
                        “device-openflow-port” : “{{port_wired2}}” 
               
               
                      } 
               
               
                    ] 
               
               
                   }, 
               
               
                   { 
               
               
                    “name” : “Micronet_Wireless_252”, 
               
               
                    “micronet-subnet-id”: “WIRELESS_wlp2s0”, 
               
               
                    “micronet-subnet” : “192.168.252.0/24”, 
               
               
                    “micronet-gateway-ip” : “192.168.252.1”, 
               
               
                    “trunk-gateway-port” : “{{port_trunk}}”, 
               
               
                    “trunk-gateway-ip” : “{{ovshost}}”, 
               
               
                    “dhcp-server-port” : “{{port_bridge}}”, 
               
               
                    “dhcp-zone” : “10.36.32.0/24”, 
               
               
                    “ovs-bridge-name” : “{{bridge}}”, 
               
               
                    “ovs-manager-ip” : “{{ovshost}}”, 
               
               
                     “connected-devices” : [ 
               
               
                      { 
               
               
                       “device-name”: “picw”, 
               
               
                       “device-id”: “Raspberry-Pi3-Model-B-v1.2”, 
               
               
                       “device-mac” : “b8:27:eb:ab : 41: 12” , 
               
               
                       “device-ip” : “192.168.252.2”, 
               
               
                       “device-openflow-port” : “{{port_wireless}} 
               
               
                          }, 
               
               
                      { 
               
               
                       “device-name”: “pidw”, 
               
               
                       “device-id”: “Raspberry-Pi3-Model-B-v1.2”, 
               
               
                       “device-mac” : “b8:27:eb:19:11:87”, 
               
               
                       “device-ip” : “192.168.252.3”, 
               
               
                       “device-openflow-port” : “{{port_wireless}} 
               
               
                      } 
               
               
                     ] 
               
               
                    } 
               
               
                   ]  
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
             
               
                   
               
               
                   
                 Computer Program Listing 7 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                   
                 OFPST_FLOW reply (OF1.3) (xid=0x2): 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=195,udp,tp_src=67 actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=195,udp,tp_dst=67 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=195,arp actions=goto_table:5 
               
               
                   
                 cookie=0xba5eba11, table=0, 
               
               
                   
                     priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.250.0/24 
               
               
                   
                     actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=0, 
               
               
                   
                     priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.251.0/24 
               
               
                   
                     actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=0, 
               
               
                   
                     priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.252.0/24 
               
               
                   
                     actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=110,ip,in_port=LOCAL,nw_src=10.36.32.55 actions=output:1 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=110,ip,in_port=1,nw_dst=10.36.32.55 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=3 actions=goto_table:10 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=2 actions=goto_table:10 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=4 actions=goto_table:10 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=100,in_port=1 actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=0, 
               
               
                   
                     priority=100,in_port=LOCAL 
               
               
                   
                     actions=load:0-&gt;NXM_NX_REG0[ ]goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=0, priority=5 actions=CONTROLLER:40 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=110,arp,arp_tpa=192.168.250.2,arp_op=1 actions=output:2 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=110,arp,arp_tpa=192.168.252.3,arp_op=1 actions=output:4 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=110,arp,arp_tpa=192.168.251.2,arp_op=1 actions=output:3 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=100,arp,dl_dst=b8:27:eb:ab:41:12,arp_op=2 actions=output:4 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=100,arp,dl_dst=b8:27:eb: 19:11:87,arp_op=2 actions=output:4 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=100,arp,dl_dst=b8:27:eb:8d:30:27,arp_op=2 actions=output:2 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=100,arp,dl_dst=b8:27:eb:df:ae:a7,arp_op=2 actions=output:3 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=100,arp,arp_op=1 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=5, priority=5 actions=drop 
               
               
                   
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:df:ae:a7 actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:8d:30:27 actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:19:ll:87 actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=10, priority=200,dl_src=b8:27:eb:ab:41:12 actions=goto_table:20 
               
               
                   
                 cookie=0xba5eba11, table=10, priority=5 actions=CONTROLLER:40 
               
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                     priority=300,ip,nw_src=10.36.32.55 
               
               
                   
                     actions=load:0-&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                     priority=300, ip,nw_src=192.168.250.0/24 
               
               
                   
                     actions=load:0x5b686f2d-&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                     priority=300,ip,nw_src=192.168.251.0/24 
               
               
                   
                     actions=load:0x5b686f2e-&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=20, 
               
               
                   
                     priority=300,ip,nw_src=192.168.252.0/24 
               
               
                   
                     actions=load:0x5b686f2f-&gt;NXM_NX_REG0[ ],goto_table:30 
               
               
                   
                 cookie=0xba5eba11, table=20, priority=5 actions=CONTROLLER:40 
               
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                     priority=500, ip,nw_dst=192.168.252.0/24 
               
               
                   
                     actions=load:0x5b686f2f-&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                     priority=500, ip,nw_dst=192.168.250.0/24 
               
               
                   
                     actions=load:0x5b686f2d-&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                     priority=500,ip, nw_dst=192.168.251.0/24 
               
               
                   
                     actions=load:0x5b686f2e-&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                 cookie=0xba5eba11, table=30, 
               
               
                   
                     priority=500,ip,nw_dst=10.36.32.55 
               
               
                   
                     actions=load:0-&gt;NXM_NX_REG1[ ],goto_table:40 
               
               
                   
                 cookie=0xba5eba11, table=30, priority=6 actions=goto_table:90 
               
               
                   
                 cookie=0xba5eba11, table=40, priority=400,reg0=0 actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=40, priority=400,reg1=0 actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=40, priority=400,reg0=0x5b686f2f,reg1=0x5b686f2f actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=40, priority=400,reg0=0x5b686f2d,reg1=0x5b686f2d actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=40, priority=400,reg0=0x5b686f2e,reg1=0x5b686f2e actions=goto_table:80 
               
               
                   
                 cookie=0xba5eba11, table=40, priority=5 actions=goto_table:50 
               
               
                   
                 cookie=0xba5eba11, table=50, priority=5 actions=goto_table:60 
               
               
                   
                 cookie=0xba5eba11, table=60, priority=5 actions=goto_table:70 
               
               
                   
                 cookie=0xba5eba11, table=70, priority=5 actions=CONTROLLER:40 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=600,ip,nw_dst=10.36.32.55 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.252.2 actions=output:4 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.251.2 actions=output:3 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.252.1 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.252.3 actions=output:4 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.250.2 actions=output:2 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.251.1 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.250.1 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=610,ip,in_port=1,nw_src=10.36.32.55 actions=LOCAL 
               
               
                   
                 cookie=0xba5eba11, table=80, priority=5 actions=drop 
               
               
                   
                 cookie=0xba5eba11, table=90, priority=5 actions=goto_table:100 
               
               
                   
                 cookie=0xba5eba11, table=100, priority=5 actions=LOCAL 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 8 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 PUT http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets:micronets 
               
               
                 { 
               
               
                  ″micronets″ : { 
               
               
                   ″micronet″ : [ 
               
               
                    { 
               
               
                     ″name″ : ″Micronet_Wired 250″, 
               
               
                     ″micronet-subnet-id″: ″WIRED_enp4s0″, 
               
               
                     ″micronet-subnet″ : ″192.168.250.0/24″, 
               
               
                     ″micronet-gateway-ip″ : ″192.168.250.1″, 
               
               
                     ″micronet-vlan″ : ″100″, 
               
               
                     ″dhcp-server-port″ : ″5″, 
               
               
                     ″dhcp-zone″ : ″192.168.1.0/24″, 
               
               
                     ″trunk-gateway-port″ : ″1″, 
               
               
                     ″trunk-gateway-ip″ : ″10.36.32.55″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″ 
               
               
                    } 
               
               
                   ] 
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 9 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 cookie=0xba5eba11, table=0, priority=195,udp,tp_src=67 actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=0, priority=195,arp actions=goto_table:5 
               
               
                 cookie=0xba5eba11, table=0, priority=195,udp,tp_dst=67 actions=output:5 
               
               
                 cookie=0xba5eba11, table=0, 
               
               
                  priority=120,ip,in_port=LOCAL,nw_src=10.36.32.55,nw_dst=192.168.250.0/24 
               
               
                  actions=goto_table:20 
               
               
                 cookie=0xba5eba11, table=0, priority=110,ip,in_port=1,nw_dst=10.36.32.55 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=0, 
               
               
                  priority=110,ip,in_port=LOCAL,nw_src=10.36.32.55 
               
               
                  actions=output:l 
               
               
                 cookie=0xba5eba11, table=0, priority=100,in_port=LOCAL actions=load:0- 
               
               
                 &gt;NXM_NX_REG0[],goto_table:30 
               
               
                 cookie=0xba5eba11, table=0, priority=100,in_port=1 actions=push_vlan:0x8100,goto_table:20 
               
               
                 cookie=0xba5eba11, table=0, priority=5 actions=CONTROLLER:40 
               
               
                 cookie=0xba5eba11, table=5, 
               
               
                  priority=105,arp,vlan_tci=0x1000/0x1000,arp_op=1 
               
               
                  actions=pop_vlan, LOCAL 
               
               
                 cookie=0xba5eba11, table=5, priority=100,arp,arp_op=1 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=5, priority=5 actions=drop 
               
               
                 cookie=0xba5eba11, table=10, priority=5 actions=CONTROLLER:40 
               
               
                 cookie=0xba5eba11, table=20, 
               
               
                  priority=300,ip,nw_src=10.36.32.55 
               
               
                  actions=load:0-&gt;NXM_NX_REG0[],goto_table:30 
               
               
                 cookie=0xba5eba11, table=20, 
               
               
                  priority=300,ip,nw_src=192.168.250.0/24 actions=load:0x5b6d921e- 
               
               
                  &gt;NXM_NX_REG0[],goto_table:30 
               
               
                 cookie=0xba5eba11, table=20,priority=5 actions=CONTROLLER:40 
               
               
                 cookie=0xba5eba11, table=30, 
               
               
                  priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=192.168.250.0/24 
               
               
                  actions=load:0x5b6d921e-&gt;NXM_NX_REG1[],set_field:4196-&gt;vlan_vid,goto_table:40 
               
               
                 cookie=0xba5eba11, table=30, 
               
               
                  priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=10.36.32.55 actions=load:0- 
               
               
                  &gt;NXM_NX_REG1[],set_field:4196-&gt;vlan_vid,goto_table:40 
               
               
                 cookie=0xba5eba11, table=30, priority=5 actions=goto_table:90 
               
               
                 cookie=0xba5eba11, table=40, priority=400,reg1=0 actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=40, 
               
               
                  priority=400,reg0=0x5b6d921e,reg1=0x5b6d921e 
               
               
                  actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=40, priority=400,reg0=0 actions=goto_table:80 
               
               
                 cookie=0xba5eba11, table=40, priority=5 actions=goto_table:50 
               
               
                 cookie=0xba5eba11, table=50, priority=5 actions=goto_table:60 
               
               
                 cookie=0xba5eba11, table=60, priority=5 actions=goto_table:70 
               
               
                 cookie=0xba5eba11, table=70, priority=5 actions=CONTROLLER:40 
               
               
                 cookie=0xba5eba11, table=80, priority=620,ip,nw_dst=192.168.250.1 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=80, priority=600,ip,nw_dst=10.36.32.55 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=80, priority=610,ip,in_port=1,nw_src=10.36.32.55 actions=LOCAL 
               
               
                 cookie=0xba5eba11, table=80, priority=5 actions=drop 
               
               
                 cookie=0xba5eba11, table=90, priority=5 actions=goto_table:100 
               
               
                 cookie=0xba5eba11, table=100, 
               
               
                  priority=800,vlan_tci=0x1000/0x1000 
               
               
                  actions=pop_vlan, LOCAL 
               
               
                 cookie=0xba5eba11, table=100, priority=5 actions=LOCAL 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 10 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 PUT http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets:micronets 
               
               
                 { 
               
               
                  ″micronets″ : { 
               
               
                   ″micronet″ : [ 
               
               
                    { 
               
               
                     ″name″ : ″Micronet_Wired 250″, 
               
               
                     ″micronet-subnet-id″: ″WIRED_enp4s0″, 
               
               
                     ″micronet-subnet″ : ″192.168.250.0/24″, 
               
               
                     ″micronet-gateway-ip″ : ″192.168.250.1″, 
               
               
                     ″trunk-gateway-port″ : ″1″, 
               
               
                     ″trunk-gateway-ip″ : ″10.36.32.55″, 
               
               
                     ″dhcp-server-port″ : ″5″, 
               
               
                     ″dhcp-zone″ : ″10.36.32.0/24″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″connected-devices″ : [ 
               
               
                      { 
               
               
                       ″device-name″: ″pia″, 
               
               
                       ″device-id″: ″Raspberry-Pi3-Model-B-v1.2″, 
               
               
                       ″device-mac″ : ″b8:27:eb:8d:30:27″, 
               
               
                       ″device-ip″ : ″192.168.250.2″, 
               
               
                       ″device-openflow-port″ : ″2″ 
               
               
                      } 
               
               
                     ] 
               
               
                    } 
               
               
                   ] 
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 11 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 PUT http ://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets:micronets 
               
               
                 { 
               
               
                  ″micronets″ : { 
               
               
                   ″micronet″ : [ 
               
               
                    { 
               
               
                     ″name″ : ″Micronet_Wired_250″, 
               
               
                     ″micronet-subnet-id″: ″WIRED_enp4s0″, 
               
               
                     ″micronet-subnet″ : ″192.168.250.0/24″, 
               
               
                     ″micronet-gateway-ip″ : ″192.168.250.1″, 
               
               
                     ″trunk-gateway-port″ : ″1″, 
               
               
                     ″trunk-gateway-ip″ : ″10.36.32.55″, 
               
               
                     ″dhcp-server-port″ : ″5″, 
               
               
                     ″dhcp-zone″ : ″10.36.32.0/24″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″connected-devices″ : [ 
               
               
                      { 
               
               
                       ″device-name″: ″pia″, 
               
               
                       ″device-id″: ″Raspberry-Pi3-Model-B-v1.2″, 
               
               
                       ″device-mac″ : ″b8:27:eb:8d:30:27″, 
               
               
                       ″device-ip″ : ″192.168.250.2″, 
               
               
                       ″device-openflow-port″ : ″2″, 
               
               
                       ″internet-filters″ : [ 
               
               
                        { 
               
               
                         ″filter-name″ : ″IP and L4″, 
               
               
                         ″filter-ip″ : ″192.168.100.50″, 
               
               
                         ″filter-14-port″ : ″8000″ 
               
               
                        } 
               
               
                       ] 
               
               
                      } 
               
               
                     ] 
               
               
                    } 
               
               
                   ] 
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 12 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 PUT http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets:micronets 
               
               
                 { 
               
               
                  ″micronets″ : { 
               
               
                   ″micronet″ : [ 
               
               
                    { 
               
               
                     ″name″ : ″Micronet_Wired_250″, 
               
               
                     ″micronet-subnet-id″: ″WIRED_enp4s0″, 
               
               
                     ″micronet-subnet″ : ″192.168.250.0/24″, 
               
               
                     ″micronet-gateway-ip″ : ″192.168.250.1″, 
               
               
                     ″trunk-gateway-port″ : ″1″, 
               
               
                     ″trunk-gateway-ip″ : ″10.36.32.55″, 
               
               
                     ″dhcp-server-port″ : ″5″, 
               
               
                     ″dhcp-zone″ : ″10.36.32.0/24″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″connected-devices″ : [ 
               
               
                      { 
               
               
                       ″device-name″: ″pia″, 
               
               
                       ″device-id″: ″Raspberry-Pi3-Model-B-v1.2″, 
               
               
                       ″device-mac″ : ″b8:27:eb:8d:30:27″, 
               
               
                       ″device-ip″ : ″192.168.250.2″, 
               
               
                       ″device-openflow-port″ : ″2″ 
               
               
                      } 
               
               
                     ] , 
               
               
                     ″allowed-micronet2micronet-routing″ : [ 
               
               
                      { 
               
               
                        ″dst-micronet″ : ″Micronet_Wired_251″ 
               
               
                      } 
               
               
                     ] , 
               
               
                     ″allowed-micronet2device-routing″ : [ 
               
               
                      { 
               
               
                        ″dst-mac″ : ″00:11:22:33:44:77″ 
               
               
                      } 
               
               
                     ] 
               
               
                    }, 
               
               
                    { 
               
               
                     ″name″ : ″Micronet_Wired_251″, 
               
               
                     ″micronet-subnet-id″: ″WIRED_enp4s0″, 
               
               
                     ″micronet-subnet″ : ″192.168.251.0/24″, 
               
               
                     ″micronet-gateway-ip″ : ″192.168.251.1″, 
               
               
                     ″trunk-gateway-port″ : ″1″, 
               
               
                     ″trunk-gateway-ip″ : ″10.36.32.55″, 
               
               
                     ″dhcp-server-port″ : ″5″, 
               
               
                     ″dhcp-zone″ : ″10.36.32.0/24″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″connected-devices″ : [ 
               
               
                      { 
               
               
                       ″device-name″: ″pib″, 
               
               
                       ″device-id″: ″Raspberry-Pi3-Model-B-v1.2″, 
               
               
                       ″device-mac″ : ″b8:27:eb:df:ae:a7″, 
               
               
                       ″device-ip″ : ″192.168.251.2″, 
               
               
                       ″device-openflow-port″ : ″3″ 
               
               
                      } 
               
               
                     ] , 
               
               
                     ″allowed-device2micronet-routing″ : [ 
               
               
                      { 
               
               
                        ″src-mac″ : ″b8:27:eb:df:ae:a7″, 
               
               
                        ″dst-micronet″ : ″Micronet_Wired_250″ 
               
               
                      } 
               
               
                     ] , 
               
               
                     ″allowed-device2device-routing″ : [ 
               
               
                      { 
               
               
                        ″src-mac″ : ″b8:27:eb:df:ae:a7″, 
               
               
                        ″dst-mac″ : ″00:11:22:33:44:77″ 
               
               
                      } 
               
               
                     ] 
               
               
                    } 
               
               
                   ] 
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 13 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 PUT http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter: device-filters 
               
               
                 { 
               
               
                  ″device-filters″ : { 
               
               
                   ″device-filter-mac″ : [ 
               
               
                    { 
               
               
                     ″device-mac″ : ″11:22:33:44:55:88″, 
               
               
                     ″drop-device-packets″ : false, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″ 
               
               
                    } 
               
               
                   ] , 
               
               
                   ″device-filter-ip″ : [ 
               
               
                    { 
               
               
                     ″device-ip″ : ″192.168.5.2″, 
               
               
                     ″drop-device-packets″ : true, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″ 
               
               
                    } 
               
               
                   ] 
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 14 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets:micronets 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 15 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets 
               
               
                 micronets/micronet/Micronet_Wired_250/ 
               
               
                 { 
               
               
                  ″micronets″ : { 
               
               
                   ″micronet″ : [ 
               
               
                    { 
               
               
                     ″name″ : ″Micronet_Wired_250″, 
               
               
                     ″micronet-subnet-id″: ″WIRED_enp4s0″, 
               
               
                     ″micronet-subnet″ : ″192.168.250.0/24″, 
               
               
                     ″micronet-gateway-ip″ : ″192.168.250.1″, 
               
               
                     ″trunk-gateway-port″ : ″1″, 
               
               
                     ″trunk-gateway-ip″ : ″10.36.32.55″, 
               
               
                     ″dhcp-server-port″ : ″5″, 
               
               
                     ″dhcp-zone″ : ″10.36.32.0/24″, 
               
               
                     ″ovs-bridge-name″ : ″brmn001″, 
               
               
                     ″ovs-manager-ip″ : ″10.36.32.55″, 
               
               
                     ″connected-devices″ : [ 
               
               
                      { 
               
               
                       ″device-name″: ″pia″, 
               
               
                       ″device-id″: ″Raspberry-Pi3-Model-B-v1.2″, 
               
               
                       ″device-mac″ : ″b8:27:eb:8d:30:27″, 
               
               
                       ″device-ip″ : ″192.168.250.2″, 
               
               
                       ″device-openflow-port″ : ″2″ 
               
               
                      } 
               
               
                     ] , 
               
               
                     ″allowed-micronet2micronet-routing″ : [ 
               
               
                      { 
               
               
                        ″dst-micronet″ : ″Micronet_Wired_251″ 
               
               
                      } 
               
               
                     ] , 
               
               
                     ″allowed-micronet2device-routing″ : [ 
               
               
                      { 
               
               
                        ″dst-mac″ : ″00:11:22:33:44:77″ 
               
               
                      } 
               
               
                     ] 
               
               
                    } 
               
               
                   ] 
               
               
                  }  
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 16 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets: 
               
               
                 micronets/micronet/Micronet_Wired_250/connected-devices/b8:27:eb:8d:30:27 
               
               
                 { 
               
               
                  ″connected-devices″: [ 
               
               
                    { 
               
               
                    ″device-name″: ″pia″, 
               
               
                    ″device-id″: ″Raspberry-Pi3-Model-B-v1.2″, 
               
               
                    ″device-mac″ : ″b8:27:eb:8d:30:27″, 
               
               
                    ″device-ip″ : ″192.168.250.2″, 
               
               
                    ″device-openflow-port″ : ″2″, 
               
               
                    ″internet-filters″: [ 
               
               
                      { 
               
               
                       ″filter-name″ : ″IP and L4″, 
               
               
                       ″filter-ip″ : ″192.168.100.50″, 
               
               
                       ″filter-14-port″ : ″8000″ 
               
               
                      } 
               
               
                     ] 
               
               
                    } 
               
               
                   ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 17 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET http://{{ODL_IP}}:{{ODL_PORT}}/restconf /operational/micronets 
               
               
                 micronets/micronet/Micronet_Wired_250/connected- 
               
               
                 devices/b8:27:eb:8d:30:27/ 
               
               
                 internet-filters/IP+and+L4 
               
               
                 { 
               
               
                  ″internet-filters″: [ 
               
               
                   { 
               
               
                    ″filter-name″ : ″IP and L4″, 
               
               
                    ″filter-ip″ : ″192.168.100.50″, 
               
               
                    ″filter-14-port″ : ″8000″ 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 18 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets:micronets/ 
               
               
                 micronet/Micronet_Wired_250/allowed-micronet2micronet- 
               
               
                 routing/Micronet_Wired_251 
               
               
                 { 
               
               
                  ″allowed-micronet2micronet-routing″: [ 
               
               
                   { 
               
               
                    ″dst-micronet″: ″Micronet_Wired_251″ 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 19 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets:micronets/ 
               
               
                 micronet/Micronet_Wired_250/allowed-micronet2device- 
               
               
                 routing/00:11:22:33:44:77 
               
               
                 { 
               
               
                  ″allowed-micronet2device-routing″: [ 
               
               
                   { 
               
               
                    ″dst-mac″: ″00:11:22:33:44:77″ 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 20 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets:micronets/ 
               
               
                 micronet/Micronet_Wired_251/allowed-device2micronet- 
               
               
                 routing/Micronet_Wired_250/00:11:22:33:44:77 
               
               
                 { 
               
               
                  ″allowed-micronet2device-routing″: [ 
               
               
                   { 
               
               
                    ″dst-micronet″: ″Micronet_Wired_250″, 
               
               
                    ″dst-mac″: ″00:11:22:33:44:77″ 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 21 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/micronets:micronets/ 
               
               
                 micronet/Micronet_Wired_251/allowed-device2device- 
               
               
                 routing/b8:27:eb:df:ae:a7/00:11:22:33:44:77/ 
               
               
                 { 
               
               
                  ″allowed-device2device-routing″: [ 
               
               
                   { 
               
               
                    ″src-mac″: ″b8:27:eb:df:ae:a7″, 
               
               
                    ″dst-mac″: ″00:11:22:33:44:77″ 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 22 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter:device-filters 
               
               
                 { 
               
               
                  ″device-filters″ : { 
               
               
                   ″device-filter-mac″ : [ 
               
               
                    { 
               
               
                     ″device-mac″ : ″11:22:33:44:55:88″, 
               
               
                     ″drop-device-packets″ : false, 
               
               
                     ″ovs-manager-ip″ : {{OVS_MGR_IP}}, 
               
               
                     ″ovs-bridge-name″ : {{OVS_BRIDGE_NAME}} 
               
               
                    } 
               
               
                   ] , 
               
               
                   ″device-filter-ip″ : [ 
               
               
                    { 
               
               
                     ″device-ip″ : ″192.168.5.2″, 
               
               
                     ″drop-device-packets″ : true, 
               
               
                     ″ovs-manager-ip″ : {{OVS_MGR_IP}}, 
               
               
                     ″ovs-bridge-name″ : {{OVS_BRIDGE_NAME}} 
               
               
                    } 
               
               
                   ] 
               
               
                  } 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 23 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter:device-filters/device-filter-mac/11:22:33:44:55:88 
               
               
                 { 
               
               
                  “device-filter-mac” : [ 
               
               
                   { 
               
               
                    “device-mac” : “11:22:33:44:55:88”, 
               
               
                    “drop-device-packets” : false, 
               
               
                    “ovs-manager-ip” : {{OVS_MGR_IP}}, 
               
               
                    “ovs-bridge-name” : {{OVS_BRIDGE_NAME}} 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 24 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter:device-filters/device-filter-ip/192.168.5.2 
               
               
                 { 
               
               
                  “device-filter-ip” : [ 
               
               
                   { 
               
               
                    “device-ip” : “192.168.5.2”, 
               
               
                    “drop-device-packets” : true, 
               
               
                    “ovs-manager-ip” : {{OVS_MGR_IP}}, 
               
               
                    “ovs-bridge-name” : {{OVS_BRIDGE_NAME}} 
               
               
                   } 
               
               
                  ] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 25 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/ 
               
               
                   
                   
                 micronets:micronets/ 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 26 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/ 
               
               
                   
                   
                 micronets:micronets/micronet/Micronet_Wired_250/ 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 27 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/ 
               
               
                   
                   
                 micronets:micronets/micronet/Micronet_Wired_250/ 
               
               
                   
                   
                 connected-devices/00:11:22:33:44:55/ 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 28 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/ 
               
               
                   
                   
                 micronets:micronets/micronet/Micronet_Wired_250/connected- 
               
               
                   
                   
                 devices/00:11:22:33:44:55/internet-filters/block+IP 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
               
               
             
               
                   
                   
               
               
                   
                   
                 Computer Program Listing 29 
               
               
                   
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/ 
               
               
                   
                   
                 micronets:micronets/micronet/Micronet_Wired_250/allowed- 
               
               
                   
                   
                 micronet2micronet-routing/Micronet_Wired_251 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
               
               
             
               
                   
                   
               
               
                   
                   
                 Computer Program Listing 30 
               
               
                   
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/ 
               
               
                   
                   
                 micronets:micronets/micronet/Micronet_Wired_250/allowed- 
               
               
                   
                   
                 micronet2device-routing/00:11:22:33:44:77 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 31 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 DELETE 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/ 
               
               
                 micronets:micronets/micronet/Micronet_Wired_251/allowed- 
               
               
                 device2micronet-routing/Micronet_Wired_250/00:11:22:33:44:77 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
               
             
               
                   
                   
               
               
                   
                   
                 Computer Program Listing 32 
               
               
                   
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                   
                 DELETE 
               
               
                   
                   
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/operational/ 
               
               
                   
                   
                 micronets:micronets/micronet/Micronet_Wired_251/allowed- 
               
               
                   
                   
                 device2device-routing/b8:27:eb:df:ae:a7/00:11:22:33:44:77/ 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 33 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 DELETE 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter:device-filters/ 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 34 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 DELETE 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter:device-filters/device-filter-mac/11:22:33:44:55:88 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 35 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 DELETE 
               
               
                 http://{{ODL_IP}}:{{ODL_PORT}}/restconf/config/micronets-device- 
               
               
                 filter:device-filters/device-filter-ip/192.168.250.2 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 36 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                   
                 GET http://localhost:8181/restconf/config/micronets-notifications: 
               
               
                   
                 micronets-notifications 
               
               
                   
                 { 
               
               
                   
                  “micronets-notifications”: { 
               
               
                   
                   “micronet-notification”: [ 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1534156314429, 
               
               
                   
                     “timestamp”: 1534156314431, 
               
               
                   
                     “odl-started”: { } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1534156314430, 
               
               
                   
                     “timestamp”: 1534156357792, 
               
               
                   
                     “ovs-manager-connected”: { 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56”, 
               
               
                   
                      “ovs-mgr-port”: 6640 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1534156314431, 
               
               
                   
                     “timestamp”: 1534156357833, 
               
               
                   
                     “ovs-bridge-created”: { 
               
               
                   
                      “ovs-bridge-name”: “br0”, 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1534156314432, 
               
               
                   
                     “timestamp”: 1534156357943, 
               
               
                   
                     “ovs-bridge-port-change”: { 
               
               
                   
                      “ovs-bridge-name”: “br0”, 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56”, 
               
               
                   
                      “ovs-bridge-port-name”: “veth0-br”, 
               
               
                   
                      “ovs-bridge-port-of-port-number”: “1”, 
               
               
                   
                      “is-port-up”: true, 
               
               
                   
                      “ovs-bridge-port-mac”: “e6:e8:36:ee:75:61” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171733, 
               
               
                   
                     “timestamp”: 1534156357990, 
               
               
                   
                     “unknown-device”: { 
               
               
                   
                      “ovs-bridge-name”: “br0”, 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56”, 
               
               
                   
                      “device-bridge-port”: “1”, 
               
               
                   
                      “device-ip”: “192.168.1.2”, 
               
               
                   
                      “device-mac”: “00:11:22:33:44:55” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171734, 
               
               
                   
                     “timestamp”: 1534156357997, 
               
               
                   
                     “unknown-bridge-port”: { 
               
               
                   
                      “ovs-bridge-name”: “br0”, 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.26”, 
               
               
                   
                      “bridge-port”: “1” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171735, 
               
               
                   
                     “timestamp”: 1534156358193, 
               
               
                   
                     “forbidden-inter-micronet-routing”: { 
               
               
                   
                      “device-src-ip”: “192.168.1.2”, 
               
               
                   
                      “device-src-mac”: “00:11:22:33:44:55”, 
               
               
                   
                      “device-dest-ip”: “192.168.2.2”, 
               
               
                   
                      “device-dest-mac”: “00:11:22:33:44:77” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171736, 
               
               
                   
                     “timestamp”: 1534156358298, 
               
               
                   
                     “forbidden-internet-routing”: { 
               
               
                   
                      “device-src-ip”: “192.168.1.2”, 
               
               
                   
                      “device-src-mac”: “00:11:22:33:44:55”, 
               
               
                   
                      “device-src-id” : “DeviceId”, 
               
               
                   
                      “device-src-name” : “DeviceName”, 
               
               
                   
                      “device-dest-ip”: “192.168.2.2” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171737, 
               
               
                   
                     “timestamp”: 1534156358348, 
               
               
                   
                     “ovs-bridge-port-change”: { 
               
               
                   
                      “ovs-bridge-name”: “br0”, 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56”, 
               
               
                   
                      “ovs-bridge-port-name”: “veth0-br”, 
               
               
                   
                      “ovs-bridge-port-of-port-number”: “1”, 
               
               
                   
                      “is-port-up”: false, 
               
               
                   
                      “ovs-bridge-port-mac”: “e6:e8:36:ee:75:61” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171738, 
               
               
                   
                     “timestamp”: 1534156358972, 
               
               
                   
                     “ovs-bridge-deleted”: { 
               
               
                   
                      “ovs-bridge-name”: “br0”, 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56” 
               
               
                   
                     } 
               
               
                   
                    }, 
               
               
                   
                    { 
               
               
                   
                     “notification-id”: 1523454171739, 
               
               
                   
                     “timestamp”: 1534156359108, 
               
               
                   
                     “ovs-manager-disconnected”: { 
               
               
                   
                      “ovs-mgr-ip”: “192.168.86.56”, 
               
               
                   
                      “ovs-mgr-port”: 6640 
               
               
                   
                     } 
               
               
                   
                    } 
               
               
                   
                   ] 
               
               
                   
                  } 
               
               
                   
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 Computer Program Listing 37 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 GET http://localhost:8181/restconf/config/micronets- 
               
               
                 notifications:micronets-notifications/micronet-notification/1534156314429 
               
               
                 { 
               
               
                  “micronet-notification”: [ 
               
               
                   { 
               
               
                    “notification-id”: 1534156314429, 
               
               
                    “timestamp”: 1534156314431, 
               
               
                    “odl-started”: { } 
               
               
                   } 
               
               
                  ] 
               
               
                 }