Service peer exchange

Abstract

Embodiments of the present disclosure relate to service peer exchange. The present disclosure describes methods for providing early acknowledgment to a source device performing a data write operation within a data center or across geographically distributed data centers. In one example, the present disclosure describes a method comprising receiving data from a source device in a local data center to be stored at a destination device located in a remote data center; storing the data in a high-speed memory included in a gateway device; outputting a local acknowledgment to the source device after storing the data and before the data is stored at the destination device; sending the data over a connection to a remote data center; receiving a remote acknowledgment from a device in the remote data center; and, in response to receiving the remote acknowledgment, deallocating the data from the high-speed memory included in the gateway device.

Description

[0001] This application is a divisional application of the invention patent application with international application number PCT / US2018 / 037389, international application date June 13, 2018, date of entry into the Chinese national phase December 12, 2019, Chinese national application number 201880039255.5, and invention name “Service Peer Exchange”.

[0002] Related applications

[0003] This application claims priority to U.S. Provisional Application Serial No. 62 / 518,992, filed June 13, 2017, the entire contents of which are incorporated herein by reference. Technical Field

[0004] The present disclosure relates to computer networks, and more particularly, to a service peering exchange for creating and managing service-to-service paths between applications provided by a computer network. Background Art

[0005] As digital services become increasingly dominant, these services interact in an automated manner to provide connectivity between enterprises. Productized application programming interfaces (APIs) for accessing enterprise services are becoming the new digital storefronts, and enterprises often deploy API gateways accessible to the public internet to provide a single, controlled, and reliable entry point into their internal system architecture. Summary of the Invention

[0006] In general, the present disclosure describes a service peering exchange for creating and managing service-to-service paths between applications. For example, a service peering exchange having a network connection to multiple networks can receive application programming interface (API) data that describes APIs for services provided, for example, by an enterprise or cloud service provider (CSP) and that can be accessed via the network using service requests. Such services can include, for example, data storage, e-commerce, billing, marketing, customer relationship management (CRM), social media, digital media, finance, weather, search, and other services accessible using machine-to-machine communications over the network. An administrator or customer of the service peering exchange can configure policies applied by the service peering exchange to coordinate service-to-service paths between different services accessible via different networks.

[0007] Based on the policy, the Service Peering Exchange can logically segment the shared service bandwidth provided by the Service Peering Exchange and route the service request to the appropriate service endpoint. For certain service requests, the Service Peering Exchange can also verify that the service requester is authorized and enforce service-level policies before routing the service request to the service endpoint, based on the policy configured for each destination service endpoint.

[0008] Each instance of a service that exchanges service traffic with a service peer exchange exposes a remote API at a network address and transport layer port that can be advertised and used using a service directory, service layer, and higher layers of a protocol stack. At least in some cases, one or more of the services may be accessed via a service provider's service gateway (or "API gateway") that serves as a public interface to the remote API at the service gateway's network address and port. The service peer exchange may include or access a service registry to obtain corresponding network addresses and ports for accessing services at various service endpoints across multiple service provider networks. The service peer exchange publishes registered, accessible APIs for clients of the service peer exchange and provides network layer and higher layer connectivity for clients to access the APIs at the network addresses and ports of the service peer exchange that are accessible to the clients on access links.

[0009] In some examples, to route service requests received at the network address and port of a service peer exchange to the appropriate service endpoint, the service peer exchange performs service level mapping and proxies the service session between: (i) the requesting application and the service peer exchange and (ii) the service peer exchange and the service endpoint. In some examples, the service peer exchange can have connectivity with a cloud exchange or other network service exchange, which enables a one-to-many connection between the service peer exchange and the network hosting the service. In some examples, to route service requests, the service peer exchange applies policies to allow bridging (i.e., forwarding at layer 2) of service requests to service endpoints visible at the network layer (layer 2 / layer 3) to the requesting application. In some examples, the service peer exchange can arrange service chains for services by routing service requests according to one or more policies.

[0010] The service peering exchange technology described herein may have one or more technical advantages. For example, by proxying service sessions or bridging communications, a service peering exchange can allow multiple applications to exchange service requests and responses without requiring any dedicated direct network-layer connections between the networks of the service instances that communicate with each other. In this way, a service peering exchange can replace interconnected networks, allowing customer networks to remain disconnected from each other except via the service peering exchange and solely for service traffic. This can avoid the need for customers to purchase or otherwise establish direct or virtual connections between customers using cross-connects or virtual connections, such as virtual private networks or virtual circuits of cloud exchanges, Internet exchanges, or Ethernet exchanges. Reducing or eliminating direct or virtual connections between customers can facilitate lower-latency service traffic and can simplify network configuration and reduce network load by reducing the resources and / or resource utilization typically required to facilitate such network connections, such as network links, firewalls, and memory resources of network devices. A service peering gateway can also provide a centralized location for multiple service endpoints to perform endpoint-specific (or at least customer-specific) requester authentication, security and packet inspection, API-level policy enforcement, data collection, and analysis.

[0011] In one example, a method includes: receiving, by a service peer exchange executed by one or more computing devices and at a first service exchange endpoint of the service peer exchange, a first incoming service request from a first customer network, wherein the first incoming service request is destined for the first service exchange endpoint and wherein the first incoming service request may call an application programming interface of a first application; outputting, by the service peer exchange, a first outgoing service request destined for a service endpoint of a second customer network executing the first application in response to receiving the first incoming service request, wherein the first outgoing service request may call an application programming interface of the first application; receiving, by the service peer exchange and at a second service exchange endpoint of the service peer exchange different from the first service exchange endpoint, a second incoming service request from the first customer network, wherein the second incoming service request is destined for the second service exchange endpoint and wherein the second incoming service request may call an application programming interface of a second application; outputting, by the service peer exchange, a second outgoing service request destined for a service endpoint of a third customer network executing the second application in response to receiving the second incoming service request, wherein the second outgoing service request may call an application programming interface of the second application.

[0012] In another example, a service exchange system includes one or more service peer exchanges configured to be executed by a service peer exchange platform including one or more computing devices; and a service gateway for an application configured to be executed by a first customer network, the service gateway configured to be executed by a computing device of the first customer network, wherein the one or more service peer exchanges are configured to receive, at a service exchange endpoint, an incoming service request from a second customer network, wherein the incoming service request is destined for the service exchange endpoint, and wherein the incoming service request can call an application programming interface of an application configured to be executed by the first customer network, wherein the one or more service peer exchanges are configured to, in response to receiving the incoming service request, output an outgoing service request destined for the service endpoint of the service gateway, wherein the outgoing service request can call an application programming interface of an application configured to be executed by the first customer network, and wherein the service gateway is configured to receive a second service request at the service endpoint and route the second service request to the application.

[0013] In another example, a service exchange system includes one or more service peering exchanges configured for execution by a service peering exchange platform comprising one or more computing devices, wherein the one or more service peering exchanges are configured to receive a first incoming service request from a first customer network at a first receiving service exchange endpoint, wherein the first incoming service request is destined for the first service exchange endpoint and wherein the first incoming service request may invoke an application programming interface of a first application, wherein the one or more service peering exchanges are configured to, in response to receiving the first incoming service request, output a first outgoing service request destined for a service endpoint of a second customer network for executing the first application, wherein the first outgoing service request may invoke the application programming interface of the first application, wherein one or more service peering exchanges are configured to receive a second incoming service request from the first customer network at a second service exchange endpoint different from the first service exchange endpoint, wherein the second incoming service request is destined for the second service exchange endpoint, wherein the second incoming service request may invoke an application programming interface of a second application, and wherein the one or more service peering exchanges are configured to, in response to receiving the second incoming service request, output a second outgoing service request destined for a service endpoint of a third customer network for executing the second application, wherein the second outgoing service request may invoke the application programming interface of the second application.

[0014] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1is a block diagram illustrating an example service exchange system for creating and managing service-to-service paths between applications accessible to multiple different service endpoints, in accordance with techniques of this disclosure.

[0016] Figure 2A –2B is a block diagram illustrating an example cloud exchange point, configurable by a programmable network platform, according to techniques of this disclosure to establish network connections between a service peering exchange and multiple customer networks to enable service-to-service communications between applications executed by the customer networks.

[0017] Figure 3 is a block diagram illustrating an example service exchange system in accordance with techniques of this disclosure.

[0018] Figure 4 is an example service mapping according to the techniques of this disclosure.

[0019] Figure 5 is a block diagram illustrating a conceptual diagram of a service exchange system with a metro-based cloud exchange providing multiple cloud exchange points for communicating with service peer exchanges, in accordance with techniques described herein.

[0020] Figure 6 is a flow chart illustrating an example mode of operation for service peer exchange according to the techniques of this disclosure.

[0021] Figure 7 is a block diagram illustrating an example of a distributed services exchange system in accordance with the techniques described herein.

[0022] Like reference characters denote like elements throughout the drawings and text. DETAILED DESCRIPTION

[0023] Figure 1 1 is a block diagram illustrating an example service exchange system for creating and managing service-to-service paths between applications accessible by multiple different service endpoints, in accordance with techniques of the present disclosure. The service exchange system 100 includes a plurality of customer networks 108A-108C (collectively, "customer networks 108") for respective customers of a provider of a service peering exchange 101.

[0024] Each of customer networks 108 may represent one of the following: an enterprise network, a cloud service provider network, a private, public, or hybrid cloud network, or a tenant network within a cloud network. Each of customer networks 108 is a layer 3 network that may include one or more non-edge switches, routers, hubs, gateways, security devices (e.g., firewalls), intrusion detection and / or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices.

[0025] Each of customer networks 108 includes one or more host servers (not shown), each of which executes an instance of at least one of applications 110A-110D (collectively, "applications 110"). For example, one or more host servers in customer network 108A each execute a service instance of application 110A, and the service instance processes service requests received at the network address and port assigned to the host server of the service instance. As another example, one or more host servers in customer network 108C each executes a service instance of application 110C and / or a service instance of application 110D.

[0026] A host server may include a computing server, a storage server, an application server, or other computing device for executing an application that processes service requests received via a network. A host server may represent a real server or a virtual server, such as a virtual machine, a container, or other virtualized execution environment.

