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
- Re: PQC and QOSPF Yao-Min Chen
- PQC in draft-ietf-qosr-framework-06.txt FUJIKAWA Kenji
- Re: PQC in draft-ietf-qosr-framework-06.txt Masataka Ohta
- PQC and QOSPF Yao-Min Chen
- Re: PQC and QOSPF Zhaohui Zhang
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Yao-Min Chen
- Re: PQC and QOSPF Yao-Min Chen
- Re: PQC and QOSPF FUJIKAWA Kenji
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Zhaohui Zhang
- Re: PQC and QOSPF Jon Crowcroft
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Kenneth CARLBERG
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Kenneth CARLBERG
- Re: PQC and QOSPF Yao-Min CHEN