In methods and apparatus for acquiring vpn reachability information at a node of a data network, a vpn reachability information request is transmitted from a requesting node. The vpn reachability information request comprises a vpn identifier. Other nodes of the data network receive the vpn reachability information request and, if they have reachability information relevant to that vpn, they transmit such information to the requesting node where it is received and stored. The invention can be used in MPLS vpn architectures.
|
12. A data network providing a plurality of virtual Private networks (VPNs), comprising:
a plurality of nodes capable of communicating with each other, each node coupled to at least one unit of a customer network;
wherein a first node is capable of:
maintaining a vpn reachability information (VRI) database comprising, for each vpn in which at least one unit coupled to the first node is participating, a send list of nodes coupled to at least one unit participating in that vpn;
receiving a request to establish participation by a first unit coupled to the first node in a specified vpn; and
if the VRI database does not contain a send list for the specified vpn:
transmitting VRI for the first unit to all other nodes in the data network; and
requesting from all other nodes in the data network transmission of vpn reachability information for all units participating in the specified vpn;
otherwise transmitting VRI for the first unit only to nodes on the send list for the specified vpn.
1. For use in a data network comprising a plurality of nodes capable of communicating with each other, each node coupled to at least one unit of a customer network, a method of providing a plurality of virtual Private networks (VPNs) comprising the steps of:
maintaining in a first node a vpn reachability information (VRI) database comprising, for each vpn in which at least one unit coupled to the first node is participating, a send list of nodes coupled to at least one unit participating in that vpn;
receiving a request to establish participation by a first unit coupled to the first node in a specified vpn; and
if the VRI database does not contain a send list for the specified vpn:
transmitting VRI for the first unit to all other nodes in the data network; and
requesting from all other nodes in the data network transmission of vpn reachability information for all units participating in the specified vpn;
otherwise transmitting VRI for the first unit only to nodes on the send list for the specified vpn.
23. For use in a first node in a data network, the first node capable of communicating with other nodes in the network and coupled to at least one unit of a customer network, computer-executable instructions stored on a computer-readable storage medium for providing a plurality of virtual privacy networks (VPNs), the computer-executable instructions comprising the steps of:
maintaining a vpn reachability information (VRI) database comprising, for each vpn in which at least one unit coupled to the first node is participating, a send list of nodes coupled to at least one unit participating in that vpn;
receiving a request to establish participation by a first unit coupled to the first node in a specified vpn; and
if the VRI database does not contain a send list for the specified vpn:
transmitting VRI for the first unit to all other nodes in the data network; and
requesting from all other nodes in the data network transmission of vpn reachability information for all units participating in the specified vpn,
otherwise transmitting VRI for the first unit only to nodes on the send list for the specified vpn.
2. The method of
3. The method of
at the first node, receiving from a second node in the data network VRI for a second unit coupled to the second node, the received VRI identifying a vpn in which the second unit is participating; and
if the first node is coupled to a unit participating in the identified vpn, storing at least a part of the received VRI in the VRI database.
4. The method of
5. The method of
the VRI database further comprises, for each vpn in which at least one unit coupled to the first node is participating, a list of units participating in that vpn;
the received VRI identifies the second unit; and
the step of storing further comprises the step of adding the identified second unit to the list of units participating in the identified vpn.
6. The method of
7. The method of
maintaining in the route repeater, for each vpn in which at least one unit coupled to a client peer node is participating, a route repeater send list of client peer nodes coupled to at least one unit participating in that vpn;
at the route repeater, receiving from a first client peer node VRI for a second unit coupled to the first client peer node, the received VRI identifying a vpn in which the second unit is participating;
reflecting the VRI to all client peer nodes on the route repeater send list for the identified vpn that are not the first client peer node; and
reflecting the VRI to all non-client peer nodes.
8. The method of
at the route repeater, receiving from a non-client peer node VRI identifying a vpn; and
reflecting the VRI to all client peer nodes on the route repeater send list for the identified vpn.
9. The method of
at the route repeater, receiving from the external peer node VRI identifying a vpn;
reflecting the VRI to all client peers on the route repeater send list for the identified vpn; and
reflecting the VRI to all non-client peers.
10. The method of
11. The method of
13. The data network of
14. The data network of
receiving from a second node in the data network VRI for a second unit coupled to the second node, the received VRI identifying a vpn in which the second unit is participating; and
if the first node is coupled to a unit participating in the identified vpn, storing at least a part of the received VRI in the VRI database.
15. The data network of
16. The data network of
the VRI database further comprises, for each vpn in which at least one unit coupled to the first node is participating, a list of units participating in that vpn;
the received VRI identifies the second unit; and
the first node is capable of storing at least a part of the received VRI in the VRI database by adding the identified second unit to the list of units participating in the identified vpn.
17. The data network of
at least one non-solicit-capable node that is not capable of maintaining a VRI database;
wherein the VRI database further comprises, for each vpn in which at least one unit coupled to a non-solicit-capable node is participating, a send list of non-solicit-capable nodes coupled to at least one unit participating in that vpn.
18. The data network of
a route reflector coupled to a plurality of client peer nodes and at least one non-client peer node;
wherein the route reflector is capable of:
maintaining, for each vpn in which at least one unit coupled to a client peer node is participating, a route repeater send list of client peer nodes coupled to at least one unit participating in that vpn;
receiving from a first client peer node VRI for a second unit coupled to the first client peer node, the received VRI identifying a vpn in which the second unit is participating;
reflecting the VRI to all client peer nodes on the route repeater send list for the identified vpn that are not the first client peer node; and
reflecting the VRI to all non-client peer nodes.
19. The data network of
receiving from a non-client peer node second VRI identifying a second vpn; and
reflecting the second VRI to all client peer nodes on the route repeater send list for the second identified vpn.
20. The data network of
receiving from the external peer node third VRI identifying a third vpn;
reflecting the third VRI to all client peers on the route repeater send list for the third identified vpn; and
reflecting the third VRI to all non-client peers.
21. The data network of
22. The data network of
24. The computer-executable instructions stored on the computer-readable storage medium of
25. The computer-executable instructions stored on the computer-readable storage medium of
receiving from a second node in the data network VRI for a second unit coupled to the second node, the received VRI identify4ng a vpn in which the second unit is participating; and
if the first node is coupled to a unit participating in the identified vpn, storing at least a part of the received VRI in the VRI database.
26. The computer-executable instructions stored on the computer-readable storage medium of
27. The computer-executable instructions stored on the computer-readable storage medium of
the VRI database further comprises, for each vpn in which at least one unit coupled to the first node is participating, a list of units participating in that vpn;
the received VRI identifies the second unit, and
the step of storing further comprises the step of adding the identified second unit to the list of units participating in the identified vpn.
28. The computer-executable instructions stored on the computer-readable storage medium of
the data network comprises at least one non-solicit-capable node that is not capable of maintaining a VRI database; and
the VRI database further comprises, for each vpn in which at least one unit coupled to a non-solicit-capable node is participating, a send list of non-solicit-capable nodes coupled to at least one unit participating in that vpn.
|
This application is a continuation of prior U.S. patent application Ser. No. 09/441,367 filed on Nov. 17, 1999 (now U.S. Pat. No. 6,813,644), which claims priority to Canadian Patent Application No. 2,254,813 filed Nov. 18, 1998.
This invention relates to distribution of reachability information in Virtual Private Networks (VPNs).
A typical Internet network implementation comprises a Service Provider Network (SPN) connected to a plurality of customer data facilities, commonly referred to as Customer Premises Equipment (CPE). The SPN is operated by an Internet Service Provider (ISP), and comprises a network Provider Edge (PE) nodes (for example, routers and/or IP switches). Each PE node is connected to one or more instances of CPE by access links. The PE nodes are connected within the SPN directly, via other nodes and via route reflectors. Each CPE may comprise a computer or network of computers operated by a customer, the computers being interconnected, for example, by a Local Area Network (LAN). Virtual Private Networks. A VPN is an emulated multi-site wide area routed network using IP facilities which are operated and implemented by an Internet Service Provider (ISP). Thus an SPN can be used to “connect” CPE across multiple sites. These “connections” are shared in the sense that the same PE nodes can be used to connect the CPE of more than one customer. Typically, a VPN is operated by establishing tunnels between Provider Edge (PE) devices supporting the sites of a VPN.
The Internet Engineering Task Force (IETF) is an industry consortium which seeks to define standards for implementation of Internet networks. Participants submit Internet Drafts to the IETF for discussion in working groups. Some proposals contained in Internet Drafts may eventually be adopted as standards by the IETF. Copies of Internet Drafts are available at Internet address ftp://frp.ietf.org/internet-drafts.
Recent IETF drafts make proposals concerning the implementation of Virtual Private Networks (VPNs) in SPNs using Multi-Protocol Label Switching (MPLS). Such drafts include:
To implement VPNs on SPNs using MPLS, {3} proposes that a CPE will transmit a Border Gateway Protocol (BGP) message to the SPN to indicate its presence in the network and to indicate the set of VPNs in which the CPE wants to participate. The BGP message includes “VPN reachability information”, including the CPE's address in the ISP's address space and a VPN identifier.
The BGP message is received by the PE node which is connected to the CPE. The PE node can filter or otherwise examine the message to ensure that it complies with the ISP's policies. If the message does comply with the ISP's policies, the message is propagated to other PE nodes of the SPN according to the specifications of BGP (see IETF document RFC 1771).
The other PE nodes of the SPN store the VPN reachability information and forward the BGP message to any of their connected CPE that are participating in the same VPN. The CPE receiving the BGP message can then use MPLS signalling protocol to set up a MPLS tunnel to the CPE which has just joined the VPN. The PE nodes use the stored VPN reachability information to establish the MPLS tunnels.
The method described in {3} requires very little or no intervention by an ISP when a new CPE is added to a VPN. However, in a large SPN which supports a large number of VPN subscribers, each PE node of the SPN would be required to store a very large amount of VPN reachability information. Moreover, only a small percentage of the stored VPN reachability information may actually be needed by any particular PE node.
For example, in an SPN having 2000 PE nodes and 1000 VPN interfaces per PE node with an average of 10 sites per VPN, 2 million VPN reachability information records would be distributed to each PE node. Assuming conservatively that each VPN reachability information record requires 30 bytes of storage, the VPN reachability information would require 60 Mbytes of storage at each PE node. However, according to the above assumptions, only 10,000 of the stored VPN reachability information records would actually be used by a typical PE node to establish VPN tunnels. The remaining 1.99 million of the 2 million reachability information records, stored at a typical PE node, i.e. 99.5% of the stored records, would not be used.
{4} proposes that PE nodes transmitting BGP messages apply outbound filtering so as not to propagate VPN reachability information to other PE nodes which are not participating in the VPN identified in the BGP message. Alternatively, {4} proposes that PE nodes receiving BGP messages apply inbound filtering so as not to store VPN reachability information for VPNs in which they are not participating. These filtering approaches may address the storage inefficiencies noted above. However, should CPE requiring access to a particular VPN be connected to a PE node not previously participating in that VPN, such filtering would result in the PE node lacking VPN reachability information for that VPN. The required VPN reachability information would need to be provided to the PE node, either by operator provisioning or by dropping and re-establishing the connection between the PE node and other PE nodes of the SPN so that all other PE nodes of the SPN automatically transmit all of their accumulated VPN reachability information to the PE node. The former method for acquiring the required VPN reachability information is time-consuming, error-prone and expensive. In a large network, the latter method for acquiring the required VPN reachability information would take too long and have too great an impact on SPN performance to be acceptable.
The invention seeks to reduce or eliminate the above problems by enabling a particular PE node to solicit specified VPN reachability information from other PE nodes when such information is needed at the particular PE node. Preferred embodiments of the invention will be described which present a scaleable solution which reduces the storage requirements at each node and which can co-exist with existing equipment.
One aspect of the invention provides a method for distributing VPN reachability information in a data network. The method comprises transmitting a VPN reachability information request from a requesting node of the data network to another node of the data network, the VPN reachability information request comprising a VPN identifier. The method further comprises receiving the VPN reachability information request at another node of the data network; retrieving VPN reachability information associated with the VPN identifier at the other node; transmitting the retrieved VPN reachability information from the other node to the requesting node; and receiving the transmitted VPN reachability information at the requesting node.
Another aspect of the invention provides a method for acquiring VPN reachability information at a node of a data network. The method comprises transmitting a VPN reachability information request from the node, the VPN reachability information request comprising a VPN identifier. The method further comprises receiving VPN reachability information at the node.
Yet another aspect of the invention provides a method for providing VPN reachability information at a node of a data network. The method comprises receiving a VPN reachability information request at the node, the VPN reachability information request comprising a VPN identifier. The method further comprises retrieving VPN reachability information associated with the VPN identifier at the node; and transmitting retrieved VPN reachability information from the node.
The methods as defined above enable a node in a data network to acquire VPN reachability information when it is required without unduly disrupting operation of the data network. Because the VPN reachability information is acquired at the node only when required, storage of large quantities of unneeded VPN reachability information at the data node is avoided, enabling cost reduction of the data node.
Modifications to the operation of route reflectors in data networks provide further benefits. In particular, by enabling route reflectors to filter VPN reachability information so that it is provided only to client peer nodes nodes participating in the VPNs to which the reachability information applies, processing and storage at non-participating peer nodes can be reduced.
Thus, another aspect of the invention provides a method for operating a route reflector in a data network. The method comprises receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN. The method further comprises reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a method for operating a route reflector in a data network, comprising receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Yet another aspect of the invention provides a method for operating a route reflector in a data network, comprising receiving VPN reachability information from an external node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN; reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a method for distributing VPN reachability information in a data network. The method comprises maintaining at a node of the data network a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN. Upon receipt of VPN reachability information for the particular VPN, the node transmits that VPN information only to peer nodes on the VPN send list for the particular VPN.
Another aspect of the invention provides a data network, comprising a plurality of nodes. Each node comprises means for transmitting a VPN reachability information request to another node of the data network, the VPN reachability information request comprising a VPN identifier; means for receiving a VPN reachability information request from another node of the data network; means for retrieving VPN reachability information associated with a VPN identifier in a received VPN reachability information request; means for transmitting retrieved VPN reachability information to another node of the data network; and means for receiving VPN reachability information from another node of the data network.
Another aspect of the invention provides a node for a data network, comprising means for transmitting a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; and means for receiving VPN reachability information.
Yet another aspect provides a node for a data network, comprising means for receiving a VPN reachability information request, the VPN reachability information request comprising a VPN identifier; means for retrieving VPN reachability information associated with the VPN identifier; and means for transmitting retrieved VPN reachability information.
Another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from particular client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from a non-client peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Yet another aspect of the invention provides a route reflector for a data network, comprising means for receiving VPN reachability information from an external peer node connected to the route reflector, the VPN reachability information including a VPN identifier identifying a particular VPN; means for reflecting the received VPN reachability information to all non-client peer nodes connected to the route reflector; means for reflecting the received VPN reachability information to all non-solicit-capable client peer nodes connected to the route reflector; and means for reflecting the received VPN reachability information to only those solicit-capable peer nodes connected to the route reflector which are currently participating in the particular VPN.
Another aspect of the invention provides a node for a data network. The node comprises means for maintaining a VPN send list for each VPN in which the node currently participates, the VPN send list for a particular VPN identifying peer nodes of the node which also participate in that particular VPN. The node further comprises means for transmitting that VPN information only to peer nodes on the VPN send list for the particular VPN upon receipt of VPN reachability information for the particular VPN.
Yet another aspect of the invention provides a PE node comprising:
Advantageously, embodiments of the invention can be introduced into existing networks via software upgrades to existing PE nodes. For example, another aspect of the invention provides computer-readable medium containing a computer program that when loaded into a node of a data network, the node comprising hardware and software and for establishing connections to one or more other nodes, instructs the node to distribute VPN reachability information according to the steps of:
Yet another aspect of the invention provides computer-readable medium containing a computer program that when loaded into a route reflector in a data network, the instructs the route reflector to distribute VPN reachability information according to the steps of:
Another aspect of the invention provides a computer-readable medium containing a computer program that when loaded into a node of a data network, the node comprising hardware and software and for establishing connections to one or more other nodes, instructs the node to distribute VPN reachability information according to the steps of:
Embodiments of the invention are described below with reference to the accompanying drawings, by way of example only. In the drawings:
A typical customer has data networks at multiple sites and contracts with the service provider to link those sites via the SPN 10 to form a VPN for that customer. For the example illustrated in
In a Multi-Protocol Label Switching (MPLS) network, the PE nodes require VPN reachability information to establish MPLS tunnels corresponding to VPN connections. As described above, in previously proposed MPLS VPN architectures, the PE nodes are each required to store a full set of VPN reachability information, only a small proportion of which is used at any one PE node.
In this description, the term “VPN Reachability Information” will be abbreviated to “VRI” for convenience.
In the SPN 10 constructed according to an embodiment of the invention, at least some of the PE nodes 12 are “solicit-capable”—i.e. they are provided with functionality that enables them to request VRI when they need it without unduly disrupting operation of the SPN 10.
Send List is a set of peers which are known to participation in a given VPN. When there is a change in VPN information on a PE, the send list is used to distribute the changes to the appropriate peers.
As is known, adj-RIB-In is a database which contains the VRIs learned from peers. It is organized to associated the VRIs with the peer from which they are learned.
Also as is known, adj-RIB-Out is a database which contains the VRIs to be sent to peers.
Note that the data structures are illustrated as being organized by VPN. This facilitates the ability to manage the databases so that only relevant entries are maintained, and so that routing tables can be created and maintained per VPN. Advantageously, different policies can be applied on a per VPN basis. Furthermore, this organization (by VPN) allows each PE node to notify PEERs (via its adj-RIB-out table) on a VPN basis.
If, however, the PE node does not have the required VRI, it transmits the VRI received with the VPN connection request together with specified overhead bits set to indicate that further VRI is required for that VPN to all peer nodes. The resulting message acts as a VRI request.
We will now further describe the operation of the above system with reference to a specific example wherein the PE nodes are routers which communicate via BGP. In this example, the following definitions will be helpful:
Routers incorporating this embodiment of this invention utilize two new BGP-4 path attributes: Solicitation Request (Type Code 16): and Solicitation Withdraw (Type Code 17).
The Solicitation Request (SOL_REQ) path attribute is an optional transitive attribute of length 0. It is used by a SC PE to solicit VRI from other SC PEs.
The Solicitation Withdraw (SOL_WD) path attribute is an optional transitive attribute of variable length.
The SOL_WD path attribute consists of a list of four octet values, each of which indicates membership withdraw from a particular VPN. Each SOL_WD path attribute is represented by a list of tuples of form <length, VPN identifiers>, where each tuple is encoded as shown below:
Length (2 octets)
VPN identifiers (variable)
Length - total length of the VPN identifiers in octets
VPN identifiers - a list of withdrawing VPN identifiers
An UPDATE message that contains the SOL_WD attribute is not required to carry any other path attributes.
The solicitation extension path attributes are not passed to EBGP peers.
The first time a SC PE A advertises a VRI for VPN X, PE A includes a SOL_REQ path attribute along with the VRI. This VRI is distributed to all IBGP peers. It should be noted that subsequent
VRIs advertised by PE A for VPN X should not include the SOL_REQ path attribute.
When a SC PE B which supports VPN X receives the VRI originated from PE A (may come from a route reflector), B must distribute all of its LOCAL VRIs associated with VPN X back to the peer from which it received the solicitation.
A SC PE not in VPN X may discard the reachability information from PE A (i.e. does not store it in its Adj-RIB-In).
A NSC PE C receiving PE A's UPDATE message ignores the SOL_REQ path attribute, store the reachability information in its Adj-RIB-In and continue to distribute its VRIs for VPN X to all of its peers. Meanwhile, PE A should store all reachability information from C in its adj-RIB-In regardless whether C participates in the same VPN(s) or not.
When a member of VPN X unsubscribes, a SC PE A will notify all other IBGP peers known to support VPN X. Multiple members of VPN X may be supported by PE A. But if the last member of VPN X is withdrawn from PE A, all other SC PE that support X should stop sending VPN X's VRI to PE A. To withdraw membership from VPN X, a SC PE A may include a SOL_WD path attribute along with the unfeasible route(s) in its UPDATE message. Upon receiving this UPDATE message, a SC PE B withdraws the unfeasible route(s). B also stops sending reachability information related to VPN X to PE A if the last reachability information related to VPN X from PE A has been withdrawn.
Advantageously, the above described system allows a BGP-4 equipped PE node to discard Adj-RIB-In entries that are not relevant and solicit those that are. Furthermore, this architecture allows NSC PE (including route reflectors) to continue supporting the general VPN architecture without any loss of VRI.
BGP route reflectors which do not support solicitation operate in a conventional manner. BGP route reflectors which support solicitation according to an embodiment of the invention operates as follows.
Each route reflector keeps track of the VPN associated with each of its SC-Client peers. When a route is received by a route reflector, it selects the best path based on its path selection rule.
After the best path is selected, it does the following depending on the type of peer it is receiving the best path from:
The embodiments of the invention described above may be modified without departing from the broad principles of the invention.
For example, the order of some steps in some of the processes described above may be interchanged without appreciably altering their effect.
The format of the VRI request may be altered without departing from the principles of the invention. In the embodiment described above, the VRI request is implemented as a flag in a VRI distribution message sent by a PE node to inform peer nodes that a CPE has registered for VPN participation at the sending PE node. Alternatively, the VRI request could take the form of a separate VRI request message.
These and other modifications of the embodiments described above are intended to be within the scope of the invention as defined by the claims which follow.
Jamieson, Dwight D., Wang, Rong R.
Patent | Priority | Assignee | Title |
8111633, | Aug 30 2004 | Juniper Networks, Inc. | Multicast trees for virtual private local area network (LAN) service multicast |
8121056, | Aug 30 2004 | Juniper Networks, Inc. | Aggregate multicast trees for multicast virtual private networks |
8160076, | Aug 30 2004 | Juniper Networks, Inc | Auto-discovery of multicast virtual private networks |
8462635, | Jun 30 2006 | Juniper Networks, Inc. | Resource reservation protocol with traffic engineering point to multi-point label switched path hierarchy |
8488614, | Jun 30 2006 | Juniper Networks, Inc. | Upstream label assignment for the label distribution protocol |
8625465, | Aug 30 2004 | Juniper Networks, Inc. | Auto-discovery of virtual private networks |
8767741, | Jun 30 2006 | Juniper Networks, Inc. | Upstream label assignment for the resource reservation protocol with traffic engineering |
8953500, | Mar 29 2013 | Juniper Networks, Inc | Branch node-initiated point to multi-point label switched path signaling with centralized path computation |
Patent | Priority | Assignee | Title |
6205488, | Nov 13 1998 | RPX CLEARINGHOUSE LLC | Internet protocol virtual private network realization using multi-protocol label switching tunnels |
6339595, | Dec 23 1997 | Cisco Technology, Inc | Peer-model support for virtual private networks with potentially overlapping addresses |
6493349, | Nov 13 1998 | RPX CLEARINGHOUSE LLC | Extended internet protocol virtual private network architectures |
6516417, | Aug 07 1998 | RPX CLEARINGHOUSE LLC | Virtual private networks |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Nov 01 2004 | Nortel Networks Limited | (assignment on the face of the patent) | / | |||
Dec 18 2009 | Nortel Networks Limited | AVAYA Holdings Limited | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 023998 | /0799 | |
Jan 24 2017 | AVAYA INTEGRATED CABINET SOLUTIONS INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | Octel Communications Corporation | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | VPNET TECHNOLOGIES, INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | AVAYA Inc | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Nov 28 2017 | CITIBANK, N A | VPNET TECHNOLOGIES, INC | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | OCTEL COMMUNICATIONS LLC FORMERLY KNOWN AS OCTEL COMMUNICATIONS CORPORATION | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | AVAYA INTEGRATED CABINET SOLUTIONS INC | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Feb 11 2019 | AVAYA Holdings Limited | AVAYA MANAGEMENT L P | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048577 | /0492 | |
Mar 15 2019 | AVAYA MANAGEMENT L P | CITIBANK, N A | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 048612 | /0582 | |
Mar 15 2019 | AVAYA MANAGEMENT L P | Goldman Sachs Bank USA | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 048612 | /0598 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA MANAGEMENT L P | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 48612 FRAME 0582 | 063456 | /0428 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA HOLDINGS CORP | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 48612 FRAME 0582 | 063456 | /0428 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA Inc | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 48612 FRAME 0582 | 063456 | /0428 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | AVAYA MANAGEMENT L P | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | CAAS TECHNOLOGIES, LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | HYPERQUALITY II, LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | HYPERQUALITY, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | ZANG, INC FORMER NAME OF AVAYA CLOUD INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | VPNET TECHNOLOGIES, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | OCTEL COMMUNICATIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | AVAYA INTEGRATED CABINET SOLUTIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | INTELLISIST, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | AVAYA Inc | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 48612 0598 | 063691 | /0294 |
Date | Maintenance Fee Events |
Oct 22 2007 | ASPN: Payor Number Assigned. |
May 05 2010 | ASPN: Payor Number Assigned. |
May 05 2010 | RMPN: Payer Number De-assigned. |
Apr 14 2011 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Apr 29 2015 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Oct 11 2016 | ASPN: Payor Number Assigned. |
Oct 11 2016 | RMPN: Payer Number De-assigned. |
Jul 01 2019 | REM: Maintenance Fee Reminder Mailed. |
Dec 16 2019 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Nov 13 2010 | 4 years fee payment window open |
May 13 2011 | 6 months grace period start (w surcharge) |
Nov 13 2011 | patent expiry (for year 4) |
Nov 13 2013 | 2 years to revive unintentionally abandoned end. (for year 4) |
Nov 13 2014 | 8 years fee payment window open |
May 13 2015 | 6 months grace period start (w surcharge) |
Nov 13 2015 | patent expiry (for year 8) |
Nov 13 2017 | 2 years to revive unintentionally abandoned end. (for year 8) |
Nov 13 2018 | 12 years fee payment window open |
May 13 2019 | 6 months grace period start (w surcharge) |
Nov 13 2019 | patent expiry (for year 12) |
Nov 13 2021 | 2 years to revive unintentionally abandoned end. (for year 12) |