[0027] The applications 110 provide services such as data storage, e-commerce, billing, marketing, customer relationship management (CRM), social media, digital media, finance, weather, search, and other services accessible using machine-to-machine communications over the corresponding customer network 108. Each of the applications 110 can represent a different service. Each service instance hosted by a host server exposes a remote application programming interface (API) at the network address and port of the host server. The combination of the network address and port mapped to the service instance executed by the host server is called a "service endpoint" and, more specifically, in this example, where the service instance is logically located behind the service gateway 112, is called an "internal service endpoint." A service instance, such as application 110D, processes a service request received at the network address and port of the host server executing the service instance, which service request conforms to the API of application 110D. A service request can alternatively be referred to as an "API request."

[0028] The services provided by the application 110 may also be referred to alternatively as "web services" because these services communicate with web services, applications, and messaging protocols of other computing devices and other emerging protocols that were developed at least in part for the World Wide Web, such as Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), and run on Internet Protocol networks. These services can operate according to different service frameworks, such as Apache Axis, Java Web Services, Windows Communication Foundation (WCF), and .NET Framework, each of which uses one or more web service protocols to communicate service data between machines. Example web service protocols include JavaScript Object Notation (JSON)-Remote Procedure Call (RPC), Representational State Transfer (REST) ​​services, Simple Object Access Protocol (SOAP), Apache Thrift, Extensible Markup Language (XML)-RPC, Message Queuing Telemetry Transport (MQTT), Rabbit Message Queuing (RabbitMQ) and Constrained Application Protocol (CoAP), and Web Services Description Language (WSDL).

[0029] In this example, the administrator of customer network 108 deploys a corresponding service gateway 112 to the customer network to expose the internal API of the service instance to customers outside the customer network. For example, service gateway 112A of customer network 108A operates as a single entry point for one or more service instances of application 110A and is responsible for routing service requests to the service instances. That is, service gateway 112A routes service requests received at service gateway 112 to target services provided by one or more service instances of application 110A. Service gateway 112A can represent a server computing device that executes a service gateway application. Service gateway 112A can represent a pool of service gateway instances ("gateway pool") accessible at one or more service endpoints. Service gateway 112A can be instantiated by corresponding customers that create one or more network function virtualization (NFV) instances of the service gateway function. After instantiating them, customers can register the NFV instances in service peer exchange 101. Service gateway 112A has a network address and can receive service requests for routing at a transport layer port, such as port 80 or 8080 for HTTP-based service requests, although the service gateway can map any suitable transport layer port to a service. The combination of the network address and port of the service gateway application is a service endpoint 114A for the service exposed by service gateway 112A. Service gateways 112B and 112C can be deployed and operate similarly to service gateway 112A as described above. Therefore, service gateway 112B includes service endpoint 114B, at which service gateway 112B receives service requests for application 110B, and service gateway 112C includes service endpoints 114C and 114D, at which service gateway 112C receives service requests for applications 110C and 110D.

[0030] As used herein, the term "routing" and similar terms used to convey a service request to an intended destination may include layer 2 / layer 3 forwarding, but may additionally or alternatively include the application of policies to identify, approve, and output the service request to its intended destination in accordance with its service agreement. The outgoing service request may be routed in its original form or in a modified form, for example, to direct the service request from a received service exchange endpoint to an application's service endpoint, which may be reachable via a service endpoint of a service gateway.

[0031] In addition to routing service requests between requesters (i.e., issuers of service requests) and internal service endpoints, each of the service gateways 112 can also verify that the requester is authorized to make the request, prevent unauthorized requesters from accessing the internal service endpoints, perform load balancing among multiple service instances for application 110, throttle service requests, and / or convert the network service protocol of the received service request to another network service protocol (e.g., converting a RESTful protocol to SOAP) before routing the service request. Each of the service gateways 112 can use a service discovery mechanism to identify the internal service endpoints of the services provided by application 110 and route service requests for the services to the internal service endpoints. Example service discovery mechanisms include client-side discovery and server-side discovery. In this manner, the service gateway 112 provides an external API for reaching the internal service endpoints of application 110.

[0032] Service discovery may occur at the service layer, as the service layer typically describes and provides business functions and services for providing services that conform to one or more Web service protocols. The services provided by applications 110 for corresponding clients 108 are associated with service endpoints 114. Service discovery information obtained by service peer exchange 101 and communicated to service gateway 112 for service discovery by service gateway 112 may be stored by service peer exchange 101 in association with the service endpoints.

[0033] Customer network 108 is coupled to service peer exchange 101 via corresponding communication links 103A-103C (collectively, "communication links 103"). Customer network 108 and service peer exchange 101 exchange data communications via communication links 103, each of which may represent, for example, at least one Ethernet link, an Asynchronous Transfer Mode (ATM) link, and a SONET / SDH link. Communication links 103 may each represent a Layer 2 network, such as a local area network (LAN) or a virtual local area network (VLAN). The data communications may conform to the Open Systems Interconnection (OSI) model, the Transmission Control Protocol (TCP) / Internet Protocol (IP) model, or the User Datagram Protocol (UDP) / IP model. The data communications may include Layer 3 (i.e., network layer) packets having an Internet Protocol (IP) header that includes source and destination network addresses and Layer 4 (e.g., transport layer protocol, such as TCP / UDP) source and destination ports. The IP header also specifies the transport layer protocol used for the data communications.

[0034] Customer networks 108 may not have network connectivity to each other. That is, a device in customer network 108A may not be able to send a network (layer 3) packet to a device in customer network 108B or a device in customer network 108C because there is no physical or virtual network configured to route network packets between customer networks 108. In some cases, customer networks 108 may only have network connectivity to each other via communication links other than communication link 103.

[0035] The service peer exchange 101 obtains service endpoint data describing the service endpoint 114 for the API exposed by the service gateway 112, for example, using service discovery. The service endpoint data may include the network address and port information of the service endpoint 114. The service peer exchange 101 may perform service discovery, such as by sending a service discovery message to the service gateway to obtain the service endpoint data from the service registry of the service gateway. The service peer exchange 101 may further obtain API description data for the API exposed by the service gateway 112 at the service endpoint 114. The API description data may describe protocols, methods, API endpoints, etc., which define acceptable service requests for the service endpoint to interact with the services of the application 110. The API description data may be formatted using WSDL.

[0036] According to the techniques described in this disclosure, service peering exchange 101 enables inter-service communication between applications 110 executed by different customer networks 108 by creating and managing service-to-service paths between the applications. In this example, service peering exchange 101 enables service exchange endpoints 106 to send and receive service traffic with customer networks 108. As used herein, "service traffic" can refer to service requests that invoke an application programming interface of a service instance, as well as responses to such service requests (or "service responses").

[0037] Each service exchange endpoint 106 is a network address and port pair that the service peering exchange 101 uses internally using service mapping data to map to one of the service endpoints 114 for a service provided by an application 110 executed on a customer network 108. The service peering exchange 101 receives a service request, for example, issued by an application 110 at a service exchange endpoint 106. In response, the service peering exchange 101 outputs a corresponding service request, which is directed to a service endpoint 114 on a different customer network 108 to which the destination service exchange endpoint 106 is mapped. In this manner, the service peering exchange 101 enables service-to-service communication between applications executed on customer networks 108 that do not have dedicated direct network layer connections to each other. The service peering exchange 101 can obtain the service mapping data in real time by performing service mapping resolution for load balancing service requests between service gateways / applications that are members of a pool.

[0038] exist Figure 1 In the example of FIG. 1 , service peering exchange 101 maps service exchange endpoints 106A-106D to corresponding service endpoints 114A-114D of multiple customer networks 108, where service endpoint 114 is accessible at service gateway 112 in this example. Service peering exchange 101 maps service exchange endpoint 106A, exposed by service peering exchange 101, to service endpoint 114A, exposed by service gateway 112A of customer network 108A, which can be used to access an API of application 110A. Service peering exchange 101 maps service exchange endpoint 106B, exposed by service peering exchange 101, to service endpoint 114B, exposed by service gateway 112B of customer network 108B, which can be used to access an API of application 110B. The service peering exchange 101 maps the service exchange endpoints 106C, 106D exposed by the service peering exchange 101 to the service endpoints 114C, 114D exposed by the service gateway 112C of the customer network 108C and usable to access the APIs of the applications 110C, 110D. Thus, as described in further detail below, the service peering exchange 101 enables the applications 110B-110D executed by the customer networks 108B, 108C to issue service requests to the application 110A even though the customer networks 108B, 108C have no network connectivity to each other.

[0039] Service peer exchange 101 receives a service request 124A from customer network 108A. Service request 124A has a destination network address and destination port that matches the network address and port of service exchange endpoint 106C. Service request 124A may conform to a Web services protocol, such as any of the Web services protocols listed above. For example, service request 124A may represent REST communication using HTTP, SOAP communication, or another type of service request that may invoke an API of application 110C. That is, the service instance of application 110C recognizes service request 124A as a service request to invoke an API for application 110C. Service request 124A may be generated by the service instance of application 110A and may be output from a computing device in customer network 108C executing the service instance. Service request 124A includes service data for invoking an API provided by the service instance of application 110C.

[0040] Service peer exchange 101 maps service request 124A received at service exchange endpoint 106C to service endpoint 114C and generates a new outgoing service request 124A'. Outgoing service request 124A' includes the service data from service request 124A and includes a layer 4 header and a layer 3 header that enable outgoing service request 124A' to be received at service endpoint 114C exposed by service gateway 112C. In other words, service peer exchange 101 rewrites at least the destination network address and destination port of service request 124A destined for service exchange endpoint 106C to generate and output outgoing service request 124A' destined for service endpoint 114C. Service peer exchange 101 may also generate outgoing service request 124A' to have a source service endpoint of service exchange endpoint 106A, which was mapped to service endpoint 114A by service peer exchange 101. Service peer exchange 101 outputs outgoing service request 124A' via communication link 103C. Service gateway 112C receives outgoing service request 124A' at service endpoint 114C. Service peering exchange 101 can proxy the transport layer (e.g., TCP) session between service peering exchange 101 and the service instance of application 110A, as well as the transport layer session between service peering exchange 101 and the service instance of application 110C. In this way, service peering exchange 101 creates a service-to-service path for service requests and service responses between the service instance of application 110A and the service instance of application 110C, even though customer network 108 lacks inter-network connectivity.

