Subject: Re: [NSIS] QoS NSLP v. "13-pre1"

From: Roland Bless <[email-masked]>
Date: Mon, 08 Jan 2007 00:42:45 +0100

Hi Jukka and all,

Jukka MJ Manner wrote:
> I sent the following request for feedback two weeks ago. No comments have 
> been raised. I will wait until this Friday, then submit the draft.

Sorry for being so late...here some comments (including nits).

> 3.2.5.  Reduced Refreshes
> 
>    For scalability, the QoS NSLP supports an abbreviated form of refresh
>    RESERVE message. In this case, the refresh RESERVE references the
>    reservation using the RSN and the SESSION_ID, and does not include
>    the full reservation specification (including QSPEC). By default
>    state refresh should be performed with reduced refreshes in order to
>    save bytes on the wire. Stateless QNEs will require full refresh
                       ^^^^
because this is especially interesting for wireless users, I would
prefer something like: "save bytes during transmission."

>    since they do not store the whole reservation information.
> 
>    If the QNE does not support reduced refreshes, or there is a mismatch
>    between the local and received RNS, the QNE must reply with an
                                    ^^^ RSN
>    RESPONSE carrying an INFO_SPEC indicating the error.

and the QNE should stop sending reduced refreshes to this
peer if the error indicates lacking support for this feature.

> 3.2.6.  Summary Refreshes and Summary Tear
> 
>    For limiting the number of individual messages, the QoS NSLP supports
>    a summary refresh and summary tear messages. When sending a
>    refreshing RESERVE for a certain (primary) session, a QNE may include
>    a SESSION_ID_LIST object where the QNE indicates (secondary) sessions
>    that are also refreshed. An RSN_LIST object must also be added. The
>    SESSION IDs and RSNs are stacked in the objects such that the index
>    in both stacks refer to the same reservation state, i.e., the
>    SESSION_ID and RSN at index i in both objects refers to the same
>    session. If the receiving QNE noticies unknown SESSION IDs or a
                                   ^^^^^^^^ notices
>    mismatch with RSNs for a session, it will reply back to the upstream
>    QNE with an error.
> 
>    In order to tear down several sessions at once, a QNE may include a
>    SESSION_ID_LIST object in a tearing reserve. The downstream QNE must
>    then also tear the other sessions indicated. No RSN_LIST is sent. The
>    downstream QNE must silently ignore any unknown SESSION IDs.

[maybe a little more rationale why RSNs are useless for tearing
reserves: in case of mismatching RSNs a resynchronization of
reservation state prior to teardown is useless.]

>    GIST provides a SII_HANDLE for every downstream session. The
>    SII_HANDLE identifies a peer, and should be the same for all sessions
>    whose downstream peer is the same. The QoS NSLP uses this information
>    to decide when summary refresh messages can be sent, or when a
               ^^^^ better: if/whether                       ^^^^
               (in contrast to the point in time)
>    summary tear is possible.

> 5.1.1.  Common Header
> ...
>    Generic flags: 16 bits
> 
>       Generic flags have the same meaning for all message types. There
>       exists currently three generic flag, the (next hop) Scoping flag
        ^^^^^^exist                    ^^^^flags
>       (S), and the Proxy scope flag (P).

>    The ACK flag is usefull when a QNE wants to make sure the messages
                     ^^^^^^^ was already mentioned by Andrew
>    received by the downstream QNE are truly processed, even when GIST
>    continues to work. This is usefull for faster dead peer diagnostics
>    on the NSLP layer. Reliable transmission of messages between two QoS
>    NSLP peer should be handled by GIST, not the NSLP by itself.

[we must detail somewhere how a missing acknowledgment is detected,
esp. how to determine the timeout]
That means a missing acknowledgment is not used to trigger
retransmissions but to detect a dead peer.

>    or MAY use the Ack-flag to request confirmation from the downstream

This sounds like using ACKs for reliable transmission, and thus
contradicts the previous statement.
>    peer.  When the QNE sends out a tearing RESERVE, it MUST NOT send

