Subject: Re: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP

From: "Thanh Tra LUU" <[email-masked]>
Date: Tue, 18 Nov 2003 12:04:45 +0100

hi Lee,

[S-H] After a route change caused by mobility, an NSIS node can set up the NTLP state along the new path by peer discovery. That is, if an NSIS node has two different NTLP states with the same mQoS-NSLP and session identifier, it can be an appropriate CRN. Note that an NSIS-aware CRN should be a merging point of the old and new paths, which should have two different (old and new) NTLP states.

Why are there two NTLP states ?

[S-H] We mentioned that the CRN itself could be considered dead when it was temporarily or permanently disconnected from the network due to the failure of communication links (or processors), system rebooting, or node congestion. It is also possible that the NTLP of CRN does not work properly (in this case, the CRN can also be considered dead). Dead peer discoverycan be considered as an extension to the peer discovery.

Dead=interruption ? 

> for draft-lee-nsis-mobility-nslp-01 :
> 
> In the 5, local repair, i don't think CRN can be NI/NR (in the way you
> mean ). NI/NR is the signaling entities which initiate/terminate the
> signaling session. For me, NI/NR can only be endhost, edge router, proxy.

[S-H] Please refer to Section 5.2 in the NSIS signaling requirements draft 
        which addresses that the placement of NSIS Initiator, Forwarder, and 
        Responder anywhere in the network MUST be allowed. Please also 
        see Section 5.6.2 in the NSIS signaling requirements draft which 
        addresses flexibility in the placement of the NSIS Initiator/Responder. 

        If an MN is a sender, the CRN can send a Resv message (or an ACK
        message) in response to a Path message (or a RESERVE messge) from
        the MN to localize the re-establishment of mQoS-NSLP state. In this case 
        the CRN acts as an NR. If an MN is a receiver, the CRN can send a 
        Path messge (or a RESERVE message) toward the MN to fast re-establish 
        mQoS-NSLP state. In this case, the CRN acts as an NI.

I totally agree about the placement of NI,NR, NF in the requirement draft. However, if you mean CRN is a NI/NR, it mean that CRN initiate a new signaling application session and it can terminate this session. In case of handover, CRN just send the trigger message  which it has receiced before (with some modified parameters) to reestablish the session a new path. As a result, CRN is not the NI/NR.

> I dont understand the last paragraph in the section 5.

[S-H]  The last paragraph addresses the last-node-detection problem 
        which may occur in mobile scenarios. An NSIS node can periocally 
        send peer discovery messages to detect dead peer nodes. If the previous 
        node of the last node detects that the signaling message can not be 
        forwarded to the last node for some reason, the NSIS node may need to
        notify the sender of the signaling messge of unreachability state (of 
        signaling message) by initiating an error message indicating   
        'Can-Not-Be-Forwarded-to-the-Last-Node'. Therefore, the signaling session
        state will not be updated by signaling messages or will be removed.

       If an MN is the last node of the mQoS-NSLP session, the OAR may initiate 
       the error message indicating 'Can-Not-Be-Forwarded-to-the-Last-Node' 
       after handover. However, NEs along the old path should not remove the 
       mQoS-NSLP state before re-establishment of the mQoS-NSLP state 
       along new path. Please refer to Section 5 of draft-jeong-nsis-mobility-ntlp-01. 

ok. I agree.

Nary Tra
ENST, Paris