[0041] Service gateway 112C sends outgoing service request 124A' for processing by the service instance of application 110C. In some cases, service gateway 112C may generate a new outgoing service request 124A' with a layer 4 header and a layer 3 header with a destination port and a destination address for the service instance of application 110C. The service instance of application 110C may output a new service request 125A for application 110B executed by customer network 108B. Service request 125A is destined for service exchange endpoint 106B of service peer exchange 101. Service peer exchange 101 receives service request 125A at service exchange endpoint 106B. Service peer exchange 101 maps service request 125A at service exchange endpoint 106B to service endpoint 114B and generates a new outgoing service request 125A'. To generate a new outgoing service request 125A', service peer exchange 101 may apply operations similar to those expressed above to generate outgoing service request 124A'. Service peer exchange 101 outputs outgoing service request 125A' via communication link 103B. Service gateway 112C receives outgoing service request 125A' at service endpoint 114C. Service peer exchange 101 may proxy the transport layer session between service peer exchange 101 and the service instance of application 110C, as well as the transport layer session between service peer exchange 101 and the service instance of application 110B.

[0042] Service gateway 112B sends outgoing service request 125A' for processing by the service instance of application 110B. In some cases, service gateway 112B may generate a new outgoing service request 125A' with a layer 4 header and a layer 3 header with a destination port and a destination address for the service instance of application 110B. The service instance of application 110B processes outgoing service request 125A' and may generate a service response 125B destined for service exchange endpoint 106C, which is indicated as the source service endpoint of service request 125.

[0043] Service peer exchange 101 receives service response 125B at service exchange endpoint 106C and generates an outgoing service response 125B' based on the mapping of service exchange endpoint 106C to service endpoint 114C. Therefore, outgoing service response 125B' is destined for service endpoint 114C. Service peer exchange 101 outputs outgoing service response 125B' to customer network 108C via communication link 103C. Service gateway 112C receives outgoing service response 125B' at service endpoint 114C and directs outgoing service response 125B' to the service instance of application 110C. The service instance of application 110C processes outgoing service response 125B'.

[0044] The service instance of application 110C may generate a service response 124B in response to outgoing service request 124A'. Service response 124B is destined for service exchange endpoint 106A based on the source endpoint indicated by outgoing service request 124A'. Service peer exchange 101 receives service response 124B at service exchange point 106A and generates service response 124B' based on a mapping of service exchange endpoint 106A to service endpoint 114A. Therefore, service response 124B' is destined for service endpoint 114A. Service peer exchange 101 outputs service response 124B' to customer network 108A via communication link 103A. Service gateway 112A receives service response 124B' at service endpoint 114A and directs service response 124B' to the service instance of application 110A. The service instance of application 110A processes service response 124B'.

[0045] In some examples, each of the service gateways 112 exposes its registered APIs and corresponding service endpoints 114 to the service peer exchange 101. For example, service gateway 112A may register an API accessible at service endpoint 114A, service gateway 112B may register an API accessible at service endpoint 114B, and service gateway 112C may register an API accessible at service endpoints 114C and 114D. In some cases, a customer operating each gateway 112 may register APIs and service endpoints 114 via a portal application, such as described below with respect to Figure 2A-Customer portal 330 as described in 2B. Service endpoints and service exchange endpoints can be indicated in part using a uniform resource locator (URL) or uniform resource identifier, in part using a transport layer port, or by explicitly specifying a network address and transport layer port for the service endpoint. As described above, the service peer exchange 101 can use service discovery to obtain the service endpoint 114 of the API of the service gateway 112. The service peer exchange 101 can publish the endpoint 114 along with the API to customers of the customer network 108 in an API catalog, which can be accessed, for example, via a portal deployed by the provider of the service peer exchange 101. In some examples, the service peer exchange 101 (or a customer portal for the service peer exchange, such as portal 330) outputs an indication of the accessibility of the application programming interface at the service exchange point. For example, the service peer exchange 101 maps the registered endpoint 114 to the service exchange endpoint 106 and publishes the endpoint 106 along with the API to customers of the customer network 108 in the API catalog. Thus, the application 110 and the service gateway 112 can direct service requests for the API to the service exchange endpoint 106 of the service peer exchange 101, thereby impersonating the service gateway 112 using the service exchange endpoint 106 to receive service requests that are ultimately destined for the application 110 behind the service endpoint 114.

[0046] Application 110 can perform service discovery to identify a service exchange endpoint 106 for accessing a service endpoint 114 via service peer exchange 101. Service discovery can occur at the service layer. Service peer exchange 101 can expose a discovery API, for example, using a discovery uniform resource locator (URL), to enable such service discovery by application 110. For example, application 110A can invoke the discovery API using a discovery request message that includes parameter values ​​indicative of application 110C. Service peer exchange 101 provides a discovery response message that includes the network address and port of service exchange endpoint 106C, which is mapped to service endpoint 114C by service peer exchange 101. Thus, application 110A can direct a service request to service exchange endpoint 106C using the above-described techniques for service peer exchange 101 to pass to service endpoint 114C exposed by service gateway 112C.

[0047] The service peering technology enables the service peering exchange 101 to receive service requests and route them to appropriate service endpoints 114 for corresponding applications 110 executed by multiple different customer networks 108, even though such networks, at least in some cases, lack dedicated network connections to each other. In this way, the service peering exchange 101 can replace the interconnected network, allowing customer networks 108 to remain disconnected from each other except via the service peering exchange 101 and solely for service traffic, thereby obviating the need for customers deploying customer networks 108 to purchase or otherwise establish direct or virtual connections between customer networks 108 using cross-connects or virtual connections such as virtual private networks. In effect, the service peering exchange 101 essentially abstracts the network by providing service request routing between customer networks 108 and service segmentation between service gateways 112 based on access authorization between applications 110.

[0048] Furthermore, the service peering exchange 101 can provide clients with a neutral service for peering API services between each other. As business processes become more fluid and intertwined within business ecosystems, clients may bundle and share services within a process. The flow of service requests 124 and 125 from client network 108A via client 108C to client 108B is an example of such a flow. Each service may belong to a different organizational entity (and the digital service components provided by that entity), and the flow may represent a new joint business offering. The service peering exchange 101 provides layered services as a point of intersection for digital business-to-business transactions between two or more clients that have deployed their respective customer networks 108. As described in further detail below, the service peering exchange 101 can be deployed as a service exchange, such as a cloud exchange or an internet exchange, and become an open digital business exchange for tenants that have access to the service exchange or otherwise have applications executed by a network that has access to the service exchange. In some cases, one or more tenant clients are directly collocated with the service exchange by deploying network and computing equipment for the customer network 108 within the physical data center that houses the service exchange. One or more tenant customers may also or instead be indirectly connected to the service exchange via a network service provider that is collocated within the physical data center and connected to the service exchange.

[0049] Figure 2AFigure 2B is a block diagram illustrating an example cloud exchange point, configurable by a programmable network platform, according to techniques of this disclosure to establish network connectivity between a service peering exchange and multiple customer networks, enabling service-to-service communication between applications executed by the customer networks. Cloud exchange point 303 is an example implementation of a software-defined networking (SDN)-controlled or software-defined wide area network (SD-WAN)-controlled network switch fabric, in which a controller (in this example, programmable network platform 328) manages the network configuration of the network to facilitate connectivity between customer network 308 and service peering exchange 301. Cloud exchange point 303, customer network 308, and service peering exchange 301 can represent example instances of service exchange system 100. Customer network 308 can represent example customer network 108, application 310 can represent example application 110, service gateway 312 can represent example service gateway 112, service endpoint 314 can represent example service endpoint 114, and service peering exchange 301 can represent example service peering exchange 101.

[0050] Customer networks 308A-308C (collectively, "customer networks 308"), each associated with a different customer of the provider of cloud exchange point 303, access cloud exchange point 303 in data center 300 to receive aggregated services from one or more other networks coupled to cloud exchange point 303. Customer networks 308 each include endpoint devices that provide and / or use services. Example endpoint devices include real or virtual servers, smartphones, television set-top boxes, workstations, laptops / tablets, video game systems, teleconferencing systems, media players, and the like.

[0051] Customer networks 308A-308B include corresponding provider edge / autonomous system boundary routers (PE / ASBRs) 309A-309B. Each of PE / ASBRs 309A, 309B can execute an exterior gateway routing protocol to peer with one of PE routers 302A-302B ("PE routers 302" or more simply "PE 302") via one of access links 316A-316B (collectively, "access links 316"). In the illustrated example, each of access links 316 represents a transit link between an edge router of customer network 308 and an edge router (or autonomous system boundary router) of cloud exchange point 303. For example, PE 309A and PE 302A can directly peer via an exterior gateway protocol (e.g., external BGP) to exchange L3 routes over access link 316A and exchange L3 data traffic between customer network 308A and cloud service provider network 320. In some cases, access links 316 may represent, or may be referred to as, attachment circuits for IP-VPNs configured in IP / MPLS fabric 318, as described in further detail below. In some cases, access links 316 may each comprise a direct physical connection between at least one port of customer network 308 and at least one port of cloud exchange point 303, without an intervening transit network. Access links 316 may operate over a VLAN or stacked VLANs (e.g., QinQ), a VxLAN, an LSP, a GRE tunnel, or other types of tunnels.

[0052] While illustrated and primarily described with respect to L3 connectivity between customer network 308 and service peering switch 301, PE router 302 may additionally or alternatively provide L2 connectivity between customer network 308 and service peering switch 301 via access link 316. For example, a port of PE router 302A may be configured with an L2 interface that provides L2 connectivity to customer network 308A via access link 316A to service peering switch 301, and service peering switch 301 is coupled (directly or via another network device) to a port of PE router 304A that is also configured with an L2 interface. A port of PE router 302A may additionally be configured with an L3 interface that provides L3 connectivity to customer network 308A via access link 316A to cloud service provider 320B. PE 302A can be configured with multiple L2 and / or L3 sub-interfaces so that the cloud exchange provider can offer customer 308A one-to-many connectivity to service peering exchange 301 and one or more other networks coupled to cloud exchange point 303 .

