Zero-day zero-touch provisioning of services with policy control

Abstract

Services can be provided with policy control. A computing device can receive registration information associated with a border device. The registration information can include information identifying a service provided by a server associated with the border device, information identifying the border device, and a policy associated with the service. An address of the server can then be determined. Next, a request can be received, the request including information identifying the service provided by the server. In response to receiving the request including information identifying the service provided by the server, the address of the server, the information identifying the border device, and the policy associated with the service can be provided.

Description

Technical Field

[0001] This application was filed on November 8, 2021 as a PCT international patent application and claims the benefit and priority of U.S. non-provisional patent application serial number 17 / 097,709, filed on November 13, 2020, the entire disclosure of which is incorporated herein by reference.

[0002] This disclosure generally relates to providing services with policy controls. Background Technology

[0003] A computer network, or data network, is a telecommunications network that allows computers to exchange data. In a computer network, networked computing devices use data links to exchange data with each other. Connections between nodes are established using cable or wireless media. The most well-known computer network is the Internet.

[0004] Network computer devices that initiate, route, and terminate data are called network nodes. Nodes can include hosts such as personal computers, telephones, servers, and networking hardware. Two such devices can be said to be networked when one device is able to exchange information with another, regardless of whether there is a direct connection between them. Computer networks vary in the transmission media used to carry their signals, the communication protocols that organize network traffic, the size of the network, its topology, and its organizational intent. Attached Figure Description

[0005] The accompanying drawings, which are included in and constitute a part of this disclosure, illustrate various embodiments of the present disclosure. In the drawings: Figure 1 It is a block diagram of the network; Figure 2 This is a flowchart of a method for providing services with policy controls; Figure 3 This is a flowchart of a method for providing services with policy controls; and Figure 4 It is a block diagram of a computing device. Detailed Implementation

[0006] Overview The independent claims describe various aspects of the invention, and the dependent claims describe preferred features. A feature of one aspect may be applied individually to each aspect or in combination with other features.

[0007] Services with policy controls can be provided. The computing device can receive registration information associated with a border device. This registration information may include information identifying the service provided by a server associated with the border device, information identifying the border device, and the policy associated with the service. The server's address can then be determined. Next, a request may be received, including information identifying the service provided by the server. In response to receiving the request including information identifying the service provided by the server, the server's address, information identifying the border device, and the policy associated with the service can be provided.

[0008] The foregoing overview and the following exemplary embodiments are merely illustrative and should not be construed as limiting the scope of the described and claimed disclosure. Furthermore, features and / or variations may be provided in addition to those described. For example, embodiments of the disclosure may be adapted to various combinations and sub-combinations of features described in the exemplary embodiments.

[0009] Example Implementation The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar elements. While embodiments of this disclosure can be described, modifications, adaptations, and other implementations are possible. For example, elements illustrated in the drawings may be replaced, added, or modified, and the methods described herein may be modified by replacing, reordering, or adding stages to the disclosed methods. Therefore, the following detailed description does not limit this disclosure. Rather, the proper scope of this disclosure is defined by the appended claims.

[0010] A fabric network can include a network topology in which components pass data to each other by interconnecting network nodes (e.g., devices). A fabric network can include an overlay and an underlay. The underlay handles connectivity between fabric network devices, while the overlay handles user traffic traversing the fabric network. Fabric network overlays can include functional components such as fabric edge (FE) devices, fabric middleware devices, fabric border (FB) devices, map servers (MS), and the control plane (CP).

[0011] In the architecture network coverage, FE devices may include, for example, Locator / ID Separation Protocol (LISP) xTR (Ingress / Exit Tunnel Router) / PxTR (Proxy xTR) nodes, and FB devices may include, for example, LISP PxTR (Proxy xTR) nodes. Endpoints (e.g., client devices or hosts) may be attached to FE devices. Endpoints may reside in an endpoint identification space, where each endpoint may have an Endpoint Identifier (EID). Each device in the architecture network (e.g., FE devices and FB devices) may be configured with an address (e.g., a locator address). FE devices may register the discovered EID (from the endpoint) with the architecture host tracking database running on the MS, associating the discovered EID with, for example, the configured locator address of the FE device that discovered it.

