Re: PQC and QOSPF

Yao-Min Chen <ychen@fla.fujitsu.com> Fri, 24 July 1998 01:18 UTC

Delivery-Date: Thu, 23 Jul 1998 21:18:40 -0400
Return-Path: owner-qosr@ca.newbridge.com
Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09274 for <ietf-archive@ietf.org>; Thu, 23 Jul 1998 21:18:39 -0400 (EDT)
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id VAA09537; Thu, 23 Jul 1998 21:16:47 -0400 (EDT)
Received: from kanata-gw1.newbridge.com(192.75.23.72), claiming to be "kanata-gw1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa09492; Thu Jul 23 21:16:35 1998
Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 24 Jul 1998 01:16:33 UT
Received: from distmaster.newbridge.com (distmaster.ca.newbridge.com [138.120.118.27]) by ca.newbridge.com. (8.8.8/8.8.6) with SMTP id VAA07714; Thu, 23 Jul 1998 21:16:32 -0400 (EDT)
Received: by distmaster.newbridge.com (SMI-8.6/SMI-SVR4) id VAA23227; Thu, 23 Jul 1998 21:07:11 -0400
Message-ID: <35B7DBE8.5AB6@fla.fujitsu.com>
Date: Thu, 23 Jul 1998 17:57:12 -0700
From: Yao-Min Chen <ychen@fla.fujitsu.com>
Organization: Fujitsu Labs of America
X-Mailer: Mozilla 3.04 (X11; U; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
CC: Zhaohui Zhang <zzhang@argon.com>, ychen@cad.fla.fujitsu.com, qosr@newbridge.com
Subject: Re: PQC and QOSPF
References: <199807231825.DAA09823@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-qosr@ca.newbridge.com
Precedence: bulk
X-Info: [Un]Subscribe to qosr-request@newbridge.com

Ohta-san, 

I checked the PQC paper again and have a question 
about its use of RSVP Path messages.  The resource 
reservation info (equivalent of qospf RRAs) is 
piggybacked in the Path messages.  However, since 
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
and downstream routers see different network
status.  For example, if S-R1-R2-R3-D is the 
path taken by a flow, R1 tells R2  
resource reservation info on link (R1,R2), 
and R2 tells R3 the resource reservation 
info on links (R1,R2) and (R2,R3).
However, R2 and R3 do not communicate their
resource reservation info 
(on links (R2,R3) and (R3,D)) to R1.  

Using the terminilogy of the paper,
R1 can "correct" the "generic" link state
of link (R1,R2);  R2 can correct 
generic link states of (R1,R2) and 
(R2,R3); and R3 can correct 
the generic link states of (R1,R2), 
(R2,R3) and (R3,D).  So different
routers see inconsistent link states.  
(Let me know if I miss anything in this 
reasoning.) 

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?

Regards,
-- 
Yao-Min Chen, Fujitsu Labs of America, ychen@fla.fujitsu.com  
595 Lawrence Expressway, Sunnyvale, CA 94086-3922
Phone: +1 408 530-4513 Fax: +1 408 530-4515