Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft

From: "Shivanajay Marwaha" <[email-masked]>
Date: Mon, 27 Feb 2006 18:09:26 +0800

Dear Seong-Ho,

Thanks for your reply. Regarding your question on CRN
operation/discovery failure, we are actually referring to the
mobility scenario when multiple interfaces are used for one session
(e.g. load balancing as indicated in section 5.2.5 of the mobility
applicability draft). Detailed description of the issue is as
following:

As described in Section 5.2.5, 2nd paragraph of the mobility draft,
the MN is using two paths for the same session (i.e. Path 1 and Path
2). In this case, as suggested by section 5.2.5 of the mobility
draft, same Session ID with different Flow IDs will be used for the
two paths. 

When one of these paths (Path 2) experiences a mobiity event, e.g.
one of the multiple interfaces of the MN handovers to another
network, a new path is resulted, i.e. Path 3. Yet, NSIS will use the
same Session ID with a new Flow ID for this path. Therefore, two
types of CRNs will now exist:- CRN for Path 1 and Path 3; and CRN for
Path 2 and Path 3. 

If the NSIS signaling over Path 3 triggers a CRN discovery, the CRN
discovery may lead to discovery of a QNE which is a CRN for path 1
and Path 3 only, instead of correctly identifying a QNE which is a
CRN for Path 2 and Path 3. This is because the current NSIS CRN
Discovery Procedure does not provide information about whether a CRN
is caused by the mobility event or multiple interfaces. 

The problem encountered in this case is that the discovered CRN would
have no information to decide its proper action (whether it is a
mobility event, or it's a multihoming case). There is a more thorough
analysis of this problem in section 4.1 of
draft-sanda-nsis-path-type-03
[http://tools.ietf.org/wg/nsis/draft-sanda-nsis-path-type-03.txt]

The above problem is an important issue to be considered in the
mobility draft as this scenario is very common and realistic. The
text sent earlier provides a brief  description of this problem. If
there is a need for further clarification on this problem, we can
provide more/amended text for that.

Best regards,
Shivanajay 
(On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong)

-----Original Message-----
From: Seong-Ho Jeong [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 1:35 PM
To: Shivanajay Marwaha; 'Sung-Hyuck Lee'; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section
5.2.5) ofMobility Draft

Hi Shivanajay,

Thanks for your comments.
Please see my comments inline.

Regards,
Seong-Ho

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of

>Shivanajay Marwaha
>Sent: Thursday, February 16, 2006 8:49 PM
>To: Seong-Ho Jeong; Sung-Hyuck Lee; [email-masked]; 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: [NSIS] Some More Suggestions on Multi-homing (section
>5.2.5) ofMobility Draft
>
>Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and 
>other NSIS WG members,
> 
>Some more comments on Multi-homing section in Mobility draft:-
> 
>--------------------------------------------------------------------
>Comment 1:- Section 5.2.5, Change title to "Host multihoming"
> 
>Discussion -
>We think that the above title would be more meaningful if it's changed 
>to Host Multihoming, since Issue discussed here applies to host 
>multihoming in general (where multiple connection between MN and CN are

>possible, either via different physical interfaces or a single 
>interface). So, the discussion in this section should not be limited to

>load balancing, which is just a use case of multihoming. In view of 
>this, the title "Host multihoming" would be more suitable.

This subsection is not the only one which discusses host multihoming.
Other subsections in Section 5.2 are also related to host multihoming. 

> 
>-------------------------------------------------------------------
> 
>Comment 2:- Section 5.2.5, reference to external drafts
> 
>Original Text - 
>   "There may be a situation where an MN may need to distribute its 
>traffic load to multiple paths via multiple interfaces.  In this case, 
>the MN can send multiple QUERY messages to multiple interfaces to 
>establish NSIS state on multiple paths."
> 
>Discussion -
>As load balancing represents only one of the many reasons for doing 
>multihoming, for better understanding, it is better to refer to the 
>draft "Goals and Benefits of Multihoming"
>(draft-ernst-generic-goals-and-benefits-02). So we suggest to replace 
>the above paragraph of section 5.2.5 with following text:-
>
>Suggested Text:-
>    "There may be a situation where an MN may need to distribute its 
>traffic load to multiple paths via multiple interfaces.  In this case, 
>the MN can send multiple QUERY messages to multiple interfaces to 
>establish NSIS state on multiple paths. There are many other scenarios 
>and applications in multi-homing as mentioned in [x] ".
>[x] Goals and Benefits of Multihoming
>draft-ernst-generic-goals-and-benefits-02

I also think that it would be good to mention the draft as a relevant
reference. We already have the reference in the References section
although the version needs to be changed.

> 
>--------------------------------------------------------------------
> 
>Comment 3:- Section 5.2.5, 2nd para: add description on mobility 
>problem with multihoming
> 
>Original Text - 
>   " Suppose that an MN wants to set up NSIS state on a path which is 
>able to support the specific bandwidth requirement for a certain 
>application in the multihomed environment.  It may not be possible to  
>find a feasible path for such a requirement.  In this case, multiple 
>paths can be used at the same time so that the bandwidth requirement 
>can be met.  Note that the flow identifier on each path may be 
>different although the session identifier is unchanged. "
> 
>Discussion -
>With the scenario described above, there would be a problem for NSIS 
>signalling when mobility happens. Please refer to draft  "Path type 
>support for NSIS signalling"
>(draft-sanda-nsis-path-type-03.txt) for details of the problem 
>analysis. So we suggest inserting the following paragraph after the 2nd

>paragraph of section 5.2.5:-
> 
>Suggested Text:-
>"When multiple paths are used for the same session, mobility support 
>may pose a problem for the NSIS signalling. For example, if Path-1 and 
>Path-2 are used for the same session, signalling for these two paths 
>would use different flow identifier, say FID-1 and FID-2, with the same

>session identifier, say SID. In the case a mobility event causes the
>Path-1 to be replaced by Path-3 for communication, signalling for the 
>Path-3 will be also using a different flow identifier, say FID-3, and 
>the same session identifier, SID. With this, current NSIS signalling 
>may fail, e.g. CRN discovery, and tearing of the old path. This is due 
>to the lack of information to differentiate Path-1 from Path-2. Detail 
>analysis of the problem can be find in draft [x] [x] "Path type support

>for NSIS signalling"
>(draft-sanda-nsis-path-type-03.txt)

Could you clarify further why the current CRN discovery may fail?

>
> 
>Regards,
>Shivanajay
>(On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong)
>
>_______________________________________________
>nsis mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/nsis
>
>

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