[0012] When a local FE device receives a packet from a local endpoint destined for a remote endpoint (i.e., on a remote FE device) whose location is unknown (e.g., the endpoint is connected via the Internet), the local FE device can send a map request message to the MS. The MS may have a border device registered as an Internet service provider. In this case, the MS can reply to the map request with a remote locator address, which is the address of the Internet service boundary. Once the local FE device receives a reply message from the MS associating an unknown EID with the remote locator address, all subsequent traffic from the local endpoint can be encapsulated (e.g., LISP encapsulation) and forwarded to the remote locator address (i.e., the remote xTR device). Once the encapsulated packet is received on the remote xTR device, the remote xTR device can decapsulate the packet and forward it locally (e.g., to the remote endpoint).

[0013] FB devices can connect infrastructure networks to their local routing domain. FB devices can be configured, for example, as LISP PxTR nodes and can provide default gateway services to FE nodes. Communication can occur through FB devices configured, for example, as LISP PxTR nodes. When an FE device receives a packet from a local endpoint destined for a host outside the infrastructure network within its local routing domain, the FE device can encapsulate and send the packet to the FB device. FB devices can provide, for example, LISP PxTR functionality and advertise themselves as the next-hop address for all infrastructure-managed EID prefixes to their local routing domain so that it can route traffic.

[0014] Architecture overlay can provide the following services. For example, architecture overlay can use Layer 3 overlay to provide stretched Layer 2 services, which can provide the flexibility to extend subnets to any part of the architecture network. For example, subnets can exist between multiple FE devices with the same anycast gateway Internet Protocol (IP) address to allow roaming by allowing endpoints to continue using the same gateway IP address. The services provided may also include Layer 3 overlay services and built-in mobility.

[0015] When deploying a network architecture (e.g., with access switches and routers), it may be unknown in advance where different cloud-based applications (e.g., private, public, or hybrid) or other on-premises applications, services, or servers might be located, and what subnets / IP addresses they might be assigned. Without this prior network knowledge, the network may initially be configured and deployed without the support of these applications / services. Later, as applications, services, and servers are configured, different network components (e.g., edge switches, border devices, control plane servers, firewalls, etc.) may need to be modified to allow networking paths to and from these new applications, services, and servers. However, this can be an expensive and time-consuming operation, as it may involve complex network reconfiguration and debugging, which may require skilled network engineers and network outages. It may also lead to the reconfiguration and reassessment of existing network security mechanisms, which, if done incorrectly, could result in security vulnerabilities. This could be because the network may already be deployed and operational. All of these issues can cause problems during application and service deployment. This could be problematic for companies that may be handling time-critical operations where disruption is unacceptable (e.g., hospitals, financial institutions that handle high-frequency or critical financial transactions, mission-critical applications like space research, autonomous vehicles, Internet of Things (IoT) applications, etc.).

[0016] Embodiments of this disclosure can provide deployments of enterprise-architectural networks (e.g., cloud-based or on-premises) with applications and services, where the location and IP / subnet addresses of the applications, services, or servers may not need to be known in advance. These services can be unicast, multicast, or broadcast. Furthermore, using embodiments of this disclosure, the network may not need to be changed when these applications, services, or servers are subsequently deployed. Instead, the network can dynamically detect the location and subnet of the applications, services, and servers and forward relevant traffic to them. Any other traffic not intended for these servers (i.e., even if the destination address is a server address) can be dropped at the network edge according to policies configured in the architecture control plane. This not only solves the aforementioned problems but may also make enterprise-architectural networks more secure.

[0017] For example, an enterprise "abc" may have a Dynamic Host Configuration Protocol (DHCP) server "dhcp.abc.com", which may have location ranges: i) East Coast dhcp.abc.com can resolve to 192.168.1.2; West Coast dhcp.abc.com can resolve to 192.168.2.2; and Asia Pacific dhcp.abc.com can resolve to 192.169.2.2. For example, embodiments of this disclosure may allow the architecture to provide "zero" contact location-specific DHCP service. Border devices (e.g., xTR / border) connected to the DHCP server may register with a site map server (MS) as "dhcp.abc.com" (or its resolved address), with a service type such as "DHCP_SRV" and its associated policy. MS can resolve (e.g., using a Domain Name Server (DNS)) and populate its registry (e.g., in the schema host trace database) with the server's destination IP address (i.e., the IP address of the DHCP server or a Uniform Resource Locator (URL)) and routing locator (RLOC) mappings and associated service policies.

