|Publication number||US7969981 B2|
|Application number||US 12/202,454|
|Publication date||Jun 28, 2011|
|Priority date||Sep 2, 2008|
|Also published as||US20100054245|
|Publication number||12202454, 202454, US 7969981 B2, US 7969981B2, US-B2-7969981, US7969981 B2, US7969981B2|
|Inventors||Rajiv Asati, Yiqun Cai, Mohamed Khalid|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (15), Referenced by (8), Classifications (8), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention relates in general to the field of communications and, more particularly, to a system and a method for multicasting in an Internet Protocol virtual private network environment.
Network operators may seek to offer multicast based network services such as broadcast video, file sharing etc. to their end users. Multicast enabled networks usually employ a multicast routing protocol such as Protocol Independent Multicast (PIM) to build the multicast tree (such that the multicast source becomes the root and the multicast receivers become the leaves of the tree) in the network.
A Virtual Private Network (VPN) is a logical network that uses shared network infrastructure, such as the Internet, to provide dedicated and optionally secure communications to members of the VPN. A VPN may maintain privacy through agreed upon security procedures and protocols. Essentially, a VPN uses custom encryption to encrypt messages communicated via the VPN. The encryption and decryption of messages rely upon keys that are securely held by participants of the VPN.
A Dynamic Multipoint virtual private network (DMVPN) is an enhancement of the virtual private network (VPN) configuration process for routers. DMVPN makes use of Internet Protocol (IP) tunneling technique such as Generic Route Encapsulation (GRE) to tunnel the VPN traffic through the shared network infrastructure. A tunnel between two spoke routers may be created on an as needed basis. This alleviates the need for the hub router to route ‘unicast’ data between spoke networks, as was common in a non-fully meshed frame relay topology. However, this is not applicable to ‘multicast’ data.
Usage of multicasting in current DMVPN framework is limited to ‘hub and spoke’ topology by which the multicast traffic always involves the hub. While the current framework satisfies the general needs of a given networking model, using a non-broadcast multi-access (NBMA) technique puts a significant replication load on the hub router(s), particularly when the multicast source is located in a spoke site. Accordingly, the ability to minimize this load or to optimize these communications in the context of multicasting activities presents a significant challenge to network administrators, component manufacturers, and system designers alike.
To provide a more complete understanding of the present invention and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, wherein like reference numerals represent like parts, in which:
A method is provided in one example implementation and includes sending a PIM join message to the second spoke router by the hub router. The second spoke router dynamically determines each interested remote spoke router by parsing a hub-sent PIM message and accordingly constructs the multicast routing entry such that the first and second spoke routers establish multicast communication independent of a hub router. In more specific embodiments, the PIM join/prune messaging includes a list of each downstream spoke router that sent a PIM join/prune, in a new attribute. The PIM join/prune message is sent by the hub router towards a multicast source. A new receiver-list attribute is created that the hub router populates with a non-broadcast multi-access (NBMA) address for each interested spoke router.
The receiver-list attribute is used by the spoke router to formulate the outgoing interfaces for each multicast route entry. Additionally, a multicast route entry may be provided with the same incoming interface (IIF) and outgoing interface (OIF), whereby multicast traffic is received on a multi-point IP tunnel interface with Generic Routing Encapsulation (mGRE) and is forwarded on the same IP tunnel interface.
Also provided in
In accordance with teachings of the present invention, communication system 10 can enable the DMVPN spoke router to dynamically determine the interested remote spokes by parsing the hub-sent enhanced protocol independent multicast (PIM) join/prune message and then constructing the related OIF of the prescribed source (S), group (G) multicast route (mroute) for each interested remote spoke. This innovation allows for spoke-to-spoke (any-to-any) multicasting in DMVPN, where the hub router does not need to be in the multicast-forwarding path. It further offers a cooperative multicasting support, where the hub and spoke routers together can share the multicast replication load.
Such an architecture further affords the ability to specify which spoke is to receive multicast traffic directly from another spoke and for what (S,G) multicast route. Furthermore, the innovation requires: a) no IGP routing protocol adjacency between spokes; b) no PIM adjacency between spokes; and c) no changes to the unicast routing table and forwarding; d) no changes to or reliance on NHRP. Additionally, there is independent control for unicast and multicast traffic for this concept. Finally, such a solution assists a DMVPN operator to readily upgrade the spoke site routers to achieve many of these benefits.
Before turning to some of the components of embodiments of the present invention, some preliminary information about typical DMVPN protocols is provided. The following foundational information may be viewed as a basis from which the present invention may be properly explained. Such information is offered earnestly for purposes of explanation only and, accordingly, should not be construed in any way to limit the broad scope of the present invention and its potential applications.
DMVPN is one of the widely deployed technologies by enterprises. DMVPN enables the enterprise VPN sites to communicate with each other in any-to-any fashion over an IP cloud that may be either a public network (such as Internet) or a private network (such as the MPLS VPN cloud). Any-to-any communication (i.e., Spoke-to-Spoke communication) is achieved by having a VPN site be aware of only the hub site through provisioning and dynamically discovering the remote VPN sites. Moreover, the network resources such as tunneling, cryptography material etc. for any-to-any communication are utilized only when they are needed.
Commonly, a DMVPN spoke is configured with one or more hub IP addresses. DMVPN hub IP addresses are typically static, such as at a corporate headquarters. DMVPN spoke IP addresses may be static, or dynamic. An example would be a DMVPN spoke router acting as a Dynamic Host Control Protocol (DHCP) client on a digital subscriber line (DSL) or cable provider's network. The spoke router is configured with the hub's IP address, allowing it to connect when online. The hub router does not need to be configured with the IP addresses of the spoke routers. This allows many-spoke VPN routers to be deployed without the need to configure additional peers on the hub(s). In the past, the configuration of the hub grew whenever a spoke VPN router was added to the DMVPN network. One of the benefits of DMVPN is that it requires the IP cloud to be capable of only unicasting, to support both unicasting and multicasting. Stated otherwise, to support multicasting in DMVPN, the DMVPN framework does not require the public or private network to be multicast capable. However, the any-to-any communication is applicable to unicast data forwarding, not multicast data forwarding.
The usage of multicasting in current DMVPN framework is limited to hub and spoke topology by which the multicast traffic goes through the hub. Spoke-to-spoke multicasting in DMVPN is desired as DMVPN operators enable their networks to carry the next-generation (Triple Play) traffic including point-to-multipoint applications such as video, etc. in which the multicast source may be located anywhere in the network
While the current multicasting solution satisfies the general needs of the hub and spoke networking model, in using a non-broadcast multi-access (NBMA) technique, there is a significant multicast replication load on the hub router(s) especially when the multicast source is located in a spoke site. The current multicasting solution may also require the presence of a Rendezvous Point (RP) in the Hub site, and may not work with Source Specific Multicast (SSM).
Communication system 10 addresses these shortcomings, and others, in using a method (using PIM extensions) for spoke-to-spoke multicasting such that the multicast source can reside behind any spoke and can make use of SSM. This further facilitates any-to-any multicasting in an efficient manner and flexible manner (i.e. two hybrid models including cooperative multicasting) for optimal utilization of the DMVPN network resources.
In essence, communication system 10 lets the hub router off-load the replication load either fully or partially to the spoke router (that fronts the multicast source), while controlling which spoke site can receive the multicast data directly from the spoke site or through the hub router. The available bandwidth and processing at the spoke router makes this innovation feasible and attractive for deployment.
The invention enables the DMVPN hub router 70 to receive one or more PIM join/prune messages from one or more spoke router 62 that fronts the receiver 58, and transmit an enhanced PIM join/prune message towards the remote spoke router 64 where the multicast source 60 is located. The PIM is enhanced such that it includes the list of each downstream spoke that sent the PIM join/prune (J/P) for a particular (S,G) in a new attribute referred to as the receiver-list attribute. This attribute is illustrated in
Embodiments of the invention can enable the DMVPN spoke router 64 to dynamically determine the interested remote spokes by parsing the hub-sent enhanced PIM join/prune message and then constructing the related OIF in the multicast routing entry for the prescribed (S,G) mroute.
In terms of some of the more important aspects of the present invention, the PIM enhancement is significant, where the PIM Hello message includes a new option type. In addition, the PIM join/prune includes a new receiver-list attribute that the hub populates to include the NBMA address of each interested spoke. There may also be an mroute entry with the same IIF and OIF at the hub. Communication system 10 also offers logic to allow multicast traffic to be received on an mGRE interface and be forwarded on same mGRE interface. The logic may include two internal virtual private network (VPN) routing/forwarding (VRF) tables to separate received and transmitted traffic on the same mGRE interface. Communication system 10 also offers the creation of outgoing interface (OIF) within the multicast routing entry using the PIM enhancement at the spoke. This creation is based on the receiver-list attribute information of the received PIM join/prune message, by which the spoke router updates (adds/deletes) the OIF for each multicast routing entry as per the receiver-list.
Finally, communication system 10 provides the framework to achieve cooperative multicasting, by which the DMVPN operator can selectively apply this invention such that: (a) no spoke receives traffic directly from another spoke (i.e., spoke-hub-spoke forwarding continues): (b) some spokes receive the multicast traffic directly from another spoke; and (c) all spokes receive the multicast traffic directly from another spoke. This allows the spoke router, fronting the multicast source, to dynamically determine the interested remote spoke receivers, update the multicast routing entry, and establish the GRE/IP tunnel with such receivers for multicast forwarding. The IPSec pair-wise security association (SA) may be established between the spoke source and spoke receivers. Note that the IPSec SA is needed only in one direction, i.e. from spoke2 to spoke1. Such control plane enhancement facilitates the support for both specific source multicast (SSM) and any source multicast (ASM) usage in DMVPN.
At step 308, spoke1 formulates the PIM join destined to the hub router and transmits it on the mGRE tunnel to the hub (IPSec associations are likely to exist, since the hub is a routing neighbor as well as the NHRP NextHop Server). At step 310, the hub router decapsulates the received message and processes the PIM message as per standard multicast processing (i.e., create an mroute etc.), and forwards the PIM message to the remote spoke2 router, which is the RPF neighbor, as per the uRIB/MuRIB for the created mroute.
The formulated PIM message includes a new extension, which includes the list of the spoke routers that sent the PIM join for this S, G (or *, G). This is illustrated by step 312. The hub router may limit the number of spoke sites included in this extension via the provisioning component, etc. The extension would include the public and private IP address pairs related to the spoke site. This helps to avoid NHRP resolution, if NHRP is present at the spoke2 router. The spoke sites that are included in this new PIM extension are intended to be directly served by the remote spoke router. Hence, such spoke sites may not be present in the outgoing interface list (OIL) of the mroute entry at the hub (or if present, then flagged accordingly to not use forwarding).
At step 314, spoke2 receives the PIM join from the hub router over the mGRE tunnel and creates the multicast route for S, G. More importantly, at step 316, the spoke2 parses the new extension and creates the OIF for each of the included spoke sites (addresses) that were included in the new PIM extension. At step 318, each OIF is updated with the relevant GRE/delivery header (using the information from the new PIM extension). If IPSec cryptography is enabled on the interface, then Pair-wise IPSec SA is established with spoke sites corresponding to each OIF in the OIL of mroute in only one direction. This facilitates the direct spoke-to-spoke forwarding. At step 320, spoke2 receives the multicast traffic on the LAN and forwards it out on the mGRE tunnel (after performing the needed replication) directly to the interested remote spokes, such as spoke1 and/or the hub.
In terms of the PIM enhancement and new extensions, the two new extensions can be defined as: 1) a new option type within Hello message to convey the ability to include the receiver list attribute in the PIM J/P message; and 2) a new receiver-list attribute within the Group-list of PIM J/P message. This attribute encodes the list of interested spoke routers' IP addresses. The receiver-list is formulated using the incoming PIM joins from the interested spoke sites. The encoding includes at least the NBMA address of the spoke router. This helps to avoid any next-hop resolution for the spoke routers.
The modified group list 80 in PIM J/P may look like that which is depicted by
In regards to the RPF and multicast routing table at the hub, there is intelligence that is added to the multicast routing such that the receiving spoke sites (corresponding to outgoing interfaces (OIFs)) are differentiated from the source spoke site (corresponding to the Incoming Interface (IIF)) in the mroute entry, even though they are all reachable via the same mGRE interface. This allows the hub router to receive the PIM joins from the receivers (spoke sites), and to transmit the resulting PIM join upstream towards the source (another spoke site) without violating conventional multicasting rules.
For the OIF creation using PIM extensions at the spoke, the intelligence is added to the multicast routing such that the OIF is added to the relevant mroute for each entry in the list included within the new PIM extension. This allows the spoke router, fronting the multicast source, to dynamically determine the interested remote spoke receivers. Once the OIF is created, the corresponding GRE header is built and IPSec pair-wise SA can be established.
For the forwarding plane, the multicast-forwarding plane remains unchanged except that the (spoke) router may update the mroute's OIL with the OIFs, as per the information in the “receiver-list” attribute of the received PIM message. In the case of a PIM Join, the OIF is added, and in the case of PIM Prune, the corresponding OIF is removed. In terms of a hybrid model (e.g., spoke-hub-spoke and spoke-spoke forwarding), there could be two models. One model allows the hub to specify which spoke sites get to use (100%) the spoke-to-spoke multicasting protocol. The other model allows hub to share the multicasting (e.g. replication responsibility) with each of the specified spokes sites.
For hybrid model #1—, a DMVPN operator may want to limit the deployment of this invention to certain spoke sites that have sufficient WAN bandwidth available. This means that certain spoke sites (with sufficient capacity) may forward multicast traffic spoke-to-spoke to every interested spoke, whereas certain spoke sites (with less-than-sufficient processing capacity) may forward the multicast traffic spoke-hub-spoke. While there may be a number of ways to control this, a model by which the DMVPN operator could control this via the hub router(s) is the most optimal, as well as preferable (due to better manageability). In this approach, the hub router, based on the local policy, determines whether the new extension (containing the list of interested spoke sites) should be added to the outgoing PIM message or not.
In terms of hybrid model #2—, a DMVPN operator may want to limit the deployment of this invention to a spoke site such that both the spoke site router and the hub router together serve the receivers. Some receivers are served by the spoke directly (spoke-to-spoke), whereas the remaining receivers are served by the hub (spoke-hub-spoke), where the hub becomes the proverbial ‘middleman.’ This helps to distribute the multicast replication load (i.e., fan-out load) on the spoke router fronting the multicast source and the hub router. This can be accomplished by having the hub router utilize certain logic by which it includes only a limited number of spoke sites in the new extensions of the PIM message. The included spoke sites receive the multicast content directly from the spoke site fronting the multicast source. The remaining spoke sites end up receiving the multicast content through the hub site.
This logic may also include consideration for the replication capacity (including available WAN bandwidth) of the spoke site fronting the multicast source. The replication capacity is considered to be related to the number of OIF for an mroute. This model includes consideration for the bandwidth and router resource bottleneck when using multicast applications in DMVPN networks.
In terms of highlighting some (not necessarily all) of the advantages of the architecture of communication system 10 and the previously discussed flows, such protocols do not require the spoke router (fronting the multicast source) to request any multicast receiver information. The architecture does not require the spoke router (fronting the multicast receivers) to do anything extraordinary. Furthermore, it does not require the IPSec SAs between two spokes in both directions because multicast traffic flows in one direction. Furthermore, it requires changes at the spoke router (fronting the multicast source), as well as the hub router. Conceptually, the protocol helps the hub router keep control over whether to pass this list to each spoke for each S, G, etc. This helps with the incremental deployment of example embodiments of the invention.
Software and/or hardware (inclusive of memories and processors that can execute any software application) may reside in spoke router(s) and/or the hub in order to achieve the teachings of the present invention. The software can offer the control plane enhancements (outlined herein) and could be stored in any type of memory and subsequently executed by any type of processor to carry out the functionalities explained in this Specification. In one instance, only the spoke router (e.g., having the source behind it) includes this software, potentially along with the hub router in order to achieve the operational advantages as outlined here. In other embodiments, all spoke routers include such upgrades, along with the hub router. In still other embodiments, only the hub router includes the necessary enhancements to achieve the teachings of the present invention. Any of these components may be consolidated, or any one of these can be eliminated, or added to the system elsewhere, while remaining within the broad scope of the present invention. Due to their flexibility, these items may alternatively be equipped with (or include) any suitable algorithm, hardware, component, device, application specific integrated circuit (ASIC), processor, microprocessor, algorithm, read-only memory (ROM) element, random access memory (RAM) element, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), field-programmable gate array (FPGA), or any other suitable element or object that is operable to facilitate the operations thereof. Considerable flexibility is provided by the structure of these outlined configurations in the context of communication system 10 and, accordingly, they should be construed as such.
Note that the examples of the preceding FIGURES have been offered for purposes of teaching only. Accordingly, some of these discussed steps may be changed, deleted, or replaced with other steps where appropriate. Such modifications may be based on particular communication needs or specific communication architectures and configurations and are within the teachings of the present invention.
As explained above, the lack of spoke-spoke multicasting support has been a known limitation in DMVPN. This invention aids the DMVPN adoption by customers (such as Movie Studios, Financial Enterprises, Media Enterprises etc.) needing to distribute Multicast traffic (such as Video or Data) spoke-to-spoke. There are two approaches to tackle the multiple hubs scenario. One approach is to let each hub append the attached receiver information in the PIM message that ultimately is delivered to the remote spoke (sender). The other approach is to enable each hub to individually and directly convey the PIM message (and receiver info) to the remote spoke (sender), since NHRP, at the hub, would have resolved the next-hop of remote spoke via the other hubs. Both approaches are outlined and encompassed in this Specification.
Although the present invention has been described in detail with reference to particular embodiments, it should be understood that various other changes, substitutions, and alterations may be made hereto without departing from the spirit and scope of the present invention. For example, although the present invention has been described as operating in IPSec environments or VPN arrangements, the present invention may be used in any networking environment that could include such technology. Virtually any configuration that could offer a hub and spoke connection would enjoy the benefits of the present invention.
Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present invention encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims. In order to assist the United States Patent and Trademark Office (USPTO) and, additionally, any readers of any patent issued on this application in interpreting the claims appended hereto, Applicant wishes to note that the Applicant: (a) does not intend any of the appended claims to invoke paragraph six (6) of 35 U.S.C. section 112 as it exists on the date of the filing hereof unless the words “means for” or “step for” are specifically used in the particular claims; and (b) does not intend, by any statement in the specification, to limit this invention in any way that is not otherwise reflected in the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6640251||Sep 17, 1999||Oct 28, 2003||Nortel Networks Limited||Multicast-enabled address resolution protocol (ME-ARP)|
|US7136374||May 24, 2001||Nov 14, 2006||Juniper Networks, Inc.||Transport networks supporting virtual private networks, and configuring such networks|
|US7260097||Oct 8, 2002||Aug 21, 2007||Nortel Networks Limited||Label control method and apparatus for virtual private LAN segment networks|
|US7281058||Oct 9, 2002||Oct 9, 2007||Juniper Networks, Inc.||Delivering and receiving multicast content across a unicast network|
|US7283465||Jan 7, 2003||Oct 16, 2007||Corrigent Systems Ltd.||Hierarchical virtual private LAN service protection scheme|
|US7292542||Mar 5, 2003||Nov 6, 2007||At&T Bls Intellectual Property, Inc.||Method for traffic engineering of connectionless virtual private network services|
|US7339925||Oct 26, 2001||Mar 4, 2008||British Telecommunications Public Limited Company||Telecommunications routing|
|US7366894||Nov 27, 2002||Apr 29, 2008||Cisco Technology, Inc.||Method and apparatus for dynamically securing voice and other delay-sensitive network traffic|
|US7386010||Jun 13, 2003||Jun 10, 2008||Corrigent Systems Ltd||Multiprotocol media conversion|
|US7408882||Jun 24, 2003||Aug 5, 2008||Paradyne Corporation||Automatic discovery of network node addresses|
|US20030223372 *||Jun 4, 2003||Dec 4, 2003||Sanchez Juan Diego||Efficient rendezvous point tree to shortest path tree switch-over process|
|US20050083955 *||Sep 29, 2003||Apr 21, 2005||Guichard James N.||Methods and apparatus to support routing of information|
|US20070153790 *||Jan 3, 2006||Jul 5, 2007||Arjen Boers||Scaling enhancement for PIM control messages in multicast VPNs|
|US20080080501 *||Sep 28, 2006||Apr 3, 2008||Gerard Damm||Individual end-to-end d/dv/l measurement in ip multicast|
|US20090304003 *||Dec 10, 2009||Olivier Huynh Van||Global Virtual VPN|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8416775 *||Apr 9, 2013||Juniper Networks, Inc.||Systems and methods for equal-cost multi-path virtual private LAN service|
|US8879604||Jul 6, 2011||Nov 4, 2014||Cisco Technology, Inc.||Efficient rendezvous for distributed messages in frequency-hopping communication networks|
|US9071546 *||May 20, 2011||Jun 30, 2015||Cisco Technology, Inc.||Protocol independent multicast designated router redundancy|
|US9100281||Apr 5, 2013||Aug 4, 2015||Juniper Networks, Inc.||Systems and methods for equal-cost multi-path virtual private LAN service|
|US20110286462 *||May 19, 2010||Nov 24, 2011||Juniper Networks, Inc.||Systems and methods for equal-cost multi-path virtual private lan service|
|US20120294308 *||Nov 22, 2012||Cisco Technology, Inc.||Protocol independent multicast designated router redundancy|
|CN102694684A *||May 30, 2012||Sep 26, 2012||华为技术有限公司||Multi-gateway-based control entry configuration method, equipment and network system|
|CN102694684B *||May 30, 2012||Nov 5, 2014||华为技术有限公司||Multi-gateway-based control entry configuration method, equipment and network system|
|Cooperative Classification||H04L45/00, H04L12/18, H04L45/16|
|European Classification||H04L12/18, H04L45/16, H04L45/00|
|Sep 2, 2008||AS||Assignment|
Owner name: CISCO TECHNOLOGY, INC.,CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ASATI, RAJIV NMI;CAI, YIQUN NMI;KHALID, MOHAMED NMI;SIGNING DATES FROM 20080812 TO 20080814;REEL/FRAME:021466/0696
|Dec 29, 2014||FPAY||Fee payment|
Year of fee payment: 4