Re: Action:draft-zhao-mipshop-fmip-pfmip-00.txt

Hi David,

Thanks for your comments. Please see inline.

On Tue, Oct 28, 2008 at 5:57 AM, David Cypher <david.cypher <at> nist.gov> wrote:
> Comments
> 1)
> I thought by definition of PMIP, the MN was unaware and not involved.  That
> is a MN did not support PMIP.
> If this is still true, how can the first sentence of 3 (page 4) be true?
>
> "A MN may support both MIP and the PMIP."

There was some discussion on whether PMIP can be supported, but such issue
is not in the scope of this draft. What I intend to say is that the MN
knows about
both mobility protocols and knows what protocol is supported by a
specific access
network. I can make the text clearer.

>
> 2)
> With the release of
> draft-ietf-mipshop-pfmipv6-00.txt
> will 9.1 page 11 normative reference #2 be updated accordingly?
Yes, we will refer to the new version of PFMIP.

Sincerely,
fan

I-D Action:draft-ietf-mipshop-mstp-solution-09.txt

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           : IEEE 802.21 Mobility Services Framework Design (MSFD)
	Author(s)       : T. Melia, et al.
	Filename        : draft-ietf-mipshop-mstp-solution-09.txt
	Pages           : 25
	Date            : 2008-11-03

This document describes a mobility services framework design (MSFD)
for the IEEE 802.21 Media Independent Handover (MIH) protocol that
addresses identified issues associated with the transport of MIH
messages.  The document also describes mechanisms for mobility
service (MoS) discovery and transport layer mechanisms for the
reliable delivery of MIH messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-09.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.

_______________________________________________

MIPSHOP meeting in Minneapolis

Hello folks,

We are putting together the agenda for the MIPSHOP meeting at IETF 73.

If you need a slot please send an email to Stefano and myself.

Vijay

new draft "Mobile IPv6 Handover Using Home Agent Buffering"

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www.ietf.org/mailman/listinfo/mipshop

comments on draft-ietf-mipshop-pfmipv6-00

Hi,

I have some comments on this draft.

1) Section 4.1
"  (c)  The PAR sends the HI to the NAR.  The HI message MUST include
        the MN ID and SHOULD include the MN-HoA, the MN-HNP, the MN-IID
        and the address of the LMA that is currently serving the MN.
...

   (e)  The NAR requests the PAR to buffer or forward packets by setting
        U or F flags in the HI message, respectively."

From the figure, it seems to me that at step (e), a set of
new HI/Hack messages are exchanged for packet forwarding
while step (c) and (d) are for context transfer. Do I understand correctly?
Can (e) be combined with (c) and (d)?

Also It seems to me that (e) should be "The PAR requests the NAR ..
in the HI .."

2) "The timing of the context transfer and that of packet forwarding may
   be different.  Thus, a new flag 'F' and the Option Code values for it
   in the HI message are defined to request forwarding.  To request
   buffering, 'U' flag has already been defined in [RFC5268].  If the
   PAR receives the HI message with F flag set and the Option Code value
   being 2, it starts forwarding packets for the MN."

It seems to me that it is the PAR that sends the HI message and receives
the Hack message.

3) The case when the target access network supports MIP instead of PMIP
is described. I also submitted a draft,
http://tools.ietf.org/id/draft-zhao-mipshop-fmip-pfmip-00.txt.
Comments are very appreciated.

Thanks.

Sincerely,
fan

Re: I-D Action:draft-ietf-mipshop-pfmipv6-00.txt

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 itac <at> nist.gov 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
>> Mipshop <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/mipshop
> 
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
> 
> 
> 

Re: [netlmm] PMIP6-MIP6 Interactions - Take 2

Hi Kilian,

please let me just point to some work in MIPSHOP that may be of interest here .

> If PMIP is extended to support it, approach b) supports it as well.