[0018] When an Edge Device (ED) receives a DHCP packet from a host (i.e., a client device), it can query the MS (e.g., with a map request) for the "DHCP_SRV" (i.e., type of service). The MS can respond with the destination IP address (i.e., the IP address of the DHCP server) and the RLOC mapping and associated policy. The ED can receive the DHCP server's address, RLOC, and associated policy, and install a map cache for it on the ED. Therefore, at the edge, the IP address of the DHCP server may not be needed in the relay, and this process can become dynamic. The example mentioned above uses DHCP as a service, but other services consistent with the embodiments of this disclosure can also be used.

[0019] Another option is that, in response to a map request for a service, the MS can respond to the ED with a URL (e.g., "dhcp.abc.com") and the RLOC of the border device. The ED can then resolve the destination IP address of the service's server (i.e., the IP addresses of DHCP, Authentication, Authorization and Accounting (AAA) servers, and other shared service servers) and install a map cache with this destination-to-RLOC mapping. For example, {Service Type: Service IP, VN}, such as service {DHCP::10.1.1.1,VN1; DHCP::20.1.1.1,VN2;AAA::5.5.5.5,*}. Based on this, the map cache can be populated, and the service can be provided with the appropriate IP address (e.g., the AAA above could be provided with IP 5.5.5.5). The same process can be applied to other services. For example, this allows the ED to have a minimal configuration.

[0020] Figure 1 A system 100 consistent with embodiments of this disclosure is shown for providing services with policy controls. For example... Figure 1 As shown, system 100 may include a first network 102, multiple client devices 104, a second network 106, a map server 108, and a service-providing server 110. The first network 102 may include multiple network devices, including but not limited to router 112, a first edge device 114, a second edge device 116, intermediate network devices (not shown), and a border device 118. The multiple client devices 104 may include a first client device 120 and a second client device 122. The second network 106 may include networks outside of the first network 102, such as networks leading to the cloud (e.g., the Internet). The map server 108 may own and maintain a schema host tracking database 124. The service-providing server 110 may provide any service (e.g., cloud-based), including but not limited to DHCP, DNS, authentication, authorization, and accounting (AAA), and other shared services.

[0021] For example, the multiple network devices in the first network 102 may include, but are not limited to, switches and routers. The first network 102 may include any number of network devices. The multiple client devices 104 may include any number of client devices, and are not limited to two. Each of the multiple client devices 104 may include any type of device that wishes to communicate through the first network 102. For example, each of the multiple client devices 104 may include, but is not limited to, Wi-Fi access points, cellular base stations, tablet devices, Internet of Things (IoT) devices, mobile devices, smartphones, telephones, remote control devices, set-top boxes, digital video recorders, cable modems, personal computers, laptops, network computers, mainframes, routers, or other similar microcomputer-based devices.

[0022] First network 102 may include an architecture network. This architecture network may include a lower layer and an overlay. The lower layer may handle connectivity between architecture elements (e.g., network devices), and the overlay may handle user traffic entering the architecture. Traffic may enter the architecture network (i.e., first network 102) through FE devices (e.g., first edge device 114 and second edge device 116). Traffic may be routed through first network 102 via multiple intermediate network devices within the multiple network devices. FE devices may be responsible for encapsulating packets with an architecture header containing the address of the egress FE device. When a packet (e.g., a frame) arrives at the egress FE device, the architecture header can be stripped, and the native packet can be forwarded based on its internal address. The architecture network may be able to provide Layer 2 and Layer 3 services on top of the lower layer. The architecture network may have endpoints connected to it (e.g., multiple client devices 104).

[0023] The aforementioned elements of system 100 (e.g., map server 108, service-providing server 110, router 112, first edge device 114, second edge device 116, border device 118, first client device 120, or second client device 122) can be implemented in hardware and / or software (including firmware, resident software, microcode, etc.) or any other circuit or system. The elements of system 100 can be implemented in circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. Furthermore, the elements of system 100 can also be implemented using other technologies capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. As described below regarding… Figure 4 In a more detailed description, the elements of system 100 can be implemented in computing device 400.

[0024] Figure 2The flowchart illustrates the general stages involved in method 200 for providing services with policy controls, consistent with embodiments of this disclosure. Method 200 can be implemented using map server 108, as described above regarding... Figure 1 A more detailed description is available. This can be combined with... Figure 3 The flowchart 300 describes method 200. The implementation of each stage of method 200 will be described in more detail below.

