Subject: Re: [netlmm] Multiple Interface support in PMIPv6

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Nov 2007 11:19:05 -0800

Hi Mohana,

Mohana Jeyatharan wrote:
> Hi Vijay,
> 
> Thanks for posting your draft: analysis of multiple interface attachment
> over PMIP. It is really good that you have analyzed all possible ways of
> achieving multihoming in PMIP and I think it is always good to think in
> this line when one considers possible techniques of achieving host
> multihoming in PMIP domain.
> 
> I have some comments or feedback on this draft.
> Your draft has primarily concentrated on a multi-prefix model and
> analyzed the possible issues that may have to be dealt if the
> multiprefix model is implemented as specified in PMIPv6-v7.

It analyzes three different scenarios. Multiple prefixes is just
the first scenario. The second scenario assumes the same prefix
is assigned to both interfaces. The third one assumes that the
same address is assigned to both interfaces. The reason there is
more text for the first scenario is because we have analyzed that
more. In fact a lot of that text is very relevant to the base
PMIPv6 specification, since IMO, many of the details were left out
of scope in the base PMIPv6 specification.

> In section 3.1 where you have analyzed a horizontal hand-off scenario,
> it seems you have identified that when interface identifier is not
> available, the LMA may assign a different prefix if hand-off indicator
> flag is set to "4" (meaning do not know the hand-off type). 

This is in line with the base PMIPv6.

> Also it is
> mentioned that the hand-off type has to be known to MAG3 to get the
> correct prefix allocated by LMA. But, IMO it seems the IF-ID given MN at
> L2 attachment to MAG3 is sufficient to get the correct prefix allocated
> at LMA. Is the hand-off state to be known by MAG3 important? 

If the Interface ID is presented to the MAG3 by the MN, then it
the hand-off indicator flag set to "4" does not mean anything.
The LMA can assign the same prefix if the interface id is the
same as the one stored in the binding cache entry.

Bcos, when
> I read the draft, you have mentioned context transfer and AAA providing
> informarion on hand-off state. I was thinking, since MAG3 does not know
> IF-ID, MN giving it as you stated is sufficient. The hand-off state need
> not be notified.  

Right, if the Interface ID is available, then it does become
easier.

> I have another general query. From base draft v7, the general
> understanding is that for horizontal hand-off, the prefix will be
> allocated to new MAG based on matching the If-ID in PBU to the existing
> IF-ID cache at LMA. The basic assumption for this to happen is that the
> de-reg should not arrive before the hand-off PBU. If the de-reg arrives,
> then there is a possibility a new prefix may be allocated. I am not sure
> how the base spec will handle this? Any thoughts?

No. A typical LMA implementation would not allocate the prefix
to another mobile router for a short period of time and if the
MN attaches again, it will allocate the same prefix again. The
PMIPv6 base specification also hints at that. Sri?

> In section 3.1.2, to solve the same prefix to be assigned during
> hand-off between interfaces (vertical hand-off), you have mentioned that
> either If-ID, prefix or MAG address of the handed over interface needs
> to be sent to get the correct prefix to be assigned. I thought this is
> already covered in the base draft. Correct me if I am wrong. Pg. 26,
> bullet 5 has a scenario, where during vertical hand-off the previous
> interfaces's assigned prefix is sent in the PBU. I felt that this issue
> is already covered. 

The base spec does not talk about how the MAG3 obtains information
about if1. In fact it assumes the mobile node is not involved in
presenting this information to MAG3, since our charter says no
modifications to the host. Section 3.1.2 explicitly requires the
mobile node to tell MAG3 which interface is being handed off to
which one.

> Now, in section 3.2, you have mentioned of achieveing multihoming using
> a single prefix model. But, the question I have is, why should the
> binding cache be such that the addresses are used to differentiate the
> simultaneous bindings. Can't prefixes 

Prefix would be the same. So that can't be used.

> and some other interface specific
> identifiers be used. 

When the LMA receives an IP packet that needs to be tunneled to a
particular MAG, there is no interface specific information in the
IP packet. Only information available is the destination IP address
on the packet that matches the IP address allocated to the mobile
node.

> Restricting to addresses means, that a flow
> addressed to a single address cannot be traversed via all attchments of
> a MN to PMIP.

You could use the flow filter in addition to the IP address. That
is fine with me.

> Furthermore, I have another question on the multilink subnet issue you
> have mentioned for a single prefix model. When MN sees the same prefix
> via both interfaces it resembles a multi-link scenario. I perfectly
> understand this. In a multi-link subnet scenario, to avoid duplicate
> addresses being assigned, DAD may need to be done. And as you have
> mentioned in the draft, in a point-to-point link model, neighbour
> discovery cannot be run between two distinct point-to-point links. I
> have some clarification on this. First of all, since each prefix on MN
> interface is unique to a MN, a duplicate address configuration as in the
> case of general multi-link subnets does not arise here as long as the MN
> is notified not to respond to DAD message from its some other interface.
> Ofcourse a host modification is essential. Moreover, since the links are
> Point-to-point, I don't see why a DAD will fail even if duplicate
> addresses are configured across the interfaces of a MN. DAD in one link
> may not be heard by another interface of MN. This is my thinking and
> your comments are most welcome.

I do agree that this might not be a big deal. Especially the three
issues identified in 4903 in section 2 may not be applicable here.
But I have to think about this a little bit more.

> Finally, I would like to thank you for this draft since you have kind of
> highlighted the pros and cons of both model(multi prefix and single
> prefix model).

Thanks for reading the draft. :)

> Lastly, I request you to read our draft called:multiple interfaces in
> PMIP.

I will.

Vijay

>  
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jeyatharan-netlmm-multi-interf
> ace-ps-00.txt
> 
> This draft is a problem statement draft. Basically looked at multihoming
> issue when PMIP employs a single prefix assignement per MN. The draft
> highlights, if single prefix model is used, what will be the problem
> like. The problem is stated for MN which can be a MIPv6 host or an IPv6
> host. The problem is further analysed in various PMIP and CMIP roaming
> scenarios when the MN has Monami6 functionality incorporated. Basically,
> the objective is to understand the problem in various scneraios and to
> identify appropriate solutions for this issue. 
> 
> Please take a look and would really appreciate some comments and
> feedback.
> 
> Thanks in advance.
> 
> BR,
> Mohana
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, November 13, 2007 6:08 AM
> To: Netlmm
> Subject: [netlmm] Multiple Interface support in PMIPv6
> 
> Hello folks,
> 
> Here is a draft that analyzes various scenarios when a mobile node with
> multiple interfaces attaches to a PMIPv6 domain.
> 
> http://www.ietf.org/internet-drafts/draft-devarapalli-netlmm-multihoming
> -01.txt
> 
> It talks about three cases, 1) Unique prefix per interface, 2) Unique
> address per interface and 3) Shared address across interfaces. It also
> addresses inter-access technology handovers.
> 
> Comments/reviews are welcome.
> 
> Vijay
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 28 Nov 2007 14:24:04 -0800 (PST)

> PMIPv6 base specification also hints at that. Sri?

There is a MinDelayBeforeBCEDelete timer, that ensures the
network can handle out of order delivery of Reg msg from
the nMAG and and DeReg msg from the pMAG. So, we dont kill
the mobility session immediatly after we recv a dereg, but
allow some time for the new reg to come in.

Sri