Patent Application
20070211716
This Application is related to U.S. patent application Ser. No. ______ ______ by M. Khouderchah et al., filed on ______ , entitled “Managing Traffic Within and Between Virtual Private Networks When Using a Session Border Controller,” with Attorney Docket No. CSCO-13125, assigned to the assignee of the present invention, and hereby incorporated by reference in its entirety.
Embodiments of the present invention pertain to communication networks, and virtual private networks in particular.
A virtual private network (VPN) is an example of a private communication network. A VPN emulates a private, Internet Protocol (IP) network using shared or public network infrastructures such as the Internet. One type of VPN is implemented by configuring network devices (e.g., switches and routers) to establish a private, encrypted “tunnel” over a public network in order to secure VPN traffic against public access.
A VPN may encompass a number of virtual local area networks (VLANs). A VLAN consists of a network of computers or like devices, which behave as if they are connected to the same local wire but in fact may be in different locations (e.g., in different buildings, or even in different cities). Thus, devices may be a part of the same VPN although separated by large distances. A device such as a computer or a voice-over-IP (VolP) phone can be identified as a member of a particular VLAN using a VLAN tag prescribed according to, for example, IEEE 802.1 Q.
Session border controllers (SBCs) are used to provide services and to implement policies in VolP communication networks. An SBC may be used, for example, to enable VolP calls to be made to and from VPNs, from VPNs to a public switched telephone network (PSTN), or between phones that use different VolP protocols.
An SBC may serve multiple VPNs, performing different services and implementing different policies for each. Also, the services performed and policies implemented by an SBC may depend on whether or not the traffic will remain within the VPN. Accordingly, it can be important to identify whether or not the calling and called parties are members of the same VPN and, if so, which VPN.
Currently, VLAN tags are used to associate traffic with a particular VPN. Each SBC is configured with mapping tables to map VLAN tags to VPN customer identifiers (IDs). The mapping tables are needed because VLAN tags are not globally unique, and so multiple SBCs may have different VLAN tags associated with the same VPN customer. Using the mapping tables, an SBC can determine whether the calling and called parties belong to the same VPN.
A problem with the conventional approaches is the effort needed to create and update the mapping tables on each of the SBCs in a VolP network. The present invention provides a novel solution to this problem.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:
In the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be recognized by one skilled in the art that the present invention may be practiced without these specific details or with equivalents thereof. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
Some portions of the detailed descriptions, which follow, are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits that can be performed on computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, computer executed step, logic block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. 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, or the like.
It should be borne in mind, however, that all of 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 as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “receiving,” “accessing,” “directing,” “associating,” “embedding,” “forwarding” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The device 118 may be a member of one VLAN, and the device 128 may be a member of another VLAN. However, the present invention is not limited to any particular network architecture, such as VLANs, nor to any particular transport function or standard. That is, connections between devices can be accomplished using, for example, Asynchronous Transfer Mode (ATM), Transmission Control Protocol/Internet Protocol (TCP/IP), Synchronous Optical Network (SONET), Frame Relay (FR) protocol, or any other signal or connection format.
In the example of
The network 102 can include any number of network routing devices. One or more session border controllers (SBCS) may be implemented on any of the routers. Alternatively, one or more SBCs may be implemented on a separate device that is coupled to a router. In one embodiment, an SBC is implemented in hardware, as a linecard, for example. In another embodiment, an SBC is implemented in software. A combination of hardware and software may also be used. SBCs are described further in conjunction with the figures below.
Continuing with reference to
For example, the services or policies implemented by an SBC can depend on whether or not the devices 118 and 128 are members of the same VPN. If an SBC determines that the devices 118 and 128 are not members of the same VPN, then certain services or policies may be implemented by the SBC. On the other hand, if an SBC determines that the devices 118 and 128 are members of the same VPN, a different set of services and policies may be implemented by the SBC. In some instances, the services and policies implemented by the SBC may not be needed, and consequently the SBC may be bypassed. Bypassing an SBC can reduce processing overhead and shorten the communication path.
For example, consider an SBC that provides a protocol translation service to enable a call between two networks or devices that use different VoIP protocols. If the calling and called parties use the same VolP protocol, the protocol translation service of the SBC is not needed. If no other SBC-implemented services or policies are needed, the call traffic may bypass the SBC.
In one embodiment, call traffic includes both a signal stream portion and a media stream portion. The signal stream includes, for example, information for call control functions, based on signaling protocols such as, but not limited to, Session Initiation Protocol (SIP), International Telecommunications Union (ITU) standard H.323 or H.248, or Media Gateway Control Protocol (MGCP). The media stream includes, for example, audio (voice) and/or video data, such as, but not limited to, RTP (Real Time Protocol) or RTCP (Real Time Control Protocol) streams for voice or video codecs. The signal and media streams are separable from each other. In general, the signal stream precedes the media stream—the signal stream is used to establish a connection between the calling and called parties, and once the connection is established, the media stream can be initiated.
Therefore, to be more specific with regard to the foregoing discussion, an SBC can receive and act on the signal stream associated with a particular call, while the media stream associated with the call either may be directed to (through) that SBC or may bypass that SBC. That is, generally speaking, the signal stream for a call will always pass through an SBC, while the media stream for a call may or may not bypass that SBC.
Consider again the example above of an SBC that provides a protocol translation service to enable a call between two networks or devices that use different VolP protocols. If the calling and called parties use the same VolP protocol, the protocol translation service of the SBC is not needed. If no other SBC-implemented services or policies are needed, the media stream associated with the call may bypass the SBC, although the signal stream associated with the call will pass through the SBC.
In general, the practice in which the media stream bypasses an SBC is referred to as “VPN optimization” or “media optimization,” and is generally referred to herein as “optimization.” More specifically, in some embodiments, optimization means that an SBC does not modify the session description portion of the SIP, MGCP, H.323 or H.248 signaling to force RTP or RTCP traffic through the SBC when traffic remains within the VPN. As will be seen, it is also possible to perform optimization on certain subnets within a VPN, while not optimizing other subnets.
According to embodiments of the present invention, SBC 230 is configured with a number of “virtual interfaces” (VIs) exemplified by a first VI 232 and a second VI 234. The VIs 232 and 234 may also be referred to as service virtual interfaces. Generally speaking, a virtual interface is a point on the communication path that receives and evaluates traffic. More generally, a virtual interface is an element that has, but is not limited to, the functionality described below.
In configuring the virtual interfaces, VI 232 is associated with a particular VPN (e.g., VPN1) and VI 234 is associated with another VPN (e.g., VPN2). As such, all traffic from VPN1 with destination prefixes assigned to VI 232 is directed to VI 232. Other VPN1 traffic with different destination prefixes is routed as usual, without passing through VI 232. Similarly, all traffic from VPN2 with destination prefixes assigned to VI 234 is directed to VI 234.
According to embodiments of the present invention, a virtual interface and VPN are associated with each other by associating a unique VPN identifier (ID) with the virtual interface. In one embodiment, the unique VPN identifier is a globally unique “VPN-ID” specified according to RFC 2685. In another embodiment, the unique VPN identifier is a “VRF-name” (the VPN routing and forwarding name used by routers). In yet another embodiment, both a VPN-ID and a VRF-name are used.
A VPN-ID is suitable (unique) for inter-autonomous system (AS) traffic as well as intra-AS traffic, while a VRF-name is suitable (unique) for intra-AS traffic. In general, an autonomous system is a collection of IP networks and routers, perhaps under the control of one entity (e.g., a carrier or an Internet service provider), that presents a common routing policy to the Internet. “Intra-AS” refers to, for example, traffic within a particular carrier or provider network, while “inter-AS” refers to, for example, traffic across carrier/provider networks.
Significantly, by using a unique VPN identifier (e.g., a VPN-ID and/or a VRF-name) to identify a VPN, and by configuring a virtual interface to automatically associate traffic that it receives with that unique VPN identifier, the mapping tables that are conventionally used to map VLAN tags to customer IDs can be eliminated. Furthermore, because call traffic 202 is separable into a signal stream 204 and a media stream 206, the VPN-ID can be embedded in the signal stream 204 and/or used by an external control protocol (e.g., a protocol based on ITU H.248) to eliminate mapping tables from both the media and the signaling blocks (e.g., in “softswitches”).
In one embodiment, a virtual interface receives traffic from only a single VPN (one-to-one mapping of VPN to VI). In another embodiment, a virtual interface receives traffic from more than one VPN (many-to-one mapping of VPNs to VI). In the latter embodiment, a virtual interface can be configured to map a particular subset of destination prefixes or IP addresses (subnet) to a particular VPN. Accordingly, the virtual interface can distinguish traffic from one VPN versus traffic from another VPN by looking at, for example, the subnet associated with the incoming traffic. A VPN can receive traffic from any number of virtual interfaces.
With reference to
In one embodiment, the router 200 performs a Layer 3 (L3) lookup based on information in the signal stream 204. “Layer 3” refers to the network layer of the well known OSI (Open System Interconnection) model. The L3 lookup identifies the appropriate virtual interface to which the call traffic 202 is to be directed. In the example of
Continuing with reference to
To summarize, in one embodiment, an SBC 230 on (or coupled to) a router 200 is configured with virtual interfaces 232 and 234 that belong to VPN1 and VPN2, respectively. Each of the VIs 232 and 234 is configured with a unique VPN identifier such as a VPN-ID and/or a VRF-name. The SBC 230 automatically associates the virtual interfaces, which are unique to SBC 230, to the respective unique VPN identifiers, which are either unique within the network (in the case of VPN-IDs) or unique within an autonomous system (in the case of VRF-names). When traffic is routed to SBC 230 from a particular VPN, that traffic is routed to the particular virtual interface associated with that VPN, and in this manner the virtual interface uniquely identifies the VPN customer. Thus, SBC 230 is made VPN-aware without a mapping of VLAN tags to VPNs.
In one embodiment, SBC 230 embeds the unique VPN identifier in the signal stream 204 of the call traffic 202. In essence, the call traffic 202 is stamped with the unique VPN identifier. Consequently, other SBCs downstream of SBC 230, as well as other network elements—such as softswitches—downstream of SBC 230, are made aware of the VPN that is the source of the call traffic 202.
The unique VPN identifier can be embedded as a cookie in the signal portion 204. Other mechanisms can be utilized to include the unique VPN identifier in the call traffic 202. For example, the various signaling protocols, such as but not limited to SIP, ITU H.323, ITU H.248 and MGCP, include existing fields in the signal stream 204 that are available or can be modified to include the unique VPN identifier.
In one embodiment, SBC 230 performs an appropriate media-related service or implements an appropriate policy. In addition to the examples already mentioned herein, examples of media-related services include, but are not limited to, transcoding, network address translation (NAT), encryption, inter-VPN connectivity, and dual tone multi-frequency (DTMF) detection.
In the example of
Continuing the example of
As previously described herein, a virtual interface 232 is configured on SBC 230 and another virtual interface 341 is configured on SBC 340. In the present embodiment, signal stream 204 of call traffic 202 (
Depending on the configured policies on SBC 230 and SBC 340, the media stream 206 can be controlled through modification of the signal stream 204 prior to initiation of the media stream 206. If VPN/media optimization is deemed to be required, then the media stream 206 bypasses both SBCs 230 and 340. However, if VPN/media optimization is not required, then the media stream 206 passes through one or both of the SBCs 230 and 340.
To summarize, if the source and destination of the call traffic are terminated on different SBCs that serve the same VPN, either of the SBCs can perform optimization. If the traffic traverses one or more entities (e.g., a softswitch or an SIP proxy) before reaching the downstream SBC (e.g., SBC 340), the unique VPN identifier embedded in the signal portion of the traffic will be passed through those entities so that the downstream SBC (e.g., SBC 340) can be made aware of the source of the call, can determine whether the source and destination are in the same VPN, and can make a decision with regard to optimization.
In block 410 of
In block 420, the virtual interface receives traffic from a source in the VPN. In one embodiment, the traffic includes a signal portion and a media portion, where the signal portion and the media portion are separable. In another embodiment, the traffic is associated with a VolP call.
In block 430, the virtual interface associates the traffic with the unique identifier. As such, the virtual interface identifies the source of the traffic as being in the VPN mentioned above in connection with block 410.
In block 440, in one embodiment, the unique identifier is embedded in the signal portion of the traffic. The signal portion of the instance of traffic can be forwarded to another network element, perhaps another SBC.
In block 450, the unique identifier is used to determine whether the source of the traffic and the destination of the traffic are in the same VPN. Depending on the result of this determination, and depending on the policy in place, the media portion of the traffic is either directed to the SBC or will bypass the SBC. As previously described herein, the decision on whether the SBC is bypassed or not may be made by a downstream SBC and communicated back to the upstream SBC.
In block 510 of
In block 520, the unique identifier provided in the signal portion is used to determine whether the source and destination of the VPN are in the same VPN.
In block 530, in one embodiment, the media portion of the instance of traffic is directed to the SBC if the destination is not in the same VPN as the source.
In block 540, in one embodiment, the media portion bypasses the SBC if the destination is in the same VPN as the source.
Returning to block 520, as mentioned above, the determination as to whether the source and destination are in the same VPN can be made by one SBC and communicated to another SBC. Likewise, either of the SBCs may receive the media portion for processing.
Although specific steps are disclosed in flowcharts 400 and 500 of
In summary, embodiments in accordance with the present invention provide a friendly solution for configuring SBCs so that the SBCs are made VPN-aware without the complication and overhead of mapping tables.
Embodiments of the present invention are thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the below claims.
