Patent Grant
7581010
This invention pertains generally to computer networks, and, more particularly, to computer networks in which a networked computer is capable of changing its network attachment point.
Today's large computer networks typically provide a network user, particularly a mobile network user, with the opportunity to attach to the network at multiple points. The network user may be motivated to change network attachment points because different network attachment points may, for example, offer different qualities of service, at different costs, and/or be maintained by different organizations. A computer may even be configured to automatically change network attachment points, for example, in order to minimize cost and/or maximize quality of service.
It is typically desirable for applications that utilize computer network services, that the computer network service be as transparent as possible to the application, that is, that the application need be aware of as few computer network service implementation details as possible, particularly with regard to lower layer network protocol changes. For computer networks that don't incorporate suitable facilities in to their base protocol, making network attachment point change transparent to an application may require additional mechanisms. For example, when a computer changes its attachment point to the Internet, the new network attachment point is typically associated with a new Internet Protocol (IP) address. Under baseline Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6), for example, an application on the computer that has active connections before a network attachment point change may need to make provision to rebuild those connections following the change.
For the purposes of this description, conventional attempts to make network attachment point change transparent to the application may be classified as infrastructure solutions and end-to-end solutions. Infrastructure solutions typically require additional network elements and/or network routing system modifications. For example, Mobile IP for IPv4 and Mobile IP for IPv6 are routing-based infrastructure solutions that require an additional Home Agent network element. In contrast, end-to-end solutions manage network attachment point change at communication endpoints, independent of network routing. An example end-to-end solution is described by Snoeren et al., An End-to-End Approach to Host Mobility, 6th ACM/IEEE International Conference on Mobile Computing and Networking, August 2000 (“Snoeren et al”). An advantage of end-to-end solutions is that they may enable transparent network attachment point change without modification to existing network infrastructure.
Conventional solutions have drawbacks. For example, Mobile IP for IPv4 and Mobile IP for IPv6 include routing indirection which may introduce routing inefficiencies and violate network security models. Some conventional end-to-end solutions fail to handle the case where each computer that is party to a communication connection changes its network attachment point simultaneously, or else handle the case inconsistently. The use of Network Address Translation (NAT) in a computer network is another aspect of modern computer networks that is handled inefficiently and/or inconsistently by some conventional solutions.
Some conventional solutions handle different versions of a network protocol differently, which may harm transparency. Some computer networks provide support layered protocols, for example, the Internet Protocol is commonly used in conjunction with a Transmission Control Protocol (TCP) and a User Datagram Protocol (UDP). Some conventional solutions support aspects of upper protocol layers only inefficiently or inconsistently, for example, a solution may support TCP over IP but fail to work properly with UDP over IP. Transparency may be improved if the application need not be aware that different aspects of a layered protocol are handled differently.
This section presents a simplified summary of some embodiments of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some embodiments of the invention in a simplified form as a prelude to the more detailed description that is presented later.
In an embodiment of the invention, a local connection translation table is maintained local to a peer participating in at least one communication connection. The local connection translation table includes one or more original connection parameters of a communication connection which the peer is participating in, as well as one or more current (and perhaps different) connection parameters of the communication connection.
In an embodiment of the invention, a peer may change its network attachment point. As a result of a change, the peer sends Connection Update messages to each peer with which it has an active communication connection. The Connection Update message includes a communication connection identifier as well as an identifier for the network attachment point to which the peer has moved.
In an embodiment of the invention, a local connection translation component is configured to maintain a local connection translation table. The local connection translation table has an entry for each active communication connection between a peer local to the local connection translation component and its remote peers. Each local connection translation table entry includes an original connection specification as well as a current connection specification.
While the appended claims set forth the features of the invention with particularity, the invention and its advantages are best understood from the following detailed description taken in conjunction with the accompanying drawings, of which:
Prior to proceeding with a description of the various embodiments of the invention, a description of a computer and networking environment in which the various embodiments of the invention may be practiced is now provided. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, programs include routines, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. The term “program” as used herein may connote a single program module or multiple program modules acting in concert. The terms “computer” and “computing device” as used herein include any device that electronically executes one or more programs, such as personal computers (PCs), hand-held devices, multi-processor systems, microprocessor-based programmable consumer electronics, network PCs, minicomputers, tablet PCs, laptop computers, consumer appliances having a microprocessor or microcontroller, routers, gateways, hubs and the like. The invention may also be employed in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, programs may be located in both local and remote memory storage devices.
An example of a computer networking environment suitable for incorporating aspects of the invention is described with reference to
Referring to
The computer 102 may also have additional features/functionality. For example, computer 102 may also include additional storage (removable 208 and/or non-removable 210) including, but not limited to, magnetic or optical disks or tape. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, including computer-executable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to stored the desired information and which can be accessed by the computer 102. Any such computer storage media may be part of computer 102.
The computer 102 preferably also contains communications connections 212 that allow the device to communicate with other devices such as remote computer(s) 214. A communication connection is an example of a communication medium. Communication media typically embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, the term “communication media” includes wireless media such as acoustic, RF, infrared and other wireless media. The term “computer-readable medium” as used herein includes both computer storage media and communication media.
The computer 102 may also have input devices 216 such as a keyboard/keypad, mouse, pen, voice input device, touch input device, etc. Output devices 218 such as a display, speakers, a printer, etc. may also be included. All these devices are well known in the art and need not be described at length here.
In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computing devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
In an embodiment of the invention, a protocol for establishing and maintaining communication connections in a computer network may be implemented by multiple protocol layers, for example, corresponding to layers described by an Open Systems Interconnect (OSI) model of the International Standards Organization (ISO). For details of an OSI model see Zimmerman, OSI Reference Model—The ISO Model of Architecture for Open System Interconnection, IEEE Transactions on Communications, April 1980. In an embodiment of the invention, a virtual connectivity (VC) layer is added to the protocol or is incorporated into an existing protocol layer. In what follows, examples are described with reference to the Internet Protocol (IP) and IP-based protocols, however, embodiments of the invention are not so limited, and the examples may be generalized to any networking protocol with stateless routing.
An application layer 308 utilizes network services by interacting with the upper network layers 306. The upper network layers 306 interact with the virtual connectivity layer 302, and the virtual connectivity layer 302 interacts with the lower networking layers 304. At least one of the lower networking layers 304 interacts with the physical transmission medium. In an embodiment of the invention, the virtual connectivity layer 302 virtualizes communication connections (e.g., the communication connections 212 of
In some conventional TCP/IP implementations, the IP layer and TCP layer are implemented as a single data processing module, for example, to increase performance. When this is the case, it may be advantageous to add a virtual connectivity layer 502 at an alternate location shown in
The virtual connectivity module 600 may include a virtual connectivity subscribe-notify service (VC SNS) proxy component 610 which serves as a local proxy to a remote virtual connectivity subscribe-notify service (not shown in
The local connection translation table 604 includes an entry for each active communication connection between peers. In an embodiment of the invention, the entry is added when the communication connection is established and deleted when the communication connection ends. Each entry in the local connection translation table 604 associates an original connection specification with a current connection specification. A connection specification includes one or more communication connection parameters and may uniquely identify a communication connection for a particular network protocol layer or set of network protocol layers. In an embodiment of the invention, there is a one-to-one relationship between each original connection specification and current connection specification.
The connection specification may include a network attachment point identifier (a network address) for each peer participating in the connection, for example, an IP address in an IP network, an IP address and TCP port in a TCP/IP network, or an IP address and UDP port in an UDP/IP network. In an embodiment of the invention, if none of the peers participating in an active communication connection has changed its network attachment point, the current connection specification for the corresponding entry is the same as the original connection specification. However, if one or more of the peers does move (i.e., does change its network attachment point) then the current connection specification is updated. In an embodiment of the invention, the original connection specification remains unchanged throughout the life of the communication connection.
The following table is an example of a connection specification for an IP-based computer network supporting upper layer protocols such as TCP and UDP.
The table includes a local IP address identifying the IP network attachment point of the local peer and a local port number identifying an upper layer protocol port at the local peer. The local peer may participate in multiple communication connections. Each communication connection may be associated with a port number. Similarly, the table further includes a remote IP address and remote port number. The upper layer protocol type indicates a type of upper layer protocol being routed by the IP network, for example, TCP or UDP. In an embodiment of the invention, the combination of local and remote IP addresses, upper layer protocol type, and local and remote port numbers specifies a communication connection.
The virtual connectivity module 602 may intercept each outgoing network protocol unit (e.g., IP datagram) in an outbound data stream and each incoming network protocol unit in an inbound data stream. In an embodiment of the invention, for each outgoing network protocol unit intercepted by the virtual connectivity module 602, the local connection translation component 602 translates the connection specification associated with the outgoing network protocol unit from the original connection specification to the current connection specification. Furthermore, for each incoming network protocol unit intercepted by the virtual connectivity module 602, the local connection translation component 602 translates the connection specification associated with the incoming network protocol unit from the current connection specification to the original connection specification. An example translation operation is illustrated in
In
An outgoing protocol unit 706 is intercepted by the virtual connectivity module 600 (
The local connection translation component 602 determines the connection specification for the outgoing protocol unit 706. For the outgoing protocol unit 706 this corresponds to the original connection specification IP1:IP2. The local connection translation component 602 then performs a lookup of the local connection translation table 604 (utilizing well-known techniques) to find the corresponding current connection specification which, in this case, is current connection specification IP1:IP3. The local connection translation component 602 replaces the IP address and any other connection specification associations of protocol unit 706 (in the protocol unit or in the protocol unit's context, as appropriate) with data from the current connection specification IP1:IP3 resulting in translated outgoing protocol unit 708.
Similarly, incoming protocol unit 710 is intercepted by the virtual connectivity module and submitted to the local connection translation module 602 for translation. The local connection translation module determines that incoming protocol unit 710 is associated with current connection specification IP1:IP3, performs a lookup of the local connection translation table 604 to find the corresponding original connection specification IP1:IP2, and then replaces the connection specification associations of protocol unit 710 to give translated incoming protocol unit 712, which is then passed on to the higher protocol layers. In an embodiment of the invention, the upper protocol layers and in particular the application, see connection specification information corresponding to the original connection specification while the lower protocol layers see connection specification information corresponding to the current connection specification.
Returning to
In the example update shown in the table, an active TCP/IP connection exists between a local peer with IP address IP2 and a remote peer with IP address IP1. In this example, the connection specification is a 5-tuple including the IP address and port number of the local peer (originally IP2 and port2), the IP address and port number of the remote peer (i.e., IP1 and port1), and the upper layer protocol type (i.e., TCP). The local peer changes its IP network attachment point so that its IP address and port number becomes IP3 and port3. Before the change, the original connection specification and current connection specification are the same, that is, the 5-tuple (IP2, port2, IP1, port1, TCP). After the change, the original connection specification is the same, but the current connection specification is updated with the new IP network attachment point, that is, it is now the 5-tuple (IP3, port3, IP1, port1, TCP).
In an embodiment of the invention, in order to update active connection table(s) 604 at remote peer(s), the local connection management component 606 is informed of the local network attachment point change. The local connection management component 606 may communicate with remote connection management component(s) with at least three virtual connectivity messages: Connection Update (CU), Connection Update Acknowledge (CUA), and Connection Update Request (CUR).
The Connection Update message may carry changed connection specification information from the peer where the change occurred to a remote peer participating in the communication connection. In an embodiment of the invention, when a peer changes its network attachment point, the peer sends the Connection Update message to each peer with which it has an active communication connection. The Connection Update Acknowledge message may be sent in reply to the Connection Update message to acknowledge the receipt of the Connection Update message. The Connection Update Acknowledge message may include the same information as a Connection Update message. The Connection Update Request message may be sent by a peer to request a Connection Update message from the recipient, for example, when the peer has been notified that the recipient has changed its network attachment point, but the recipient has not sent the peer a Connection Update message.
Following the move, Peer B 806 updates its local LCT table as described above and then sends a Connection Update message 808 to Peer A 802. Following the move and until Peer A 802 receives the Connection Update message 808, Peer A 802 may be unable to communicate with Peer B 806 because Peer A 802 is unaware of Peer B's 806 new IP network attachment point. The Connection Update message 808 includes information identifying Peer B's 806 new network attachment point, for example, the new IP address IP3 and a new port number port3. In addition, the Connection Update message 808 includes information referencing the original connection, for example, an original connection identifier such as the original IP address IP2 and port number port2, the original connection specification, or a connection token corresponding to the original connection. A suitable connection token may, for example, be a cryptographic hash of the original connection specification, or a connection count as maintained by one of the communicating peers.
Upon receipt of the Connection Update message 808 by the virtual connectivity module of Peer A 802, the Connection Update message 808 is parsed by the connection management component (e.g., the connection management component 606 of
Before Peer B's 804 move, both the original connection specification and the current connection specification are the same 5-tuple, that is, the IP address and port number for Peer A 802 (i.e., IP1 and port1), the IP address and port number for Peer B 804 (i.e., IP2 and port2), and the upper layer protocol type, in this case, TCP. After Peer B's 804 move, the current connection specification is updated with respect to Peer B's new network attachment point (i.e., IP2 and port2 become IP3 and port3) so that the current connection specification 5-tuple becomes (IP1, port1, IP3, port3, TCP). The original connection specification is unaffected by the move.
In reply to the Connection Update message 808, Peer A 802 sends a Connection Update Acknowledge message 810 to Peer B 806. The Connection Update Acknowledge message 810 may inform Peer B 806 of the success or otherwise of the connection update operation at Peer A 802. Following the receipt of the Connection Update Acknowledge message 810, Peer A 802 and Peer B 806 may once again engage in IP-based communications. In addition, in an embodiment of the invention, protocol and application layers above the virtual connectivity layer are unaware of Peer B's 806 IP network attachment point change.
As well as the Connection Update message 808 that Peer B 806 sends to Peer A 802, in
Before moving on from the example depicted in
The table shows a first local connection translation table entry with original connection specification including Peer A's network attachment point (IP1, port1), Peer B's original network attachment point (IP2, port2) and upper layer protocol TCP. The current connection specification for the first entry shows that Peer B has changed its network attachment point to (IP3, port3). That is, the first entry corresponds to the scenario illustrated by
If IPC is the same as IP2 and portC is the same as port2, then the first and second entries in the local connection translation table may have the same original connection specification, that is, they may be in conflict. In this example, the conflict may be avoided at Peer A by locally reattaching the connection from Peer C to (IP1, portA), where portA is different from port1, before accepting the connection. Like strategies may be available for non-IP-based computer networks. A similar conflict check and action may be required with regard to current connection specification to ensure a one-to-one relationship between original connection specification and current connection specification.
A malicious peer able to generate Connection Update messages may be able to cause havoc with peers utilizing virtual connectivity functionality. To prevent unauthorized connection updates, in an embodiment of the invention, each virtual connectivity message may include a cryptographic signature authenticating the message as from a trusted peer. To establish a basis for authentication, peers incorporating virtual connectivity modules may exchange a series of virtual connectivity messages when establishing a communication connection. For example, the peers may utilize an Elliptic Curve Diffie-Hellman public key exchange scheme to establish a basis for cryptographic authentication. This and other such suitable schemes are known in the art and need not be detailed here. A basis for cryptographic authentication may also be able to be utilized for message encryption if desired.
For example, the series of virtual connectivity messages sent and received when establishing a communication connection (the peer negotiation messages) may be processed by the peer negotiation component 608 of
In an embodiment of the invention, the virtual connectivity subscribe-notify service allows communicating peers to: subscribe to peer network attachment point change events, publish network attachment point change events, and receive notification of published network attachment point change events to which they have subscribed. Subscribe-notify services (or publish-subscribe services) are known in the art, so only some of their details are described here.
In an embodiment of the invention, a network attachment point change event occurs when a peer changes its network attachment point, for example, when Peer B of
In response to the publish message, the virtual connectivity subscribe-notify service may check each of its subscriptions and send notify messages to the notification address of subscriptions that match the published event. The notify message may include the current network attachment point of the peer that moved so that, for example, the peer being notified may send the peer that moved a Connection Update Request message. The notify message may include a copy of the Connection Update message published by the peer that moved. In an embodiment of the invention, the subscription matches the published network attachment point change event if the subscription specifies the network attachment point from which the peer that published the event moved, that is, if the subscription specifies the previous network attachment point of the publishing peer. In alternative embodiments, matching the network attachment point change event to the network attachment point change event subscription may include additional steps and/or criteria described below.
It is possible for one or more virtual connectivity subscribe-notify services to be the sole source of Connection Update messages in a computer network incorporating virtual connectivity. However, in an embodiment of the invention, scalability may be enhanced by implementing a policy that has the peer that moves send Connection Update messages directly to its communication peers whenever possible, and reserving the role of the virtual connectivity subscribe-notify service to situations where sending Connection Update messages directly (“direct connection update”) is not possible. Examples of situations where direct connection update is not possible include when more than one party to a communication connection moves simultaneously, and when the peer that moves is communicating with a peer behind network address translation (NAT).
Again as for
Neither direct connection update succeeds because both peers (Peer A 802, Peer B 804) have moved. Peer A 1102 and Peer B 806 may not be able to continue to communicate without assistance. In an embodiment of the invention, the virtual connectivity subscribe-notify service 814 provides assistance by detecting the simultaneous movement of both peers (Peer A 802, Peer B 804) and notifying at least one of the peers that the other has moved. The virtual connectivity subscribe-notify service 814 may determine that, for example, two peers have moved simultaneously if each peer publishes a network attachment point change event to the virtual connectivity subscribe-notify service 814 within a configurable period of time (e.g., 1 second).
In the example illustrated by
As a result of receiving the notify message 1106, Peer B 806 is able to determine the current network attachment point of Peer A 1102. To update the connection between Peer B 806 and Peer A 1102, Peer B 806 sends a Connection Update (CU) message 1108 to Peer A 1102 and, in accordance with an embodiment of the invention, Peer A 1102 replies with a Connection Update Acknowledgement (CUA) message 1110. Following a successful local connection translation table update at A and B, the communication connection between Peer A 1102 and Peer B 806 has been updated.
The receipt of the notify message 1106 by Peer B 806 prompts Peer B 806 to send the Connection Update message 1108 to Peer A 1102. In response to the Connection Update message 1110, Peer A 1102 sends the Connection Update Acknowledgement message 1110 to Peer B 806, completing the sequence.
In a computer network without NAT and/or when it is known that a peer is not behind NAT, the notify message 1106 may serve as the Connection Update message 1108, and the Connection Update Acknowledgement 1110 sent to Peer A 1102 in response may complete the connection update thus making the Connection Update message 1108 redundant. In a computer network with NAT, the Connection Update Request message (not shown in
Network address translation (NAT) is known in the art, so only some of its features are described here. In some computer networks, each network attachment point is associated with a network address, for example, in an IP network, each IP network attachment point may be associated with an IP address. The network address is typically of a limited size, for example, in an IPv4 network the network address is limited to 32 bits. The set of network addresses may be understood as an address space. In networks with limited size network addresses, it is possible for network addresses to become scarce, that is, it is possible to desire more network attachment points than the network address space will support. NAT provides a way to attach a new address space to an existing address space at, for example, a single network address in the existing address space. For details of an example NAT mechanism, see Egevang et al., The IP Network Address Translator (NAT), RFC 1631, Internet Engineering Task Force, May 1994.
In this description, the existing address space is called the public address space, in which, for example, the example discussed with reference to
In an embodiment of the invention, a characteristic feature of computer networks incorporating NAT is that a peer in the public address space (a public peer) may not communicate with a peer in the private address space (a private peer) unless the private peer has first contacted the public peer. Furthermore, it is common practice for the NAT mechanism to identify a peer by its network address, so that a peer that moves to a new network attachment point with a new network address may seem, to the NAT mechanism, to be a different peer. If that is the case, then a public peer that has moved will be unable to send a Connection Update message directly to a private peer. In an embodiment of the invention, the virtual connectivity subscribe-notify service is able to facilitate the connection update.
Peer A 1302 subscribes to network attachment point change events published by Peer B 804 by sending a subscribe message 1306 to the virtual connectivity subscribe-notify service 814. By sending the subscribe message 1306, the private Peer A 1302 also establishes a communication connection with the virtual connectivity subscribe-notify service 814 over which the virtual connectivity subscribe-notify service 814 may send later messages, e.g., the notify message 1308. In an embodiment of the invention, Peer B 804 may determine that Peer A 1302 is associated with a private network address. If Peer B 804 determines that Peer A 1302 is associated with a private network address then, in an embodiment of the invention, Peer B 804 does not subscribe to changes in Peer A's 1302 network attachment point because Peer B 804 would be unable to take action, i.e., send Peer A 1302 a Connection Update message, based on a private network attachment point change event notification.
Having moved to IP address IP3, Peer B 806 publishes a Connection Update message 812 to the virtual connectivity subscribe-notify service 814. If Peer B 806 attempted to send a Connection Update message (not shown in
As a result of receiving the Connection Update message 812, the virtual connectivity subscribe-notify service 814 searches its subscription database and determines that private Peer A 1302 has subscribed to changes in Peer B's 804 network attachment point. In contrast to the example described with reference to
In
In this example, Peer B 806 has determined that Peer A 1302 is a private peer and so Peer B 806 does not attempt to send a Connection Update message directly to Peer A 1302. Having moved, Peer A 1502 does attempt to send a Connection Update message (not shown in
Having described aspects of the virtual connectivity protocol with respect to various example scenarios, there now follows example decision procedures utilized by virtual connectivity protocol participants when sending virtual connectivity protocol messages in accordance with an embodiment of the invention.
In order to cause an update of the corresponding LCT table 604 at a remote peer, the procedure progresses to step 1710, where it is determined if the remote peer is in the public address space or in a private address space. If the remote peer is determined to be public then the procedure progresses to step 1712. At step 1712 a Connection Update message is sent to the remote peer. If the remote peer is determined to be private, then the connection management component 606 relies on the virtual connectivity subscribe-notify service to notify the remote peer of the network attachment point change event and the procedure progresses to step 1714. At step 1714, the procedure checks if each entry in the local connection translation table 604 has been selected. If not, the procedure returns to step 1706 to select the next entry, otherwise the example procedure is finished.
At step 1806 it is determined whether the peer that placed the subscription (the subscriber) is public or private. An example decision procedure for determining if a peer is public or private is described below with reference to
If the subscribing peer is public, then the peer that published the network attachment point change event (the publisher) may be able to send the subscriber a Connection Update message directly and without the aid of the virtual connectivity subscribe-notify service, unless, for example, the subscriber simultaneously also changes its network attachment point. In order to detect such a simultaneous movement by the subscriber, the procedure progresses to step 1810. At step 1810, the procedure waits for the subscriber to also publish a network attachment point change event, up to a maximum period of time, 1 second in this example. If the subscriber has already published a network attachment point change event when the procedure progresses to step 1810, then the procedure may spend no time waiting at step 1810.
After step 1810, the procedure progresses to step 1812 where a determination is made as to whether the subscriber may have moved before the publisher could send the subscriber a Connection Update message, that is, whether the subscriber has also published a network attachment point change event before the maximum time period expired. If the subscriber is determined to have moved “simultaneously”, then the procedure progresses to step 1808 so that the subscriber may be notified of the publisher's move. Otherwise, the virtual connectivity subscribe-notify service assumes that the publisher was able to send a Connection Update message directly to the subscriber. The procedure skips step 1808 and progresses to step 1814. Although multiple threads of execution and other parallel processing techniques may be utilized to advantage throughout an embodiment of the invention, step 1810 and step 1812 are surrounded by a dashed line 1816 to indicate that these steps are good candidates for parallel processing or equivalent techniques (e.g., a periodically checked watch list) so as to minimize candidate subscriber processing loop delays.
If the candidate subscriber is private and the notification attempt fails, it may be that the private subscriber has moved as well as the publisher, as for the example described above with reference to
At step 1814, the procedure checks for more candidate subscribers. If there are more candidate subscribers, then the procedure returns to step 1804 for the next subscriber. Otherwise, the procedure may exit.
In an embodiment of the invention, some behavior is determined by whether a communications peer is public or private. As described above, there may be at least two network addresses associated with a private peer: the public network address of the NAT service, and the peer's network address in the private address space created by the NAT service. A private peer may explicitly flag its private status in a virtual connectivity message to another peer. Alternatively, each peer may include its network address in one or more virtual connectivity messages that it sends. Other peers receiving the messages may then compare the included network address with the network address that is the apparent source address of the messages. If the included network address matches the apparent source address, the peer may be determined to be public. If the included network address does not match the apparent source address of the messages, then the sending peer may be determined to be private.
At step 1908, the apparent source of the subscribe message is compared with the network address included in the subscribe message. If the apparent source of the subscribe message matches the network address included in the subscribe message by the subscribing peer, then the procedure progresses to step 1910. Otherwise, the procedure progresses to step 1912. At step 1910, the subscription is determined to be associated with a public peer. At step 1912, the subscription is determined to be associated with a private peer. This determination may occur repeatedly in different modules of the virtual connectivity subscribe-notify service 1000, or just once, for example in the subscribe module 1002, and the subscription then stored in the subscription database 1008 flagged as public or private.
Virtual connectivity messages may be incorporated into lower layer networking protocols. For example, a virtual connectivity message may be added to an IP datagram by utilizing the IP options feature of the Internet protocol. For details of the IP options feature of the Internet protocol, see Postel, J., Internet Protocol, RFC 791, Information Sciences Institute at the University of Southern California, September 1981. When a virtual connectivity message is incorporated into a lower layer protocol datagram by utilizing one or more, for example, IP options, the additional options may be called virtual connectivity options (VC options). While virtual connectivity options carrying outgoing virtual connectivity messages are typically incorporated into outgoing protocol units generated by higher protocol layers, the virtual connectivity layer may generate its own, for example, “empty” IP packets incorporating virtual connectivity options when waiting for the next upper layer protocol unit would be ineffective and/or inefficient.
Virtual connectivity options may be added to a TCP datagram by utilizing the TCP options feature of the transmission control protocol. For details of the TCP options feature of the transmission control protocol, see Postel, J., Transmission Control Protocol, RFC 793, Information Sciences Institute at the University of Southern California, September 1981. Lower layer protocols that do not explicitly support datagram options may still be able to incorporate virtual connectivity options by appending the virtual connectivity options to the lower layer protocol datagram.
In
LengthVC Options=LengthIP−LengthIP Header−LengthUDP
That is, the number of bytes (octets) of the one or more virtual connectivity options 2002 is calculated as the total number of bytes in the IP datagram less the number of bytes in the IP header 2008 and less the number of bytes in the UDP datagram.
Similar schemes may be utilized to append virtual connectivity options to other lower layer protocol datagrams. However, such appended data may not be properly interpreted by peers that do not incorporate a virtual connectivity module (e.g., the virtual connectivity module 600 of
All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.
Preferred embodiments of this invention are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6021443 | Bracho et al. | Feb 2000 | A |
| 6865613 | Millet et al. | Mar 2005 | B1 |
| 7050432 | Banavar et al. | May 2006 | B1 |
| 7051102 | Gupta et al. | May 2006 | B2 |
| 7117270 | Rosenblum | Oct 2006 | B2 |
| 7167920 | Traversat et al. | Jan 2007 | B2 |
| 7207008 | Koch | Apr 2007 | B1 |
| 7379970 | Huang et al. | May 2008 | B1 |
| 7443865 | Zhang et al. | Oct 2008 | B1 |
| 7516174 | Tashjian et al. | Apr 2009 | B1 |
| 20020188657 | Traversat et al. | Dec 2002 | A1 |
| 20030041141 | Abdelaziz et al. | Feb 2003 | A1 |
| 20040030743 | Hugly et al. | Feb 2004 | A1 |
| 20040064512 | Arora et al. | Apr 2004 | A1 |
| 20040111469 | Manion et al. | Jun 2004 | A1 |
| Number | Date | Country |
|---|---|---|
| 1331791 | Jul 2003 | EP |
| Number | Date | Country | |
|---|---|---|---|
| 20050015496 A1 | Jan 2005 | US |
