This application is based on and hereby claims priority to European Application No. 04257487 filed on Dec. 1, 2004, the contents of which are hereby incorporated by reference.
Described below is a method and an access point for transferring data packets from a first portable source endpoint belonging to a first, preferably mobile network to a second destination endpoint belonging to a second, preferably packet oriented network, wherein the first network may be moving relatively to the second network.
The method assigns addresses to nodes, which are connected to a moving network, i.e. a network, which can change location at some point in time.
It is presented a description of a concept for enabling hosts, such as notebooks, personal digital assistants (PDAs) and other network devices attached a moving network to initiate and maintain communications (such as TCP/IP or RTP/UDP connections) with other nodes on the Internet.
A moving network is a “network in motion”, that is a collection of portable nodes (PNs), which move together with (at least) one of them (the mobile router, MR) having a backhaul connection and thus providing the PNs with connection to the rest of the network. A group of moving nodes which commonly move with the same ground speed in the same direction constitute to a moving network. There is at least one gateway router, called mobile router here, which provides access for the contained client nodes (portable nodes) towards external networks. A correspondent node is reached through a transport network in the backhaul.
A Personal Area Network (PAN) in a car or a train network is imaginable such as a managed vehicular network (VN) to represent examples of moving networks. The architecture of a moving network includes one or more special gateway routers. Such a Mobile Router (MR) is enabled with a Mobility Protocol (e.g. Mobile IP (MIP)) to update location information for the moving network in external networks, e.g. network domains in the Internet and to facilitate handover procedures in case there are triggering events, such as movement, profile change etc. In addition to one or more MR there are a number of devices and user terminals that attain connectivity through the MR. The term portable node (PN) is used to refer to those devices, which can be carried y a user and may or may not support mobility, i.e. run a protocol for location updating and handover. However the method described here does not rely on this assumption.
The problem that has to be addressed is the mobility of the whole network. When the VN changes its point of attachment a mechanism must be applied so as to forward to the current location of the VN datagrams destined to nodes in it.
Prior-art mobility management protocols provide support for individual nodes. Extra functionality might be applied to those protocols for supporting networks with the drawback of modifications. The approach where all nodes within the VN are enabled with mobility functionality is not sophisticated since the amount for required location update signalling after handover depends on the number of portable nodes that require such mobility services from the network. Apart from that, the requirement for each PN running a mobility protocol, such as Mobile IP (MIP) eliminates the number of possible nodes that could be part on the VN, since there is no installed base of mobility protocols on PNs.
The method aims to overcome the above mentioned disadvantages.
A main aspect is a method for address translation performed by the home domain of the first moving network, wherein the address of a first endpoint is associated to the home address of the moving network. Further aspects are a mobile access point and a home access point to perform the above mentioned method.
The proposed algorithm provides support for both mobility aware and unaware nodes since the VN's mobility is hidden from he PNs. The IP address assigned to the PN remains unchanged through out the whole duration of the PN's connection to the VN. Additionally another problem that is tackled by the proposed mechanism is the handover from on VN to another, provided that the VNs are managed by the same operator.
The general concept of the method is to use address translation to associate PNs CoA (temporary address) with the MR home address(es). In the following Mobile IP (MIP) is mentioned, but this is an exemplification and in principle other mobility protocols/mechanisms could be taken into account as well. The translation is performed accordingly to a set of identifiers that are used to distinguish inbound and outbound packets and determine which address is used for translation. Translation enables network mobility to be supported without altering existing mobility mechanisms, such as the MIP protocol running on the MR or MR home agent, and further overcomes the addressing restrictions discussed previously. A key feature of the translation is that is uses information from an element external to the network address translator (NAT), i.e. information that is neither encoded within the IP packet header nor statically configured into the NAT unit.
It is assumed that the MR is MIP enabled which means that it has the ability-to maintain all ongoing sessions while changing its point of attachment to the Internet. MIP achieves its goals with the aid of a special router—the Home Agent (HA), which is situated in the home network of the mobile node. The network with network prefix matching that of the mobile node's home address. Packets destined to a MIP enabled node will be directed towards its home network with IP routing. Once within the home network, the packets are intercepted by the HA and tunnelled through to the current IP address (CoA) of the MIP enabled node. Tunnelling refers to the situation, where a packet is encapsulated at an ingress node and de-capsulated at an egress router to enforce the packet to travel on a fixed network path. Thus although MIP takes care of the delivery of packets from the MR home network to the MR care-of address, no support is provided for packets destined to nodes in the VN. This can be bypassed if address translation is performed on all packets generated from PNs in the VN. In every IP packet generated from the PNs the source address field is replaced by an MR home address, HoA. This results in response packets generated by correspondence nodes, CNs, to be destined to the same address (MR HoA) and consequently, with the aid of MIP, the packets are finally delivered to their final destination.
When a node connects to the VN it attains an IP address from the MR. Since this is a private address in principle it may not have to obey to any addressing restrictions imposed for routing packets in public networks. Different mechanisms can be employed for achieving this. One option is the dynamic allocation of an IP address for the PN e.g. through the use of Dynamic Host Configuration Protocol (DHCP). A different address allocation mechanism is associated with stateless auto-configuration like suggested for IPv6 networks. Any valid address space (which can be used for routing packets) can be used for providing addresses to hosts. This is a consequence of the address translation, which hides the real address of the hosts from other nodes on the Internet. More precisely the addresses assigned to the PNs are employed only for the communication which the VN. This gives a broader scope of possible addresses to allocate to PNs. Private addresses and MR subnet addresses are only one subset of the possible address range.
The major advantages of the proposed method are:
These and other objects and advantages will become more apparent and more readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawing in which:
Reference will now be made in detail to the preferred embodiments, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout.
It is assumed that the HA of the MR is responsible for performing the address translation.
In
After a PN has been granted an IP address and has installed the MR as the default router, it is ready to embark communication with other nodes on the Internet. The PN will construct all IP packets in the same way as if it was in a stationary IP network and it will forward them as usual to its default router, the MR in this case. As expected, the source address field of the IP header is set to the IP address assigned to the PN from the MR and the destination address field is set to the IP address of the node with which the PN wishes to communicate.
The MR will receive the packet and it will tunnel it to its HA. Prior to the encapsulation the MR could compress the original IP packet for efficiency purposes. Reducing the upload traffic is beneficial because the available bandwidth is exploited more efficiently and also the financial cost charged from the Ground Network, GN, is reduced in cases like GPRS networks for example where traffic is charged per byte.
When the HA receives the encapsulated packet it removes the outer packet header information and forwards the packet, with additional information, to the NAT device. The additional information is used to manage the address mapping and can include for example the following information:
The NAT device then uses this information, plus information encoded within the packet header (for example the PN source address, the source and destination port identifiers) to maintain its address-mapping table. Finally, the NAT device replaces the PN source address with an address from the MR home network prefix before forwarding the packet along the next hop towards its destination. For IPv4, the checksum of the IP header must also be recalculated.
When the packet reaches the ON it appears as if the MR sent the packet from its home address since the source address field is set to the MR's HoA. As a result, response packets generated from the CN contain the MR's HoA in the destination address field, and are routed with IP routing to the MR's Home Network. Here, the NAT device captures the packets and checks the address mapping table so as to determine if reverse translation is required to the packet. If a match is found then reverse translation is required and consequently the destination address field is altered. More precisely the address allocated to the PN is used instead of the MR's HoA. After the translation, the HA tunnels the packet to the MR, using the MR's CoA as the destination address field of the outer IP packet. (How the packet reaches the HA depends upon whether the HA and NAT are an integrated device or not.) When the packet reaches the MR it is decapsulated and finally forwarded to the PN. If no entry is found to indicate that the packet should undergo translation the NAT realizes that this is a MR destined packet. The diagram in
It has been described how communication is achieved between nodes in the VN and other nodes on the Internet while the VN is away from the MR's home network. The same mechanism is applied when the VN is in the home network, with the only variation being the absence of the tunnel between the MR and the HA. Outbound packets generated from the PN are forwarded to the MR and from there to the NAT without the presence of a tunnel. Translation is performed again and the packet is forwarded to the final destination with IP routing.
A key feature of the proposed method is the capability of the PNs to handover from one VN ton another, e.g. a passenger leaves a train in the station and enters another one. This can occur when both VNs are managed by the same operator, and thus both MRs are being served by the same (or coordinated) HA. Extra intelligence installed at the MR HA would enable PNs to migrate from one VN to another while keeping the same IP address, hence maintaining all active network connections. Since datagrams destined to the PN are delivered towards their destination with the aid of tunnels it is possible for a PN to move from one \IN to another and the only requirement would be for the MR HA to tunnel PN destined messages to the appropriate VN.
In the case where the PN does not change the VN, inbound traffic at the home agent can be routed based on a certain address prefix, which uniquely identifies the destination VN. If handover between different VNs should be supported, while the PN keeps the address, the destination VN can't be identified based on the address prefix of the destination address for inbound packets. Addressing is managed by a central node, the HA, so as to avoid address duplication conditions i.e. where the same IP address is assigned to more than one PN. Whilst centralized addressing affects the HA performance, it offers the advantage that every PN is identifiable by a unique IP address.
When a PN migrates to a different VN, the routing tables in the MR home network have to be updated according to the router advertisements received from the new MR. For outbound traffic, sent by the PN the mechanism for decapsulation and translation in the MR home network are the same just like for a single VN supported by the home network. When the PN sends a datagram, the packet as before is tunnelled to the HA and decapsulated. Before forwarding the packet to the destination address, i.e. the CN, the correct PN source address has to be determined, which is used for address translation. The forwarding of inbound traffic also requires additional steps at the HA compared to the situation with just single VN home networks. For inbound traffic destined for a PN, the correct VN has to be determined before address translation and packet encapsulation can take place. The shortcoming of this solution is that the HA needs to do per host instead of prefix based routing, which delays the forwarding process to some extend. This can be partly compensated if address mappings are cached based on inbound and outbound traffic as well. With this procedure handovers between different VNs have no effect on communication between the PN and the CN since the socket pair remains unchanged at both ends, As a result the PN can move around the VNs and the NAT will be responsible for keeping the same address for address translation and also for tunnelling datagrams destined to the PN to the correct VN. The flowchart of
However the PN may specify during the initial registration with a VN the demand for a future handover to a different VN. In this situation an address could be allocated to the PN from a special address prefix, which indicates that per host routing is required in the home network domain. Consequently if the PN would not specify its-demand for future VN handover, prefix based routing can be applied for packets destined for those PNs. Thus per host routing would be required just or those PNs, which require VN handover in the future.
In the case where the PN is enabled with mobility functionality (i.e. runs a mobility protocol and sends location update information to its home agent) some additions must be applied, because the address assigned to the PN from the MR cannot be employed with macromobility protocols as the address known to the PN may not be globally reachable. One approach to this problem, which has been adopted within the IETF NEMO working group, requires that the address assigned to a PN belongs to a subnet of the MR's home network. Then datagrams directed by the PN home agent will reach the MR's home network, and from there can be delivered to the VN. However, as in the NEMO case, the inefficiency of double tunnelling occurs.
The topologically irrelevant address problem can be surmounted if the PN registers a specific MR home address as a CoA with its home agent (PN_HA). In this case the PN_HA will forward all packets destined to the PN to this address and consequently the datagrams will be captured by the Home Agent of the MR, as shown in
This section contains the functions performed according to the described algorithm during a PN session. First is portrayed the scenario where the translation is executed at the HA. For outband packets:
Scenario 1: PN Registration
Scenario 2: Translation for Outbound Traffic in MR Home Network
Scenario 3: Translation for Inbound Packets in MR Home Network
Scenario 4: Handover between VNs
In the case where a PN performs a handover to another VN managed by the same operator the following steps are followed. Note that in this scenario addressing is managed by the HA thus the IP address that is assigned to the PN is unique.
Scenario 5: Packets, which By-Pass the Translation Process
A description has been provided with particular reference to preferred embodiments thereof and examples, but it will be understood that variations and modifications can be effected within the spirit and scope of the claims which may include the phrase “at least one of A, B and C” as an alternative expression that means one or more of A, B and C may be used, contrary to the holding in Superguide v. DIRECTV, 358 F3d 870, 69 USPQ2d 1865 (Fed. Cir. 2004).
| Number | Date | Country | Kind |
|---|---|---|---|
| 04257487.1 | Dec 2004 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2005/055919 | 11/11/2005 | WO | 00 | 4/18/2008 |