Patent Description:
The present disclosure relates generally to providing services with policy control.

A computer network or data network is a telecommunications network that allows computers to exchange data. In computer networks, networked computing devices exchange data with each other using a data link. The connections between nodes are established using either cable media or wireless media. The best-known computer network is the Internet.

Network computer devices that originate, route, and terminate the data are called network nodes. Nodes can include hosts such as personal computers, phones, servers as well as networking hardware. Two such devices can be said to be networked together when one device is able to exchange information with the other device, whether or not they have a direct connection to each other. Computer networks differ in the transmission medium used to carry their signals, the communications protocols to organize network traffic, the network's size, topology, and organizational intent.

<CIT> describes technologies for function as a service (FaaS) arbitration that include an edge gateway, multiple endpoint devices, and multiple service providers. <CIT> describes client address based forwarding of dynamic host configuration protocol response packets. <CIT> describes technologies for accelerated edge data access and physical data security that include an edge device that executes services associated with endpoint devices.

Features of one aspect may be applied to each aspect alone or in combination with other features.

Services with policy control may be provided. A computing device may receive registration information associated with a border device. The registration information may comprise information identifying a service provided by a server associated with the border device, information identifying the border device, and policies associated with the service. Then an address for the server may be determined. Next a request may be received comprising the information identifying the service provided by the server. In response to receiving the request comprising the information identifying the service provided by the server, the address for the server, the information identifying the border device, and the policies associated with the service may be provided.

Both the foregoing overview and the following example embodiments are examples and explanatory only, and should not be considered to restrict the disclosure's scope, as described and claimed. Furthermore, features and/or variations may be provided in addition to those described. For example, embodiments of the disclosure may be directed to various feature combinations and sub-combinations described in the example embodiments.

The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar elements. While embodiments of the disclosure may be described, modifications, adaptations, and other implementations are possible. For example, substitutions, additions, or modifications may be made to the elements illustrated in the drawings, and the methods described herein may be modified by substituting, reordering, or adding stages to the disclosed methods. Accordingly, the following detailed description does not limit the disclosure. Instead, the proper scope of the disclosure is defined by the appended claims.

A fabric network may comprise a network topology in which components pass data to each other through interconnecting network nodes (e.g., devices). Fabric networks may comprise an overlay and an underlay. The underlay deals with connectivity between fabric network devices and the overlay deals with user traffic transiting the fabric network. The fabric network overlay may comprise functional components such as Fabric Edge (FE) devices, fabric intermediate devices, Fabric Border (FB) devices, a Map Server (MS), and a fabric Control Plane (CP).

In the fabric network overlay, FE devices may comprise, for example, Locator/ID Separation Protocol (LISP) xTR (Ingress/Egress Tunnel Router)/PxTR (Proxy xTR) nodes and FB devices may comprise, for example, LISP PxTR (Proxy xTR) nodes. End points (e.g., client devices or hosts) may be attached to the FE devices. The end points may be in Endpoint Identification space where each endpoint may have an Endpoint Identifier (EID). Each device in the fabric network (e.g., FE devices and FB devices) may be configured with an address (e.g., a locator address). FE devices may register discovered EIDs (from the end points) with a fabric host-tracking database running on the MS associating the discovered EID to, for example, the configured locator address of the FE device that discovered it.

When a local FE device receives a packet from a local end point destined to a remote end point (i.e., on a remote FE device) whose location is not known (e.g., end points connected over the internet), the local FE device may send a map request message to the MS. The MS may have a border device registered as a provider of internet service. In that case, the MS may reply to a map request with a remote locator address that is an address of the internet service border. Once the local FE device receives the reply message back from the MS associating the unknown EID to the remote locator address, all subsequent traffic from the local end point may be encapsulated (e.g., LISP encapsulated) and forwarded to the remote locator address (i.e., remote xTR device). Once the encapsulated packet is received on the remote xTR device, the remote xTR device may decapsulate the packet and forward natively (e.g., to the remote endpoint).

