Patent Application
20220272033
The present disclosure relates generally to telecommunications systems, and more particularly to techniques and mechanisms for a group-based service insertion for enterprise private networks for traffic flows, such as Fifth Generation (5G) traffic flows for remote hosts, using a Locator ID/Separation Protocol (LISP) control plane.
Service insertion poses challenges in enterprise private networks when multiple services need to be applied in relation to a particular traffic flow. Services may include firewall or security services, billing or accounting services, service level agreement (SLA) monitoring services, Quality of Service (QoS) policy services, and the like. These challenges become more prevalent in relation to enterprise software-defined access (SDA) or software-defined networking (SDN) fabrics, which are overlay-based and utilize group-based policy and segmentation. Service insertion in enterprise SDA/SDN fabrics is problematic due to the use of traditional service routers that would need to apply the services. Specifically, traditional service routers do not readily support the appropriate encapsulation and tagging (e.g. security group tags or “SGTs”) associated with overlay headers of data packets for appropriate processing.
Traditionally, access control list (ACL)/policies (e.g. for policy-based routing) are used on an edge or border router to redirect traffic to service routers. However, this approach does not scale well as the number of flows, groups, and/or subnets become larger, especially in relation to security services where the traffic needs to be routed to a particular service router (e.g. a firewall). In addition, ACLs consume a great deal of hardware or forwarding resources which may already be scarce, for example, on relatively low-end switches or routers.
In a solution, fabric routers that connect to services should be able to differentiate between pre-service and post-service traffic, so that traffic does not get routed back to apply same service again (e.g. looping) after post-service processing. As some services may fail, dynamic service updating is also a feature to consider, and such updating should be transparent to users as the system moves traffic from old to new service instances. Load-balancing to service instances (e.g. hash-based load balancing) should also be achievable in such a solution.
Even further, with the promise of Fifth Generation (5G) connectivity to provide high-speed direct communication via a shared 5G backbone network, specific services may need to be inserted in relation to 5G traffic flows that enter into or exit from an enterprise private network. Multiple services, such as security services and/or policy services, may need to be applied to 5G traffic flows from 5G endpoints.
Service insertion that is not bound by topological restrictions may be useful or essential for such communications. Consider, for example, the current working environment where in-person meetings are restricted (e.g. COVID-19 restrictions) and members of an organization are connected remotely. Here, an architecture that allows for dynamic service insertion could make the network truly location-independent (e.g. without requiring member traffic to be brought back into the enterprise private network). It would be advantageous if the general solution to enterprise SDA/SDN networks would inherently provide a solution in this environment.
So that the present disclosure can be understood by those of ordinary skill in the art, a more detailed description may be had by reference to aspects of some illustrative implementations, some of which are shown in the accompanying drawings.
Numerous details are described in order to provide a thorough understanding of the example implementations shown in the drawings. However, the drawings merely show some example aspects of the present disclosure and are therefore not to be considered limiting. Those of ordinary skill in the art will appreciate that other effective aspects and/or variants do not include all of the specific details described herein. Moreover, well-known systems, methods, components, devices and circuits have not been described in exhaustive detail so as not to obscure more pertinent aspects of the example implementations described herein.
Techniques and mechanisms for “dynamic” group-based service insertion for enterprise private networks for traffic flows using Locator ID/Separation Protocol (LISP) control plane or Map Server/Map Resolver (MS/MR) are described herein. Such techniques and mechanisms may be suitable for use in facilitating virtual enterprise networking with remote access and Fifth Generation (5G) traffic flows.
In one illustrative example, a method may be performed by one or more computing devices (a “computing device”) which implement a MS/MR of a LISP control plane for use in an enterprise private network. In some implementations, the enterprise private network may comprise a software-defined access (SDA) or software-defined networking (SDN) fabric. The computing device may be configured to facilitate communications from a first host that is located for communication via a first tunnel router to a second host that is located for communication via a second tunnel router. The first and the second hosts are assigned with first and second endpoint IDs (EIDs), respectively, and the first and the second tunnel routers are assigned with first and second routing locators (RLOCs), respectively.
In the method, the computing device may receive, from the first tunnel router, a message which indicates a map request for requesting an EID-to-RLOC mapping associated with the second EID, which is triggered in response to the first tunnel router receiving initial traffic of the communications from the first host. The computing device may select, from a policy database, the service insertion policy based on at least the second EID or a group identifier in the message. The service insertion policy may include an address of a service border router for a service that is registered with the MS/MR. The service may be one of firewall or security service, a billing or an accounting service, a service level agreement (SLA) monitoring service, or a Quality of Service (QoS) policy service, as a few examples. The computing device may send, to the first tunnel router, a message which indicates a map reply and includes the address of the service border router, for populating an overlay route in the first tunnel router to forward the communications via the service border router for insertion of the service.
On the other hand, when no service insertion policy exists, the computing device may select, from the mapping database, the second RLOC of the second tunnel router based on the second EID. The computing device may send, to the first tunnel router, the message which indicates the map reply and includes the second RLOC of the second tunnel router, for populating the route in the first tunnel router to forward the communications to the second tunnel router to the second host.
Prior to receiving the initial traffic of the communications from the first host, the computing device may receive, from the service border router, a message which indicates a service registration for registering the service with the MS/MR. In some implementations, service registration is performed by each one of a plurality of services available via the service border router. Here, the selecting of the service insertion policy may comprise selecting the service insertion policy from a plurality of service insertion policies respectively associated with the plurality of services registered with the MS/MR. In some implementations, the selecting of the service insertion policy from the plurality of service insertion policies may be performed according to a service ID associated with the service insertion policy or service.
In some implementations, the group identifier comprises a source group tag (SGT), and the service insertion policy may be selected based on at least the SGT and a destination group tag (DGT) associated with the second host. Here, the computing device may send, to the first tunnel router, the message which indicates the map reply and includes the address of the service border router, to further include the SGT, the DGT, and a group policy for application at the first tunnel router.
In some implementations, the service insertion policy further includes an instance ID associated with a virtual routing and forwarding (VRF) at the service border router. Here, the message which indicates the map reply may include the address of the service border router, a virtual network identifier of a virtual private network associated with the VRF, and the group identifier, for populating the overlay route in the first tunnel router to forward the communications, with encapsulation of the virtual network identifier and the group identifier, via the service border router for insertion of the service.
In some implementations, the service insertion policy further includes a virtual local area network (VLAN) ID of a VLAN. Here, the message which indicates the map reply may include the address of the service border router, the VLAN ID, and the group identifier, for populating the overlay route in the first tunnel router to forward the communications, with encapsulation of the VLAN ID and the group identifier, via the service border router for insertion of the service.
Subsequently (i.e. after processing associated with the service), the computing device may receive, from the service border router, a message which indicates another map request for requesting an EID-to-RLOC mapping associated with the second EID. The computing device may select, from a mapping database, the second RLOC of the second tunnel router based on the second EID. The computing device may send, to the service border router, a message which indicates another map reply and includes the second RLOC of the second tunnel router, for populating an overlay route in the service border router to forward the communications via the second tunnel router to the second host.
Accordingly, in some implementations, the computing device may select either the service insertion policy or the second RLOC of the second tunnel router, based on identifying an indication (e.g. a message indication) of whether the message which indicates the map request or the other map request is sent from the first tunnel router or the service border router.
When the second host is a 5G endpoint which is located for communication via the second tunnel router that is external to the enterprise private network, the computing device may receive, from the service border router, a message which indicates another map request for requesting an EID-to-RLOC mapping associated with the second EID. The computing device may send, to the service border router, a message which indicates another map reply and include a third RLOC of a border router, for populating an overlay route in the border router to the second host via the second tunnel router that is external to the enterprise private network.
In some implementations, the computing device may comprise one or more processors, one or more interfaces to connect in a network for SDA or SDN, and one or more memory elements for storing instructions executable on the one or more processors for operation as the MS/MR of the LISP control plane as described. In some preferred implementations, the computing device may implement the MS/MR of the LISP control plane as well as tunnel router functionality on the same device (with logical separation). In some implementations, the method may be embodied in a computer program product comprising a non-transitory computer readable medium and instructions stored on the non-transitory computer readable medium, where the instructions are executable by one or more processors of a computing device for operation as the MS/MR of the LISP control plane as described.
One or more advantages may be realized depending on the implementation. When a service (or its associated path) becomes unavailable or is taken off-line, the service border router may send a message for service deregistration of the service. When the service (or its associated path) becomes available again or is brought back on-line, the service border router may again send a message for service registration for registration of the service. When a new or updated service becomes available, the service border router may send a message for service registration for registration of the new or updated service. As is apparent, the MS/MR may be updated dynamically for indicating the availability or non-availability of services. A plurality of service routers/service instances associated with a (e.g. single) service may register/deregister for load balancing and/or redundancy for the service.
More detailed and alternative techniques and implementations are provided herein as described below.
As described earlier above in the Background section, service insertion poses challenges in enterprise private networks when multiple services need to be applied in relation to a particular traffic flow. These challenges become more prevalent in relation to enterprise software-defined access (SDA) or software-defined networking (SDN) fabrics, which are overlay-based and utilize group-based policy and segmentation.
In general, a network overlay may employ software virtualization to create an additional layer of network abstraction on top of a physical network. Such a network overlay may be used to provide virtual private networking (VPN) for hosts in a network. Specifically, routers in the network may be configured to operate using a network overlay protocol to facilitate VPN networking. The protocol may be, for example, Locator ID/Separation Protocol (LISP); however, other suitable alternatives may be utilized, such as Border Gateway Protocol (BGP) Ethernet VPN (EVPN) (BGP-EVPN), Virtual Extensible LAN (VXLAN), Enhanced VLAN (EVLAN), or Identifier Locator Addressing (ILA). Here, the routers create and maintain multiple VPN instances comprising forwarding tables for the routing of user plane traffic associated with different VPNs.
The technology utilized may be based on or referred to as virtual routing and forwarding (VRF) technology. Such network virtualization creates multiple, logically-separated topologies across one common physical infrastructure. Network reachability within a VPN is typically restricted to the addresses of the end-points that are members of the VPN. Such a level of segmentation is useful in providing fault isolation, enforcing access-control restrictions, enabling the use of a single network by multiple tenants, and scoping network policy per VPN.
In general, LISP is a network architecture and protocol that uses multiple namespaces or network addresses for identifying and locating network nodes, such as an identity namespace or address space and a location namespace or address space. This is distinguishable from a conventional network that may only use a single namespace or address space (e.g. Internet Protocol “IP” addresses) for both identifying and locating network nodes. LISP can assign addresses in the identity namespace (e.g., Endpoint Identifier or “EID” namespace) to hosts, and addresses in the location name space (e.g., Routing Locator or “RLOC” namespace) to network devices. LISP can maintain a directory of identifiers and their corresponding locations (e.g., a directory mapping of the EID namespace to the RLOC namespace). LISP, as a protocol, can define the signaling to populate this directory, keep it updated, and enable network devices to consult the directory and resolve the locations of EIDs of interest. Routing and forwarding of data packets can continue to be the responsibility of traditional routing protocols in the RLOC namespace but LISP can augment these protocols by adding another namespace to enable functionality that may otherwise be difficult to achieve natively in traditional routing protocols. Because of the separation of the namespaces and their loose coupling with basic routing and forwarding, the definition of EIDs and RLOCs can extend beyond addressing to include policy semantics and other metadata to provide features such as host mobility, large-scale segmentation, traffic engineering, location-aware policies, location tracking services, and so forth. A WAN platform that can integrate LISP (or similar technology for separating host identifier information and host location information) across multiple LANs can take further advantage of the decoupling of host identity and location.
Again, LISP provides two namespaces: an EID namespace and a RLOC namespace. A host (e.g. a computer or a server) may be associated with an EID (e.g. an IP address), whereas a router may be associated with an RLOC (e.g. an IP address). A router may be an ITR, an ETR, or a combination thereof (ITR+ETR=XTR). A LISP Mapping System (e.g. including a mapping server and/or database) maps EIDs to RLOCs. Either the EID space, the RLOC space, or both, may be segmented. The LISP Mapping System can be used to map a segmented EID address space to the RLOC space. When the EID namespace is segmented, a LISP Instance-ID (IID) is encoded in both the data plane and the control plane to provide segmentation as well as to disambiguate overlapping EID Prefixes. This allows multiple VRFs to share a common routing locator network while maintaining EID prefix segmentation.
In a LISP VPN, XTRs that are members of the VPN should be configured with a forwarding context (e.g. a VRF) and the associated IID for the VPN. Based on this configuration, the ETRs must register the EIDs within the forwarding context as Extended EIDs (IID+EID). The LISP mapping system consolidates the registrations from all the ETRs in the VPN and builds a mapping database for the VPN. ITRs that are members of the VPN will do forwarding lookups in the forwarding context where traffic was received. Upon a cache miss within the forwarding context, the ITR will issue a Map-Request for the destination EID and include the VPN's BD. This information will be encoded as an Extended EID (IID+EID) in the Map-Request issued. The BD to associate with the EID in this Map-request is derived from the configuration of the VPN's forwarding context (in which the traffic was received). The Mapping System should reply to the Map Request with a Mapping for the Extended EID (IID+EID), the IID of the Extended EID should be used to identify the forwarding context in which the Mapping received should be cached. Once a mapping has been cached in the VPN's forwarding context, the ITR may encapsulate the traffic towards the RLOC in the mapping. The IID corresponding to the VPN's forwarding context must be included in the IID field of the data plane header. When the encapsulated traffic is received at the ETR, the encapsulation header is removed and the IID received in the header is used to identify the forwarding context to use to do a forwarding lookup for the decapsulated traffic. Protocols associated with these technologies are described in various published documents, including The Locator/ID Separation Protocol (LISP), Internet Engineering Task Force (IETF), Request for Comments (RFC): 6830; D. Farinacci et al., January 2013.
Extranet VPN support may be provided using LISP. Typically, an extranet allows for communication across multiple VPNs, subject to policy constraints, in which each “subscriber” VPN may communicate with a “provider” VPN to access a shared service but be restricted from communicating with each other via the provider VPN. LISP specifically allows for distributed extranet VPN support. Here, as the extranets are not centralized but rather distributed to ITRs, there is no centralized point of failure. For extranet routes, an ITR may operate to encapsulate user plane traffic associated with the IID corresponding to the VPN connected to the ETR. Extranet routes may be installed at the ITR with the IID corresponding to the destination VPN.
To provide better context of the general environment within which the present techniques and mechanisms of the present disclosure may be practiced, description associated with the network infrastructure arrangements, functional block diagrams, and message flow diagrams of
A plurality of hosts 106 may be connected in the one or more networks of network overlay fabric 102. The plurality of hosts 106 illustrated in
One or more mapping servers or systems (e.g. mapping system 108) may be connected in the one or more networks of network overlay fabric 102. Mapping system 108 may be more generally referred to as a communications management server or entity. Hosts 106 may register with mapping system 108 to provide their (route/router) locations in the network, for example, in the form of host-to-router mappings. Mapping system 108 may be or include, for example, a MS/MR.
Registrations of hosts 106 in mapping system 108 are indicated in
In
Referring ahead now to
In
Similar processing may be performed for communications initiated by a host (e.g. host 140) in the VPN S. More particularly, host 140 in VPN S may send to tunnel router 114 a message comprising a data packet intended for host 120 of VPN A (step 216 of
After the configuration of step 202 of
Mapping system 108 may test or identify whether the selected communication policy allows for cross-VRF communication for the security group associated with the SGT (step 256 of
Referring back now to
Referring now to
As described earlier above in the Background section, service insertion poses challenges in enterprise private networks when multiple services need to be applied in relation to a particular traffic flow. Services may include firewall or security services, billing or accounting services, service level agreement (SLA) monitoring services, Quality of Service (QoS) policy services, and the like. These challenges become more prevalent in relation to enterprise SDA or SDN fabrics, which are overlay-based and utilize group-based policy and segmentation. Service insertion in enterprise SDA/SDN fabrics is problematic due to the use of traditional service routers that would need to apply the services. Specifically, traditional service routers do not readily support the appropriate encapsulation and tagging (e.g. security group tags or “SGTs”) associated with overlay headers of data packets for appropriate processing. Traditionally, access control list (ACL)/policies (e.g. for policy-based routing) are used on an edge or border router to redirect traffic to service routers. However, this approach does not scale well as the number of flows, groups, and/or subnets become larger, especially in relation to security services where the traffic needs to be routed to a particular service router (e.g. a firewall). In addition, ACLs consume a great deal of hardware or forwarding resources which may already be scarce, for example, on relatively low-end switches or routers. In a solution, fabric routers that connect to services should be able to differentiate between pre-service and post-service traffic, so that traffic does not get routed back to apply same service again (e.g. looping) after post-service processing. As some services may fail, dynamic service updating is also a feature to consider, and such updating should be transparent to users as the system moves traffic from old to new service instances. Load-balancing to service instances (e.g. hash-based load balancing) should also be achievable in such a solution.
What are described herein are techniques and mechanisms for dynamic group-based service insertion for enterprise private networks for traffic flows using the LISP control plane (e.g. the MS/MR). The techniques and mechanisms of the present disclosure may be built upon or based on traditional techniques and mechanisms described in relation to LISP, for example, in relation to
In the method of
Beginning at a start block 402 of
On the other hand, when no service insertion policy exists, the MS/MR may select, from a mapping database, the second RLOC of the second tunnel router based on the second EID (step 408 of
As mentioned above, prior to receiving the initial traffic of the communications from the first host, the computing device may receive, from the service border router, a message which indicates a service registration for registering the service with the MS/MR. In some implementations, service registration is performed by each one of a plurality of services available via the service border router(s). Here, the selecting of the service insertion policy may involve selecting the service insertion policy from a plurality of service insertion policies respectively associated with the plurality of services registered with the MS/MR. In some implementations, the selecting of the service insertion policy from the plurality of service insertion policies may be performed according to a service ID associated with the service insertion policy or service.
In some implementations of step 406, 410, and 412, the group identifier may be an SGT, and the service insertion policy may be selected based on at least the SGT and a DGT associated with the second host. Here, in step 410, the computing device may send, to the first tunnel router, the message which indicates the map reply and includes the address of the service border router, to further include the SGT, the DGT, and a group policy for application at the first tunnel router. In one example, the group policy comprises a group policy for access or access control.
In some implementations of steps 406, 410, and 412, the service insertion policy further includes an instance ID associated with a VRF at the service border router. Here, the message which indicates the map reply may include the address of the service border router, a virtual network identifier of a virtual private network associated with the VRF, and the group identifier, for populating the overlay route in the first tunnel router to forward the communications, with encapsulation of the virtual network identifier and the group identifier, via the service border router for insertion of the service. Here, the service border router may perform decapsulation and then forward the communications to a service node/router (e.g. a firewall or firewall service) via the VRF using L3 communications (e.g. tunnel encapsulation); the communications may return to the service border router in a similar manner after processing.
In other implementations of steps 406, 410, and 412, the service insertion policy further includes a VLAN ID of a VLAN. Here, the message which indicates the map reply may include the address of the service border router, the VLAN ID, and the group identifier, for populating the overlay route in the first tunnel router to forward the communications, with encapsulation of the VLAN ID and the group identifier, via the service border router for insertion of the service. Here, the service border router may perform decapsulation and then forward the communications to the service node/router (e.g. the firewall or firewall service) via the VLAN using L2 communications (e.g. tunnel encapsulation); the communications may return to the service border router in a similar manner after processing.
The method of
As is apparent, in some implementations, the MS/MR may be operative to select either the service insertion policy (see e.g. step 406 of
Again, as described above in relation to
In some implementations, when the second host is a 5G endpoint which is located for communication via the second tunnel router that is external to the enterprise private network, the MS/MR may receive, from the service border router, a message which indicates a map request for requesting an EID-to-RLOC mapping associated with the second EID. The MS/MR may then send, to the service border router, a message which indicates a second map reply and includes a third RLOC of a border router. The message which indicates the second map reply and includes the third RLOC of the border router is for populating an overlay route in the border router to the second host via the second tunnel router that is external to the enterprise private network.
Two detailed scenarios for service insertion using the MS/MR of the LISP control plane (or “service control plane”) will now be described, Scenario (A) and Scenario (B). Although a firewall service is used as an example in the scenarios, any suitable service at a service node or a service router may be employed. The service may be one of firewall or security service, a billing or an accounting service, an SLA monitoring service, or a QoS policy service, as a few examples. In the discussion, the service border router may be referred to simply as a service border (SB).
In Scenario (A), service insertion using LISP MS/MR may be characterized as “within” virtual network (VN)/VRF service insertion. For the same VN/VRF service insertion, the approach is to use LISP service registration from a service border with service insertion policies (e.g. based on groups, application ID, port number etc.). Since the service control plane is requested to provide a mapping of the destination with the destination switch (i.e. the RLOC), policy for a source-destination pair may be easily, selectively applied at the forwarding switch. This may be done without the need to download all policies (*, *) on the forwarding switches, thereby saving forwarding resources.
In some implementations, each VN/VRF may perform a different service registration (with different RLOCs and service policy) at the service border connected to the service, for any and all services to be applied. After traffic is communicated to the service border for the service, the service border may return the traffic to another VN/VRF where the destination host would be reachable. Here, no service would be applied again. Rather, the traffic may be sent to the final destination which is within the enterprise private network or outside to the Internet/5G network. The same mechanism may be used for return traffic from the Internet/5G network to enterprise hosts when the destination path is requested from the service control plane (e.g. LISP MS/MR, using Map-Request or LISP PUB-SUB).
In some implementations, the high-level flow may be as follows:
1. The service border may perform a service registration to the MS/MR with all policy/parameters required for service insertion in its own VRF.
2. The MS/MR may store the information, for example, in a separate policy database (e.g. outside of the standard registration/mapping database).
3. When the edge boots up, it may query the MS/MR for edge policies (e.g. per security group, subnet, or VN/VRF) and the default-service-etr. The MS/MR may reply with the registered service border, or a configured first-packet-service-border within the same VRF.
4. The Map-Request may be differentiated, and inserted with a service indication (and service-id, source security group identifier, etc.) based on whether it is an original, pre-service Map-Request or a post-service Map-Request. This may be determined based on whether the Map-Request originator node is the edge or the service border that performed the service registration (and has the local path to the service router).
5. Based on the indication (and the service-id, SGT) in the Map-Request, the MS/MR may reply with the appropriate RLOC (i.e. of the service border or the final destination) and any destination parameters needed (e.g. the destination security group, destination VN/VRF) after applying the destination policies (e.g. the SGACL based on the SGT, DGT).
6. If the destination policy does not allow the communication (e.g. the SGT, DGT pair is denied), the MS/MR does not reply with a positive Map-Reply (or it may send a Negative Map Reply or “NMR”), which may possibly facilitate the dropping of the packet at the source node itself instead of the destination node.
In Scenario (B), service insertion using LISP MS/MR may be characterized as “across” VRF service insertion. For across VRF service insertion, the above-described approach is extended to use the LISP extranet with subscriber-to-subscriber communication and service insertion policies (e.g. for groups, application ID, port number, etc.). After the traffic traverses the service border (e.g. the firewall), the service may return the traffic to another subscriber VN/VRF, where the destination host would be reachable and no service would be applied again, sending traffic flow to the final destination within the enterprise private network or outside to the Internet/5G network.
In some implementations, the high-level flow may be as follows:
1. The service border may perform a service registration with the MS/MR with all policy/parameters for the service insertion in its own VRF.
2. The MS/MR may be provisioned with across VN/VRF/VLAN policies which include service insertion policies.
3. When the edge boots up, it may query the MS/MR for the edge policies (e.g. per security group, subnet, or VN/VRF) and the default-service-etr. The MS/MR may reply with the registered service border or a configured first-packet-service-border within the same VRF.
4. The MS/MR may store the information, for example, in a separate policy database (e.g. outside the standard registration/mapping database).
5. The Map-Request may be differentiated, and inserted with the service indication (and the service-id, source security group, etc.) based on whether it is the original pre-service Map-Request or a post-service Map-Request. This may be determined based on whether the Map-Request originator node is the edge or the service border that performed the service registration (and has the local path to the service router).
6. Based on the Map-Request indication, the MS/MR may check whether the destination is reachable within the same VRF (e.g. Scenario A) or across VRF. For across VRF destinations, it may additionally check the extranet and extranet service insertion policy. It may proceed further (e.g. only) if the extranet policy allows for it.
7. Based on the indication (and the service-id, SGT) in the Map-Request, the MS/MR may reply with appropriate RLOC (i.e. the service border or the final destination) and any destination parameters needed (e.g. destination security group, destination VN/VRF) after applying the destination policies (e.g. the SGACL based on SGT, DGT).
8. If the destination policy does not allow the communication (e.g. the SGT, DGT pair is denied), the MS/MR does not reply with a positive Map-Reply (or it may send an NMR), which may possibly facilitate the dropping of the packet at the source node itself instead of the destination node.
Advantageously, the techniques and mechanisms of the present disclosure may be employed both for fabric-deployments as well as non-fabric (traditional) deployments.
Below is an example configuration for service insertion using the service control plane, for allowing dynamic SGT-based service insertion for both SDA and non-SDA deployments.
As now described in relation to
The LISP control plane may include an MS/MR 550 which serves as a service control plane for dynamic service insertion. A high-level flow for the dynamic service insertion using L3 forwarding is now described. Initially, SB 520 may perform registration from an L3 instance (i.e. VRF) with its IP address and policy (e.g. SGT-DGT, etc.).
1. When tunnel router 510 boots up, MS/MR 550 may invoke tunnel router 510 (EN1) to install a default service insertion policy, specifying that traffic for 0/0 (or a specific subnet/group) is to be sent to a specific/default SB to apply a service (e.g. a firewall service). This may be considered a first packet punt and forward policy. One of at least two options may be utilized:
(a) Redirect unresolved traffic at tunnel endpoint 504 (EN1) to an appropriate SB; or
(b) Redirect unresolved traffic to a first packet forwarder (e.g. pre-populated via PUB-SUB).
2. In general, traffic is intended to be communicated from host 510 (H1) at IP1 to host 514 (H3) at IP3.
3. Tunnel router 504 (EN1) may send a Map-Request to resolve for H3 (in SGT 100 context) with MS/MR 550, which will return the SB 520 (e.g. SB, VRF) and also return the DGT 200 corresponding to H3 per the service insertion policy. Two options may be utilized here:
(a) The policy may be applied at tunnel endpoint 504 (EN1). Here, the forwarding plane may trigger a Map-Request for the destination in the VRF context, carrying the SGT, but the policy may be applied at the edge. MS/MR 550 may reply based on the destination and VRF, but with the DGT and the policy for the SGT-DGT. The forwarding plane on the edge may install the policy for the SGT-DGT, in addition to the forwarding entry (e.g. in the map-cache). In this case, the forwarding plane may operate to regenerate the Map-Request on a “miss” when the corresponding SGT-DGT policy is not available at the forwarding plane.
(b) The policy may be applied at MS/MR 550. Here, the forwarding plane on the edge may trigger resolution (i.e. a Map-Request) in the SGT 100 context for the destination H3. The service control plane may reply after applying the policy with the appropriate node (e.g. SB 520, or DB 524 or destination edge node). Here, the forwarding plane may (simply) install the forwarding entry at the edge (i.e. no SGT, DGT policy at the edge). This option assumes that the forwarding plane is configured to generate a Map-Request in the SGT 100 context for the destination.
While generating the Map-Request, the edge may also forward the packet to the default SB. The policy may provide the firewall IP or the SB IP (e.g. based on which entity performed the service insertion registration). A separate SB would not be required in the case where the firewall can directly terminate the VxLAN. The Map-Reply may also indicate “native-forward.”
4. The tagged packet may be sent to SB 520 with the VxLAN Network Identifier (VNI) and SGT encapsulation.
5. The SB 520 may decapsulate the traffic and send the traffic to SN 522 (i.e. the firewall) using L3/VRF. The SB IP as Tunnel Endpoint (TEP) in packet encapsulation may be used to identify the traffic that needs to be sent to the firewall. This may be useful in scenarios where SB 520 also serves as a gateway to north-south traffic.
6. SN 522 (i.e. the firewall) may process the traffic and send it back to SB 520 using L3.
7. Since the packet encapsulation TEP is not the IP/RLOC of SB 520 in the service overlay (e.g. or check F bit=0?), SB 520 may perform a map cache query (e.g. or use LISP PUB-SUB) for H3's IP address which will return tunnel endpoint 506 (EN2). MS/MR 550 may determine based on the source of the Map-Request which node to resolve for (e.g. SB 520 or tunnel endpoint 506 (EN2); the request from the SB/VRF will not resolve to same SB/VRF).
8. SB 520 may send the encapsulated packet to tunnel endpoint 506 (EN2).
9. Internet traffic (e.g. associated with NMR) may be sent to DB 524 or SB 520 through VxLAN encapsulation, as mapping resolution for Internet prefixes may point to the DB or SB IP.
10. Return the Internet traffic at DB 524 that has overlay subnets provisioned to generate a Map-Request (or have the mapping pre-installed via LISP PUB-SUB). MS/MR 550 may reply with the mapping resolved to SB 520 or the tunnel endpoint in order to send the return traffic to the service or directly to the destination edge node (e.g. encapsulate with the SB or tunnel endpoint).
Initially, SB 520 may register with MS/MR 550 with its IP address and group-based service insertion policy within the VLAN or L2 instance-id (e.g. extending the service insertion registration/border convergence mechanism for the L2 instance). An L2 Map-Reply may return the address of SB 520 instead of the normal RLOC. An L2 negative-Map-Reply or NMR may be returned or indicate “forward-native” instead of “drop.” With respect to SB 520 (e.g. if the Map-Request source is the same as the SB), MS/MR 550 may return the normal RLOC. In some implementations, flooding over the tunnel is controlled from the service control plane; local VLAN flooding control may be handled outside of the service control plane. The service control plane may provision the group-based service insertion policy across the VLANs (e.g. extending the extranet service insertion mechanism across L2 instances).
A high-level flow for the dynamic service insertion using L2 forwarding is now described in relation to
1. When tunnel endpoint 504 (EN1) boots up, MS/MR 550 may install a default service insertion policy, such that traffic for any MAC address destination to be sent to a specific SB (or default SB) to apply a firewall service. This is a first packet punt and forward policy for L2. One of at least two options may be utilized:
(a) Unresolved traffic at tunnel endpoint 504 (EN1) may be redirected to an appropriate SB.
(b) Unresolved traffic may be redirected to a first packet forwarder (e.g. a default-service border) which has all static or already-known steering policies (e.g. pre-populated via LISP PUB-SUB).
2. In general, traffic is intended to be communicated from host 510 (H1) at MAC1 to host 514 (H3) at MAC3.
3. Tunnel endpoint 504 may send a Map-Request to resolve for host 514 (H3) (in SGT 100 context) with MS/MR 550, which will return both SB 520 (e.g. SB, VLAN) and also return the DGT 200 corresponding to host 514 (H3) as per the service insertion policy. Two options may be utilized here:
(a) Policy may be applied at tunnel endpoint 504 (EN1). The forwarding plane may trigger a Map-Request for the destination MAC in the VLAN context, carrying the SGT, but the policy may applied at tunnel endpoint 504 (EN1). MS/MR 550 may reply based on the destination and the VLAN, but with the DGT and the policy for the SGT-DGT. The forwarding plane at tunnel endpoint 504 (EN1) may install the policy for the SGT-DGT in addition to the forwarding entry (e.g. in the map-cache). Note that, in this case, the forwarding plane may regenerate the Map-Request on a “miss” when the corresponding SGT-DGT policy is not available at the forwarding plane.
(b) Policy may be applied at MS/MR 550. The forwarding plane at tunnel endpoint 504 (EN1) may trigger a resolution (e.g. a Map-Request) in the SGT 100 context for the destination MAC H3. MS/MR 550 may reply after applying the policy with the appropriate node (SB 520, DB 524, or the destination edge node). The forwarding plane may just install the forwarding entry at the edge (i.e. no SGT-DGT policy at the edge). This option assumes that the forwarding plane is able to generate a Map-Request in the SGT 100 context for the destination MAC.
While generating the Map-Request, tunnel endpoint 504 (EN1) may also forward the packet to DB 524. The policy may provide the firewall IP or the SB IP (e.g. based on which entity performs the service insertion registration in the VLAN). A separate SB would not be necessary in the case the firewall can directly terminate the VxLAN.
4. The tagged packet may be sent to SB 520 with the VNI and SGT encapsulation.
5. SB 520 may decapsulate the traffic and send the traffic to SN 522 (e.g the firewall) using the VLAN. The SB IP as TEP in packet encapsulation may be used to identify the traffic that needs to be sent to the firewall. This may be useful in scenarios where SB 520 also serves as a gateway to north-south traffic.
6. SN 522 may process the traffic and send it back to SB 520 using the VLAN.
7. Since packet encapsulation TEP is not the IP/RLOC of SB 520 in the service overlay (e.g. or check F bit=0?), SB 520 may perform a map cache query (e.g. or use LISP PUB-SUB) for H3 MAC which will return tunnel endpoint 506 (EN2). MS/MR 550 may determine, based on the source of the Map-Request, which node to resolve (i.e. SB 520 or tunnel endpoint 506 (EN2); the request from the SB/VRF will not resolve to same SB/VLAN/VNI).
8. SB 520 may send the encapsulated packet to tunnel endpoint 506 (EN2).
To better illustrate message formatting that may be utilized, with reference to
Advantageously, techniques and mechanisms of the present disclosure may be suitable for use in facilitating virtual enterprise networking with remote access and 5G traffic flows. With the promise of 5G connectivity to provide high-speed direct communication via a shared 5G backbone network, specific services may be inserted in relation to 5G traffic flows that enter into or exit from the network. Advantageously, leveraging LISP and the MS/MR for service insertion as described may be applied for use with remote 5G endpoints or hosts, where a border router which interfaces to the external network or Internet may trigger, based on configured prefixes, the Map-Request/Map-Reply in the same or similar manner for service insertion.
With reference to
Advantageously, service insertion in enterprise SDA/SDN fabrics is simplified and no longer problematic using traditional service routers. The services that may be employed include firewall or security services, billing or accounting services, SLA monitoring services, QoS policy services, and the like. The techniques and mechanisms of the present disclosure are scalable as the number of flows, groups, and/or subnets become larger, and do not require additional consumption of hardware resources. Further, fabric routers that connect to the services are able to differentiate between pre-service and post-service traffic, so that traffic does not get routed back to apply the same service again (e.g. looping) after post-service processing. As some services may fail, dynamic service updating is also feasible, and such updating may be made transparent to users as the system moves traffic from old to new service instances. Even further, the proposed techniques and mechanisms that allow for dynamic service insertion may make the network truly location-independent. At least in some implementations, solving the problem for enterprise SDA/SDN networks according to the present disclosure inherently provide a solution for remote hosts with 5G traffic flows.
In at least one embodiment, computing device 800 may include one or more processor(s) 802, one or more memory element(s) 804, storage 806, a bus 808, one or more network processor unit(s) 810 interconnected with one or more network input/output (I/O) interface(s) 812, one or more I/O interface(s) 814, and control logic 820. In various embodiments, instructions associated with logic for computing device 800 can overlap in any manner and are not limited to the specific allocation of instructions and/or operations described herein.
In at least one embodiment, processor(s) 802 is/are at least one hardware processor configured to execute various tasks, operations and/or functions for computing device 800 as described herein according to software and/or instructions configured for computing device 800. Processor(s) 802 (e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, processor(s) 802 can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. Any of potential processing elements, microprocessors, digital signal processor, baseband signal processor, modem, PHY, controllers, systems, managers, logic, and/or machines described herein can be construed as being encompassed within the broad term ‘processor’.
In at least one embodiment, memory element(s) 804 and/or storage 806 is/are configured to store data, information, software, and/or instructions associated with computing device 800, and/or logic configured for memory element(s) 804 and/or storage 806. For example, any logic described herein (e.g., control logic 820) can, in various embodiments, be stored for computing device 800 using any combination of memory element(s) 804 and/or storage 806. Note that in some embodiments, storage 806 can be consolidated with memory element(s) 804 (or vice versa), or can overlap/exist in any other suitable manner.
In at least one embodiment, bus 808 can be configured as an interface that enables one or more elements of computing device 800 to communicate in order to exchange information and/or data. Bus 808 can be implemented with any architecture designed for passing control, data and/or information between processors, memory elements/storage, peripheral devices, and/or any other hardware and/or software components that may be configured for computing device 800. In at least one embodiment, bus 808 may be implemented as a fast kernel-hosted interconnect, potentially using shared memory between processes (e.g., logic), which can enable efficient communication paths between the processes.
In various embodiments, network processor unit(s) 810 may enable communication between computing device 800 and other systems, entities, etc., via network I/O interface(s) 812 to facilitate operations discussed for various embodiments described herein. In various embodiments, network processor unit(s) 810 can be configured as a combination of hardware and/or software, such as one or more Ethernet driver(s) and/or controller(s) or interface cards, Fibre Channel (e.g., optical) driver(s) and/or controller(s), and/or other similar network interface driver(s) and/or controller(s) now known or hereafter developed to enable communications between computing device 800 and other systems, entities, etc. to facilitate operations for various embodiments described herein. In various embodiments, network I/O interface(s) 812 can be configured as one or more Ethernet port(s), Fibre Channel ports, and/or any other I/O port(s) now known or hereafter developed. Thus, the network processor unit(s) 810 and/or network I/O interface(s) 812 may include suitable interfaces for receiving, transmitting, and/or otherwise communicating data and/or information in a network environment.
I/O interface(s) 814 allow for input and output of data and/or information with other entities that may be connected to computer device 800. For example, I/O interface(s) 814 may provide a connection to external devices such as a keyboard, keypad, a touch screen, and/or any other suitable input and/or output device now known or hereafter developed. In some instances, external devices can also include portable computer readable (non-transitory) storage media such as database systems, thumb drives, portable optical or magnetic disks, and memory cards. In still some instances, external devices can be a mechanism to display data to a user, such as, for example, a computer monitor, a display screen, or the like.
In various embodiments, control logic 820 can include instructions that, when executed, cause processor(s) 802 to perform operations, which can include, but not be limited to, providing overall control operations of computing device; interacting with other entities, systems, etc. described herein; maintaining and/or interacting with stored data, information, parameters, etc. (e.g., memory element(s), storage, data structures, databases, tables, etc.); combinations thereof; and/or the like to facilitate various operations for embodiments described herein.
The programs described herein (e.g., control logic 820) may be identified based upon application(s) for which they are implemented in a specific embodiment. However, it should be appreciated that any particular program nomenclature herein is used merely for convenience; thus, embodiments herein should not be limited to use(s) solely described in any specific application(s) identified and/or implied by such nomenclature.
In various embodiments, entities as described herein may store data/information in any suitable volatile and/or non-volatile memory item (e.g., magnetic hard disk drive, solid state hard drive, semiconductor storage device, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM), application specific integrated circuit (ASIC), etc.), software, logic (fixed logic, hardware logic, programmable logic, analog logic, digital logic), hardware, and/or in any other suitable component, device, element, and/or object as may be appropriate. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory element’. Data/information being tracked and/or sent to one or more entities as discussed herein could be provided in any database, table, register, list, cache, storage, and/or storage structure: all of which can be referenced at any suitable timeframe. Any such storage options may also be included within the broad term ‘memory element’ as used herein.
Note that in certain example implementations, operations as set forth herein may be implemented by logic encoded in one or more tangible media that is capable of storing instructions and/or digital information and may be inclusive of non-transitory tangible media and/or non-transitory computer readable storage media (e.g., embedded logic provided in: an ASIC, digital signal processing (DSP) instructions, software [potentially inclusive of object code and source code], etc.) for execution by one or more processor(s), and/or other similar machine, etc. Generally, memory element(s) 804 and/or storage 806 can store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, and/or the like used for operations described herein. This includes memory element(s) 804 and/or storage 806 being able to store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, or the like that are executed to carry out operations in accordance with teachings of the present disclosure.
In some instances, software of the present embodiments may be available via a non-transitory computer useable medium (e.g., magnetic or optical mediums, magneto-optic mediums, CD-ROM, DVD, memory devices, etc.) of a stationary or portable program product apparatus, downloadable file(s), file wrapper(s), object(s), package(s), container(s), and/or the like. In some instances, non-transitory computer readable storage media may also be removable. For example, a removable hard drive may be used for memory/storage in some implementations. Other examples may include optical and magnetic disks, thumb drives, and smart cards that can be inserted and/or otherwise connected to a computing device for transfer onto another computer readable storage medium.
Thus, techniques and mechanisms for “dynamic” group-based service insertion for enterprise private networks for traffic flows using the LISP control plane or the MS/MR have been described. Such techniques and mechanisms may be suitable for use in facilitating virtual enterprise networking with remote access with 5G traffic flows. The dynamic group-based service insertion (e.g. SGT-based service insertion) may be utilized in both SDA and non-SDA deployments. Note that the techniques and mechanisms of the present disclosure may be applied using other suitable overly technologies, such as BGP-EVPN.
In one illustrative example, a method of the present disclosure may be performed by one or more computing devices (a “computing device”) which implement a MS/MR of a LISP control plane for group-based service insertion in an enterprise private network. The computing device may be configured to facilitate communications from a first host that is located for communication via a first tunnel router to a second host that is located for communication via a second tunnel router. The first and the second hosts are assigned with first and second EIDs, respectively, and the first and the second tunnel routers are assigned with first and second RLOCs, respectively.
In the method, the computing device may receive, from the first tunnel router, a message which indicates a map request for requesting an EID-to-RLOC mapping associated with the second EID, which is triggered in response to the first tunnel router receiving initial traffic of the communications from the first host. When a service insertion policy exists, the computing device may select, from a policy database, a service insertion policy based on at least the second EID or a group identifier in the message. The service insertion policy may include an address of a service border router for a service that is registered with the MS/MR. The computing device may send, to the first tunnel router, a message which indicates a map reply and includes the address of the service border router, for populating an overlay route in the first tunnel router to forward the communications via the service border router for insertion of the service. The service may be one of firewall or security service, a billing or an accounting service, an SLA monitoring service, or a QoS policy service, as a few examples.
On the other hand, when no service insertion policy exists, the computing device may select, from a mapping database, the second RLOC of the second tunnel router based on the second EID. The computing device may send, to the first tunnel router, the message which indicates the map reply and includes the second RLOC of the second tunnel router, for populating the route in the first tunnel router to forward the communications to the second tunnel router to the second host.
Prior to receiving the initial traffic of the communications from the first host, the computing device may receive, from the service border router, a message which indicates a service registration for registering the service with the MS/MR. In some implementations, service registration is performed by each one of a plurality of services available via the service border router. Here, the selecting of the service insertion policy may comprise selecting the service insertion policy from a plurality of service insertion policies respectively associated with the plurality of services registered with the MS/MR. In some implementations, the selecting of the service insertion policy from the plurality of service insertion policies may be performed according to a service ID associated with the service insertion policy or service.
In some implementations, the group identifier comprises an SGT, and the service insertion policy may be selected based on at least the SGT and a DGT associated with the second host. Here, the computing device may send, to the first tunnel router, the message which indicates the map reply and includes the address of the service border router, to further include the SGT, the DGT, and a group policy for application at the first tunnel router.
In some implementations, the service insertion policy further includes an instance ID associated with a VRF at the service border router. Here, the message which indicates the map reply may include the address of the service border router, a virtual network identifier of a virtual private network associated with the VRF, and the group identifier, for populating the overlay route in the first tunnel router to forward the communications, with encapsulation of the virtual network identifier and the group identifier, via the service border router for insertion of the service. In other implementations, the service insertion policy further includes a VLAN ID of a VLAN. Here, the message which indicates the map reply may include the address of the service border router, the VLAN ID, and the group identifier, for populating the overlay route in the first tunnel router to forward the communications, with encapsulation of the VLAN ID and the group identifier, via the service border router for insertion of the service.
Subsequently (i.e. after processing associated with the service), the computing device may receive, from the service border router, a message which indicates another map request for requesting an EID-to-RLOC mapping associated with the second EID. The computing device may select, from the mapping database, the second RLOC of the second tunnel router based on the second EID. The computing device may send, to the service border router, a message which indicates another map reply and includes the second RLOC of the second tunnel router, for populating an overlay route in the service border router to forward the communications via the second tunnel router to the second host.
Accordingly, in some implementations, the computing device may select either the service insertion policy or the second RLOC of the second tunnel router, based on identifying an indication (e.g. a message indication) of whether the message which indicates the map request or the other map request is sent from the first tunnel router or the service border router.
When the second host is a 5G endpoint which is located for communication via the second tunnel router that is external to the enterprise private network, the computing device may receive, from the service border router, a message which indicates another map request for requesting an EID-to-RLOC mapping associated with the second EID. The computing device may send, to the service border router, a message which indicates a second map reply and include a third RLOC of a border router, for populating an overlay route in the border router to the second host via the second tunnel router that is external to the enterprise private network.
Advantageously, when a service (or its associated path) becomes unavailable or is taken off-line, the service border router may send a message for service deregistration of the service. When the service (or its associated path) becomes available again or is brought back on-line, the service border router may again send a message for service registration for registration of the service. When a new or updated service becomes available, the service border router may send a message for service registration for registration of the new or updated service. As is apparent, the MS/MR may be updated dynamically for indicating the availability or non-availability of services. A plurality of service routers/service instances associated with a (e.g. single) service may register/deregister for load balancing and/or redundancy for the service.
In some implementations, the computing device of the present disclosure may include one or more processors, one or more interfaces to connect in an enterprise private network comprising an SDA or SDN fabric, and one or more memory elements for storing instructions executable on the one or more processors for operation as a MS/MR of a LISP control plane as described. In some other implementations, a computer program product may include a non-transitory computer readable medium and instructions stored on the non-transitory computer readable medium, where the instructions are executable by one or more processors of the computing device for operation as the MS/MR of the LISP control plane as described.
Embodiments described herein may include one or more networks, which can represent a series of points and/or network elements of interconnected communication paths for receiving and/or transmitting messages (e.g., packets of information) that propagate through the one or more networks. These network elements offer communicative interfaces that facilitate communications between the network elements. A network can include any number of hardware and/or software elements coupled to (and in communication with) each other through a communication medium. Such networks can include, but are not limited to, any local area network (LAN), VLAN, wide area network (WAN) (e.g., the Internet), software defined WAN (SD-WAN), wireless local area (WLA) access network, wireless wide area (WWA) access network, metropolitan area network (MAN), Intranet, Extranet, virtual private network (VPN), Low Power Network (LPN), Low Power Wide Area Network (LPWAN), Machine to Machine (M2M) network, Internet of Things (IoT) network, Ethernet network/switching system, any other appropriate architecture and/or system that facilitates communications in a network environment, and/or any suitable combination thereof.
Networks through which communications propagate can use any suitable technologies for communications including wireless communications (e.g., 4G/5G/nG, IEEE 802.11 (e.g., Wi-Fi®/Wi-Fi6®), IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), Radio-Frequency Identification (RFID), Near Field Communication (NFC), Bluetooth™, mm.wave, Ultra-Wideband (UWB), etc.), and/or wired communications (e.g., T1 lines, T3 lines, digital subscriber lines (DSL), Ethernet, Fibre Channel, etc.). Generally, any suitable means of communications may be used such as electric, sound, light, infrared, and/or radio to facilitate communications through one or more networks in accordance with embodiments herein. Communications, interactions, operations, etc. as discussed for various embodiments described herein may be performed among entities that may directly or indirectly connected utilizing any algorithms, communication protocols, interfaces, etc. (proprietary and/or non-proprietary) that allow for the exchange of data and/or information.
In various example implementations, entities for various embodiments described herein can encompass network elements (which can include virtualized network elements, functions, etc.) such as, for example, network appliances, forwarders, routers, servers, switches, gateways, bridges, loadbalancers, firewalls, processors, modules, radio receivers/transmitters, or any other suitable device, component, element, or object operable to exchange information that facilitates or otherwise helps to facilitate various operations in a network environment as described for various embodiments herein. Note that with the examples provided herein, interaction may be described in terms of one, two, three, or four entities. However, this has been done for purposes of clarity, simplicity and example only. The examples provided should not limit the scope or inhibit the broad teachings of systems, networks, etc. described herein as potentially applied to a myriad of other architectures.
Communications in a network environment can be referred to herein as ‘messages’, ‘messaging’, ‘signaling’, ‘data’, ‘content’, ‘objects’, ‘requests’, ‘queries’, ‘responses’, ‘replies’, etc. which may be inclusive of packets. As referred to herein and in the claims, the term ‘packet’ may be used in a generic sense to include packets, frames, segments, datagrams, and/or any other generic units that may be used to transmit communications in a network environment. Generally, a packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof. In some embodiments, control or routing information, management information, or the like can be included in packet fields, such as within header(s) and/or trailer(s) of packets. Internet Protocol (IP) addresses discussed herein and in the claims can include any IP version 4 (IPv4) and/or IP version 6 (IPv6) addresses.
To the extent that embodiments presented herein relate to the storage of data, the embodiments may employ any number of any conventional or other databases, data stores or storage structures (e.g., files, databases, data structures, data or other repositories, etc.) to store information.
Note that in this Specification, references to various features (e.g., elements, structures, nodes, modules, components, engines, logic, steps, operations, functions, characteristics, etc.) included in ‘one embodiment’, ‘example embodiment’, ‘an embodiment’, ‘another embodiment’, ‘certain embodiments’, ‘some embodiments’, ‘various embodiments’, ‘other embodiments’, ‘alternative embodiment’, and the like are intended to mean that any such features are included in one or more embodiments of the present disclosure, but may or may not necessarily be combined in the same embodiments. Note also that a module, engine, client, controller, function, logic or the like as used herein in this Specification, can be inclusive of an executable file comprising instructions that can be understood and processed on a server, computer, processor, machine, compute node, combinations thereof, or the like and may further include library modules loaded during execution, object files, system files, hardware logic, software logic, or any other executable modules.
It is also noted that the operations and steps described with reference to the preceding figures illustrate only some of the possible scenarios that may be executed by one or more entities discussed herein. Some of these operations may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the presented concepts. In addition, the timing and sequence of these operations may be altered considerably and still achieve the results taught in this disclosure. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the embodiments in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the discussed concepts.
As used herein, unless expressly stated to the contrary, use of the phrase ‘at least one of’, ‘one or more of’, ‘and/or’, variations thereof, or the like are open-ended expressions that are both conjunctive and disjunctive in operation for any and all possible combination of the associated listed items. For example, each of the expressions ‘at least one of X, Y and Z’, ‘at least one of X, Y or Z’, ‘one or more of X, Y and Z’, ‘one or more of X, Y or Z’ and ‘X, Y and/or Z’ can mean any of the following: 1) X, but not Y and not Z; 2) Y, but not X and not Z; 3) Z, but not X and not Y; 4) X and Y, but not Z; 5) X and Z, but not Y; 6) Y and Z, but not X; or 7) X, Y, and Z.
Additionally, unless expressly stated to the contrary, the terms ‘first’, ‘second’, ‘third’, etc., are intended to distinguish the particular nouns they modify (e.g., element, condition, node, module, activity, operation, etc.). Unless expressly stated to the contrary, the use of these terms is not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified noun. For example, ‘first X’ and ‘second X’ are intended to designate two ‘X’ elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements. Further as referred to herein, ‘at least one of’ and ‘one or more of’ can be represented using the ‘(s)’ nomenclature (e.g., one or more element(s)).
One or more advantages described herein are not meant to suggest that any one of the embodiments described herein necessarily provides all of the described advantages or that all the embodiments of the present disclosure necessarily provide any one of the described advantages. Numerous other changes, substitutions, variations, alterations, and/or modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and/or modifications as falling within the scope of the appended claims.
