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

From: Sung-Hyuck Lee <[email-masked]>
Date: Thu, 02 Mar 2006 00:04:37 +0900

Hello Shivanajay,
 
----- Original Message ----- 
From: "Shivanajay Marwaha" <[email-masked]>

>> > 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.
>> 
>> [SHL] "CD (CRN_Discovery) flag" described in Section 5.1.4.1 
>> can solve this issue because the CD flag can prevent NEs to 
>> incorrectly perform the process of CRN discovery. For 
>> example, once CRN between Path 2 and Path 3 is discovered, 
>> the CD flag is set and thus downstream NEs don't perform the 
>> process of CRN discovery. Therefore, the CRN discovery 
>> between Path 1 and Path 3 doesn't occur.
>>  
>> After handover, if a merging point between Path 1 and Path 3 
>> exists before the CRN between Path 2 and Path 3, the merging 
>> point between Path 1 and Path 3 becomes CRN and thus 'CD 
>> flag' is set. The existing CRN (as downstream NE of the CRN 
>> btw Path 1 and Path 3) between Path 1 and Path 2 can remove 
>> the old state on the Path 2 when it checks the CD flag 
>> included in NSIS signaling message from upstream NEs. In this 
>> case, the existing CRN needs to remove the old state through 
>> checking the CD flag.
>
> [SHIV] As mentioned above, for the CRN (between Path 1 and Path 2) to
>remove/update the old state, it needs to know which path is the old
> state (e.g.
> whether it is Path 1 or Path 2). However, the CD Flag does not contain
> this
> information. Therefore, the CRN (between Path 1 and Path 2) would not be
> able
> to identify the correct path state to remove using the CD Flag alone.

[SHL] NSLP_Br_ID (described in Section 4.2.2) enables CRN to identify 
which branch is old and new. The counter of NSLP_Br_ID is updated when 
a new branch is created or the old branch is removed.
 
> Secondly, the discovered CRN has no way to know whether it is a CRN of
> mobility
> event (i.e. between Path 2 and Path 3) or a CRN of multiple paths (e.g.
> between
> Path 1 and Path 3). And, this is the root of the issue. Changing the CRN
> behavior and using CD Flag does not solve it fundmentally, and may cause
> further problems. For example, the CRN behavior described above
> obviously does
> not fit for non-multihoming cases.    

[SHL] Could you give me more clarifications on how the Path type ID 
classifies the paths required by multihoming functionalities from the paths 
created by mobility events? I guess the issues on removing the NSIS states 
at CRNs depend on how to put some identifiers in NSIS signaling messages.
 
>> 
>> > 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.
>>  
>> [SHL] I think this issue needs to further be discussed in the 
>> mobility draft.
>
> [SHIV] Correct, we need to discuss this issue/scenario further in the
> mobility draft as it is a valid issue. If needed we can provide
> relavent text for the draft, kindly let us know. 
>
> >[SHL] What do you think differences between Path type and CD flag?
> >
> 
> [SHIV] The CD Flag and Path Type ID are actually introduced for
> different
> purposes. The CD Flag (as what we understand) is for CRN discovery
> process, e.g.
> to avoid unnecessary further CRN discovery process after a CRN is
> already
> identified. 
>
> However CD Flag does not provide information about the relationship
> between
> different paths (whether they are old and new paths resulted from a
> mobility
> event, e.g. Path 2 & Path 3; or they are paths simultaneously used for a
> session,
> e.g. Path 1 and Path 3). This is where the Path Type ID could be used
> for. We
> don't think that the CD Flag and Path Type ID conflicts with each other
> since
> they are addressing different issues. 

[SHL] As I mentioned above, please give more clarifications on the 
"Path type ID."

Warm regards,
 
Sung-Hyuck

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

---

From: Takako Sanda <[email-masked]>
Date: Thu, 02 Mar 2006 17:39:47 +0900

Hi Sung-Hyuck,

Thank you for your comment. Please see my comment below.

BR,
Takako

On Thu, 02 Mar 2006 00:04:37 +0900
Sung-Hyuck Lee <[email-masked]> wrote:

<snip>
> at CRNs depend on how to put some identifiers in NSIS signaling messages.
<\snip>

