rfc3175.Aggregation of RSVP for IPv4 and IPv6 Reservations

rfc文档

Network Working Group F. BakerRequest for Comments: 3175 C. IturraldeCategory: Standards Track F. Le Faucheur

B. Davie Cisco Systems September 2001 Aggregation of RSVP for IPv4 and IPv6 Reservations

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.Abstract

This document describes the use of a single RSVP (Resource

ReSerVation Protocol) reservation to aggregate other RSVP

reservations across a transit routing region, in a manner

conceptually similar to the use of Virtual Paths in an ATM

(Asynchronous Transfer Mode) network. It proposes a way to

dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the

bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.

1. Introduction

A key problem in the design of RSVP version 1 [RSVP] is, as noted in its applicability statement, that it lacks facilities for aggregation of inpidual reserved sessions into a common class. The use of such aggregation is recommended in [CSZ], and required for scalability. The problem of aggregation may be addressed in a variety of ways. For example, it may sometimes be sufficient simply to mark reserved traffic with a suitable DSCP (e.g., EF), thus enabling aggregation of scheduling and classification state. It may also be desirable to install one or more aggregate reservations from ingress to egress ofBaker, et al. Standards Track [Page 1]

rfc文档

an "aggregation region" (defined below) where each aggregate

reservation carries similarly marked packets from a large number of flows. This is to provide high levels of assurance that the end-to- end requirements of reserved flows will be met, while at the same time enabling reservation state to be aggregated.

Throughout, we will talk about "Aggregator" and "Deaggregator", referring to the routers at the ingress and egress edges of an aggregation region. Exactly how a router determines whether it should perform the role of aggregator or deaggregator is described below.

We will refer to the inpidual reserved sessions (the sessions we are attempting to aggregate) as "end-to-end" reservations ("E2E" for short), and to their respective Path/Resv messages as E2E Path/Resv messages. We refer to the the larger reservation (that which

represents many E2E reservations) as an "aggregate" reservation, and its respective Path/Resv messages as "aggregate Path/Resv messages".

1.1. Problem Statement: Aggregation Of E2E Reservations

The problem of many small reservations has been extensively

discussed, and may be summarized in the observation that each reservation requires a non-trivial amount of message exchange,

computation, and memory resources in each router along the way. It would be nice to reduce this to a more manageable level where the load is heaviest and aggregation is possible.

Aggregation, however, brings its own challenges. In particular, it reduces the level of isolation between inpidual flows, implying that one flow may suffer delay from the bursts of another.

Synchronization of bursts from different flows may occur. However, there is evidence [CSZ] to suggest that aggregation of flows has no negative effect on the mean delay of the flows, and actually leads to a reduction of delay in the "tail" of the delay distribution (e.g., 99% percentile delay) for the flows. These benefits of aggregation to some extent offset the loss of strict isolation.

1.2. Proposed Solution

The solution we propose involves the aggregation of several E2E reservations that cross an "aggregation region" and share common ingress and egress routers into one larger reservation from ingress to egress. We define an "aggregation region" as a contiguous set of systems capable of performing RSVP aggregation (as defined following) along any possible route through this contiguous set.

Baker, et al. Standards Track [Page 2]

rfc文档

Communication interfaces fall into two categories with respect to an aggregation region; they are "exterior" to an aggregation region, or they are "interior" to it. Routers that have at least one interface in the region fall into one of three categories with respect to a given RSVP session; they aggregate, they deaggregate, or they are between an aggregator and a deaggregator.

Aggregation depends on being able to hide E2E RSVP messages from

RSVP-capable routers inside the aggregation region. To achieve this end, the IP Protocol Number in the E2E reservation’s Path, PathTear, and ResvConf messages is changed from RSVP (46) to RSVP-E2E-IGNORE (134) upon entering the aggregation region, and restored to RSVP at the deaggregator point. These messages are ignored (no state is

stored and the mess …… 此处隐藏：37496字，全部文档内容请下载后查看。喜欢就下载吧 ……