Subject: RE: [netlmm] PMIPv6 (A Protocol for Network-based Localized Mobility Management )

From: "Damic, Damjan" <[email-masked]>
Date: Tue, 19 Dec 2006 15:17:47 +0100

Hello Ajoy,

Please find here few (hopefully useful) comments... 

1) I got confused by one detail while reading the protocol description
in Section 4.0:

At first, we were assuming the approach where 2 tunnels adjoin at the
LMA (AR<==>LMA<==>GMA), thus envisaging global mobility across different
domains. 
But after reading the description again, it seems that actually 2
tunnels get established in parallel:

	AR<==>LMA   (binding the MN's CoA to AR address)
	MN<==>GMA  (binding MN's HoA to CoA)

If so, we couldn't quite figure the exact purpose of the first tunnel?
Could you elaborate in few more details how exactly the data path gets
established, the suitable description is either missing in the document
or can be easily misinterpreted.

2) The draft states MN may be a MIP capable node (and may utilize this
for global mobility)
Advertisement of the LMA prefix by ARs should suppress the MN from
initating the MIP dialogue while roaming within the same LMD.
Why should the MN then self-initiate the registration at the GMA?
Shouldn't the PMIP have its part in this process (This actually extends
my previous question about the MN-GMA tunnel).
Apart, use of PMIPv6 solely for LMM, while relying on a host-based
approach for global mobility doesn't look like a straghtforwards use
scenario, probably one may argue about the overall benefit of such
concept.

 3) Compared to other IETF PMIPv6 proposals, the approach with the
standalone PMIP client is a novelty.
Maybe you are aware that a similar concept is proposed in WiMAX Forum,
though PMIPv4-wise? If not, here's a simple example:
MN moves away from the Serving AR/FA (SAR), initiating the HO.
After receiving a HO trigger, the standalone PMIP-Client (somewhere in
the network, assigned for the whole session-lifetime) generates a new
MIP4 RRQ and sends towards the Target AR/FA (TAR). TAR registers at the
HA expecting to receive RRP. RRP is forwarded back to PMIP-Client,
initiating establishment of the new data path. While this procedure is
ongoing, you may have context exchange as well as the temporary
tunneling in between SAR-TAR, to reduce delay and packet loss.

Otherwise, the document is trying to cover a lot of ground with the
HMIPv6 compliant solution, but still misses some distinct details in
those sections.

Kind regards,
Damjan

>From: "Singh Ajoy-ASINGH1" <[email-masked]>
>Subject: [netlmm] PMIPv6 (A Protocol for Network-based Localized
Mobility Management )
>To: <[email-masked]>
>
>Hi, All,
> 
>We have submitted an enhanced version of PMIPv6 draft
>(http://www.ietf.org/internet-drafts/draft-singh-netlmm-protoco
>l-00.txt)
>. This draft is
>resubmission of our earlier draft
>(http://tools.ietf.org/wg/netlmm/draft-raman-netlmm-protocol-00.txt).
>The earlier draft was submitted before Dallas IETF meeting as 
>an input to design team. We did not pursue this draft because 
>NETLMM DT was working on a protocol design and it was not 
>clear if PMIPv6 solution will be considered by NETLMM or not. 
>Given that there is renewed interest in PMIPv6 approach, this 
>draft is very relevant to current scope of NETLMM WG. 
>In this draft, we have introduced the concept of bearer and 
>control plane separation, possibility of implementing PMIPv6 
>client function on a centralized entity and use of MIPv6 HA 
>and HMIPv6 as LMA.  We have also looked at security aspect of 
>PMIPv6 solution in more detail. I would request NETLMM WG to 
>review and provide feedback to our draft. 
> 
>Regards,
>Ajoy 
> 
> 
>PS: I will be on leave next week, so I can only respond to any 
>email comments after I am back. But my co-authors will be able 
>to respond to any comments. 

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Tue, 19 Dec 2006 14:05:53 -0500

Hello Damjan, 

Thanks for reviewing our draft and providing useful comments. 
Please find below our inline responses. 

Regards,
Ajoy  

-----Original Message-----
From: Damic, Damjan [mailto:[email-masked]] 
Sent: Tuesday, December 19, 2006 8:18 AM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: RE: [netlmm] PMIPv6 (A Protocol for Network-based Localized
MobilityManagement )

Hello Ajoy,

Ajoy-> The two different tunnels AR<-->LMA and MN<-->GMA are basically
for the situation where the MN connects to a (local-mobility-capable)
domain, acquires an address there, and wants to use this address as a
CoA for its global mobility. But you're right, strictly speaking, what
the MN does with the address it acquires in the local domain is its
business - it can use it just for internet access, or it can use it as a
CoA for some global mobility MIP or whatever. The focus of the draft
really is just the first AR<-->LMA tunnel. This tunnel is "transparent" 
to the MN, and similarly what the MN does with the address it acquires
for the local domain is "transparent" to the AR/LMA. As far as the draft
is concerned, the MN acquires/configures an address for the local
domain, and as long as the MN remains in that domain, it can use the
address (with the LMA redirecting packets to the appropriate AR in the
domain through PMIP binding update). We would clearifu this in
subsequent submission. 

2) The draft states MN may be a MIP capable node (and may utilize this
for global mobility) Advertisement of the LMA prefix by ARs should
suppress the MN from initating the MIP dialogue while roaming within the
same LMD.

