Subject: [NSIS] QoS NSLP updated

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 1 Mar 2006 21:01:43 +0200 (EET)

Dear all,

I have now updated the QoS NSLP draft. The changes are:

- Edits based on two sets of comments from Jerry and Roland, most changes
  are in 5.2.4 and 5.3.6.

- Re-named some of the references (I hated those loooooong ref names) ;)

- Re-arranged the references

- Removed the changelog

- Re-wrote a bit the IANA considerations section

I'm now running out of ideas of what to edit further. If I don't hear 
otherwise, I'm going to make a final sanity check during the weekend, and 
submit this version for consideration by the ADs and the IESG.

As usual, a diff is available here:

http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-09-10.html

Cheers,
Jukka

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

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 04 Mar 2006 00:59:46 +0100

Hi Jukka,

a few things are not quite clear to me:

Who is responsible to trigger the Refresh Messages? Is it the QNI or the Client 
Application connected to the QNI?

Who is allowed to tear down a session? Is it only the QNI or the QNR as well in 
both sender initiated and receiver initiated reservations?

On page 41 the field 'Class' is the 4-bit error class. Is this the same as the 
severity class in the sentence below the diagram ("The first four bits of the 
error code indicates the severity class.")? If yes, that would mean that the 4 
most significant bits of the error code represent the error class. But these are 
two independent objects. E.g. the bit representation for the error code 0x01 is: 
0000 0000 0001. The error class would be 0x00.

What is the reason to split up the objects in 4, 12 and 8 bits? This means we 
can have up to 16 error classes, 4096 error codes and 256 error subcodes. Do we 
need so many error codes? From programmer's view the 4-bit field is a possible 
source for bugs as you have to mask and shift bits.

On page 61, in the first paragraph about the QUERY messages with set R-bit, is 
it possible that QNI and QNR are mixed up? Compared to the figure on page 22, 
the QUERY message travels from QNR to QNI and the QNI would create a RESERVE 
message.

On page 63, IANA considerations the QoS NSLP Message Type is a 16 bit value. 
It's a 8 bit field on page 33. A bit further there are 7 objects listed (not 6).

Thanks,
Bernd

---

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 4 Mar 2006 15:49:54 +0200 (EET)

Hi,
Some answers below:

On Sat, 4 Mar 2006, Bernd Schloer wrote:

> Who is responsible to trigger the Refresh Messages? Is it the QNI or the
> Client Application connected to the QNI?

Page 4:
  "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205
   [RFC2205], and uses soft-state peer-to-peer refresh messages as the
   primary state management mechanism (i.e. state installation/refresh
   is performed between pairs of adjacent NSLP nodes, rather than in an
   end-to-end fashion along the complete signalling path)."

> 
> Who is allowed to tear down a session? Is it only the QNI or the QNR as well
> in both sender initiated and receiver initiated reservations?

An actual tearing RESERVE can only be sent towards the QNR. Any QNE can 
send a NOTIFY upstream, e.g., to indicate an error situation that should 
the same effect as a tear. A real tear can only be sent with a RESERVE.

> 
> On page 41 the field 'Class' is the 4-bit error class. Is this the same
> as the severity class in the sentence below the diagram ("The first four
> bits of the error code indicates the severity class.")? If yes, that
> would mean that the 4 most significant bits of the error code represent
> the error class. But these are two independent objects. E.g. the bit
> representation for the error code 0x01 is: 0000 0000 0001. The error
> class would be 0x00.

Yes, this should say "error class". There are six error classes, and 
within them 12-bits of error values, in each class.

> 
> What is the reason to split up the objects in 4, 12 and 8 bits? This
> means we can have up to 16 error classes, 4096 error codes and 256 error
> subcodes. Do we need so many error codes? From programmer's view the
> 4-bit field is a possible source for bugs as you have to mask and shift
> bits.

This has been deemed a usefull way to split 24 bits used for error 
reporting. Don't see a reason to change this.

> 
> On page 61, in the first paragraph about the QUERY messages with set
> R-bit, is it possible that QNI and QNR are mixed up? Compared to the
> figure on page 22, the QUERY message travels from QNR to QNI and the QNI
> would create a RESERVE message.

This should be the QNI.

> It's a 8 bit field on page 33. A bit further there are 7 objects listed (not

This was fixed in my current editor's version, and appears in the diff.

Thanks,
Jukka

---

From: Roland Bless <[email-masked]>
Date: Thu, 09 Mar 2006 11:10:03 +0100

Hi Jukka,

>    end-to-end fashion along the complete signalling path)."

The latter is, however, possible in case one uses a refreshing RESERVE
with an RII object included:
5.1.2.1.  RESERVE
   ...
   A refresh right along the path can be forced by requesting a RESPONSE
   from the far end (i.e. (i.e., by including an RII object in the RESERVE
   message).

I still don't know what it's good for...

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 9 Mar 2006 13:42:25 +0200 (EET)

Hi,

The "forced" refresh is useful to have, and makes it possible for any node 
to force a refresh operation to be carried. For example, a mobility anchor 
point may get to know that an MN has moved, and can force a refresh 
towards the MN. A similar indication and a subsequent refresh can happen 
with Mobile IP, when the HA, or CN receive a binding update, and know that 
the path near the MN has changed.

Regards,
Jukka

---

From: Roland Bless <[email-masked]>
Date: Thu, 09 Mar 2006 14:04:55 +0100

Hi Jukka,

> The "forced" refresh is useful to have, and makes it possible for any node 
                       ^^^^^^^^^
Yes, I'm interested in examples that show its usefulness (they should
possibly mentioned in the draft section 4).

> towards the MN. A similar indication and a subsequent refresh can happen

Hm, I don't quite get it. In case the MN has moved he also
changed his CoA and thus the MRI, and, in this case, the MAP will
usually send a new RESERVE with a different MRI.

> the path near the MN has changed.

I don't see why a forced refresh will help much in mobility scenarios.
Basically what you achieve with a forced refresh is that the state
along the whole path doesn't expire, but states will not expire
using the normal peer refreshes in case nothing else changed.
So in case the routing in the network didn't change, the refreshing
RESERVE will take exactly the same path as before. If the MN has changed
its CoA, you will usually end up sending a RESERVE with a different MRI
which then may traverse along a new path. Then states along the
unchanged path are refreshed anyway.
The only benefit would be IMHO to force a refresh before a handover
so that the time period for performing the handover is long enough
to keep the reservation while the QNI moves. But this could be achieved
by an ordinary refresh, too.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 10 Mar 2006 19:18:03 +0200 (EET)

Hi,

If you use a local mobility management scheme, controlled by a MAP, then
you don't need to change the IP address after each handover. Thus, a
refresh from the MAP towards the MN will look like an ordinary refresh,
and will not help in making reservations closer to the MN, say, at the
access router. If you can force a refresh, you can repair the reservation
faster.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Mon, 13 Mar 2006 14:27:50 +0100

Hi Jukka,

> you don't need to change the IP address after each handover. Thus, a

Maybe I don't understand that because the scenario is not quite clear
to me. Do you mean we use something like H-MIP? If yes, then we may
have a situation like this:

MN---AR1
        \
         R1---R2(MAP)--R3--R4--...--CN
        /
     AR2

I assumed that we consider a reservation from CN->MN and the
MN changes ARs. In this case the MN will get a new IP address
which is indeed hidden for the CN. However, I thought that
we have more or less two reservations, one from CN->MAP and
one from CN->MN. The latter will be updated in case the MN
registers its new address at the MAP. In this case the MAP will
use a new MRI towards the MN anyway, so it is not a "refresh"
because it will be forwarded along the whole path from the MAP
to the MN.

> access router. If you can force a refresh, you can repair the reservation

I apologize that I still don't understand. In case the MN's local
address doesn't change the refreshing RESERVE will also not take any
new path from MAP to CN?! Maybe you can explain it with help of the
above example.

Regards,
 Roland

-- 
Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
Institut für Telematik, Universität Karlsruhe (TH), Germany
Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
Tel.: +49 721 608-6413 Fax: +49 721 608-6789

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 19 Mar 2006 21:57:41 +0200 (EET)

Hi,

using your topology, we use an LMM scheme that does not change the IP 
address, say CIP or BCMP. We have a true e2e reservation. The MRI does not 
change after handover.

If we have the MAP at R3, it gets to know the MN moved, and sends a
RESERVE. R2 gets the RESERVE and thinks it is a simple refresh, since no
information is different. We could use an RII in the RESERVE, which forces
the refresh to go all the way, and the MAP gets back a RESPONSE. If we use
a forcing refresh, we get the refresh through all the way, and don't need
back a RESPONSE. 

I could live with both ways to get the refresh through.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Sun, 19 Mar 2006 23:08:40 +0100

Hi Jukka,

> address, say CIP or BCMP. We have a true e2e reservation. The MRI does not 

Ok, now it's getting clearer...

> a forcing refresh, we get the refresh through all the way, and don't need

Forcing refresh would mean a new flag?

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 20 Mar 2006 10:09:34 +0200 (EET)

Hi, sorry, got mixed up with what I would want to have, and what is there
actually. :) A "force refresh" flag isn't there, it is only in my LRSVP.  
The QoS NSLP can only force a refresh by include the RII, which gets back
a response.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Mon, 20 Mar 2006 16:46:13 +0100

Hi Jukka,

> The QoS NSLP can only force a refresh by include the RII, which gets back

Yep. So is it possibly of interest/advantage to have that flag,
i.e., RESERVE w/o RII, but with this new F flag?
I would also suggest to add a little rationale for both cases.

Regards,
 Roland