Patent Application
20080101366
The present invention relates generally to an Internet Protocol (IP) enabled communication network and more particularly to minimizing IP header overhead for packets sent within the network.
Packets sent in communication networks wherein nodes implement Mobile Internet Protocol (MIP) and/or some form of security protocol can be burdened with significant packet overhead due to one or more factors including, but not limited to, the size of the headers, multiple sets of IP headers and possibly also Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) headers. For example, packets to and from nodes that are connected to a mobile network behind a mobile router may include four headers that are associated with four IP tunnels—two for the mobile router and two for the node connected behind the mobile router. This is especially a problem where such packets must traverse a narrowband wireless link.
Thus, there exists a need to optimize the use of IP headers in a communication network in order to minimize header overhead. Such optimization will enhance efficiency of the system overall, but will be especially useful for packets being sent over links that have a narrow bandwidth.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention.
Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to a method and apparatus for IP header optimization. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Thus, it will be appreciated that for simplicity and clarity of illustration, common and well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments.
It will be appreciated that embodiments of the invention described herein may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and apparatus for IP header optimization described herein. As such, these functions may be interpreted as steps of a method to perform the IP header optimization described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Both the state machine and ASIC are considered herein as a “processing device” for purposes of the foregoing discussion and claim language.
Moreover, an embodiment of the present invention can be implemented as a computer-readable storage element having computer readable code stored thereon for programming a computer (e.g., comprising a processing device) to perform a method as described and claimed herein. Examples of such computer-readable storage elements include, but are not limited to, a hard disk, a CD-ROM, an optical storage device and a magnetic storage device. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
Generally speaking, pursuant to the various embodiments, a device that we'll call a sending device receives a message (e.g., a packet) comprising a first header having a first size (e.g., a given number of bytes) and comprising data (also referred to herein as payload). The sending device could be, for example, a mobile router, a correspondent node, a mobile node, a DCME (directly connected mobile entity), a node behind a mobile router or a MVPN server that serves any of the aforementioned nodes. The first header includes information to enable transport of the first message from a source device to a destination device. For example, the information may include Internet Protocol (IP) addresses for the source and destination devices, next header information and identification and fragmentation fields. The sending device generates a first shim that has a smaller byte size than the first header and that includes a first portion of the information from the first header (e.g., the IP address for the source device and/or the IP address for the destination device). The sending device generates at least a second header comprising a second portion of the information in the first header (e.g., the next header information and the identification and fragmentations fields). The sending device then generates a second message using the data, the shim and the at least a second header and forwards the second message toward the destination device.
A second device (which we'll call the receiving device) receives the second message and determines that it contains the first shim. Upon such a determination, the receiving device recreates the first header using the first and second portions of information, appends the recreated first header to the data to generate a third message and forwards the third message toward the destination device. Further optimizations could be realized where the sending and receiving devices implement both MIP and a security protocol. For example, where the security protocol creates both a security protocol header and an IP header associated with the security protocol header (e.g., an IPSec ESP header and associated IP header), the sending device could forward the second message without the associated IP header for the security protocol, such that the second message comprises the data, the shim, the IPSec ESP header and the IP header for MIP as the outer header. The receiving device in this embodiment would also have to recreate the security protocol IP header. Further optimizations can be realized in the case of packets being sent to and from a visiting mobile node (VMN) behind a mobile router. For example, in some implementations both the VMN and the mobile router use a security protocol. Thus in accordance with another embodiment, the mobile router (or MVPN server for the mobile router) forwards packets from (to) the VMN using only one security protocol tunnel.
Accordingly, embodiments of the present invention enable IP packets to be generated and transported in an IP-enabled system that are reduced in byte-size over packets that would normally be sent where optimizations in accordance with the teachings herein are not used. Those skilled in the art will realize that the above recognized advantages and other advantages described herein are merely exemplary and are not meant to be a complete rendering of all of the advantages of the various embodiments of the present invention.
Prior to describing the figures, a list of terms used herein is defined as follows.
IP is a protocol that enables nodes to communicate (transmit and/or receive) packets over the Internet and includes, but is not limited to, both IETF (Internet Engineering Task Force) Internet Protocol version 4 (IPv4) as defined in RFC (Request for Comments) 791 and all subsequent revisions and Internet Protocol version 6 (IPv6) as defined in RFC 2460 and all subsequent revisions, as are well known in the art.
A node (also referred to herein as an entity) is a device that implements IP.
A router is a node that forwards IP packets not explicitly addressed to itself.
A host is any node that is not a router.
A link is a communication facility or medium over which nodes can communicate at the link layer, such as an Ethernet, which is below IP.
An interface is a node's attachment to a link.
A unicast routable address is an identifier for a single interface such that a packet sent to it from another subnet is identified by that address.
A packet is a header plus payload (also referred to herein as data).
A tunnel is the path followed by a packet while it is encapsulated (using one or more associated headers). The model is that, while it is encapsulated, a packet is routed to a knowledgeable decapsulation agent, which decapsulates the packet and then correctly delivers it to its ultimate destination. A security tunnel is encapsulated using a security protocol header. A mobility tunnel is encapsulated using a mobility management protocol header (also referred to herein as a mobility header). An IP tunnel is encapsulated using an IP header.
A security protocol is used to create a security association between two nodes, which is a cooperative relationship formed by the sharing of cryptographic keying material and associated context. IETF IP Security protocol suite (also referred to as IPSec protocol) is an example of a security protocol.
A home address (HoA) is a unicast routable address assigned to a mobile node and used as the permanent address of the mobile node. This address is within the mobile node's home network.
A home network is a network, possibly virtual, having a network prefix matching that of a mobile node's home address. Standard IP routing mechanisms will deliver packets destined to a mobile node's home address to the mobile node's home network.
A mobile node (MN) is a node that can change its point of attachment from one link to another, while still being reachable via its home address. A mobile node can be a mobile router or a mobile host.
A correspondent node is a peer node with which a node is communicating and which may be either mobile or stationary.
A mobility management protocol is a protocol that enables nodes to change their point of attachment in a network while still being accessible by their home addresses. Well known standard Mobile IP (MIP) (as defined in RFC 3344 and all subsequent revisions entitled “IP Mobility Support for IPv4” and RFC 3775 and all subsequent revisions entitled “Mobility Support in IPv6”) is an example of a mobility management protocol.
A mobility agent is a router on a mobile node's home network (e.g., a home agent (HA)) or on a foreign network (e.g., a foreign agent (FA)) that implements a mobility management protocol to forward packets destined to the mobile node.
A foreign network is a network, possibly virtual, having a network prefix that does not match that of a mobile node's home address.
A visited network is a network other than a mobile node's home network, to which the mobile node is currently connected.
A binding is an association of the home address with a care-of address for a mobile node.
Registration is the process during which a mobile node sends a binding update to a mobility agent causing a binding for the mobile node to be registered.
A care-of address (CoA) is a unicast routable address associated with a mobile node while visiting a foreign network and is the termination point of a tunnel toward the mobile node for packets forwarded to the mobile node while it is away from its home network. For example, a foreign agent care-of address is an address of a foreign agent with which the mobile node is registered, and a co-located care of address is an externally obtained local address which the mobile node has associated with one of its own network interfaces.
A mobile network is a network having a network prefix assigned to a mobile router. A mobile network associated with a given mobile router and the nodes attached to the network are commonly referred to as being “located behind the mobile router”.
A directly connected mobile entity (DCME) is a mobile node (host or router) that is directly connected to access infrastructure, i.e., without going through a mobile router.
A shim is a piece of data that replaces a header and has a smaller bit or byte size than the header that it replaces. Where the header at least includes information enabling the transport of a message between a source device and a destination device, the shim includes only a portion of that information.
Referring now to the drawings, and in particular
Shown in communication network 100 is a home network 120 for a mobile host (VMN) 124 (and from which host 124 is assigned a HoA), a customer enterprise network (CEN) 130, which serves as a home network for a DCME (MN) 138 and a mobile router (MR) 134 (and from which MN 138 and MR 134 are assigned a HoA) and a mobile network 140 behind MR 134. Networks 120, 130 and 140 may be interconnected using any known wireless and/or wired means and may be further connected to other access networks and the Internet across which packets may flow from a source node to a destination node. Moreover, networks 120, 130 and 140 are IP-enabled networks, meaning that they each at a minimum provide IP connectivity for nodes and may further include devices that assign IP addresses for these nodes using IPv4 and/or IPv6. Networks 120 and 130 may further be reachable via Radio Access Networks (RANs) (not shown), for example, for facilitating media exchange between nodes connected to network 100. Also shown is a correspondent node 110 that communicates with nodes in network 100.
VMN home network 120 comprises at least one mobility agent such as a home agent (e.g., VMN MVPN 122) performing mobility management functions for mobile nodes (e.g., mobile node 124) using a mobility management protocol such as, for instance, MIP in this embodiment (although any suitable mobility management protocol can be used). As explained in more detail below, and as illustrated in
In an exemplary implementation, communication network 100 and the embodiments disclosed herein are practiced within a public safety context, although the teachings herein are in no way limited to such a context. However in such a context, an aim of communication network 100 is incorporating mobile networks (e.g., MR mobile network 140) into public safety vehicles, for example, to allow multiple devices (e.g., HMN 136 and VMN 124 that may be for instance Personal Digital Assistants (PDAs), portable radios, mobile radios, laptops, etc., but that are shown as laptops in this illustration) in the vehicle to access the CEN 130 and/or another network through a mobile router (e.g., MR 134), which is connected to these networks. In addition, communication network 100 ideally provides for secure delivery of packets over an access network or the Internet, for instance, as mobile nodes (e.g., MN 138) roam around network 100, and may further provide for authentication services to control who has access to and can use resources associated with the various networks.
Accordingly, in general, the architecture of communication network 100 is built upon MIP and virtual private network (VPN) security for both individual mobile hosts and for mobile networks. The VPN security is implemented using a security protocol, which for purposes of this discussion is IPsec protocol but can be any suitable security protocol depending on parameters including, but not limited to, customer requirements, system design constraints, cost constraints, etc. In this context, VPN implies a client/server remote access style of VPN, with at least the functions of encryption, user authentication, network authentication and basic key management.
As mentioned above, each logical home agent may be physically co-located with a logical VPN gateway (controlling the VPN functionality), such that a single server supplies mobility management and VPN gateway functions and to enable an IPSec tunnel to be based on a home address of a mobile node and be located inside of an MIP tunnel for enabling some of the header optimizations in accordance with the teachings herein. This single server comprising the co-located home agent and VPN gateway functionality is referred to herein as an MVPN server. Those of ordinary skill in the art will realize, however, that such physical co-location is not necessary in implementing the various teachings disclosed herein. In addition, IP and basic IP services (e.g., DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name System), Web services, etc.) may be supported in communication network 100. It should be noted that only one MVPN server is shown in networks 120 and 130 (e.g., VMN MVPN 122 and MVPN 132, respectively) for clarity of illustration, but there may be additional such servers implemented in one or more of these networks as needed or desired by a customer. Moreover, in general, the architecture of communication network 100 further supports mobile routers that (besides the basic mobile router functions in accordance with MIP) may include functions such as a mobile host, a VPN client, a VPN gateway, a local WVAN (Wireless Vehicular Area Network) authentication server, a provider of basic IP services, etc.
The CEN 130 may deploy an AAA (Authentication, Authorization and Accounting) infrastructure with AAA servers, to authenticate various mobile nodes, and which implements an AAA protocol like RADIUS protocol, for example. Accordingly, the MVPN server further hosts an AAA client that communicates with an AAA server. The mobile routers and mobile hosts may be configured to dynamically obtain a CoA or co-located CoA (CCoA), and optionally support obtaining a FA CoA, and the mobile routers dynamically obtain at least one mobile subnet.
Additional detail regarding the architecture of the various elements comprising network 100 will now be provided to assist in understanding the operation of these elements and to later enable a deeper understanding of benefits associated with implementing the teachings herein. The CEN 130 hosts at least one MVPN server (e.g., 132). MVPN 132 is configured in accordance with the general architecture described above and, therefore, comprises multiple logical components including, but not limited to, a VPN gateway and a home agent. It may have additional functions of a DHCP server and an AAA client. However, in other embodiments some of these components may be implemented as standalone physical devices such as, for instance, the DHCP server. MVPN 132 may be connected to the CEN 130 using any suitable wireless or wired interface, but is usually connected using a wired interface such as, for instance, Ethernet. The VMN MVPN 122 can be configured similarly to MVPN 132 and have a suitable interface for connecting to network 120.
Mobile network 140 is a Vehicular Area Network (VAN) associated with a public safety vehicle, for example, and comprises MR 134 and may comprise Local Fixed Nodes (or LFNs, not shown), Home Mobile Nodes (or HMNs, with only one shown, e.g., HMN 136, for simplicity of illustration), Visiting Mobile Nodes (or VMNs, with only one shown, e.g., VMN 124, for simplicity of illustration), any additional nodes connected to MR 134 indirectly for instance using an adhoc network and mobile routers. LFNs, HMNs, VMNs and the MRs behind another MR are collectively referred to as MNNs (or mobile network nodes) and are supported by MR 134. In one embodiment, network 140 is further a wireless VAN (WVAN) providing Wireless Local Area Network (WLAN) connectivity around the vehicle for hosts (such as HMNs or VMNs or even LFNs) to connect wirelessly to the MR 134. However, MNNs may also connect to MR 134 through other means, such as Ethernet, USB, RB 132 and the like. Moreover, MR 134 can be directly attached to an access network (e.g., a RAN) through a transceiver or indirectly attached through a wireless modem in the vehicle, with the MR 134 to modem link being Ethernet, USB, RB 132, etc.
The basic functionality of MR 134 is to be a mobile router, and MR 134 can be a hardware or a software-based mobile router. As a mobile router, it provides IP connectivity to hosts (and routers) connected to mobile network 140. MR 134 is also responsible for advertising its capabilities inside the VAN. MR 134 can also act as a mobile host implementing MIP host functions and connecting to the CEN 130, for example, directly (as a DCME) and/or via another mobile router. MR 134 also provides other services in the VAN such as a VPN client, a VPN gateway, authentication, DHCP, DNS, etc. As a VPN client, it establishes security associations with its MVPN server (MVPN 132) and enables applications in the MR 134 to securely communicate with nodes within CEN 130. As a VPN gateway, it enables hosts connected to mobile network 140 to use the VPN connection between MR 134 and its MVPN server. Accordingly, MR 134 in this implementation comprises multiple logical components including, but not limited to, an AAA server or proxy, possibly an AAA client, an MIP client, a VPN client, a DHCP server and a DNS server.
As stated above, the MR 134 can support at least the following three types of MNNs. The Local Fixed Node is always fixed behind a particular MR and, typically, has no MVPN capability. In other words, these nodes generally do not have a Mobile IP or IPSec stack that needs to be supported. Accordingly, a LFN behind MR 134 comprises logical components of a DNS client and a DHCP client, respectively, to the DNS and DHCP servers in MR 134.
The Home Mobile Node is a mobile node behind the MR, which has its home on the mobile subnet behind the MR it is attached to. The HoA of a HMN belongs to the MR's mobile subnet, and it typically shares the same MVPN server (and hence the same home agent) as the MR to which it is attached. When a HMN roams to a different MR, it becomes a VMN.
A Visiting Mobile Node is a mobile node that does not have its home on the mobile subnet to which it is attached. In MIP terms, the VMN is in a “foreign network”, and obtains a CoA (or a CCOA) in the mobile network. Its HoA is usually part of the CEN 130 or another mobile subnet (in this case network 120). Note that a VMN may or may not share the same MVPN server (and hence HA) as the MR to which it is attached (and does not in this illustration). In this case, both the HMN 136 and VMN 124 are mobile hosts that have MIP host functions and VPN client functions that are substantially identical to MR 134. HMN 136 and VMN 124 comprise the same basic logical components of a DNS client, a DHCP client, an MIP client and a VPN client.
As stated above, also included in communication network 100 are correspondent nodes, with only one (e.g., CN 110) being shown for clarity of illustration and DCMEs (e.g., MN 138). DCME 138 in this implementation is a mobile host and is structurally and functionally similar to a mobile host such as HMN 136 and VMN 124 described above. However, a DCME could be a mobile router, and additional DCMEs could be included in network 100. Moreover, it should be realized that (although not shown) a DCME could be connected to the infrastructure via a foreign agent that may or may not implement some of the teachings herein. CN 110 has a home network, which may be network 120 or 130 or some other network, and CN 110 may be a fixed or mobile node. Let us assume, however, for purposes of this discussion and for clarity of illustration that CN 110 is in its home network, and the network connecting CN 110 and the mobility server with which it communicates is secure and no additional security or mobility headers are needed.
In accordance with embodiments of the teachings herein, optimizations will be explained for replacing IP headers with shims and also reducing IP headers (and thereby associated tunnels) when IP packets are being sent between any node behind a mobile router (e.g., MR 134) and a correspondent node (e.g., CN 110) or between a DCME (e.g., MN 138, MR 134) and the correspondent node. By adding intelligence into DCME 138, MR 134 and MVPN 132 and optionally in MVPN 122 and FAs in network 100, embodiments of the present invention enable replacing an IP header with a shim (also referred to herein as a HOS or header optimization shim); elimination of an IPSec IP header; elimination of an MIP tunnel for a VMN behind MR 134; and selective use of the VPN tunnel for MR 134. Thus optimizations of IP headers, in accordance with the teachings herein, can be realized with respect to IP headers (and associated tunnels), mobility management headers (and associated tunnels) and security headers (and associated tunnels).
Some embodiments of the present invention are implemented as methods or processes, e.g., 200, 300, 1000, 100 and 1200 for optimizing headers in a network as illustrated, respectively, by the flow diagrams shown in
Moreover, processes in accordance with embodiments of the invention can be executed using apparatus that includes: any suitable memory, e.g., Random Access Memory, for storing state or other relevant information as discussed below; one or more processing devices, for example as described above, or processing modules or stacks that implement the optimization techniques discussed herein; and suitable interfaces (e.g., wireless, wired, software or a combination thereof) for sending packets to and receiving packets from the one or more processing devices, modules or stacks within a given device or a different device altogether. The functionality discussed below may also be implemented as a computer-readable storage element having computer readable code stored thereon for programming a computer (e.g., comprising one or more processing devices) to perform processes in accordance with the embodiments.
Since embodiments of the invention may be performed in a number of the devices illustrated in network 100, techniques for negotiating availability and use of header and tunnel optimization between these devices may be desired. In the case of integrated MIP and IPSec functionality, a MIP registration request and response can be used to negotiate availability and use of header and tunnel optimization. For instance, when a mobile node first registers with its MVPN server, it may use an extension in the registration request that we'll call a “Header Optimization Extension” that specifies the types of optimization supported by the mobile node. In the response, the MVPN server indicates an overlapping set of optimization features that it shares with the mobile node. In another implementation, Internet Key Exchange (IKE) can be used to negotiate optimization capability and use for the IPSec stack in the mobile node (independent of MIP). Moreover, in the case of a HMN and a VMN, the MR supporting those nodes could additionally determine the type of optimization supported by each node connected to its mobile network by snooping registration request and response messages sent between the nodes and their HAs.
We first turn to embodiments of the invention wherein a HOS is used for header optimization, as illustrated by exemplary methods 200 and 300. Method 200 describes the process for creating, in a sending device, a message (also referred to herein as a packet) using a HOS to replace a header, and forwarding or routing the packet with the HOS toward an intended destination device. Method 200, in general, includes the steps of: receiving (202) a first message comprising data and a first header having a first size, the first header including information to enable transporting or routing of the first message from a source device to a destination device; generating (204) a shim (HOS) having a second size that is smaller than the size of the first header, the shim comprising a first portion of the information in the first header; generating (206) at least a second header comprising a second portion of the information in the first header; generating (208) a second message comprising the data, the shim and the at least a second header; and forwarding or routing (210) the second message toward the destination device.
Method 300 describes the process performed in a receiving device, which receives the message from the sending device; recreates the header that was replaced by the shim and forwards a resulting packet with the recreated header toward the destination device. Method 300, in general, includes the steps of: receiving (302) a first message comprising at least data and at least a first header; determining (304) that the first message further comprises a shim having a first size and including a first portion of information from a second header having a second size that is larger than the size of the shim, the second header being included in a second message and the information from the second header to enable routing of the second message from a source device to a destination device, wherein the at least a first header includes a second portion of the information from the second header; recreating (306) the second header using the first and second portions of the information; generating (308) a third message using the data and the recreated second header; and routing (310) the third message toward the destination device.
We first consider optimizations wherein a packet is sent from a mobile node to a correspondent node (e.g., CN 110), wherein the mobile node can be a DCME or a MNN. The packets fall into one of two categories: (1) packets that are encrypted and/or authenticated, e.g., undergo IPSec ESP processing; and (2) packets that bypass the VPN and are, therefore, sent in the clear.
After standard IPSec and MIP processing (with no optimization) in the mobile node, the packet will look as shown in
The first optimization implementation discussed is for packets sent from a mobile node to CN 110, wherein the packets undergo both IPSec processing and MIP processing. Accordingly, the mobile node “receives” packet 400 (step 202) either via a software interface from another processing module within the mobile node (as in the case where a DCME or MNN is performing the optimizations itself) or receives the packet via a wireless (e.g., radio frequency, bluetooth) or wired (e.g., Ethernet, USB) interface from another node (as in the case of a MR performing optimizations for a MNN behind it). Upon receipt of packet 400, the mobile node generates (at step 204) a HOS to replace (original) inner header 404.
The HOS is smaller in size (e.g., 4 bytes) than header 404 (e.g., 20 bytes), and the HOS includes only a first portion of the information in header 404. In this exemplary implementation, the mobile node copies the entire destination IP address for CN 110 or at least the suffix portion of the IP address from header 404 to the HOS so that the HOS includes at least this portion of the information from header 404. The HOS may also include other information from header 404 or other information that is not in or related to header 404 such as, for instance information to enable the receiver to easily identify the HOS. For example, to enable the receiver to identify the HOS, the next header field in the header preceding the HOS may be set to IPinIP and the HOS may begin with an ALL zero byte field (instead of the normal 0100 or 0101 which would indicate IPv4 or IPv6). Other such values may be added to the HOS depending on the particular implementation.
Moreover, since the mobile node performs MIP and IPSec processing, it generates at least one other header (e.g., headers 502, 506 and 508) during its normal processing. In accordance with the teachings herein, the mobile node copies a different (second) portion of the information from header 404 into one or more of these headers (step 206). For example, the next header information in header 404 is copied to a next header field in the ESP Header, and the mobile node includes in another IP header (e.g., header 506) the same identification and fragmentation field offsets as in header 404. In one embodiment the more fragments (MF) bit in the original header is copied to a MF field in SPI and the MF bit in the newly created header is set to 0. Embodiments of the invention may further be combined with other techniques that enable UDP, TCP or other transport or session headers to be reduced or eliminated.
Prior to forwarding the packet, the IPSec module processes (e.g. encrypts) payload 402 and HOS 602. However, even though the shim 602 instead of the original inner header 404 is included for encryption, it is desirable to perform authentication of the ESP payload packet (including authentication of ESP Header 604, HOS 602 and payload 402) using at least some of the information in header 404 so that when header 404 is recreated in the receiving device, the reconstructed header 404 is substantially identical to original header 404. For example, the sending device can generate a message authentication code (MAC) for packet 600 (during authentication) based on the ESP payload packet prefixed with the original IP header present in the packet with any changing fields such as TTL, fragmentation offset, etc., set to zero and the CN IP address (which is already inside the HOS 602) also set to zero. After the receiving device has recreated the original header using the HOS (and the additional information from the other IP header(s)), it can re-compute the MAC based on the recreated IP header to ensure that the reconstructed header is substantially identical to the original header.
To distinguish between cases where the HOS optimization (and optionally additional optimizations) is used verses the case where the HOS optimization is not used, the sending device can use a suitable technique to indicate at least the presence of the shim (and other optimizations) in the packet. For example, as is illustrated by the SPI′ in ESP header 604 (
As mentioned above, in one implementation a MR can perform optimizations on packets sent to and from a VMN behind the mobile router. The MOT bits are used to indicate this implementation. Therefore, the MOT bits can be set to 00 for packets sent to and from a DCME or a LFN or HMN behind a mobile router. Only the mobile router and its MVPN Server process the MOT bits and these entities clear (set to zero) the MOT bits prior to passing a packet to the VMN or its MVPN Server. Exemplary values for the MOT bits are: 00—indicating packets that are associated with a node other than a VMN; 01—indicating packets optimized by both a MR and a VMN behind the mobile router and the presence of two shims, with an HOS added by the MR and containing the VMN IP address and another HOS added by the VMN and containing the CN IP address; 10—indicating unoptimized VPN-bypassed packets (discussed in more detail below) from the VMN that are optimized by the MR, and the 10 value further implying that a packet has been encrypted by the MR (or its MVPN server) and that the packet should be decrypted and the original inner header and VMN MIP tunnel restored before the packet is passed to the VMN or its MVPN server; and 11—can be used to indicate if the protocol headers that follow IP (such as UDP/RTP or TCP headers) have been compressed.
Further as mentioned above, the IPO bit shows the presence or absence of IP options in the original (innermost) IP header (e.g., 404) of the packet. For example, zero (0) indicates the absence of IP options and one (1) indicates the presence of IP options in the inner header. Moreover, this bit helps the receiving device to correctly determine the length of the IP header, wherein the length of the IP options is added to the 20 byte IP header length.
The HOT bits can be used for entities including: a DCME that performs its own optimization; a MR performing optimization on packets from LFNs, HMNs, or VMNs that completely bypass their MVPN tunnel; and VMNs that perform their own optimization. Exemplary values for the HOT bits are: 000—indicating that the packet is unoptimized; 001—indicating that the HOS contains only the CN IP address; 010—indicating that the HOS contains both CN and MNN IP addresses; 011—indicating that the HOS contains only the MNN (e.g., VMN HoA) IP address.
This modified SPI (SPI) is now present in the ESP header to at least indicate the presence of the HOS after the ESP header and may also indicate further optimizations as referred to above. After IPSec processing, a packet comprising payload 402, HOS 602, ESP Header 604, ESP Trailer 504 and IPSec IP header 606 is passed on to the MIP module of the mobile node. If IP options are present in the original packet then the IP Options follow the HOS. The outer header 606 length includes only the length of the header (20 bytes), and the length of the IP options can be included as a last field in the HOS if the IPO bit is set. Typically, the MIP module simply adds the MIP tunnel (by adding header 508) to the incoming packet. However, in another embodiment the packet can be further optimized by the mobile node adding the MIP header in place of the IPSec IP header. In this case, all relevant fields from header 404 as discussed above are, alternatively, copied to the MIP IP header instead of header 606.
The resulting packet after this processing implementation is illustrated as a packet 800 in
As mentioned above, in one implementation packets are sent to and from a MNN behind a mobile router. For this implementation further indications in the packet are useful to properly reconstruct the inner IP header 404 at the receiving device. For instance, the sending device performing the optimizations adds a further indication to the packet to enable the MR or the MVPN server (depending on which direction the packet is traveling) to distinguish between whether a packet is to or from the MR or the MNN behind the MR. An indication that a packet is to or from the MNN may include, but is not limited to, also including the MNN IP address in the HOS and setting the HOT bit value to 010 to indicate that the HOS contains both CN and MNN IP addresses.
We now turn back to method 300 of
For example, the MVPN server can detect the removal of the IPSec IP header (and hence optimization of the MIP header) using the following implicit approach. In the packet if the next header field in the MIP IP header indicates IPIP, then the packet is not optimized and normal MIP processing is performed on the packet. However, if the next header field indicates the ESP header, then the MVPN server can implicitly assume that the MIP header has been optimized since the MVPN server usually expects packets in tunnel mode (i.e., a next header of the IPSec IP header) when the ESP header is present. Hence, the absence of another IP header (i.e., an IPSec IP header) inside the MIP tunnel indicates that the MIP IP header has been optimized. In another implementation, the reserved bits in the SPI can be used to detect the removal of IPSec IP header. The MIP module, in this case, replaces the source address with the HoA of the MR or DCME. The HoA is determined by mapping the CoA in the packet header (in conjunction with UDP source port if UDP tunneling is used) to the HoA in the registration table.
After performing its processing, the MIP module passes the packet to the IPSec module, which detects (at step 304) that the packet includes at least one shim. The IPSec module reconstructs or recreates (at step 306) header 404, based on the value of the SPI field in the ESP header, the HOS contents and relevant contents in the IPSec IP header before routing a resulting packet (generated at step 308) toward the CN 110 (at step 310). The ultimate goal is creating in a receiving device a packet that is substantially identical to the original packet 400 sent by the mobile node to the correspondent node and having a header that is substantially identical to header 404, wherein the source IP address in the recreated IP header is usually the HoA of the mobile node and the destination address is the CN IP address. The MVPN server can obtain the source IP address for the mobile node using the mapping of the mobile node HoA and CoA that it maintains and can obtain the CN IP address from the information included in the HOS.
More specifically, the IPSec module receives the packet from the MIP stack. Only the 24 bits of SPI are used to look-up the SAD entry. Once the packet has been decrypted, the IPSec module performs the following processing on the received packet. If the HOT bits are set to 000, then normal IPSec processing is performed, wherein the inner header (e.g., 404) is matched with SAD values, and, if okay, the inner packet (e.g., header 404 and payload 402) is sent to upper layers in the MVPN server. In cases where the HOT bits are set to other than 000, sequence number matching and anti-replay protection are performed as normal, and an integrity check may be performed before decryption or in parallel with decryption. For either case of the integrity check, the receiving device prefixes the ESP payload with a pseudo IP header comprising the received outer IP header (e.g., the IPSec IP header) with the CN field and other changing fields such as TTL, fragmentation offset etc., set to zero (0). The CN field is set to zero because the CN IP address is included inside the ESP encrypted payload and is, hence, authenticated. Thus, the receiving device obtains the CN address after decryption.
If the HOT bits are set to 001, then the header 404 is recreated by setting the destination address to be the address in the first four bytes of the HOS (following the ESP header) and by setting the source address to the source address of the packet received from the MIP stack (the packet from MIP stack has the HoA of the MN as the source address—see header 606 of
In both of the above cases, the header 404 information contained in the IPSec header, e.g., identification field, ToS, etc., are all copied into the recreated IP header 404. The MF field is copied from the MF field in SPI. The next header field is copied to the recreated header 404 from the ESP next header field. ToS is either copied as is, or reverse mapping is performed in cases where such mapping exists at the MVPN server. If the IPO bit is set to 1, then in addition to the above steps, the IP header length is incremented by the value in the first byte following the source and destination addresses in the HOS. This is done to include the length of the IP options that are present in the original packet. Once the inner IP header 404 is fully reconstructed, it is prefixed to the payload 402 and the packet is routed toward CN 110.
The above description focused on the case wherein packets are sent from a mobile node to a correspondent node. However, the processing is substantially the same in the reverse direction from the correspondent node to the mobile node, with optimizations being performed, for example, at a MVPN server for a MNN or for a DCME. The packets are similar to those illustrated in figures four through six and eight through nine except that the source and destination addresses in the headers are reversed. Moreover, the same SPI format 700 as illustrated in
Moreover, the above description focused on the case where VPN processing is implemented. Described next is an embodiment wherein header optimization is performed when VPN processing is not implemented (such as when such processing is bypassed or simply not used), and there is, therefore, no ESP header included in the packet. Let us call this embodiment the “bypass mode of operation”. Such an embodiment can be used, for example, when a DCME has a co-located CoA from its access network, or the FA in the access network supports the optimization.
The bypass mode of operation will be described by reference to a packet being sent from a mobile node to a correspondent node. However, the discussion is equally applicable to the other direction with the exception being that the source and destination addresses in the headers are reversed. Accordingly, packet 400 is delivered from the IP stack to the MIP processing module in the MN. The MIP processing module typically adds an outer tunnel header without modifying anything in the inner packet. The resulting packet is one comprising only the payload 402, the header 404 and the header 508 from packet 500. In accordance with the teachings herein, the MN can replace the header 404 with a HOS. The HOS in this case includes at least the information from the header 404 that was included in the HOS implementation described above (with respect to the VPN processing embodiment) and may also contain more of the information from header 404 to aid in reconstructing header 404 and/or indicating the presence and/or type of optimizations in the packet. The MIP IP header includes all other fields and portions of the information from header 404 that will be needed by the receiving device to reconstruct header 404. As should be understood based on the above teachings, in another embodiment an MVPN server or MR could perform the optimizations in the bypass mode of operation.
However, the inclusion of the HOS in the packet is indicated differently. For example, IP options can be used to indicate that a HOS follows the MIP IP header, or the next protocol field in MIP IP header can be used for such an indication. In the latter case, the HOS further includes bits for a “next protocol” to identify what follows the inner IP header 404. In addition, the next header in outer IP header (e.g., MIP IP header or a UDP tunnel header) can be used indicate the type of packet that follows the HOS. The presence of optimizations are implicitly known based on the lack of IPIP. This indication works in all cases except for when the mobile node is sending an IPIP packet to the correspondent node itself. In that case, the next header that follows the HOS will be IP. Accordingly, the presence of HOS is detected as follows. The HOS has the first byte set to all zeros (IP will normally expect the first byte to contain the version, which is a non-zero field). The second and third bytes are reserved and are set to 0. The final byte has the same format as the byte used in SPI to indicate optimization. This approach indicates HOS using zero instead of IP protocol and compensates for lack of IPSec SPI in an ESP header by adding a field as part of the HOS. Following this, the CN IP address can be included in the HOS.
Following are additional optimization techniques in accordance with embodiments of the present invention. In one embodiment, when the MVPN server detects a level of traffic (e.g., data exchanged) between a given MN-CN (source and destination device) pair that exceeds a threshold, the MVPN server may optionally generate and send in packets to a DCME (MN or MR) an index that is representative of the MN-CN pair. This index may be used in place of the HOS or in place of one or more IP addresses carried in the HOS and can be, in one exemplary implementation, embedded as a value in the SPI field of an ESP header. This embodiment can save an extra four to eight bytes on the packet, which is valuable when a large amount of data is exchanged with the same correspondent node. The DCME can also perform this optimization in the reverse direction.
Further optimization may be realized for packets sent between a VMN and the correspondent node, as mentioned briefly above. These optimizations are next described in additional detail. In many instances VMNs may have an MVPN server that is different from the MVPN server of the mobile router to which it is attached. Hence, they maintain an MVPN tunnel with their MVPN server even after moving into the mobile network subnet of a MR. In a typical case, a VMN would add its own MIP and IPSec tunnels and pass the packet on to the MR, which then adds its MIP and IPSec tunnels. This results in an overhead of over 80 bytes. However, the embodiments described below reduce such large tunneling overhead for packets sent to and from the VMN.
In order to provide tunnel optimizations for the mobile node, the MR and the MR's MVPN Server needs to obtain and track state information. More particularly, in order to provide tunnel optimizations for VMN 124 (for example), MR 134, MVPN 132 and VMN MVPN 122 obtain certain information from the mobility, and optionally VPN associated headers of the packets to and from VMN 124 and stores this information (in any suitable internal memory element). This information is referred to herein as “state” information and comprises one or more of the following: the VMN 124 HoA and CoA, an IP address for the VMN HA; a Security Parameter Index (SPI) associated with a VPN connection; and an IP address for the VMN VPN server. In one embodiment, this state information is obtained from a registration request message from VMN 124 to VMN MVPN 122 upon connecting to network 140 and/or a registration reply message from VMN MVPN 122 to VMN 124 responsive to the registration request, since MR 134 and MVPN 132 are in the path of the registration message exchanges between VMN 124 and VMN MVPN 122 and since the registration request and reply contain the VMN 124 HoA and CoA and HA IP address. For certain security tunnel optimizations, MR 134 and/or MVPN 132 may obtain further state information such as the VPN server IP address (for VMN MVPN 122) from messages between VMN 124 and VMN MVPN 122 such as, for instance, Internet Key Exchange (IKE) messages that contain this state information.
In this embodiment, both the MR 134 and MVPN 132 can independently obtain the state information from the registration (or security association) message sequence, or one of the devices can extract the information and forward it to the other device. In this case, ideally MR 134 extracts the state information since it usually deals with much less traffic than the MVPN 132. Moreover, in a beneficial embodiment, the state information is extracted only upon detection (using any suitable means) of a successful registration reply (or security association). This preserves storage space in MR 134 and MVPN 132.
In alternative embodiments, the state information may be obtained in other ways. For example, the MR 134 may obtain the state information using a separate message exchange with VMN 124 (separate from the registration message exchange or security association message exchange, that is), wherein VMN 124 notifies MR 134 of the state information. In another embodiment, a new DHCP option may be used to notify MR 134 of the state information. MR 134 could also detect state information for VMN 124 “on the fly”, upon receiving an encapsulated packet from VMN 124. In this case, the state information is beneficially stored only upon receipt of a first reverse tunneled packet from VMN 124. Upon extracting and storing the state information for VMN 124, MR 134 communicates this information to MVPN 132 so that MVPN 132 can also save the state information.
Turning now to
Explained first is how MR 134 and MVPN 132 use this stored state information for VMN 124 to implement embodiments of the present invention when packets are routed between CN 110 and VMN 124. It is assumed for purposes of this first example that no security protocol is used by MR 134 or VMN 124. However, in many implementations a security protocol is used, and additional optimizations are later described for such security protocol implementations. Optimizations can be performed on the link between MVPN 132 and MR 134 to eliminate a mobility header from the packet. In this case, the HA in MVPN 132 performs method 1100 (of
When the HA (of MVPN server 132) “removes” (at step 1104) the VMN mobility header and “inserts” its own header, this could have more than one implementation. In one embodiment, the HA may update the necessary fields in the existing VMN mobility header to create the modified mobility header. For instance, IP version number, Type of Service (TOS) and identification fields may stay the same, but the source and destination IP addresses are modified. In another embodiment, the HA may create a fresh IP header, wherein it fills in the necessary fields.
As indicated above, further optimizations can be realized where a security protocol is used.
Depending on the particular implementation, VMN MVPN 122 may send packets with or without a VPN tunnel, or in other words the packets may be encrypted or unencrypted. Where VMN MVPN 122 sends unencrypted packets without a VPN tunnel, the MVPN 132 creates a VPN tunnel and in accordance with the teachings above further removes the VMN 124 MIP tunnel and inserts the MR 134 MIP tunnel. This embodiment may be used, for example when the MR 134 and the VMN 124 belong to the same administrative domain, implying that the VPN tunnel is not required between the MR MVPN server and the VMN MVPN server.
However, in the event where the VMN 124 and MR 134 belong to different administrative domains, VMN MVPN 122 may use a VPN tunnel for sending packets comprising encrypted data between itself and MVPN 132. In that case, the MVPN 132 can forward the packets using the VPN tunnel already associated with the packet (which was established by VMN MVPN 122), and in accordance with the previously discussed embodiment further remove the VMN 124 MIP tunnel and insert the MR 134 MIP tunnel. In one implementation, The MVPN 132 may detect encryption based on the presence of an IPSec ESP header.
Moreover, an additional optimization can be implemented where a security protocol is used along the path from CN 110 to VMN 124. In general, when VMN MVPN 122 establishes a security tunnel (in this case using IPsec protocol) an IP header associated with the ESP Header that would normally be included in the packet from MVPN 122 to VMN 124 can be eliminated and then recreated in MR 134. This embodiment is discussed above with respect to the HOS embodiment. Accordingly, the outer MR mobility header is followed by the ESP header instead of an IPSec IP header. Numerous variations of this implementation within the scope of the teachings herein can be envisioned by one of ordinary skill in the art. A few such variations are as follows. For example, on the path from CN 110 to VMN 124 the VMN MVPN 122 or the MVPN 132 could establish the security tunnel and perform the optimization omitting the IPsec IP header. Also, where CN 110 sends packets to HMN 136 or a LFN behind MR 134, only the MIP tunnel for MR 134 is used, and a security header could further be deleted where MVPN 132 established a security tunnel.
The above description focused on the case wherein packets are sent from a correspondent node to the VMN. However, the processing is substantially the same in the reverse direction from the VMN to the correspondent node, with optimizations being performed, for example, at the VMN and/or the MR. The packets are similar except that the source and destination addresses in the headers are reversed.
As can be seen by the above detailed description, there are numerous optimizations combinations when packets are sent to and from a CN and VMN. In the simplest case, the VMN may be sending the packets natively in bypass mode (i.e., bypassing its MVPN tunnel) to the MR. In a second case, the VMN may be already performing the HOS optimizations discussed in detail above. In a third case, the VMN may be sending an unoptimized MVPN tunneled packet to the MR. A fourth case may be where the VMN bypasses its VPN tunnel, but not its MIP tunnel.
The MR 134 receives packet 1300 and generates a further optimized packet such as a packet 1400 illustrated in
As stated above, ESP Header 1404, in addition to indicating the optimizations performed by VMN 124, further indicates optimizations performed at the MR 134. More specifically, the MR uses the two bit MOT value in the SPI″ of ESP header 1404 to indicate its optimizations. Note that use of the MOT bits are transparent to the VMN itself because the value is set to zero by the VMN and is cleared by the MVPN server 132 prior to the packet being forward to MVPN 122. The MR 134 adds HOS2 immediately following the ESP header, with the VMN CoA, and indicates this by setting the MOT bits in the modified SPI field in ESP header 1404 to 01.
If the next protocol field in the received packet is ESP, the MVPN server 132, starts its processing by looking at the value of the MOT field in the SPI. If it is set to 01, MVPN server 132 learns that that there are two levels of optimization, and the ESP header was added by the VMN 124. MVPN 132 obtains the VMN CoA from HOS2, sets the MOT bits to zero and strips away the HOS2 portion. The resultant packet is substantially identical to original optimized packet 1300 generated by VMN. This packet is forwarded to the VMN MVPN server 122. Note that the mapping between the VMN CoA and the VMN MVPN Server is already present at MVPN 132. The rest of the fields can be copied from the MR 134 reverse tunnel IP header. Moreover, the authentication in the ESP packet is not affected, since the packet is restored to the original packet sent out by the VMN 124. In the reverse direction, the MVPN 122 sends a packet from CN 110 to the VMN CoA with the MOT bits in the SPI set to 00. The packet, when it reaches the MVPN 132 (since the VMN CoA is on the mobile subnet of the MR 134), is further optimized by MVPN 132. MVPN 132 sets the MOT bits to 01 to indicate the double optimization and forwards the packet to MR 134.
In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. For example, the teachings herein are applicable to nested mobile networks with one or more mobile networks behind a mobile network. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
The present application is related to the following U.S. application commonly owned together with this application by Motorola, Inc. and incorporated by reference in its entirely: Ser. No. 11/463,628, filed Aug. 10, 2006, titled “Optimized Tunneling Methods in a Mobile Network” by Narayanan, et al. (attorney docket no. CM07966BBH).