Ajoy-> Correct. MIP client on MN is used to address mobility when an MN
moves from one LMD to 
other i.e., global mobility. Note MN MIP stack is not aware of mobile's
inter-AR movement inside a given LMD
because it will always receive same LMA specific prefix information as
part of Rtr Adv. 

Ajoy-> This is needed when MN would move from one LMD to other i.e., for
global mobility. Note mobile will receive new prefix 
information after it will cross from one LMD to other as part of RA
messages. The reception of new prfeix information 
would trigger client based movement detection thereby requing MN to
establish binding with home agent.     

Ajoy-> I guess you are asking why PMIP agent is not performing global
mobility? Yes, it is possible to do that but we have not described that
usecase scenario in our draft. We did not do that because we thought
host based approach would be better method for inter-domain mobility.
However, the protocol defined in our draft does not prohibit use of PMIP
for global mobility. 

Ajoy-> Yes, the "standalone" PMIP client is an aspect we are very
interested in. It facilitates several things - keeping the security keys
for securing the BU "anchored" in one place even when the MN moves from
AR to AR, etc.
We are aware of the WiMAX PMIP solution, and this is partly motivated by
how WiMAX is doing it. Note that in WiMAX (PMIPv4) implementation, the
PMIP client sends the request to the HA "through" the AR, and the reply
has to come back to PMIP client "through" the AR. In our draft for
PMIPv6, though, we are proposing the use of the "alternate CoA" option
from RFC 3775 - the standalone PMIP client can send a BU directly to the
HA (i.e. not "through" the AR), giving the "alternate CoA" as the
address of the AR. This accomplishes exactly what WiMAX is trying to do,
but within the framework of MIPv6. MIPv4 doesn't allow such an
"alternate CoA" possibility. Further, the way MIP4 is defined, when an
FA is used (rather than colocated COA), the RRQ has to go "through" the
FA otherwise the FA doesn't know that it needs to get involved, etc. 
Hence MIP4 RRQ has to be sent "through" the FA.
We have also touched on the other point he raises - context transfer and
temporary tunneling between SAR-TAR, perhaps this requires further
elaboration too.

Ajoy-> Once again, good comments. We will try to address some of your
comments in next revision of the draft. 
We will also beef-up HMIPv6 section. 

Kind regards,
Damjan

Mobility Management )
>The earlier draft was submitted before Dallas IETF meeting as an input 
>to design team. We did not pursue this draft because NETLMM DT was 
>working on a protocol design and it was not clear if PMIPv6 solution 
>will be considered by NETLMM or not.
>Given that there is renewed interest in PMIPv6 approach, this draft is 
>very relevant to current scope of NETLMM WG.
>In this draft, we have introduced the concept of bearer and control 
>plane separation, possibility of implementing PMIPv6 client function on

