Aggregation policies over RSVP tunnels

Abstract

Abstract-IETF's integrated service with resource aggregation techniques provide a mechanism to reduce the RSVP states kept at router. Therefore, it reduces the number of RSVP refresh messages exchanged across routers. But the high frequency of setup messages exchanged between the edge routers can hinders the performance of aggregation. In this paper, we look at the management of the aggregation of resources over IP-in-IP tunnel with a view of reducing the setup messages. We develop and compare the cost functions of three aggregation control policies: the Temporal Operating Policy, the Cardinal Operating Policy, and the Resource Threshold Operating Policy. We also figure out the conditions under which the operating costs of these policies are minimum. Furthermore, we compare the performance of these policies under different conditions and shown that the Temporal Operating Policy will be more cost effective than the other two policies.

Aggregation methods for integrated services

“…Another way to reduce the frequency of aggregation adjustment is to set a waiting period, and then only one adjustment is performed by considering all requests received during this period. Two policies for setting the waiting period are proposed in [14,16], Temporal Operating Policy (TOP) and Cardinal Operating Policy (COP). The former configures the waiting period as a fixed time interval, the latter configures it as a varying time interval during which the received number of requests is fixed.…”

“…In this section, we briefly describe two aggregation policies cited above, TOP and COP, and amend the cost functions that have been done in [14]. With TOP, ingress router waits a T interval before making an aggregate reservation for all requests received during this T interval, whereas, in COP, the ingress router does not perform reservation aggregation until it receives K requests.…”

“…With TOP, ingress router waits a T interval before making an aggregate reservation for all requests received during this T interval, whereas, in COP, the ingress router does not perform reservation aggregation until it receives K requests. Since we consider underutilization as one major cost for aggregate reservation and ignore edge router processing, the cost functions defined in [14] should be amended. Before calculating the cost functions, we define three subcosts:…”

“…Then, in Section 3, we describe the aggregation adjustment procedure of our proposed policies. Since we will compare our policy with two other polices proposed in [14], we amend their cost functions in Section 4. The optimal value for the aggregation size and the lower threshold is calculated by TBP in Section 5.…”

“…Those values are calculated by RVP in Section 6. Then, in Section 7, we present a set of simulation experiments to compare our policies with those in [14]. Finally, we conclude our work in Section 8.…”