> 5.1.3.6.  Information Object (INFO_SPEC) and Error Codes

>          *  0x04 - Congestion situation: Possible congestion situation
>                    ocurred on downstream path.
                     ^^^^^^^ occurred
>          *  0x06 - Mismatch in RSN in RSN LIST
Should be (?): Mismatching RSN in RSN List

>          *  0x01 - Reservation succesful
                                 ^^^^^^^^^successful
>          *  0x02 - Tear down succesful
                               ^^^^^^^^^successful

>          *  0x08 - Path truncated 
          *  0x08 - Path truncated - Next Peer Dead

> 5.2.4.  Retransmissions
> 
>    Retransmissions may happen end-to-end, e.g., between QNI and QNR
>    (using an RII object), or peer-to-peer, between two adjacent QNEs.
>    When a QNE transmits a RESERVE with an RII object set, it waits for a
>    RESPONSE from the responding QNE. QoS NSLP messages for which a
>    response is requested by including an RII object, but fail to elicit
>    a response are retransmitted. Similarly, a QNE may include the ACK-
>    flag to request confirmation of message reception from its immediate
>    peer.

>    The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait
>    period. Retransmissions MUST be made with exponentially increasing
>    wait intervals (doubling the wait each time). QoS NSLP messages
>    SHOULD be retransmitted until either a RESPONSE (which might be an
>    error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after
>    the initial transmission. In the latter case, a failure SHOULD be
>    indicated to the signaling application. The default values for the
>    above-mentioned timers are:
> 
>    QOSNSLP_REQUEST_RETRY: 2 seconds      Wait interval before initial
>                                          retransmit of the message
> 
>    QOSNSLP_RETRY_MAX:    30 seconds      Give up retrying to send the
>                                          message
> 
>    Retransmissions SHOULD be disabled for tear messages.

I'm not very lucky with this, esp. with respect to
interference of e2e retransmission and peer to peer
retransmission due to ACKs. I'm fine with the e2e RII
mechanism. However, the ACK mechanism for dead peer
detection will probably interfere with this.
I'll see the following points:
- if a msg with ACK flag set is sent, an acknowledgment
  (Success/0x03, usually without any QSPEC) is expected.
  A suitable timeout period must be determined.
- the acknowledgment may not arrive within the expected
  time, either due to:
  - loss of the original msg
  - loss of the acknowledgment msg
  - high delay due to processing overload at the peer
  the first two possibilities will not apply if
  reliable transport is required from GIST.
  So in this case QOSNSLP_REQUEST_RETRY/2 may be
  fine to indicate a problem. False alarms may still
  occur due to the last issue, however.
- In case of unreliable GIST transport, I'm not
  convinced that having another retransmission
  mechanism is the right thing...

So, it would probably be a good idea to add
an explicit liveliness test message (Hello) and either
drop the ACK mechanism and use the liveliness test
message instead, or, to keep the ACK mechanism and
use an explicit liveliness test message if the
acknowledgment didn't arrive within the expected
time frame. For instance, if the acknowledgment
did not arrive within 1s, the QNE will send a
Hello message that should be answered immediately
by the other peer. It may be retransmitted, too.

As we discussed at the last meeting (not in the official
WG meeting, but in the hallway) the original idea of the ACK
was to detect a situation when a QNE keeps sending refresh
messages but doesn't notice when the QoS NSLP at the next peer
crashed (maybe we should described this situation as rationale).
However, refreshes are not (usually) not sent end to
end. So if we restrict the ACK flag usage to refreshing RESERVEs
between peers only, we have no interference problem.

> 5.3.1.  Reservation Sequence Number (RSN)

>    the new reservation. If the RNS is greater than the current stored
                                 ^^^ RSN
>    value and the RESERVE was a reduced refresh, the QNE SHOULD send
>    upstream a error message "Full QSPEC required". 
                ^ transient.

Any suggestions?
 Roland

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 8 Jan 2007 10:45:01 +0200 (EET)

Hi Roland,
thank you for the input.

About the ack-functionality, I thought it was only meant between peers. If 
a peer receives a refresh with the ack-flag, it is a policy decision, 
whether it will also send its next own refresh with the ack-flag, thus, 
committing to checking the whole path is still intact.

Yet, we do have the RII-mechanism, where by introducing the RII, a QNE can 
request confirmation for its message. This could also be used to make a 
separate e2e refresh and confirm the state reservation is valid e2e.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Mon, 08 Jan 2007 11:42:13 +0100

Hi Jukka,

> committing to checking the whole path is still intact.

I'm not questioning this behavior. It is clear that the ACK mechanism is
only used between directly adjacent peers. What I'm asking is whether
the ACK mechanism is limited to refreshes only. Otherwise we run
into problems, e.g.: a non-refreshing RESERVE arrives with an RII
at a QNE and is now forwarded with an additionally set ACK flag.
Then the QNE must retransmit this message if it receives no
acknowledgment for the ACK from its peer. Simultaneously, there is
a retransmission mechanism at the QNI/QNE that will be triggered by the
missing e2e response requested by the RII. And I see problems
in this particular situation.

> separate e2e refresh and confirm the state reservation is valid e2e.

If we restrict the ACK flag use to refreshing RESERVEs, this would
be ok. Then we would IMHO have the following:
If a QNE decides to set an ACK flag for a refreshing RESERVE
(it need not be set for every refreshing message), it will
trigger the same retransmission algorithm described in sec. 5.2.4,
which is used by QNEs that set an RII. After QOSNSLP_RETRY_MAX
it will give up and send the Path truncated notification upstream.
The ACK flag must not be set for e2e refreshing RESERVEs that
include already an RII.

One further issue:
I would like to see a different name for the ACK flag. Actually, it is
an ACK _request_ flag since it asks the peer to send back an ACK.
If you think about TCPs definition and use of an ACK flag
people may get easily confused. So probably calling it ACR or AKR would
be clearer.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 8 Jan 2007 13:34:22 +0200 (EET)

Hi Roland,

thanks for clarifications and further suggestions. I agree with all of 
them.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 10 Jan 2007 11:36:57 +0200 (EET)

Hi Cheng,

After re-reading the QoS NSLP spec, I think the spec is quite accurate in 
how the NSLP supports mobility, and it seems to work properly. Tearing 
down the reservation on the old path from the cross-over QNE would be good 
to do, but not necessarily critical for the proper operation of the NSLP. 
Yet, the current QoS NSLP spec mentions the tear-down at the cross-over 
router.

Consider the following scenario:

[MN]   [QNE1] --- [QNE2] ---\
 |                           \
 |                           [QNE3] --- [QNE6] --- [QNE7] ---
 |                           /
 V                          /
[MN]   [QNE4] --- [QNE5]---/

The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR 
and receiver"

"MN as QNI and data sender": we could rely on just the soft-state to 
expire on the old path, and a new RESERVE on the new path, or use the 
following, based on the NSLP draft text.

- MN moves from peer QNE1 to QNE4
- GIST gets a hint that routing has changed, triggers the NSLP
- The NSLP then sends a new full RESERVE with a new RSN
- The RESERVE hits QNE4, which makes reservation
- Then the RESERVE is forwarded to QNE5, which also makes the reservation
- Finally, the RESERVE hits QNE3, which makes a reservation and forwards 
  the RESERVE to QNE6, and so on

The tear-down part:
- QNE3 also noticies that the SII-Handle has changed, and could basically 
  send a NOTIFY to QNE2 and through the QNI's old path saying "Route 
  Change" 0x02
- QNE2 will forward it to QNE1
- QNE1 would then at some point figure out QNI has disappeared, and will
  start removing the reservation using a tearing RESERVE
- The tearing RESERVE will eventually hit QNE3, which noticies that it has 
  an existing, and newer state (higher RSN), and will drop the tear

"MN as QNR and data receiver": we could rely on routing changes to 
eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will 
then send back a RESPONSE saying "full QSPEC required". A subsequent 
full RESERVE will then set up the reservation on the new path. Or, in 
order to make it faster, we could use the following:

- MN moves, gets a hint from GIST that routing has changed
- MN sends a NOTIFY towards QNI saying "Route Change" 0x02
- QNE4 will receive it, and forward it, same with QNE5
- The NOTIFY will hit QNE3, which notes that the message for a known 
  session comes from a new SII-Handle.
- QNE3 should then send a full RESERVE with a new RSN and an RII to 
  QNE5
- QNE4 will receive the RESERVE, make the reservation, and forward it to 
  the MN
- The MN gets the RESERVE and replies with a RESPONSE

The tear down:
- QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which 
  again sends ti QNE1

Jukka

On Thu, 14 Dec 2006, Hong Cheng wrote:

> Hi Jukka,
> 
> I would agree that the cross-over router should be left capable of tearing
> down the unneeded reservations. Please see some comments inline below:
> 
> cheers
> 
> Cheng Hong
> 
> 
> Jukka MJ Manner wrote:
> > Hi all,
> >
> > If you look at how the NSIS protocols work, there is no way a node can
> > make sure a tear-down was intiated by the QNI. A QNE receives a
> > teardown from its upstream peer, but it can't tell whether that peer
> > initiated the tear down in the first place, or the QNI.
> >
> > If I would do a "mobility enhanced QoS NSLP", I would tear down at the
> > cross-over router the unnecessary reservation. Of course the spec can say
> > "don't do it", but a QNE can not really confirm it isn't being done. And the
> > QNI or the QNR can't see that either.
> >
> > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to
> > initiate a tear down", and thus leave the option open for a QNE to also do
> > it.
> >   
> 
> [Cheng] Agree. This should be left open. And I think the quoted text in
> current QoS NSLP draft is reflecting this point.
> 
> > Or we could make a new INFO_SPEC code for "reservation not need" which is a
> > hint sent by the cross-over router to inform downstream QNEs on the old path
> > that the MN has moved away. It is then up to each QNE to decide whether to
> > remove the resources and state, or not.
> >
> >   
> 
> [Cheng] This option might lead to some problem though, since it could leave
> the QNEs on the path unsynchronized should they decide to do different things
> in response to the INFO_SPEC.
> 
> > Jukka
> >
> > On Wed, 13 Dec 2006, Takako Sanda wrote:
> >
> >   
> > > Hi Jukka and all,
> > >
> > > I would like to clarify about tearing down operation.
> > >
> > > In section 3.2.11 (Rerouting), 5th paragraph, it is said,
> > >    "After the reservation on the new path is set up, the branching node
> > >    may want to tear down the reservation on the old path (sooner than
> > >    would result from normal soft-state time-out)."
> > >
> > > This means that the CRN will initiate the TEAR on the old path.
> > >
> > > At Munich Interim, It was discussed that tearing down from intermediate
> > > node needs to be avoided because of session ownership issue. But I
> > > cannot find any conclusion of this discussion.
> > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html
> > >
> > > Do we have any decision for "tearing down from intermediate node"?
> > >
> > > cheers,
> > > Takako
> > >
> > >
> > >
> > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET)
> > > Jukka MJ Manner <[email-masked]> wrote:
> > >
> > >     
> > > > Dear all,
> > > >
> > > > I sent the following request for feedback two weeks ago. No comments
> > > > have been raised. I will wait until this Friday, then submit the draft.
> > > >
> > > > Jukka
> > > >
> > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote:
> > > >
> > > >       
> > > > > Hi all,
> > > > >
> > > > > I have done all the edits I had in my list to the QoS NSLP spec, the
> > > > > main points are in recent thread with Roland. From the url below you
> > > > > can find the current draft v. "13-pre1" and a diff to v. 12.
> > > > >
> > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/
> > > > >
> > > > > A direct link to the diff:
> > > > >
> > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html
> > > > >
> > > > >
> > > > > I would appreciate comments on the changes I did (what is wrong, what
> > > > > I missed, etc.).
> > > > >
> > > > >
> > > > > I still have one problem with the spec, namely the way the NSLP
> > > > > suggests to handle mobility and path changes. I think we need to
> > > > > review that statement, because it seems like a "hack" (playing with
> > > > > the RSN value), and not really useful. And the interactions with GIST
> > > > > look partly wrong. The folks working on the mobility draft (me
> > > > > included) could comment. The section I'm talking about is 3.2.10,
> > > > > especially 3.2.10.2, in the v.12 draft.
> > > > >
> > > > > BR,
> > > > > Jukka
> > > > >
> > > > >         
> 
> 
> 
>

