Subject: resource reservation for LSPs

From: Kappler Cornelia <[email-masked]>
Date: Tue, 27 Feb 2001 17:03:33 +0100

I'm wondering about the definition for bandwidth reservation for LSPs. Sorry if this is obvious. 

My understanding is the following: Bandwidth for LSPs can be reserved using e.g. RSVP-TE. However, what does "reservation" mean? It means that at LSP establishment time, the LSR checks whether it has enough resources available. However, it only does a "book keeping" of its resources. It does not need to control their actual use. Admission control and policing must be performed by the LERs. If they don't do it, bandwidth is not guaranteed.

I derived this understanding from conversations with others. Cisco seems to implement it this way. Checking on RFCs and IDs however, the picture is not entirely straight:

draft-ietf-mpls-diff-ext-08.txt (MPLS Support of Differentiated Services) corroborates the above view:

"Establishing an E-LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signaled at LSP establishment time. Such signaled bandwidth requirements may be used by LSRs at establishment time to perform admission control of the signaled LSP over the Diff-Serv resources provisioned (e.g. via configuration, SNMP or policy protocols) for the relevant PSC(s)"

I.e. there is no mention of using the signaled bandwidth for on-line control of resource usage. 

I would expect to find something on the subject in the RSVP-TE draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. However, it only seems to talk about "reserving" bandwidth without defining what that is. It also says:

"an implementation SHOULD support the Controlled-Load service"

Checking, on "Controlled-Load service" one finds:

"Network elements must not assume that data sources or upstream elements have taken action to "police" controlled-load flows by limiting their traffic to conform to the flow's TSpec.  Each network element providing controlled-load service MUST independently ensure that the requirements given above are met in the presence of nonconformant arriving traffic for one or more controlled-load flows."

I.e. each individual LSP is responsible for guaranteeing bandwidth after all. 

Additionally, RFC 2205 on RSVP states

"During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". ... If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. "

So RSVP seems to require the individual routers make sure all flows receive their due. Since RSVP-TE is just an extension of RSVP I would assume it works with the same router requirements.

I am confused. Which one is it, must LSPs assure bandwidth reservations are met, or not?

Thanks for your help,

-- Cornelia Kappler

---

From: Eric Gray <[email-masked]>
Date: Tue, 27 Feb 2001 11:41:07 -0500

Cornelia Kappler,

    Increasingly often, the systems in production have the basic
capability (perhaps a software/firmware upgrade is required)
to manage bandwidth.  This is necessary in the general case
in order to be able to guarantee bandwidth through the network
- even when ingress devices are policing and/or traffic shaping
the data they admit to the network.

    This is true because not all traffic is strictly subject to
admission control based on a bandwidth guarantee.  For
example, there is the DiffServ model for QoS provisioning.
The purpose of the DiffServ model is to avoid introducing a
requirement for a lot of state information in the network
relating to bandwidth guarantees.

    If it is the intention that a network support both bandwidth
guarantees and differentiated services, then it is necessary that
QoS is more than a book-keeping exercise. :-)

---

From: David Charlap <[email-masked]>
Date: Tue, 27 Feb 2001 12:08:42 -0500

Kappler Cornelia wrote:
> 
> My understanding is the following: Bandwidth for LSPs can be reserved
> using e.g. RSVP-TE. However, what does "reservation" mean? It means
> that at LSP establishment time, the LSR checks whether it has enough
> resources available. However, it only does a "book keeping" of its
> resources. It does not need to control their actual use. Admission
> control and policing must be performed by the LERs. If they don't do
> it, bandwidth is not guaranteed.

For the most part, this is correct.  Transit routers may or may not also
do policing.  It shouldn't be necessary if the ingress router is
properly policing traffic, but it may not be safe to assume that this
will always be true.

Also note that artifacts of packet queueing algorithms may cause
compliant traffic to become non-compliant (at least for short bursts) at
some point along the LSP.  This may require a transit router to perform
policing, in order to enforce any service guarantees.  Routers may also
perform traffic shaping to try and minimize this effect.

> I would expect to find something on the subject in the RSVP-TE draft,
> draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. However, it only seems to talk
> about "reserving" bandwidth without defining what that is. It also
> says:

RSVP-TE, like RSVP, uses IntServ for its reservations.  Check out the
IntServ RFCs:
	RFC 2210
	RFC 2211
	RFC 2212
	RFC 2215

There are other possibly relevant RFCs that I haven't mentioned.  Search
for "Integrated Services" in the RFC index file to find them all.

-- David