[0053] To create an L2 interconnection between customer networks 308 and service peering switch 301, in some examples, IP / MPLS fabric 318 is configured with an L2 bridging domain (e.g., an L2 virtual private network (L2VPN), such as a virtual private LAN service (VPLS), E-LINE, or E-LAN) to bridge L2 traffic between the customer-facing ports of PE 302 and the service peering switch ports of 304A. In some cases, service peering switch 301 and one or more customer networks 308 may have access links to the same PE router 302, 304, which uses a bridging domain to bridge L2 traffic. To create an L3 interconnection between customer networks 308 and service peering switch 301, in some examples, IP / MPLS fabric 318 is configured with an L3 virtual routing and forwarding instance (VRF).

[0054] In some examples of cloud exchange point 303, any of access link 316 and aggregate link 322 can represent a network-to-network interface (NNI) link. Additional details of NNI links and provisioning NNI links to facilitate layer 2 connectivity in data center 300 are provided in U.S. Patent No. 8,537,845, entitled “Real-time configuration and provisioning for a carrier Ethernet exchange,” issued on September 17, 2013, which is incorporated herein by reference in its entirety.

[0055] In this example, customer network 308C is not an autonomous system with an autonomous system number. Customer network 308C can represent other customer networks within the routing footprint of an enterprise, network service provider, or cloud exchange point. Customer network includes customer edge (CE) device 311, which can execute an exterior gateway routing protocol to peer with PE router 302B via access link 316C. In various examples, any of PEs 309A-309B can alternatively or otherwise represent a CE device. Customer networks 308A-308B may or may not be autonomous systems with autonomous system numbers.

[0056] Access link 316 comprises a physical link and may include one or more intermediate switching devices. PE / ASBRs 309A-309B, CE devices 311, and PE routers 302A-302B exchange L2 / L3 packets via access link 316. In this regard, access link 316 constitutes a transport link for cloud access via cloud exchange point 303.

[0057] In some examples, cloud exchange point 303 aggregates access to cloud exchange point 303 by clients 308 to other networks coupled to cloud exchange point 303. For example Figures 2A-2B Access links 316A-316B are shown connecting various customer networks 308A-308B to PE router 302A of cloud exchange point 303, and access link 316C connects customer network 308C to PE router 302B. Any one or more of PE routers 302, 304 may comprise an ASBR. PE routers 302, 304 and IP / MPLS fabric 318 may be configured according to the techniques described herein to interconnect any of access links 316 to access link 322. As a result, for example, cloud service provider network 320A only needs to configure a single cloud aggregate link (here, access link 322A) to provide services to multiple customer networks 308. That is, the cloud service provider operating cloud service provider network 302A does not need to provision and configure separate service links, such as from service peering exchange 303 to PE routers 309, 311, to provide services to each of customer networks 308. Cloud exchange point 303 may instead interconnect access links 322 coupled to PE 304A and service peering switch 301 to multiple cloud access links 316 to provide layer 3 peering and network reachability for service traffic between any one of customer networks 308 and service peering switch 301 .

[0058] Furthermore, a single customer network, such as customer network 308A, need only have a single cloud access link (here, access link 316A) configured to a cloud exchange point 303 within data center 300 for service peering exchange 301 to provide services that are peered with customer network 308 that is also coupled to cloud exchange point 303. That is, the operator of service peering exchange 301 does not need to provision and configure separate service links connecting service peering exchange 301 in order to provide services that are peered with multiple customer networks 308. Cloud exchange point 303 can instead interconnect each of cloud access links 316A-316B (again, as an example) to access link 322 to provide layer 3 peering and network reachability for cloud service delivery to customer networks 308A-308C.

[0059] In some cases, service peering exchange 301 can be coupled to a PE router (not shown), which is coupled to access link 322. The PE router can execute an exterior gateway routing protocol, such as eBGP, to exchange routes with PE router 304A of cloud exchange point 303.

[0060] In the example shown, an Internet Protocol / Multi-Protocol Label Switching (IP / MPLS) fabric 318 interconnects PE 302 and PE 304A. IP / MPLS fabric 318 includes one or more switching and routing devices, including PEs 302, 304A, that provide IP / MPLS switching and routing of IP packets to form an IP backbone. In some examples, IP / MPLS fabric 318 can implement one or more different tunneling protocols (i.e., in addition to MPLS) to route traffic between PE routers and / or associate the traffic with different IP-VPNs. According to the techniques described herein, IP / MPLS fabric 318 implements an IP virtual private network (IP-VPN) to connect any of customers 308 to service peering exchange 301 to provide data center-based "transit" and layer 3 cross-connectivity. Given that service provider-based IP backbones require limited-bandwidth wide area network (WAN) connections to transport service traffic from layer 3 service providers to customers, the cloud exchange point 303 described herein "transports" service traffic and interconnects the service peering exchange 301 to customers 308 within the high-bandwidth local environment of the data center 300, provided by a data center-based IP / MPLS fabric 318. In some examples, the IP / MPLS fabric 318 implements an IP-VPN using the techniques described in "BGP / MPLS IP Virtual Private Networks (VPNs)" by Rosen & Rekhter, Internet Engineering Task Force (IETF) Network Working Group, Draft for Comment 4364, February 2006, which is incorporated herein by reference in its entirety. In some example configurations, the customer network 308 and the service peering exchange 301 can be connected to the same PE router of the IP / MPLS fabric 318 via corresponding links.

[0061] Access link 316 and access link 322 may include attachment circuits that associate traffic exchanged with connected customer network 308 or service peering exchange 301 with a virtual routing and forwarding instance (VRF) configured in PEs 302 and 304A and corresponding to an IP-VPN running on IP / MPLS fabric 318. For example, PE 302A may exchange IP packets with PE 310A over a bidirectional label-switched path (LSP) running through access link 316A, the LSP being the attachment circuit 302A to the VRF configured in the PE. As another example, PE 304A may exchange IP packets with a PE device or network switch for service peering exchange 301 over a bidirectional label-switched path (LSP) or VLAN operating through access link 322, the LSP or VLAN being the attachment circuit to the VRF configured in PE 304A. Each VRF may include or represent different routes and forwarding tables with different routes.

[0062] The PE routers 302, 304 of the IP / MPLS fabric 318 can be configured in a corresponding hub-and-spoke arrangement for cloud services, where PE 304A is implemented as the hub and PE 302 is configured as the spoke of the hub (for various hub instances / arrangements). The hub arrangement ensures that service traffic can flow between the hub PE and any of the spoke PEs, but not between different spoke PEs. In this way, a hub VPN can achieve complete separation between customer networks 308. As further described below, in a hub arrangement, for data center-based IP / MPLS fabric 318 and customer-bound service traffic (i.e., from service peering exchange 301 to customer network 308), PE 302 advertises routes received from PEs 309, 311 to PE 304A. For service traffic bound to the service peering exchange (i.e., from customer network 308 to service peering exchange 301), PE 304A advertises routes from service peering exchange 301 to PE 302, which in turn advertises routes to PE 309 and CE 311. As used herein, the hub VRF exports routes with an "up" route target (RT), while the spoke VRFs import routes with an "up" route target. Conversely, the spoke VRFs export routes with a "down" route target, while the hub VRFs import routes with a "down" route target. In some examples, each VRF instance has a unique route distinguisher (RD).

[0063] For some customers of cloud exchange point 303, the provider of cloud exchange point 303 may configure a full mesh deployment, whereby each set of PEs 302 and 304A is coupled to a different customer site network for that customer. In this case, IP / MPLS fabric 318 implements a Layer 3 VPN (L3VPN) for cage-to-cage or redundant traffic (also known as east-west or horizontal traffic). L3VPN can implement closed user groups, whereby each customer site network can send traffic to each other but cannot send or receive traffic outside the L3VPN.

[0064] In some examples, PE routers may be coupled to each other based on a peer-to-peer model without using an overlay network. That is, PE 309, CE 311, and the network serving peer exchange 301 may not directly peer with each other to exchange routes, but may exchange routes indirectly via IP / MPLS fabric 318. Figure 2B In the example of FIG3 , programmable network platform 328 configures cloud exchange point 303 to implement multiple virtual circuits 324A-324C (collectively, "virtual circuits 324") for interconnecting customer network 308 and service peering exchange 301 with an end-to-end IP path. Service peering exchange 301 and customer 308 can each be an endpoint of multiple virtual circuits 324, where multiple virtual circuits 324 traverse one or more attachment circuits between a PE / PE or PE / CE pair for IP / MPLS fabric 318 and the customer or service peering exchange 301. Virtual circuits 324 can represent layer 3 paths through IP / MPLS fabric 318 between attachment circuits connecting customer networks to fabric 318 and attachment circuits connecting service peering exchange 301 to fabric 318. Each virtual circuit 324 can include at least one tunnel (e.g., LSP and / or Generic Routing Encapsulation (GRE) tunnel) having endpoints at PEs 302, 304. PEs 302 , 304 can establish a complete channel mesh interconnected with each other.

[0065] Each virtual circuit 324 can be implemented using a different star network configured in IP / MPLS network 301, which has PE routers 302, 304A that exchange routes using a full or partial mesh of Border Gateway Protocol peering sessions, in this example a full mesh of Multi-Protocol Interior Border Gateway Protocol (MP-iBGP) peering sessions. MP-iBGP, or simply MP-BGP, is an example of a protocol by which routers exchange labeled routes to implement MPLS-based VPNs. However, PEs 302, 304 can use other technologies and / or protocols to exchange routes to implement IP-VPNs.

[0066] In the example of virtual circuit 324A, PE 304A may associate a route for reaching a service peering exchange with a star network, possibly with an associated VRF, that includes spoke PE router 302A. PE 304A then exports the route to PE router 302A; PE router 304A may export the route specifying PE router 304A as the next-hop router along with a label identifying the star network. PE router 302A sends the route to PE router 309B via a routing protocol connection with PE 309B. PE router 302A may send the route after adding the autonomous system number of cloud exchange point 303 (e.g., to a BGP autonomous system path (AS_PATH) attribute) and specifying PE router 302A as the next-hop router. Thus, even though cloud exchange point 303 may be based in a data center, cloud exchange point 303 is an autonomous system "hop" in the path from customer 308 to the autonomous system of cloud service provider 320 (or vice versa). PE router 310B installs the routes into a routing database, such as a BGP Routing Information Base (RIB), to provide layer 3 reachability to service peering exchange 301. In this manner, cloud exchange point 303 "leaks" routes from service peering exchange 301 to customer network 308 without requiring a direct layer 3 peering connection between service peering exchange 301 and customer network 308.

