Re: PQC and QOSPF

[Yao-Min Chen <[e-mail]>]

--- Begin Message ---

Ohta san, 

Masataka Ohta wrote:
> 
> Yao-Min;
> 
> > these messages follow the direction of a flow,
> > only downstream routers receive resource reservation
> > info of upstream routers but not the other way
> > around.  The problem with this is that upstream
> 
> Yes, it makes the QOS routing a little more stable and is not a problem.

Could you elaborate on the stability part? 

As for "not a problem" part, 
I hope I understand the protocol correctly but it 
seems there could be a potential problem.  Consider 
the following example: a bandwidth of b1 is reserved
for a multicast flow on the path S--A--B--C--R1. 
For simplicity, assume all links on the path have 
the same available (residual) bandwidth b2 (<b1)
after committing b1 bandwidth to the flow.  This 
info is flooded to all routers using some form of 
extension to link state advertisements (LSAs).  
(In QOSPF, the extension is called RES-LSA while
 in PQC, QoSLSAP messages) 

Using PQC, router A considers link (B,C) 
has only available bandwidth b2.  On the 
other hand, router C can 
"correct" the link bandwidth to b1+b2 as far 
as computing the route for the flow is concerned. 
Now suppose a new receiver R2 would like to join 
the multicast tree and links (A,R2) and (C,R2)
both exist (see Figure below).

S--A--B--C--R1
    \   / 
     \ /
      R2

Since router A thinks the available bandwidth b2 
of (B,C) is insufficient (recall b2<b1), it 
adds branch (A,R2) for the new multicast tree 
but router C may compute (C,R2) to reach  
the new receiver.  So we have an inconsistent 
calculation of the new multicast tree. 

My main concern is that a very fundamental 
premise of link state routing algorithm is 
that all routers see the same network status
(link states); or one could say all routers
should have consistent link state databases.  
PQC, by only notifying downstream routers the 
reservation status of upstream routers, seems
to break this premise.   
  
> 
> > I guess a simple fix would be to also
> > piggyback resource reservation on the
> > RESV messages.  Or maybe it is not
> > necessary because receiving successful
> > RSVP Resv message by a router would
> > imply the resource reservation info
> > on downstream links?
> 
> Yes, as the QoS routing is hop-by-hop, which is necessary for multicast
> and RESV merge, a router do not have to know the result of
> previous routing. The router can not, in case of multicast and RESV merge.

Yes indeed. 

> 
> Note that, to assist dynamic rerouting, it reduces rerouting delay, if
> upstream, NOT DOWNSTREAM, link state of the current path is carried
> back in RESV, which is an extension to PQC I'm thinking about now.

Are you saying that instead of using the _next_ refresh PATH 
message to propagate the resource reservation info, we use 
_current_ RESV so that we can reduce information propagation
delay? 

> 
> Note also that, with QoS routing, PATH must follow the result of
> QoS routing, if any, of RESV, because only RESV has the QoS information
> which is necessary for QoS routing.
> 
>                                         Masataka Ohta

Thanks,
-- 
Yao-Min Chen, Fujitsu Labs of America, [e-mail]  
595 Lawrence Expressway, Sunnyvale, CA 94086-3922
Phone: [phone] Fax: [phone]

--- End Message ---