Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-pfmipv6-00.txt

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 05 Nov 2008 23:48:16 +0900

Hi David,

Sorry for the late reply. I admit that there is not enough explanation
in the current document compared to the proactive mode. The MN may
provide the old AP ID at step (b) or the necessary information to
identify the PMAG may be exchanged between the P-AN and N-AN in advance
(before step (b)). All of them, however, are supposed to be access
specific and therefore not necessarily visible to the IP layer, which is
why the detail flows are not shown. The context shown along the HI/HAck
is the minimum common (therefore not exhaustive) information to identify
the MN and to send the PBU from the NMAG.

The MN policy profile may contain some additional information of the
PMAG, but it's not mandatory. There might be other ways.

I think that the reactive mode should have more text to explain this.

Thanks for your comments,
-- 
Hidetoshi

David Cypher wrote:
> Would someone please explain to me how the FPMIP handover can work when 
> it is the reactive case?
> 
> As shown in Figure 3 (page 12)
> If the mobile node (MN) is not involved in the PMIP and therefore not 
> involved in the FMIP part of FPMIP,
> how does the NMAG know the PMAG  that the MN was attached to in order 
> for the NMAG to send an HI (or Hack) to the PMAG?
> It looks like a case of "catch 22"  The NMAG must already have some 
> context for the MN so it knows the PMAG of the MN.
> However if the NMAG already has this information, why is a context 
> switch needed?  Why cannot the same place the provided the association 
> with MN and PMAG also contain the MN-HNP?
> 
> For FMIP the MN knew the PAR, but the MN is not involved in PMIP
> 
> There seems to be two purposes for the HI/HAck exchange
> a) context information exchange
> b) setting up the bi-directional tunnel
> 
> In the predictive state both purposes are used.  However in the reactive 
> state only b) is used.  Some of a) was obtained already, but how?   The 
> NAR has not sent a PBU to the LMA at this time, so it cannot have learnt 
> of the PMAG from the LMA.  Is it being proposed that the MN policy 
> profile contain the additional information (e.g., previous MAG and 
> MN-HNP) of its current MAG?
> 
> David Cypher
> ===============================
> At 02:30 PM 10/27/2008, you wrote:
>> Warning: This message has had one or more attachments removed
>> Warning: (not named).
>> Warning: Please read the following for more information.
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Mobility for IP: Performance, 
>> Signaling and Handoff Optimization Working Group of the IETF.
>>
>>
>>         Title           : Fast Handovers for Proxy Mobile IPv6
>>         Author(s)       : H. Yokota, et al.
>>         Filename        : draft-ietf-mipshop-pfmipv6-00.txt
>>         Pages           : 37
>>         Date            : 2008-10-27
>>
>> This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when
>> Proxy Mobile IPv6 is used as the mobility management protocol.
>> Necessary extensions are specified for FMIPv6 to support the scenario
>> when the mobile node does not have IP mobility functionality and
>> hence is not involved with either MIPv6 or FMIPv6 operations.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-pfmipv6-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> This is a message from the MailScanner E-Mail Virus Protection Service
>> ----------------------------------------------------------------------
>> The original e-mail attachment "not named"
>> was believed to be infected by a virus and has been replaced by this 
>> warning
>> message.
>>
>> If you wish to receive a copy of the *infected* attachment, please
>> e-mail [email-masked] and include the whole of this message
>> in your request. Alternatively, you can call them on x5375, with
>> the contents of this message at hand when you call.
>>
>> At Mon Oct 27 14:31:37 2008 the virus scanner said:
>>    External message bodies cannot be scanned and are removed
>>
>> Note to iTAC: Look on the NIST MailScanner3 in 
>> /var/spool/MailScanner/quarantine/20081027 (message m9RIVa6s012608).
>> -- 
>> Postmaster
>> National Institute of Standards and Technology
>>
>> _______________________________________________
>> Mipshop mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mipshop
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
> 
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: <[email-masked]>
Date: Thu, 20 Nov 2008 01:04:09 +0100

Hi Hidetoshi,

I have same concern than David with regards to reactive mode procedure:

How the nMAG knows pMAG id the MN is not involved in the mobility management process?

Summarizing our discussion we had yesterday after your presentation, there are several solutions. Stating that the MN is not involved in the process, nMAG can obtain the information from:

1- specific access network mechanisms. However a generic, i.e. a media independent, mechanism should be preferable.
2- MN's policy profile, assuming the later has been updated with the IP address of pMAG. However it duplicates binding information from the LMA. It seems not to be efficient (IMHO).
3- the LMA, which knows pMAG since the BCE is not uptated before step h) (fig 3.). Of course it requires a piece of additional signalling on nMAG/LMA interface between steps b) and c) of fig. 3. 