---

From: Hong Cheng <[email-masked]>
Date: Wed, 10 Jan 2007 18:24:50 +0800

Hi Jukka,

The operation is well analyzed. The text should be incorporated into the 
Mobility Applicability draft. I think generally a tear-down could be 
initiated by any QNE (e.g. the CRN), as long as it is along the 
direction from QNI to QNR.

Please find a few more comments inline.

cheers

Cheng Hong

>   start removing the reservation using a tearing RESERVE

How the QNE1 figure out the QNI has disappeared might require some 
enhancement. Maybe the "Route Change" indication from QNE3 could further 
identify whether it is upstream route changed or downstream route 
changed. It might help the QNE1 reach the conclusion faster.

> - QNE4 will receive it, and forward it, same with QNE5

This is assuming the QNE4 has already been discovered. When the MN is 
QNR and data receiver, considering the discovery process, wouldn't 
sending a trigger to QNI directly result in a faster process?

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 10 Jan 2007 12:35:00 +0200 (EET)

Hi,

some answers below.

Jukka

On Wed, 10 Jan 2007, Hong Cheng wrote:

> initiated by any QNE (e.g. the CRN), as long as it is along the direction
> from QNI to QNR.
> 
> > how the NSLP supports mobility, and it seems to work properly. Tearing down
> > the reservation on the old path from the cross-over QNE would be good to
> > do, but not necessarily critical for the proper operation of the NSLP. Yet,
> > the current QoS NSLP spec mentions the tear-down at the cross-over router.
> > 
> > "MN as QNI and data sender": we could rely on just the soft-state to expire
> > on the old path, and a new RESERVE on the new path, or use the following,
> > based on the NSLP draft text.
> > 
> identify whether it is upstream route changed or downstream route changed. It
> might help the QNE1 reach the conclusion faster.

