Subject: Re: What is the bad tspec?

From: "Hong Liao" <[email-masked]>
Date: Wed, 3 Jul 2002 14:21:30 -0400

Please read inline comments.

                    David Charlap                                                                      
                    <david.charlap@ma        To:     [email-masked]                                       
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                        
                                             Subject:     Re: What is the bad tspec?                   
                    07/03/02 01:29 PM                                                                  

Chetan Pinto wrote:
> Few examples
> (1) m should not be 0

No.  Zero means "don't care" in all IntServ objects - including TSPEC,
FLOWSPEC and ADSPEC.

Zero is legal for all fields.

>>>>>>>>>[Julia] I agree.

> (2) m must not be greater than M
> (3) r must not be greater than p

These make sense, as long as you keep in mind that M and p can be zero
without violating these rules.

>> If I set the token bucket rate very large, it will send back the patherr
>> msg with 'Requested bandwidth unavailable', it will not send the bad
>> tspec.

Keep in mind that a huge value in the TSPEC may not cause a PathErr.
Until the Resv message arrives from downstream, the actual size of the
reservation could be any value between zero and the value of the TSPEC.

If the FLOWSPEC in the Resv is too large, then a PathErr is mandatory.

>>>>>>>>[Julia]  If there is something wrong in the resv msg, it should
send the ResvErr instead of Patherr, right?

The TSPEC in a PathErr message is optional.  More specifically, the
entire sender descriptor (SENDER_TEMPLATE, TSPEC and ADSPEC) is optional
in PathErr.  IMO, the sender descriptor should be sent, because you
can't uniquely identify a single LSP within a session without it.

A PathErr with a SENDER_TEMPLATE, but no TSPEC doesn't seem to be legal,
according to my reading of RFC 2205.  (It violates the BNF description
of a sender descriptor in section 3.1.3.)  I wouldn't reject the
message, however, since the TSPEC can be determined by looking at the
stored value.  (Part of being liberal in what you accept.)

-- David

---

From: David Charlap <[email-masked]>
Date: Wed, 03 Jul 2002 14:32:14 -0400

Hong Liao wrote:
> If there is something wrong in the resv msg, it should

In straight RSVP, yes.  But in section 4.7.3 of RFC 3209, that changed.

Note the sixth paragraph of that section:

     If the requested bandwidth is not available a PathErr message is
     returned with an Error Code of 01, Admission Control Failure and an
     Error Value of 0x0002.  ...

In other words, for LSP-type sessions, PathErr should be generated if 
resources are unavailable.

-- David