Subject: [NSIS] 5.5.7 requirement (Section 5.5.7)

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 15:12:58 +0100

Hi Marcus

Regarding requirement "Independence of reservation identifier" in Section 5.5.7

I do not know how to interpret this requirement.
What I mean is that in many cases the reservation has to depend on
the flow identifier, i.e., similar to RSVPv1.
However, I know that in Mobile IP this will cause severe problems
due to handoff situations where Care of Addresses are changing.

Therefore, I propose to emphasise that the reservation identifier 
SHOULD be independent, when Mobile IP scenarios are used.
However, for scenarios/applications that are not using Mobile IP,
the reservation identifier is defined as in RSVPv1.

Best Regards,
Georgios

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 15:42:07 +0100

Hello Georgios

I'm sticking with Markus' definition: A reservation ID must be independant. The reservation ID may carry the full flow information as part of it. The reseravtion ID may as well carry only part of the flow spec and it may further be service specific. I'd suggest to stay flexible here. 

Regards, Rüdiger

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 16:13:47 +0100

Hello Rüdiger

I think that we should be flexible only if it is required 
to be flexible. In the case of Mobile IP, it is required that the 
reservation ID must be independent, due to the Care of Addresses changes. 
Could you please give other examples where you will need to
have an independent reservation ID.

Please note that due to this independence of reservation ID, each router in a 
communication path must change its packet classification algorithm for 
each accepted flow. This will become to be a very complex procedure.

In Mobile IP this is much easier, since it can be predicted when 
the Care of Address changes.

best Regards,
Georgios

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: vrijdag 8 maart 2002 15:42
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7)

Hello Georgios

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Mar 2002 19:47:17 -0000

Georgios,

That's not how I read the requirement. The requirement is that it should be possible to refer to the reservation in a way which is independent of the flow classifier being used (e.g. for the reasons you mention to do with MIP, but we can't rule out other applications as well).

This is an entirely different question from what flow classifiers actually are allowed, which is what the routers care about. 

If the mapping between (fixed) reservation identifier and flow classifier changes, the router will have to be updated. But it would have to do this in any case. And in the meantime, the signalling is simplified.

If the mapping is fixed, no one is hurt by the fact that we had an identifier available in the QoS signals just in case. This requirement doesn't place any extra burden on the router so far as I can see.

We haven't got enough discussion of flow classifiers in the requirements draft. Martin Karsten raised a related issue with aggregation (for which I proposed some text), but a more general discussion is needed.

Robert H.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 08 March 2002 15:14
> To: 'Geib, Ruediger'
> Cc: [email-masked]
> I'm sticking with Markus' definition: A reservation ID must 
> be independant. The reservation ID may carry the full flow 
> information as part of it. The reseravtion ID may as well 
> carry only part of the flow spec and it may further be 
> service specific. I'd suggest to stay flexible here. 
> 
> Regards, Rüdiger
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 11 Mar 2002 09:33:54 +0100

Hi Georgios,

> have an independent reservation ID.

Yep. The scenario I'm talking about all the time is edge to edge aggregate reservation. In that case all I need is some unique ID, a destination address and a prefix. Instead of a destination address, we may even need a couple of addresses and more than one prefix. Then a  reference to e.g. a directory entry may even be more useful. 

Of course you could add source IP addresses, prefixes, ports and applications and wildcard all of it as it may be not required. What's the benefit of signaling useless information?

Regards, Rüdiger

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 11 Mar 2002 10:08:24 +0100

Hi Rüdiger

I think that you might be right,
but emphasising that the reservation ID is independent
of any information it will cause a
complex specification and implementation of the NSIS protocol.
In my opinion we should not say that the reservation ID is 
completely independent. I think that the reservation ID and its relation
to e.g., flow ID, DSCP, DCLASS, etc., should be specified. 
I agree with you that this specification will be difficult
but we will have to do it. 
We could probably say (in the requirement) that the specification of 
the reservation ID depends on the scenario used. During the 
specification of a scenario,
also the specification of the reservation ID
should be provided.

Best Regards,
Georgios

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: maandag 11 maart 2002 9:34
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7)

Hi Georgios,

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 11 Mar 2002 10:22:41 +0100

Hello Georgios

> specification of a scenario, also the specification of the 
> reservation ID should be provided.

Would be allright with me.

> Yep. The scenario I'm talking about all the time is edge to 
> edge aggregate reservation. In that case all I need is some 
> unique ID, a destination address and a prefix. Instead of a 
> destination address, we may even need a couple of addresses 
> and more than one prefix. Then a  reference to e.g. a 
> directory entry may even be more useful. 
> 
> Of course you could add source IP addresses, prefixes, ports 
> and applications and wildcard all of it as it may be not 
> required. What's the benefit of signaling useless information?
> 
> Regards, Rüdiger
>