Service chaining based on labels in control and forwarding

FIELD

0001Embodiments of the present invention relate to networking.

BACKGROUND

0002Enterprises and Service Providers (SPs) have a common requirement to pass data traffic through certain locations or along certain paths.

0003Existing solutions have the ability to pass traffic through a single location or to tie traffic to a specific path by determining a specific hop-by-hop forwarding path. However, if any service along the path experiences a disruption, then the only remedy is to rely on routing protocols that inherently lack awareness of service locations.

SUMMARY

0004In one aspect there is provided a network system comprising a plurality of service locations, wherein each service location is equipped to make independent forwarding decisions based on policy and wherein a service can be provided in a redundant fashion making the infrastructure aware of where a service is located and how it can be backed up.

0005In a second aspect there is provided a mechanism to allow for several different services to be tied together in a chain.

0006Other aspects of the invention will be apparent from the detailed description below.

BRIEF DESCRIPTION OF THE FIGURES

0007<figref idref="DRAWINGS">FIG. <b>1</b></figref> shows and architecture for achieving service chaining, with emphasis on a control plane, in accordance with one embodiment of the invention.

0008<figref idref="DRAWINGS">FIG. <b>2</b></figref> shows and architecture for achieving service chaining, with emphasis on a forwarding plane, in accordance with one embodiment of the invention.

0009<figref idref="DRAWINGS">FIG. <b>3</b></figref> shows a flowchart of operation for constructing a service chain, in accordance with one embodiment of the invention.

0010<figref idref="DRAWINGS">FIGS. <b>4</b>-<b>5</b></figref> show examples of service chains, in accordance with one embodiment of the invention.

0011<figref idref="DRAWINGS">FIG. <b>6</b></figref> shows a high-level block diagram for an overlay controller, in accordance with one embodiment of the invention.

0012<figref idref="DRAWINGS">FIG. <b>7</b></figref> shows a high-level block diagram of hardware for a router, in accordance with one embodiment of the invention.

DETAILED DESCRIPTION

0013In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block or flow diagram form only in order to avoid obscuring the invention. Accommodate

0014Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearance of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.

0015Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to the details are within the scope of the present invention. Similarly, although many of the features of the present invention are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the invention is set forth without any loss of generality to, and without imposing limitations upon, the invention.

0016Broadly, embodiments of the present invention disclose a service chain construct that may be used to facilitate routing within a network based on service availability within the network.

0017In one embodiment, to realize the service chain construct, network elements may be interconnected across a regular network infrastructure in order to provide an overlay network on top of the regular network infrastructure. <figref idref="DRAWINGS">FIG. <b>1</b></figref> shows an embodiment <b>100</b> of the overlay network. Referring to <figref idref="DRAWINGS">FIG. <b>1</b></figref>, the overlay network <b>100</b> includes an overlay controller <b>102</b>, a mapping server <b>104</b>, and a plurality of overlay edge routers <b>106</b>. The overlay controller <b>102</b> is configured to orchestrate the overlay network <b>100</b> using a secure transport (TLS, Transport Layer Security, IETF RFC5246) and a designated overlay control plane protocol over underlying network infrastructure <b>108</b>. In one embodiment, the network infrastructure <b>108</b> may include a public network such as the Internet. The overlay control plane protocol may operate in a similar fashion to BGP (IETF RFC4271), in functions related to route and policy distribution, reliable transport over TCP (IETF RFC793), and optimal path selection process and distributed state creation.

0018In one embodiment, in order for the overlay control plane protocol to provide a functional architecture, it distributes overlay routes that are learned from each location where an overlay network element is present, together with external addresses used as next-hop addresses for the overlay routes. The external addresses may be assigned to the physical interfaces of the overlay network elements that attach to the underlying network <b>108</b>. In one embodiment, the overlay routes may only be accessed through the overlay network <b>100</b> and the next-hop addresses can only be reached through the underlying network <b>108</b>. Together, the overlay routes and next-hop addresses provide for a complete and functional overlay architecture, as will be explained. As far as the underlying network <b>108</b> is concerned, the only element used to forward traffic between the sites is the next-hop address. The underlying network <b>108</b> does not know about any other routes, addresses or labels that may be used for providing a functional network infrastructure within the overlay network <b>100</b> itself.

0019Secure tunnels are established between the next-hop addresses, which define the elements (hubs or edges) that actually instantiate the overlay network <b>100</b>. The secure tunnels define a control plane, as shown in <figref idref="DRAWINGS">FIG. <b>1</b></figref> Thus, all traffic that use the overlay network <b>100</b> for transport is carried within this topology of tunnels.