JM: I believe this falls a bit down the path of security. What can a QNE 
trust? I would rather let the QNE1 figure by itself that the QNI has 
disappeared. The message sent is only a hint that tells QNE1 to verify if 
QNI is still there. It would only take a few seconds, basically once the 
retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce 
that the QNI is gone.

> > then send back a RESPONSE saying "full QSPEC required". A subsequent full
> > RESERVE will then set up the reservation on the new path. Or, in order to
> > make it faster, we could use the following:
> > 
> This is assuming the QNE4 has already been discovered. When the MN is QNR and
> data receiver, considering the discovery process, wouldn't sending a trigger
> to QNI directly result in a faster process?

JM: Once GIST tells a routing change has happened, the NSLP will ask GIST 
to send the NOTIFY towards the QNI. For doing that, GIST must find the 
next peer QNE node, which is QNE4 in this case. Since the NSLP works 
hop-by-hop, you can't really send a message directly to the QNI, without 
going through all the intermediate nodes.

---

From: Takako Sanda <[email-masked]>
Date: Fri, 12 Jan 2007 20:03:33 +0900

Hi Jukka,

I still have a question for the operation below.

> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce 

How does QNE1 know the next peer was NI?
In order to know this, I guess, QNE1 needs to have received an explicit
notification from NI in advance.

