Subject: [NSIS] NSIS-mobility Issue #11: Mobility Object

From: "Sung-Hyuck Lee" <[email-masked]>
Date: Wed, 3 Aug 2005 22:40:21 +0900

Hi all,

NSIS-mobility draft authors have newly identified the following issues 
which need to be addressed.

1. Ping-pong type handover-related issues.

  1.1 NO_REPLACE flag and related-hint information

- Description: An NE (e.g., QNE) can determine if it is a merging point 
   (i.e. an NSLP CRN) of the old and new paths, and then it can 
   perform an involved state setup on the new path and state teardown 
   on the old path. However, if the QNE receives an NSIS message 
   (e.g., RESERVE) with a special flag (e.g., NO_REPLACE flag) set but 
   with the different SII, state teardown on the old path should not 
   happen. This may apply to a ping-pong type handover where the MN 
   wishes to keep state to its old attachment point in case it moves 
   back there. For interaction with the ping-pong type handover, 
   QoS-NSLP should determine when to set the NO_REPLACE flag 
   depending on when and where the MN handovers.  It may require 
   NTLP to monitor or react on the mobility events over possible APIs 
   and to notify QoS-NSLP of the mobility events with "primitives". It is 
   still an open issue and needs to be discussed further.
  
-  Question 1: is this an implementation-specific issue?
 
1.2 RSN-related issues

- In section 5.4, the usage of RSN was described to cope with a 
  ping-pong type handover. However, it does not seems to be 
  appropriate to use RSN for the ping-pong type handover because the 
  RSN MUST be incremented for each new RESERVE message where 
  the reservation for the session changes. Therefore, the RSN-related 
  texts need to be removed. What do you think?

 2. Mobility object format

2.1 Mobility_Event_Counter (MEC) 

  A certain object needs to be considered in order for some nodes 
  (e.g., CRN) on the session path to determine which RESERVE message 
  is latest in the ping-pong type handover scenarios. The Mobility object 
  described in Section 4.2.2 can be some possible solution. The Mobility 
  object may be defined in the NTLP (e.g., in GIMPS payload) or NSLP 
  messages to notify of any mobility event explicitly, and it may contain 
  various mobility-related fields, e.g., mobility_event_counter (MEC). The 
  MEC field can inform the CRN of which incoming massage is the latest 
  and so it is useful to detect the latest handover event for avoiding any
   confusion about where to send a confirmation message and to handle
   the ping-pong type of movement.
 
2.2 Handover_Init (HI)

  -  Mobility object is also used to cope with the "Invalid NR problem (the last 
     node detection problem)" as follows.
 
      If the MN moves, care should be taken to prevent the teardown of NSIS
      state on the old path before the NSIS state is re-established on
      the new path.  In this case, an error message (or refresh
      timeout) should not be generated (or happen) to avoid any teardown
      on the old path and common path.  The problem can be solved by
      using handover_init (HI) field of the Mobility object described in
      Section 5.4.  The HI field can explicitly inform AR (or CRN) that
      a handover is now initiated, and thus the AR does not initiate any
      error messages (or refresh timeout) when it does not receive
      responses to refresh messages from the MN.  In this case, there are
      two approaches which AR can make. One of the possible approaches 
      may be a proxy for the MN (the last node) and it may be able to send 
      RESPONSE messages in response to REFRESH (or RESERVE) 
      messages from a upstream node.  AR may also forward the
      error message including the HI field toward CN to prevent the NI
      from removing the NSIS state.  However, it is sill an open issue
      whether the hint information such as the HI field through NSIS
      signaling messages needs to be forwarded.
 
      Q.3 Those issues are related to the usage-related issue of 
      Mobility object. Does the mobility object need to be included in NxLP 
      messages?.

 Thanks,

Sung-Hyuck

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

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 4 Aug 2005 14:14:10 +0800

Hi Sung-Hyuck,

Regarding the point 1.1, I think from standards point of view, the API
details should be left to implementation. But, the "primitives" and the
functional requirements on the interaction between NTLP, QoS-NSLP should
be defined clearly. (assuming you are referring to the API part of the
text ?:)

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sung-Hyuck Lee
> Sent: Wednesday, August 03, 2005 9:40 PM
> To: [email-masked]
> Subject: [NSIS] NSIS-mobility Issue #11: Mobility Object 
> 
> Hi all,
> 
> NSIS-mobility draft authors have newly identified the 
> following issues which need to be addressed.
>