Ping Pan

BGRP: Sink-tree-based aggregation for inter-domain reservations

Resource reservation must operate in an efficient and scalable fashion, to accommodate the rapid growth of the Internet. In this paper, we describe a distributed architecture for inter-domain aggregated resource reservation for unicast traffic. We also present an associated protocol, called the Border Gateway Reservation Protocol (BGRP), that scales well, in terms of message processing load, state storage and bandwidth. Each stub or transit domain may use its own intra-domain resource reservation protocol. BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network. Since backbone routers maintain only the sink tree information, the total number of reservations at each router scales linearly with the number of Internet domains N. (Even aggregated versions of the current protocol RSVP have a reservation count that can grow like O(N2).) BGRP maintains these aggregated reservations using “soft state.” To further reduce the protocol message traffic, routers may reserve bandwidth beyond the current load, so that some sources can join or leave the tree without sending messages all the way to the tree root. BGRP relies on Differentiated Services for data forwarding, hence the number of packet classifier entries is extremely small.

BGRP: A Tree-Based Aggregation Protocol for Inter-domain Reservations

Resource reservation needs to accommodate the rapidly growing size and increasing service diversity of the Internet. Recently, hierarchical architectures have been proposed that provide domain-level reservation. However, it is not clear that these proposals can set up and maintain reservations in an efficient and scalable fashion. In this paper, we describe a distributed architecture for inter-domain aggregated resource reservation for unicast traffic. We also present an associated protocol, called the Border Gateway Reservation Protocol (BGRP), that scales well, in terms of message processing load, state storage and bandwidth. Each stub or transit domain may use its own intra-domain resource reservation protocol. BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network. Since backbone routers only maintain the sink tree information, the total number of reservations at each router scales linearly with the number of domains in the Internet. (Even aggregated versions of the current protocol RSVP have an overhead that grows like N.) BGRP relies on Differentiated Services for data forwarding. As a result, the number of packet classifier entries is extremely small. To reduce the protocol message traffic, routers may reserve domain bandwidth beyond the current load, so that sources can join or leave the tree or change their reservation without having to send messages all the way to the tree root for every such change. We use “soft state” to maintain reservations. In contrast to RSVP, refresh messages are delivered reliably, allowing us to reduce the refresh frequency. Columbia University Computer Science Technical Report No. CUCS-029-99

YESSIR: a simple reservation mechanism for the Internet

RSVP has been designed to support resource reservation in the Internet. However, it has two major problems: complexity and scalability. The former results in large message processing overhead at end systems and routers, and inefficient firewall processing at the edge of the network. The latter implies that in a backbone environment, the amount of bandwidth consumed by refresh messages and the storage space that is needed to support a large number of flows at a router are too large. We have developed a new reservation mechanism that simplifies the process of establishing reserved flows while preserving many unique features introduced by RSVP. Simplicity is measured in terms of control message processing, data packet processing, and user-level flexibility. Features such as robustness, advertising network service availability and resource sharing among multiple senders are also supported in the proposal.The proposed mechanism, YESSIR (YEt another Sender Session Internet Reservations) generates reservation requests by senders to reduce the processing overhead, builds on top of RTCP, uses soft state to maintain reservation states, supports shared reservation and associated flow merging and is compatible with the IETF Integrated Services models.YESSIR extends the all-or-nothing reservation model to support partial reservations that improve over the duration of the session.To address the scalability issue, we investigate the possibility of using YESSIR for per-stream reservation and RSVP for aggregate reservation.

Staged refresh timers for RSVP

The current resource reservation protocol (RSVP) design has no reliability mechanism for the delivery of control messages. Instead, RSVP relies on periodic refresh between routers to maintain reservation states. This approach has several problems in a congested network. End systems send PATH and RESV messages to set up RSVP connections. If the first PATH or RESV message from an end system is accidentally lost in the network, a copy of the message will not be retransmitted until the end of a refresh interval, causing a delay of 30 seconds or more until a reservation is established. If a congested link reuses a tear-down message (PATHTEAR or RESVTEAR) to be dropped, the corresponding reservation will not be removed from the routers until the RSVP cleanup timer expires. We present an RSVP enhancement called staged refresh timers to support fast and reliable message delivery that ensures hop-by-hop delivery of control messages without violating the soft-state design. The enhancement is backwards-compatible and can be easily added to current implementations. The new approach can speed up the delivery of trigger messages while reducing the amount of refresh messages. The approach is also applicable to other soft-state protocols.

Processing overhead studies in resource reservation protocols

We study the signaling cost factors from two aspects: reservation retry process (or how to recover from reservation blocking), and one-pass signaling. Through simulation, we discover that the reservation retry mechanism used in RSVP is not only process intensive, but also the reservations are slow to converge. We thus explore several design options that can speed up reservation setup and quickly recover from partial reservations. To gain a better understanding of reservation overhead, we have implemented a lightweight one-pass reservation protocol, YESSIR. We show that with careful implementation and by using some of basic hashing techniques to manage flow states, we can achieve good performance with low processing cost. Our YESSIR implementation can support up to 10,000 flow setups per second (or about 300,000 active flows) on a commodity 700 MHz Pentium PC.

PF_IPOPTION: A Kernel Extension for IP Option Packet Processing

Existing UNIX kernels cannot easily deliver IP packets containing IP options to applications. To address this problem, we have defined and implemented a new protocol family called PF IPOPTION for the FreeBSD kernel. We have verified the implementation with some of the commonly used IP options. Measurements in kernel and user space showed that BSD socket I/O is the performance bottleneck.

Lightweight Resource Reservation Signaling: Design, Performance and Implementation

Recent studies take two different approaches to admission control. Some argue that due scalability limitations, using a signaling protocol to set up reservations is too costly and CPU-intensive for routers. Instead, end users should apply various end-to-end measurement-based mechanisms to run admission control. Several other proposals have recommended to reduce the number of reservations in the network by using aggregation algorithms, and, thus, reduce the number of signaling messages and states. We study the signaling cost factors, propose several solutions that achieve good performance with reduced processing cost, and evaluate an implementation of a lightweight signaling protocol that incorporates these solutions. First, we identify some the protocol design issues that determine protocol complexity and efficiency, namely the choice of a two-pass vs. one-pass reservation model, partial reservation, and the effect of reservation fragmentation. We also explore several design options that can speed up reservation setup and quickly recover from reservation fragmentation. Based on the conclusion of these studies, we developed a lightweight signaling protocol that can achieve good performance with low processing cost. We also show that with careful implementation and by using some of basic hashing techniques to manage flow states, we can support up to 10,000 flow setups per second (or about 300,000 active flows) on a commodity 700 MHz Pentium PC.