Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier

From: Bob Braden <[email-masked]>
Date: Tue, 5 Nov 2002 19:48:30 GMT

*> From [email-masked]  Tue Nov  5 05:39:02 2002
  *> Date: Tue, 05 Nov 2002 14:38:16 +0100
  *> From: Marcus Brunner <[email-masked]>
  *> To: Bob Braden <[email-masked]>, [email-masked]
  *> Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation
  *>  identifier
  *> MIME-Version: 1.0
  *> Content-Transfer-Encoding: 7bit
  *> Content-Disposition: inline
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> Bob,
  *> 
  *> Just for clarification. Is the emphesis on the independence the problem? Or 
  *> is the reservation ID itself the problem?

Marcus,

The first, in general.

  *> 
  *> So reformulating the requirement into "An NSIS protocol MUST support a 
  *> reservation identifer" would solve the first one. 

OK, although I would say "MUST be able to support".

BTW, a reservation identifier is presumably a multi-hop thing, so in my
2-level model it is a creature of ULSP, i.e., it is carried in an
SAPU.  That's good, because non-QoS signaling applications probably
don't have any reservations to identify.

Ooops, your requirement only applies to QoS signaling.  Is that
appropriate?

  *> The reservation 
  *> identifier then can be the same as the flow id or can be something else.

I am not sure I understand this last sentence above.  I understand "flow id"
as we have been using it to mean the set of header fields that define
the flow.  If it is a microflow, this generally includes the source and
destination IP addresses and the source and destination ports, and perhaps
the IP protocol number.  A reservation identifier is presumably a single
number from some distinct number space; I am not sure what you mean
by "the same as".

Bob
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 06 Nov 2002 11:30:22 +0100

> Ooops, your requirement only applies to QoS signaling.  Is that

I would think all applications do have to identify a reservation (state), 
otherwise you do not need signaling at all. And I don't see why it should 
apply to QoS signaling. Do you see this in the req text?

> I am not sure I understand this last sentence above.  I understand "flow
> id" as we have been using it to mean the set of header fields that define
> number from some distinct number space; I am not sure what you mean by
> "the same as".
>
> Bob

And the number space for the reservation id could be 5-dimensionl 
containing src/dest addr, ports, and proto number, but it can also be 
derived from any other information or chosen randomly etc. I regard this 
then a protocol specification task to define what the reservation id is.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus