1. Field of the Invention
The present invention relates to Mobile IP network technology. More particularly, the present invention relates to methods and apparatus for using Stream Control Transmission Protocol (SCTP) to provide a layer 4 IP mobility.
2. Description of the Related Art
Mobile IP is a protocol which allows laptop computers or other mobile computer units (referred to as “Mobile Nodes” herein) to roam between various sub-networks at various locations—while maintaining internet and/or WAN connectivity. Without Mobile IP or related protocol, a Mobile Node would be unable to stay connected while roaming through various sub-networks. This is because the IP address required for any node to communicate over the internet is location specific. Each IP address has a field that specifies the particular sub-network on which the node resides. If a user desires to take a computer which is normally attached to one node and roam with it so that it passes through different sub-networks, it cannot use its home base IP address. As a result, a business person traveling across the country cannot merely roam with his or her computer across geographically disparate network segments or wireless nodes while remaining connected over the internet. This is not an acceptable state-of-affairs in the age of portable computational devices.
To address this problem, the Mobile IP protocol has been developed and implemented. An implementation of Mobile IP is described in RFC 2002 of the IP Routing for Wireless/Mobile Hosts Working Group, C. Perkins, Ed., October 1996. Mobile IP is also described in the text “Mobile IP Unplugged” by J. Solomon, Prentice Hall. Both of these references are incorporated herein by reference in their entireties and for all purposes.
The Mobile IP process and environment are illustrated in FIG. 1. As shown there, a Mobile IP environment 2 includes the internet (or a WAN) 4 over which a Mobile Node 6 can communicate remotely via mediation by a Home Agent 8 and a Foreign Agent 10. Typically, the Home Agent and Foreign Agent are routers or other network connection devices performing appropriate Mobile IP functions as implemented by software, hardware, and/or firmware. A particular Mobile Node (e.g., a laptop computer) plugged into its home network segment connects with the internet through its designated Home Agent. When the Mobile Node roams, it communicates via the internet through an available Foreign Agent. Presumably, there are many Foreign Agents available at geographically disparate locations to allow wide spread internet connection via the Mobile IP protocol. Note that it is also possible for the Mobile Node to register directly with its Home Agent.
As shown in FIG. 1, Mobile Node 6 normally resides on (or is “based at”) a network segment 12 which allows its network entities to communicate over the internet 4 through Home Agent 8 (an appropriately configured router denoted R2). Note that Home Agent 8 need not directly connect to the internet. For example, as shown in FIG. 1, it may be connected through another router (a router R1 in this case). Router R1 may, in turn, connect one or more other routers (e.g., a router R3) with the internet.
Now, suppose that Mobile Node 6 is removed from its home base network segment 12 and roams to a remote network segment 14. Network segment 14 may include various other nodes such as a PC 16. The nodes on network segment 14 communicate with the internet through a router which doubles as Foreign Agent 10. Mobile Node 6 may identify Foreign Agent 10 through various agent solicitations and agent advertisements which form part of the Mobile IP protocol. When Mobile Node 6 engages with network segment 14, it composes a registration request for the Home Agent 8 to bind the Mobile Node's current location with its home location. Foreign Agent 10 then relays the registration request to Home Agent 8 (as indicated by the dotted line “Registration”). During the registration process, the Home Agent and the Mobile Node 6 may then negotiate the conditions of the Mobile Node's attachment to Foreign Agent 10. For example, the Mobile Node 6 may request a registration lifetime of 5 hours, but the Home Agent 8 may grant only a 3 hour period. Therefore, the attachment may be limited to a period of time. When the negotiation is successfully completed, Home Agent 8 updates an internal “mobility binding table” which links the Mobile Node's current location via its care-of address (e.g., a collocated care-of address or the Foreign Agent's IP address) to the identity (e.g., home address) of Mobile Node 6. Further, if the Mobile Node 6 registered via a Foreign Agent, the Foreign Agent 10 updates an internal “visitor table” which specifies the Mobile Node address, Home Agent address, etc. In effect, the Mobile Node's home base IP address (associated with segment 12) has been binded to the care-of address such as the Foreign Agent's IP address (associated with segment 14).
Now, suppose that Mobile Node 6 wishes to send a message to a Correspondent Node 18 from its new location. An output message from the Mobile Node is then packetized and forwarded through Foreign Agent 10 over the internet 4 to Correspondent Node 18 (as indicated by the dotted line “packet from MN”) according to a standard internet protocol. If Correspondent Node 18 wishes to send a message to Mobile Node—whether in reply to a message from the Mobile Node or for any other reason—it addresses that message to the IP address of Mobile Node 6 on sub-network 12. The packets of that message are then forwarded over the internet 4 and to router R1 and ultimately to Home Agent 8 as indicated by the dotted line (“packet to MN(1)”). From its mobility binding table, Home Agent 8 recognizes that Mobile Node 6 is no longer attached to network segment 12. It then encapsulates the packets from Correspondent Node 18 (which are addressed to Mobile Node 6 on network segment 12) according to a Mobile IP protocol and forwards these encapsulated packets to a “care of” address for Mobile Node 6 as shown by the dotted line (“packet to MN(2)”). The care-of address may be, for example, the IP address of Foreign Agent 10. Foreign Agent 10 then strips the encapsulation and forwards the message to Mobile Node 6 on sub-network 14. The packet forwarding mechanism implemented by the Home and Foreign Agents is often referred to as “tunneling.”
Although Mobile IP is in widespread use, there are various disadvantages associated with the Mobile IP protocol. For instance, once a Mobile IP session is initiated after registration with a Home Agent is completed, packets must be transmitted by a Correspondent Node to the Home Agent for those packets to be received by the Mobile Node. In other words, packets must first be sent to the Home Agent in order for those packets to subsequently be forwarded to the Mobile Node. This two-step transmission process adds to the delay with which such packets would be received by the Mobile Node. In addition, such a protocol relies upon the reliability of the Home Agent and/or redundancy of Home Agents capable of receiving and forwarding such packets to the Mobile Node. In other words, if the Home Agent fails, there is a substantial probability that packets addressed to the Mobile Node will no longer be forwarded to the Mobile Node. It would therefore be desirable to establish an alternate mechanism for providing mobility within a node or network device.
Stream Control Transmission Protocol (SCTP) is viewed as a layer between the SCTP user application (“SCTP user” for short) and a connectionless packet network service such as IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints.
SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations which may be generated from each endpoints lists. RFC 2960, “Stream Control Transmission Protocol,” October 2000, authored by Stewart, et al., discloses the requirements for SCTP and specific packet formats, and is incorporated herein by reference for all purposes.
An SCTP association is a protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints must not have more than one SCTP association between them at any given time.
An SCTP endpoint is the logical sender or receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint.
An SCTP packet is the unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes a common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP data chunks. FIG. 2 is a diagram illustrating an exemplary SCTP common header format. As shown, the SCTP common header typically includes a source port number 202, destination port number 204, verification tag 206, and checksum 208. The verification tag 206 is a 32 bit unsigned integer that is randomly generated. The verification tag 206 provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association. The checksum 208 is similarly a 32 bit unsigned integer.
The SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user messages into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end. More particularly, a chunk is a unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content.
FIG. 3 is a diagram illustrating an exemplary chunk that may be transmitted in an SCTP packet. As shown, a chunk header 300 includes a chunk type 302, chunk flags 304 which are chunk specific, and a chunk length 306. The chunk further includes a chunk value 308.
A chunk value 308 may include a single value as well as multiple parameter values. FIG. 4 is a diagram illustrating an exemplary chunk value that may be transmitted as shown at block 308 of FIG. 3. More particularly, a chunk value 308 may include a parameter type 402, a parameter length 404, and a parameter value 406.
An association is initiated by a request from the SCTP user. FIG. 5 is a process flow diagram illustrating the steps performed to set up an association between a first endpoint A and a second endpoint Z. As shown at block 502, endpoint A sends an INIT message to endpoint Z including endpoint A addresses (e.g., IPA, IPH). Upon receipt of the INIT message by endpoint Z, Z sends an acknowledgement message (INIT-ACK) which includes a security cookie to endpoint Z including endpoint Z addresses at block 504. A cookie mechanism is employed during the initialization to provide protection against security attacks. Thus, as shown at block 506, endpoint A gathers endpoint Z addresses and other information from the INIT-ACK message. At block 508 endpoint A composes a COOKIE-ECHO message including the cookie received in the INIT-ACK message and sends the message to endpoint Z. Endpoint Z receives the COOKIE-ECHO message and enters the appropriate state at block 510. Endpoint Z then sends a COOKIE-ACK message to endpoint A at block 512.
At association start-up, a primary path is defined for each SCTP endpoint (e.g., endpoints A and Z), and is used for normal sending of SCTP packets. The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation may wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed. On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing.
It is often desirable to add an additional network card for purposes of fault tolerance and redundancy. In addition, it may be desirable to change the IP address that is assigned to a particular interface of the network card. Unfortunately, in order to add a network card to a device or modify an IP address associated with a particular network card, it is typically necessary to disconnect a session. FIG. 6 is a process flow diagram illustrating a method of adding a network interface card to a device. As shown, after an association is set up at block 602 as described above with reference to FIG. 5, it is typically necessary to disconnect the session 604 in order to add an interface card (or otherwise modify an IP address associated with a network interface card) at block 606. As shown at block 608 when an address is added in association with a network card, it is then necessary to reconnect at block 610 so that a new association can be set up at block 612.
In view of the above, it would be desirable to modify an SCTP association without disconnecting a session. Moreover, it would be beneficial if SCTP could be used to provide mobility for a device without disconnecting an existing session.