Patent Application
20100254385
Service Insertion Architecture (SIA) provides a platform independent framework for inserting services into a network. A service may be regarded as a feature that performs packet manipulations over and beyond the conventional packet forwarding. For example, a service may be an application that operates at one or more of, layers three (L3) (Network) through seven (L7) (Application). A service may be considered to be an optional function performed in a network that provides connectivity to a network user. Services include, but are not limited to, encryption, decryption, firewall, server load balancing, intrusion management, accounting, and so on. A service may be distributed throughout members of a service path. The members may be referred to as service nodes.
SIA includes a control plane entity that is known as a service broker (SB). Service Nodes register with a service broker and thus a service broker can provide a consistent domain-wide service view. A service may be implemented as a service path. A service path may be organized as an ordered list of path segments, where a segment represents a service feature provided by a service node. A service broker can, therefore, instantiate service paths when service nodes are registered.
A consumer of a service may be referred to as a service classifier (SCL). A service broker can allocate a service path to a consumer when the consumer registers with the broker. A service broker may also distribute information concerning service path segments to service nodes and to consumers to facilitate setting up the data plane for the SIA.
Both an SIA and a VPN have respective data planes and control planes. An SIA may interact with a VPN. When an SIA interacts with a VPN, there may be interactions in both the data planes and control planes at the interfaces between the SIA and the VPN. These interactions may affect a logical forwarding plane for the SIA-VPN combination. For example, when a VPN packet interacts with an SIA, the packet may travel from the packet's VPN forwarding plane to the SIA forwarding plane and then back to the packet's VPN forwarding plane to reach its original destination. When a VPN interacts with SIA, the two forwarding planes may be in two different forwarding domains. For example, the SIA forwarding plane may be in a global forwarding domain while the packet forwarding plane may be in a private forwarding domain.
To illustrate, consider a day in the life of a packet associated with a VPN that interacts with an SIA. The packet will enter the VPN plane, traverse some of the VPN plane, and then exit the VPN plane as it enters the SIA plane. The packet will then traverse an SIA service path using the SIA forwarding plane and ultimately reach the end of the SIA service path. At this point the packet will exit the SIA plane and desire to re-enter the VPN plane. Conventionally it has been difficult, if even possible, to re-enter the VPN plane due to the loss of VPN information that was available when the packet left the VPN plane and entered the SIA plane. The VPN information may not have been available when the packet was ready to leave the SIA plane. Complex signaling protocols may have mitigated some of these issues, but with undesirable and/or unacceptable levels of complexity, processing requirements, and/or timing delays.
In the SIA data plane, a service classifier intercepts certain packets and redirects them onto the service path. The traffic in the service path flows from one service node to another service node and from one service to another service until a final service node is reached. This final service node is responsible for forwarding the packet to its original destination. If the original destination was part of the global forwarding plane, this may be a straightforward task. However, if the original destination was part of a private forwarding plane, conventionally this may have been difficult, if even possible at all.
SIA is described in United States Patent Application US 2008/0177896. One attribute of an SIA is network topology independence. Services may reside at different locations in a network, independent of network path or network node deployment. Another attribute of SIA is inter-service communication. This communication facilitates a state sharing mechanism to path services together and to share information between those services. Another attribute is service topology independence. This attribute concerns how the actual form (e.g., distributed, centralized, clustering) of a service does not matter. SIA also provides consistent administration and management policies. These attributes facilitate SIA redirection, where packets may be redirected to an appropriate service node in a network independent of the physical location of that service node. The packets can be forwarded based on their service header within the SIA service path.
Understanding the SIA data plane functions includes examining classification and SIA context tagging, SIA header insertion, redirection, service selection, and packet forwarding. A service classifier intercepts traffic desiring a service and adds a unique identifier to packets that enter the relevant service path. The unique identifier may be, for example, a service header identifier. The service header identifier may convey the classification context that resulted from the traffic classification. Service nodes in the service path apply service specific policies to packets as a function of information conveyed in the service header. The service header identifier may remain unchanged as a packet traverses a service path.
Redirection occurs at the data plane level as SIA physical devices forward tagged packets to the next physical device in a service path. The SIA physical devices may include service classifiers and service nodes. Ultimately, at the end of the service path, a service node will be responsible for handing a packet to a routing plane. Adding additional information to an SIA packet to facilitate handing the packet to the next routing plane may have included complex signaling protocols and/or updating each member of a service path. This has generally been unacceptable. The redirection performed by service nodes in the service path may rely on transport mechanisms available in an underlying network. Logically and/or physically adjacent peer SIA devices share redirection encapsulation. This redirection encapsulation facilitates carrying SIA traffic for multiple service paths that flow between the logically and/or physically adjacent SIA devices.
Service selection involves forwarding an SIA packet to an appropriate logical service. This action occurs in the SIA forwarding plane. The SIA forwarding plane may be physically and/or logically separate from the service plane where the actual service is performed. The SIA forwarding plane may rely on an SIA header that includes a classification context identifier and a service sequence number. The SIA header may determine the next hop transport encapsulation.
Recall the day in the life of a packet. An SIA packet travels from the packet's forwarding plane to the SIA forwarding plane and back to the packet forwarding plane to reach the original destination known to the packet's forwarding plane. However, when an SIA interacts with a VPN, these two planes are in two different, potentially incompatible, potentially un-resolvable, forwarding domains. The SIA forwarding plane is in a global forwarding plane while the packet forwarding plane may be in a private plane associated with the VPN. Conventional attempts to resolve this issue may have involved complex signaling protocols and/or updating every member of a service path, both of which are sub-optimal.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various example systems, methods, and other example embodiments of various aspects of the invention. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that in some examples one element may be designed as multiple elements or that multiple elements may be designed as one element. In some examples, an element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.
Example systems and methods implicitly encode VPN information in the SIA data plane. VPN information, which is derived at the entry to the SIA plane, is preserved in the packet in the SIA plane and used at the exit from the SIA plane to facilitate forwarding a packet to the original VPN destination. The VPN information may be implicitly encoded by a service classifier device that intercepts the packet and provides it to the service path. The VPN information may be decoded by a service node or a service classifier at the end of a service path and thus at an exit point from the SIA plane. “Implicitly encoding” the VPN information means using a field that would already appear in an SIA packet (e.g., service header) for dual purposes that satisfy both an SIA function and a VPN function.
In one embodiment, a VPN identifier uniquely identifies a VPN in the SIA domain network. The VPN identifier may be, for example, a Global VPN Identifier as described in RFC 2685, a VNET identifier associated with Cisco's Network Virtualization technology, a Route-target as described in RFC 4364, and so on. One skilled in the art will appreciate that different unique VPN identifiers may take different forms and that different unique VPN identifiers may be employed.
In one embodiment, a service broker establishes, maintains, and distributes mappings. A mapping may be between a VPN identifier and a service header. In one example, the traffic classification identifier in the service header may be used to implicitly encode the VPN information. Thus, information concerning the mapping may be stored in the service header. The information can function both as SIA data and as VPN to SIA mapping resolving data. Note that the VPN information need not be the VPN identifier, but rather may be data that facilitates deriving a VPN identifier.
In one embodiment, a service classifier will pass the VPN identifier to a service broker when the service classifier requests a service path as part of registration. The VPN identifier may be part of the VPN configuration and/or classification context. The service broker may allocate a globally distinct service header for a classification context per VPN using the received VPN identifier. The service broker maintains the mapping between the VPN identifier and the service header. The service broker also selectively provides mapping data to service nodes and/or service classifiers. In one example, the service broker may provide VPN identifier to service header mapping data when the service broker distributes path segment information. In one embodiment, the service broker may only distribute VPN identifier to service header mapping data to service path entry points and service path exit points.
A service path entry point may therefore implicitly encode VPN routing information in an SIA packet using the VPN identifier to service header mapping. A service path exit point may decode VPN routing information from the service header using the VPN identifier to service header mapping. While a service path entry point and a service path exit point are described, in the SIA data plane, service nodes and service classifiers may maintain the VPN identifier to service header mapping in, for example, an SIA switching table. When the last service node in a service path receives an SIA data packet, it can be controlled to resolve the VPN identifier to service header mapping to derive corresponding VPN routing information. The VPN routing information may include, for example, VPN forwarding table information.
Since VPN identification information is implicitly encoded in a service header, it may not be necessary to explicitly transmit a VPN identifier, which facilitates simplifying VPN forwarding in an SIA domain. By way of illustration, VPN forwarding may be simplified because the SIA forwarding plane is transparent to VPNs. Therefore, routing may not depend on a VPN label exchange mechanism between physical devices in the SIA domain. By way of further illustration, routing may also not depend on additional information being tagged in an SIA packet for transporting VPN information in the SIA data plane. Therefore the SIA forwarding plane and the service plane implementations become consistent with both VPN and non-VPN cases. By way of further illustration, virtualization is provided in the SIA domain without services actually being aware of VPNs. The service header identifiers are available for virtualization by the services in an SIA domain. Since the services are transparent to VPNs, the services can be shared among multiple VPNs in an SIA domain, greatly improving the efficacy of the service utilization.
One skilled in the art will appreciate that the mapping, encoding, and decoding may be implemented in different combinations of hardware and/or software. For example, in a primarily software based platform the mapping may be maintained in an SIA switching table that stores path segment information for SIA packet switching. In a primarily hardware based platform, mapping, encoding, and/or decoding functions required for this scheme may leverage the existing multi-protocol label switching (MPLS) VPN forwarding information base (FIB) ternary content addressable memory (TCAM) of a forwarding application specific integrated circuit (ASIC). For example, a service header identifier may function as the MPLS label in an MPLS VPN FIB table and can derive the VPN table identifier. A VPN forwarding table can then be selected as a function of the VPN table identifier. One skilled in the art will appreciate that this specific embodiment is but one example and is not intended to be limiting.
In one example, there may be a one-to-one mapping of a service path identifier to a VPN identifier. In another example, there may be a one-to-many mapping of VPN identifier to service path identifiers. For a single VPN identifier, there may be many service path identifiers. The service path identifiers may be, for example, traffic classification identifiers.
While examples have been provided describing how an SIA and a VPN can interact, one skilled in the art will appreciate that a more general use case is available. For example, where there is a central authority that can establish, maintain, and distribute mapping information, it may be possible to implicitly encode information that facilitates routing traffic back onto a first forwarding plane after it has transited a second forwarding plane having potentially incompatible routing data and/or processes. For example, in a client server architecture, clients may be able to talk to each other and may be able to talk to the server. A first logical grouping of clients may route traffic using a first combination of data and processes while a second logical grouping of clients may route traffic using a second combination of data and processes. But some traffic may want to travel over members of both the first logical grouping and the second logical grouping. When the server understands the two combinations of data and processes, the server may implicitly encode information associated with the first combination into data useable by the second combination and vice versa. Thus, the two potentially incompatible combinations may be able to interact without requiring complex signaling protocols. Instead, entry points and exit points associated with the logical groupings may be reconfigured to encode and/or decode mapping information to facilitate re-routing.
Because the encoding of forwarding information is implicit, adaptations to existing platforms may be limited to interfaces between the two logical groupings. At an entry interface, the implicit encoding may occur while at an exit interface decoding of the implicitly encoded information may occur. Since the information is implicitly encoded, intermediate points between an entry point and an exit point may process normally, remaining unaware that any information is implicitly encoded in traffic they are forwarding.
Apparatus 100 may also include an instantiation logic 120. Instantiation logic 120 may be configured to establish the mapping. The mapping may be based, at least in part, on a first unique identifier associated with the first logical group and a second unique identifier associated with the second logical group. In one example, the mapping may be a one-to-one mapping between the first logical group and the second logical group while in another example, the mapping may be a one-to-many mapping between the first logical group and the second logical group. One skilled in the art will appreciate that there are various ways to store both one-to-one and one-to-many mappings. For example, a record in a database may be manipulated, an entry in a table may be manipulated, a set of pointers may be manipulated, and so on. In different examples, the first unique identifier may be a Global VPN Identifier configured according to RFC 2685, a VNET identifier configured according to Cisco Network Virtualization technology, a route-target configured according to RFC 4364, and so on. In one example, the second unique identifier may be a service path identifier. One skilled in the art will appreciate that the mapping is stored as a data and thus establishing the mapping creates a physical transformation in a computer memory.
Apparatus 100 also includes an encoding logic 130. Encoding logic 130 may be configured to implicitly encode information to identify the first logical group in a packet received from the first logical group. The packet can then be provided to the second logical group. Implicitly encoding refers to manipulating a field that would already be present in, for example, the SIA packet, so that it conveys both SIA information and VPN information. For example, an SIA service header may be established that provides information traditionally found in an SIA service header but that also facilitates resolving a VPN to SIA mapping. Thus, the implicitly encoded information is configured to be used without modification by the forwarding plane associated with the second logical group.
Recall that a packet will eventually leave the forwarding plane employed by the second logical group and attempt to re-enter the forwarding plane employed by the first logical group. Therefore, the implicitly encoded information is configured to facilitate a member of the second logical group resolving the mapping. This member would likely be the exit point from the second logical group. This may be, for example, the last service node in a service path. At this point, the SIA packet will be forwarded to a device in the VPN, and thus the mapping facilitates a member of the second logical group forwarding the packet from the second logical group to a receiving member of the first logical group.
In one embodiment, the encoding logic 130 is configured to provide the identifying information to an SIA switching table that is configured to store path segment information for SIA packet switching. The encoding logic 130 may also be configured to store the identifying information in a service header identifier that functions as an MPLS label in an MPLS VPN FIB table. In this embodiment, a member of the second logical group is configured to derive the VPN table identifier from the identifying information in the service header. In one embodiment, a VPN forwarding table is then selectable as a function of the VPN table identifier.
The apparatus 100 is described as having logics. “Logic”, as used herein with reference to figures one through three, includes but is not limited to hardware, firmware, software in execution on a machine, and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system. Logic may include a software controlled microprocessor, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions, and so on. Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
References to “one embodiment”, “an embodiment”, “one example”, “an example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, though it may.
The service classifier 430 may then classify the incoming packet and generate an outgoing packet 490. Packet 490 may include encapsulation information 492, a service header 494, and a payload 496. In one example, the mapping information may be stored in the service header 494. The service header 494 still needs to perform its original role in the SIA forwarding plane. Thus, the service header 494 must still provide information that is known to and useable by members of the service path. The members of the service path are to use this information without having to be modified. Thus, the information is said to be “implicitly encoded” in the service header 494. While in the VPN/SIA path (e.g., 430, 440, 450) the packet may include encapsulation 492, service header 494, and payload 496. While in the pure VPN path (e.g., 410, 420, 460, 470), a packet may include payload 496 and, optionally, some encapsulation. SN 450 hands over a packet to VPN entry point 460. Before handing over the packet, SN 450 may remove SH 494.
Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a memory. These algorithmic descriptions and representations are used by those skilled in the art to convey the substance of their work to others. An algorithm, here and generally, is conceived to be a sequence of operations that produce a result. The operations may include physical manipulations of physical quantities. Usually, though not necessarily, the physical quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a logic, and so on. The physical manipulations create a concrete, tangible, useful, real-world result.
It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, and so on. It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it is appreciated that throughout the description, terms including processing, computing, determining, and so on, refer to actions and processes of a computer system, logic, processor, or similar electronic device that manipulates and transforms data represented as physical (electronic) quantities.
Example methods may be better appreciated with reference to flow diagrams. While for purposes of simplicity of explanation, the illustrated methodologies are shown and described as a series of blocks, it is to be appreciated that the methodologies are not limited by the order of the blocks, as some blocks can occur in different orders and/or concurrently with other blocks from that shown and described. Moreover, less than all the illustrated blocks may be required to implement an example methodology. Blocks may be combined or separated into multiple components. Furthermore, additional and/or alternative methodologies can employ additional, not illustrated blocks.
This embodiment of method 600 also includes, at 630, determining a next hop in the SIA forwarding plane. The next hop is determined, at least in part, as a function of analyzing the VPN-SIA interaction data. This embodiment of method 600 also includes, at 640, determining a next hop in the VPN forwarding plane. This next hop is determined, at least in part, as a function of decoding the VPN-SIA interaction data in the SIA forwarding plane. Thus, the VPN-SIA interaction data serves two roles, one in the SIA forwarding plane and one associated with the VPN forwarding plane. Service nodes employing the SIA forwarding plane do not need to be updated to determine the next hop. Thus, the VPN-SIA interaction data is said to be “implicitly encoded” in the SIA packet.
While
In one example, executable instructions associated with performing a method may embodied as logic encoded in one or more tangible media for execution. When executed, the instructions may perform a method. Thus, in one example, a logic encoded in one or more tangible media may store computer executable instructions that if executed by a machine (e.g., processor) cause the machine to perform method 600. While executable instructions associated with the above method are described as being embodied as a logic encoded in one or more tangible media, it is to be appreciated that executable instructions associated with other example methods described herein may also be stored on a tangible media.
A “tangible media”, as used herein, refers to a medium that stores signals, instructions and/or data. A tangible media may take forms, including, but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and so on. Volatile media may include, for example, semiconductor memories, dynamic memory, and so on. Common forms of a tangible media may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an application specific integrated circuit (ASIC), a compact disk CD, other optical medium, a random access memory (RAM), a read only memory (ROM), a memory chip or card, a memory stick, and other media from which a computer, a processor or other electronic device can read.
“Signal”, as used herein, includes but is not limited to, electrical signals, optical signals, analog signals, digital signals, data, computer instructions, processor instructions, messages, a bit, a bit stream, or other means that can be received, transmitted and/or detected.
“Software”, as used herein, includes but is not limited to, one or more executable instruction that cause a computer, processor, or other electronic device to perform functions, actions and/or behave in a desired manner. “Software” does not refer to stored instructions being claimed as stored instructions per se (e.g., a program listing). The instructions may be embodied in various forms including routines, algorithms, modules, methods, threads, and/or programs including separate applications or code from dynamically linked libraries.
An “operable connection”, or a connection by which entities are “operably connected”, is one in which signals, physical communications, and/or logical communications may be sent and/or received. An operable connection may include a physical interface, an electrical interface, and/or a data interface. An operable connection may include differing combinations of interfaces and/or connections sufficient to allow operable control. For example, two entities can be operably connected to communicate signals to each other directly or through one or more intermediate entities (e.g., processor, operating system, logic, software). Logical and/or physical communication channels can be used to create an operable connection.
Logic 830 may provide means (e.g., hardware, software, firmware) for implicitly encoding data in a packet provided to an SIA by a VPN. The data that is implicitly encoded into the SIA packet is configured to facilitate forwarding in a VPN forwarding plane. Furthermore, the data that is implicitly encoded into the SIA packet is configured to be processed without modification in an SIA forwarding plane. The means may be implemented, for example, as an ASIC programmed to control a router. The means may also be implemented as computer executable instructions that are presented to computer 800 as data 816 that are temporarily stored in memory 804 and then executed by processor 802.
Generally describing an example configuration of the computer 800, the processor 802 may be a variety of various processors including dual microprocessor and other multi-processor architectures. A memory 804 may include volatile memory and/or non-volatile memory. Non-volatile memory may include, for example, ROM, programmable ROM (PROM), and so on. Volatile memory may include, for example, RAM, static RAM (SRAM), dynamic RAM (DRAM), and so on.
A disk 806 may be operably connected to the computer 800 via, for example, an input/output interface (e.g., card, device) 818 and an input/output port 810. The disk 806 may be, for example, a magnetic disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, a memory stick, and so on. Furthermore, the disk 806 may be a CD-ROM drive, a CD recordable (CD-R) drive, a CD rewriteable (CD-RW) drive, a digital versatile disk and/or digital video disk read only memory (DVD ROM), and so on. The memory 804 can store a process 814 and/or a data 816, for example. The disk 806 and/or the memory 804 can store an operating system that controls and allocates resources of the computer 800.
The bus 808 may be a single internal bus interconnect architecture and/or other bus or mesh architectures. While a single bus is illustrated, it is to be appreciated that the computer 800 may communicate with various devices, logics, and peripherals using other busses (e.g., peripheral component interconnect express (PCIE), 1384, universal serial bus (USB), Ethernet). The bus 808 can be types including, for example, a memory bus, a memory controller, a peripheral bus, an external bus, a crossbar switch, and/or a local bus.
The computer 800 may interact with input/output devices via the i/o interfaces 818 and the input/output ports 810. Input/output devices may be, for example, a keyboard, a microphone, a pointing and selection device, cameras, video cards, displays, the disk 806, the network devices 820, and so on. The input/output ports 810 may include, for example, serial ports, parallel ports, and USB ports.
The computer 800 can operate in a network environment and thus may be connected to the network devices 820 via the i/o interfaces 818, and/or the i/o ports 810. Through the network devices 820, the computer 800 may interact with a network. Through the network, the computer 800 may be logically connected to remote computers. Networks with which the computer 800 may interact include, but are not limited to, a LAN, a WAN, and other networks.
While example systems, methods, and so on have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and so on described herein. Therefore, the invention is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims.
To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim.
To the extent that the term “or” is employed in the detailed description or claims (e.g., A or B) it is intended to mean “A or B or both”. When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).
To the extent that the phrase “one or more of, A, B, and C” is employed herein, (e.g., a data store configured to store one or more of, A, B, and C) it is intended to convey the set of possibilities A, B, C, AB, AC, BC, and/or ABC (e.g., the data store may store only A, only B, only C, A&B, A&C, B&C, and/or A&B&C). It is not intended to require one of A, one of B, and one of C. When the applicants intend to indicate “at least one of A, at least one of B, and at least one of C”, then the phrasing “at least one of A, at least one of B, and at least one of C” will be employed.