cheers,
Takako

On Wed, 10 Jan 2007 12:35:00 +0200 (EET)

> > > > > > > > especially 3.2.10.2, in the v.12 draft.

----- 
Takako SANDA <[email-masked]>
Next-Generation Mobile Communications Development Center,
Matsushita Electric Industrial Co., Ltd. (Panasonic)
Phone: +81 46 840 5764  Fax: +81 46 840 5122

---

From: Takako Sanda <[email-masked]>
Date: Fri, 12 Jan 2007 20:49:54 +0900

Hi Jukka,

I have another concern about the operation for overlapping section, (i.e.
[QNE3] --- [QNE6] --- [QNE7] --- ).

If MN's CoA is changed after it's movement, MRI and packet classifier is
also changed. Therefore reservation for the overlapping section also
must be new.

In the "MN as QNI and data sender" scenario below, old reservation in the
overlapping section is not removed because QNE3 drops tearing RESERVE.
Therfore, some mechanisms may be necessary:-
 - QNE3 perform both RESERVE for new state and tear RESERVE for old
state when it receives RESERVE from QNE5.
Or,
 - QNE3 forwards tear RESERVE to QNE6 when it receives tear RESERVE from
QNE2. (Although it remains so called "double resource reservation issue"...)

In the "MN as QNR and data receiver" scenario below, new reservation for
overlapping is not performed.
Therfore, operation may need to be changed, such as:-
 - NOTIFY form MN goes to QNI (i.e. QNE3 does not stop it), and QNI
