Subject: Re: [netlmm] PMIPv6 (A Protocol for Network-based Localized MobilityManagement )

From: Marco Liebsch <[email-masked]>
Date: Wed, 10 Jan 2007 17:11:14 +0100

Hi Ajoy,

I have a general question to the proposed architecture, which can
have the PMIP Client separated from the AR. The draft sais that the
PMIP Assistent is *optional* and required in case the PBU is
sent though the AR. I think you need an Assistant on the AR in
any case, as the AR is responsible to handle the MN's data plane.
To take routing decisions, you probably need additional states
on the AR, not only on the PMIP Client. So, to set up these
states, sync between the PMIP Client and the AR is required.
Unless the AR contacts the PMIP Client for each packet, asking
for routing decisions...but I don't think this is what you propose.

What do you think?

marco

Singh Ajoy-ASINGH1 wrote:

>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,
>
>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.
>
>
>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. 
>
>Why should the MN then self-initiate the registration at the GMA?
>
>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.     
>
>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.
>
>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. 
>
> 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.
>
>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.
>
>
>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.
>
>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
>
>
>
>  
>
>>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
>
>_______________________________________________
>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: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Wed, 10 Jan 2007 17:50:17 -0500

Hi, Marco, 

Thanks for reviewing our draft. Please find my inline responses. 

Regards,
Ajoy  

-----Original Message-----
From: Marco Liebsch [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 10:11 AM
To: Singh Ajoy-ASINGH1
Cc: Damic, Damjan; [email-masked]
Subject: Re: [netlmm] PMIPv6 (A Protocol for Network-basedLocalized
MobilityManagement )

Hi Ajoy,

I have a general question to the proposed architecture, which can have
the PMIP Client separated from the AR. The draft sais that the PMIP
Assistent is *optional* and required in case the PBU is sent though the
AR. I think you need an Assistant on the AR in any case, as the AR is
responsible to handle the MN's data plane.
     
To take routing decisions, you probably need additional states on the
AR, not only on the PMIP Client. So, to set up these states, sync
between the PMIP Client and the AR is required.

Ajoy-> Sure, AR will need to know HA address, HoA and CaA of mobile. We
are assuming that such information will be 
available at AR in cases where PMIP assistant is not used. It can be
obtained using some out of band mechanism. 
Do you see any problem with approach? Probably we should clarify this. 

Unless the AR contacts the PMIP Client for each packet, asking for
routing decisions...but I don't think this is what you propose.

Ajoy-> We do not expect AR to consult PMIP client for routing decision. 

What do you think?

marco

Singh Ajoy-ASINGH1 wrote:

>LMA (AR<==>LMA<==>GMA), thus envisaging global mobility across 
>different domains.

>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 
>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

>suppress the MN from initating the MIP dialogue while roaming within 
>the same LMD.
>

>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., 
>Ajoy-> 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

>However, the protocol defined in our draft does not prohibit use of 
>PMIP for global mobility.
>

>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.
>We have also touched on the other point he raises - context transfer 
>and temporary tunneling between SAR-TAR, perhaps this requires further 
>elaboration too.
>
>

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 11 Jan 2007 10:01:52 +0100

Hi Ajoy,

my thoughts are inline as well.

>Do you see any problem with approach? Probably we should clarify this. 
Marco-> Does 'out of band' mean 'out of scope' of netlmm? Well, I thought
about more enhanced setup, such as multiple LMAs, states for route 
optimization, etc.
Such information is netlmm specific and must be available on the AR, which
would require signaling between the AR and a remote PMIP Client. I see
your PMIP Assistant as NetLMM processing entity on the AR node. Hence,
I see this function as mandatory. Maybe the discussion is more about
'in' and 'out of' scope. I see it 'in', by the way, in case a distributed
architecture should be supported.

>Ajoy-> We do not expect AR to consult PMIP client for routing decision.
Ok.

marco

>Singh Ajoy-ASINGH1 wrote:
...

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 11 Jan 2007 15:14:00 -0500

Hi, Marco, 

Please find my inline responses. 

Regards,
Ajoy 

Marco-> Does 'out of band' mean 'out of scope' of netlmm?

Ajoy-> You are correct. By "out of band" I meant 'out of scope" of
NETLMM. 
This is something that can be defined by SDO. 

Well, I 
Marco-> thought about more enhanced setup, such as multiple LMAs, states
for route optimization, etc.

Ajoy-> Ok

Such information is netlmm specific and must be available on the AR,
which would require signaling between the AR and a remote PMIP Client. I
see your PMIP Assistant as NetLMM processing entity on the AR node. 

Hence, I see this function as mandatory. Maybe the discussion is more
about 'in' and 'out of' scope. I see it 'in', by the way, in case a
distributed architecture should be supported.

Ajoy-> I am fine with this suggestion as well. We will take care of this
in next revision of the draft. 

Ok.

marco

...