Before discussion, let me clarify the issue again.

The point here is, there are two types of CRNs in the case MN uses
multiple (here we assume two) paths for same session. One is CRN between
two on-going paths, and the other one is CRN between old and new paths
caused by MN's handover. The former one (I temporally name it LB-CRN)
will need to manage two on-going paths, while the latter one (I temporally
name it HO-CRN) need to handle path update. These two CRNs need to be
differentiated in order to avoid perform path update for wrong one. Path
type ID is one way to differentiate these two.

Again, I give an example to show why two types of CRN should be
differentiated (with figures below):-
MN uses path1 and path2 for the same session. According to an assumption
in section 5.2.5 of the applicability draft, path1&2 uses the same SID
but different FID. So, CRN between path1&2, LB-CRN has two FID
information for the same SID.
Then, MN's one interface performs handover and obtain nCoA, MN will try
to establish new path with nCoA (i.e. new FID).
The new path will crossover with path1 or path2 (let's assume the new
path crossovers with path2). But the CRN between path2 and the new path
cannot know if it is LB-CRN or HO-CRN because for both case, SID is the
same but FID is different. And so it does not know if Path Update can be
performed. Even if "CD_Flag" is set by this CRN, existing CRN (LB-CRN)
still cannot differentiate which path should be updated.

      Path1                       
+--+  *********  +---+   +--+     
|  |**         **|LB |***|  |     
|MN|             |CRN|***|CN|     
|  |**         **|   |   |  |     
+--+  *********  +---+   +--+     
      Path2                       
 |                                
 v                                
                                  
+--+  *********  +---+   +--+     
|  |**         **|LB |***|  |     
|MN|             |CRN|***|CN|     
|  |**     ?   **|   |   |  |     
+--+  *****CRN*  +---+   +--+     
    *     *                       
     *****                        

As one of solutions, we proposed the way to explicitly show "which path
performs handover". If the new path include the information "I was path2
previously", the CRN in the example can know "OK, I am HO-CRN. So I
should perform path update for path2". If the information says "I was
path1 preciously", the CRN will say "OK, I am new LB-CRN, so path update
should be done in different node" (in this case, previous LB-CRN should
have a role of HO-CRN).
For this explicit information, we proposed to use extra few bit for
showing "path1" or "path2", and we call this path type ID. Of course, previous
FID can be utilized for this information. But as FID has large space, we
introduced to use small information.
I am not sure if NSLP_BR_ID has similar sort of information. In current
Applicability draft, NSLP_BR_ID contains (if my understanding
is correct) NSLP_ID-flow (=NSLP ID?!), upstream or downstream, and
mobility counter. And  so it seems not containing the similar
information. But I may misunderstand NSLP_Br_ID and CD_flag. If so,
could you kindly show how the parameters could solve the issue?

---

From: Sung-Hyuck Lee <[email-masked]>
Date: Thu, 02 Mar 2006 22:02:24 +0900

Hi Takako,
 
----- Original Message ----- 
From: "Takako Sanda" <[email-masked]>
To: "Sung-Hyuck Lee" <[email-masked]>
Cc: "Shivanajay Marwaha" <[email-masked]>; <[email-masked]>; "Pek Yew Tan" <[email-masked]>
Sent: Thursday, March 02, 2006 5:39 PM
Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft

> still cannot differentiate which path should be updated.

[SHL] I also guess Path type ID seems to be necessary to distinguish
paths created by mobility from paths established by load balancing. In this 
case, Path type ID just needs to identify whether a branch is additional for 
load balancing: For example, Path type ID can set as M (multiple path by 
multihoming ) or H (handover). And, NSLP_Br_ID can help classify which 
branch is old and new by its counter.
 
In the first figure above, CRN also needs to identify which branch is additional 
for load balancing. In this case, Let's assume Path 2 is the additional branch 
for load balancing. When LB-CRN is discovered between Path 1 and Path 2, 
NSLP_Br_ID for Path 1 and Path 2 is set as 1-D-#1 and 1-D-#2 (additional 
path for load balancing), respectively . LB-CRN may perform aggregation for 
downstream flows, not State Update by checking Path type ID for Load 
Balancing. 'CD flag' can be set saying "LB-CRN is discovered."
 