[0067] PE routers 309B, 302A, and 304A can perform similar operations in the reverse direction to forward routes initiated by customer network 308B to PE 304A, thereby providing connectivity from service peering exchange 301 to customer network 308B. In the example of virtual circuit 324A, PE routers 309A, 304A, and 302A exchange routes for customer network 308A and service peering exchange 301 in a manner similar to that described above for establishing virtual circuit 324B. As a result, cloud exchange point 303 within data center 300 can internalize peering connections that can otherwise be established between network devices for service peering exchange 301 and each of PEs 309A, 309B to aggregate services provided by service peering exchange 301 to multiple customer networks 308 via a single access link 322 to cloud exchange point 303. Without the techniques described herein, fully interconnecting customer network 308 and service peering exchange 301 would require peering connections between each of PE 309, CE 311, and the network equipment for service peering exchange 301. Using the techniques described herein, cloud exchange point 303 can fully interconnect customer network 308 and service peering exchange 301 by internalizing layer 3 peering and providing a data center-based "transit" between access interfaces, with one peering connection per site edge device (i.e., to each of PE 309, CE 311, and the network equipment for service peering exchange 301).

[0068] In examples where IP / MPLS fabric 318 implements a BGP / MPLS IP-VPN or other IP-VPN that uses route targets to control route distribution within the IP backbone, PE 304A can be configured to use different asymmetric route targets to import routes from PE 302 and export routes for service peering exchange 301. Similarly, PE 302 can be configured to use asymmetric route targets to import routes from PE 304A and export routes received from PE 309 and CE 311. Thus, PEs 302 and 304A can be configured to implement advanced L3VPNs, each of which includes the basic backbone L3VPN of IP / MPLS fabric 318 as well as the extranets of any of the customer networks 308 and service peering exchanges 301 attached to the basic backbone L3VPN. Each advanced L3VPN constitutes a cloud service delivery network from the service peering exchange 301 to one or more customer networks 308, and vice versa. In this manner, cloud exchange point 303 enables service peering exchange 301 to exchange service traffic with any customer network 308, while simultaneously internalizing the Layer 3 routing protocol peering connection that would otherwise be established between a customer network 308 and a pair of networks for service peering exchange 301 for service connectivity between a given pair. In other words, cloud exchange point 303 allows each of customer networks 308 and service peering exchange 301 to establish a single (or multiple, for redundancy or other reasons) Layer 3 routing protocol peering connection to the data center-based Layer 3 interconnect. By filtering routes from network 301 for service peering exchange to customer networks 308, and vice versa, PEs 302 and 304A control the establishment of virtual circuits 324 and the associated service traffic flows between customer networks 308 and service peering exchanges 301 within data center 300. Routes distributed into MP-iBGP mesh 318 may be VPN-IPv4 routes and are associated with a route differentiator to differentiate routes from different sites with overlapping address spaces.

[0069] Additional details of an example interconnection platform and programmable network platform for configuring a cloud exchange point are described in U.S. Patent Application No. 15 / 001,766, filed on January 20, 2016, entitled "MULTI-CLOUD, MULTI-SERVICE DATA MODEL," and U.S. Patent Application No. 14 / 927,451, filed on October 29, 2015, entitled "INTERCONNECTION PLATFORM FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF A CLOUD-BASED SERVICES EXCHANGE," each of which is incorporated herein by reference in its entirety. A customer of the provider of cloud exchange point 303 and associated with customer network 308A can request an interconnection, such as a virtual circuit, with service peering exchange 301 using customer portal 330 or by calling one or more APIs of programmable network platform 328 for requesting a virtual circuit. In response, programmable network platform 328 configures virtual circuit 324A to create virtual circuit 324A. Customer network 308A then communicates with service peering exchange 301 using virtual circuit 324A.

[0070] Service peering exchange 301 exposes service exchange endpoints 306A-306C reachable from cloud exchange point 303 via access link 322 to PE 304A. Service peering exchange endpoint 306 can also be reached from any customer network 308, which is coupled to cloud exchange point 303 and has a virtual circuit 324 for interconnecting with service peering exchange 301. Service exchange endpoint 306 may represent an example instance of service exchange endpoint 106. Service peering exchange 301 stores configuration data in the form of a service map 320, which maps service exchange endpoints 306 to corresponding service endpoints 314 for accessing application 310 via service gateway 312. For example, service map 320 may map service exchange endpoint 306A to service endpoint 314A, service exchange endpoint 306B to service endpoint 314B, and service exchange endpoint 306C to service endpoint 314C. Service map 320 may represent an associative data structure, such as a table, a mapping, or a dictionary.

[0071] The service peer exchange 301 receives the service request from the cloud exchange point 303 via the access link 322 and uses the service map 320 to determine the corresponding destination service endpoint 314 for the service request. Figure 2BIn the example shown in FIG3 , application 310 initiates service request 325A, which is destined for service exchange endpoint 306B. Customer network 308A outputs service request 325A to cloud exchange point 303 via access link 316A on virtual circuit 324A. Cloud exchange point 303 forwards service request 325A using virtual circuit 324A to service peer exchange 301, which receives service request 325 via access link 322.

[0072] Service peer exchange 301 receives service request 325A at service exchange endpoint 306B. Service peer exchange 301 uses service exchange endpoint 306B information as a query key to query service mapping 320 to determine the service endpoint mapped to service exchange endpoint 306B. Service peer exchange 301 generates a new service request 325A' based on service request 325A. Service request 325A' includes the service data from service request 325A and includes a Layer 4 header and a Layer 3 header that enable outgoing service request 124A' to be received at service endpoint 314B exposed by service gateway 312B. For example, service peer exchange 301 may rewrite at least the destination network address and destination port of service request 325A destined for service exchange endpoint 306A to generate and output service request 325A' destined for service endpoint 314B. Service peer exchange 301 may also generate service request 325A' to have a source service endpoint as service exchange endpoint 306A, which is mapped by service peer exchange 301 to service endpoint 314A for service gateway 312A for application 310A that originated service request 325A.

[0073] Service peering switch 301 outputs service request 325A' via access link 322. Cloud exchange point 303 determines that service request 325A' is destined for service endpoint 314B and will be forwarded using virtual circuit 324B. Service peering switch 301 may output service request 325A' on a VLAN or other attachment circuit for an IP-VPN or other virtual network with customer network 308B. Cloud exchange 303 may forward service request 325A' using virtual circuit 324B based in part on the attachment circuit over which PE 304A received service request 325A'. Customer network 308B receives service request 325A' from cloud exchange point 303 via access link 316B.

[0074] Service gateway 312B receives service request 325A' at service endpoint 314B. Service gateway 312B sends at least the service data from service request 325A' to application 310B for processing.

[0075] Service peering exchange 301 can proxy transport layer (e.g., TCP) sessions between service peering exchange 301 and a service instance of application 310A, as well as transport layer sessions between service peering exchange 301 and a service instance of application 310B. Service peering exchange 301 can also proxy connectionless communications (e.g., UDP) between service peering exchange 301 and a service instance of application 310A, as well as connectionless communications between service peering exchange 301 and a service instance of application 310B. In this manner, even though customer networks 108A and 108B do not have network connectivity to each other, service peering exchange 301 creates a service-to-service path between the service instance of application 310A and the service instance of application 310B, at least via cloud exchange point 303. The service instance of application 310A and the service instance of application 310B can exchange service traffic via the service-to-service path that includes service peering exchange 301.

[0076] In some cases, the service peer exchange 301 can apply policies to control direct bridging (layer 2 forwarding) of service requests for corresponding applications 310 between service endpoints 314. In this case, the service peer exchange can avoid service level mapping and proxying, where the service gateways 312 have network reachability to each other via the service peer exchange 301. For example, a service request initiated by application 310A and specifying service endpoint 314C can be received at the service peer exchange 301 acting as a bridge to customer network 308C. The service peer exchange 301 applies policies 332 as described below to determine whether the service request is allowed. If so, the service peer exchange 301 forwards the service request to the service endpoint 314. If not, the service peer exchange 301 discards the service request.

[0077] In some examples, as part of routing service requests, the service peer exchange can orchestrate sessions to provision service chains for services.

[0078] Policy 332 enables service segmentation between applications 310 executed by customer network 308. That is, based on policy 332, service peer exchange 301 determines the set of applications (e.g., pairs) for which service peer exchange 301 will provide a service-to-service path by passing service requests and service responses to each other. In this way, policy 332 prevents service peer exchange 301 from providing visibility of service traffic by service gateways 312 other than that directed to each service gateway. In addition, each service gateway 312 can only issue service requests to other service gateways 312 as permitted by policy 332. An administrator or operator of service peer exchange 301 can also configure policy 332. Policy 332 can further specify the frequency, quantity, date and time of one or more service requests between a pair of service gateways 312, or other attributes. In this way, service peer exchange 301, applying policy 332, acts as an intermediary between applications 310 to protect and control service flows. In some examples, customer portal 330 provides customers with self-service automation to configure policy 332. In some examples, service peer exchange 301 exposes a configuration API to provide self-service automation to customers to configure policy 332 .

[0079] For example, customer portal 330 represents an application that can provide a user interface for customers to configure the operation of service peer exchange 301, particularly to configure service mapping 320 and policy 332. Customer portal 330 can provide a web interface or other graphical user interface accessible via a website for configuring policy 332. One or more computing devices, such as real servers, execute customer portal 330. Operators of service peer exchange 301 can also use customer portal 330 to configure service mapping 320 and policy 332.

[0080] Strategy 332 may include, for example, strategies for security, intermediary, routing, service conversion, load balancing, and service restrictions. Strategy 332 may be customer-specific (i.e., established for a specific customer, or global). For example, security policies include strategies for authentication, authorization, verification, and encryption. For example, strategy 332 may require that the service peer gateway 301 use credentials or previously obtained login tokens to authorize service requests using a security protocol, such as OAuth 2.0, X.509, Kerberos, or a username and password. The security policy may also determine whether to authorize a user, service instance, or service gateway 312 in the customer network 308 to issue a service request to another service gateway 312 (or service endpoint 314) in the customer network 308. The application of strategy 332 for load balancing may include dynamically mapping a service name to a service destination as a gateway pool instance.