I agree to your statement that PMIP doesn't support delaying of PBU at nMAG (e.g. MAG on home link). But
actually, MIPSHOP currently is specifying a way to allow this in the way that the PBU comes with a
"transient binding" option. This option indicates that the LMA shall not yet forward traffic to the MN via
nMAG (i.e. the home link in this case). Later, a second PBU (without the option) can be used to start
forwarding through the tunnel to nMAG. With this extension delaying would be possible. (see
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-transient-bce-pmipv6-00.txt . An
earlier version of this has been discussed as an individual draft to netlmm in Philadelphia)  

A use case for delaying occurs when the link layer is not yet finalised (e.g. during bearer setup between
access point and MAG in the home link). Another use case may be that at the time of the PBU the radio channel to
the home link is still quite weak and the nMAG preferes to wait until the MN comes closer into the coverage of
the home link. Meanwhile the foreign MIP link may still be used.

Please not that this should also work for the opposite HO, i.e. for a HO from PMIP home link to a foreign MIP
link, at least for approach b).

Regards,

Oliver

>-----Ursprüngliche Nachricht-----
>Von: netlmm-bounces <at> ietf.org [mailto:netlmm-bounces <at> ietf.org] 
>Im Auftrag von Kilian Weniger
>Gesendet: Mittwoch, 5. November 2008 16:00
>An: Giaretta, Gerardo; Kilian Weniger; Basavaraj Patil; Suresh Krishnan
>Cc: Christian Vogt; Mohana Jeyatharan; NETLMM Mailing List
>Betreff: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
>
>Hi Gerardo, 
>
>> > I was referring to the specific scenario described in 
>section 5.3 of 
>> > draft-tsirtsis, where the MN wants to delay the direction
>> of traffic to
>> > the interface that attaches to the home link. This scenario
>> was brought
>> > up by others as an argument against the approach to do forwarding 
>> > according to latest received registration. I have not yet
>> received an
>> > answer why this scenario is needed.
>> > 
>> 
>> This is the usual procedure for vertical handovers. Since the MN is 
>> dual radio it can connect to one access, prepare the access 
>in advance 
>> and then move the data later whenever it wants. In this way 
>you don't 
>> need FMIPv6 or other optimizations.
>
>So you say that this feature is needed to improve handover performance?
>I wouldn't agree to that. 
>
>Even with approach b) the MN can send/receive data via the 
>first interface while the second interface sets up the radio 
>bearer. The traffic is redirected to the second interface once 
>the attach procedure is complete and the PBU reaches the LMA. 
>So in dual radio case, the handover performance of approach b) 
>should not be worse than that of approach a). In single radio 
>case, approach b) is obviously better than approach a) (i.e., 
>1 RTT lower handover delay), as already discussed.
>
>Actually, a vertical foreign-home handover with approach b) 
>has same handover performance than a vertical PMIP handover.
>
>> 
>> The main point you don't get is that technically from a MN point of 
>> view this is not about MIP-PMIP handovers. This is about a MIP 
>> handover to a home link which happens to be a PMIP domain 
>(and this is 
>> transparent to the MN). Therefore everything which works in a normal 
>> MIP handover must work also in this scenario.
>
>A normal MIP handover works with approach b). So far, only two 
>special scenarios were brought up as issues:
>1) the MN wants to delay the redirection of traffic by some 
>amount of time after a vertical handover from foreign to home 
>link by sending a delayed BU de-reg. I still have not seen a 
>convincing answer why this is important to support. This is 
>not specified in RFC3775 or anywhere else and PMIP does not 
>support it either. If PMIP is extended to support it, approach 
>b) supports it as well.
>2) MN has multiple interfaces up and uses foreign link 
>interface for sending/receiving traffic. MN does horizontal 
>handover within the home link, but doesn't want to redirect 
>the traffic to this interface. This can be solved by 
>considering HI flags in PBU and/or with flow filters.
>
>
>Kilian
>
>> 
>> Gerardo
>> 
>> > If the MN wants to use both home and foreign interface for traffic 
>> > simultaneously,  it can do so by using H-flag in BU de-reg,
>> as specified
>> > in MCoA draft. That also works for approach b).
>> > 
>> > >
>> > > >
>> > > > What I don't understand are two things:
>> > > > 1.) why this scenario is essential to be supported.
>> > >
>> > > Because the MN intends to maintain both BCEs and have 
>connectivity 
>> > > via both interfaces.
>> > >
>> > > > 2.) why is it only essential for MIPv6 handover scenarios
>> > > and not for
>> > > > PMIPv6 (i.e., MAG1->MAG2) handover scenarios? Because
>> > > PMIPv6 does not
>> > > > support this scenario.
>> > > >
>> > > > Anyway, this scenario can be supported with approach b) in
>> > > interaction
>> > > > scenarios or even in pure PMIP scenarios, when PMIP is
>> > > extended to allow
>> > > > the MN to signal during attach that PBU shall be delayed by
>> > > some time or
>> > > > until MN explicitly triggers it.
>> > >
>> > > At least there is no way for the MN to explicitly 
>trigger the PBU, 
>> > > right? At least not with the current specs and scope of Netlmm. 
>> > > What is the reason to delay the PBU?
>> > 
>> > Exactly, in case of PMIP handovers this is currently not
>> supported. So
>> > why do some people think that this scenario is essential to
>> be supported
>> > specifically for the MIP->PMIP handover case?
>> > 
>> > Kilian
>> > 
>> > >
>> > > -Raj
>> > >
>> > > >
>> > > > Kilian
>> > > >
>> > > >
>> > > >
>> > > > Panasonic R&D Center Germany GmbH
>> > > > 63225 Langen, Hessen, Germany
>> > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas 
>> > > > Micke
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > netlmm mailing list
>> > > > netlmm <at> ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/netlmm
>> > >
>> > >
>> > >
>> > 
>> > 
>> > Panasonic R&D Center Germany GmbH
>> > 63225 Langen, Hessen, Germany
>> > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: 
>Thomas Micke
>> > 
>> > 
>> > _______________________________________________
>> > netlmm mailing list
>> > netlmm <at> ietf.org
>> > https://www.ietf.org/mailman/listinfo/netlmm
>> 
>> 
>
>
>Panasonic R&D Center Germany GmbH
>63225 Langen, Hessen, Germany
>Reg: AG Offenbach (Hessen) HRB 33974
>Managing Director: Thomas Micke
>
>
>_______________________________________________
>netlmm mailing list
>netlmm <at> ietf.org
>https://www.ietf.org/mailman/listinfo/netlmm
>