FB devices may connect the fabric network to the native routing domain. FB devices may be configured, for example, as LISP PxTR nodes and may provide a default gateway service to the FE nodes. Communication may happen through the FB device configured, for example, as a LISP PxTR node. When an FE device receives a packet from a local end point destined to a host outside the fabric network in the native routing domain, the FE device may encapsulate and send the packet to the FB device. The FB device may provide, for example, the LISP PxTR functionality and advertise itself as a next-hop address for all the fabric managed EID prefixes to the native routing domain so that it can steer the traffic.

Fabric overlay may provide the following services. For example, fabric overlay may provide stretched Layer-<NUM> service using Layer-<NUM> overlay, which may provide the flexibility of extending a subnet to any part of the fabric network. For example, a subnet may be present across multiple FE devices with the same anycast gateway Internet Protocol (IP) address to allow for roaming by allowing endpoints to continue using the same gateway IP address. The provided services may also include Layer-<NUM> overlay service and built-in mobility.

When fabric networks (e.g., with access switches and routers) are deployed, it may not be known in advance where different cloud based applications (e.g., private, public, or hybrid) or other on-premises applications, services, or servers may be located and what subnet/IP address they may be assigned. Without this network pre-knowledge, the network may be configured and deployed without these application/services support first, and later when application, services, and servers are configured, different components of the network (e.g., edge switches, border devices, control plane servers, firewalls, etc.) may be modified to allow networking paths to and from these new applications, services, and servers. However, this may be a costly and time consuming operation because it may involve complex network reconfigurations and debugging that may need skilled network engineers and network outages. This may also cause reconfiguration and reevaluation of network security mechanisms in place, which may result in security lapses if not done correctly. This may be because the network may already be deployed and operational. All of these issues may create a problem during applications and services deployment. This may, be problematic in enterprises that may handle time critical operations where outages are not acceptable (e.g., hospitals, financial institutions handling high frequency trading or critical financial transactions, mission critical applications like space research, autonomous vehicles, Internet-of-Things (IoT) applications, etc.).

Embodiments of the disclosure may provide for deployment of enterprise fabric networks with the applications and services (e.g., cloud based or on-premises) where there may be no need to know the locations and IP/subnet addresses for applications, services, or server in advance. These services may be unicast, multicast, or broadcast. Moreover, with embodiments of the disclosure, the network may not need to change when these applications, services, or servers are later deployed. Instead, the network may dynamically detect the locations and subnets of the applications, services, and servers and forward the relevant traffic towards those. Any other traffic not intended to go towards these servers (i.e., even if the destination address is the server's address) may be dropped at the edge of the network per the configured policies in the fabric control plane. This not only addresses the aforementioned problems, but may also make enterprise fabric networks more secured.

For example, an enterprise "abc" may have a Dynamic Host Configuration Protocol (DHCP) server "dhcp. com" that may be location scoped: i) East-coast dhcp. com may resolve to <NUM>. <NUM>; West-coast dhcp. com may resolve to <NUM>. <NUM>; and asiapac dhcp. com may resolve to <NUM>. Embodiments of the disclosure may allow the fabric to provide "zero" touch location specific DHCP service for example. A border device (e.g., xTR/border) that is connected to the DHCP server may register as "dhcp. com" (or its resolved address) with a site Map Server (MS) with service type, for example, as "DHCP_SRV" and with its associated policies. The MS may resolve (e.g., with a Domain Name Server (DNS)) and populate its registration table (e.g., in a fabric host-tracking database) with the server's destination IP address (i.e., the DHCP server's IP address or Uniform Resource Locator (URL)) and Routing Locator (RLOC) mapping with associated service policy.

