Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 22 Apr 2008 09:15:49 -0700 (PDT)

David,
  Receiving FBU from NAR to establish the tunnel with the NAR for PAR was how we had it in RFC 4067. Why should we need Hi/Hack exchange which is technically wrong because clearly the context is totally different than the predictive HO for which Hi/Ack was designed?

Regards,

Behcet

----- Original Message ----
From: David Cypher <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Rajeev Koodli <[email-masked]>
Cc: [email-masked]
Sent: Friday, April 18, 2008 3:09:09 PM
Subject: Re: [Mipshop] I-D  Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

At 03:48 PM 4/18/2008, Behcet Sarikaya wrote:
This is the text from6.2.1:

The Handover Initiate (HI) is an ICMPv6 message sent by an Access
   Router (typically PAR) to another Access Router (typically
NAR) to
   initiate the process of a MN's
handover.In reactive modethe handover is already finished. How come PAR would send a HANDOVERINITIATE message to NAR? 

There might still be data packets arriving at the PAR for the mobilenode.  In reactive mode the MN sends the FBU to the PAR via the NARto tell the PAR to establish the tunnel with the NAR using the HI/Ackexchange.  The result is the same whether predictive of reactive,data arriving at the PAR after the mobile node has connected to the NARand prior to the mobile node sending a BU to its home agent.  If themobile node dose not want to receive packets in transit prior to the homeagent receiving the BU, then there is no need to specify a FMIP reactivemode.  Thus this is the reason for reactive mode.

David Cypher

Clearly the purpose of theexchange in Fig. 3 is context transfer and it should be made explicitONLY in the extension document that needs it.

The basics of protocol engineering requires us to not to repeat anexchange like Hi/HAck anywhere we like.

Regards,

Behcet

----- Original Message ----
From: Rajeev Koodli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Friday, April 18, 2008 11:33:43 AM
Subject: Re: [Mipshop] I-DAction:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

Hi Behcet,

On Fri, Apr 18, 2008 at 8:30 AM, Behcet Sarikaya<[email-masked]> wrote:
Hi Rajeev,
  The concern I raised on Fig. 3 in my mail on April 1st (it wasnot April fool's joke though ) still remains valid in Version 7.

:-)
 
  As I mentioned this change was first made in Version 2 rightafter July 2007 Chicago IETF meeting and it has some links withdraft-yokota-mipshop-pfmipv6.

This is not accurate. The HI/Hack exchange in the reactive case has beenaround since RFC 4068.
See " When the source IP address of the FBU is not PCoA, i.e., theFBU is sent from the NAR's link, the HI message MUST have a Code value of1; see Section 6.2.1." in paragraphthat starts with "After a PrRtAdv message is processed.." inSection 4, RFC 4068. Section 6.2.1 discusses using Code 1 for such aHI/HAck exchange.

Figure 3 is only making this illustrative.

Thanks,

-Rajeev

  Please remove this change! The extensions of FMIP can definenew messages if needed.

Regards,

Behcet

----- Original Message ----
From:"
[email-masked]"<[email-masked]>
To:[email-masked]
Cc: [email-masked]
Sent: Thursday, April 17, 2008 8:15:02 AM
Subject: [Mipshop] I-DAction:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

A New Internet-Draft is available from the on-line Internet-Draftsdirectories.
This draft is a work item of the Mobility for IP: Performance,Signaling and Handoff Optimization Working Group of the IETF.

   Title          : Mobile IPv6Fast Handovers
    Author(s)      : R.Koodli
    Filename       : draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
   Pages          : 48
   Date            :2008-04-17

Mobile IPv6 enables a Mobile Node to maintain its connectivity tothe
Internet when moving from one Access Router to another, aprocess
referred to as handover.  During handover, there is a periodduring
which the Mobile Node is unable to send or receive packets becauseof
link switching delay and IP protocol operations.  This"handover
latency" resulting from standard Mobile IPv6 procedures,namely
movement detection, new Care of Address configuration, andBinding
Update, is often unacceptable to real-time traffic such as Voiceover
IP.  Reducing the handover latency could be beneficial tonon-real-
time, throughput-sensitive applications as well.  Thisdocument
specifies a protocol to improve handover latency due to MobileIPv6
procedures.  This document does not address improving thelink
switching latency.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.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 ofthe
Internet-Draft.