Re: comments on draft-ietf-mipshop-pfmipv6-00

Hi Fan,

Thanks for your questions. I think the draft needs more text to make the
procedures clearer. Please see inline:

fan zhao wrote:
> Hi,
> 
> I have some comments on this draft.
> 
> 1) Section 4.1
> "  (c)  The PAR sends the HI to the NAR.  The HI message MUST include
>         the MN ID and SHOULD include the MN-HoA, the MN-HNP, the MN-IID
>         and the address of the LMA that is currently serving the MN.
> ...
> 
>    (e)  The NAR requests the PAR to buffer or forward packets by setting
>         U or F flags in the HI message, respectively."
> 
>>From the figure, it seems to me that at step (e), a set of
> new HI/Hack messages are exchanged for packet forwarding
> while step (c) and (d) are for context transfer. Do I understand correctly?
> Can (e) be combined with (c) and (d)?

Yes, they can be combined if the context transfer and the tunnel setup
for packet forwarding happen at the same time. If these two procedures
are performed at different times, additional HI/HAck messages are
exchanged. So, step (e) is not mandatory, and this should be described
more clearly.

> Also It seems to me that (e) should be "The PAR requests the NAR ..
> in the HI .."
> 
> 2) "The timing of the context transfer and that of packet forwarding may
>    be different.  Thus, a new flag 'F' and the Option Code values for it
>    in the HI message are defined to request forwarding.  To request
>    buffering, 'U' flag has already been defined in [RFC5268].  If the
>    PAR receives the HI message with F flag set and the Option Code value
>    being 2, it starts forwarding packets for the MN."
> 
> It seems to me that it is the PAR that sends the HI message and receives
> the Hack message.

The arrows go in both ways, which means that either may request
buffering and/or forwarding. I admit that this should also be reflected
to the text. In general, however, the NAR newly allocates resources for
the MN, so during that time, the NAR asks the PAR to buffer the packets
and when the NAR is ready to accept those packets, it asks the PAR to
forward them.