When an Edge Device (ED) receives a host's (i.e., client device's) DHCP packet, it may query the MS (e.g., with a map-request) for the "DHCP_SRV" (i.e., SERVICE_TYPE). The MS may respond with the destination IP address (i.e., DHCP server's IP address) and RLOC mapping with associated policy. The ED may receive the DHCP server's address, RLOC, and associated policy and may installs a map-cache for it on the ED. Accordingly, at the edge, there may be no need for the DHCP server's IP address in the relay and this process may become dynamic. The aforementioned example used DHCP as the service, but other services may be used consistent with embodiments of the disclosure.

Another option may be, in response to a map-request for the service, the MS may respond with a URL (e.g., "dhcp. com") and the border device's RLOC to the ED. Then the ED may resolve the service's server's destination IP address (i.e., DHCP, Authentication, Authorization and Accounting (AAA), and other shared services server's IP address) and install map-caches with this destination to RLOC mapping. For example, {Service-type:Service-IP,VN} e,g Services {DHCP::<NUM>. <NUM>,VN1; DHCP::<NUM>. <NUM>,VN2; AAA::<NUM>. Based on this, the map-cache may be populated and service may be provide with the corresponding IP address (e.g., AAA in the above may be provided with IP <NUM>. ) The same process may apply to other services. This may allow the ED to have a minimal configuration for example.

<FIG> shows a system <NUM> consistent with embodiments of the disclosure for providing services with policy control. As shown in <FIG>, system <NUM> may comprise a first network <NUM>, a plurality of client devices <NUM>, a second network <NUM>, a map server <NUM>, and a server providing a service <NUM>. First network <NUM> may comprise a plurality of network devices including, but not limited to, a router <NUM>, a first edge device <NUM>, a second edge device <NUM>, intermediate network devices (not shown), and a border device <NUM>. Plurality of client devices <NUM> may comprise a first client device <NUM> and a second client device <NUM>. Second network <NUM> may comprise a network outside of first network <NUM>, for example, a network to the cloud (e.g., the Internet). Map server <NUM> may have and maintain a fabric host-tracking database <NUM>. Server providing a service <NUM> may provide any service (e.g., cloud based) comprising, but not limited to, DHCP, DNS, Authentication, Authorization and Accounting (AAA), and other shared services.

The plurality of network devices in first network <NUM> may comprise, but are not limited to, switches and routers for example. First network <NUM> may comprise any number of network devices. Plurality of client devices <NUM> may comprise any number of client devices and is not limited to two. Each of plurality of client devices <NUM> may comprise any type device wishing to communicate over first network <NUM>. For example, each of plurality of client devices <NUM> may comprise, but are not limited to, a Wi-Fi access point, a cellular base station, a tablet device, an Internet-of-Things (IoT) device, a mobile device, a smart phone, a telephone, a remote control device, a set-top box, a digital video recorder, a cable modem, a personal computer, a notebook computer, a network computer, a mainframe, a router, or other similar microcomputer-based device.

First network <NUM> may comprise a fabric network. The fabric network may comprise an underlay and an overlay. The underlay may deal with connectivity between fabric elements (e.g., network devices) and the overlay may deal with user traffic entering the fabric. Traffic may enter the fabric network (i.e., first network <NUM>) through FE devices (e.g., first edge device <NUM> and second edge device <NUM>). The traffic may be routed through first network <NUM> via a plurality of intermediate network devices within the plurality of network devices. The FE devices may be responsible for encapsulating a packet with a fabric header that contains an egress FE device address. When a packet (e.g., frame) arrives at the egress FE device, a fabric header may be stripped off and the native packet may be forwarded according to an inner address. The fabric network may be capable of providing Layer-<NUM> and Layer-<NUM> services on top of the underlay. The fabric network may have endpoints (e.g., plurality of client devices <NUM>) connected to it.

The elements described above of system <NUM> (e.g., map server <NUM>, server providing a service <NUM>, router <NUM>, first edge device <NUM>, second edge device <NUM>, border device <NUM>, first client device <NUM>, or second client device <NUM>) may be practiced in hardware and/or in software (including firmware, resident software, micro-code, etc.) or in any other circuits or systems. The elements of system <NUM> may be practiced in electrical circuits comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. Furthermore, the elements of system <NUM> may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to, mechanical, optical, fluidic, and quantum technologies. As described in greater detail below with respect to <FIG>, the elements of system <NUM> may be practiced in a computing device <NUM>.

<FIG> is a flow chart setting forth the general stages involved in a method <NUM> consistent with an embodiment of the disclosure for providing services with policy control. Method <NUM> may be implemented using map server <NUM> as described in more detail above with respect to <FIG>. Method <NUM> may be described in conjunction with flow diagram <NUM> of <FIG>. Ways to implement the stages of method <NUM> will be described in greater detail below.

Method <NUM> may begin at starting block <NUM> and proceed to stage <NUM> where map server <NUM> may receive registration information associated with border device <NUM>. The registration information may comprise information identifying a service provided by a server (e.g., server providing the service <NUM>) associated with border device <NUM>, information identifying border device <NUM>, and policies associated with the service. For example, border device <NUM> (e.g., a site border/xTR) may be configured using URLs for the applications for which, servers would be located behind border device <NUM>. Border device <NUM> may register to the enterprise fabric control plane (i.e., map server <NUM>) with the applications by registering itself as the RLOC and EID as the "distinguished name" for that application or service. (Stage <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). Map server <NUM> may be configured with policies specific to these different applications. In other embodiments, these policies may be sent to map server <NUM> during registration by border device <NUM>. The information identifying the service provided by the server associated with the border device may comprise an Endpoint Identifier (EID), which may comprise, for example, an Internet Protocol (IP) address, a Media Access Control (MAC) address, the distinguished name identifying the service, or a Uniform Resource Locator (URL) identifying the service. The information identifying the border device may comprise a Routing Locator (RLOC) locator type such as a default locator or a specific service locator for example.

Map server <NUM> may keep trying with a DNS at frequent interval to resolve the URL for the application, which may fail because the application server may not be connected yet. In other embodiments, map server <NUM> may be re-registered to resolve IP addresses when those services are announced or advertised. An edge device (e.g. first edge device <NUM>) may recognize that an application packet in the forwarding plane and may request map server <NUM> (e.g., using the service name as "distinguished name EID" for that application) for the RLOC for that application server. Because map server <NUM> may not have the URL for the application resolved yet, it may reply with having drop action. Edge device (e.g., first edge device <NUM>) may drop the application packet.

From stage <NUM>, where map server <NUM> receives the registration information associated with border device <NUM>, method <NUM> may advance to stage <NUM> where map server <NUM> may determine an address for the server (e.g., server providing the service <NUM>). For example, the application server may be connected to border device <NUM> (e.g., a site border/xTR). The service may now be deployed and announced or advertised by respective devices. Map server <NUM> may now be able to resolve the URL for the application or registers the IP or Media Access Control (MAC) addresses for the service based on service announcements of its devices. Map server <NUM> may associate IP or MAC addresses with the "distinguished name" EID for the application or service. Map server <NUM> may keep this information in fabric host-tracking database <NUM> with the configured policies for these applications or services.

Once map server <NUM> determines the address for the server (e.g., server providing the service <NUM>) in stage <NUM>, method <NUM> may continue to stage <NUM> where map server <NUM> may receive a request comprising the information identifying the service provided by the server (e.g., server providing a service <NUM>). For example, first edge device <NUM> may recognizes that an application packet had been received from first client device <NUM> (stage <NUM> of <FIG>) and may request map server <NUM> for the RLOC for that application. (Stage <NUM> of <FIG>).

After map server <NUM> receives the request comprising the information identifying the service provided by the server (e.g., server providing the service <NUM>) in stage <NUM>, method <NUM> may proceed to stage <NUM> where map server <NUM> may provide, in response to receiving the request comprising the information identifying the service provided by the server (e.g., server providing the service <NUM>), the address for the server (e.g., server providing the service <NUM>), the information identifying border device <NUM>, and the policies associated with the service. (Stage <NUM> of <FIG>). For example, in response, map server <NUM> may not only send the RLOC for the application server (e.g., server providing the service <NUM>), but may also specify policies for that application. For some services, map server <NUM> may also send a list of device IP addresses as well as their corresponding RLOCs for the service devices. Border device <NUM> may install those policies in its forwarding hardware for the traffic towards the application server or service devices. Future traffic may then be forwarded according to the installed policies. (Stages <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). Once map server <NUM> provides the address for the server (e.g., server providing the service <NUM>), the information identifying border device <NUM>, and the policies associated with the service in stage <NUM>, method <NUM> may then end at stage <NUM>.

For multisite application provisioning or deployment, embodiments of the disclosure may include the MS notifying to a site BD for all the applications the site is planning to host for other sites. The MS may also notify the application's policies in the notifications. For multisite, the site BD may register to a transit control plane (e.g., a T-MS) for the specific application by registering the BD using the EID as the resolved IP/MAC address as well as the "distinguished name" and the policy for that application. (In another embodiment, the T-MS may also be preconfigured with the policies for all the applications). The T-MS may propagate this registration and policy to another site's local MS to use the remote site's server for the application. Or other site's edge device may forward the packet to a default border Egress Tunnel Router (ETR) and that default ETR border may request to the T-MS for the application's RLOC and policies. If the location of any service or application changes, the MS may be re-registered with their new locations (i.e., RLOCs). The MS may update existing map-caches using any map-cache update process. Any policy change for these services may also be updated using existing policy change processes.

Embodiments of the disclosure may provide a zero day, zero touch deployment of enterprise fabric applications or services where there may be no need to know the application's, service's, or server's locations and their IP/subnet addresses in advance. These services may be unicast, multicast, or broadcast. Also, the whole network may not need to change when later these applications, services, or servers are deployed. Instead, the networks may dynamically detect the applications, services, or servers locations and subnets, automatically apply correct policies, and forward the relevant traffic towards these servers. Any other traffic not intended to go towards these servers (e.g., even if the destination address is the server's address) may be dropped at the edge of the network per the configured policies in the fabric control plane. This may not only solve aforementioned problems, but may also make the enterprise fabric networks more secured.

