Addressing Issues for Downstream Reservations

In the localized signaling mechanisms there is the important question of what destination address the mobile node should use when it initiates a downstream reservation setup. The answer has implications on the network path on which the reservation will be set up. On upstream reservations, the resources are set up on the proper path even in handover situations.

The Session Object and the Sender Template define the parties involved in the reservation. Thus, the destination IP address is not needed in the reservation set up but it affects the routing of packets. The issue concerns the situations where there are several ingress routes to the access network. In such a scenario, LRSVP proxies might be located further away from the access routers, closer to the edge of the access network, for example.

There are two fundamentally different options for the IP destination address.

The first option is that the mobile node can use the IP address of the host that it intends to communicate with. This has the benefit that a Path message will be routed according to the usual IP routing mechanisms. Thus, the Path message will be routed to the proxy that will eventually also receive the upstream data flow. This works regardless of whether the correspondent node is fixed or mobile.

1We have made the assumption that each access point has its own dedicated network interface at the access router. Otherwise, IP resource sharing between several access points and mobile nodes served by them becomes somewhat more complex, because IP resource sharing on an interface must also take into account the MAC address of mobile nodes.

However, if the correspondent node is mobile and its IP address changes, the reservation is not effective and must be renewed.

If the mobile wants to set up a reservation for the downlink on behalf of the correspondent node, there is a potential problem. If the access network has several ingress routes, for example access network gateways, there will most probably be several LRSVP proxies. Thus, the data flow may eventually arrive through a path different from the path that had a reservation in place. This can happen because IP routing is not symmetric by default. Figure 6.8 illustrates the problem.

The mobile node might set up a reservation on behalf of the correspondent node through a path using the LRSVP proxy A in Figure 6.8. However, the data will actually arrive through a path through LRSVP proxy B. The same problem arises if the mobile node wants to reserve resources without an exact sender IP address. An example is that the mobile node wants resources for audio streams initiated while browsing the Internet without specifying all possible Web servers that it may be using.

0000

Figure 6.8: Example of the Localized QoS Signaling Protocol.

The first solution is to use the destination address of the correspondent host the local mobile node is trying to initiate a reservation for. However, the end host may not know the correspondent node address, for example, if it wants to allocate resources only for certain services regardless of the sender, to have a smooth and fast web browsing session using HTTP, for example.

Thus, the second option for the IP destination address is to target the signaling to the LRSVP proxy. In this case the mobile node must be given an address of the proper LRSVP proxy through auto-configuration. However, if the access network has several LRSVP proxies and the mobile node moves constantly, it may need to be given a new LRSVP proxy address from time to time. Alternatively, in an IPv6 access network, LRSVP proxies could be allocated a well-known anycast address.

When an access router receives RSVP requests from mobile nodes, it will forward

6.4 Local QoS Support 103 the requests to the closest LRSVP proxy.

An alternative is that the mobile node directs the localized RSVP messages to all LRSVP proxies. This can be achieved using a multicast address of all the LRSVP proxies. As a result, each LRSVP in the access network would receive the RSVP packets, a Path or a Path Request, and respond to the mobile. Since re-source reservations are set up on several paths but only some of them will actually be used, a mechanism is needed to remove unnecessary reservations. This can be accomplished using the RSVP soft state mechanism. The unused reservations are revoked using a timeout mechanism when no refresh messages are sent for those paths. This is possible if the reservation refresh is coupled with actual data transferred through the reservation. The reservations are only kept alive if data is actually sent through the actual path.

The multicast functionality can further be modified so that a proxy will not even send the Path message if it does not receive packets from the specified sender within a timeout. Thus, no downstream reservation is initialized for paths that are not carrying packets belonging to the request. Furthermore, it is possible to make the RSVP daemon running on the access router to multicast the messages from the local mobile node to all LRSVP proxies in the network and, thus, set up reservation states for all inbound routes. This would be done only when the LI bit is set and the reservation does not define a specific correspondent node.

However, multicasting packets introduces heavy signaling, which raises questions about scalability and efficient resource usage in large access networks.

Regardless of the specific solution, it is important that the implementation should be transparent to the mobile node. The mobile node would always operate in the same way when it wants to set up a QoS reservation for downstream flows.

When a mobile node wants to reserve resources for the downstream, it should use as IP destination address, in order,

1. the IP address of the correspondent node, or, if the address is not known, 2. an LRSVP proxy address anycast address provided in the host

auto-configuration, or, if such an anycast address is not provided,

3. an LRSVP proxy unicast address provided in the host auto-configuration, or, if such an unicast address is not provided,

4. an LRSVP proxy multicast address provided in the host auto-configuration, or, if such a multicast address is not provided,

5. the default router address.

The LRSVP proxy address can be a unicast or multicast address. It should be up to the access network to take care of removing unneeded reservations. If

the mobile node does not have the LRSVP proxy address configured, it will use the default router address. The access router can then perform routing lookup and address translation so that it can forward the Path Request message to the correct LRSVP proxy.

If the mobile node is using Mobile IP, it must use the Care-of-Address as the address in the Session Object address field. If the CoA changes in a handover, the mobile node needs to create a new Path message, and hence Path state, to set up new upstream reservations. A new Path state is needed, if the filters in the old Path state used the CoA of the mobile node as a part of filtering.