[0081] Offloading the application of policies from service gateways 312, or more broadly, from customer networks 308, can provide technical advantages that improve the value and / or scalability of services across the network. For example, rather than applying security services such as distributed denial of service (DDoS) protection to each service gateway 312, service peering exchange 301 can apply DDoS protection to various service gateways. Other services may include throttling, authentication, other security services, mediation, load balancing, and routing. This technical advantage can be particularly beneficial for smaller customers that cannot devote significant resources to network infrastructure.

[0082] The routing policy of policy 332 causes the service peer exchange 301 to direct matching service requests to specific target service endpoints. Although shown as a separate data structure, in some cases, policy 332 can be used to implement the service mapping 320. For example, the routing policy can match service requests based on the application data therein, the initiator of the service request, and the destination service exchange endpoint 306. The service restriction policy of policy 332 can restrict service requests to a client based on the service, the initiator of the service request, or other criteria. The service gateway 312 can apply load balancing to service requests received at the service endpoint 314.

[0083] Although relative to Figures 2A-2B The service peering exchange 301 is described with reference to FIG. 3 , but the policy 332 may be applied by other service peering exchanges described in this disclosure.

[0084] Service mapping 320 maps service exchange endpoints 306 to corresponding service endpoints 314 to access remote applications 310 from customer network 308 via service gateway 312. As described above, service mapping 320 may be implemented using the routing policy of policy 332.

[0085] exist Figure 2B In the example of FIG. 3 , service peer exchange 301 can apply policy 332 to authenticate and / or authorize service gateway 312A or application 310A to send a service request to service endpoint 314B via service exchange endpoint 306B. Service peer exchange 301 can return an authorization token to the authorization entity. Service request 325A can include the authorization token or other credentials. Service peer exchange 301 can apply policy 332 and service mapping 320 to service request 325A received at service exchange endpoint 306B to authorize, restrict, and route a representation of service request 325A to service endpoint 314B as service request 325A′.

[0086] Figure 3is a block diagram illustrating an example service exchange system according to techniques of the present disclosure. Service exchange system 400 includes a service peer exchange platform 401 in communication with an exchange 410, and a plurality of service gateways 440A-440N in communication with exchange 410. Exchange 410 may represent an Internet exchange, an Ethernet exchange, or a cloud exchange, such as cloud exchange point 303, which may be managed by a data center provider in a data center, where customer networks for service gateways 440 are co-located to exchange network traffic with other customer networks.

[0087] The service peer exchange platform 401 can provide Figure 1 、 2A , the service peer exchange described in 2B. The service peer exchange 401 can represent a real or virtual server or a cluster of real or virtual servers and / or networked devices coupled using network communication. The service peer exchange 401 can be hosted on a public cloud, a private cloud, or a hybrid cloud. The service peer exchange platform 401 may include one or more communication units 402, one or more input devices 404, and one or more output devices 406. The service peer exchange platform 401 includes one or more processors 412 and one or more storage devices 440. The one or more storage devices 440 include an operating system 431 and a service peer exchange application 422. One or more of the devices, modules, storage areas, or other components of the service peer exchange platform 401 can be interconnected to enable inter-component communication (physically, communicatively, and / or efficiently). In some examples, such connectivity can be provided via a system bus, a network connection, an inter-process communication data structure, or any other method for transmitting data. The service peer exchange application 422 can be executed in a distributed manner by multiple servers, of which the service peer exchange platform 401 is an example. The server executing the service peer exchange application 422 may include one or more of a bare metal server, a virtual machine, a container, or other execution environment.

[0088] Input may be generated, received, or processed by one or more input devices 404 of the service peer exchange platform 401. Such input may include input from a keyboard, pointing device, voice response system, camera, button, sensor, mobile device, control panel, microphone, presence-sensitive screen, network, or any other type of device for detecting input from a human or machine.

[0089] One or more output devices 406 of service peer exchange platform 401 can generate, transmit or process output.The example of output is sense of touch, audio, visual and / or video output.Output device 406 can comprise display, sound card, video graphic adapter card, loud speaker, presence sensitive screen, one or more USB interfaces, video and / or audio output interface or can generate the device of any other type of sense of touch, audio, video or other output.Output device 406 can comprise display device, and this display device can be used as the output device of the technology comprising the following: liquid crystal display (LCD), quantum dot display, dot matrix display, light emitting diode (LED) display, organic light emitting diode (OLED) display, cathode ray tube (CRT) display, electronic ink or monochrome, color or can generate the display of any other type of sense of touch, audio and / or visual output.

[0090] One or more communication units 402 of the service peer exchange platform 401 can communicate with devices external to the service peer exchange platform 401 by sending and / or receiving data, and in some aspects can be used as both input devices and output devices. In some examples, the communication unit 402 can communicate with other devices on the network via the exchange 410, including communicating with the service gateway 440 via the exchange 410. In other examples, the communication unit 402 can send and / or receive radio signals on a radio network such as a cellular radio network. In other examples, the communication unit 402 of the service peer exchange platform 401 can send and / or receive satellite signals on a satellite network such as a global positioning system (GPS) network. Examples of the communication unit 402 include a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and / or receive information. Other examples of the communication unit 402 can include those found in mobile devices and universal serial bus (USB) controllers, etc. GPS, 3G, 4G and radio.

[0091] One or more processors 412 of the service peer exchange platform 401 can implement functions and / or execute instructions. Examples of processor 412 include a microprocessor, an application processor, a display controller, an auxiliary processor, one or more sensor hubs, and any other hardware configured to function as a processor, a processing unit, a processing device, or a processing circuit. The service peer exchange platform 401 can use the one or more processors 412 to perform operations according to one or more aspects of the present disclosure using software, hardware, firmware, or a combination of hardware, software, and firmware stored by and / or executed at the service peer exchange platform 401.

[0092] One or more storage devices 420 can store information for processing during the operation of the service peer exchange platform 401. In some examples, one or more storage devices 420 are temporary storage, meaning that the primary purpose of one or more storage devices is not long-term storage. Storage devices 420 can be configured for short-term storage of information as volatile memory, so that the stored contents are not retained if deactivated. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage devices 420 also include one or more computer-readable storage media. Storage devices 420 can be configured to store larger amounts of information than volatile memory. Storage devices 420 can further be configured to store information long-term as non-volatile storage space and retain the information after activation / deactivation cycles. Examples of non-volatile memory include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). The storage device 420 may store program instructions and / or data associated with one or more modules described according to one or more aspects of the present disclosure.

[0093] The one or more processors 412 and the one or more storage devices 420 may provide an operating environment or platform for one or more modules, which may be implemented as software, but in some examples may include any combination of hardware, firmware, and software. The one or more processors 412 may execute instructions, and the one or more storage devices 420 may store instructions and / or data for the one or more modules. The combination of the processors 412 and the storage devices 420 may retrieve, store, and / or execute instructions and / or data for one or more applications, modules, or software. The processors 412 and / or storage devices 420 may also be operably coupled to one or more other software and / or hardware components, including but not limited to Figure 3 One or more components shown.

[0094] Figure 3The one or more modules or applications shown in the storage device 420 (or modules described elsewhere herein) can use software, hardware, firmware, or a mixture of hardware, software, and firmware that resides and / or executes in the service peer exchange platform 401 to perform the described operations. The service peer exchange platform 401 can use multiple processors or multiple devices to execute each of the modules. The service peer exchange platform 401 can execute one or more of these modules locally or as a virtual machine or container executed on the underlying hardware. One or more of these modules can be executed as one or more services of the operating system 431 or the computing platform. One or more of such modules can be executed as one or more executable programs on the application layer of the operating platform provided by the operating system 431.

[0095] The user interface module 435 can manage user interactions with one or more user interface devices, which can include one or more input devices 404 and one or more output devices 406. In some examples, the service peer exchange platform 401 can include a presence-sensitive display, which can function as a user interface device and can be considered both an input device 404 and an output device 406. In some examples, the user interface module 435 can act as an intermediary between various components of the service peer exchange platform 401 to make determinations based on user input detected by the one or more user interface devices and / or the one or more input devices 404 and generate output on the user interface device or the one or more output devices 406.

[0096] The user interface module 435 can receive instructions from an application, service, platform, or other module of the service peer exchange platform 401 to cause a user interface device (e.g., a presence-sensitive display) to output a user interface. The user interface module 435 is shown as a module of the service peer exchange application 422, but the user interface module 436 can generally be a subcomponent of, or execute a subcomponent of, an operating system that controls the operation of the service peer exchange platform 401, and the user interface module 435 can alternatively or also be a separate application, service, or module executed on the peer exchange platform 401. The user interface module 435 can manage input received by the service peer exchange platform 401 as a user views and interacts with the presented user interface and update the user interface in response to receiving additional instructions from an application, service, platform, or other module of the peer exchange platform 401 that is processing the user input. As described further below, the user interface module 435 can output a portal and receive input data (eg, exchange rate data) from an input device 404 accessible by a customer or administrator of the service peer exchange platform 401 to specify and / or manipulate policies 432 .

[0097] The storage device 420 may include an operating system 431 and a service peer exchange application 422 for performing operations related to providing service peer exchange for exchanging service requests between the service gateways 440. The service peer exchange application 422 may interact with and / or operate in conjunction with one or more modules of the service peer exchange platform 401. The service peer exchange application 422 may listen for network packets on a service exchange endpoint of the service peer exchange platform 401. The operating system 431 may execute a network stack and pass network packets destined for a service exchange endpoint to the service peer exchange application 422. The service request may be included in one or more network packets. Each service exchange endpoint is a combination of a network layer (L3) address and a transport layer (L4) port of the service peer exchange platform 401.

