|Publication number||US7379465 B2|
|Application number||US 10/005,328|
|Publication date||May 27, 2008|
|Filing date||Dec 7, 2001|
|Priority date||Dec 7, 2001|
|Also published as||CA2412916A1, CA2412916C, US20030108041|
|Publication number||005328, 10005328, US 7379465 B2, US 7379465B2, US-B2-7379465, US7379465 B2, US7379465B2|
|Inventors||Can C. Aysan, Ru C. Wadasinghe|
|Original Assignee||Nortel Networks Limited|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Referenced by (12), Classifications (18), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to virtual private networks provided within public data networks and, in particular, to a tunneling scheme optimized for use in virtual private networks.
Traditionally, to securely connect geographically distributed private local area networks (LANs) of an enterprise to each other, hard-wired connections were leased from telecommunication companies, or at least an amount of guaranteed bandwidth on these connections. As well, to connect a single remote user to a private LAN, the remote user would dial in to a dedicated collection of modems, phone lines and associated network access servers. These private LANs are typically used for networking functions (e.g., e-mail, file sharing, printing) within an enterprise. Network connected devices within such a private LAN are not intended to be reachable by devices in other, unrelated networks. Increasingly, the use of Virtual Private Networks (VPNs) is replacing the use of leased hard-wired connections for providing links between LANs and the use of dedicated dial-up lines for providing remote users access to corporate intranets.
VPNs typically use a public data network, such as the Internet, to connect computer systems in private networks that are related to each other. Four critical functions have been identified as being necessary for VPNs to ensure security of data: authentication; access control; confidentiality; and data integrity. To meet these ends, while using a public data network which uses a protocol such the Internet Protocol (IP) for instance, the concept of “tunneling” has been successfully implemented.
Tunneling involves the encapsulation of a sender's data in IP packets. These encapsulated packets hide the underlying routing and switching infrastructure of the Internet from both senders and receivers. At the same time, these encapsulated packets can be protected against snooping by outsiders through the use of encryption techniques.
Tunnels can have two types of endpoints, where an endpoint may be either an individual computer or a LAN with a security gateway, which might be a carrier router or firewall. Only two cases of combinations of these end points, however, are usually considered in designing VPNs. In the first case, LAN-to-LAN tunneling, a security gateway at each end point serves as the interface between the tunnel and the private LAN. In such cases, users on either LAN can use the tunnel transparently to communicate with each other. The second case, that of client-to-LAN tunnels, is the type usually set up for a mobile user who wants to connect to a corporate LAN. The client, i.e., the mobile user, initiates the creation of the tunnel on his end in order to exchange traffic with the corporate LAN. To do so, he runs special client software on his computer to communicate with the gateway protecting the corporate LAN.
In particular, tunneling is described in K. Hamzeh, et al., “Point-to-Point Tunneling Protocol (PPTP)” Internet Engineering Task Force (IETF) Request for Comments (RFC) 2637, hereby incorporated herein by reference, which specifies a protocol that allows the known Point to Point Protocol (PPP) to be “tunneled” through an IP network. A client-server architecture is defined, in RFC 2637, in order to decouple functions which exist in current Network Access Servers so as to support VPNs. The PPTP uses an enhanced Generic Routing Encapsulation mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. The PPTP is designed to run at Open Systems Interconnection (OSI) Layer 2. Layer 2 is the OSI “Data Link” layer and is used to provide reliable transfer of information across a physical link. Tasks performed on the Data Link layer include synchronization, error control and flow control. To be sent on a LAN or wide area network (WAN) link, the payload of an IP packet (i.e., an IP datagram) is encapsulated with a header and trailer for the Data Link layer technology of the outgoing physical interface. For example, if an IP datagram is sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP datagrams are sent over a point-to-point WAN link, such as in an analog phone network or Integrated Services Digital Network (ISDN), the IP datagram is encapsulated with a PPP header and trailer.
Once the number of endpoints in a given VPN begins to increase, maintaining the given VPN with multiple point to point tunnels may become highly complex. Further, shortcomings of point to point tunneling, that include security threats due to configuration errors and a lack of address separation between the end user IP address space and the carrier IP address space, can become more pronounced.
With regard to the latter of these shortcomings, it is typical for an IP LAN behind a carrier router (i.e., a tunnel endpoint) to have an IP address space that is not meant to be seen by the outside IP world. Such IP addresses may follow a consistent pattern, such as 10.X.X.X. This pattern is often dependent upon the supplier of the networking equipment used to implement the VPN. Hence, by using the same networking equipment, the IP address spaces related to VPNs of different organizations (say, SEARS™ and SPRINT™) may share common addresses. This sharing of common addresses may lead to problems when configuring multiple VPNs over a single carrier network. In particular, a configuration error could lead to packets missing their intended destination in favor of a destination in an unrelated network. For example, a computer behind a carrier router with the VPN identifier 456 may address a packet to a destination with an address of 10.10.2.4 behind a carrier router with the VPN identifier 123. It may be that, due to a configuration error, the packet is sent to a destination with an address of 10.10.2.4 behind a carrier router with the VPN identifier 132.
Consequently, there is a need for a tunneling scheme that can better cope with shared end user IP address spaces, reduces Layer 2 complexity and minimizes security threats due to configuration errors.
A tunneling scheme optimized for use in virtual private networks provides each tunnel endpoint with two addresses, one private address and one public address. In particular, a tunnel endpoint is stretched over two sub-endpoints, each with an address. An address resolution table at each customer virtual router maintains a mapping between the various addresses of tunnel sub-endpoints.
Advantageously, the present invention provides address separation between the end user address space and the carrier address space. Further, the present invention may reduce Layer 2 complexity in the carrier network. Even further, the present invention overcomes the problem of security threats due to configuration errors.
In accordance with an aspect of the present invention there is provided a method of forwarding a packet to a destination. The method includes examining a header of said packet to determine a private destination address, determining a private address of a private remote sub-endpoint of a tunnel, said private sub-endpoint being associated with said private destination address, determining a public address of a public remote sub-endpoint of said tunnel, encapsulating said packet, resulting in an encapsulated packet, to indicate a public address of a public local sub-endpoint of said tunnel as a source address and said public address of said public remote sub-endpoint of said tunnel as a destination address and forwarding said encapsulated packet to a node in a carrier network. In a further aspect of the present invention, there is provided a software medium that permits a general purpose computer to carry out this method.
In accordance with another aspect of the present invention there is provided a carrier router. The carrier router includes a backbone router including a public network interface for connecting to a public data network and a sub-endpoint for a tunnel having a network address in an address space of said public data network. The carrier router also includes a customer virtual router including a private network interface for connecting to a private data network and a sub-endpoint for said tunnel having a network address in an address space of said private data network.
In accordance with a further aspect of the present invention there is provided a carrier router. The carrier router includes a private network interface, a public network interface and a processor operable to receive a packet at said private network interface, examine a header of said packet to determine a private destination address, determine a private address of a private remote sub-endpoint of a tunnel, said private sub-endpoint being associated with said private destination address, determine a public address of a public remote sub-endpoint of said tunnel, encapsulate said packet, resulting in an encapsulated packet, to indicate a public address of a public local sub-endpoint of said tunnel as a source address and said public address of said public remote sub-endpoint of said tunnel as a destination address and forward said encapsulated packet to a node in a public network via said public network interface.
In accordance with a still further aspect of the present invention there is provided a method of receiving a packet, said packet having public source and destination addresses and private source and destination addresses. The method includes receiving said packet from a node in a carrier data network, forwarding said packet to a first tunnel sub-endpoint having said public destination address, at said first tunnel sub-endpoint, removing said public source and destination addresses from said packet, forwarding said packet to a second tunnel sub-endpoint and at said second tunnel sub-endpoint, forwarding said packet to a device having said private destination address. In a further aspect of the present invention, there is provided a software medium that permits a general purpose computer to carry out this method.
In accordance with an even further aspect of the present invention there is provided a method of adding a given carrier router to a virtual private network, said virtual private network described by a plurality of tunnel definitions, each of said tunnel definitions defining tunnels between sub-endpoints of existing carrier routers. The method includes adding a public network address of a sub-endpoint of said given carrier router as a destination address in each of said plurality of tunnel definitions to create a plurality of amended tunnel definitions and adding a new tunnel definition where said public network address for said sub-endpoint of said given carrier router is a source address in said new tunnel definition and public network addresses for said sub-endpoints of said existing carrier routers are destination addresses in said new tunnel definition. In a further aspect of the present invention, there is provided a software medium that permits a general purpose computer to carry out this method.
Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
In the figures which illustrate example embodiments of this invention:
The remote carrier router 216N, as illustrated in
As will be apparent to a person skilled in the art, the elements of the carrier routers 216, including the customer virtual routers 206 and the backbone routers 204 of
The architecture of the local carrier router 216M, as shown in
To implement a traditional VPN using point to point tunnels in the communication system 100 of
When a given packet, originating at a source in LAN Q 108Q arrives at the third carrier router 104P, a table is consulted to associate a destination address, identified in the given packet, with a carrier network address of a carrier router 104 (i.e., one of the first carrier router 104M and the second carrier router 104N). The precise table that is consulted is dependent upon the association of the source with a particular VPN. For example, the table may indicate that the site with the destination address is in LAN B 108B. The third carrier router 104P may then encapsulate the given packet in a new packet with the carrier network address of the first carrier router 104M as the destination address of the new packet and the carrier network address of the third carrier router 104P as the source address of the new packet. The encapsulation of the given packet in the new packet for sending to the first carrier router 104M may be considered placing the given packet in a tunnel that connects the third carrier router 104P to the first carrier router 104M. At the first carrier router 104M, the given packet is extracted from the new packet and forwarded to the LAN that includes the site with the identified destination address, namely LAN B 108B. Note that the terms “first carrier router”, “second carrier router” and “third carrier router” used above in relation to carrier routers 104M, 104N and 104P are intended only to nominally distinguish between the carrier routers 104 and not to indicate a time sequence with which a given packet arrives at the carrier routers 104.
Such a mesh of point to point tunnels can begin to become complex when many more VPNs are configured and/or when many more endpoints are added to existing VPNs. Indeed, complexity can be estimated when the relationship among the major components of a given carrier managed VPN are known. The components may include: the average number of sites per VPN (S); the total number of VPNs (V); and the number of carrier routers (N). As long as N<<S*V, the Layer 2 complexity of the carrier data network 102 may be estimated to have the order O(V*S2).
In a less complex scenario, the carrier data network 102 may support two exemplary traditional VPNs. A first VPN is defined by establishing a tunnel from the first carrier router 104M to the third carrier router 104P and a tunnel from the third carrier router 104P to the first carrier router 104M. A second VPN is defined by establishing a tunnel from the second carrier router 104N to the third carrier router 104P and a tunnel from the third carrier router 104P to the second carrier router 104N. The first VPN may, for instance, be defined to facilitate communications between sites in LAN Q 108Q and LAN B 108B while the second VPN may be defined to facilitate communications between sites in LAN Q 108Q and LAN Y 108Y.
Where the address of a site in LAN B 108B is held in common with a site in LAN Y 108Y, there is potential for an error to be made at the third carrier router 104P. A packet originating at a site in LAN Q 108Q may arrive at the third carrier router 104P and may indicate, as the destination address, the address of the site in LAN B 108B that has an address in common with the site in LAN Y 108Y. The third carrier router 104P then determines a carrier router 104 to which to forward the packet. As described above, this decision is based on an association of the origin of the packet with a particular VPN, and thus a table of associations of destination addresses and carrier router addresses. As stated above, sites in LAN Q 108Q are associated with the first VPN. The definition of VPNs along with their associations with upstream networks may be performed dynamically (i.e., by machine auto-discovery) or statically (i.e., by hand data entry by a network manager). It is in the static definition of VPNs where errors are most likely. If a network manager mistakenly associates sites in LAN Q 108Q with the second VPN, the packet in question will be sent on the tunnel to the second carrier router 104N instead of the tunnel to the first carrier router 104M. At the second carrier router 104N, the original packet will be extracted from the encapsulation. Because LAN Y 108Y includes a site with the destination address of the packet, the packet will be sent to that site, rather than the appropriate site in LAN B 108B.
By dividing the endpoint of a given tunnel (i.e., a carrier router 104) into two sub-endpoints, the tunneling scheme described herein is able to reduce the likelihood of the security threat that can occur in the case of a mis-provisioning of a traditional VPN. The tunneling scheme described herein includes cross-checks that can catch mis-provisioned VPNs before such security threats are allowed to manifest themselves. Furthermore, such endpoint division provides an address separation between the carrier network address space and the customer network address space. As will be apparent hereinafter, a packet is effectively in a tunnel when the packet is given an encapsulating source and destination address. This is in contrast to the traditional approach wherein the process of giving a packet an encapsulating source and destination address is equivalent to sending the packet into a tunnel.
In overview, the tunneling scheme described herein requires two components, namely tunnels, each tunnel having a source address and at least one (potentially more than one) destination address, and a static Address Resolution Protocol (ARP) table. The static ARP table contains information on VPN membership. More particularly, the static ARP table provides address resolution between public and private addresses of tunnel sub-endpoints as well as information on the customer premise equipment (at a site within a LAN) that is assigned to a particular VPN.
Each tunnel endpoint has two addresses, one private (or customer) address and one public (or carrier) address. The private address resides on the customer virtual router 206 and the public address resides on the backbone router 204. Thus, none of the carrier's addresses are known by the end customers and customer addresses can be held in common with carrier addresses.
The static ARP table is created on a per VPN basis and defines a mapping between public and private addresses. An identical static ARP table is distributed to all customer virtual routers 206 in the same VPN.
Consider, in view of
Initially, the local customer router 324A recognizes that the private destination address 714 of the packet is outside of LAN A 108A. The local customer router 324A routes the packet to the local carrier router 216M where the packet is received by the local customer virtual router 206A (step 802). More specifically, the packet is received by the local CVR customer network interface 310. The local CVR customer network interface 310 examines the original header 702A of the packet to read the private destination address 714 (step 804). The local CVR customer network interface 310 then proceeds to look up (step 806) the private destination address 714 (10.20.1.1) in a routing table to learn that the packet should be sent to the remote CVR tunnel interface 412, which is part of the remote carrier router 216N and has an address of 10.1.2.1. The local CVR customer network interface 310 then looks up (step 808) the address of the remote CVR tunnel interface 412 (10.1.2.1) in a forwarding table and finds that, to reach the address 10.1.2.1, the packet must be sent to the local CVR tunnel interface 312, which has an address of 10.1.2.2. Upon receiving the packet, the local CVR tunnel interface 312 performs an ARP look-up (step 810) in the static ARP table.
To be clear, at a given customer virtual router 206, there are three tables: a routing table, a forwarding table and a static ARP table. These tables may be stored in the memory 508 (
The static ARP table also includes an indication of the carrier network address for the local BR tunnel interface 314A that is associated with the local CVR tunnel interface 312 (i.e., 10.1.2.2⇄188.8.131.52). Typically, however, this address information is close at hand for the local CVR tunnel interface 312 and does not require an ARP table look-up.
The packet may then be encapsulated, by the local CVR tunnel interface 312 with a public source address and a public destination address that are both in the address space of the carrier data network 102, to result in an encapsulated packet (step 812). An exemplary encapsulated packet 700B is illustrated in
The encapsulated packet 700B is then forwarded (step 814) through the local BR carrier interface 316, across the carrier data network 102 to arrive at the remote BR carrier interface 416. Notably, each of the BR carrier interfaces 316, 416 have distinct carrier network addresses and maintain routing tables. In particular, the local BR carrier interface 316, with an address, for this example, of 184.108.40.206, may maintain a routing table that indicates that a packet destined for 220.127.116.11 (the remote BR tunnel interface 414X) should be sent toward 18.104.22.168 (the remote BR carrier interface 416). It may be that a direct link to 22.214.171.124 is not available. However, the routing table may indicate the address of a “next hop” to which to forward the packet. At the next hop, another routing table will be consulted, as is conventional, and a subsequent next hop toward 126.96.36.199 may be identified, etc.
Upon receipt of the encapsulated packet 700B (step 902), the remote BR carrier interface 416 may read the public destination address of the packet (step 904) and send the encapsulated packet 700B to the remote BR tunnel interface 414X (step 906) having that address. As will be apparent to a person skilled in the art, where the carrier router 216N has multiple CVRs, as illustrated in
In sum then, instead of the case in
It is also worth noting that the CVR customer interface 310 effectively places the packet into a tunnel by determining to forward the packet to the CVR tunnel interface 312. It is at the CVR tunnel interface 312 that encapsulating address information is added to the packet. The field of addresses available for use, at the CVR tunnel interface 312, as an encapsulation destination address is limited to the public addresses in the ARP table. This is in contrast to the traditional approach to tunneling for virtual private networks wherein encapsulation and placing the packet into a tunnel are equivalent and the field of addresses available for use, at a carrier router 104, as an encapsulation destination address may only be limited by the valid addresses in the Internet (or other carrier data network).
Consider now, in view of
Initially, a new customer virtual router 206Q is added to the structure of the new carrier router 216P. A CVR tunnel interface (not shown) of the new customer virtual router 206Q is then given a private address (10.1.1.3). The new private address may be in the same subnet as the other private addresses in the pre-existing VPN so that the new customer virtual router 206Q may be reached by a broadcast, but this is not a necessity. A BR tunnel interface (not shown) of the new customer virtual router 206Q is given a public address (188.8.131.52). Notably, this public address need not be in the same subnet as the other BR tunnel interface public addresses. As is conventional, the assignment of addresses to these sub-endpoints may be accomplished by appropriate network mangers (i.e., people) given the task of assigning new addresses or by an automatic process of network address assignment. This automatic process may be, for instance, performed by a Dynamic Host Configuration Protocol (DHCP) server or a Windows Internet Naming Service (WINS) server, as is known. Notably, the assignment of the private address to the CVR tunnel interface is likely to be handled within the customer network (LAN Q 108Q) while the assignment of the public address to the BR tunnel interface is likely to be handled within the carrier data network 102.
Subsequently, the existing tunnel definitions that define the pre-existing VPN at the local customer virtual router 206A and the remote customer virtual router 206X may be re-provisioned to add a new public destination address. In particular, the tunnel definitions become Tunnel1(SA:184.108.40.206, DA:220.127.116.11, DA:18.104.22.168) and Tunnel2(SA:22.214.171.124, DA:126.96.36.199, DA:188.8.131.52). At the new customer virtual router 206Q, a new tunnel is provisioned with a tunnel definition as Tunnel3(SA:184.108.40.206, DA:220.127.116.11, DA:18.104.22.168).
The static ARP table for the pre-existing VPN may then be updated and distributed to all customer virtual routers 206 by a management console, such the management console 610 (
The task of provisioning tunnels in a VPN and updating static ARP tables may be either performed statically (i.e., by a person) or dynamically (i.e., by a network management system). As mentioned above with respect to convention VPN maintenance using point-to-point tunnels, static provisioning can lead to errors, especially as a particular VPN becomes increasingly complex.
To guard against the mis-provisioning of tunnels, the local carrier router 216M may perform a cross check of the public addresses in the tunnel configuration against the static ARP table to identify any errors before a tunnel service is activated. For instance, consider a particular point to multipoint tunnel provisioned to have a source address of 22.214.171.124 and two destination addresses, 126.96.36.199 and 188.8.131.52. The local carrier router 216M attempts to validate that the addresses of the provisioned tunnel are present in the ARP table. If the ARP table appears as follows:
Private Address Public Address 10.1.2.1 ←→ 184.108.40.206 10.1.2.2 ←→ 220.127.116.11 10.1.2.3 ←→ 18.104.22.168
then the provisioning of the tunnel may be identified as flawed. In particular, the destination address 22.214.171.124 is not in the ARP table. When such mis-provisioning is identified by the local carrier router 216M, the local carrier router 216M may communicate the error to the management console 610 (
Although, the tunneling scheme disclosed herein may appear to increase complexity, such is only the case when the number of VPNs and sites therein are limited. One advantage of the herein proposed tunneling scheme is a reduction in Layer 2 complexity for carrier data networks supporting multiple VPNs. Consider the communication system of
Advantageously, the network management aspect of the herein described tunneling scheme allows single site provisioning and multi-site distribution of VPNs. Furthermore, the ability is granted to deploy IP-VPNs today without later re-engineering the carrier data network 102 to accommodate Multi Protocol Label Switching (MPLS). The present scheme also significantly reduces the possibility of security threats due to configuration errors, a common problem with other IP-VPN solutions.
Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6226751 *||Apr 17, 1998||May 1, 2001||Vpnet Technologies, Inc.||Method and apparatus for configuring a virtual private network|
|US6496867 *||Aug 27, 1999||Dec 17, 2002||3Com Corporation||System and method to negotiate private network addresses for initiating tunneling associations through private and/or public networks|
|US6636516 *||Mar 7, 2000||Oct 21, 2003||Nec Corporation||QOS-based virtual private network using ATM-based internet virtual connections|
|US6765591 *||Apr 2, 1999||Jul 20, 2004||Nortel Networks Limited||Managing a virtual private network|
|US20020038419 *||Mar 20, 2001||Mar 28, 2002||Garrett John W.||Service selection in a shared access network using tunneling|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7469294 *||Jan 15, 2002||Dec 23, 2008||Cisco Technology, Inc.||Method and system for providing authorization, authentication, and accounting for a virtual private network|
|US7653746 *||Aug 1, 2003||Jan 26, 2010||University Of Southern California||Routable network subnet relocation systems and methods|
|US8005958 *||Jun 27, 2003||Aug 23, 2011||Ixia||Virtual interface|
|US8073966||Dec 16, 2009||Dec 6, 2011||Ixia||Virtual interface|
|US8078736||Aug 2, 2011||Dec 13, 2011||Ixia||Virtual interface|
|US8090843 *||Apr 15, 2011||Jan 3, 2012||Impro Network Facility, LLC||Creating a public identity for an entity on a network|
|US8797874 *||Sep 9, 2011||Aug 5, 2014||Futurewei Technologies, Inc.||Apparatus and system for packet routing and forwarding in an interior network|
|US20020184388 *||Oct 15, 2001||Dec 5, 2002||Nimer Yaseen||Layered approach to virtual private routing|
|US20050015642 *||Jun 27, 2003||Jan 20, 2005||Clifford Hannel||Virtual interface|
|US20130064088 *||Sep 9, 2011||Mar 14, 2013||Futurewei Technologies, Inc.||Apparatus and System for Packet Routing and Forwarding in an Interior Network|
|US20140334485 *||May 9, 2013||Nov 13, 2014||Vmware, Inc.||Method and system for service switching using service tags|
|WO2002099575A2 *||May 31, 2002||Dec 12, 2002||Fujitsu Network Communications||Layered approach to virtual private routing|
|U.S. Classification||370/409, 370/469, 370/392, 370/401|
|International Classification||H04L12/56, H04L29/12, H04L29/06, H04L12/46|
|Cooperative Classification||H04L29/12009, H04L12/4633, H04L63/0272, H04L29/12018, H04L61/10|
|European Classification||H04L63/02C, H04L61/10, H04L12/46E, H04L29/12A, H04L29/12A1|
|Dec 7, 2001||AS||Assignment|
Owner name: NORTEL NETWORKS LIMITED, CANADA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AYSAN, CAN C.;WADASINGHE, RU C.;REEL/FRAME:012362/0530
Effective date: 20011123
|Sep 23, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Oct 28, 2011||AS||Assignment|
Owner name: ROCKSTAR BIDCO, LP, NEW YORK
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:027164/0356
Effective date: 20110729
|Feb 2, 2014||AS||Assignment|
Owner name: ROCKSTAR CONSORTIUM US LP, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROCKSTAR BIDCO, LP;REEL/FRAME:032115/0114
Effective date: 20120509
|Feb 5, 2014||AS||Assignment|
Owner name: CONSTELLATION TECHNOLOGIES LLC, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROCKSTAR CONSORTIUM US LP;REEL/FRAME:032162/0489
Effective date: 20131113
|Feb 9, 2015||AS||Assignment|
Owner name: RPX CLEARINGHOUSE LLC, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROCKSTAR CONSORTIUM US LP;ROCKSTAR CONSORTIUM LLC;BOCKSTAR TECHNOLOGIES LLC;AND OTHERS;REEL/FRAME:034924/0779
Effective date: 20150128