Patent Application
20100091707
The present invention relates generally to mobility management systems and more specifically to route optimization between two mobile entities.
There has been an increasing use of mobility management systems that utilize a client/server approach to mobility management of entities that are coupled to the system. One goal of these systems is to provide a solution for seamless mobility on a network such as, for instance, the global Internet or a private network, that is scalable, robust and secure, and that allows mobile routers or mobile nodes (together referred to herein as “mobile entities”). Mobile entities can be, for instance, wirelessly connected radios, phones, laptops, PDAs, etc., to maintain ongoing communications while changing their point of attachment to the network. Specifically, each mobile entity is always identified by its home address (HoA) (regardless of its current point of attachment to the network), which provides information about its point of attachment to a home network. However, when the mobile entity is connected to the network outside of its home network, i.e. when visiting a foreign network or a foreign domain, the mobile entity is also associated with a care-of address (CoA) that provides information about its current point of attachment. Those of ordinary skill in the art should realize that the term “care-of address” is not meant to be limited to any particular client/server mobility mechanism but covers other terms used in the art that describe a topologically correct address such as, for instance, a “point-of-presence address.”
Typically, such systems can include one or more agents and mobility routers that utilize a protocol for facilitating the mobility management of the mobile entities (mobile routers and/or mobile nodes). The mobility router is an entity, on the mobile entity's home network that tunnels data packets for delivery to the mobile entity, and maintains current location information for the mobile entity for proper delivery by a serving agent.
A mobile internet protocol (Mobile IP) enabled system is one well known example in the art of a mobility management system. Presently there are two standard implementations of Mobile IP, MIPv4 and MIPv6, with corresponding NEtwork MObility extensions thereof, NEMOv4 and NEMOv6, which define support for enabling mobility management for mobile networks (i.e. mobile routers and their attached nodes). NEMO protocols may also define a dynamic prefix allocation mechanism for enabling the mobile router to dynamically configure a Mobile Network Prefix (MNP) for its mobile network; where the MNP can be defined as a bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the IP topology. All nodes in a mobile network necessarily have an address containing this prefix.
Mobile IP protocols provide IP mobility for mobile nodes and mobile networks (i.e. a mobile router and its attached IP subnet) respectively. Mobile IP provides for a registration process for registering a care-of address with a mobility server called a home agent (HA) whose point of attachment, i.e., its IP address, is in the mobile node's home network. The home agent registration is what enables the home agent to send the data packets destined for the mobile node, i.e., outbound data packets, through a tunnel to the care-of address. After arriving at the end of the tunnel, each data packet is then delivered to the mobile node. Such tunneling is used to deliver both inbound and outbound data packets through the mobile node's home agent.
However, there may be shortcoming to have all data packets go through the mobile node's home agent. There may be some situations where peer-to-peer communications (i.e., wherein data packets are not routed through a mobile node's home agent) may be desired when tunneling is being implemented so as to prevent data from being routed along paths that are significantly longer than optimal. For example, if a mobile node is visiting some subnet, even data packets from another mobile node on the same subnet must be routed through the mobile node's home agent (on its home network), only then to be tunneled back to the original subnet for final delivery. This indirect routing delays the delivery of the datagrams to mobile nodes, and places an unnecessary burden on the networks and routers along their paths. Hence, one major limitation of the Mobile-IP and NEMO protocols tunneling scheme is the suboptimal routing due to the forwarding of packets via the HA. This issue is particularly critical in the case of communications between two mobile entities (MEs), especially when the two MEs are topologically-close one to the other but are far away from the HA(s). A typical example of the latter scenario is the case of two firemen at an incident scene.
One way known in the art of implementing peer-to-peer communication when tunneling is implemented is through route optimization. Route optimization provides a means for a correspondent node to maintain a binding cache containing the care-of address of one or more mobile nodes. When sending data to a mobile node, if the sender has a binding cache entry for the destination mobile node, it may tunnel the data directly to the care-of address indicated in the cached mobility binding. In the absence of any binding cache entry, data destined for a mobile node will be routed to the mobile node's home network and then tunneled to the mobile node's care-of address by the mobile node's home agent in accordance with standard Mobile IP.
One shortcoming of route optimization known in the art is the high signaling overhead associated with rendering the route optimization secure. Indeed, before placing a binding between a mobile entity's home address and care-of address in its binding cache, a correspondent node must ensure that both addresses belong to the mobile node for which the binding is provided. This is known as the address ownership problem, which if not solved may introduce various types of attacks such as traffic redirection attacks.
At present MIPv4, NEMOv4, and NEMOv6 protocols from the IETF do not support route optimization. MIPv6 supports route optimization between a correspondent node (that may also be a mobile node) and a mobile node, but at the cost of very high signaling overhead: six messages are required for MN-CN (Mobile Node-Correspondent Node) route optimization, to be exchanged each time the MN changes IP subnet. This message overhead is also doubled for route optimization between two mobile nodes. In addition this procedure cannot support route optimization for mobile routers. Other alternatives known in the art either lack scalability (e.g. assume an existing security association between any MN or a MN's HA and any CN), or do not support mobile routers, or require specific extensions in the visited network which obviously limits the ability to deploy such a system.
What is needed is a technique for optimizing the routing between two mobile entities that is secure, efficient, and can be easily implemented. As far as security is concerned, a correspondent node should be capable of verifying that the node sending route optimization messaging is authorized to do so for the home address in order to avoid risk or traffic redirection attacks. As far as efficiency is concerned, a secure route optimization process should introduce minimal signaling overhead. As far as implementation is concerned, a network managing a fleet of mobile entities should be able to control when route optimization is to be realized between any two of its mobile entities. This would allow for any type of route optimization triggering policies to be supported by the network.
Currently there is no prior art providing such a secure, efficient and manageable route optimization between mobile entities, be they mobile nodes or mobile routers. Thus, there exists a need for a technique to provide a secure, efficient and manageable route optimization for one mobile entity to tunnel data packets to a second mobile entity, for instance on the same subnet, without the need for the data packets to be first sent to the mobile entity's home agent. It is further desirable that the solution be compatible with mobile IP environments.
Accordingly, the present invention seeks to preferably mitigate, alleviate or eliminate one or more of the above mentioned disadvantages singly or in any combination.
According to a first aspect of the invention there is provided a method for route optimization between the mobile entities in a communication network including at least one home agent and at least two mobile entities. The method comprises the steps of: determining an optimized route from a first mobile entity to a second mobile entity by a first home agent; delivering the route optimization information from the first home agent to the first mobile entity; and configuring the first mobile entity using the route optimization information to enable routing of data packets from the first mobile entity to the second mobile entity bypassing the at least one home agent.
According to another aspect of the invention there is provided a network for route optimization between at least two mobile entities. The network comprises: at least two home agents serving the at least two respective mobile entities, the home agents determine an optimized route between the mobile entities, receive a trigger to provide route optimization information to each respective mobile entity, and securely deliver the route optimization information to their respective mobile entities; and each mobile entity configuring itself using the route optimization information to enable routing of data packets between the mobile entities bypassing the home agents.
These and other aspects, features and advantages of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.
The features of the present invention, which are believed to be novel, are set forth with particularity in the appended claims. The invention, together with further objects and advantages thereof, may best be understood by making reference to the following description, taken in conjunction with the accompanying drawings, in the several figures of which like reference numerals identify identical elements, wherein:
The present invention provides a technique for optimizing the routing between two mobile entities that is secure, efficient, and can be easily implemented. A mobile entity verifies that the node sending route optimization messaging is authorized to do so for the home address in order to avoid risk or traffic redirection attacks. As far as efficiency is concerned, a secure route optimization process is implemented in the present invention that introduces minimal signaling overhead. As a result, a network managing a fleet of mobile entities is able to control when route optimization is to be realized between any two of its mobile entities, which allows for any type of route optimization triggering policies to be supported by the network. In particular, the present invention provides a secure, efficient and manageable route optimization for one mobile entity (mobile node or mobile router) to tunnel data packets to a second mobile entity without the need for the data packets to be first sent to the mobile entity's home agent, while being compatible with mobile IP environments.
In operation, the present invention relies on the re-use of existing security association between a mobile entity and its home agent, which is very simple to implement and provides stronger security than other methods known in the art. The secure route optimization solution of the present invention is much more efficient than any of the other solutions know in the art. Indeed, only two messages may be sufficient for providing (secure) route optimization information to a mobile entity in the case where the process is initialized by the mobile entity, and only one message may be sufficient in the case where the process is initiated by the network.
The present invention provides a network with the control of the route optimization process and allows for any type of route optimization triggering policies to be supported, without requiring any extension/modification to the visited network. The solution is applicable both to mobile nodes and mobile routers referred herein as mobile entities (ME); both in IPv4 or IPv6 environments. In addition, this scheme works for both Collocated Care of Address mode and Foreign Agent-CoA mode of operation for MIPv4. Further, it provides a means of Route Optimization between mobile entities using either of these modes. The present invention also enables route-optimization for inter-agency communications, using techniques for HAs of different domains to dynamically discover each other, and securely exchange information therebetween for enabling route optimization between MEs served by HAs in different domains.
In practice, the present invention leverages an existing (Mobile-IP) security association between a mobile entity (ME) and its home agent (HA) for securely delivering route optimization information from the ME's HA to the ME. Said route optimization information refers to other mobile entities (e.g. home address/care-of address binding of another mobile entity).
The present invention discloses the use of a novel Route Optimization Information Notification (ROI_NOTIFY) message from a Home Agent to one of its Mobile Entities. The message includes the necessary information for the mobile entity to send data packets to another mobile entity that is possibly attached to a different Home Agent along an optimized routing path. The information in the ROI_NOTIFY message typically includes a target ME home address (HoA), mobile network prefix (MNP) if the target ME is a mobile router, care-of address (CoA), and a lifetime. Using the information contained in the ROI_NOTIFY message, the ME will configure its IP stack to route data packets to the target ME along an optimized path. Various embodiments are described herein, considering both IPv4 and IPv6 contexts.
The present invention also introduces novel ROI_REQUEST and ROI_REPLY messages for requesting route optimization information, and a novel Route Optimization Control Function for facilitating route optimization with multiple Home Agents. In addition, the present invention provides a technique for HAs of different domains to discover each other, and provides a technique for triggering route optimization either from the network or from the ME. The different domains may be, for example, police, fire dept., etc.
Included in the network 12 is a mobility server or home agent (HA1) 40 for mobile entity (ME1) 20, and included in the network 10 is a home agent (HA2) 50 for mobile entity (ME2) 30. Mobile entity ME120 must register a care-of address with HA140 when its point of attachment is in a foreign network (i.e., a network other than network 12) so that HA140 may tunnel data destined to mobile entity ME120 to that care-of address. Likewise, mobile entity ME230 must register a care-of address with HA250 when its point of attachment is in a foreign network (i.e., a network other than network 10) so that HA250 may tunnel data destined to mobile entity ME230 to that care-of address. It should be recognized that HA1 and HA2 may also be the same home agent.
A novel aspect of the present invention consists in leveraging an existing security association and security protocol, such as Mobile-IP, IPsec etc., between a mobile entity (ME) and its home agent (HA) for securely delivering route optimization information from the ME's HA to the ME; the said route optimization information referring to other mobile entities (e.g. home address/care-of address binding of another mobile entity). Upon determining an optimized route from (or between) a mobile entity by its serving home agent, the serving home agent delivers the route optimization information to the served mobile entity using an existing Mobile IP security protocol, whereupon the served mobile entity is configured using the route optimization information to enable routing of data packets from the first mobile entity to the second mobile entity bypassing the serving home agent.
Similarly, a second home agent (or the same home agent) serving a second mobile entity can determine an optimized route between the mobile entities, deliver the route optimization information from the second home agent to the second mobile entity using an existing Mobile IP security protocol, whereupon the second mobile entity is configured using the route optimization information to enable routing of data packets between the first and second mobile entities bypassing the home agents.
In the embodiment of
When the network (e.g. a “Route Optimization Control Function” in the corporate network), decides (e.g. based on route optimization policies) that route optimization should be established between the two mobile entities ME1 and ME2, the network triggers the sending of Route Optimization Information Notification messages (ROI_NOTIFY) from HA1 and HA2 to ME1 and ME2 respectively. The ROI_NOTIFY message sent from HA1 to ME1 includes the necessary information for ME1 to send data packets to ME2 along an optimized routing path. This information includes ME2_HoA (and also ME2_MNP if ME2 is a mobile router), ME2_CoA, and a lifetime (i.e. the amount of time the route optimization information is considered valid).
Similarly, the ROI_NOTIFY message sent from HA2 to ME2 includes ME1_HoA (eventually ME1_MNP), ME1_CoA, and a lifetime. A ROI_NOTIFY message can potentially include route optimization information for different target nodes. Also, it can be implemented as a new message, or an extension of an existing MIPv4/6 (or NEMOv4/6) message (e.g. MIPv6 Binding ACKnowledge, MIPv4 Registration Reply, etc.).
The ROI_NOTIFY message sent from HA1 to ME1 may be secured by leveraging the existing security association between ME1 and HA1. This security association may be a Mobile IP security association or an IPsec security association. Similarly The ROI_NOTIFY message sent from HA2 to ME2 may be secured by leveraging the existing security association between ME2 and HA2.
Using the information contained in the ROI_NOTIFY message, each of ME1 and ME2 will configure its IP stack to route packets to the other along an optimized path. For instance, in a first embodiment, ME1 will configure a tunnel interface towards ME2_CoA, and route any IP packet which destination address matches ME2_HoA or ME2_MNP through the said tunnel; (and thus bypassing the ME1's MIP tunnel to its home agent HA1). ME2 will perform similar operations for ME1. This configuration is typically applied when both ME1 and ME2 have a co-located care-of address (CCoA); where a CCoA can be defined as an externally obtained local address which the mobile entity has associated with one of its own network interfaces. This is illustrated in
In an alternative embodiment, where the two mobile entities are MIPv6 mobile nodes (MN1 and MN2), the mobile entities can use the MIPv6 home address options and type-2 routing header (as per MIPv6 specification) instead of a tunnel to route data packets between them along the optimized path.
In another alternative embodiment of
In another embodiment where the destination mobile entity ME2 is a mobile node (i.e. not a mobile router) attached to a Foreign Agent; only one tunnel bound to the FA-based care-of address (ME2_FA-CoA) is needed for sending packets to ME2 (i.e. ME2_HoA) along an optimized path. If the source mobile entity (MN or MR) is using a co-located care-of address then this address should be used as the source address of the route optimization tunnel. On the other hand, if the source mobile entity (MN or MR) is using a FA-based care-of address, then it can use either this address or its home address as the source address of the route optimization tunnel.
A Home Agent (e.g. HA1) can obtain Route Optimization Information concerning a target Mobile Entity (e.g. ME2) in various ways such as:
In another embodiment of the present invention of
The ROI_REQUEST message includes (at least) the IP address of the target node for which route optimization information are requested. This is typically the home address of a mobile entity (see
As for the ROI_NOTIFY message, The ROI_REQUEST and ROI_REPLY messages exchanged between a mobile entity (e.g. ME1) and its home agent (e.g. HA1) can be secured using a Mobile IP/NEMO security protocol. In particular, these messages can be secured by leveraging the existing security association between the mobile entity (e.g. ME1) and its home agent (e.g. HA1). For instance, this security association can be a Mobile IP security associated (e.g. as per RFC 3344, or RFC 4285) or an IPsec security association (e.g. as per 3776).
Note that if the target node is a node behind a mobile router (e.g. LFN2 behind MR2, as in
Finally, note also that if the target node is a node for which no route optimization information are available (for instance because the target node is a fixed node) then a ROI_REPLY message with an appropriate error code is sent to the requestor.
Of course, the ROI_REQUEST can potentially include IP addresses of multiple target nodes; and the ROI_REPLY include route optimization information for different target nodes. Both messages can be implemented as a new message, or as an extension of an existing MIPv4/6 (or NEMOv4/6) message.
Optionally (and preferably), the delivery of route optimization information relating to a second node (e.g. ME2) to a first node (e.g. ME1) should also trigger the delivery of route optimization information relating to the first node (e.g. ME1) to the second node (e.g. ME2). This will provide bi-directional route optimization between the two nodes. The trigger (see step 3 in FIG. 5/
In the embodiment where the ROCF is used, a specific interface exists between Home Agents and the ROCF. Firstly, this interface allows any HA to obtain Route Optimization Information for a specific target node, e.g. upon reception of a ROI_REQUEST message. The ROCF (possibly with the help of the Route Optimization Policy Server ROPS and Route Optimization Information Server ROIS) will verify whether route optimization is authorized between the requestor ME and the target ME, and if authorized retrieve the associated route optimization information. Any type of route optimization policy can be implemented at the ROPS; for instance allowing Route Optimization (RO) only between mobile entities of the same agency or between mobile entities of collaborating agencies (e.g. police and firemen). The ROIS functional entity may be implemented as a centralized server (as shown) or in a distributed manner. For instance, each HA in the system may co-locate a ROIS that will manage a database made of only the bindings of the mobile entities of the said HA (i.e. from the HA's binding cache). In that case, the ROCF would contact HA2 to get ME2's binding/ROI and respectively would contact HA1 to get ME1's binding/ROI. Secondly, the interface allows the ROCF to trigger the sending of ROI_NOTIFY from a ME's HA to the ME.
Of course, any of the ROCF, ROPS, and ROIS can be co-located or not; and any of these functions (or all) can be collocated on a home agent.
There are also mobility considerations in route optimization. When route optimization is used between two mobile entities ME1 and ME2, and one of the two (e.g. ME1) moves to a new visited network, a ROI_NOTIFY message containing route optimization information of ME1 should be sent from ME2's HA to ME2.
Again this can be implemented in different ways. In one embodiment, the ME2's HA receives a trigger message from ME1's HA including the updated ME1 route optimization information. In another embodiment, the ME2's HA receives a trigger message from a ROCF in the network for sending the new ROI_NOTIFY with the updated ME1 route optimization information. In both cases, the trigger message received by ME2's HA may contain ME2's identity (e.g. ME2 home address), in addition to the ME1 route optimization information, for indicating to ME2's HA the identity of the mobile entity (here ME2) that needs to be updated with ME1's route optimization information via a ROI_NOTIFY. When the ROCF is used, it can be informed of any change in the binding database by the ROIS, the binding database being updated by a HA (e.g. ME1's HA) each time the later receives a new binding from one of its ME (e.g. ME1).
Note that when a ROCF is present in the network, the first way of sending the ROI_NOTIFY message to ME2's HA (i.e. from ME1's HA) can be activated dynamically by the ROCF; in which case the ROCF delegates the sending of the ROI_NOTIFY messages to the ME1's HA.
In both cases, the entity sending the trigger (ROCF or ME1's HA) maintains a list of corresponding mobile entities (e.g. ME2) which are using route optimization with ME1 in order to trigger the sending of a ROI_NOTIFY message with the updated information forwarded to all of them as ME1 changes of care-of address. This list can be established at the time the route optimization is established (i.e. authorized) between the two nodes (see the create ROI states in
The present invention also has security and inter-agencies considerations. Since ROI_REQUEST, ROI_REPLY, and ROI_NOTIFY messages are exchanged between a mobile entity and its home agent, these messages can be authenticated by leveraging the existing Mobile-IP/NEMO mobility security association that exists between those entities (and that is used to secure Mobile-IP/NEMO signaling messages between them). As per Mobile IP specification (RFC 3344), a Mobility Security Association is a collection of security contexts, between a pair of nodes, which may be applied to Mobile IP protocol messages exchanged between them. Each context indicates an authentication algorithm and mode (e.g. HMAC-MD5), a secret (a shared key, or appropriate public/private key pair), and a style of replay protection in use (e.g. timestamps or “nonces”).
For instance, in the case of Mobile IPv4/NEMOv4, the ROI_NOTIFY and ROI_REPLY messages can be authenticated in the same way as a Registration Reply message from the HA to the MN, using the existing mobility security association. Similarly, the ROI_REQUEST message can be authenticated in the same way as a Registration Request message, using the existing mobile security association. The same approach can also be used with Mobile IPv6/NEMOv6 irrespective of whether a mobility security association ala Mobile-IPv4 (RFC 4285) or instead an IPsec security association (default mode as per RFC 3775) is used to secure the Mobile IPv6/NEMOv6 messages.
Assuming the Mobile Entity trusts information (e.g. route optimization information of a target node) sent by its Home Agent, it is sufficient for the ME to authenticate the messages as being sent by its HA for considering the received information as valid.
In addition, it can be assumed that HA1-HA2 link is secured in the case of HA1-HA2 direct communications, or HA1 and HA2 have trust relationship with the ROCF (and other logical nodes mentioned previously) in the case of HA1-HA2 indirect communication via ROCF. Both these trust relationships can be established in a number of ways such as:
An embodiment of the present invention for the inter-agency scenario is described below, based on dynamic security association establishment using a PKI. Consider two agencies A and B which need to provide route optimization between their mobile entities. Agency A owns the ROCF that needs to be used for route optimization management of mobile entities of both agencies. A PKI infrastructure is used to provide certificates to the ROCF and all HAs of agency A as well as to all HAs of agency B. Note that the certificates for agency A and B can potentially be issued by different Certificate Authorities (CA) as long as a trust relationship can be verified between the CAs (e.g. using known PKI interconnection techniques such as a Bridge CA or a Mesh of CAs).
Using their certificates and the IKE protocol, any HA of agency B can mutually authenticate with the ROCF of agency A and dynamically establish an IPsec security association between them for securing the exchange of route optimization information. This way the ROCF can control the agency an HA belongs to and determine whether it will or not provide the route optimization service for this HA.
In the specific situation where route optimization needs to be supported only between mobile entities of a same Home Agent, the use of a Route Optimization Information Server (ROIS, and its associated database) is not required and can be replaced by the HA's local binding cache. Similarly the Route Optimization Policy Server (ROPS, and its associated database) can be replaced with a local policy file available on the HA. The Route Optimization Control Function (ROCF), then preferably co-located on the HA, is thus simplified and only needs to interact with the route optimization local policy file, and the binding cache.
Considering Mobile VPN (Virtual Private Network), in some specific scenarios the mobile entities may use a VPN service (in addition to Mobile IP) to connect to a network, known as a Mobile VPN (MVPN) solution. A Mobile VPN solution is for instance achieved by combining the Mobile IP tunnel (between the mobile entity and the Home Agent in the corporate network) with a VPN tunnel (between the mobile entity and a VPN gateway in the corporate network). The VPN tunnel is bound to the home address (HoA) of the mobile entity, and maintained thanks to the Mobile IP tunnel as the mobile entity changes IP subnet. In other words, in this case, the VPN tunnel is nested inside the Mobile IP tunnel. The confidentiality provided by the VPN service allows the mobile entities to exchange data between them in a secure manner, via the MVPN tunnels of each of the mobile entities.
When route optimization is achieved between the two mobile entities, the data exchanged between them should still be provided the same level of security as when routed via the network (i.e. via HA+VPN gateway). To address this issue, in another embodiment of the invention, the route optimization tunnel used between the two mobile entities is secured (e.g. provides authentication and/or encryption). This can be implemented in various manners; for instance by using IPsec (and IKE) for securing the route optimized tunnel bound to the care-of addresses (see
The present invention envisions different methods of triggering route optimization. There are several methods of triggering RO, depending on the use case scenario and policy settings of the system. If the two MEs involved in the RO are both served by the same HA, then it is fairly easy to assume the HA can trigger the RO process based on the proximity (geographic or otherwise) of the MEs in question, based on each MEs CoA. The HA can for instance use a map of the network topology (including addressing information) for that purpose.
The following methods can be used for triggering Route Optimization between 2 MEs served by different HAs in the same domain or agency.
In a first method, a location tracking database or server can be used to trigger RO or inform an inquiring HA1 on the location of ME2 based on the known ME2's HoA (HA1 already knows ME1 by its HoA-CoA mapping). The ROCF function can be involved here as well to determine if RO should occur. For example, HA1 queries the location database after a certain threshold of time or amount of data sent for the location (e.g. care-of address) of what it knows to be the CN (ME2 in this case). The location database server replies with the location (e.g. care-of address) of ME2 (whose mobility is managed by HA2). HA1 provides the location server with the HoA of the ME2 as part of the query.
A second method for triggering route optimization between two MEs served by different HAs in the same domain or agency relies on direct interaction between the HAs (without the need for a location server). In this approach, all HAs in a domain can be configured with the mappings of HoA ranges to specific HAs, so HA1 can query HA2 directly for CoA of ME2, simply based on the knowledge of ME2's HoA. This avoids the needs for interacting with a location tracking database or server. As a worst case, if HAs have no location info at all, we can still trigger RO when HA1 detects that ME2 is on the same subnet as ME1 (i.e. ME1 and ME2 care-of addresses share the same network prefix). Otherwise geographic proximity can be considered by HA1 for triggering (i.e. by using either real geographic location information or other means such as a map of the network topology including IP addressing information).
If the two HAs are in different domains, similar approaches can be used for triggering RO between two MEs served by HAs in different domains/agencies.
A first approach can rely on collaboration between location servers/ROCF (managing geographical or topological location information) of the two domains, for providing location information (e.g. care-of addresses) relating to nodes of a first domain to a second domain. The following solutions can be used to allow location servers of different domains to discover each others, and securely exchange information between them for the purpose of route optimization, such as:
a) Each location server can be pre-configured with the IP address of location servers of collaborating agencies together with the Home Address (HoA) ranges they serve. When this solution is used,
b) Preferably, the discovery can also be achieved dynamically by using DNS for instance. In particular, DNS lookup by Location Server name (e.g. “location_server.domain2.com”), or DNS lookup by service name (i.e. using “SRV” RR as per RFC 2782) can be used. When this solution is used,
Security Association between location servers of the different domains or agencies can be pre-configured, or preferably dynamically established for instance by having location servers mutually authenticating via the AAA infrastructure, or using a PKI.
A second approach for triggering route optimization between MEs served by different HAs in different domains or agencies can rely on direct communications between HAs of the different domains. The following solutions can be used to allow HAs of different domains to discover each other, and securely exchange information between them, such
a) Each HA can be pre-configured with the mappings of HoA ranges to specific HAs at least within its own domain. When this solution is used,
b) Preferably, the discovery of the IP address of an HA2 serving a target ME2 can be achieved dynamically for instance using DNS by: 1) Sending a Reverse DNS request to get ME2 Fully Qualified Domain Name (FQDN) or hostname (e.g. “me2.domain2.com”) from ME2 home address (ME2_HoA), 2) Deriving the ME2 domain (e.g. “domain2.com”) from ME2 FQDN, and 3) Sending a DNS request to get the IP address of the Home Agents (including HA2) serving the domain of ME2, either with DNS lookup by Home Agent name (e.g. “ha.domain2.com”), or DNS lookup by service name (SRV RR—i.e. a request with QNAME set to “_mip6._ipv6.domain2.com” and QTYPE to SRV).
Both DNS lookup approaches can potentially return a list of home agent IP addresses, in case there are multiple home agents deployed in the domain of ME2. Retrieving, from the list, the particular HA2 serving ME2 can then be achieved in a number of ways such as; a) by contacting each HA of the list one after the other, until the one serving ME2 is reached, or b) by contacting only a single HA in the list (whatever it is), and receiving from this HA the list of HoA ranges served by each HA in the domain of ME2, and from this information retrieving the HA2 serving ME2, which is the preferred approach since it is efficient and simple to implement. (
Whatever the mechanism used for the discovery of HAs in another domain, each HA of a first domain should cache the received information and build/maintain a database of all HAs in other domains with their respective ranges of HoAs. This will speed up the HA discovery process for subsequent need of route optimization between ME in different domains.
Another solution to allow HAs of different domains to discover each other, and securely exchange information therebetween can includes a pre-configured Security Association between Home Agents, or preferably dynamically established for instance by having location servers mutually authenticating via the AAA infrastructure, or using a PKI.
In both intra and inter domain/agency scenarios, when a location server detects (geographical/topological) proximity between two MEs, it may first contact the respective HAs to determine whether communications is ongoing between the two MEs (or even a certain type of traffic) before triggering RO.
The present invention envisions that Route Optimization can be triggered by the network (e.g. by an HA or a Location Server/ROCF) or by a mobile entity. Network-triggered RO can be based on a) location proximity between the MEs, (e.g. by using MEs CoAs with a map of the network topology including IP addressing information, or by using geographical location information such as GPS); or b) based on characteristic of communication between MEs (e.g. triggering RO only after a time threshold, or after a given amount of data exchanged, or for certain type of applications such as audio/video streams/conferences, etc); or c) based on HA load (for offloading the HA, and thus enabling a form of load balancing).
With respect to ME-triggered route optimization, some level of situational awareness can be assumed by the MEs/applications when at incident scenes (e.g. the fact that a specific RAN is used). This can trigger the ROI handshake process by the MEs as described above. For example, certain applications may be tailored for incident scene usage, such as peer-to-peer video sharing. The launching of this application and communication to another node could trigger each ME to send a ROI request to its respective HA. This is true for both intra and inter-domain cases. Optionally (in the inter-domain cases), before sending the ROI request to its HA, the ME could query its correspondent ME (using specific ME-to-ME signaling, routed via the HAs) about the IP address of its Home Agent. This information could then be sent by the ME to its own HA to facilitate discovery of the correspondent ME HA.
Advantageously, the present invention leverages an existing (Mobile-IP) security association between a mobile entity (ME) and its home agent (HA) for securely delivering route optimization information from the ME's HA to the ME; the said route optimization information referring to other mobile entities (e.g. home address/care-of address binding of another mobile entity). The solution provided is unique because it meets all the requirements of a secure, lightweight, and manageable route optimization solution. It is secure in that it relies on the re-use of existing security association between a mobile node and its home agent. It is very simple to implement; and no extra keying materials are required (thus simple to manage). In addition, the security provided is stronger than with some other method known in the art such as the default Return Routability procedure (see RFC 3775). It is efficient in that a maximum of two messages (ROI_REQUEST and ROI_REPLY) is sufficient for providing (secure) route optimization information to a mobile entity, in the case of the process being initialized by the mobile entity, and only one message is needed (ROI_NOTIFY) in the case where the process is initiated by the network. It is also important to note that only one message is needed to update the route optimization information of a target node as the target node moves. This compares to the six messages of the prior art standard return routability procedure needed for the initialization as well as for each change of IP subnet. It is manageable in that the solution provides the network with the control of the route optimization process and allows for any type of “route optimization triggering” policies to be supported. Such manageability allows on one hand reducing the signaling/memory overhead associated with supporting route optimization for the every mobile nodes, and on the other hand supporting differentiation with respect to the “route optimization” service. In addition, the solution does not require any extension/modification to the visited network. Further, the solution is applicable both to mobile nodes and mobile routers; both in IPv4 or IPv6 environments. In addition, this scheme works for both Collocated Care of Address mode and Foreign Agent-CoA mode of operation for MIPv4. Further, it provides a means of Route Optimization between MEs using either of these modes. Moreover, the present invention also enables route-optimization for inter-agency communications.
The present invention has been described with respect to a mobility management system that utilizes mobile IP. However, it should be understood by those of ordinary skill in the art that the present invention may also be used in systems that use a different client-server based (and perhaps proprietary) mobility management mechanism. For instance, as long as there is a mobility server or router in the system that handles mobility management for clients, and as long as the clients inform the mobility server of their IP point of attachment, this invention can be applied.
Advantageously the present invention bases route optimization on the care-of address of the mobile node and hence provides a method of route optimization between two mobile nodes.
In practice, the present invention is implemented as follows:
This document describes extensions to the Mobile IPv6 protocol [2] and Network Mobility (NEMO) Basic Support protocol [1] for enabling route optimization between two mobile entities. A mobile entity can be a mobile node or a mobile router. These extensions allow the home agent of a mobile entity to securely deliver to the mobile entity route optimization information referring to another mobile entity attached to the same or a different home agent.
Three new messages are specified which are the Route Optimization Information Request, Reply, and Notify messages. These messages are authenticated (and eventually encrypted) by leveraging the existing security association between a mobile entity and its home agent, thus enabling secure route optimization between two mobile entities.
The Route Optimization Information (ROI) of a target mobile entity refers to the information that can be used by a source mobile entity to sent packets towards the target mobile entity along an optimized route, bypassing the home agent of the target mobile entity.
The ROI of a target mobile entity includes the following information:
The Route Optimization Information (ROI) Request message is sent by a mobile entity to its home agent for requesting route optimization information of a target node. ROI Request messages are sent as described in section 4.
The ROI Request message follows the Mobility Header format specified in Section 6.1 of [2] and illustrated in
The ROI Request message uses the MH Type value (To Be Defined). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is shown in
The Route Optimization Information (ROI) Reply message is sent by a home agent in response to a ROI Request message. ROI Reply messages are sent as described in section 4.
The ROI Reply message follows the Mobility Header format specified in Section 6.1 of [2].
The ROI Reply message uses the MH Type value (To Be Defined). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as shown in
The Route Optimization Information (ROI) Notify message is sent to a mobile entity by its home agent for notifying the mobile entity about Route Optimization Information of a target mobile entity. ROI Notify messages are sent as described in section 4 and as shown in
A mobile entity sends ROI Request messages to its home agent for requesting route optimization information of a target node.
If the mobile entity expects a one-time ROI Reply containing the requested route optimization information but no update when this route optimization information changes it should set the ROI Req Type in the ROI Request message to value 0 (Simple Request without ROI Refreshment).
If the mobile entity expects a ROI Reply containing the requested route optimization information, together with receiving updates (through ROI Notify messages) when the route optimization information changes, it should set the ROI Req Type in the ROI Request message to value 1 (Request for activating ROI Refreshment).
If the mobile entity requests termination of the update of the route optimization information changes it should set the ROI Req Type in the ROI Request message to value 2 (Request for terminating ROI Refreshment).
4.2.1 Receiving ROI Request with ROI Req Type Set to 0 or 1
A home agent receiving a ROI Request message with ROI Req Type set to 0 or 1 may determine if the node sending the request is authorized for receiving route optimization information of the target node address indicated in the ROI Request message. The authorization process may include the step of authenticating (and identifying) the source of the message and consult a set of route optimization policy rules.
If the sending node is not authorized, the home agent may reply with a ROI Reply message with Status field set to 129 (Administratively prohibited).
If the sending node is authorized for receiving the requested route optimization information, the home agent may retrieve the route optimization information of the Target Address indicated in the received ROI Request message. The home agent may use different means for this purpose such as:
A mobile entity receiving a ROI Reply message with Status set to 0, or a ROI Notify message, from its home agent may create (or update) an entry for the received route optimization information in its Route Optimization Information cache (ROI cache). This entry can then be used by the mobile entity for the purpose of optimization routing towards the target mobile entity corresponding to the received route optimization information.
A mobile entity receiving a ROI Reply message with Status set to 1, may first determine if a corresponding ROI Request (with the same sequence number and a ROI Req Type set to 2) had been sent for the said target mobile entity address:
A mobile entity may use information in its ROI cache for optimizing routing towards a target node. If the destination address of a packet to be sent (or forwarded) by the mobile node matches the home address or mobile network prefix of one of the ROI entry in the ROI cache, the mobile entity may tunnel the packet towards the care-of address indicated in the corresponding ROI entry, using IPv6 tunneling or other type of tunneling (e.g. UDP tunneling as needed, e.g. for IPv4 NAT traversal).
The ROI Request message may be authenticated in one of the following ways:
The sequences and methods shown and described herein can be carried out in a different order than those described. The particular sequences, functions, and operations depicted in the drawings are merely illustrative of one or more embodiments of the invention, and other implementations will be apparent to those of ordinary skill in the art. The drawings are intended to illustrate various implementations of the invention that can be understood and appropriately carried out by those of ordinary skill in the art. Any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiments shown.
The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term comprising does not exclude the presence of other elements or steps.
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by e.g. a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also the inclusion of a feature in one category of claims does not imply a limitation to this category but rather indicates that the feature is equally applicable to other claim categories as appropriate.
Furthermore, the order of features in the claims do not imply any specific order in which the features must be worked and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus references to “a”, “an”, “first”, “second” etc do not preclude a plurality.
| Number | Date | Country | Kind |
|---|---|---|---|
| 07300997.9 | Apr 2007 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US08/61374 | 4/24/2008 | WO | 00 | 8/11/2009 |