sends both RESERVE and tear RESERVE to MN and QNE1, respectively.
Or,
 - QNE3 performs localized RESERVE and tear RESERVE as shown below, but
NOTFY also goes to NI, and NI performs "scoping" RESERVE and tear
RESERVE.

cheers,
Takako

On Wed, 10 Jan 2007 11:36:57 +0200 (EET)

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 17 Jan 2007 18:06:05 +0200 (EET)

Hi,

QNE1 does not need to know that the next peer is the QNI. QNE1 just 
figures out that its next peer for the session is not there anymore, thus, 
the reservation can be torn down.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 17 Jan 2007 18:11:01 +0200 (EET)

Hi,

if the IP addresses change, then we have to make a full end-to-end refresh 
with a new MRI. Forcing an e2e refresh can be done by adding an RII into 
the refresh. Furthermore, if a refresh arriving at a QNE is a so-called 
full refresh, and the MRI is different, this is an indication to the QNE 
that the whole reservation must be refreshed end-to-end.

When sending the NOTIFY, it will include a new MRI. This can be used as an 
indication that the NOTIFY should be forwarded up to the QNI, which will 
then send back a full new refresh with a new MRI.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 17 Jan 2007 18:16:38 +0200 (EET)

Hi,

There is actually another problem with the RSN.

Consider the case "MN as QNR and data receiver"

When QNE3 gets the notify, it replies back with a RESERVE towards QNR 
which has "RSN=old-RSN +1". But all nodes from QNI up to QNE3 will still 
be sending refresh messages using the old RSN.

Thus, we need some further mechanism to inform the QNI that it should use 
a new RSN value in further refreshes, right? E.g. a NOTIFY towards the QNI 
that says "Path changed, new RSN" and include the new RSN? Sounds like a 
hack, any suggestions?

Jukka

---

From: Roland Bless <[email-masked]>
Date: Fri, 19 Jan 2007 15:15:47 +0100

Hi Jukka,

> a new RSN value in further refreshes, right? E.g. a NOTIFY towards the QNI 

No, not really. Maybe I'm completely off-track, but IIRC RSNs have only
local significance between directly adjacent QNEs. Thus there is simply
no need to notify other nodes upstream of a new RSN value.

> that says "Path changed, new RSN" and include the new RSN? Sounds like a 

Maybe I need to dig into a scenario down below before I understand
the problem, but the above suggestion doesn't make sense to me.

 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: Fri, 19 Jan 2007 17:03:50 +0200 (EET)

Right... True. Even though the RSN changes on some hops of the e2e 
path, this doesn't really need to be propagated anywhere.

The only case where we need to do e2e signaling is when the MRI changes, 
e.g., the CoA of the MN.

Jukka

---

From: Hong Cheng <[email-masked]>
Date: Mon, 22 Jan 2007 14:34:57 +0800