My two cents... Please feel free to comment.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Hidetoshi Yokota
> Envoyé : mercredi 5 novembre 2008 15:48
> À : David Cypher
> Cc : [email-masked]
> Objet : Re: [Mipshop] I-D Action:draft-ietf-mipshop-pfmipv6-00.txt
> 
> Hi David,
>

---

From: "Desire Oulai" <[email-masked]>
Date: Wed, 19 Nov 2008 22:56:20 -0500

Hi Pierrick, Hitoshi,

 That was my question at the end of Hidetoshi's presentation. IMO, even if the alternatives proposed by pierrick are good, we need MN involvement, specially in the handover between two interfaces. The MAG has two choices:

1 following regular PMIP operation to register the MN over the new interface
2 triggering FPMIP process. 

 It seems to me that FPMIP will be automatically triggered and that will result in setting HI = 2 (Handover between two interface). However, may be the MN want to have simultaneous access over both interfaces. Therefore, even if the PMAG address can be resolved using the MN profile, the LMA or other means, a MN indication is required to prevent this case.

BR

Desire
 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: November 19, 2008 7:04 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-pfmipv6-00.txt
> 
> 
> Hi Hidetoshi,
> 
> Summarizing our discussion we had yesterday after your 
> presentation, there are several solutions. Stating that the 
> MN is not involved in the process, nMAG can obtain the 
> information from:
> 
> 1- specific access network mechanisms. However a generic, 
> i.e. a media independent, mechanism should be preferable.
> 2- MN's policy profile, assuming the later has been updated 
> with the IP address of pMAG. However it duplicates binding 
> information from the LMA. It seems not to be efficient (IMHO).
> 3- the LMA, which knows pMAG since the BCE is not uptated 
> before step h) (fig 3.). Of course it requires a piece of 
> additional signalling on nMAG/LMA interface between steps b) 
> and c) of fig. 3. 
> 
> > De : [email-masked] 
> [mailto:[email-masked]] De la 
> > part de Hidetoshi Yokota Envoyé : mercredi 5 novembre 2008 
> 15:48 À : 
> > David Cypher Cc : [email-masked] Objet : Re: [Mipshop] I-D 
> > Action:draft-ietf-mipshop-pfmipv6-00.txt
> > 
> > Hi David,
> > 
> > identify the PMAG may be exchanged between the P-AN and N-AN in 
> > advance (before step (b)). All of them, however, are supposed to be 
> > access specific and therefore not necessarily visible to 
> the IP layer, 
> > which is why the detail flows are not shown. The context 
> shown along 
> > the HI/HAck is the minimum common (therefore not exhaustive) 
> > information to identify the MN and to send the PBU from the NMAG.
> > 
> > > Would someone please explain to me how the FPMIP handover 
> can work 
> > > when it is the reactive case?
> > >
> > > If the mobile node (MN) is not involved in the PMIP and therefore 
> > > not involved in the FMIP part of FPMIP, how does the NMAG 
> know the 
> > > PMAG  that the MN was attached to in order for the NMAG 
> to send an 
> > > HI (or Hack) to the PMAG?
> > > switch needed?  Why cannot the same place the provided the 
> > > association with MN and PMAG also contain the MN-HNP?
> > >
> > > NAR has not sent a PBU to the LMA at this time, so it cannot have 
> > > learnt of the PMAG from the LMA.  Is it being proposed 
> that the MN 
> > > policy profile contain the additional information (e.g., previous 
> > > MAG and
> > >> Necessary extensions are specified for FMIPv6 to support the 
> > >> scenario when the mobile node does not have IP mobility 
> > >> functionality and hence is not involved with either 
> MIPv6 or FMIPv6 operations.
> > >>
> -------------------------------------------------------------------
> > >> --- The original e-mail attachment "not named"
> > >> was believed to be infected by a virus and has been replaced by 
> > >> this warning message.
> > >>
> > >> e-mail [email-masked] and include the whole of this 
> message in your 
> > >> request. Alternatively, you can call them on x5375, with the 
> > >> contents of this message at hand when you call.
> > >>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 20 Nov 2008 13:34:39 -0500

Hi Desire,

>  It seems to me that FPMIP will be automatically triggered and that will
> result in setting HI = 2 (Handover between two interface). However, may be
> the MN want to have simultaneous access over both interfaces. Therefore,
> even if the PMAG address can be resolved using the MN profile, the LMA or
> other means, a MN indication is required to prevent this case.

[RKo:>] Why is this (simultaneous connectivity) specific to FPMIP? This is a general PMIP problem, IMO.

I think it is sufficient not to disallow different mechanisms for the NMAG to determine the PMAG's address; I would use access-network mechanisms.  
 
-Rajeev

---

From: "Desire Oulai" <[email-masked]>
Date: Thu, 20 Nov 2008 17:06:43 -0500

Hi Rajeev,

 See inline.

BR

Desire 

> From: Koodli, Rajeev [mailto:[email-masked]] 
> Sent: November 20, 2008 1:35 PM
> To: Desire Oulai; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Mipshop] I-D Action:draft-ietf-mipshop-pfmipv6-00.txt
> 
> 
> Hi Desire,
> 
> >  It seems to me that FPMIP will be automatically triggered and that 
> > will result in setting HI = 2 (Handover between two interface). 
> > However, may be the MN want to have simultaneous access over both 
> > interfaces. Therefore, even if the PMAG address can be 
> resolved using 
> > the MN profile, the LMA or other means, a MN indication is 
> required to prevent this case.
> 
> [RKo:>] Why is this (simultaneous connectivity) specific to 
> FPMIP? This is a general PMIP problem, IMO.
> 
> I think it is sufficient not to disallow different mechanisms 
> for the NMAG to determine the PMAG's address; I would use 
> access-network mechanisms.  
[Desire]: My comment was not about directly about the PMAG address resolution. 
I agree that simultaneous connectivity but I raised this comment because the draft 
provides some interesting rules to set the HI bit. And those rules are are access 
agnostic. Therefore, in simultaneous mobility, it is important to have the input of 
the MN. Of course, it could be access specific but I believe the draft should mention 
This (Maybe in the section where you give the rules for HI value determination).