[0025] Method 200 can begin at start block 205 and proceed to stage 210, where map server 108 can receive registration information associated with border device 118. This registration information may include information identifying services provided by a server associated with border device 118 (e.g., server 110 providing the service), information identifying border device 118, and policies associated with that service. For example, border device 118 can be configured using an application's URL (e.g., site boundary / xTR), for which a server will be located behind border device 118. Border device 118 can register applications with the enterprise architecture control plane (i.e., map server 108) by registering itself as an RLOC and registering its EID as the "distinguished name" for the application or service. Figure 3 (Phase 305, 310, 315, and 320). Map server 108 can be configured with policies tailored to these different applications. In other embodiments, these policies may be sent to map server 108 during the registration of border device 118. Information identifying services provided by servers associated with the border device may include endpoint identifiers (EIDs), which may include, for example, Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, distinguished names identifying services, or Uniform Resource Locators (URLs) identifying services. Information identifying the border device may include Router Locator (RLOC) locator types, such as default locators or service-specific locators.

[0026] Map server 108 may repeatedly attempt to resolve the application's URL with DNS at frequent intervals, which may fail because the application server may not yet be connected. In other embodiments, map server 108 may be re-registered to resolve IP addresses when these services are advertised or announced. An edge device (e.g., first edge device 114) may identify application packets in the forwarding plane and may request map server 108 for the application server's RLOC (e.g., using the service name as the application's "Distinctive Name EID"). Because map server 108 may not yet have resolved the application's URL, it may respond with a drop action. The edge device (e.g., first edge device 114) may drop the application packet.

[0027] From stage 210, where map server 108 receives registration information associated with border device 118, method 200 can proceed to stage 220, where map server 108 can determine the address of a server (e.g., server 110 providing the service). For example, an application server can connect to border device 118 (e.g., site boundary / xTR). The service can now be deployed by the individual devices and advertised or announced. Map server 108 can now resolve the application's URL or the IP or Media Access Control (MAC) address of the registered service based on the service announcement from its devices. Map server 108 can associate the IP or MAC address with the application or service's "Distinguished Name" (EID). Map server 108 can store this information, along with the configuration policies for these applications or services, in the schema host trace database 124.

[0028] Once map server 108 has determined the address of the server (e.g., server 110 providing the service) in phase 220, method 200 can proceed to phase 230, where map server 108 can receive a request including information identifying the services provided by the server (e.g., server 110 providing the service). For example, first edge device 114 can recognize that it has received an application packet from first client device 120. Figure 3 (Stage 325), and can request map server 108 for the application's RLOC. Figure 3 Stage 330).

[0029] After map server 108 receives a request in stage 230 including information identifying a service provided by a server (e.g., server 110 providing the service), method 200 can proceed to stage 240, where map server 108 may, in response to receiving the request including information identifying a service provided by a server (e.g., server 110 providing the service), provide the address of the server (e.g., server 110 providing the service), information identifying the boundary device 118, and the policy associated with the service. Figure 3 (Stage 335). For example, in response, map server 108 can not only send the RLOC of the application server (e.g., server 110 providing the service), but also specify policies for that application. For some services, map server 108 can also send a list of device IP addresses, along with the RLOC of their corresponding service devices. Border device 118 can install these policies in its forwarding hardware for traffic directed to the application server or service devices. Future traffic can then be forwarded according to the installed policies. Figure 3(Phase 340, 345, 350, 355, and 360). Once map server 108 has provided the address of the server (e.g., server 110 providing the service), information identifying the boundary device 118, and the policy associated with the service in phase 240, method 200 can then end in phase 250.

[0030] For multi-site application configuration or deployment, embodiments of this disclosure may include the MS notifying the site BD of all applications that the site plans to host for other sites. The MS may also notify the application's policies in the notification. For multiple sites, the site BD can register a specific application to the transit control plane (e.g., T-MS) by registering the BD using the EID as the resolved IP / MAC address, along with a "distinguished name" and the application's policies. (In another embodiment, the T-MS may also be pre-configured with the policies for all applications). The T-MS can propagate this registration and policy to a local MS at another site to use the remote site's server for the application. Alternatively, edge devices at other sites can forward packets to the default Egress Tunnel Router (ETR), which can request the application's RLOC and policies from the T-MS. If the location of any service or application changes, the MS can be re-registered to their new location (i.e., RLOC). The MS can use any map cache update procedure to update the existing map cache. Existing policy change procedures can also be used to update any policy changes for these services.

[0031] Embodiments of this disclosure can provide zero-day, zero-touch deployment of enterprise architecture applications or services, where the location and IP / subnet addresses of the applications, services, or servers may not need to be known in advance. These services can be unicast, multicast, or broadcast. Furthermore, the entire network may not need to be changed when deploying these applications, services, or servers later. Instead, the network can dynamically detect the location and subnet of the applications, services, or servers, automatically apply the appropriate policies, and forward relevant traffic to these servers. Any other traffic not intended for these servers (e.g., even if the destination address is a server address) can be dropped at the network edge according to policies configured in the architecture control plane. This not only solves the aforementioned problems but also makes enterprise architecture networks more secure.

[0032] Figure 4 A computing device 400 is shown. (For example...) Figure 4 As shown, computing device 400 may include a processing unit 410 and a memory unit 415. Memory unit 415 may include software module 420 and database 425. When executed on processing unit 410, software module 420 may execute processes, for example, for providing services with policy control, as described above regarding... Figure 2 and Figure 3 The computing device 400 may provide an operating environment for, for example, a map server 108, a service-providing server 110, a router 112, a first edge device 114, a second edge device 116, a border device 118, a first client device 120, or a second client device 122. The map server 108, the service-providing server 110, the router 112, the first edge device 114, the second edge device 116, the border device 118, the first client device 120, and the second client device 122 may operate in other environments, and are not limited to the computing device 400.

[0033] The computing device 400 can be implemented using Wi-Fi access points, cellular base stations, tablet devices, mobile devices, smartphones, telephones, remote control devices, set-top boxes, digital video recorders, cable modems, personal computers, network computers, mainframes, routers, switches, server clusters, smart TV-like devices, network storage devices, network relay devices, or other similar microcomputer-based devices. The computing device 400 can include any computer operating environment, such as handheld devices, multiprocessor systems, microprocessor-based or programmable transmitter electronics, microcomputers, mainframes, etc. The computing device 400 can also be implemented in a distributed computing environment, where tasks are performed by remote processing devices. The systems and devices described above are examples, and the computing device 400 can include other systems or devices.

[0034] Embodiments of this disclosure may be implemented, for example, as a computer process (method), a computing system, or as an article of manufacture such as a computer program product or a computer-readable medium. A computer program product may be a computer storage medium that is readable by a computer system and encodes instructions for performing a computer process. A computer program product may also be a propagated signal on a carrier of a computer program that is readable by a computing system and encodes instructions for performing a computer process. Therefore, this disclosure may be embodied in hardware and / or software (including firmware, resident software, microcode, etc.). In other words, embodiments of this disclosure may take the form of a computer program product on a computer-usable or computer-readable storage medium that embodies computer-usable or computer-readable program code for use by or in connection with an instruction execution system. A computer-usable or computer-readable storage medium may be any medium capable of containing, storing, communicating, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device.

[0035] Computer-usable or computer-readable media can be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, devices, or propagation media. More specific examples of computer-readable media (not an exhaustive list) include: electrical connections having one or more wires, portable computer disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, and compact disc-only memory (CD-ROM). Note that computer-usable or computer-readable media can even be paper or another suitable medium on which a program is printed, because the program can be electronically captured, for example, by optical scanning of the paper or other medium, and then, if necessary, compiled, interpreted, or otherwise processed in a suitable manner, and subsequently stored in computer memory.

[0036] While some embodiments of this disclosure have been described, other embodiments are possible. Furthermore, although embodiments of this disclosure have been described as being associated with data stored in memory and other storage media, data may also be stored on or read from other types of computer-readable media, such as secondary storage devices like hard disks, floppy disks, or CD-ROMs, carrier waves from the Internet, or other forms of RAM or ROM. Additionally, the stages of the disclosed methods may be modified in any way, including through reordering stages and / or insertion or deletion stages, without departing from this disclosure.

[0037] Furthermore, embodiments of this disclosure can be implemented in circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. Embodiments of this disclosure can also be implemented using other techniques capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. Additionally, embodiments of this disclosure can be implemented within a general-purpose computer or in any other circuit or system.

[0038] Embodiments of this disclosure can be implemented via a system-on-a-chip (SOC), wherein Figure 1Each or many of the components shown can be integrated onto a single integrated circuit. Such a SoC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which can be integrated (or “programmed”) onto a chip substrate as a single integrated circuit. When operating via the SoC, the functions described herein with respect to embodiments of this disclosure can be executed via dedicated logic integrated on a single integrated circuit (chip) along with other components of the computing device 400.

[0039] For example, embodiments of the present disclosure have been described above with reference to block diagrams and / or operational illustrations of methods, systems, and computer program products according to embodiments of the present disclosure. The functions / behaviors described in the blocks may not occur in the order shown in any flowchart. For example, depending on the functions / actions involved, two blocks shown consecutively may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order.

[0040] While this specification includes examples, the scope of this disclosure is indicated by the appended claims. Furthermore, although this specification has been described in language specific to structural features and / or methodological actions, the claims are not limited to the features or actions described above. Rather, the specific features and actions described above are disclosed as examples of embodiments implementing this disclosure.

Claims

1. A method comprising: The map server of the architecture network receives registration information associated with a service to be provided by a server of a border device to be connected to the architecture network. The registration information includes information identifying an endpoint identifier, information identifying the border device, and a policy associated with the service. The endpoint identifier includes a unique Uniform Resource Locator (URL) for the service, and the information identifying the border device includes a routing locator for the service. Parse the unique Unique Resource Locator (URL) of the server; Receive a request that includes information identifying the service provided by the server; and In response to receiving the request including information identifying the service provided by the server, the server's address, information identifying the border device, and the policy associated with the service are provided.

2. The method as described in claim 1, wherein, Receiving the registration information includes receiving the registration information from the border device.

3. The method of claim 1 further includes storing the registration information and the address of the server in a database located on the map server.

4. The method of claim 1, wherein, Receiving the request includes receiving the request from an architecture edge (FE) device.

5. The method of claim 1, further comprising providing information identifying the edge device, the policy associated with the service, and the address to the architecture edge device.

6. The method of claim 5, further comprising forwarding future traffic of the service to the server according to the policy associated with the service.

7. A system comprising: Memory storage device; as well as A processing unit coupled to the memory storage device, wherein the processing unit is operable to: Receive registration information, which is associated with a service to be provided by a server of a border device to be connected to the network architecture. The registration information includes information identifying an endpoint identifier, information identifying the border device, and a policy associated with the service. The endpoint identifier includes a unique Uniform Resource Locator (URL) for the service, and the information identifying the border device includes a routing locator for the service. Parse the unique Unique Resource Locator (URL) of the server; Receive a request that includes information identifying the service to be provided by the server; and In response to receiving the request including information identifying the service to be provided by the server, the server's address, information identifying the border device, and the policy associated with the service are provided.

8. The system of claim 7, wherein, The processing unit is operable to receive the registration information, including: the processing unit is operable to receive the registration information from the border device.

9. The system as claimed in claim 7 or 8, wherein, The processing unit is located in a map server (MS).

10. A computer-readable medium storing a set of instructions, said set of instructions, when executed, performing a method performed by said set of instructions, said method comprising: The map server of the architecture network receives registration information associated with a service to be provided by a server of a border device to be connected to the architecture network. The registration information includes information identifying an endpoint identifier, information identifying the border device, and a policy associated with the service. The endpoint identifier includes a unique Uniform Resource Locator (URL) for the service, and the information identifying the border device includes a routing locator for the service. Parse the unique Unique Resource Locator (URL) of the server; Receive a request that includes information identifying the services to be provided by the server; and In response to receiving the request including information identifying the service to be provided by the server, the server's address, information identifying the border device, and the policy associated with the service are provided.

11. The computer-readable medium of claim 10, wherein, Receiving the registration information includes receiving the registration information from the border device.

12. The computer-readable medium of claim 10, further comprising storing the registration information and the address of the server in a database located on the map server.

13. The computer-readable medium according to any one of claims 10 to 12, wherein, Receiving the request includes receiving the request from an architecture edge (FE) device.

14. An apparatus comprising: A means for receiving registration information by a map server of an architecture network, the registration information being associated with a service to be provided by a server of a border device to be connected to the architecture network, the registration information including information identifying an endpoint identifier, information identifying the border device, and a policy associated with the service, the endpoint identifier including a unique Uniform Resource Locator (URL) for the service, and the information identifying the border device including a routing locator for the service; A means for resolving the unique Unique Resource Locator of the server; A means for receiving a request including information identifying a service to be provided by the server; as well as A means for providing the address of the server, information identifying the border device, and a policy associated with the service in response to receiving a request including information identifying the service to be provided by the server.

15. The apparatus of claim 14, further comprising means for implementing the method of any one of claims 2 to 6.

16. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method as claimed in any one of claims 1 to 6.

Images