SIGLITE is an effort to study lightweight signaling for Internet
resource reservation. Though it may be useful and insightful sometimes, here, we
should try to avoid further debate on "do we need resource reservation".
It might be helpful to assume that we might need it for "some" subset
of Internet flows in some network, and maybe get some grasp on the scaling issues - i.e., what are
reasonable assumptions on scaling needs. (In other words, scaling doesn't much matter if only 100 Mb/s flows need it or can get it, since
you're not likely to have too many of them at any given time.)
Here are the technical issues that we are trying to address in SIGLITE:
- There is the perception at least that traditional QoS signaling is hard to implement and resource-intensive (in memory code or data space
and/or CPU cycles), in particular for low-end end systems such as IP phones and Internet appliances, even though the task at hand is pretty
simple: "May I have 100 kb/s to 18.104.22.168?" "Yes, please."
- There's a fair amount of disagreement as to scaling of per-flow or per-aggregate reservation. Some say that this doesn't scale, some say
that it doesn't need to scale, some say that scaling problems are primarily issues of either implementation or protocol complexity, not
necessarily the notion of reservation state in the network. Are there mechanisms to address these scaling issues? What are the trade-offs in
terms of the type of services that can be provided (e.g., not all metrics may be amenable to being aggregated)?
- Also, we seem to be lacking a mechanism for negotiating and conveying prices for QoS. (The usual disclaimer: the IETF doesn't get involved in
business models, so this topic may need to be suitably abstracted before it becomes BOF material, but since this mailing list is not a WG
mailing list, this shouldn't keep us from discussing the topic, if there's interest.)
- Some have proposed that there's a wider class of problems that need signaling at the lower layers, such as tunneling through a bunch of
firewalls and NATs or setting up lambda or label paths across some circuit-like network. Is there a common protocol or architecture
infrastructure that can be re-used for a variety of signaling needs? Is there such a thing as signaling, which I'm defining loosely as protocols
and mechanisms for establishing distributed state in the network?
For further understanding on Internet QoS, please refer to RFC2990:
Next Steps for the IP QoS Architecture.
Over the years, there have been many studies on, signaling scaling and
- Reduce State Maintenance Overhead in RSVP:
- Staged Refresh
Timers for RSVP, P. Pan, and H. Schulzrinne, Global Internet'97.
- RSVP Refresh Overhead Reduction Extensions,
L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and S. Molendini, Internet
Draft, June 2000.
- RSVP Refresh Overhead Reduction by State Compression,
L. Wang, A. Terzis and L. Zhang, Internet Draft, March 2000.
- Reduce the Number of RSVP States in the Network:
RSVP-based QoS Requests, R. Guerin, S. Herzog and S. Blake, Internet
Draft, November 1997.
- Aggregation of RSVP for IPv4 and IPv6 Reservations,
F. Baker, C. Iturralde, F. Le Faucheur,
and B. Davie,
Internet Draft, March 2000.
- Aggregation of Internet Integrated Services State,
S. Berson and S. Vincent, IWQoS'98.
- Reduce Router's Overhead with Centralized Control: (Bandwidth Broker,
or Reservation Agent)
- A Two-bit Differentiated Services Architecture for the Internet,
K. Nichols, V. Jacobson, and L. Zhang, RFC2638.
- A Two-Tier Resource Management Model for the Internet,
A. Terzis, L. Wang, J. Ogawa and L. Zhang, Global Internet 1999.
- A Two-Tier Resource Management Model for Differentiated Services
Networks, F. Reichmeyer and L. Ong, A. Terzis, L. Zhang and R.
Yavatkar, November 1998.
Resource Reservation Over Multiple Routing Domains, O. Schelen and Steve Pink,
- Reduce Router's Overhead via Distributed Control:
- BGRP: A Tree-Based
Aggregation Protocol for Inter-domain Reservations, P.
Pan, E, Hahne, and H. Schulzrinne, Journal of Communications and
Networks, Vol. 2, No. 2, June 2000, pp. 157-167.
- BGRP: A Framework
for Scalable Resource Reservation, P. Pan, E, Hahne, and H.
Schulzrinne, Internet Draft, December 1999.
- A Provider Architecture for Differentiated Services and Traffic
Engineering (PASTE), T. Li, and Y. Rekhter, RFC2430.
- Simplify Reservation Sequence:
- YESSIR: A Simple
Reservation Mechanism for the Internet, P. Pan, and H. Schulzrinne,
- Scalable Resource Reservation for the Internet,
W. Almesberger, J. Le Boudec and T. Ferrari, PROMS-MmNet'97.
- A case for dynamic sender-based reservations in the
Internet, P. White and J. Crowcroft, HPN'98.
- Boomerang - A Simple Protocol for Resource Reservation in IP
Networks, G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J. Bergkvist,
D. Ahlard, and T. Engborg, RTAS'99.
Another aspect in Siglite is to evaluate different Internet QoS pricing
In the past several years, there have been some studies on RSVP performance:
There are more papers on RSVP available at the official
by Ping Pan, Henning