When a handover occurs, there are two scenarios on CRN created by Path 3. 
One is the case that CRN is created between Path 1 and Path 3 before 
Path 3 meets Path 2. The first case is same as the scenario shown in the 
first figure. NSLP_Br_IDs, for example, are set to 1-D-#1 and 1-D-#2 for 
Path 1 and Path 3, respectively. 'CD' flag is set to LB-CRN and just 
aggregation is performed for downstream flows. And afterwards, when Path 3 
meets Path2, HO-CRN is discovered and 'CD' flag is set to 'CRN'. In this 
case, although Path 3 follows track of Path 1, NSLP_Br_ID (for Path 3 and 
Path 1) is again set to 1-D-#3 to classify which branch is old and thus 
remove the old path.
 
Another is the case that CRN is created between Path 2 and Path 3 at first.
This case is same as the case that Path 2 and Path 3 meet at the first 
scenario. Only, NSLP_Br_ID is differently set whether CRN is created where 
Path 1, Path 2, and Path 3 all meets or not. Once CRN is discovered, the 
aggregation for flow can be perfomed irregardless of whether it is LB-CARN
or HO-CRN.

Thanks,
 
Sung-Hyuck

---

From: Takako Sanda <[email-masked]>
Date: Fri, 03 Mar 2006 12:20:36 +0900

Hi Sung-Hyuck,

Thank you for your comments. Please see my comments in line.

Thanks,
Takako

On Thu, 02 Mar 2006 22:02:24 +0900
Sung-Hyuck Lee <[email-masked]> wrote:

<snip>
> paths created by mobility from paths established by load balancing.
<\snip>

I guess the problem statement could be shared :)

<snip>
In this 
<\snip>

Our original thinking of path type usage is a bit different. let me
introduce the idea.
Path type ID is different identifiers for on-going paths, e.g. path type
"a" for path1 and path type "b" for path2 (see figure below). 

      Path1                       
+--+  aaaaaaaaa  +---+   +--+     
|  |aa         aa|LB |aaa|  |     
|MN|             |CRN|bbb|CN|     
|  |bb Path2   bb|   |   |  |     
+--+  bbbbbbbbb  +---+   +--+     

And when one path change the route, the same ID is reused, e.g. if path2
is change to path3, "b" is used for path3.Therefore, when two paths meet,
the CRN check the path type ID of the paths. if they are the same (case1),
the CRN is HO-CRN, and if they are different (case2), the CRN is LB-CRN. 
NSLP_Br_ID, especially "mobility counter" parameter, is necessary for
HO-CRN to know which path is old.

(case1)
+--+  aaaaaaaaa  +---+   +--+     
|  |aa         aa|LB |aaa|  |     
|MN|      +---+  |CRN|bbb|CN|     
|  |bb    |HO |bb|   |   |  |     
+--+  bbbb|CRN|  +---+   +--+     
    b    b+---+                   
     bbbb                         

(case2)                                
+--+  aaaaaaaaa  +---+   +--+     
|  |aa         aa|HO |aaa|  |     
|MN|      +---+  |CRN|bbb|CN|     
|  |bb    |LB |bb|   |   |  |     
+--+  bbbb|CRN|aa+---+   +--+     
    a    a+---+                   
     aaaa                         

<snip>
<\snip>

In this case NSLP_Br_IDs can differentiate on-going paths. But it may be
confused with mobility counter. Therefore, IMO, it would be better that
NSLP_Br_ID and path type ID are co-existing (although this discussion
would be too implementation specific :)). 

Thanks,
Takako

---

From: Sung-Hyuck Lee <[email-masked]>
Date: Fri, 03 Mar 2006 13:53:40 +0900

Hi Takako,
 
----- Original Message ----- 
From: "Takako Sanda" <[email-masked]>
To: "Sung-Hyuck Lee" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 03, 2006 12:20 PM
Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft

> HO-CRN to know which path is old.

[SHL] I see. There seem to be just differences on how to use the Path type ID. 

> would be too implementation specific :)). 

[SHL] I guess we say the same thing. :-) In the sentence above, I just mentioned 
the differences from the scenario shown in your first figure

Thanks,
 
Sung-Hyuck