Patent Application
20100177698
The present invention relates to a network architecture for providing Network-Based Local Mobility Management (NetLMM), and in particular to a network architecture using Host Identity Protocol (HIP) proxies as Access Routers.
As is well known, a mobile node 5 may connect to the network 1 via of a plurality of access points 4 (“AP”). Each access point has a defined area of geographic coverage and, as the mobile node 5 moves, it is “handed-off” from one access point to another when it passes from a geographic area served by one access point to the geographic area served by another access point. It is desirable that the user of the mobile node does not experience any breakdown or interruption in communication when the mobile node is handed-off from one access point to another.
Network-based Local Mobility Management (NetLMM) is an IETF endorsed approach to provide mobile nodes with an illusion of an extended layer 2 link. One specific solution to the NetLMM problem is currently being standardised in the NETLMM working group at the IETF (see http://www.ietf.org/html.charters/NetLMM-charter.html). The basic architecture, as being worked on at the IETF, is described by H. Levkowetz, Editor, et al, “The NetLMM Protocol”, Internet draft draft-giaretta-NetLMM-dt-protocol-02, work in progress, October 2006.
In the network of
In
One aspect of the present invention provides a network comprising an NetLMM domain having at least one Host Identity Protocol proxy coupled to one or more Access Points and acting, in use, as an Access Router.
According to the invention, the NetLMM Mobility Access Gateways/Access Routers of the network of
The invention provides the following additional benefits compared to the existing solution:
Each domain may comprise a respective Local Mobility Anchor coupled to the or each HIP proxy in the domain. In such a case, the network architecture of a HIP Proxy based solution can be a traditional NetLMM like network architecture, where a Local Mobility Anchor (LMA) acts both as a central hub and as the termination of HIP traffic towards the Internet, if needed. The LMA may itself be provided with HIP functionality.
Alternatively, the LMA of a NetLMM domain may be provided with HIP functionality instead of the Access Router(s) of the domain. This provides for mobile NetLMM domains.
Alternatively, two or more of the HIP proxies in a domain may be arranged in a distributed manner, for example as described in co-pending PCT application PCT/EP 2007/055930 filed concurrently herewith, Marks & Clerk Reference P54284WO. The network architecture can be fully distributed, with the necessary gateways to the outside world. The combination of the two inventions allows mobile NetLMM Access Routers to be connected with each other without the need for extra infrastructure.
One or more further HIP proxies may be arranged in a hierarchical manner from one of the HIP proxies arranged in the distributed manner.
The domain may comprise a routing table comprising one or more Bloom filters.
At least one HIP proxy may be a mobile proxy.
A second aspect of the present invention provides a method comprising the steps of assigning one or more Host Identity Protocol (HIP) proxies as respective Access Routers of an NetLMM domain.
The method may additionally or alternatively comprise assigning a Host Identity Protocol (HIP) proxy as a Local Mobility Anchor of the domain.
The method may further comprise the steps of:
a) creating a Host Identity Protocol (HIP) association between an HIP proxy and the NetLMM domain;
b) registering the HIP proxy with the domain as a new proxy service provider;
c) determining whether or not to accept the registration; and
d) if the registration is accepted, using the HIP proxy as an Access Router of the domain.
Step (a) may comprise creating the HIP association between the HIP proxy and the Local Mobility Anchor of the domain. Alternatively, it may comprise creating the HIP association between the HIP proxy and an existing HIP proxy of the domain.
The method may comprise the further step of configuring the HIP proxy with the identity of the NetLMM domain before the step of creating the HIP association between the HIP proxy and the NetLMM domain.
The method may comprise the further step of, if the registration is accepted, sending a registration reply to the HIP proxy.
The method may comprise arranging the HIP proxies in the NetLMM domain in a distributed manner.
The method may comprise the further step of, if the registration is accepted, sending details of the registration to at least one other Access Router in the domain.
The method may comprise the step of assigning a Host Identity Protocol (HIP) proxy as a Local Mobility Anchor of a NetLMM domain.
At least one HIP proxy may be a mobile HIP proxy.
Further aspects of the invention provide an Access Router for a NetLMM domain or a Local Mobility Anchor for a NetLMM domain configured with a Host Identity Protocol proxy.
The Access Router may be adapted to perform, in use, the steps of:
a) creating a Host Identity Protocol (HIP) association with an NetLMM domain;
b) registering with the domain as a new proxy service provider; and
c) if the registration is accepted, acting as an Access Router of the domain.
The Access Router may be adapted to create the HIP association between the HIP proxy and a Local Mobility Anchor of the NetLMM domain.
The Access Router may be adapted to create the HIP association between the HIP proxy and an existing HIP proxy of the NetLMM domain.
The Access Router may be adapted to carry out the further step of configuring the HIP proxy with the identity of the NetLMM domain before creating the HIP association between the HIP proxy and the NetLMM domain.
The Access Router may be adapted to receive a registration reply indicating that the registration has been accepted.
The Access Router or Local Mobility Anchor may be configured with a mobile HIP proxy.
Further aspects of the invention provide a network comprising an Access Router or a Local Mobility Anchor of the preceding aspects.
Preferred embodiments of the present invention will now be described with reference to the accompanying drawings, in which:
As is known, the Host Identity Protocol separates the end-point identifier role and locator role of an IP (Internet Protocol) address. It defines a new global Internet name space, that decouples the end-point identifier role and locator role. With HIP, the transport layer operates on Host Identities rather than using IP addresses as endpoint names, while the network layer uses IP addresses as pure locators.
With HIP, an identifier is the public key of a public-private key pair. The HIP Host Identity (HI), being a public key, can be quite long and is therefore not practical in all situations. In HIP, the HI is represented with a 128-bit long Host Identity Tag (HIT) that is generated from the HI by hashing it. Thus, the HIT identifies a HI. Since the HIT is 128 bits long, it can be used for IPv6 applications directly as it is exactly the same length as IPv6 addresses.
Another representation of the Host Identities is the Local Scope Identifier (LSI), which is a 32-bit representation for the Host Identity. The purpose of the LSI is to facilitate using Host Identities in existing protocols and Application Programming Interfaces (APIs). For example, since the LSI is the same length as an IPv4 address, it can be used for IPv4 applications directly.
When HIP is used, the upper layers, including the applications, no longer see the IP address. Instead, they see the HIT (or LSI) as the “address” of the destination host. The location information is hidden at a new layer, to be described below. The IP addresses no longer identify the nodes; they are only used for routing the packets in the network.
Further details of the HIP protocol can be found in, for example, R. Moskowitz and P. Nikander, “Host Identity Protocol Architecture”, Internet-Draft, work in progress, August 2005 or R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson, “Host Identity Protocol”, Internet-Draft, work in progress, October 2005.
In the embodiment of
The network architecture of the present invention can provide all the features provided by the IETF architecture shown in
One problem with mobile Access Routers is security. If an Access Router is mobile, the available security level of the access networks is likely to fluctuate as the Access Router moves. The present invention can provide high security even with a mobile Access Router, since a HIP mobile proxy may establishes a secure channel between an Access Router and the associated LMA, thereby preventing hijacking of the connection or tracking of mobile nodes, and facilitating deployment of mobile Access Routers in insecure networks (although the mobile nodes access network remains unprotected).
Furthermore, all the typical benefits of HIP are available for making the NetLMM domain more flexible, including easy deployment over both IPv4 (IP version 4) and IPv6 (IP version 6), and route optimisation between Access Routers. Moreover, the Access Routers can even be behind NAT (Network Address Translation) boxes, provided that the NAT box is provided between an Access Router and the LMA at which the Access Router is registered.
In a further embodiment of the invention, the Local Mobility Anchors are also embodied as HIP proxies to provide them with HIP functionality. This embodiment is shown schematically in
In a further embodiment of the invention, a Local Mobility Anchor of an NetLMM domain is embodied as an HIP proxy to provide it with HIP functionality, instead of the Access Routers. This embodiment is shown schematically in
The network architectures of
The invention may also be applied to a partly-distributed architecture, for example as shown in
Access Router 13d maintains the individual routing information (for example Bloom filters) for the Access Routers 13e,13f that are underneath it as well as its own local routing information (Bloom filter). Upon arrival of a packet at Access Router 13d, Access Router 13d consults the routing information to determine whether the Mobile Node to which the packet is destined is behind Access Router 13d itself, is behind Access Router 13e, or is behind Access Router 13f, and routes the packet accordingly.
In the embodiments of
Various steps in maintenance of a NetLMM domain of the network architecture of the invention will now be described. By “domain maintenance” is meant dynamic adding or removing of HIP proxies. At the highest level, this does not differ much from the procedures needed in other NetLMM architectures for addition or removal of Access Routers/Mobility Access Gateways. However, on the assumption that all the infrastructure nodes (Access Routers/Mobility Access Gateways, and Local Mobility Anchors if any) implement HIP, it is possible to describe a more detailed solution than do the current IETF documents.
To add a new HIP proxy to a NetLMM domain to serve as an Access Router/Mobility Access Gateway the following procedure, shown schematically in
If the above mentioned HIP registration procedure is used to join the domain, the proxy will be automatically dropped from the domain at the expiry of the registration and/or the issued certificate, unless it is renewed.
A HIP proxy may prematurely stop serving in the domain simply by removing all mobile nodes that are behind it. No other action is needed, as the information will automatically be removed at other proxies as soon as the registration expires.
Alternatively, there may be a separate, signed discontinuation messages, sent to the LMA or distributed to all participating AR/MAGs.
When a new mobile node arrives at some HIP proxy, the Mobile Node needs to be assigned an IPv6 address. This address is assigned from the routing prefix assigned to the domain, as defined in J. Laganier, S. Narayanan, F. Templin, “Network-based Localized Mobility Management Interface between Mobile Node and Access Router”, Internet Draft draft-ietf-NetLMM-mn-ar-if-01, work in progress, June 2006.
There are no fundamental differences in node mobility within a domain between the HIP proxy based architectures of the invention and other NetLMM architectures. Similarly, there are no fundamental differences concerning disappearing mobile nodes between HIP proxy based architectures of the invention and other NetLMM architectures.
There are no fundamental differences in establishment of a connection between the HIP proxy based architectures of the invention and other NetLMM architectures. However, a HIP proxy based architecture allows route optimizations in cases where both mobile nodes are within the same NetLMM domain.
In the case of a distributed HIP proxy based architecture, as shown in
In the case of a traditional hierarchical architecture as in
It should be noted that the invention is not limited to the specific arrangements and numbers of Access Points and Access Routers shown in
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2007/055928 | 6/14/2007 | WO | 00 | 3/25/2010 |