>a centralized entity and use of MIPv6 HA and HMIPv6 as LMA.  We have 
>also looked at security aspect of
>PMIPv6 solution in more detail. I would request NETLMM WG to review and

>provide feedback to our draft.
> 
>Regards,
>Ajoy
> 
> 
>PS: I will be on leave next week, so I can only respond to any email 
>comments after I am back. But my co-authors will be able to respond to 
>any comments.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Dec 2006 16:12:33 +0100

Hi Damjan, please allow me to respond to some parts of your message.

Damic, Damjan wrote:
[...]
> 2) The draft states MN may be a MIP capable node (and may utilize 
> this for global mobility) Advertisement of the LMA prefix by ARs 
> should suppress the MN from initating the MIP dialogue while roaming
>  within the same LMD. Why should the MN then self-initiate the 
> registration at the GMA? Shouldn't the PMIP have its part in this 
> process (This actually extends my previous question about the MN-GMA
>  tunnel). Apart, use of PMIPv6 solely for LMM, while relying on a 
> host-based approach for global mobility doesn't look like a 
> straghtforwards use scenario, probably one may argue about the 
> overall benefit of such concept.

I think it makes a lot of sense to have MIPv6 (host-based approach)
implementation on the mobile node for global mobility, and have
network-based mobility implementation in some access networks.  It is
very straightforward to me.

The quirk is how to make MN think it hasn't moved while changing ARs in
the lm domain.  Draft-sgundave proposes to advertise same prefix in an
RA from any AR.  Draft-singh assumes that too.  However, while
draft-sgundave advertises a specific prefix to each MN draft-singh
advertises only one prefix across entire domain.  I think none is
feasible and that maybe RAs should be sent as usual: different under
each AR, not depending on MN presence, and not depending on a specific MN.

We could also make MN decide it never changes its CoA by some new
1bit-enhanced RAs it receives.  For example, as long as that new 1bit is
1 consider sending DHCP Confirm, instead of requesting a new address by
DHCP, and instead of using prefix in RA (that's given by M too).

> standalone PMIP client is a novelty.

I agree, draft-singh is first to mention it at IETF.  I was surprised by
it because I'm not aware of the WiMax PMIPv4.  There's an IETF PMIPv4
draft-leung-mip4-proxy and that doesn't talk standalone PMIP client.

It may be that some of the such separated standalone functionalities may
be needed.  For example, draft-njedjou-netlmm-nih talks about
network-initiated handovers with netlmm, by a "inter-system mobility
function"; that draft also motivates 802.21 MIH Service that would do ho
initiation across heterogeneous links.

Similarly approaching concepts are in
draft-nishida-netlmm-protocol-applicability where a MME or HSS (of 3GPP
SAE LTE) would do approximately the same thing as standalone PMIP client
(personal long speculation).

Now the question is whether our PMIPv6 protocol will use only AR and pHA
topological entities, or will it need to use a third standalone entity.

> Maybe you are aware that a similar concept is proposed in WiMAX 
> Forum, though PMIPv4-wise? If not, here's a simple example: MN moves 
> away from the Serving AR/FA (SAR), initiating the HO. After receiving
> a HO trigger, the standalone PMIP-Client (somewhere in the network,
> assigned for the whole session-lifetime) generates a new MIP4 RRQ and
> sends towards the Target AR/FA (TAR). TAR registers at the HA
> expecting to receive RRP. RRP is forwarded back to PMIP-Client,
> initiating establishment of the new data path. While this procedure
> is ongoing, you may have context exchange as well as the temporary

Remark with draft-singh the AR initiates the handover, not the MN.

> HMIPv6 compliant solution, but still misses some distinct details in 

I think there is no need to cover HMIPv6 usage in PMIP protocol.  It is
indeed a theoretical possibility but may make things too complicated.
PMIP and HMIP both do approximately same thing.  In the previous netlmm
discussion HMIP was presented as a candidate but considered out out
scope since it has host involvement.

So one would have a choice to make net-based LMM: either use MIP
derivations or HMIP derivations.  Can't use both.

Alex