0020In one embodiment, within the overlay network <b>100</b>, the overlay controller <b>102</b> processes control plane traffic, but does not get involved in the processing of data traffic. All data traffic is processed by the network elements present at site locations, such as a branch office, or central locations, such as a data center or a headquarters location. These network elements if, at a branch location is referred to as an “edge” and if, at a central location, is referred to as a “hub”. In <figref idref="DRAWINGS">FIG. <b>1</b></figref> hubs are indicated by reference numeral <b>110</b>, whereas edges are indicated by reference numeral <b>106</b>. In one embodiment, secure peer-to-peer links between the hubs and services define a forwarding plane, as shown in <figref idref="DRAWINGS">FIG. <b>2</b></figref>.

0000Providing Services

0021In general, services within a network may be provided at two or more layers. However, the most common layers are User services or Applications, and Network services or Applications. The differentiator between the two is that users will actively interact with user services, such as those provided through a web-browser, where network services are applied to network traffic in a way that is, or at least should be, transparent to the user.

0022Providing applications for user consumption requires the network to carry traffic from the user endpoint to the service endpoint and back. Providing network services requires a direct interaction between the network elements closest to the user, the network elements closest to the service, and traditionally, all the network elements in between. Even with this simplification that removes dependency on the intermediate network, there are still challenges in providing network level services that can be delivered in a way that is transparent to the user. These challenges include:

0023Chaining multiple services together, either in the same or in different locations of the network;

0024Overloading an existing control plane protocol with service information in a way that it was not designed to handle;

0025Minimizing the rerouting and shuffling of network traffic such that it only has to touch the sites where the services required for a given type of traffic are located;

0026Providing different services or chains of services depending on the direction of traffic; Requirements may be different depending on whether the traffic is originating from user location or is destined for a user location

0027Offering different services depending on which virtual domain a given user may be a part of;

0028Providing traffic load distribution across multiple different locations that are providing different instances of the same service;

0029Distributing awareness across the network of which services are available and where the are located;

0000Providing Services in the Overlay Network <b>100</b>

0030An enormous benefit of providing services in an overlay network <b>100</b> is that the network elements sitting in between the user facing elements and the service facing elements do not have to be involved in the delivery of network level services. The entire responsibility of providing the service now rests with network element serving the user location and the network element serving the service location. As used herein the network element serving the user location is referred to as an “edge router or “edge, wherein the network element serving the service location will be referred to as a “hub router” or “hub”.

0031In one embodiment, the overlay controller may be provisioned with or at least have access to traffic policy functions. These traffic policy functions may be distributed to selected hubs and edges and may be used to direct traffic. In one embodiment, the use of labels that identify services and provide for a forwarding tag, allows the overlay network <b>100</b> to overcome all of the previously presented challenges. Labels that represent Virtual Private Networks (VPN) may be combined, in some embodiments, with the Service labels to provide services that are VPN-specific and are reached using VPN-specific policies, versus general overlay network policies for reaching a service identified solely by a service label applicable to the entire overlay network.

0032In each of the locations where a network level service is being provided, which technically could be either an Edge or a Hub location but for the sake of simplicity in the examples are presented as Hub sites, the Hub router is configured with information on which service it is providing and how to reach from a locally configured interface. The hub router will advertise this service using a label that identifies the type of service and how edge routers, by prepending the same label to packets being sent out from their sites, can reach the service. The next-hop address that the hub router uses to connect with the underlying network is also used as the means of actually getting to the same hub site across the intermediate network. This is how an edge router forwarding traffic into the overlay network determines which tunnel to use to reach the intended destination.

0033Services that may exist and provided at the network level include, but are not limited to, the following:

0034Firewall services

0035Intrusion Detection services

0036Traffic scrubbing services

0037Traffic sampling and analytical services

0038Caching

0039Deep Packet Inspection

0040Internet Service

0041Based on the advertisements of routes from each edge and hub router and the advertisements of service labels from each hub router hosting a service, potentially restricted on a per-VPN basis by associating a service-label with a VPN-label, the overlay controller <b>102</b> constructs policies that are subsequently distributed to the network elements (hubs and edges) involved. The set of policies and their required contents are related to the exact nature of the service chain that is being constructed. Two examples are provided below.

Example 1: Simple Service-Chain with Only a Single Service

0042The setup for this service and network infrastructure is the following:

0043A router in a hub location, Hub2 advertises a service with a Label of 1 and a Service-type of Firewall (see <figref idref="DRAWINGS">FIG. <b>1</b></figref>). The steps in creating the service chain are shown in <figref idref="DRAWINGS">FIG. <b>4</b></figref>.

0044The network administrator decides that all traffic going to and from the Internet must pass through the firewall service

0045The Internet entry and exit point is through a hub router referred to as Hub3, which could be advertised as a service but not in this example, for reasons of simplicity.

0046Each Edge location is equipped with the necessary routing information required to determine if traffic must be sent to the Internet or not.

0047The setup and distribution of policies will take place as follows:

0048Block <b>400</b>: Hub2 advertises Service information: (Service-Type, Label) to the controller <b>102</b>.

0049Block <b>402</b>: The overlay controller <b>102</b> constructs the set of required policies and distributes them accordingly. This means that each node involved will be assigned a policy for managing the required traffic flow.

0050Block <b>404</b>: Every Edge-router receives an outbound policy (for traffic towards the Internet) stipulating that all the traffic matching the routes received from Hub3, will be encapsulated in a packet with a Service-label of 1, matching the Firewall Service, and a next-hop address of Hub2. This will ensure all traffic destined for the Internet is using the tunnel from the Edge-router to Hub2

0051Block <b>406</b>: The controller <b>102</b> creates a policy (in) for Service Locations: For received Traffic arriving tagged with Service-Label, forward traffic to service-element and advertises the policy thus created to each hub.

0052Block <b>408</b>: Hub2 receives an inbound policy (for traffic received on its external interface), stipulating that all received traffic matching Service Label 1 is sent to the firewall. Exactly how the traffic is forwarded is a local decision.

0053Block <b>410</b>: Hub2 receives an outbound policy (for traffic received from the Firewall) stipulating that the traffic destined for the Internet must be encapsulated with a next-hop address of Hub3, taking the traffic to the Internet. Any traffic destined for an Edge-router in the overlay network is sent with an encapsulation of that Edge-routers next-hop address

0054Block <b>412</b>: Hub3 receives an inbound policy (for traffic received from the Internet) stipulating that all traffic matching a destination advertised from an Edge-router is encapsulated in a packet with a Service-label of 1, matching the Firewall Service, and a next-hop address of Hub2

Example 2: Two Services are Chained Together

0055Using the same setup as in the prior example, but adding that all traffic returning from the Internet must not only pass through the Firewall Service, but also pass through an Intrusion Detection Service, the modification required to the infrastructure is the following:

0056Hub1 hosts the Intrusion Detection service and advertises a service with a Label of 2 and a Service-type of Intrusion Detection.

0057The changes in setup and distribution of policies is following:

0058Hub2, hosting the firewall service, has one addition to its outbound policy. All traffic destined for any Edge-router in the overlay network must be encapsulated with a Service-label of 2 and a next-hop address of Hub1.

0059Hub1 is equipped with policies identical to what Hub2 had in the previous example, with the differences being that the label matching is done on Service-label 2 for inbound traffic. <figref idref="DRAWINGS">FIG. <b>5</b></figref> shows a flowchart corresponding to this example of service chaining. Referring the <figref idref="DRAWINGS">FIG. <b>5</b></figref>, C1 to C3 are conditions and the processing blocks are as provided below:

0060Block <b>500</b>: Edge1 receives a packet destined for Network Entry/Exit point. Local policy tells Edge1 that the path to reach Hub3 is through Hub2

0061Block <b>502</b>: Edge1 encapsulates the packet with information containing the address of Hub2 and the Label for the Service at Hub2, then sends it off.

0062Block <b>504</b>: Hub2 receives the packet from Hub2 with the Service-label. The service label is removed and forwarded to the service-element.

0063Block <b>506</b> Hub2 later receives the packet from the service-element. Local policy dictates that traffic destined for Hub3 should use the address of Hub3.

0064Block <b>508</b> Hub2 encapsulates the packet with information containing the address of Hub3, then sends it off.

0065Delivering on Other Requirements

0066The list of requirements presented earlier had several attributes that were not covered in the previous examples. The facilities used to deliver on those requirements are all present in this architecture and are used in the following ways to ensure that all requirements can be met

0067For purposes of clarity, the control plane protocol used in this architecture is designed to distribute routing information, policy information and labels. By overloading the labels with inherent representations of services, information on services can be distributed without any modifications to the protocol itself.

0068The rerouting and reshuffling of traffic and control information is avoided entirely by making this service-chaining architecture policy driven and decoupled from the underlying forwarding plane represented by the intermediate underlying network.

0069By adding VPN-designations to the service attachments points, services can be delivered on a per-VPN basis. This requires the use of a label-stack where one label represent the VPN and another label represents the service. Alternatively, and at a higher administrative cost, service-labels can be assigned in VPN-specific ranges to avoid the use of a label-stack.

