Subject: [PCN] multi flows in rsvp

From: [email-masked] (Scott O. Bradner)
Date: Fri, 26 Mar 2010 18:29:27 -0400 (EDT)

this came up at the pcn meeting today - I asked Fred and he pointed
to draft-polk-tsvwg-intserv-multiple-tspec

Scott

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 29 Mar 2010 14:52:46 -0500

>to draft-polk-tsvwg-intserv-multiple-tspec

I'm not sure the context of this topic, as I wasn't in the pcn 
meeting -- but the "subject" line above indicates there might be a 
disconnect between what pcn might be talking about and the ID Scott mentions.

draft-polk-tsvwg-intserv-multiple-tspec is an Integrated Services 
extension to allow multiple TSPECs and FLOWSPECs in PATH and RESV 
messages to have these messages include more than one set of BW 
parameters within a single message.

This is an optimization of having many round trips to effectively 
guess which BW a network and/or a called node can handle. Coupled 
with an ADSPEC [RFC2205] in PATH messages and RSVP's existing ability 
to have to have traversed routers grant or reject BW parameters 
within a RESV message, having more than one TSPEC/FLOWSPEC to choose 
from increases the chances of a single message having a choice that's 
acceptable.

Where this "disconnect" is between the what the ID specifies and the 
subject line of this message is there is never more than one flow 
created by this ID.  Perhaps that was a slip of Scott's fingers or an 
attempt to make this topic a bit too short.

James

>Scott
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

---

From: Tom Taylor <[email-masked]>
Date: Mon, 29 Mar 2010 16:55:56 -0400

This topic came up because we need a way to signal that flow termination is 
needed on some ingress-egress aggregate. RSVP messages such as NOTIFY apply to 
individual flows in the first instance. I believe that we can use RFC 3175 as a 
means to make a NOTIFY refer to an aggregate.

The other part of the problem of signalling flow termination is, in certain 
deployments, the need to signal a list of flows that are candidates for 
termination. This is perhaps where something like RFC 4860 or your draft might 
come in.

James M. Polk wrote:
> I'm not sure the context of this topic, as I wasn't in the pcn meeting 
> -- but the "subject" line above indicates there might be a disconnect 
> between what pcn might be talking about and the ID Scott mentions.
> 
> This is an optimization of having many round trips to effectively guess 
> which BW a network and/or a called node can handle. Coupled with an 
> ADSPEC [RFC2205] in PATH messages and RSVP's existing ability to have to 
> have traversed routers grant or reject BW parameters within a RESV 
> message, having more than one TSPEC/FLOWSPEC to choose from increases 
> the chances of a single message having a choice that's acceptable.
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 30 Mar 2010 09:46:55 +0200

Hi Tom,

On 29 Mar 2010, at 22:55, Tom Taylor wrote:

> This topic came up because we need a way to signal that flow termination is needed on some ingress-egress aggregate. RSVP messages such as NOTIFY apply to individual flows in the first instance. I believe that we can use RFC 3175 as a means to make a NOTIFY refer to an aggregate.
> 
> The other part of the problem of signalling flow termination is, in certain deployments, the need to signal a list of flows that are candidates for termination. This is perhaps where something like RFC 4860 or your draft might come in.

James' multi-Tspec I-D is about signaling multiple "bandwidth" for a given flow. I don't think it can help you signal multiple "flows".

Cheers

Francois

>> I'm not sure the context of this topic, as I wasn't in the pcn meeting -- but the "subject" line above indicates there might be a disconnect between what pcn might be talking about and the ID Scott mentions.
>> draft-polk-tsvwg-intserv-multiple-tspec is an Integrated Services extension to allow multiple TSPECs and FLOWSPECs in PATH and RESV messages to have these messages include more than one set of BW parameters within a single message.
>> This is an optimization of having many round trips to effectively guess which BW a network and/or a called node can handle. Coupled with an ADSPEC [RFC2205] in PATH messages and RSVP's existing ability to have to have traversed routers grant or reject BW parameters within a RESV message, having more than one TSPEC/FLOWSPEC to choose from increases the chances of a single message having a choice that's acceptable.
>> Where this "disconnect" is between the what the ID specifies and the subject line of this message is there is never more than one flow created by this ID.  Perhaps that was a slip of Scott's fingers or an attempt to make this topic a bit too short.
>> James
>>> Scott

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html