<FIG> shows computing device <NUM>. As shown in <FIG>, computing device <NUM> may include a processing unit <NUM> and a memory unit <NUM>. Memory unit <NUM> may include a software module <NUM> and a database <NUM>. While executing on processing unit <NUM>, software module <NUM> may perform, for example, processes for providing services with policy control as described above with respect to <FIG> and <FIG>. Computing device <NUM>, for example, may provide an operating environment for map server <NUM>, server providing a service <NUM>, router <NUM>, first edge device <NUM>, second edge device <NUM>, border device <NUM>, first client device <NUM>, or second client device <NUM>. Map server <NUM>, server providing a service <NUM>, router <NUM>, first edge device <NUM>, second edge device <NUM>, border device <NUM>, first client device <NUM>, and second client device <NUM> may operate in other environments and are not limited to computing device <NUM>.

Computing device <NUM> may be implemented using a Wi-Fi access point, a cellular base station, a tablet device, a mobile device, a smart phone, a telephone, a remote control device, a set-top box, a digital video recorder, a cable modem, a personal computer, a network computer, a mainframe, a router, a switch, a server cluster, a smart TV-like device, a network storage device, a network relay devices, or other similar microcomputer-based device. Computing device <NUM> may comprise any computer operating environment, such as hand-held devices, multiprocessor systems, microprocessor-based or programmable sender electronic devices, minicomputers, mainframe computers, and the like. Computing device <NUM> may also be practiced in distributed computing environments where tasks are performed by remote processing devices. The aforementioned systems and devices are examples and computing device <NUM> may comprise other systems or devices.

