Patent Application
20100296443
This invention relates to the field of telecommunications in a packet-switched data communications network. More particularly, it concerns providing an optimized route to a mobile node having an end-to-end route optimization protocol and hierarchical mobility management protocol implemented.
Many devices today communicate with each other using the Internet Protocol version 6 (IPv6). In order to provide mobility support to mobile devices, the Internet Engineering Task Force (IETF) has developed the “Mobility Support in IPv6 (MIPv6)” [Non Patent Citation 1]. Mobility support is done in [Non Patent Citation 1] with an introduction of an entity at the home network known as a home agent (HA). Mobile Nodes (MNs) register their care-of addresses that they obtain in foreign links with the home agents using messages known as Binding Updates (BU). The above-mentioned BU allows the home agent to create a binding between the home address, which is the long-term address obtained in the home link, and care-of address of the mobile node. The home agent is responsible to intercept messages that are addressed to the mobile node's home address (HoA), and forward the packet to the mobile node's care-of address using packet encapsulation (i.e. putting one packet as the payload of a new packet, also known as packet tunneling). In addition, MIPv6 also specifies a route optimization (RO) method when communicating with a correspondent node (CN). This RO mechanism allows the MN to perform a validated registration of its care-of address at CN so that MN and CN can communicate with each other using MN's care-of address, without having to go through MN's home agent. CN obtains a validated registration of MN's care-of address by means of Return Routability (RR) test that is initiated by MN. This Return Routability test provides a proof to the CN that the care-of address of MN is collocated with MN's home address. This RO mechanism is an optional mechanism and its benefits are obtained only when the CN has some functionality to support RO mechanism.
One problem with MIPv6 is that for a single change in network attachment, the MN needs to update one or more of its home agents and one or more of its correspondent nodes. This increases the signaling load injected into the network for fast moving MN. Moreover, the average hand-off establishment time with CN per change in network attachment is high as every single change in network attachment involves transmission of RR and BU messages. Thus, during a session associated with a flow or connection, considerable amount of time is allocated to hand-off establishment, which results in jitters and packet losses. Such jitters are detrimental for applications such as voice over IP (VoIP), multimedia and video streaming and packet losses are detrimental for flows that carry critical text information. Furthermore, packet losses decreases transmission control protocol (TCP) throughput when TCP is used for information critical data applications.
To address such issues of MIPv6, IETF has standardized a protocol called the hierarchical mobility management protocol version 6 (HMIPv6) disclosed in [Non Patent Citation 2]. HMIPv6 uses two types of care-of addresses and a new node called the Mobility Anchor Point (MAP). The basic principle is that the MN derives two care-of addresses at a new network it is attached to. One of the care-of addresses is called the Local care-of address (LCoA) which is the address obtained from the network MN is directly attached to. The other address is called the Regional care-of address (RCoA) and it is derived from the MAP's home network prefix. The RCoA is the address the MN will use as the care-of address when communicating with CN and HA. Since MAP is preferably a fixed router placed higher up in the routing hierarchy, this RCoA does not change often. As long as the roaming MN is inside the network segment where the MAP information such as the MAP address embedded in a MAP option can be obtained, Regional care-of address does not change. In this protocol, for every change in network attachment, the hand-off establishment procedure is mostly with the MAP where the LCoA is registered. Only when the MN moves out of the MAP and hence the RCoA is changed, will there be simultaneous updates or hand-off establishments to MAP, CNs and HAs. Thus, on average, signaling load into network per change in network attachment is much less when compared to pure MIPv6. Furthermore, for every change in network attachment, the hand-off establishment time is less on average. This is because, majority of the time, hand-off is only associated with a simple LCoA registration at MAP which is placed at close proximity to the roaming MN. Thus the complexities such as jitters and packet losses discussed previously are much less here. This protocol is an accepted standard for nodes that want power saving for its flows and for nodes that carry flows that require stringent QoS parameters.
With the ever-increasing proliferation of wireless devices, it is foreseeable that a new class of mobility technology will emerge: network mobility, or NEMO, where a whole network of nodes changes its point of attachment in entirety. The IETF has developed a solution for basic network mobility support disclosed in [Non Patent Citation 3]. Here, it is specified that the mobile router (MR) when sending BU to home agent, will specify the network prefix, which the nodes in the mobile network are using. The above mentioned network prefix are specified using special options known as Network Prefix Options to be inserted into the BU. These allow the home agent to build a prefix-based routing table so that the home agent will tunnel any packets sent to destinations with these prefixes to the care-of address of the mobile router.
When a MN is deeply nested in a NEMO, two types of problems arise. The first type of problems includes overhead of multiple encapsulations and suboptimal routing for data packets. This is due to nested tunneling for the nested NEMO scenario. Multiple encapsulations results in delay of data packet due to the increase in packet size and may also further lead to packet fragmentation. Packet fragmentation may further result in data packet loss. Suboptimal routing also leads to data packet delay, increase in network load and burdening the HAs with higher processing load.
The second type of problems includes the massive delay for layer three hand-off establishments for the deeply nested MN and the high signaling load injected into the network due to signaling overhead of RR and BU stream. This arises because when MN is deeply nested and if there is a change in network attachment, the new care-of address obtained has to be registered at the CNs or HAs. There will be a massive delay in such registration due to the packets involved in hand-off registration being subjected to multiple encapsulations and also traversing through pinball routing path comprising of all upstream MRs and their home agents. As discussed previously, this increase in hand-off delay time will contribute significantly to the overall session or connection time of a flow carried by a fast moving MN, which results in jitters and packet losses. Furthermore, excessive hand-off establishment signaling by a MN during a given time affects other flows carried in the network as well.
To solve the first type of problems, there have been various proposals to what is known as a nested tunnel optimization in the relevant field of art. Particularly, [Non Patent Citation 4] discloses a solution known as the Access Router Option (ARO). This new option, called the Access Router Option, is used by the sender (i.e. mobile router or mobile host) to inform the recipient (e.g. home agent or correspondent node) the primary global address of the access router the sender is directly attached to. After sending the binding update message with the access router option, the mobile node can then insert a special signal called the “direct-forwarding-request” signal to the data packet it sends out. This signal will cause upstream mobile routers to send their own binding updates to the destination address. This process is repeated until an access router (which usually is the fixed router of the access network) is reached that does not understand the “direct-forwarding-request” signal. With all upstream mobile routers sending binding updates to the destination, the destination can build a chain of mobile routers the mobile node is attached to. This can be used to construct the extended Type 2 Routing Header (RH2), so that when the destination node wants to send a packet back to the mobile node, it can embed the packet with the routing header, and the packet will be routed directly to the mobile node via the chain of mobile routers. This method is considered as an adequate method to provide end-to-end route optimization without trading off security.
To solve the second type of problems and to partially solve the first type of problems, [Non Patent Citation 5] reveals a scheme which tackles issues such as nested tunneling and Layer three (L3) hand-off establishment delay. This scheme attempts to improve hand-off efficiency and signaling overhead and provide reasonable end-to-end route optimization for a nested MN in a MAP environment. In this scheme, every MN behaves as specified in HMIPv6. For every change in local network attachment, the MN will update its LCoA at the MAP and for every change in the RCoA or the MAP domain, the MN will update its CNs and HAs of the new RCoA. In this scheme, it is also assumed that the MR will operate as specified in the HMIPv6 protocol for the MN but will have slight modifications. The MR when operating in the router mode will advertise the MAP option in its router advertisement (RA) to extend the MAP services to the MNs and MRs that are attached to it. Furthermore, in order to help the MAP trace the optimum path to reach a MN LCoA, the MRs will do a prefix scoped binding update (PSBU) at the MAP instead of the pure HMIPv6 type of registration. Suppose the MN is deeply nested behind some number of MRs, the binding cache at the MAP will have MN's LCoA and RCoA as well as the upstream MRs' LCoAs, RCoAs and prefixes. It should be well known to one skilled in the art how the MAP can use this prefix to locate all the LCoA associated with the MN's upstream MRs. Such tracing is possible because the MN's or MR's LCoA is derived from its access router's prefix.
When a data packet arrives at the MAP where the destination address is RCoA associated with the MN, MAP will first locate this RCoA in its binding cache (BC). Then the MAP will find the corresponding LCoA associated with this RCoA in the binding cache entry (BCE). Following that the MAP will search for the prefix that matches this LCoA of MN. By doing this, MAP can find the location parameters of the direct mobile router of MN and repeat such process until all the upstream MRs LCoAs can be obtained. Once such recursive tracing is done at the MAP, it will tunnel the data packet to the MN by inserting a routing header in the tunnel consisting of the all-upstream MRs LCoAs. When MN sends a packet to the CN, as in HMIPv6, MN will first encapsulate the packet in a tunnel to the MAP. All the upstream MRs of MN, since it has a binding at the MAP, will further encapsulate the packet in separate tunnels to the MAP. The final effect of this scheme is that for incoming data packets, there will be a single tunnel from MAP with extended routing header. For outgoing data packet there will be multiple encapsulations from MN/MR to MAP in the wireless domain. It is important to understand that this protocol mainly attempts to improve hand-off and signaling for a MN deeply nested in a NEMO. When comparing this scheme to the ARO scheme as disclosed in [Non Patent Citation 4], it is important to appreciate that the ARO scheme provides better end-to-end RO. This is because in ARO, there is no tunnel in the wireless domain in the reverse direction, whereas there are multiple tunnels in the wireless domain in [Non Patent Citation 5]. In addition, for ARO, there is no tunnel in the forward direction.
From the above discussions it can be foreseen that in the future, different types of protocols may need to be implemented in the system in order to achieve the objectives of data flows, end terminals and networks. As far as data flows are concerned, the main objective will be to reduce delay, jitters and packet loss. The main objective of the network perceived QoS is to reduce the network load or more correctly the signaling load into the network. The MN's objective is to save power. Hence in order to combine all these objectives as a single goal, it is very likely that multiple protocols may need to be implemented in the system. A future MN may need to support different types of flows having different QoS needs. For example, the MN may carry some flows that require strict end-to-end RO and also some flows that are not strict about end-to-end RO. For flows that are not too strict about end-to-end RO the MN may need to consider improving signaling load injected into network and save power by reducing frequent binding updates. Thus, it is foreseeable that in the future different type of protocols needs to be implemented in a MN, MR, some key routers and CN.
In the future, there may be a case where both ARO protocol and some HMIPv6 related protocol (pure HMIPv6 or HMIPv6 with some RO) implemented in MNs and MRs. Furthermore, such heterogeneous protocols implementing nodes may possibly be roaming in localized mobility management domains that could possibly have a plurality of Mobility Anchor Points or Localized Mobility Management Anchors (LMAs). The above-mentioned LMA is a well-defined terminology in the Network based Localized Mobility Management (NetLMM) IETF working group and it could possibly have a MIPv6 home agent functionality or a HMIPv6 MAP functionality. A detail description of LMA can be found in [Non Patent Citation 6]. When a nested NEMO is roaming in a NetLMM domain with above mentioned heterogeneous protocols implemented, non of the MNs and MRs in the nested NEMO would know the localized mobility management functionality available in the architecture and all the MNs and MRs in the nested NEMO will not trigger the HMIPv6 related stack and may only use ARO mechanism to communicate with CNs. In non-NetLMM domain, but in a domain where there are MAPs available, the nested NEMO MNs and MRs with the above mentioned heterogeneous protocols will trigger ARO and/or HMIPv6 related stacks according to the QoS needs of the flows, the power state of the MN/MR and the traffic state of the network. The traffic state of the network implies the network bandwidth utilization state or network congestion state.
In the above said local mobility management domain with plurality of MAPs, it is further assumed that all these MAPs have the same HMIPv6 functionality as the roaming MNs and MRs. Basically; this means that all the MAPs in the domain have the same HMIPv6 RO functionality. The above said HMIPv6 RO functionality can be ARO enabled HMIPv6 functionality, prefix delegation based HMIPv6 functionality as briefly mentioned in [Patent Citation 3] or PSBU based HMIPv6 functionality as disclosed in [Non Patent Citation 5].
The above mentioned ARO enabled HMIPv6 functionality is such that the MAP is similar to a pure HMIPv6 MAP where it gives its home address as the MAP option so that MNs and MRs can derive RCoA from this address prefix and perform local registrations at the MAP. Furthermore, this ARO enabled HMIPv6 MAP also supports addresses that are sent as ARO option in local binding update and will carry out similar ARO based tracing as outlined in [Non Patent Citation 4]. The parameters sent to the MAP in the ARO option can be the mobile access router's home address or the mobile access router's regional care-of address. The tracing at the ARO enabled HMIPv6 MAP will be for the RCoA associated with a MN or MR. All the LCoAs required to reach this RCoA optimally is traced by using single or multiple ARO parameter registered at the MAP. More explanation on this will be given in other sections of this document.
The above mentioned prefix delegation based HMIPv6 functionality is such that the MAP is RO enabled and it will delegate prefixes to the MRs upon request and the MRs will perform a local PSBU with the MAP using this delegated prefix in the prefix option. It is further assumed that MNs and MRs that are attached to a MR will use this MAP delegated prefix to derive its LCoA. The MAP accepts this above mentioned local PSBU straight away and there is no need for the MAP to perform a collocation test between RCoA, LCoA and the prefix as this prefix was assigned by the MAP itself. When a packet arrives at the MAP from CN, the MAP will initially look for the RCoA entry and find the corresponding LCoA. Then it will look for the prefix field matching the LCoA prefix. If the prefix entry is found then the tracing mechanism will look for the LCoA entry associated with the above found prefix and continue such searching until no more prefix matching is found. In an alternate manner, it can be said that when all the LCoAs associated with the upstream MRs of a particular MN/MR has been found, the tracing comes to an end.
The above-mentioned PSBU based HMIPv6 MAP functionality is such that the MRs perform PSBU at the MAP where the said prefix is given to the MR from its home network. In this case, the MAP may have to carry out a RCoA, LCoA and prefix collocation test before accepting this local PSBU. A detail explanation of this was given previously in this current document when explaining the [Non Patent Citation 5].
It is further assumed that the nested NEMO nodes with previously mentioned heterogeneous protocols are roaming in domains where there are multiple MAPs in the architecture. Multiple MAPs are usually implemented in a domain for load balancing purposes. For example, when there is a single MAP in the domain, and it is placed further up in the network architecture covering a large segment of the network, the local mobility management domain will be big and hence large number of MNs and MRs will want to use the MAP for local mobility management services. This will increase the load on the MAP. The MAP usually does Neighbor Discovery (ND) Proxy signaling for the RCoA values derived from its home link prefix by the MNs and MRs. This ND proxy signaling for large number of MNs and MRs drains a considerable amount of power from the MAP and increases the processing load. Furthermore, the single MAP needs to tunnel large number of packets coming to numerous RCoA values registered at the MAP, which further increases the processing load on the MAP. Moreover, when there are numerous nodes in the local mobility management domain and there is only a single MAP in the architecture, the BCEs at this single MAP will be exhaustive and the MAP will use quite a large chunk of its memory for its BCEs and hence waste MAP's resources. The single MAP is also subjected to heavy de-tunneling procedure for out going traffic, which also further increases the MAP's processing load. All these anomalies associated with a single MAP imply that such single MAP architectures are not favorable for local mobility management domains that want to house large number of MNs and MRs. If a single MAP is used then there is a high possibility of MAP failure when large number of nodes uses the MAP functionality. Thus it is clear that multiple MAPs in localized mobility domain or multiple LMAs in NetLMM Domain or multiple proxy home agents in the Proxy Mobile IP (PMIP) domain is required for load balancing. More details of PMIP and proxy home agents are discussed in [Non Patent Citation 7] and will be briefly discussed later in this document.
To alleviate all these problems just mentioned with a single MAP in the architecture, as outlined in [Non Patent Citation 2], it is quite common to deploy multiple MAPs. In [Non Patent Citation 2] it was outlined that these MAPs may possibly be deployed hierarchically in a domain. Hierarchy of MAP placement in a domain means there will be a single or plurality of root MAPs and also will possibly have n (n>1) number of tiers of MAPs tessellated in the domain. In an alternate deployment to the hierarchical way, all MAPs in the domain can be deployed at a single tier. There is no standard or mandatory way to deploy the multiple MAP architecture.
In the hierarchical MAP deployment, the MNs and MRs will receive MAP options associated with MAPs that are in their default routing path. In some cases, there can be more than one default routing path and thus numerous MAP options may be available to the MNs and MRs. When MNs and MRs are moving fast, they may choose MAPs that are further away so that the global registrations need not be performed often but the trade-off is that the tunnel from further away MAP to the end MN/MR is longer and hence subjected to more data packet delay. For slow moving MNs and MRs, the MAPs at lower tiers can be chosen. The advantage with lower tier MAPs is that the tunnel length is short. Furthermore, low-tiered MAPs are suitable for slow moving MNs and MRs because, the change of RCoA rate will not be too high and hence global registration frequency will be within desired limits. In [Non Patent Citation 2] there is no standard mechanism for load balancing among MAPs. One way is for the MAPs to, when it realizes that it is extremely overloaded, set the preference value to “zero” in its MAP option. In this case, the MN/MR MUST not use that MAP. Nevertheless, in all other instances any MAP can be chosen out of some number of MAPs available to a MN/MR. In the prior art [Non Patent Citation 2], the multiple MAP availability is revealed to a roaming MN/MR only and there is no prior analysis or work done for a roaming nested NEMO in a multiple MAP scenario. Next
In
Once MR 20 processes the MAP 30 option, it will derive a RCoA value using the address prefix of MAP 30 and make a local registration at MAP 30. The above said registration values are shown by BCE 61 in
Once VMN 10 has completed local registration at its MAP 31, VMN 10 will perform appropriate global registration at its HA 40 and CN 50 respectively. It is assumed that VMN 10 carries out RR and then does MIPv6 based ARO registration at CN 50 but using its RCoA as its care-of address. The first row of entries in BCE 60 shows the VMN 10 global registration values. The third column in BCE 60 shows the ARO value given by VMN 10. CN 50 may possibly send an ACK to RCoA of VMN 10 by explicitly source routing the ACK via home address of MR 20. Once MR 20 receives the above said ACK from CN 50, it will send its appropriate ARO registration to CN 50 using its RCoA as its care-of address. The above said registration values are shown by the second row of entries in BCE 60.
When CN sends its data packet to VMN 10, the destination address will be set to RCoA of MR 20. Such a destination address setting is obtained by performing ARO tracing using the BCE 60. This packet will travel via path 120 and reach MAP 30 and then MR 20. Since MAP 30 has a route to RCoA of MR 20 the data packet sent from CN 50 will get further tunneled to LCoA of MR 20 at MAP 30. When MR 20 processes the packet reached via path 120, the next address to be reached will be RCoA of VMN 10 and it will be set by MR 20. Since MR 20 does not have a route to RCoA of VMN 10, the packet will be sent to RCoA of VMN 10 via MAP 30 and home agent of MR 20. These above mentioned paths are shown by path segments 121 and 122 respectively. At HA 41, when the packet traversed via path 122 is decapsulated, the destination will be found as RCoA of VMN 10 and the packet will be sent to MAP 31 where this above-mentioned RCoA was derived. MAP 31 has routing path to RCoA of VMN 10 as can be seen from BCE 62. The next hop to reach RCoA of VMN 10 will be RCoA of MR 20. Thus the packet will be further routed via the path 124 and reach MAP 30. At MAP 30, the route to reach RCoA of MR 20 is available and the packet will reach VMN 10 finally via MR 20 along the path 125.
One can clearly see that the CN 50 to VMN 10 routing path is very long-winded and sub-optimal. This long-winded ping-pong routing via MAPs occurs mainly due to the fact that the VMN 10 and MR 20 local registrations (LCoA registrations) are made at different MAPs. Basically, to trace all the LCoAs required to optimally reach a RCoA of a MN or MR that is attached to a nested NEMO, all the upstream MRs of the said MN or MR may preferably need to have some form of permanent or semi-permanent registrations at the MAP from which the above said RCoA is derived. Since in
To further understand the above outlined routing problem in greater depth,
MR 20 will decapsulate the packet 209 and will realize the packet is destined to itself (inner packet destination address is RCoA of MR 20). In such a case, MAP 30 will further inspect the packet by looking at the RH2 and will note that the next address is RCoA of VMN 10. MR 20 will then set the destination address of the packet to RCoA of VMN 10 and put the RCoA of MR 20 in the RH2. The innermost packet in packet 210 shows this said packet construction. MR 20 does not have any route to RCoA of VMN 10 and thus to overcome ingress filtering, MR 20 will encapsulate the packet in two tunnels. The immediate tunnel will be to its home agent, which is HA 41, and the outermost tunnel will be to its MAP, which is MAP 30. This doubly encapsulated packet 210 will be first sent via path 202 to MAP 30. There the outermost tunnel will be removed and the packet with single level of encapsulation will be further routed via the path 203 to HA of MR, which is HA 41.
At HA 41 the single tunnel will be completely removed and the innermost packet will finally reach MAP 31. The fully decapsulated packet at HA 41 will be destined to RCoA of VMN 10 and thus it will travel via path 204 and will be intercepted by MAP 31. MAP 31 using the BCE 62 as given in
It can be clearly seen from
Patent Citation 1: Hirano, J., Ng, C. W., et al., “Method and Apparatus for controlling packet forwarding, and communication node”, WIPO Patent Application Publication WO06129863A1, December 2006.
Patent Citation 2: Hirano, J., Ng, C. W., et al., “Method and Apparatus for controlling packet forwarding”, WIPO Patent Application Publication WO06129858A1, December 2006.
Patent Citation 3: Hirano, J., Ng, C. W., et al., “Method and Apparatus for controlling packet forwarding”, WIPO Patent Application Publication WO06129855A1, December 2006.
Non Patent Citation 4: C. Ng and J. Hirano, “Securing Nested Tunnels Optimization with Access Router Option”, IETF Internet Draft: draft-ng-nemo-access-router-option-01.txt, Jul. 12, 2004.
Non Patent Citation 5: Ohnishi, H., Sakitani, K., and Takagi, Y., “HMIP based Route Optimization Method in Mobile Network”, IETF Internet Draft: draft-ohnishi-nemo-ro-hmip-00.txt, October 2003.
Non Patent Citation 6: Bedekar, A., et al., “A protocol for Network-based Localized Mobility Management” IETF Internet Draft: draft-singh-netlmm-protocol-00.txt, Dec. 5, 2006.
Non Patent Citation 7: Gundavelli, S., et al., “Proxy Mobile IPv6” IETF Internet Draft: draft-sgundave-mip6-proxymip6-01.txt, Jan. 5, 2007.
From prior discussions, it can be understood that, for large local mobility management domains it is essential that this domain have many MAPs for load balancing purposes. In such a case, MNs or MRs in nested NEMO should preferably receive all the MAP addresses that are in their default routing path to support load balancing among the MAPs. If such a design is incorporated for load balancing purposes, then as seen in the prior problem analysis there is a possibility for the MN/MR and its upstream MRs to end up choosing different MAPs to derive its RCoA and make local registrations. When different MAPs are chosen among MNs and MRs in the nested NEMO tree path, and the above said MN or MR in nested NEMO does global MIPv6 registration with CN using RCoA, there will be definite routing sub-optimality as described previously.
It is thus an objective of the present invention to overcome or at least substantially ameliorate the afore-mentioned disadvantages and shortcomings of the prior art. Specifically, there are two objectives of the present invention in such an ARO and HMIPv6 heterogeneous scenario when there are multiple MAPs in the architecture. The first objective is to provide MN or MR nested in a NEMO, local mobility management services as well as obtain optimal routing with CN without trading-off the load-balancing objective of the multi MAP scenario. Basically, the above said objective is such that the above said MN/MR should ideally configure its RCoA only from one MAP out of some n number of MAPs available and yet, eliminate route sub-optimality issues. The second objective is to enable the above said route optimization in a multiple MAP scenario without excessive signaling via the wireless domain or without excessive signaling in the local mobility management network domain.
In order to achieve the foregoing object, according to the present invention, the following systems, methods and apparatuses are provided.
The present invention provides a system of communications node comprising of VMNs, MRs, MAPs, HAs and CNs where it is considered that the said VMNs and MRs have ARO and some HMIPv6 RO enabled protocols implemented in them. It is further considered in this system there are a plurality of MAPs in the local mobility management domain architecture, where the said MAPs have some HMIPv6 RO functionality implemented similar to the said VMNs and MRs. In such a system, MR in nested NEMO will make a registration at the MAP of its down stream MRs and VMNs in the nested NEMO tree path, irrespective of the MAP it is attached to. This said alternate duplicate registration at other MAP is done without configuring a new regional care-of address from other MAP.
The present invention provides a system of communications node comprising of VMNs, MRs, MAPs, HAs and CNs where it is considered that the said VMNs and MRs have ARO and some HMIPv6 RO enabled protocols implemented in them. It is further considered in this system there are a plurality of MAPs in the local mobility management domain architecture, where the said MAPs have some HMIPv6 RO functionality implemented similar to the said VMNs and MRs. In such a system, MR in nested NEMO will have information on all the MAP options available to its nested NEMO tree path MNs and MRs and thus attach the other MAP addresses in its local binding update to its chosen MAP. It is further considered that all MNs and MRs in the nested NEMO tree path will attach to one MAP out of some number of MAPs available to the nested NEMO.
According to the present invention, methods and apparatuses used by each of all nodes in the above systems are also provided.
The present invention has the advantage of providing a useful mechanism in an ARO and HMIPv6 heterogeneous environment.
The present invention presents two main approaches. The first approach is such that, in order to provide local mobility management based route-optimization (i.e. using RCoA as care-of address to CN) to a MN/MR that is in nested NEMO, without violating the load balancing principle in a multiple MAP scenario, when a MR realizes that its downstream MN/MR is attached to another MAP which is different from its own, it will make an appropriate location registration at the other MAP. By MR doing so, semi-permanent registrations are created at the other MAP until the down stream MN/MR moves out from the above said MR's NEMO. Moreover, load balancing is achieved because another RCoA at the other MAP is not derived by the said MR to solve the route sub-optimality issue. If another RCoA is derived from the other MAP, then the other MAP may have to do ND-Proxy signaling for this address and thus increase the load on the above said other MAP.
The second approach is such that, again, in order to provide local mobility management based route-optimization (i.e. using RCoA as care-of address) to a MN/MR that is in nested NEMO, without violating the load balancing principle in a multiple MAP scenario, the above said MN's/MR's upstream MRs LCoA registrations is transferred to the MAP from which the said MN/MR has derived its RCoA. Such a transfer takes place from the above said upstream MRs MAPs. Basically, the MR will inform the other MAP addresses available to it, to the MAP from which it derives its RCoA and using this information, appropriate MAP transfers takes place between MAPs via the fixed network links.
The advantage of the second approach when compared to the first is that, the transfers are taking place in the fixed network where as in the first approach the on-demand registrations are done via the wireless domain using scarce wireless bandwidth. Nevertheless, in the second approach, more changes has to be done to the MAP to implement this method, more processing burden on MAP to carry out such transfers and more memory may be required to store other MAP addresses in MAP's binding cache.
In a first preferred embodiment, the above said first approach is disclosed.
MR 20 roams into the sub-network for which AR 25 is the default router. After making appropriate authentication and attachment at Layer 2, MR 20 receives RA 300 containing MAP options revealing the presence of MAP 30 and MAP 31. It is considered that the preference value obtained in the MAP options is greater than “zero” and MR 20 decides to only use MAP 30 to configure its RCoA. After MR 20 configures its LCoA and RCoA, it makes local registration as shown by 301 with MAP 30. After such registration, the BCE at MAP 30 will be as shown by 302.
Following this local registration, MR 20 will next carry out global registration at its home agent HA 41 by sending the BU message 303. BCE 304 shows the BCE created at HA 41 as a result of registration 303. Next, MR 20 will send out an RA 305 containing MAP 30, MAP 31 and ARO options in its NEMO link. VMN 10 can be in a state where it decides to process the ARO option and the MAP 31 option. It is considered that VMN 10 chooses one of the MAP options only. As discussed previously, there is no major reason to process both available MAP options to communicate with CN 50.
After VMN 10 forms its LCoA and RCoA, it will make a local registration at MAP 31. This local BU is shown by message segments 306, 307, 308 and 309. A person skilled in the art would understand that the above mentioned message segments are subjected to various levels of tunneling because MR 20 does not have any registration at MAP 31. Once VMN 10 completes its local registration at MAP 31, MAP 31 will have the entries as given in BCE 310. Since VMN 10 process ARO and MAP 31 options, ARO option is attached in the local BU. MAP 31 being an ARO enabled MAP, will next send the ACK to this local registration. This ACK will have home address of MR 20 as first destination address. This ACK message is shown by 311 in
Immediately after sending the Local BU, VMN 10 may next send the Global BU to its HA 40. This is shown by message segments 312, 313, 314, 315 and 316. Once again it can be seen that this global registration message is going through many levels of encapsulations due to MR 20 not having any registration at MAP 31 and HA 40. Once VMN 10 completes its global registration at HA 40, BCE 317 is created at HA 40. Since HA 40 is ARO enabled, it will send an ACK where the first destination address of the ACK will be home address of MR 20. This ACK message is shown by 318 in
When MR 20 receives ACK 311, it will realize that the message is coming from another MAP in the domain. According to our present invention, MR 20 need not make any registration at this MAP since it knows that it is not its own MAP or a CN. Even if MR 20 makes a registration, since it has derived RCoA as its care-of address it will usually make a HoA, RCoA registration at MAP 31. Instead, to allow MAP 31 to trace the LCoA of VMN 10 and LCoA of MR 20, MR 20 makes a HoA, LCoA registration at MAP 31. This registration is the first main invention and this is shown by message 319 and the registration created at MAP 31 is shown by the second row of entries in BCE 320. Again, as mentioned previously, the entire tunneling and full routing path associated with message 319 is not disclosed for simplicity. It can be readily understood that the HoA, LCoA registration associated with message 319 has to include RR process as well. It can be well appreciated by one skilled in the art that the RCoA of VMN 10 can be fully traced using BCE 320 and the ARO tracing mechanism. After ARO tracing, the LCoAs of MR 20 and VMN 10 can be obtained because adequate registration entries are available at MAP 31. After such registration 319, MR 20 will next respond to the ACK it received from HA 40 and send appropriate registration message 321 to HA 40. MR 20 will consider HA 40 as a normal CN because it does not have any special classification to HA 40 in its state table.
Having done the local and global location registration signaling, VMN 10 may wish to carry out local mobility management related RO with CN 50 and thus will perform RR and MIPv6 BU with CN 50 and disclose its RCoA as its care-of address. Such registration to CN 50 and consequently formed BCE at CN 50 is given by 322 and 323 respectively. When CN 50 wants to send data to VMN 10, it will send the packet to RCoA of VMN 10. In this case, the packet will reach the home link of MAP 31 and will be intercepted by MAP 31. MAP 31 will have all the LCoAs required to reach RCoA of VMN 10 optimally (BCE 320). Thus the above said data packet will be put in a tunnel and the tunnel destination address will be set to LCoA of MR 20. The tunnel RH2 will have LCoA of VMN 10 and RCoA of VMN 10. This will be an optimized path and such bi-directional data message is shown by message segments 324 and 325 in
Basically the above method outlines an on-demand registration technique where the MR 20 only needs to make repetitive registration at the other MAP until VMN 10 is attached to it. The only disadvantage with this method is that when there are numerous MNs and MRs in the nested NEMO and there are many MAPs available, such other MAP registrations can increase the signaling load considerably and reduce the available bandwidth for data traffic in nested NEMO. Nevertheless, in many practical scenarios, nested NEMO is not too big and this method proves to be very useful to eliminate the routing sub-optimality issue disclosed in the prior art. Moreover, in this on-demand other MAP registration method, MNs and MRs in nested NEMO can randomly choose among any MAP in its default routing path and thus the probability of any one particular MAP getting overloaded is very slim.
In another preferred embodiment of the present invention, for a scenario similar to that given in
When the system nodes (VMN 410, MR 420, MAP 430 and MAP 431) have prefix delegation based/PSBU based HMIPv6 RO functionality, the binding cache created at MAP 430 and MAP 431 are given by BCE 461 and BCE 463 respectively. When the system nodes (VMN 410, MR 420, MAP 430 and MAP 431) have a modified ARO enabled HMIPv6 functionality where the mobile access router's RCoA is given as the ARO parameter to its MAP, binding cache created at MAP 430 and MAP 431 are given by BCE 462 and BCE 464 respectively.
Let us first consider the sub-scenario where VMN 410, MR 420, MAP 430 and MAP 431 have prefix delegation based/PSBU based HMIPv6 RO functionality. VMN 410 is directly connected to MR 420. MR 420 uses MAP 430 to configure its RCoA and VMN 410 uses MAP 431 to configure its RCoA. The home agents of VMN 410 and MR 420 are HA 440 and HA 441 respectively. It is also assumed that VMN 410 is having a data communication session with CN 450. The above said MAPs are rigidly placed in the MAP domain 471, which is in turn connected to the Internet 470.
MR 420 may possibly perform a prefix-oriented local registration at its MAP 430. The created entry after such registration is shown by BCE 461. The RCoA of MR 420 is derived from MAP 430 and the prefix registered at MAP 430 may well be a prefix delegated from MAP 430 or HA 441. Following which, VMN 410 may perform a local registration at its own MAP, which is MAP 431. The entries created at MAP 431 after such VMN 410 registration is shown by the first row of entries in BCE 463. It is assumed that the LCoA of VMN 410 in BCE 463 is derived from the prefix parameter given in BCE 461. When MAP 431 sends its ACK to LCoA of VMN 410, this ACK will need to be tunneled from home agent HA 441 and/or tunneled from MAP 430. In this case, after de-tunneling this ACK originally sent from MAP 431, MR 420 can realize that it has no attachment with MAP 431 (as the ACK packet was tunneled from home agent of MR 420 and or MAP 430) and furthermore a down stream MN/MR is attached to this other MAP. In such an event, using the first main invention as disclosed via
From previous discussion, it is evident that the RCoA of MR 420 registered at MAP 431 was derived from MAP 430. Furthermore, the prefix entry registered at BCE 463 can be a prefix that was delegated to MR 420 by MAP 430 or a prefix given to MR 420 from HA 441. Thus the same registration that was made by MR 420 at MAP 430 is merely repeated at MAP 431. In such a duplicate registration method, MR 420 can very readily pass the local registration values it made at its MAP 430 by using a common trusted key. MAP 430 and MAP 431 can pre-establish a common trusted key and this key could possibly be passed to MR 420 when establishing a successful local registration with its MAP 430. Such a key can be used to create appropriate authentication headers (AH) or certificates or encapsulating security payload (ESP) when MR 420 makes its other MAP duplicate registration at MAP 431. It can be well understood by one skilled in the art that MAP 431 need not do any address validity for the above said registration done by MR 420. This is because it trusts that MAP 430 has already done it.
It is further considered that since all the LCoAs required to optimally reach RCoA of VMN 410 is made available at MAP 431 using a method associated with the main invention disclosed in this current embodiment, VMN 410 could possibly give its RCoA to CN 450 via RR and MIPv6 registration. When such registration is made at CN 450, the BCE will look like that given by BCE 460. When CN 450 sends data packet to VMN 410, the destination address will be set to RCoA of VMN 410 and the packet will be intercepted at MAP 431. MAP 431 will look for a route to this RCoA of VMN 410. MAP 431 will use the prefix matching technique where the LCoA prefix is matched to the prefix entries to find all the LCoAs required reaching a RCoA optimally. Using such a method, MAP 431 can readily trace LCoA of MR 420 and LCoA of VMN 410. Thus the above said data packet will be encapsulated in a tunnel and sent to VMN 410 via a most optimized path. Such a route-optimized path is shown by message segments 480 and 481 in the
We next consider the sub-scenario where VMN 410, MR 420, MAP 430 and MAP 431 have a modified ARO enabled HMIPv6 functionality where the mobile access router's RCoA is given as the ARO parameter when registering at its MAP. In this case, MR 420 will again configure RCoA from MAP 430 and make a local registration at MAP 430. Such registered entries are shown by BCE 462. It is further assumed that VMN 410 will have the RCoA of MR 420 available to it via the ARO option it receives from RA. This RCoA of MR 420 is derived from MAP 430. In this case, VMN 410 can preferably use this ARO parameter when doing registration at its own MAP 431. Such created entry is given by first row of entries in BCE 464. MAP 431 will send an ACK with first destination address set to RCoA of MR 420. In this case, MR 420 will make the RCoA, LCoA registration at this other MAP 431. This said MR 420 registration at MAP 431 would create entries as shown by the second row of entries in BCE 464. The second row of entries in BCE 464 is identical to BCE 462 entries. In normal operation of ARO, MR 420 will only make such a recursive registration when it receives an ACK destined to its global home address. Nevertheless, using a new functionality in the MR 420, it is assumed that even when it receives an ACK sent to its RCoA it will send its duplicate registration. Again, anyone skilled in the art can readily see that the BCE 464 can be used to find all the LCoAs required reaching RCoA of VMN 410 in the most optimal manner. Again as discussed previously it should be appreciated that MR 420 is already attached to a MAP 431 and hence need not make another registration at another MAP. Nevertheless, to enable route optimization to a down stream MN/MR it makes such duplicate registration at the MAP of VMN 410.
In another preferred embodiment of the present invention, the functional architecture of MR, which implements the previously described duplicate on-demand registration method, is disclosed. This said functional architecture is given by
The routing module 484 can preferably be implemented as a plurality of sub modules. The said sub-modules are IPv6 module 488, MIPv6 module 489, NEMO Basic module 490, ARO module 491 and HMIPv6 RO module 492. It is further assumed that only codes purely related to a sub-module is implemented in that sub-module. Some codes that are implemented in some other sub modules can be re-used by the sub-module via appropriate interfacing between sub-modules. Thus it is considered that these sub-modules are further interconnected. Nevertheless, it can be well understood by one skilled in the art that there are more than one way of implementing the said routing layer functionality without deviating from the scope of the invention.
IPv6 sub-module 488 is interconnected with MIPv6 sub-module 489 via an interface 494. MIPv6 sub-module 489 is interconnected with sub-modules NEMO Basic 490, ARO sub-module 491 and HMIPv6 RO module 492 via interfaces 495, 497 and 496 respectively. NEMO Basic sub-module 490 is interconnected with sub-modules 492 and 491 via interfaces 499 and 498 respectively. ARO sub-module 491 is interacting with HMIPv6 RO module via interface 499A. In this architecture it is assumed that the MR can be in a state where all sub-modules are triggered at the same time or only a subset of sub-modules being triggered. When the MR is roaming in a MAP domain, it is assumed that all MAP related functionality is handled by HMIPv6 RO sub-module 492. The HMIPv6 RO sub-module 492 comprises of protocols required to do MAP registration. This MAP registration is done using some RO parameter as described in the previous embodiments. The said sub-module 492 further comprises of a smaller sub-module 493 embedded in it. This module 493 is specifically responsible for performing a duplicate registration at other MAP (not MR's own MAP).
The IPv6 routing module 488 is responsible for generating and processing RA, performing link local routing, sending and receiving Internet Control Message Protocol (ICMPv6) messages, IPv6 header formation and IPv6 header processing, address configuration, neighbor discovery and so forth. MIPv6 module 489 is responsible for all software and hardware required to implement MIPv6 functionality. Although this is a mobile router, MIPv6 functionality is used for two purposes. MIPv6 functionality can be used when the MR functions as a MN or it can be used to derive other advanced functionality. Basically, MIPv6 can be used as a base class and other derived classes such as NEMO basic, ARO, HMIPv6 RO can be derived from it. When packet arrives at the IPv6 module via interface 486, after being processed at sub-module 488 it will be sent to MIPv6 module if there are some unknown parameters (mobility headers) that cannot be processed by IPv6 module 488. Otherwise, the IPv6 module will pass the packet to upper layer protocols after some processing via interface 487 or it will fully process and consume the packet. When packet arrives to IPv6 module via interface 487, these packets will be purely processed by module 488 only if the MR is at home link. Otherwise, the packet will be sent to MIPv6 module 489 for further processing. If the packets such as control packets are created at the routing module 484, then IPv6 will possibly construct it depending on the nature of the packets. For example, ICMPv6 packets will be constructed by IPv6 module 488.
All packets that arrive via interface 494 will be passed to previously mentioned sub-modules for further processing based on the parameters (for example destination address of the packet) that are found in the packet and the options being processed by the MR. The said options can be MAP options, ARO options and prefix options described in previous embodiments.
In yet another preferred embodiment of the present invention, to further understand the operation of the MR when processing packet at the routing layer 484, next, the flowchart of MR is given. This said flowchart given in
If step 401A evaluates to “false” or “no”, then again step 404A is carried out and in the event that 404A evaluates to “yes” the previously mentioned step 405A will be carried out.
If step 405A evaluates to “no”, then step 406A is carried out. In this step 406A, it is checked whether the packet has arrived via ingress interface and whether the destination address is set to some MAP address that is known to the MR (received via RA). If, step 406A evaluates to “yes”, then step 407A is carried out. This step 407A is to check whether the destination address of packet is equal to the MAP address from which MR derived its RCoA. If it is so, then the MR knows it has registrations at that MAP address and it could possibly execute step 408A. The step 408A involves a method where the packet is either tunneled to MR's own MAP or the source address is switched to LCoA of MR and the packet is routed further. After this step 408A the control will possibly go back to step 401A.
If step 407A evaluates to “no”, that means the destination address associated with the packet at ingress interface is equal to some other MAP address. Thus, the step 411A is next carried out to check whether the MR has a registration at this other MAP. If 411A test evaluates to “no” then step 414A is carried out. This means that if there is no registration at the other MAP, the MR makes appropriate registration at the other MAP. As explained in previous embodiments, the type of registration parameters at other MAP depends on the HMIPv6 RO mechanism at the MAP in the domain. After making this other MAP registration, the control will go to step 405A, where the packet will be routed normally using standard operation. Or the packet can be buffered for some time and then be sent via an optimized route created by registering at the other MAP. If, when step 411A is executed, it is found that the registration at the other MAP has already been done, then step 412A will be carried out. In such a case, the packet will be tunneled to the other MAP or the source address will be changed to the LCoA and routed further to the other MAP.
If step 406A evaluates to “no”, then control will come to step 409A. This step 409A constitutes a method where it is checked whether the packet arrived via egress interface and the packet is destined to the MR. If step 409A evaluates to “yes”, then step 410A is carried out. When executing step 410A the packet will be consumed by the MR. This packet will be fully processed at layer three of MR or it may be further sent to the upper layers of MR. If when evaluating step 409A, the step evaluates to “yes”, that means first the packet will be decapsulated and then step 413A will be performed. In this step 413A, it is checked whether after decapsulation, the inner packet source address is equal to other MAP address. In this case, the MR knows that it does not have registration at other MAP, and hence control will be passed to step 414A. Again appropriate registration will be made at other MAP and the packet will be passed to step 405A where standard mechanisms will be used to route packet further. After performing step 405A, the control will go back to step 401A. If step 413A evaluates to “no”, then the packet will again be sent to step 405A for further routing.
In yet another preferred embodiment of the present invention the second approach of the main invention or rather the second main invention is disclosed. This second main invention is such that, again, local mobility management based RO is provided for VMN to CN data traffic in a multi-MAP environment without trading off the load-balancing feature. However, LCoA registrations that are required for reaching the RCoA of the said VMN via the most optimized path is transferred from one or more MAPs via the fixed network to the MAP from which the above said RCoA was derived. This way, the signaling burden on the wireless domain is less when compared to the first approach given in a previous embodiment. This second invention will be more clearly understood, once the associated
In
The core point about the second method described via
When such a method is in operation, in
Next, after appropriate local registration at the MAP of its choice, MR 521 would send its RA and MR 520 is assumed to process MAP 531 option to make its local registration. When MR 520 completes this local registration, the created entries will be given by the second row of entries at BCE 562. Again, MR 520 will give MAP 530 address when it performs the BU. This is a “hint” to MAP 531 that another MN or MR in the same nested NEMO tree path associated with MR 521 and MR 520 is possibly attached to this MAP 530 and would possibly need the MR 521 and MR 520 entries to trace the RCoA that is registered at MAP 530. When MR 520 sends it RA, it is assumed that VMN 510 uses the MAP 530 address to make its local registration. Since VMN 510 is a mobile node and not a router, it need not send other MAP addresses in its BU. This can be easily understood by one skilled in the art, because, no other MAP need this LCoA of VMN 510 (LCoA of VMN 510 is a leaf address) to reach a RCoA. The local registration entry created after this said registration at MAP 530 is shown by BCE 561.
MAP 531, whenever it has new entries or when old entries are refreshed, will trigger a mechanism associated with this second main invention. This said mechanism is such that, MAP 531 will search for entries that have the same other MAP addresses. If these entries are new or just refreshed, then, it will pass all these entries to the other MAP addresses. Basically, for this scenario, MAP 531 will pass all the registered entries given in BCE 562(except the other MAP addresses) to MAP 530. After the said transfer, BCE 563 gives the new entries created at MAP 530. It is assumed that the said MAP-to-MAP transfer is done securely by means of a security key that is mutually accepted among the MAPs in the MAP domain 571. It can be readily understood by one skilled in the art that if there are more than one other MAP addresses in the fourth column of BCE 562, then the two row of entries have to be passed to all the other MAP addresses available. Since BCE 563 has all the required entries to reach RCoA of VMN 510 optimally, it can be well understood that the bi-directional data communication between VMN 510 and CN 550 will travel via the most optimized path as shown by the path segment 581 and 582 in the figure.
It is important to appreciate the difference between the method disclosed in this current embodiment and the duplicate on-demand registration done via wireless domain. Both are similar in their effect in the sense that duplicate entries are made at the required MAPs but only based on demand from other nodes in the nested NEMO. Another good feature with both the approaches is that, load balancing is not traded off and any MN/MR in the nested NEMO can choose whatever MAP out on n number of MAPs available with a probability of 1/n. Thus, usage of all the above said n MAPs will be similar and MAP failure due to overloading can be avoided.
In another preferred embodiment of the present invention, to further understand the operation of the MAP in the embodiment associated with
When packets reach the routing module 501A via interface 503A, it will either be fully processed by IPv6 module or passed to the HMIPv6 RO module. Basically, if IPv6 module can fully process such packet it will be processed there. Otherwise, the HMIPv6 RO module will process the packet.
In a further preferred embodiment of the present invention, the MAP packet processing methods at module 501A in
If after carrying out step 500B it is found that this step evaluates to “no”, then the step 505B is carried out. At step 505B, it is checked whether the packet arrived via an ingress interface. If step 505B evaluates to “no”, then the packet is originated at MAP and thus the step 506B will be carried out. At step 506B, the packet will be constructed and routed as in standard mechanism. Nevertheless, if step 505B evaluates to “yes”, then the control will move to step 507B. At step 507B, it is checked whether the packet arriving at ingress interface is destined to the MAP. If 507B evaluates to “yes”, then step 508B is executed. At step 508B it is checked whether this packet is a Local BU and whether there are any other MAP addresses attached. If step 508B evaluates to “yes”, then step 509B is carried out. At step 509B, the other MAP addresses are placed at memory locations associated with a RCoA value. If step 508B evaluates to “no”, then step 510B is performed. At step 510B, the local BU entries are placed as per normal operations.
If the current event in the event scheduler is the event associated with step 512B, then that step 512B will be triggered. The step 512B checks whether there are any new BC entries created or whether any entries have been renewed or refreshed. If 512B evaluates to “yes”, then step 513B is executed. Step 513B has functionality where the BC entries with common other MAP addresses are grouped together. After processing step 513B the control is passed to step 514B. Here, the other MAPs identified in step 513B are informed of the changed or new BC entries. After completing step 514B, the control is passed to the main loop. It can be 500B or 512B depending on the event that is first in the event scheduler.
In yet another preferred embodiment of the present invention, if MR 521 in
In one preferred embodiment of the present invention, when MR 521 and MR 520 make registration at their selected MAP they need not send other MAP addresses. MAPs can do a self-check on their BCE to see whether all the required LCoAs are present to reach a RCoA registered there. For example, if the RO parameter in
The difference between this and the previous technique where the other MAP address was sent in the option is that in this technique, “query” and “response” are required to get the BCE entries and this is more of a reactive type of transfer; whereas the former technique is more of a proactive type of transfer. In another way, MAP 530 need not have other MAP information but can send an anycast message constructed using the prefix of RCoA of MR 520 to trace the relevant MAP. Of course, that MAP 531 should be assigned this anycast address value. For one skilled in the art, not only these there may be numerous ways to trace the other MAP in order to send the query message mentioned in this embodiment. It is also important to appreciate if the system has a prefix delegation based/PSBU based HMIPv6 RO mechanism, the MAP 530 by merely inspecting the LCoA of VMN 510 entry at BCE 561 can find the MAP at which the other entries are available. This can be easily understood by one skilled in the art.
In yet another preferred embodiment of the present invention, if a MR knows by some means—that the MAP options processed by downstream MRs or MNs (for example, MR 520 and VMN 510 are downstream to MR 521), then the MR will only send downstream MRs and MNs the MAP addresses in the registration it makes to its own MAP. This is because a particular MR's location registration value is required only at the MAPs of downstream MRs and MNs. The upstream MRs MAPs do not need downstream MRs' registrations. In this way, not all MAP addresses need to be sent as disclosed in a previous embodiment that explained
In yet another preferred embodiment of the present invention, another variation of the main invention is disclosed. This variation is explained via
In
It is further assumed that if the system (VMN 610, MR 620, MAP 630 and MAP 631) has ARO enabled HMIPv6 functionality with ARO parameter being mobile access router's RCoA (sub-scenario 1), then BCE 661 will be created at the MAP 630 when the invention disclosed in the current embodiment is operating. If the system (VMN 610, MR 620, MAP 630 and MAP 631) has ARO enabled HMIPv6 functionality with ARO parameter being mobile access router's HoA and some MAP intelligence (sub-scenario 2), then BCE 662 will be created at the MAP 630 when the invention disclosed in the current embodiment is operating. If the system (VMN 610, MR 620, MAP 630 and MAP 631) has ARO enabled HMIPv6 functionality with ARO parameter being mobile access router's HoA (sub-scenario 3), then BCE 663 will be created at the MAP 630 when the invention disclosed in the current embodiment is operating.
When analyzing the problem in the prior art, it was clearly understood that in a multi-MAP scenario where multiple MAP options are available, MNs and MRs in nested NEMO tree path can end up choosing different MAPs to configure RCoAs and thus route sub-optimality occurred. To resolve this problem, it is assumed that when MR 620 receives RA 682 and realizes that the MAPs are not too overloaded or have similar preference values, MR 620 decides to register at a single MAP (in this case MAP 630) and hence only send the MAP 630 option in the RA it creates. This is the core point of the invention disclosed in this current embodiment. Thus, MR 620 does a local registration at MAP 630, which is shown by the first row of entries in BCE 661, BCE 662 and BCE 663. After that, MR 620 will send its RA 683 and in this RA 683 it will only send the MAP 630 option. This can be seen by packet 680. This packet 680 may also have ARO parameter and/or some prefix parameter.
In the event of receiving such a RA 683, VMN 610 in sub-scenario 1 will first process the MAP 630 option and make a local registration at BCE 661 and the created entries are shown by the second row of entries at BCE 661. From BCE 661 it can be seen that RCoA of VMN 610 can be readily traced using the ARO mechanism and thus the data packet coming from CN 650 will be encapsulated in a single tunnel at MAP 630. The tunnel first destination address will be LCoA of MR 620 and the final address will be LCoA of VMN 610.
In the event of receiving such a RA 683, VMN 610 in sub-scenario 2 will first process the MAP 630 option and make a local registration at BCE 662 and the created entries are shown by the second row of entries at BCE 662. After the second row of entry is created, since the MAP 630 does not have registration to HoA of MR 620, it will send an ACK to VMN 610 but the first destination address will be set to HoA of MR 620. When MR 620 receives this, it will further send an ARO registration using RCoA because its care-of address is set to RCoA. This said ARO recursive entry is shown by the third row of entry at BCE 662. MAP 630 can possibly use some intelligent tracing to find all the LCoAs required reaching RCoA of VMN 610 optimally.
In the event of receiving such a RA 683, VMN 610 in sub-scenario 3 will first process the MAP 630 option and make a local registration at BCE 663 and the created entries due to this said registration are shown by the second row of entries at BCE 663. After the second row of entry is created, since the MAP 630 does not have registration to HoA of MR 620, it will send an ACK to VMN 610 but the first destination address will be set to HoA of MR 620. When MR 620 receives this, it will further send an ARO registration where the addresses registered will be HoA and LCoA of VMN 610. Thus, this said ARO recursive entry is shown by the third row of entry at BCE 663. MAP 630 can possibly use its normal ARO tracing operation to find all the LCoAs required reaching RCoA of VMN 610 optimally.
It can be well understood by one skilled in the art that, by making all the MNs and MRs in the nested NEMO tree path attach at a single MAP, all LCoAs required to optimally reach a RCoA associated with a MN or MR in the said nested NEMO tree path can be traced (No split cache problem). Thus, data packet originated at CN 650 will traverse via the most optimized route given by message segments 685 and 684 in
The main problem with the method disclosed in this current embodiment when compared to the methods disclosed via
In the event that nested NEMO is heavily congested, MR could possibly switch mode from the method disclosed in
In yet another preferred embodiment of the present invention, when MR 620 in
In yet another preferred embodiment of the present invention another variation of the main invention is disclosed and this said variation is further explained via
In
When VMN 710 performs local registration at MAP 730, the entry created at MAP 730 is given by BCE 761. It is further assumed that VMN 710 is having a local mobility management based RO with CN 750. Thus, it is assumed that VMN 710 will perform RR and MIPv6 BU with CN 750 using RCoA as its care-of address. The BCE at CN 750 is given by BCE 760.
It is considered in this embodiment that an arbitrary MAP in MAP cloud 771 has no special functionality to find out whether its binding cache entries are adequate or which MAPs to query to get the relevant entries. It is further considered that every MAP knows all other MAPs in the domain. Henceforth, in this method, new or renewed binding cache entries are sent to every other MAP in the domain by every single MAP. This flooding of BCE transfers is shown by signaling message 786. After such transfer 786, all the MAPs binding cache entries will be same. It can be readily understood that after transfer 786, BCE 761 will definitely have all entries of MR 720 and MR 721. In such a case, it is clear to one skilled in the art that RCoA of VMN 710 can be fully traced at MAP 730. Nevertheless, it is also clear that this method creates unnecessary duplicate permanent entries in the MAPs until the nodes are roaming in the domain (the domain itself can be big and house many MNs and MRs). This is the drawback of this method. When CN 750 sends its data packet to VMN 710 it will be intercepted by MAP 730 and encapsulated in a single tunnel to VMN 710. The route optimized data path from VMN 710 to CN 750 is shown by path segments 784 and 785 in
In yet another preferred embodiment of the present invention, a slight variation of the method disclosed via
In another preferred embodiment of the present invention, a method is disclosed where MNs and MRs in the nested NEMO tree path choose one out of n MAPs available and make a registration at the selected MAP. In this current embodiment, it is considered that flooding of BCEs among MAPs as disclosed in
Until now the main inventions and its variations were explained to eliminate route sub-optimality problem in nested NEMO in a multi-MAP scenario. From the two main methods given in the embodiments, it is clear that the first approach is a duplicate registration at another MAP but originated from the terminal (MR) where as the second approach is duplicate registration by transfers are done in the network domain. Next we will look at some scenarios where such kind of duplicate registrations are useful to solve certain problems in alternate scenarios.
Currently in local mobility management, lot of focus is on the NetLMM domain. In NetLMM domain, the local mobility management signaling is done fully via fixed network links and the roaming MN/MR is not aware of its care-of address change nor it is aware that it is moving in a NetLMM domain. In such domains, for load balancing, it is common to deploy multiple local mobility anchors (LMAs). In an alternate domain called the Proxy Mobile IPv6 domain as disclosed in [Non Patent Citation 7], Proxy Mobility Anchor (PMA) sends Proxy MIPv6 signaling on behalf of a roaming MN/MR/IPv6 Host to Proxy Home Agent (PHA). In such a Proxy MIPv6 domain as well, multiple Proxy Home Agents can be deployed for load balancing purposes. Proxy Mobile IPv6 domain is a domain similar to NetLMM domain but, mainly targeted to extend mobility services to IPv6 hosts that are roaming in their home domain. Next we will explore, how such duplicate location registration originated from a MR and MAP-to-MAP transfer of locations registrations disclosed in previous embodiments is useful to solve some issues in NetLMM and Proxy MIPv6 domains.
In the forthcoming embodiments, in the NetLMM domain, it is assumed that the MAG functionality, which is usually implemented in an AR, does the location management signaling on-behalf of the MN. This MAG functionality as disclosed in the [Non Patent Citation 6] can also be centrally located at a PMIP Client. In such a case, the PMIP client sends the local BU to the LMA and binds the MN identifier or care-of address of MN to the address of the AR (the said MN is currently attached to). It can be well understood by one skilled in the art that the above said local BU can also be sent by an AR with PMIP client functionality. In the Proxy MIPv6 domain as disclosed in [Non Patent Citation 7], the MAG functionality can be located at the Proxy MIPv6 Agent. Here, the said agent does proxy registration at the proxy home agent. This said proxy home agent is similar to the LMA in the NetLMM domain.
In another preferred embodiment of the present invention, a method where LMA to LMA location entry transfer is revealed for load balancing purpose. This is further elaborated via
In such a scenario, LMA 831 may have some information on the usage of LMA 830 and may understand that it is not used much. Some database may preferably be queried to get this information. In such a case, LMA 831 could possibly transfer some of its entries (for load balancing purpose), including entries originated from MAG 820, to LMA 830. This said transfer is shown by message 872 in
It is also assumed that MN 810 has done MIPv6 registration at its CN 850. When CN 850 sends data packet to MN 810, it will set the destination address to value that is derived from prefix of LMA 831. Nevertheless, LMA 830 will capture this data packet and will encapsulate the packet in a tunnel to MAG 820. MAG 820—will decapsulate this data packet and pass the packet to MN 810. It is important to appreciate that by means of duplicate entries made at both LMA 831 and LMA 830 via the fixed NetLMM links, load balancing is achieved and moreover LMA 831 need not do any tunneling for the numerous data packets and thus can reduce its processing load. The above said data packet routing path after the LMA 831 to LMA 830 transfer is given by 873 in
In
In yet another preferred embodiment of the present invention, duplicate registration at multiple LMAs are made via the NetLMM fixed links for the purpose of increasing reliability of the transfer of highly important data. This duplicate registration is made for bi-casting purpose and it can be well understood by one skilled in the art that bi-casting may be essential to transfer important data when the fixed links in the NetLMM domain is congested. This is further explained via
In such a scenario, again it is considered that MAG 920 will send prefix of LMA 930 in RA 970. Further, MAG 920 will make a local registration at LMA 930 and this is shown by message 971 in
When CN 950 sends its data packet to MN 910, this data packet may reach LMA 931 first because it may be higher up in the routing hierarchy or it may inject routes to get the packet. In either case, LMA 931 will make a duplicate of the packet and further route the packet to LMA 930. Following that, one version of the data packet will be tunneled from LMA 931 to MAG 920 and another version, which was sent to LMA 930, will be tunneled from LMA 930 to MAG 920. This bi casting is shown by 975 and 974 in
In yet another preferred embodiment of the present invention, duplicate registration at multiple LMAs is done for the purpose of obtaining data packets even if there is a fixed link failure in the NetLMM domain. This method is shown in
It is assumed that MAG 1020 sends the prefix of LMA 1030 in its RA 1070 and MN 1010 configures its care-of address using the prefix of LMA 1030. Following that, MAG 1020 will make its local registration on-behalf of MN 1010 at LMA 1030. After some time, it is assumed that MAG 1020 stops getting packets from the link 1061 (due to broken link or congestion). MAG hence decides to continue using the prefix of LMA 1030 in its RA but make its local registration at LMA 1030 via LMA 1031. MAG 1020 may get a hint from L2 that the link 1061 is broken or congested and may decide to use this alternate method. Thus the local registration to LMA 1030 is tunneled via LMA 1031 and this is shown by message 1071 in
In this embodiment, since LMA 1030 is not considered overloaded, it can possibly still receive data packets sent from CN 1050 and it is further considered that LMA 1031 need not inject routes to capture packets that are derived from prefix of LMA 1030.
It is further assumed that MN 1010 does RR and MIPv6 registration at CN 1050. The data packet will reach LMA 1030 and this message is shown by 1073 in
Although the invention has been herein shown and described in what is conceived to be the most practical and preferred embodiment, it will be appreciated by those skilled in the art that various modifications may be made in details of design and parameters without departing from the scope and ambit of the invention. For instance, the present invention uses ARO scheme as the route optimization mechanism used in nested mobile networks. It should be appreciated by a person skilled in the art that the present invention could be applied to other route optimization mechanism as well, such as one that uses mobile router's address in some way to achieve route optimization. In addition, the present invention uses HMIPv6 as the local mobility management protocol. It should be appreciated by a person skilled in the art that the present invention could be applied to other local mobility management protocols as well. Furthermore, this invention talks about roaming in local mobility management domains comprising of MAPs, NetLMM domain comprising of multiple LMAs and Proxy Mobile Iv6 domain comprising of multiple Proxy Home Agents. It should be appreciated by one skilled in the art that the present invention could well be applied in other local mobility management domains comprising of different types of mobility management anchors.
The present invention has the advantage of providing a useful mechanism in an ARO and HMIPv6 heterogeneous environment, and can be applied to the field of packet-switched communication.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2007-254783 | Sep 2007 | JP | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/JP2008/002672 | 9/25/2008 | WO | 00 | 3/25/2010 |
