Subject: RE: resource preemption

From: John Sparr <[email-masked]>
Date: Fri, 4 Aug 2000 07:58:22 -0700 (PDT)

Bill,

I agree with you. But I think it should not be
receiver because it just requires BW not allocates. Is
that right?

Thanks in advance
John

--- "Sanford, Bill" <[email-masked]> wrote:
> Wouldn't it be the first node that didn't have the
> bandwidth, wherever it
> was?
> 
> Bill
> -----Original Message-----
> From: John Sparr [mailto:[email-masked]]
> Sent: Friday, August 04, 2000 10:30 AM
> To: [email-masked]
> Subject: resource preemption
> 
> 
> Hi,
> 
> Quick question on resource preemption from RSVP-TE.
> 
> In section 4.8.3, it says when a new Path message is
> considered for admission, the bandwidth requested is
> compared with the bandwidth at the priority
> specified
> in the Setup Priority.
> 
> My question is who will do this compare,
> intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 4 Aug 2000 11:17:23 -0500

John

The compare is done in several places depending on 
how the path was calculated. 

Initially the path selection algorithm performs the 
compare at each node in the topology database. This step
can be skipped if you calculate the ERO manually or offline.

Then as a path message is processed at each single hop the 
comparison is performed again for each link traversed. 
The receiver does not have do anything, since the bandwidth 
has been allocated by all the single hops along the way. 

Don

> compared with the bandwidth at the priority specified
> in the Setup Priority.
> 
> My question is who will do this compare, intermidiate
> nodes or receiver?
> 
> 
> Thanks in advance
> John
>

---

From: John Sparr <[email-masked]>
Date: Fri, 4 Aug 2000 09:51:44 -0700 (PDT)

Bill,

One more question: what's the meaning of "the only
priority left is the Holding priority in the LSP just
established" ?  It seems that the Setup priority is
reset or what others? My understanding is right?

Thanks
John

--- "Sanford, Bill" <[email-masked]> wrote:
> John, the setup priority is checked every hop.  Once
> a hop doesn't have the
> bandwidth, the setup priority in the PATH message
> checks to see if an LSP
> with a holding priority lower than itself can be
> bumped.  Two things can
> happen, either the PATH message is refused and a
> PATH_ERR is sent back to
> the Ingress or it bumps an LSP with a lower holding
> priority and moves
> downstream.  The setup priority in the PATH message
> will most likely do this
> multiple times downstream. 
> 
> Once the setup priority in the PATH message has
> successfully got to the
> Egress the only priority left is the Holding
> priority in the LSP just
> established. So as far as who will do the compare of
> the setup priority,
> every downsteam node does except the receiver.
> 
> Sent: Friday, August 04, 2000 10:58 AM
> To: Sanford, Bill
> Cc: [email-masked]
> Subject: RE: resource preemption
> 
> 
> 
> Bill,
>

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 4 Aug 2000 14:48:49 -0400

Hi

I think I know where your confusion comes from, the fact that although
you reserve on the path message you lock in the bandwidth on 
the resv message. So I wouldn't preempt until the resv 
comes back (because the path message might have failed at 
subsequent hops). So in reality you do a check in both messages.

Don

> From: Navin [mailto:[email-masked]]
> Sent: Friday, August 04, 2000 11:15 AM
> To: John Sparr; mpls
> Hi There,
> First of all, you carry out admission control check while
> processing the RESV message NOT PATH message.
> 
> Secondly, admission control check will be done at all the nodes
> EXCEPT the receiver node as there you really don't reserve
> anything.
> 
> Hope this helps,
> 
> Cheers,
> Navin
> 
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of John
> Sparr
> Sent: Friday, August 04, 2000 9:30 AM
> To: [email-masked]

---

From: John Sparr <[email-masked]>
Date: Fri, 4 Aug 2000 12:22:02 -0700 (PDT)

Hi Folks,

Is that possible for the case below:

     A---B, A and B are LER

A set up one LSP and then sends another new Path
message, if the bandwidth requested is not available,
what happened? A PathErr should be returned to LER A,
but who returned, LER B?

Thanks
John

--- Navin <[email-masked]> wrote:
> Hi Folks,
> 
> >John ,
> >
> >The resv message doesn't contain session attribute
> object and hence you
> >don't know the setup and holding priorities of the
> LSP. These are available
> >in the path message and hence Call admission should
> be done during path
> >message.
> 
> In any case, Once your LSP is 'setuped', the setup
> priority doesn't have any
> meaning.
> And the only priority which will be used is the
> holding priority.
> 
> A quick question. If you are implementing RFC2212
> i.e GS, how would you
> accomodate
> R, if R > r. Considering that you would have already
> accepted the session
> while
> processing the Path message.
> 
> Anyway, Read RFC2209 and get the first hand info on
> RSVP message processing.
> 
> Have a nice weekend.
> 
> Over & out.
> 
> Navin
> 
> >
> >When there is not enough resources available to
> support the LSP, you can
> >find out how much is allocated to lower priority
> LSPs and based on that you
> >can generate the AdSepc. These lower priority must
> be preempted only when
> >you get the resv message.
> >
> >-sundara
> >
> >Sent: Friday, August 04, 2000 11:18 AM
> >To: Navin
> >Cc: [email-masked]
> >Hi Navin,
> >It should be that Resv message triggers this
> compare.
> >But why the draft says "When a path message is
> >considered for admission"?(section 4.8.3) It seems
> >when a node received a Path message it checks if
> the
> >bandwidth is avialable. I think the bandwidth
> request
> >should be in Resv message. is that right?
> >
> >
> >Regards,
> >John
> >
> >--- Navin <[email-masked]> wrote:
> >> Hi There,
> >>
> >> First of all, you carry out admission control
> check
> >> while
> >> EXCEPT the receiver node as there you really
> don't
> >> reserve
> >> anything.
> >>
> >> Hope this helps,
> >>
> >> Cheers,
> >> Navin
> >>
> >>
> >> From: [email-masked]
> [mailto:[email-masked]]On
> >> Behalf Of John
> >> Sparr