> presentation, 
> > > there are several solutions. Stating that the MN is not 
> involved in 
> > > the process, nMAG can obtain the information from:
> > >
> > > 1- specific access network mechanisms. However a generic, i.e. a 
> > > media independent, mechanism should be preferable.
> > > 2- MN's policy profile, assuming the later has been 
> updated with the 
> > > IP address of pMAG. However it duplicates binding 
> information from 
> > > the LMA. It seems not to be efficient (IMHO).
> > > 3- the LMA, which knows pMAG since the BCE is not uptated before 
> > > step h) (fig 3.). Of course it requires a piece of additional 
> > > signalling on nMAG/LMA interface between steps b) and c) 
> of fig. 3.
> > >
> > > > advance (before step (b)). All of them, however, are 
> supposed to 
> > > > be access specific and therefore not necessarily visible to
> > > the IP layer,
> > > > > If the mobile node (MN) is not involved in the PMIP and 
> > > > > therefore not involved in the FMIP part of FPMIP, how 
> does the 
> > > > > NMAG
> > > know the
> > > > > NAR has not sent a PBU to the LMA at this time, so it cannot 
> > > > > have learnt of the PMAG from the LMA.  Is it being proposed
> > > that the MN
> > > > > policy profile contain the additional information (e.g., 
> > > > > previous MAG and
> > > > >> Below is the data which will enable a MIME compliant mail 
> > > > >> reader implementation to automatically retrieve the ASCII
> > > version of the
> > > > >> Internet-Draft.
> > > > >> This is a message from the MailScanner E-Mail Virus 
> Protection 
> > > > >> Service
> > > > >>
> > > 
> This email and any attachments may contain legally privileged 
> and/or confidential information of Starent Networks, Corp. 
> and is intended only for the individual or entity named in 
> the message.  The information transmitted may not be used to 
> create or change any contractual obligations of Starent 
> Networks, Corp.  Any review, retransmission, dissemination or 
> other use of, or taking of any action in reliance upon this 
> e-mail and its attachments by persons or entities other than 
> the intended recipient is prohibited. If you are not the 
> intended recipient, please notify the sender immediately -- 
> by replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you.
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 20 Nov 2008 17:33:01 -0500

I assume you are referring to Appendix A? 

Thanks,

-Rajeev

---

From: "Desire Oulai" <[email-masked]>
Date: Thu, 20 Nov 2008 17:57:27 -0500

Right!

BR

Desire 

> [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> Sent: November 20, 2008 5:33 PM
> To: [email-masked]
> > I agree that simultaneous connectivity but I raised this comment 
> > because the draft provides some interesting rules to set 
> the HI bit. 
> > And those rules are are access agnostic. Therefore, in simultaneous 
> > mobility, it is important to have the input of the MN. Of 
> course, it 
> > could be access specific but I believe the draft should 
> mention This 
> > (Maybe in the section where you give the rules for HI value 
> > determination).
> > 
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR
> > > >
> > > > Desire
> > > >
> > > > > > identify the PMAG may be exchanged between the P-AN 
> and N-AN 
> > > > > > in advance (before step (b)). All of them, however, are
> > > supposed to
> > > > > > > As shown in Figure 3 (page 12) If the mobile node (MN) is 
> > > > > > > not involved in the PMIP and therefore not 
> involved in the 
> > > > > > > FMIP part of FPMIP, how
> > > does the
> > > > > > > NMAG
> > > > > know the
> > > > > > > =============================== At 02:30 PM 
> 10/27/2008, you 
> > > > > > > wrote:
> > > > > > >> Necessary extensions are specified for FMIPv6 to support 
> > > > > > >> the scenario when the mobile node does not have 
> IP mobility 
> > > > > > >> request. Alternatively, you can call them on x5375, with 
> > > This email and any attachments may contain legally 
> privileged and/or 
> > > confidential information of Starent Networks, Corp.
> > > and is intended only for the individual or entity named in the 
> > > message.  The information transmitted may not be used to 
> create or 
> > > change any contractual obligations of Starent Networks, 
> Corp.  Any 
> > > review, retransmission, dissemination or other use of, or 
> taking of 
> > > any action in reliance upon this e-mail and its attachments by 
> > > persons or entities other than the intended recipient is 
> prohibited. 
> > > If you are not the intended recipient, please notify the sender 
> > > immediately -- by replying to this message or by sending 
> an email to 
> > > [email-masked] -- and destroy all copies of this 
> > > message and any attachments without reading or disclosing their 
> > > contents. Thank you.
> > >

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 22 Nov 2008 00:37:51 +0900

Hi Pierrick,

Thanks for your good question. I think this is not only for the reactive 
mode, but also for the predictive mode because the PMAG needs to know 
the NMAG in advance in one way or another, which is not explicitly 
specified in this document. As you kindly listed up, there are several 
ways to do that, and it's most likely that the lower layer helps provide 
the necessary information. I fully agree that this should be access 
independent, but in reality, it's often access specific. This is why we 
avoid detailed descriptions, but it may be good to add some text to the 
level that the readers don't get lost:-)

Regards,
-- 
Hidetoshi

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 22 Nov 2008 01:26:03 +0900

Hi Desire,

Thanks for your question in the meeting and on the ML. Please see inline:

>  It seems to me that FPMIP will be automatically triggered and that will result in setting HI = 2 (Handover between two interface). However, may be the MN want to have simultaneous access over both…

The situation is the other way around. PFMIPv6 is triggered when the
network decides that the link change is a handover. it is outside the
scope how the network decides it. It may be some hint from the MN or may
be based on the policy stored somewhere in the network. The MN may be
allowed to choose whether the new link attachment is a handover or
multihoming, or the network totally controls the link attachment
regardless of the MN's intention. Anyway, once the HO initiate is
triggered and the HI is sent to the NMAG, the Handover Indicator option
can be set to 2 or 3 (Handover) depending on the access type.

You may be concerned about the case where the old and new links use
different access technologies, in which case a tight interaction may not
be easy. In reality, each SDO specifies its own optimized (fast)
handover mechanisms between different access technologies, but they are
very access specific and we want to avoid that in the draft. If the
current draft is too vague and totally clueless, I would consider add
some text for the clarification.

Regards,
-- 
Hidetoshi

---

From: <[email-masked]>
Date: Mon, 24 Nov 2008 09:29:59 +0100

> De : Hidetoshi Yokota [mailto:[email-masked]]
> Envoyé : vendredi 21 novembre 2008 16:38
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]

I definitely agree, thanks.

Pierrick

> > Summarizing our discussion we had yesterday after your presentation,
> there are several solutions. Stating that the MN is not involved in the
> process, nMAG can obtain the information from:
> >
> > 1- specific access network mechanisms. However a generic, i.e. a media
> independent, mechanism should be preferable.
> > 2- MN's policy profile, assuming the later has been updated with the IP
> address of pMAG. However it duplicates binding information from the LMA.
> It seems not to be efficient (IMHO).
> > 3- the LMA, which knows pMAG since the BCE is not uptated before step h)
> (fig 3.). Of course it requires a piece of additional signalling on
> nMAG/LMA interface between steps b) and c) of fig. 3.
> >
> learnt