[0098] A user may invoke a user interface 436 or an application programming interface 439 for the service peer exchange application 422 to configure a policy 432. The policy 432 may represent an example instance of the policy 332. The communication unit 402 may receive service endpoint data describing one or more service endpoints for one or more service endpoints. One or more processors 412 executing the service peer exchange application 422 process the service endpoint data, request a service exchange endpoint from the operating system 431, and map the service exchange endpoint to a corresponding service endpoint indicated by the service endpoint data. The processor 412 generates a service map 450 for mapping a service exchange endpoint to a service endpoint and vice versa. Through these example operations, the service peer exchange application 422 enables the service peer exchange platform 401 to operate as an application service fabric that performs service routing between service endpoints. The application service fabric may span one or more real and / or virtual computing and / or network devices comprising the service peer exchange platform 401.

[0099] Service peer exchange platform 401 receives a service request 425A from a customer network associated with service gateway 440A via communication unit 402 and network switch 410. Service request 425A is destined for a service exchange endpoint of service peer exchange 401. Request 425A may represent an example instance of any service request described herein. Operating system 431 passes service request 425A to service peer exchange application 422 for processing, which listens on the service exchange endpoint. Service request 425A may arrive as one or more packets.

[0100] According to one or more aspects of the present disclosure, one or more processors 412 executing service peer exchange application 422 processes service request 425A by applying policy 332 to output a representation of service request 425A to a service endpoint of service gateway 440B. Processor 412 applies service mapping 450 to map the destination service exchange endpoint of service request 425A to the service endpoint of service gateway 440B. Service mapping 450 may match the destination network address and destination port of one or more packets in service request 425A and specify the destination endpoint of service gateway 440B. In response, processor 412 generates service request 425A′ with a destination network address and destination port that are the specified destination endpoint of service gateway 440B. Processor 412 may generate service request 425A′ with a source network address and source port that are the service exchange endpoint of service peer exchange platform 401. In this manner, service peer exchange platform 401 emulates service gateway 440A to service gateway 440B. Processor 412 outputs service request 425A′ via communication unit 402 for delivery via network switch 410 .

[0101] Figure 4 is an example service map according to the techniques of this disclosure. Service map 450 is an associative data structure having a plurality of entries 452A-452D that each map a service exchange endpoint of a service peer exchange to a service endpoint of an application, such as a service endpoint exposed by a service gateway, and vice versa. For example, entry 452A maps service exchange endpoint 106A to service endpoint 114A. Service map 450 may store each service endpoint and service exchange endpoint as a combination of a network address and a transport layer port. Service map 450 may include a hash table such that entry 452 is a hash bucket having a hash value corresponding to a value of a hash function applied to a service endpoint or a service exchange endpoint, and hash values ​​of service exchange endpoints are mapped to service endpoints, and hash values ​​of service endpoints are mapped to service exchange endpoints. Example hash functions include SHA-1 and MD5.

[0102] Figure 5is a block diagram illustrating a conceptual diagram of a service exchange system having a metro-based cloud exchange that provides multiple cloud exchange points for communicating with service peer exchanges according to the techniques described herein. Each cloud-based service exchange point 528A-528D (hereinafter referred to as a "cloud exchange point" and collectively referred to as "cloud exchange points 528") of a cloud-based service exchange 510 ("cloud exchange 510") can represent a different data center geographically located within the same metropolitan area ("metro-based," such as New York City, Silicon Valley, California, Seattle-Tacoma, Washington, Minneapolis-St. Paul, Minnesota, London, England, etc.) to provide a resilient and independent cloud-based service exchange, cloud-based service customers ("cloud customers"), and cloud-based service providers ("cloud providers") Figure 5 528 ). Cloud exchange 510 may include more or fewer cloud exchange points 528. In some cases, cloud exchange 510 may include only one cloud exchange point 528. As used herein, references to a "cloud exchange" or "cloud-based service exchange" may refer to a cloud exchange point. A cloud exchange provider may deploy instances of cloud exchange 510 in multiple different metropolitan areas, with each instance of cloud exchange 510 having one or more cloud exchange points 528.

[0103] Each of the cloud exchange points 528 includes a network infrastructure and operating environment through which customers 508A-508D (collectively referred to as "cloud customers 508") exchange service requests and service responses via the service peering exchange 101. Each of the customers 508 may have one or more service peering gateways ( Figure 5 508). Cloud customers 508 may exchange service requests and service responses directly via layer 3 peering and physical connectivity with one of cloud exchange points 528, or indirectly via network service providers 506A-506B (collectively, "NSPs 506" or alternatively, "carriers 506"). NSPs 506 provide "cloud transit" by maintaining a physical presence within one or more of cloud exchange points 528 and aggregating layer 3 access from one or more customers 508. NSPs 506 may directly peer at layer 3 with one or more cloud exchange points 528, and in doing so, may provide indirect layer 3 connectivity and peering to one or more customers 508, through which customers 508 may obtain cloud services from cloud exchange 500.

[0104] exist Figure 5In the example shown in FIG. 5 , each of cloud exchange points 528 can be assigned a different autonomous system number (ASN). For example, cloud exchange point 528A is assigned ASN 5, cloud exchange point 528B is assigned ASN 2, and so on. Thus, each cloud exchange point 528 is the next hop in a path vector routing protocol (e.g., BGP) path from service peering exchange 101 to customer 508. As a result, despite not being a transit network with one or more WAN links and corresponding Internet access and transit policies, each cloud exchange point 528 can still peer with multiple different autonomous systems via external BGP (eBGP) or other exterior gateway routing protocols to exchange, aggregate, and route service traffic from one or more cloud service providers 550 to customers. In other words, cloud exchange point 528 can internalize the eBGP peering relationship that cloud service providers 550 and customers 508 would maintain pairwise. Alternatively, customer 508 can configure a single eBGP peering relationship with cloud exchange point 528 and receive multiple cloud services from one or more cloud service providers 550 via the cloud exchange. Although this document primarily describes eBGP or other layer 3 routing protocol peering between a cloud exchange point and a customer, NSP, or cloud service provider network, a cloud exchange point may learn routes from these networks in other ways, such as through static configuration or via Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), or other route distribution protocols. Each cloud exchange point 528 can represent an example instance of cloud exchange point 303.

[0105] As an example above, customer 508D is shown as having contracted with a cloud exchange provider for cloud exchange 500 to directly access layer 3 cloud services via cloud exchange points 528C, 528D. In this manner, for example, customer 508D receives redundant layer 3 connectivity to cloud service provider 550A. In contrast, customer 508C is shown as having contracted with a cloud exchange provider for cloud exchange 500 to directly access layer 3 cloud services via cloud exchange point 528C, and also contracted with NSP 506B to access layer 3 cloud services via NSP 506B's transit network. Customer 508B is shown as having contracted with multiple NSPs 506A, 506B to have redundant cloud access to cloud exchange points 528A, 528B via the respective transit networks of NSPs 506A, 506B. The above-described contracts are instantiated within the network infrastructure of cloud exchange point 528 through the following: L3 peering configuration within the switching equipment of NSP 506 and cloud exchange point 528, and L3 connections established within cloud exchange point 528, such as layer 3 virtual circuits, to interconnect the cloud service provider 550 network to the NSP 506 network and the customer 508 network, all of which have at least one port providing connectivity within one or more of cloud exchange points 528.

[0106] As an example, customer 508A issues a service request 525 to a service exchange point exposed by service peering exchange 101. NSP 506A transmits service request 525 to cloud exchange point 528A, which passes service request 525 to service peering exchange 101 using a virtual circuit between NSP 506A and service peering exchange 101.

[0107] Service peering exchange 101 maps the service exchange endpoint, which is the destination of service request 525, to a service endpoint at customer 508D. Service peering exchange 101 generates a new service request 525′ that includes the service data from service request 525 and outputs service request 525′ to customer network 508D. Cloud exchange point 528D delivers service request 525′ to customer network 508D using a virtual circuit between service peering exchange 101 and customer network 508D.

[0108] Figure 6 is a flow chart illustrating an example mode of operation 600 for service peer exchange according to the techniques of this disclosure. Figure 1 The Service Peering Exchange 101 describes Figure 6 , but this operation may be performed by any service peering exchange described in this disclosure. The service peering exchange 101 receives service mapping data (602) that maps the service exchange endpoint 106 to the service endpoint of the service gateway 112 of the customer network 108. The service peering exchange 101 may store the service mapping data as a service map or one or more policies.

[0109] The service peer exchange 101 receives an incoming service request 124A, which is output by a device in the customer network 108A and is destined for the service exchange endpoint 106C of the service peer exchange 101 (604). The service peer exchange 101 determines whether the service request 124A is authorized for the service exchange endpoint 106C (606). If the service request 124A is not authorized (the "no" branch of 608), the service peer exchange 101 discards the service request 124A (608). For example, the service peer exchange 101 may not respond to the service request 124A or take any action, or may respond with an error message. If the service request 124A is authorized (the "yes" branch of 608), the service peer exchange 101 routes the service request.

[0110] To route the service request, service peer exchange 101 maps service exchange endpoint 106C to service endpoint 114C of service gateway 112C based on the service mapping data. Service peer exchange 101 generates a new outgoing service request 124A′ (or rewrites the header data of service request 124A to form a new outgoing service request 124A′) destined for service endpoint 114C mapped in step 610. Service peer exchange 101 outputs outgoing service request 124A′ over communication link 103C with customer network 108C (614).

[0111] Figure 7 is a block diagram illustrating an example of a distributed service exchange system according to the techniques described herein. System 800 includes a plurality of geographically distributed data centers 810A-810B ("data centers 810") connected via communication links over a network service provider 825. Data centers 810 may be located within a single metropolitan area or within different metropolitan areas. In this particular example architecture, each of data centers 810 includes a corresponding cloud exchange 803A-803B ("cloud exchanges 803"). However, other examples of distributed service exchange system architectures may be implemented using different types of distributed SDN or SD-WAN architectures. Each of cloud exchanges 803 may be an example instance of a cloud exchange point 303. Additional details of the distributed cloud exchanges may be found in U.S. patent application Ser. No. 15 / 475,957, entitled "Inter-Metro Connectivity Network Connect," filed on Mar. 31, 2017, the entire contents of which are incorporated herein by reference.