---

From: David Charlap <[email-masked]>
Date: Fri, 04 Aug 2000 18:58:31 -0400

Don Fedyk wrote:
> you reserve on the path message you lock in the bandwidth on the resv
> message. So I wouldn't preempt until the resv comes back (because the
> path message might have failed at subsequent hops). So in reality you
> do a check in both messages.

There is no requirement to reserve anything on the Path message,
although some implementations may find it convenient to do so.

-- David

---

From: David Charlap <[email-masked]>
Date: Fri, 04 Aug 2000 18:58:59 -0400

Navin wrote:
> 
> Secondly, admission control check will be done at all the nodes EXCEPT
> the receiver node as there you really don't reserve anything.

However, the inbound interface on the receiver node may police the
packet flow.

-- David

---

From: John Sparr <[email-masked]>
Date: Mon, 7 Aug 2000 06:22:52 -0700 (PDT)

Hi David,

Quick question on PathErr message return:

If we just have two RSVP nodes A and B. First A setup
a LSP A---B. And then A want another LSP, also it is
A---B. But there is no available bandwidth exist and
the second LSP can't preempt the first LSP. A PathErr
should be returned back. Since the egress node doesn't
do the compare work, who will do the compare work and
return the PathErr msg back?

Thanks a lot!

Regards
John

--- David Charlap <[email-masked]> wrote:
> John Sparr wrote:
> compare.  But why the
> > draft says "When a path message is considered for
> admission"? (section
> > 4.8.3) It seems when a node received a Path
> message it checks if the
> request should be in
> > Resv message. is that right?
> 
> The actual resources must be reserved and locked
> down while processing
> the Resv message.
> 
> Some hardware and/or software implementation may
> find it useful or
> necessary to reserve (or confirm the availability
> of) resources during
> Path processing.
> 
> It is also, however, reasonable for a switch to just
> record the contents
> of a Path message and do all admission control
> processing when the Resv
> message is processed.
> 
> -- David

---

From: "Sanford, Bill" <[email-masked]>
Date: Fri, 4 Aug 2000 10:41:06 -0400

Wouldn't it be the first node that didn't have the bandwidth, wherever it
was?

Bill
-----Original Message-----
From: John Sparr [mailto:[email-masked]]
Sent: Friday, August 04, 2000 10:30 AM
To: [email-masked]
Subject: resource preemption

Hi,

Thanks in advance
John

---

From: "Sanford, Bill" <[email-masked]>
Date: Fri, 4 Aug 2000 11:33:20 -0400

John, the setup priority is checked every hop.  Once a hop doesn't have the
bandwidth, the setup priority in the PATH message checks to see if an LSP
with a holding priority lower than itself can be bumped.  Two things can
happen, either the PATH message is refused and a PATH_ERR is sent back to
the Ingress or it bumps an LSP with a lower holding priority and moves
downstream.  The setup priority in the PATH message will most likely do this
multiple times downstream. 

Once the setup priority in the PATH message has successfully got to the
Egress the only priority left is the Holding priority in the LSP just
established. So as far as who will do the compare of the setup priority,
every downsteam node does except the receiver.

-----Original Message-----
From: John Sparr [mailto:[email-masked]]
Sent: Friday, August 04, 2000 10:58 AM
To: Sanford, Bill
Cc: [email-masked]
Subject: RE: resource preemption

Bill,

Thanks in advance
John

---

From: "Sanford, Bill" <[email-masked]>
Date: Fri, 4 Aug 2000 14:08:28 -0400

The setup priority and the holding priority are sent downstream in a PATH
message.

Let's say you try to setup yet another LSP with a higher priority then the
last example.  The PATH message will then again look and see if the
bandwidth is available downstream and if not, then look at the active LSPs
to see which one it could bump.  It uses the setup priority in the new PATH
message to compare to the holding priorities of the active LSP's PATH
messages to determine if it can bump an LSP or not.  The LSPs have both
priority fields, but the setup is used actively to determine preemption and
the holding is used passively used to compare if the setup can preempt it.

This comparison stops at the previous hop to the receiver.

-----Original Message-----
From: John Sparr [mailto:[email-masked]]
Sent: Friday, August 04, 2000 12:52 PM
To: Sanford, Bill
Cc: [email-masked]
Subject: RE: resource preemption

Bill,

Thanks
John

---

From: "Don Fedyk" <[email-masked]>
Date: Mon, 7 Aug 2000 10:48:07 -0400

David Charlap wrote:

> 
> It is also, however, reasonable for a switch to just record 
> the contents
> of a Path message and do all admission control processing 
> when the Resv
> message is processed.
> 
> -- David
> 

Reasonable ? What happens when you have to unwind the path 
because the Resv fails ?  Seems like a lot of work that 
could easily have been avoided.

It may be what the spec says, but it is not optimal.

Don

---

From: David Charlap <[email-masked]>
Date: Mon, 07 Aug 2000 11:01:43 -0400

Don Fedyk wrote:
> David Charlap wrote:
>>
>> It is also, however, reasonable for a switch to just record the
>> contents of a Path message and do all admission control processing
>> when the Resv message is processed.
> 

As opposed to reserving resources before you know whether the path
signalled will even reach its destination?

There are justifiable reasons for both models.  The decision of which
one to choose is as much religious as it is technical.

-- David