Embodiments of the disclosure, for example, may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process. Accordingly, the present disclosure may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.). In other words, embodiments of the present disclosure may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. A computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

Embodiments of the disclosure may be practiced via a system-on-a-chip (SOC) where each or many of the element illustrated in <FIG> may be integrated onto a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communications units, system virtualization units and various application functionality all of which may be integrated (or "burned") onto the chip substrate as a single integrated circuit. When operating via an SOC, the functionality described herein with respect to embodiments of the disclosure, may be performed via application-specific logic integrated with other components of computing device <NUM> on the single integrated circuit (chip).

Claim 1:
A method comprising:
receiving (<NUM>), by a map server (<NUM>) of a fabric network (<NUM>), registration information associated with a service to be provided by a server (<NUM>) to be connected to a border device (<NUM>) of the fabric network (<NUM>), the registration information comprising information identifying an endpoint identifier comprising a uniform resource locator for the service to be provided by the server (<NUM>) to be connected to the border device (<NUM>), information identifying the border device (<NUM>) as a routing locator for the service to be provided by the server (<NUM>) to be connected to the border device (<NUM>), and policies associated with the service to be provided to the server (<NUM>) to be connected to the border device (<NUM>);
resolving (<NUM>) the uniform resource locator address for the server (<NUM>);
receiving (<NUM>) a request comprising the information identifying the service provided by the server (<NUM>); and
providing (<NUM>), in response to receiving the request comprising the information identifying the service provided by the server (<NUM>), an address for the server (<NUM>), the information identifying the border device (<NUM>), and the policies associated with the service.