Subject: [NSIS] NSIS mobility issues

From: Sung-Hyuck Lee <[email-masked]>
Date: Mon, 10 Oct 2005 22:59:48 +0900

Hi all,

As you know,  NSIS mobility authors have established the NSIS mobility 
issue tracker': http://www.tschofenig.com:8080/nsismob/. Also, the authors 
would like to address the following issues to further discuss those issues 
on the mailing list. It would be very much appreciated if NSIS folks give some 
guides and comments on the following issues addressed in 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-02.txt. 
The more detailed issues can be found in NSIS mobility issue tracker.

* Closed
   - #4: Authorization-related issues with teardown 
          solved by disabling of "reverse removal" 

   - #7: Priority of signaling messages 
          It is difficult for the signaling priority to be used due to security issues 

* Remaining issues to be resolved: 

   - #1: CRN discovery 
       the pros and cons of two discovery mechanisms on CRN was 
       described in more details: either at NTLP  layer or NSLP layer. 

   - #2: Mobile IP specific API 
       This issue is a little implementation-specific, but the usage of 
        an API needs to be described. 

   -#3: Invalid NSIS Responder problem 
        Some possible proposals to solve the 'invalid NR' problem in 
        mobility scenarios was described (e.g., hint information: 
        handover_init (HI)). This issue is pertinent to #11. 

   - #5: Optimal refresh timer value for mobile environment 
         It is difficult to provide generic mechanism, but provide specific values 
        (for specific scenarios) if possible. 

   - #6: CRN discovery and Path Update on the IP-tunneling path 
         possible issues in NSIS-mobility draft (-02) were described. 
         Suggest solutions in separate drafts. 
 
   - #8: Localized Path Update 
        Identify the difference b/w the localized mobility and micro mobility 
        management protocols in case of interaction with NSIS protocols. 
        Consider signaling optimization in the vertical handover scenarios. 

   - #9: Dead Peer Discovery
            Dead peers (e.g., AR (or FA), CRN, HA or MN ) can occur either 
        because a link or a network node failed, or MN moved away 
        without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP). 
        GIMPS discovery will detect the problem after some time: it says 
        that GIMPS discovery might be too slow. 

      - Questions for #9: 
            How can dead peers be detected in a fast and efficient manner in 
         mobility scenarios? Do some "dead peer" cases need to be 
         identified? (e.g., MN’ moving-away, CRN failure, CARs’ failure, 
         FA/HA’s failure, and so on)  

  - #10:  Multihoming issues
             An NSIS-aware node (e.g., MN, HA, CN, etc.) may be multihomed. 
         NSIS signaling can be used in such multihomed environments. 
         In this case, which NxLP functionality is needed in various 
         multihoming scenarios (e.g., bandwidth increase, load balancing, 
         bi-casting, resilience, etc.) is an open question. An overall 
         coordination for interworking between the NSIS protocol 
         suite and multihoming capability needs to be discussed further. 

      - Questions for #10: 
           How should multiple CRNs differentiate the Path Update for 
        multihoming from the generic Path Update? How do CRNs authorize 
        multiple flows with different flow identifiers for the same session? 
 
  - #11 Mobility Object
          The Mobility objects such as 'Mobility_Event_Counter (MEC)' and 
       'Handover_Init (HI)' can be used to solve the ping-pong type 
       handover and the Invalid NR problem, respectively. The MEC field can 
       inform the CRN of which incoming message is the latest. The HI field 
       can explicitly inform AR (or CRN) that a handover is now initiated. 

     - Question for #11: 
        Do those mobility objects need to be included in NxLP messages?
 
  - #12 Terminology: Path Update
        The term, "Path Update" has been chosen with the initial mobility
        manyfolks-draft. Some folks think that the term does not 
        appropriately represent the meaning of NSIS state recovery. 
        Currently, the candidates for substitution of the term are 

         i) "State Recovery" and ii) "State Update". Any suggestion? 

 * Some overlapped issues between QoS-NSLP and NSIS-mobility drafts 

   - QoS-NSLP #29: Make-before-break handovers (including 
      Seamoby-related issues) were addressed at the initial NSIS-mobility 
      draft. Was this issue closed? 
  
   - QoS-NSLP #32: Last node problem is similar to the "Invalid NR 
      problem (#3)" 
 
   - QoS-NSLP #33: Priority of signaling messages to GIMPS-NSLP API 
        & #39 Explicit indication of refresh are related to the "priority of 
        signaling messages (#7)" 
  
   - QoS-NSLP #17: Node failure and restart handling 
        "Dead peer discovery (#9)" 

   - Questions: How should we resolve the conflict? Also, who 
      describes what? 

  Thanks,

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 12 Oct 2005 11:45:28 +0200

Hi,

Find my comments inline.

--On Montag, 10. Oktober 2005 22:59 Uhr +0900 Sung-Hyuck Lee 
<[email-masked]> wrote:

| Hi all,
|
| As you know,  NSIS mobility authors have established the NSIS mobility
| issue tracker': http://www.tschofenig.priv.at:8080/nsismob/. Also, the
| authors  would like to address the following issues to further discuss
| those issues  on the mailing list. It would be very much appreciated if
| NSIS folks give some  guides and comments on the following issues
| addressed in
| http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobilit
| y-signaling-02.txt.  The more detailed issues can be found in NSIS
| mobility issue tracker.
|
| * Closed
|    - #4: Authorization-related issues with teardown
|           solved by disabling of "reverse removal"
|
|    - #7: Priority of signaling messages
|           It is difficult for the signaling priority to be used due to
| security issues
|
| * Remaining issues to be resolved:
|
|    - #1: CRN discovery
|        the pros and cons of two discovery mechanisms on CRN was
|        described in more details: either at NTLP  layer or NSLP layer.

I thought to remember that this issue has been solved at the last meeting.
The NTLP will discover the CRN "automatically": Only a NTLP being
already involved in the signaling session (i.e., having stored state for
that session) will discover the cross-over. This NTLP, by definition, will
have the right NSLP installed locally. This result of "only NTLP nodes with
the corresponding NSLP will intercept and process messages".

  Martin

|
|    - #2: Mobile IP specific API
|        This issue is a little implementation-specific, but the usage of
|         an API needs to be described.
|
|    -#3: Invalid NSIS Responder problem
|         Some possible proposals to solve the 'invalid NR' problem in
|         mobility scenarios was described (e.g., hint information:
|         handover_init (HI)). This issue is pertinent to #11.
|
|    - #5: Optimal refresh timer value for mobile environment
|          It is difficult to provide generic mechanism, but provide
| specific values          (for specific scenarios) if possible.
|
|    - #6: CRN discovery and Path Update on the IP-tunneling path
|          possible issues in NSIS-mobility draft (-02) were described.
|          Suggest solutions in separate drafts.
|
|    - #8: Localized Path Update
|         Identify the difference b/w the localized mobility and micro
| mobility          management protocols in case of interaction with NSIS
| protocols.          Consider signaling optimization in the vertical
| handover scenarios.
|
|    - #9: Dead Peer Discovery
|             Dead peers (e.g., AR (or FA), CRN, HA or MN ) can occur
| either          because a link or a network node failed, or MN moved away
|         without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP).
| GIMPS discovery will detect the problem after some time: it says
| that GIMPS discovery might be too slow.
|
|       - Questions for #9:
|             How can dead peers be detected in a fast and efficient manner
| in           mobility scenarios? Do some "dead peer" cases need to be
| identified? (e.g., MN¡¯ moving-away, CRN failure, CARs¡¯ failure,
| FA/HA¡¯s failure, and so on)
|
|   - #10:  Multihoming issues
|              An NSIS-aware node (e.g., MN, HA, CN, etc.) may be
| multihomed.           NSIS signaling can be used in such multihomed
| environments.           In this case, which NxLP functionality is needed
| in various           multihoming scenarios (e.g., bandwidth increase,
| load balancing,           bi-casting, resilience, etc.) is an open
| question. An overall           coordination for interworking between the
| NSIS protocol           suite and multihoming capability needs to be
| discussed further.
|
|       - Questions for #10:
|            How should multiple CRNs differentiate the Path Update for
|         multihoming from the generic Path Update? How do CRNs authorize
|         multiple flows with different flow identifiers for the same
| session?
|   - #11 Mobility Object
|           The Mobility objects such as 'Mobility_Event_Counter (MEC)' and
|        'Handover_Init (HI)' can be used to solve the ping-pong type
|        handover and the Invalid NR problem, respectively. The MEC field
| can         inform the CRN of which incoming message is the latest. The
| HI field         can explicitly inform AR (or CRN) that a handover is now
| initiated.
|
|      - Question for #11:
|         Do those mobility objects need to be included in NxLP messages?
|
|   - #12 Terminology: Path Update
|         The term, "Path Update" has been chosen with the initial mobility
|         manyfolks-draft. Some folks think that the term does not
|         appropriately represent the meaning of NSIS state recovery.
|         Currently, the candidates for substitution of the term are
|
|          i) "State Recovery" and ii) "State Update". Any suggestion?
|
|
|  * Some overlapped issues between QoS-NSLP and NSIS-mobility drafts
|
|    - QoS-NSLP #29: Make-before-break handovers (including
|       Seamoby-related issues) were addressed at the initial NSIS-mobility
|       draft. Was this issue closed?
|
|    - QoS-NSLP #32: Last node problem is similar to the "Invalid NR
|       problem (#3)"
|
|    - QoS-NSLP #33: Priority of signaling messages to GIMPS-NSLP API
|         & #39 Explicit indication of refresh are related to the "priority
| of          signaling messages (#7)"
|
|    - QoS-NSLP #17: Node failure and restart handling
|         "Dead peer discovery (#9)"
|
|    - Questions: How should we resolve the conflict? Also, who
|       describes what?
|
|
|   Thanks,
|
|  Sung-Hyuck Lee

---

From: Sung-Hyuck Lee <[email-masked]>
Date: Tue, 18 Oct 2005 11:04:10 +0900

Hi all,

The authors of NSIS mobility draft would like to address the following 
terminology issue on the NSIS mobility issue tracker: http://www.tschofenig.priv.at:8080/nsismob/. 

- Issue #12: Terminology, "Path Update"

   The term, "Path Update" has been chosen with the initial mobility
   manyfolks-draft. However, some folks think that the term does not 
   appropriately represent the meaning of NSIS state recovery. 

      i) "State Recovery" 
      ii) "State Update" 

It would be helpful for progress of NSIS mobility draft if you could give 
any suggestion and comment. 

Thanks & Regards,
(Kam-Sa-Hap-Ni-da)

NSIS-Mobility authors