Hi Jukka,

The RSN is meant for adjacent QNEs only. It cannot be used for 
message/state management if the peer(/SII) is different. However, in 
mobility event handling, sometimes an e2e type of sequence number comes 
in handy, e.g. to detect the latest mobility event (as discussed in 
Mobility Applicability draft).

I guess some of the confusion came from the tricks introduced in QoS 
NSLP draft section 3.2.10.2. It works fine with that particular 
scenario, but does not solve general problems (of identifying message 
sequences from different peers).

Considering the scenario in your earlier mail (MN is sending and QNI 
case), the QNE3 has no way to tell if the message from QNE2 or QNE5 is 
newer, since the RSN doesn't apply here.

cheers

Cheng Hong

---

From: Takako Sanda <[email-masked]>
Date: Mon, 22 Jan 2007 18:04:54 +0900

Hi Jukka,

> that the whole reservation must be refreshed end-to-end.

Does this mean,
 - MRI in GIST is also updated for overlapping section?
 - or a new independent end-to-end GIST routing state and MA are
established with a new MRI/SID/NSLPID tuples?

In former case, I wonder if GIST allows to change MRI.

cheers,
Takako

On Wed, 17 Jan 2007 18:11:01 +0200 (EET)

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 22 Jan 2007 11:08:46 +0200 (EET)

MRI in GIST must be updated, of course. This is fine, as long as the SID 
remains. The state associated with the session is just updated.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 22 Jan 2007 11:35:35 +0200 (EET)

Hi,

AFAICT, QNE3 uses the same RSN for the next peer towards the MN, 
regardless of the actual next peer. If the peer changes, the RSN doesn't 
matter.

Now,

1. if MN is QNI, then after handover, the GIST SII-Handle will change, 
   which is an indication that the state has changed, and thus the RSN is 
   in a way re-set. The RSN is not meaningfull here.

2. If MN is QNR, after handover, the next peer changes, and QNE3 is in 
   charge of using the right RSN.

I don't see any problems here.

However... we may have potential problem in a certain case. Say, MN is 
QNI, and sends a full RESERVE, which arrives eventually at QNE3, the 
SII-Handle changes. QNE3 prepares to change the session state and send a 
tear down to the old SII-Handle. Now, at the same time, a refreshing 
(either partial or full) RESERVE comes from the old SII-Handle. What 
should QNE3 do now? It has received two RESERVEs from two different 
SII-Handles, which is the right one? Which should be torn down? (This is 
even more problematic, if the IP address of the MN changed, so we two 
different MRIs)

Do we need some clear indication of what is a refreshing RESERVE, and what 
is an full RESERVE sent in the initial phase, and after a routing change?

Jukka

On Mon, 22 Jan 2007, Hong Cheng wrote:

> Hi Jukka,
> 
> The RSN is meant for adjacent QNEs only. It cannot be used for message/state
> management if the peer(/SII) is different. However, in mobility event
> handling, sometimes an e2e type of sequence number comes in handy, e.g. to
> detect the latest mobility event (as discussed in Mobility Applicability
> draft).
> 
> I guess some of the confusion came from the tricks introduced in QoS NSLP
> draft section 3.2.10.2. It works fine with that particular scenario, but does
> not solve general problems (of identifying message sequences from different
> peers).
> 
> Considering the scenario in your earlier mail (MN is sending and QNI case),
> the QNE3 has no way to tell if the message from QNE2 or QNE5 is newer, since
> the RSN doesn't apply here.
> 
> cheers
> 
> Cheng Hong
> 
> 
> 
> 
> 
> 
> 
> Jukka MJ Manner wrote:
> > Right... True. Even though the RSN changes on some hops of the e2e path,
> > this doesn't really need to be propagated anywhere.
> > 
> > > > Thus, we need some further mechanism to inform the QNI that it should
> > > > use a new RSN value in further refreshes, right? E.g. a NOTIFY towards
> > > > the QNI 
> > > > > > > changed. It
> > > > > > JM: I believe this falls a bit down the path of security. What can a
> > > > > > QNE trust? I would rather let the QNE1 figure by itself that the QNI
> > > > > > has disappeared. The message sent is only a hint that tells QNE1 to
> > > > > > verify if QNI is still there. It would only take a few seconds,
> > > > > > basically once the retransmission procudure of either GIST or the
> > > > > > NSLP fails, QNE1 can deduce that the QNI is gone.
> > > > > > > changed. It
> > > > > > JM: I believe this falls a bit down the path of security. What can a
> > > > > > QNE trust? I would rather let the QNE1 figure by itself that the QNI
> > > > > > has disappeared. The message sent is only a hint that tells QNE1 to
> > > > > > verify if QNI is still there. It would only take a few seconds,
> > > > > > basically once the retransmission procudure of either GIST or the
> > > > > > NSLP fails, QNE1 can deduce that the QNI is gone.
> > > > > >
> > > > > > JM: Once GIST tells a routing change has happened, the NSLP will ask
> > > > > > GIST to send the NOTIFY towards the QNI. For doing that, GIST must
> > > > > > find the next peer QNE node, which is QNE4 in this case. Since the
> > > > > > NSLP works hop-by-hop, you can't really send a message directly to
> > > > > > the QNI, without going through all the intermediate nodes.
> > > > > >
> > > > > > > > > I would agree that the cross-over router should be left
> > > > > > > > > capable of
> > > > > > > > > tearing
> > > > > > > > > > cross-over router the unnecessary reservation. Of course the
> > > > > > > > > > spec can
> > > > > > > > > > say
> > > > > > > > > > "don't do it", but a QNE can not really confirm it isn't
> > > > > > > > > > being done.
> > > > > > > > > > And the
> > > > > > > > > > initiate a tear down", and thus leave the option open for a
> > > > > > > > > > QNE to also
> > > > > > > > > > do
> > > > > > > > > > it.
> > > > > > > > > >   
> > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not
> > > > > > > > > > need" which
> > > > > > > > > > is a
> > > > > > > > > > hint sent by the cross-over router to inform downstream QNEs
> > > > > > > > > > on the old
> > > > > > > > > > path
> > > > > > > > > > that the MN has moved away. It is then up to each QNE to
> > > > > > > > > > decide whether
> > > > > > > > > > to
> > > > > > > > > [Cheng] This option might lead to some problem though, since
> > > > > > > > > it could
> > > > > > > > > leave
> > > > > > > > > the QNEs on the path unsynchronized should they decide to do
> > > > > > > > > different
> > > > > > > > > things
> > > > > > > > > > >    "After the reservation on the new path is set up, the
> > > > > > > > > > >    branching
> > > > > > > > > > >    node
> > > > > > > > > > > > I sent the following request for feedback two weeks ago.
> > > > > > > > > > > > No
> > > > > > > > > > > > comments
> > > > > > > > > > > > have been raised. I will wait until this Friday, then
> > > > > > > > > > > > submit the
> > > > > > > > > > > > draft.
> > > > > > > > > > > >
> > > > > > > > > > > > Jukka
> > > > > > > > > > > >
> > > > > > > > > > > > > I have done all the edits I had in my list to the QoS
> > > > > > > > > > > > > NSLP spec,
> > > > > > > > > > > > > the
> > > > > > > > > > > > > main points are in recent thread with Roland. From the
> > > > > > > > > > > > > url below
> > > > > > > > > > > > > you
> > > > > > > > > > > > > I would appreciate comments on the changes I did (what
> > > > > > > > > > > > > is wrong,
> > > > > > > > > > > > > what
> > > > > > > > > > > > > I missed, etc.).
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > review that statement, because it seems like a "hack"
> > > > > > > > > > > > > (playing
> > > > > > > > > > > > > with
> > > > > > > > > > > > > the RSN value), and not really useful. And the
> > > > > > > > > > > > > interactions with
> > > > > > > > > > > > > GIST
> > > > > ----- Takako SANDA <[email-masked]>