_______________________________________________
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: David Cypher <[email-masked]>
Date: Tue, 22 Apr 2008 15:13:31 -0400

Behcet,

     Okay there appears to be a disconnect in this thread.
The subject refers to
Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt,
which is the update to RFC 4068 Fast handover Mobile IP

This talk about context switching appears to relate to the FMIP/PMIP 
interactions draft.

Or are you stating that with things like those being defined in the 
draft IEEE 802.21 that these sorts of functions are already covered 
and do not need to be repeated in the new revised RFC 4068?

Or are you just arguing over the use of term/naming of handover initiate?

Or have I missed something else?

David Cypher
==================
At 12:15 PM 4/22/2008, Behcet Sarikaya wrote:
>David,
>   Receiving FBU from NAR to establish the tunnel with the NAR for 
> PAR was how we had it in RFC 4067. Why should we need Hi/Hack 
> exchange which is technically wrong because clearly the context is 
> totally different than the predictive HO for which Hi/Ack was designed?

You mean RFC 4068, not RFC 4067, correct?
Let's start with MIP, which permits nodes to remain reachable while 
moving around the internet.
If a mobile node (MN) moves from one access router (AR) to another 
AR, the mobile node's "handover (HO)" is not complete until the BU / 
BAck exchange between the mobile node and its home agent because the 
mobile node is not reachable until then.   Packets prior to the BU 
arriving at the HA are sent by the HA to the old AR and will be 
dropped (i.e., lost), since the mobile node is at a new AR.   FMIP 
comes along with the goal of having the old AR forward packets for 
the mobile node to the new AR (where the mobile node now resides) 
prior to the  BU/BAck exchange between the mobile node and the home 
agent.  Handover is not complete with the FMIP 
exchanges.  Reachability is reestablished with the FMIP 
exhanges.  Handover is complete only after the BU/Back exchange 
between the MN and the HA.  FMIP is a temporary or intermediate step 
in the overall handover / reachability of the mobile node.  The 
reactive case of FMIP still needs the PAR to send the HI to the NAR 
to establish the tunnel to forward packets.  The NAR needs to accept 
the HI by sending the Hack.  There is no requirement that the NAR 
support FMIP just because the PAR does or vica versa.  In that case 
FMIP fails to decrease the delay for the mobile node moving from one 
AR to another.

If you are arguing the term, handover.
In predictive mode FMIP, the HI/Hack exchange is "handing over" the 
arriving packets to the PAR to the NAR and handing over the mobile 
node's current care of address to the NAR's sanctioned care-of-address.

In reactive mode FMIP, the HI/Hack exchange is still "handing over" 
the arriving packets to the PAR to the NAR and handing over the 
mobile node's old care of address to the NAR's new sanctioned care-of-address.

In either case the HI/Hack exchange is needed for the tunnel establishment.

Are you suggesting that in this new version of FMIP the HI/HAck 
exchange is not needed?
If so, I would ask what method is replacing its previous functionality?

If you are arguing the term, handover, as only a link-layer term
Then the Handover Initiate message and Handover Acknowledge message 
are totally confusing as a IP layer messages.
But then scanning for access points (APs) when signal strength is low 
in 802.11 might initiate handover and it might not.  Proxy Router 
Solicitation message could be considered initiating handover 
since  the information it carries can have an impact on the decision 
to handover between APs.

If handover is only a link-layer term, then what term would one use 
to describe what MIP does?  what FMIP does?  what HMIP does? and what 
PMIP may do?

What are the triggers (both upper and lower) for a link-layer handover?

