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

From: Herve Chaplin <[email-masked]>
Date: Tue, 18 Nov 2003 17:41:28 +0800 (CST)

hi Lee,
 
I agree with Nary that more details are neccessary. See some comments in lines : 

Nary Tra wrote;

> draft-jeong-nsis-mobility-ntlp-01 :
> 
> In the section 4, I think more analysis are neccessary:
> At first, how can NTLP sent a MOBILE object to the 
> cross router (CRN), is it sent from the last NTLP node 
> to the previous (next) node or to the previous/next 
> mQoS_NSLP hop ?

[S-H] We assume that the MOBILITY object can be part of the NTLP information in mobile scenarios, so it can be sent to the CRN by a peer discovery message after handover. If the interactions with CARD & CT are considered, the MOBILITY object can also be transferred from an OAR to the CRN by the CT during handover. 
We also assume that a peer discovery message is sent between NTLP nodes after handover, and afterward the mQoS-NSLP state can be re-established fast through the CRN. 

[herve] Peer discovery is only be done between NTLP peer. In case CRN is not the next/previous NTLP node, peer discovery can not be used to detect CRN. 

> Secondly, how a node know if it is the appropriate 
> cross router ?  You wrote: " When a route change 
> caused by mobility occurs,the CRN can be recognized
> by comparing the existing session identifier with the 
> session identifier of the flow received from an incoming > interface. If the session identifier is still the same and 
> the flow identifier or interface number has been 
> changed, the current NSIS-aware node is recognized 
> as a CRN ". It seems nonsense because this node can 
> only know there is a routing change.

[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.

[herve] You defined NTLP states ? How does NTLP node identify its own state (NTLP state) ? 

> In the section 5, what is dead CRN ? ( CRN is broken 
> down, NTLP of CRN is broken down ? ) If you mean 
> peer detection (discovery), I think this is always be 
> supported for all signaling application.

[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 discovery
can be considered as an extension to the peer discovery.

[herve] Peer discovery is sent following the downstream toward NR (using flow routing). If a node on the data path dies, nothing can be done because the node sending PD request will never receive ACK, it fails to detect next peer. How can it find a new next peer ? In the upstream path, it is not the same. Your dead peer discovery looks like a keep-alive notification. Right ? More details, please.
 
Herve

 The New Yahoo! Search
- Join the Search Contest. Stand a chance to win prizes!