Subject: RE: How to calculate the actual delay when signaling QoS

From: Shahram Davari <[email-masked]>
Date: Fri, 11 May 2001 08:05:47 -0700

Hi David,

What about the optional ADSPEC in RSVP-TE, can't it be used to return the C and D terms needed to compute the delay, and be used for admission control? (i.e., GS over MPLS)

-Shahram

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Friday, May 11, 2001 10:03 AM
> To: [email-masked]
> Subject: Re: How to calculate the actual delay when signaling QoS
> 
> 
> shen jing wrote:
> > 
> > My question is:  the signaling procedure only consider the
> > bandwidth needed, real transmission dely and jitter can  not be
> > got when calculating a explicit path, right?
> 
> And it doesn't matter because none of the three MPLS 
> signaling protocols
> let you make delay/jitter-based reservations.
> 
> -- David
>

---

From: David Charlap <[email-masked]>
Date: Fri, 11 May 2001 11:34:20 -0400

Shahram Davari wrote:
> 
> What about the optional ADSPEC in RSVP-TE, can't it be used to
> return the C and D terms needed to compute the delay, and be used
> for admission control? (i.e., GS over MPLS)

The ADSPEC is only used in Path processing, not Resv.  An egress router
can learn the delay characteristics along the route the Path message has
followed, but there is no way for it to turn around and make a
delay-bounded reservation.

In MPLS, where the resources reserved will always match the TSPEC, the
information is not useful.  In straight RSVP, where the endpoint is an
application and not a router, it might be able to use this to adjust the
bandwidth or set an application-layer parameter.

-- David