[0112] System 800 includes multiple distributed service peer exchanges 801A-801B ("service peer exchanges 801") that are co-located or otherwise connected within respective data centers 810 and are executed by a distributed service peer exchange platform. In this particular example architecture, service peer exchange 801A is connected to service peer exchange 803A via access link 822A, and service peer exchange 801B is connected to service peer exchange 803B via access link 822B. Access link 822 may represent an example instance of access link 322. Although in Figure 7 Only two service peering exchanges 801 in two data centers 810 are shown, but other examples of the system 800 may include more service peering exchanges 801 located in additional corresponding data centers 810 .

[0113] Distributed service peering exchange 801 operates as a distributed service peering exchange to provide service peering exchange services across multiple locations, enabling applications executing on customer networks at local locations to access services located at remote locations. Service peering exchange 801 includes shared service exchange endpoints 806 for sending and receiving service traffic with customer networks 108 via cloud exchange 803 via access links 822 and communication links 103. Service exchange endpoints 806 can be example instances of service exchange endpoints 106.

[0114] 806C. The service peering exchange 801A includes the service exchange endpoint 806C. The service peering exchange 801A receives a service request 824A (an example instance of the service request 124A) issued by the application 110A at the service exchange endpoint 806C. The service peering exchange 801A responds by outputting a corresponding outgoing service request 824A' directed to the service endpoint 114C on a different customer network 108C to which the destination service exchange endpoint 806A is mapped. In this manner, the service peering exchange 801A enables service-to-service communication between applications executed by customer networks 108 that do not have dedicated direct network layer connections to each other and that are also connected to geographically distributed data centers 810.

[0115] The distributed service peer exchange 801 can monitor the latency between service peer exchanges 801 and expose the latency through API methods. For example, the service gateway 112A can request and receive the latency between the service peer exchange 801A and the service peer exchange 801B via API methods.

[0116] The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof. The various features described as modules, units, or components may be implemented together in an integrated logic device, or separately as discrete but interoperable logic devices or other hardware devices. In some cases, the various features of the electronic circuitry may be implemented as one or more integrated circuit devices, such as an integrated circuit chip or chipset.

[0117] If implemented in hardware, the present disclosure may be directed to an apparatus such as a processor or an integrated circuit device such as an integrated circuit chip or chipset. Alternatively or additionally, if implemented in software or firmware, the technology may be implemented at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, a computer-readable data storage medium may store such instructions for execution by a processor.

[0118] The computer-readable medium may form part of a computer program product, which may include packaging materials. The computer-readable medium may include computer data storage media such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, etc. In some examples, an article of manufacture may include one or more computer-readable storage media.

[0119] In some examples, computer-readable storage media may include non-transitory media. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. In some examples, non-transitory storage media may store data that may change over time (e.g., in RAM or cache).

[0120] The code or instructions may be software and / or firmware executed by processing circuitry including one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the term "processor" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described in this disclosure may be provided within software modules or hardware modules.

Claims

1. A service exchange system, comprising: a service peering exchange configured to be performed by a service peering exchange platform comprising one or more computing devices; as well as A cloud exchange connected to the service peer exchange platform via an access link, wherein the cloud exchange is configured with: a first virtual circuit connecting a first customer network to the service peering exchange via the access link; as well as a second virtual circuit connecting a second customer network to the service peering exchange via the access link, wherein the service peering exchange is configured to receive, at a service exchange endpoint of the service peering exchange via the first virtual circuit, an incoming service request destined for the service exchange endpoint, wherein the incoming service request is capable of invoking an application programming interface for an application configured for execution by the second customer network, and wherein the service peering exchange is configured to, in response to receiving the incoming service request, output an outgoing service request destined for a service endpoint of the second customer network via the second virtual circuit, wherein the outgoing service request is capable of invoking the application programming interface of the application configured for execution by the second customer network. 2 . The service switching system according to claim 1 , wherein the service endpoint of the second customer network comprises a service endpoint of a service gateway.

3. The service exchange system according to claim 1, wherein the service peering exchange is configured to receive service endpoint data describing the service endpoint of the second customer network, in, The service peering exchange is configured to generate an association from the service exchange endpoint to the service endpoint of the second customer network, and wherein the service peering exchange is configured to output the outgoing service request based at least on the association.

4. The service switching system of claim 1, wherein the first customer network does not have network connectivity with the second customer network.

5. The service exchange system according to claim 1, wherein the application includes a service instance of a second application, wherein the incoming service request is initiated by a service instance of a first application configured for execution by the first customer network, in, The service peer exchange further includes a policy specifying whether a service instance of the first application can send service requests to a service instance of the second application, and The service peer exchange is configured to output the outgoing service request to the service instance of the second application in response to applying the policy to the incoming service request to determine that the service instance of the first application can send the service request to the service instance of the second application.

6. The service exchange system according to claim 5, wherein the policy specifies at least one of an allowable frequency of service requests or an allowable number of service requests from the service instance of the first application to the service instance of the second application, and in, The service peer exchange is configured to output the outgoing service request to the service instance of the second application in response to applying the policy to the incoming service request to determine that the incoming service request does not exceed at least one of an allowable frequency of service requests or the allowable number of service requests from the service instance of the first application to the service instance of the second application.

7. The service exchange system of any one of claims 1-6, wherein each of the incoming service request and the outgoing service request comprises one of the following: Representational State Transfer (REST) ​​communication using Hypertext Transfer Protocol (HTTP), JavaScript Object Notation (JSON)-Remote Procedure Call (RPC), Simple Object Access Protocol (SOAP) messages, Apache Thrift requests and Extensible Markup Language (XML)-RPC, Message Queuing Telemetry Transport (MQTT), Rabbit Message Queuing (RabbitMQ), or Constrained Application Protocol (CoAP).

8. The service exchange system according to any one of claims 1 to 6, wherein the service peer exchange is configured to receive a discovery request, the discovery request invoking a discovery application programming interface of the service peer exchange and requesting a service endpoint for accessing the application programming interface of the application, and wherein the service peer exchange is configured to output a discovery response in response to the discovery request, the discovery response indicating that the service exchange endpoint is a service endpoint for accessing the application programming interface of the application.

9. The service exchange system according to any one of claims 1 to 6, wherein the service exchange endpoint comprises a combination of a network layer address and a transport layer port of the one or more computing devices.

10. The service exchange system according to any one of claims 1 to 6, wherein the cloud exchange comprises a layer 3 network located within a data center, wherein the access link comprises a first attachment circuit to an Internet Protocol-Virtual Private Network configured in the cloud exchange for communication between the service peering exchange and the first customer network via the first virtual circuit, and in, The access link includes a second attachment circuit to the Internet Protocol-Virtual Private Network configured in the cloud exchange for communication between the service peering exchange and the second customer network via the second virtual circuit.

11. A method comprising: By a service peering exchange performed by a service peering exchange platform comprising one or more computing devices, the service peering exchange platform being connected to a cloud exchange via an access link, the cloud exchange being configured with a first virtual circuit connecting a first customer network to the service peering exchange via the access link and a second virtual circuit connecting a second customer network to the service peering exchange via the access link: receiving, at a service exchange endpoint of the service peering exchange via the first virtual circuit, an incoming service request destined for the service exchange endpoint, wherein the incoming service request is capable of invoking an application programming interface for an application configured for execution by the second customer network; as well as In response to receiving the incoming service request, outputting an outgoing service request destined for a service endpoint of the second customer network via the second virtual circuit, wherein the outgoing service request is capable of invoking the application programming interface of the application configured for execution by the second customer network.

12. The method of claim 11, wherein the service endpoint of the second customer network comprises a service endpoint of a service gateway.

13. The method according to claim 11, further comprising: receiving, by the service peer exchange, service endpoint data describing the service endpoint of the second customer network, generating, by the service peering exchange, an association from the service exchange endpoint to the service endpoint of the second customer network, and The outgoing service request is output by the service peer exchange based at least on the association.

14. The method of claim 11, wherein the first customer network does not have network connectivity with the second customer network.

15. The method according to claim 11, wherein the application includes a service instance of a second application, and Wherein the incoming service request is initiated by a service instance of a first application configured for execution by the first customer network, the method further comprising: The outgoing service request is outputted by the service peer exchange to the service instance of the second application in response to applying a policy to the incoming service request to determine that the policy specifies that a service instance of a first application can send a service request to the service instance of the second application.

16. The method according to claim 15, wherein the policy specifies at least one of an allowable frequency of service requests or an allowable number of service requests from the service instance of the first application to the service instance of the second application, the method further comprising: The service peer exchange outputs the outgoing service request to the service instance of the second application in response to applying the policy to the incoming service request to determine that the incoming service request does not exceed at least one of the allowable frequency of service requests or the allowable number of service requests from the service instance of the first application to the service instance of the second application.

17. The method of any one of claims 11-16, wherein each of the incoming service request and the outgoing service request comprises one of: Representational State Transfer (REST) ​​communication using Hypertext Transfer Protocol (HTTP), JavaScript Object Notation (JSON)-Remote Procedure Call (RPC), Simple Object Access Protocol (SOAP) messages, Apache Thrift requests and Extensible Markup Language (XML)-RPC, Message Queuing Telemetry Transport (MQTT), Rabbit Message Queuing (RabbitMQ), or Constrained Application Protocol (CoAP).

18. The method according to any one of claims 11 to 16, further comprising: receiving, by the service peer exchange, a discovery request, the discovery request invoking a discovery application programming interface of the service peer exchange and requesting a service endpoint for accessing the application programming interface of the application; as well as A discovery response is output by the service peer exchange in response to the discovery request, the discovery response indicating that the service exchange endpoint is a service endpoint for accessing the application programming interface of the application.

19. The method of any one of claims 11-16, wherein the service exchange endpoint comprises a combination of a network layer address or a transport layer port of the one or more computing devices.

20. The method according to any one of claims 11 to 16, wherein the cloud exchange comprises a layer 3 network located within a data center, wherein the access link comprises a first attachment circuit to an Internet Protocol-Virtual Private Network configured in the cloud exchange for communication between the service peering exchange and the first customer network via the first virtual circuit, and The access link comprises a second attachment circuit for an Internet Protocol-Virtual Private Network configured in the cloud exchange for communication between the service peering exchange and the second customer network via the second virtual circuit.

21. A computer-readable storage medium comprising instructions for causing a processing circuit system of a service peer exchange platform to perform the method according to any one of claims 11-20.

Images