0070If traffic-load distribution is desired, then multiple service-locations can advertise the same service-type using identical labels, which would allow for each ingress Edge-router to distribute load across the set of service-sites based on some condition that is inherently defined or decided by policy.

0071Associating services with Service-type designators and associating them with the external addresses of Hub-locations, provides inherent location and service-availability awareness. This could be further augmented by geo-location information or other more specific location-related attributes.

0072Establishment of a Service Chain

0073In one embodiment, to a method for establishing a service chain is shown in <figref idref="DRAWINGS">FIG. <b>3</b></figref>. Referring to <figref idref="DRAWINGS">FIG. <b>3</b></figref>, the method includes the following blocks:

0074Block <b>300</b>: The overlay controller <b>102</b> establishes secure control channel with all associated network elements (hubs and edges).

0075Block <b>302</b>: The service-hosting locations (hubs) advertise their service type and associated label to the overlay controller <b>102</b>.

0076Block <b>304</b>: The overlay controller <b>102</b> uses the service information received when constructing policies for the edge routers that are to use them.

0077The central controller can either:

0078Apply the service policy to overlay routes before sending those to edge nodes with overlay next hop and label changed to that of service.

0079Block <b>306</b>: The central controller pushes the service policies to the edge routers. These policies link traffic to the ultimate destination with a service chain.

0080Block <b>308</b>: The central controller can also push policies to the service hosting routers, instructing them of their role in a given service chain and how to forward inbound and outbound traffic related to each VPN and each Service.

0081Policy Construction and Information Distribution

0082In one embodiment, the controller <b>102</b> has the option of building a policy involving a service chain in two different ways:

00831) The services along with the policies are both advertised to the edge routers that are to use them.

00842) Services are advertised service nodes to the controller. Controller then uses the policy to resolve the overlay routes over service routes. It then advertises the resolved overlay routes to those edge nodes that are provisioned to receive those routes.

0085In the first option, policies can be implemented that takes the availability, capacity, latency, location and other aspects of the service chain into account and gives each edge router the awareness to select the most optimal service chain. In the second option, the edge routers are kept unaware of that they are using a service chain and simply operate based on the information they have been provided for the purpose of forwarding traffic.

0000Service Identification

0086In one embodiment, a service route, service label, service identifier and transport location (TLOC) identify each service. Specific service chains are established by policy and do not require any additional information to be distributed for traffic to flow along the path instantiated by the creation of the service chain. The Service Route is distributed for identification purposes only and is not used for forwarding.\

0000Traffic Forwarding in the Service Chain

0087In one embodiment, each edge node uses existing destination routes that are given a next-hop TLOC pointing to the entry point of a service chain. This route to TLOC assignment can be done by the central controller as a way of enforcing central service-chain policy, or by edge router when enforcing policies either distributed by the central controller or created locally on the device.

0088In one embodiment, each service router in the path of a service chain accepts inbound traffic based on the destination TLOC and VPN Label in the received packet and forwards it out the associated interface for the specific service being associated with the TLOC/Label combination. In the outbound direction, each service router must be equipped with policy describing what the next hop is for the particular destination. This allows for each service router to support multiple service chains and different policies for each direction of traffic. Since the outgoing direction is controlled by policy, this allows for great flexibility in choosing the next point in the service chain based on individually defined criteria for that service chain, service, or service router.

0089The service chaining architecture and method described above provides the following benefits:

0090Bidirectional Service Chains:

0091The service chaining architecture provides for the ability to create both unidirectional and bi-directional service chains simply by means of policy with no requirement to advertise additional routing information or labels.

0092Service Chain Eligibility:

0093The service chaining architecture is inherently aware of which services are present in a fully functional service chain. This awareness allows for the ability to qualify the eligibility of each specific service chain as the nature of each chain might change during the course of providing service. If crucial service may fail then the service chain could be taken out of service whereas the failure of non-crucial service could render the chain to operate either uninterrupted or with lower priority versus other available chains.

0094Service-Type Awareness:

0095The service type is included in the advertisements from each service location and allows for each hop in a service chain, inclusive of ingress and egress points, to make decisions of which specific instance of a given service-type to use. Deciding factors can include capacity, location, current load and other influential characteristics.

0096Service any Casting:

0097Each hop in a service chain is equipped to make decisions of which instance of a given service to use at any time. This is strongly linked to the service-type awareness claim but does not have to be. Redundancy through any casting can also be linked to capacity, location, current load and other influential factors aside from service-type.

0098Primary and Backup Service Locations:

0099Policies pushed by the central controller can be used to dictate primary and secondary, or backup, locations where a given service is being provided. This further extends the Service-type awareness function described above. The switch from a primary to a backup service can be decided upon and pushed by the central controller, or through previously defined and pushed policy, take place at the edge router upon detection of pre-defined failure conditions.

0100Equal and Unequal Cost Load-Balancing:

0101Centrally defined and pushed policies can also influence how traffic is distributed across multiple sites providing the same service for the purpose of explicitly equal cost load-balancing, or if desired, using weights to achieve unequal cost load-balancing.

0102Centrally defined and pushed policies can also influence how traffic is distributed across multiple sites providing the same service for the purpose of explicitly equal cost load-balancing, or if desired, using weights to achieve unequal cost load-balancing.

0103Centrally Administered and Provisioned Service Chains:

0104The service chaining concept described has the distinct advantage that the entire function can be provisioned from a central controller location without having to perform and specific per edge-node configuration or provisioning. As soon as the policy creation is complete on the central controller and services have been made available and linked with the defined policies, edge-nodes that are to use a defined service chain are triggered to do so by the central controller. For convergence between service locations, changes in current service chain or service site affiliation, or service chain eligibility, decisions and changes can be taken and executed upon by the central controller, the edge node, or both. How these actions are performed depend on how the policies were constructed at the central controller. This claim however, does not limit the provisioning or operation of a service chain that is partially performed by the central controller and augmented by service routers or edge routers.

0105<figref idref="DRAWINGS">FIG. <b>6</b></figref> shows an example of hardware <b>600</b> that may be used to implement the overlay controller <b>102</b>, in accordance with one embodiment. The hardware <b>600</b> may includes at least one processor <b>602</b> coupled to a memory <b>604</b>. The processor <b>603</b> may represent one or more processors (e.g., microprocessors), and the memory <b>604</b> may represent random access memory (RAM) devices comprising a main storage of the hardware, as well as any supplemental levels of memory e.g., cache memories, non-volatile or back-up memories (e.g. programmable or flash memories), read-only memories, etc. In addition, the memory <b>604</b> may be considered to include memory storage physically located elsewhere in the hardware, e.g. any cache memory in the processor <b>602</b>, as well as any storage capacity used as a virtual memory, e.g., as stored on a mass storage device.

0106The hardware also typically receives a number of inputs and outputs for communicating information externally. For interface with a user or operator, the hardware may include one or more user input output devices <b>606</b> (e.g., a keyboard, mouse, etc.) and a display <b>608</b>. For additional storage, the hardware <b>600</b> may also include one or more mass storage devices <b>610</b>, e.g., a Universal Serial Bus (USB) or other removable disk drive, a hard disk drive, a Direct Access Storage Device (DASD), an optical drive (e.g. a Compact Disk (CD) drive, a Digital Versatile Disk (DVD) drive, etc.) and/or a USB drive, among others. Furthermore, the hardware may include an interface with one or more networks <b>612</b> (e.g., a local area network (LAN), a wide area network (WAN), a wireless network, and/or the Internet among others) to permit the communication of information with other computers coupled to the networks. It should be appreciated that the hardware typically includes suitable analog and/or digital interfaces between the processor <b>612</b> and each of the components, as is well known in the art.

0107The hardware <b>600</b> operates under the control of an operating system <b>614</b>, and executes application software <b>616</b> which includes various computer software applications, components, programs, objects, modules, etc. to perform the techniques described above.

0108In general, the routines executed to implement the embodiments of the invention, may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects of the invention. Moreover, while the invention has been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of machine or computer-readable media used to actually effect the distribution. Examples of computer-readable media include but are not limited to recordable type media such as volatile and non-volatile memory devices, USB and other removable media, hard disk drives, optical disks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks, (DVDs), etc.), flash drives among others.

0109<figref idref="DRAWINGS">FIG. <b>7</b></figref> shows a block diagram of hardware <b>700</b> for edge routers and hubs describe above, in accordance with one embodiment of the invention. Referring to <figref idref="DRAWINGS">FIG. <b>7</b></figref>, the hardware <b>700</b> includes a routing chip <b>704</b> coupled to a forwarding chip <b>708</b>. The routing chip <b>704</b> performs functions such as path computations, routing table maintenance, and reachability propagation. Components of the routing chip include a CPU or processor <b>704</b>, which is coupled to a memory <b>706</b>. The memory stores instructions to perform the methods disclosed herein. The forwarding chip is responsible for packet forwarding along a plurality of line interfaces <b>710</b>.

0110Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that the various modification and changes can be made to these embodiments without departing from the broader spirit of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than in a restrictive sense.