> 3) The case when the target access network supports MIP instead of PMIP
> is described. I also submitted a draft,
> http://tools.ietf.org/id/draft-zhao-mipshop-fmip-pfmip-00.txt.
> Comments are very appreciated.

I think this is workable, but I have one question: can the MN configure
its NCoA in the previous network, where the PMIP is used?

Regards,
--

-- 
Hidetoshi

> Thanks.
> 
> Sincerely,
> fan
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
> 
> 
> 

Agenda for IETF 73

Hello,

Here is the agenda for the MIPSHOP meeting in Minneapolis. There still
might be changes to the agenda.

http://www.ietf.org/proceedings/08nov/agenda/mipshop.txt

Vijay

Re: comments on draft-ietf-mipshop-pfmipv6-00

Hi Yokota-san,

Thanks for your reply. Please see below.

On Thu, Nov 6, 2008 at 9:48 PM, Hidetoshi Yokota <yokota <at> kddilabs.jp> wrote:
> Hi Fan,
>
> Thanks for your questions. I think the draft needs more text to make the
> procedures clearer. Please see inline:
>
> fan zhao wrote:
>> Hi,
>>
>> I have some comments on this draft.
>>
>> 1) Section 4.1
>> "  (c)  The PAR sends the HI to the NAR.  The HI message MUST include
>>         the MN ID and SHOULD include the MN-HoA, the MN-HNP, the MN-IID
>>         and the address of the LMA that is currently serving the MN.
>> ...
>>
>>    (e)  The NAR requests the PAR to buffer or forward packets by setting
>>         U or F flags in the HI message, respectively."
>>
>>>From the figure, it seems to me that at step (e), a set of
>> new HI/Hack messages are exchanged for packet forwarding
>> while step (c) and (d) are for context transfer. Do I understand correctly?
>> Can (e) be combined with (c) and (d)?
>
> Yes, they can be combined if the context transfer and the tunnel setup
> for packet forwarding happen at the same time. If these two procedures
> are performed at different times, additional HI/HAck messages are
> exchanged. So, step (e) is not mandatory, and this should be described
> more clearly.
OK.

>
>> Also It seems to me that (e) should be "The PAR requests the NAR ..
>> in the HI .."
>>
>> 2) "The timing of the context transfer and that of packet forwarding may
>>    be different.  Thus, a new flag 'F' and the Option Code values for it
>>    in the HI message are defined to request forwarding.  To request
>>    buffering, 'U' flag has already been defined in [RFC5268].  If the
>>    PAR receives the HI message with F flag set and the Option Code value
>>    being 2, it starts forwarding packets for the MN."
>>
>> It seems to me that it is the PAR that sends the HI message and receives
>> the Hack message.
>
> The arrows go in both ways, which means that either may request
> buffering and/or forwarding. I admit that this should also be reflected
> to the text. In general, however, the NAR newly allocates resources for
> the MN, so during that time, the NAR asks the PAR to buffer the packets
> and when the NAR is ready to accept those packets, it asks the PAR to
> forward them.
I see your point. Maybe you can clarify the behaviors of the NAR and the PAR
in the next version.

>
>> 3) The case when the target access network supports MIP instead of PMIP
>> is described. I also submitted a draft,
>> http://tools.ietf.org/id/draft-zhao-mipshop-fmip-pfmip-00.txt.
>> Comments are very appreciated.
>
> I think this is workable, but I have one question: can the MN configure
> its NCoA in the previous network, where the PMIP is used?
I think it is doable as long as the MN obtains address configuration information
on the previous network where PMIP is used. In the FMIP protocol, this
is done by RtSolPr/PrRtAdv; maybe some access specific messages for the PMIP
domain can be used. On the other hand, if the PMIP is used in the target
access network, the home address should be used.

Sincerely,
fan

>
> Regards,
> --
> Hidetoshi
>
>> Thanks.
>>
>> Sincerely,
>> fan
>> _______________________________________________
>> Mipshop mailing list
>> Mipshop <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/mipshop
>>
>>
>>
>
>