Operaciones para el tratamiento de la chapa natural

From earlier work, two primary ways to signal QoS requirements to an access network can be identified. One way is to use DiffServ Code Points (DSCP) and the other one is to use RSVP with IntServ.

In the DiffServ-based solution there are three ways to use the DSCP values.

Firstly, the mobile node can mark the upstream packets if it knows the proper DSCP values. For the downstream the access network gateway must be able to

6.4 Local QoS Support 93 mark the incoming packets with proper code points. This can be accomplished by defining default values for different micro flows in the Service Level Agreement (SLA) negotiated between the client and the access network service provider. The values and their semantics can be provided to mobile nodes as a part of host auto-configuration.

The second way to make use of DiffServ is to have a Bandwidth Broker [136]

that dynamically returns the proper code point for each flow. When the first packet of a flow arrives at the access network edge router, the router requests the proper code point from the Bandwidth Broker. The router maintains a soft state mapping from micro flow identification to the DSCP so that future packets can be directly identified and labeled. The third way would be to define a protocol that a mobile node could use to dynamically adjust the mapping information stored at the access network edge for the incoming traffic.

The second mechanism to signal QoS requirements of a flow would be RSVP.

For upstream reservations, a mobile node sends the Path message to the access network gateway that returns the Resv message and sets up the reservations. The gateway would act similarly to an RSVP proxy [64]. However, the mobile node would need to know the address of each RSVP proxy in the network in order to be able to direct the reservation to the proper proxy. Alternatively, the RSVP proxy could intercept all outgoing RSVP messages and respond with the reservation preventing end-to-end reservations.

The reservation in the downlink direction is not as straightforward since the downlink reservation needs to be initiated by the RSVP proxy. Currently there is no mechanism that would trigger the proxy to initiate the RSVP signaling for a downlink flow.

Thus, the existing mechanisms do not seem to solve the signaling problem efficiently. The DiffServ mechanisms do not allow explicit resource reservations and are quite inflexible to change the treatment of ongoing flows. The problem with the RSVP proxy approach is that the proxy can not automatically distinguish reservations that would be answered by the correspondent node and reservations that would require interception. Additionally, the RSVP proxy needs a way to know when to allocate resources for incoming flows. Mobile access networks also add to the problems since mobile nodes can constantly change their point of attachment in the network and resource allocations need to be re-arranged.

6.4.2 Overview of the Approach

The usual signaling model of RSVP includes the data sender and receiver, and a network of RSVP routers as shown in Figure 6.3. The data sender initiates the RSVP signaling by sending the Path message. This message is routed through the network, setting states in RSVP routers, and finally arriving at the data receiver.

The receiver then responds to the signaling by sending the Resv message, which applies the reservation for the data stream.

RSVP

Figure 6.3: Basic idea in the Localized RSVP.

If the data receiver is not RSVP-aware, it can not respond to the signaling and make the resource reservation happen. Similarly, if the receiver is RSVP-ware, but the sender is not, the sender can not take part in the signaling for the resource reservation.

The presented scheme changes this basic model in that the application re-sponding to the RSVP messages sent by the data sender is not anymore located at the host receiving data, but, instead, is located closer to the local end host.

This application is called the LRSVP Proxy. From a software engineering per-spective, the proxy is an RSVP-aware application running on an RSVP router and able to respond to and initiate RSVP message exchanges. The proxy is located somewhere within the local access network—a good place would be the access network gateway as in Figure 6.3.

Now, in order to distinguish local reservations from end-to-end reservations, one bit is used from the unused Flags field in the RSVP Session Object. The Local Indication (LI) bit (currently we use bit 0x8) is used to differentiate reservations that are internal to the access network. When the bit is set the RSVP message is part of local resource signaling and the RSVP router running the proxy will not forward the message to the next hop but instead give the message to the proxy application running on the router. A default value of zero indicates standard end-to-end signaling, where the proxy application is not concerned.

A second bit is also needed, the Expedited Refresh (ER) bit (currently we use bit 0x4), to indicate that a Path message is sent as a refresh to a broken path and must be forwarded immediately. This indication is needed because each RSVP

6.4 Local QoS Support 95 hop propagates a Path message before a timeout only if the Path state has changed.

When a route changes at the receiver end of the data flow, a Path message is needed to set up again the Path state. This is discussed in more detail later.

When the local end host wants to make a resource reservation for a down-stream flow, it needs a Path message from a node on the data path. If the data sender is not RSVP-aware, the local end host can trigger the LRSVP proxy to send the Path message on behalf of the data sender. A new message type called

”Path Request”, with an initial message type number 8, is used to request a Path message from the local RSVP proxy. This message has the same structure as a standard Path message.

A second new message called ”Path Request Tear”, with an initial message type number 9, is used to tear down a downstream reservation. This message is similar in structure to a standard Path Tear message. Due to the new bits and message types, all RSVP routers inside the access network must be upgraded with the LRSVP extension.

When a local mobile node wants to reserve resources in the local access net-work, it uses the LI flag in RSVP messages to indicate a local reservation. The structure of the RSVP messages follows the RSVP standard. When the router run-ning the LRSVP proxy receives an RSVP message with the LI bit set it will notice that the flag was set and does not forward the message further to the next hop. The RSVP daemon on the router gives the message to the local RSVP proxy, which responds according to the following description. As discussed in Chapter 2.3, the Session object together with the Sender Template are used to define the data sender(s) and receiver(s) of the reservation. The security issues of the solution are discussed later in this section.

The first sketch of this solution appeared in [119] and [80], although some im-plementation ideas have changed since. The most recent specification is in [121], which has been contributed to the IETF NSIS [227] and TSVWG [232] working groups. A recent conference paper has primarily the same technical description of the protocol [120].