If you are arguing over the term, "initiate the mobile node's 
handover" under the description of the HI message. Even though the 
mobile node is now attached to a new AR, handover may not have even begun.
Case 1)
With MIP handover begins with the movement detection that the mobile 
node is attached to a new AR.  Handover completes when the BU/BAck 
exchange is completed.
Case 2)
With FMIP handover as defined in MIP still holds.  Therefore anything 
that FMIP does prior to this is initiating handover.  Thus reactive 
mode and predictive mode are both happening before MIP handover and 
therefore are both initiating handover.

Layer independence, No?

I see no extra HI/HAck exchange.  I only see that the current 
exchanges are necessary.

>>This is the text from 6.2.1:
>>
>>
>>handover.In reactive mode the handover is already finished. How 
>>come PAR would send a HANDOVER INITIATE message to NAR?
>
>There might still be data packets arriving at the PAR for the mobile 
>node.  In reactive mode the MN sends the FBU to the PAR via the NAR 
>to tell the PAR to establish the tunnel with the NAR using the 
>HI/Ack exchange.  The result is the same whether predictive of 
>reactive, data arriving at the PAR after the mobile node has 
>connected to the NAR and prior to the mobile node sending a BU to 
>its home agent.  If the mobile node dose not want to receive packets 
>in transit prior to the home agent receiving the BU, then there is 
>no need to specify a FMIP reactive mode.  Thus this is the reason 
>for reactive mode.
>
>David Cypher
>
>>Clearly the purpose of the exchange in Fig. 3 is context transfer 
>>and it should be made explicit ONLY in the extension document that needs it.
>>
>>On Fri, Apr 18, 2008 at 8:30 AM, Behcet Sarikaya 
>><<mailto:[email-masked]>[email-masked] > wrote:
>>Hi Rajeev,
>>   The concern I raised on Fig. 3 in my mail on April 1st (it was 
>> not April fool's joke though ) still remains valid in Version 7.
>>
>>
>>:-)
>>
>>   As I mentioned this change was first made in Version 2 right 
>> after July 2007 Chicago IETF meeting and it has some links with 
>> draft-yokota-mipshop-pfmipv6.
>>
>>
>>This is not accurate. The HI/Hack exchange in the reactive case has 
>>been around since RFC 4068.
>>See " When the source IP address of the FBU is not PCoA, i.e., the 
>>FBU is sent from the NAR's link, the HI message MUST have a Code 
>>value of 1; see Section 6.2.1." in paragraph that starts with 
>>"After a PrRtAdv message is processed.." in Section 4, RFC 4068. 
>>Section 6.2.1 discusses using Code 1 for such a HI/HAck exchange.
>>
>>   Please remove this change! The extensions of FMIP can define new 
>> messages if needed.
>>
>>Regards,
>>Behcet
>>From: "<mailto:[email-masked]> [email-masked]" 
>><<mailto:[email-masked]>[email-masked] >
>>To: <mailto:[email-masked]>[email-masked]
>>Cc: <mailto:[email-masked]>[email-masked]
>>Subject: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
>>This draft is a work item of the Mobility for IP: Performance, 
>>Signaling and Handoff Optimization Working Group of the IETF.
>>
>>     Title          : Mobile IPv6 Fast Handovers
>>     Author(s)      : R. Koodli
>>     Date            : 2008-04-17
>>Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
>>Internet when moving from one Access Router to another, a process
>>referred to as handover.  During handover, there is a period during
>>which the Mobile Node is unable to send or receive packets because of
>>link switching delay and IP protocol operations.  This "handover
>>latency" resulting from standard Mobile IPv6 procedures, namely
>>movement detection, new Care of Address configuration, and Binding
>>Update, is often unacceptable to real-time traffic such as Voice over
>>IP.  Reducing the handover latency could be beneficial to non-real-
>>time, throughput-sensitive applications as well.  This document
>>specifies a protocol to improve handover latency due to Mobile IPv6
>>procedures.  This document does not address improving the link
>>switching latency.
>><http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt>http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt 
>>
>><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>
>>
>>
>><https://www.ietf.org/mailman/listinfo/mipshop>https://www.ietf.org/mailman/listinfo/mipshop