Subject: [Mipshop] transient binding draft update

From: Marco Liebsch <[email-masked]>
Date: Tue, 01 Sep 2009 10:56:09 +0200

Dear all,

please find below a list of changes for the transient binding draft update.
Thanks for all comments. We'll post the update in a next step.

marco

* some editorial revision for clarification to address various comments

* removed access-specific forwarding from the Abstract

   This document specifies a mechanism which enhances Proxy Mobile IPv6
   protocol signaling to support the creation of a transient binding
   cache entry which is used to optimize the performance of dual radio
   handover, as well as single radio handover. ...

* revised text about Local Information in Introduction:
  
   MAGs can establish settings of a transient binding on the
   LMA by means of signaling.  An LMA can establish or change the
   settings of a transient binding according to events, such as a
   timeout, a change of the radio technology due to a handover or a
   completed set up of a radio bearer or configuration of an MN's IP
   address .  Such event may also be triggered by other protocols, e.g.
   Diameter messages from the AAA infrastructure.  

* revise title of section 3.3 Demand for a common solution -> Need for
  a common solution

* Activation of a transient BCE --> Revised to avoid "activation",
  but write "turn a transient BCE into an active BCE".

* clarification about in which detail the "LMA must know the access technology".
  issues resolved on the list, no modification in the draft

* removed section about MN operation

* added example about configuration data "link local address" in section 3.2.1

   "...delaying the PBU, which is sent from the new MAG to the LMA after the
   MN's new interface has attached to the network, is not possible, as
   the new MAG retrieves configuration data for the MN from the LMA in
   the PBA, such as the MN's HNP and the link local address to be used
   at the MAG."

* added text about the need of radio access forwarding to benefit from
  transient binding in a single radio handover and added reference to
  Appendix Use Cases

   ... Such downlink forwarding characteristic is
   denoted as 'Late path switch' (L).  Whereas during a dual radio
   handover an MN can receive downlink packets via its previous
   interface, during a single radio handover the late path switch
   supports re-using available forwarding mechanisms in the radio access
   network.  Appendix A describes both use cases.

* revised Intro to avoid confusion with "premature" forwarding of packets

  old text:

  ".. Address configuration as well
   as possible access technology specific radio bearer setup may delay
   the complete set up of the mobile node's new interface before it is
   ready to receive or send data packets.  In case the LMA prematurely
   forwards packets towards the mobile node's new interface, some
   packets may get lost or experience major packet delay. 

  new text:

  "... Address configuration as well
   as possible access technology specific radio bearer setup may delay
   the complete set up of the mobile node's new interface before it is
   ready to receive or send data packets.  In case the LMA performs
   operation according to [RFC5213] and forwards packets to the mobile
   node's new interface after the reception of the PBU from the nMAG,
   some packets may get lost or experience major packet delay. "

*  Added note about static implementation specific approach and reference
   to Appendix B to the Introduction.

   "..Some implementation specific solutions, such as static configuration
   and introducing some delays, may help to reduce some issues addressed
   in this draft, which is discussed in Appendix B.  A dynamic solution
   by means of the proposed protocol operation helps to optimize the
   performance for a variety of handover situations and different radio
   characteristics."

* added examples from 3GPP to 3.2.1 where e.g. radio bearer setup etc. is being
  performed after PBU/PBA. 

  "...Both scenarios as depicted above can be found in [TS23.402], where
   the protocol sequence during a handover between different accesses
   considers a PMIPv6 handshake between the nMAG and the LMA to retrieve
   the MN's HNP before access specific operations can be completed."

* Made the use of DAD a "may" in the problem statement 

* revised appendix B.3, removed "secure and stable handover..."

   ".... Only additional signaling as provided by this document provides
   the information that late
   switching is applicable and enables a synchronization of the handover
   sequence, .i.e. the switching is adapted both to the finalization of
   the link between mobile terminal and nMAG and to the release of the
   link between mobile terminal and pMAG, whatever comes first.  Stable
   handover performance is achieved using protected PMIPv6 signaling as
   per [RFC5213]."

* revised appendix B.2, revised last paragraph about static timer
  based actication

  "...In order to handle all handoff circumstances, the activation mechanism
   as described in this draft is preferable over a statically configured
   timer and it would dynamically help in ending the late forwarding from
   the pMAG based on a protected signaling from the pMAG."

* revised last two paragraphs of appendix B.1

   "...Allowing the LMA to forward the received uplink traffic from the nMAG
   to the Internet while the MN BCE points to the pCoA hosted at the
   pMAG is a violation of all mobility protocols which require secure
   signaling exchange between the nMAG and the LMA before forwarding
   such traffic to the Internet.  Otherwise, the LMA will be modifying
   the mobile node's routing entry based on an unsecured data traffic
   packet coming from the nMAG.

   Therefore, this case can not be addressed by any statically
   configured information on the LMA.  On the contrary, a secure
   signaling using Transient Binding option as detailed in this draft is
   required to create a transient state for the mobile node BCE at the
   LMA.  This transient state will allow a temporary routing entry of
   the mobile node to point to the nMAG Proxy-CoA."

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 3 Sep 2009 15:25:15 -0400

Hi Marco,

Thanks for taking input into account. I have a clarification on the
following:

*  Added note about static implementation specific approach and
reference
   to Appendix B to the Introduction.

   "..Some implementation specific solutions, such as static
configuration

What do you mean by "..introducing some delays,.." in the first
sentence? 
I can think of buffering, and if you mean the same, could you reword it?
I also suggest a slight revision of the statement. Something like:

"..Some implementation specific solutions, such as static configuration
and buffering, can help to address some of the issues identified in this
draft,.."

Regards,

-Rajeev

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marco Liebsch
> Sent: Tuesday, September 01, 2009 1:56 AM
> To: Mipshop
> Subject: [Mipshop] transient binding draft update
> 
> Dear all,
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 4 Sep 2009 01:54:41 -0400

Hi Marco,

>    performance for a variety of handover situations and different radio

Both "static configuration" and "some delays" are vague. Can we replace the
above with the following?

   The problem that the transient binding cache mechanism is trying to
   address can also be achieved through implementation-specific mechanisms
   on the LMA, such a configuration on the LMA to accept uplink packets
   both from the pMAG and the nMAG during a handover and through buffering
   at the nMAG. However, dynamic solutions by means of the proposed
   extension in this document is needed to optimize the performance for
   a variety of handover situations and different radio characteristics.
   See Appendix B for a more detailed discussion on this.

>    packet coming from the nMAG.

The "static configuration" at the LMA actually starts accepting uplink
packets from the nMAG only after receiving a PBU from nMAG. What the "static
configuration" enables is for the LMA to receive uplink packets from the
pMAG for a short duration even through the BCE points to the nMAG. So can we
re-word the above accordingly?

I won't have email access until next Wednesday. If you agree with the above
two changes, please go ahead and submit a revised draft.

Vijay

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 4 Sep 2009 03:17:41 -0500

> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: Friday, September 04, 2009 12:55 AM
> To: Marco Liebsch; Mipshop
> Subject: Re: [Mipshop] transient binding draft update
> 
> Hi Marco,
> 
> Both "static configuration" and "some delays" are vague. Can 
> we replace the above with the following?
> 
>    at the nMAG. 
[Ahmad]
I am sure Marco will answer to this too, but let me jump in for a
second. This is not correct. It seems to me that there is something
missing in here! Probably misunderstanding of the usecases that tBCE
draft is trying to address. Please see more comments below.

> However, dynamic solutions by means of the proposed
> The "static configuration" at the LMA actually starts 
> accepting uplink packets from the nMAG only after receiving a 
> PBU from nMAG. 
[Ahmad]
This actually may explain why you insist on the text above under the
previous paragraph. It is very interesting! First of all, is this a new
usecase that you would like the transient BCE draft to address?! IMO, it
is a little late but we can consider that if we understand the usecase. 

Though, it will be helpful, if you take us through the details of this
usecase and what you are trying to optimize and achieve by using the
tBCE in here. Also, whether it is a new addition on top of RFC5213?

> What the "static configuration" enables is for 
> the LMA to receive uplink packets from the pMAG for a short 
> duration even through the BCE points to the nMAG. So can we 
> I won't have email access until next Wednesday. If you agree 
> with the above two changes, please go ahead and submit a 
> revised draft.
> 
> Vijay
> 
> 
> >

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 04 Sep 2009 10:37:52 +0200

Hi Vijay,

>    See Appendix B for a more detailed discussion on this.
I am surprised that you propose the same text as two weeks ago, which we 
commented on
and proposed alternative text. I think we clarified why the above text 
is not appropriate.
Very difficult to proceed..

> re-word the above accordingly?
Ahmad replied on that already.
> two changes, please go ahead and submit a revised draft.
No, we do not agree. Not sure if we can proceed if we're lost in cycle mode.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 04 Sep 2009 11:11:45 +0200

Hi Rajeev,

> What do you mean by "..introducing some delays,.." in the first
yes, maybe not precise, but I think your proposal below for a revision 
seems ok

> and buffering, can help to address some of the issues identified in this
Looks ok.

marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 4 Sep 2009 12:20:52 -0400

Hi,

>>commented on and proposed alternative text. I think we clarified why the above text
>> is not appropriate.

Isn't the text above saying the same thing? To me, it's clear.

>> Ahmad replied on that already.

Agree with Vijay. I assume we will have reference to the ID I mentioned that first outlined this issue?
 
Regards,
 
-Rajeev

marco

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 07 Sep 2009 11:36:22 +0200

Hi Rajeev,

> Isn't the text above saying the same thing? To me, it's clear.
Since both mean the same to you, we adopted the modification you
proposed in your last mail and consider this issue closed now.

Thanks,
marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 08 Sep 2009 10:12:20 +0200

Hi Vijay,

let me try to clarify about the last open issue below.

> re-word the above accordingly?
I think this is simply a misunderstanding. B1 and B2 describe different 
situations how uplink traffic
from pMAG and nMAG is handled at the LMA during a handover.
The first part of your comment describes standard behaviour and the LMA 
accepts uplink packets
from the nMAG after a PBU/PBA handshake. This is not different for 
transient BCE. The second part
of your comment fits more into B2, as it describes how to handle uplink 
packets from the pMAG.
Here, the text in the draft sais that the LMA does not forward uplink 
packets from the pMAG as
soon as the nMAG is registered as proxy CoA in the MN's BCE. This is 
what you could
address with implementation or you solve it dynamically and implicitly 
with a transient BCE.

So, I think both of your comments are valid, but already covered by the 
description in B1 and B2.
Rewording according to your proposal is in that case not appropriate, as 
the proposed text does
not fit into B1, but B2, which covers the statement already. If you this 
we need to revise a
sentence to make this clearer, please point it.

I hope we can fix this small thing soon to proceed.

Thanks,
marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 8 Sep 2009 12:18:54 -0400

Hi Marco,

> Since both mean the same to you, we adopted the modification 
> you proposed in your last mail and consider this issue closed now.

I prefer Vijay's text; it's more clear (that's what I meant above).

Thanks,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 10 Sep 2009 16:43:21 -0700

Hi Ahmad,

> tBCE in here. Also, whether it is a new addition on top of RFC5213?

There is no new use case. The use case, IMO, has always been that the LMA
should accept uplink packets both from the pMAG and the nMAG during a
handover for a certain amount of time. How you achieve this can be
different.

In the transient binding cache mechanism, there is an explicit signal from
the nMAG to the LMA to accept uplink packets from the nMAG even though the
BCE points to the pMAG. A subsequent PBU message from the nMAG updates the
binding cache entry to point to the nMAG. After that the LMA stops accepting
the uplink packets from the pMAG.

In the static configuration case, the PBU from the nMAG would update the
binding cache entry at the LMA immediately with the proxy CoA being set to
the nMAG. But, the LMA would be configured to accept uplink packets from the
pMAG for a short duration (configured on the LMA). When the timer for this
duration expires, the LMA will accept uplink packets only from the nMAG.

So it doesn't matter how you achieve this, the goal is to enable the LMA to
receive uplink packets from both the pMAG and the nMAG for a certain amount
of time during a handover.

Hope this clarifies my earlier email.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 00:13:40 -0500

Hi Vijay,
Thanks for your detailed comments. Please see comments inline.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, September 10, 2009 6:43 PM
> To: Muhanna, Ahmad (RICH1:2H10); Marco Liebsch; Mipshop
> >> The "static configuration" at the LMA actually starts accepting 
> >> uplink packets from the nMAG only after receiving a PBU from nMAG.
> > [Ahmad]
> > previous paragraph. It is very interesting! First of all, is this a 
> > new usecase that you would like the transient BCE draft to 
> address?! 
> > IMO, it is a little late but we can consider that if we 
> understand the usecase.
> > 
> There is no new use case. The use case, IMO, has always been 
> that the LMA should accept uplink packets both from the pMAG 
> and the nMAG during a handover for a certain amount of time. 
> How you achieve this can be different.
> 
> In the transient binding cache mechanism, there is an 
> explicit signal from the nMAG to the LMA to accept uplink 
> packets from the nMAG even though the BCE points to the pMAG. 
> A subsequent PBU message from the nMAG updates the binding 
> cache entry to point to the nMAG. After that the LMA stops 
> accepting the uplink packets from the pMAG.
> 
> In the static configuration case, the PBU from the nMAG would 
> update the binding cache entry at the LMA immediately with 
> the proxy CoA being set to the nMAG. But, the LMA would be 
> configured to accept uplink packets from the pMAG for a short 
> duration (configured on the LMA). When the timer for this 
[Ahmad]
I see what you are saying here. But, usecase 1 is a little different. In
usecase 1, we are not worried about the uplink data traffic from the
pMAG after the 1st PBU with the transient option included. We are
worried about the downlink traffic. In other words, in usecase 1, if we
allow the LMA to update the BCE with nMAG pCoA immediately, the LMA will
start forward downlink traffic to the nMAG immediately and that is a
problem for usecase 1. Because, the link between the LMA all the way to
the base station in the downlink direction is NOT setup yet.

In usecase 1, IMO, 3GPP folks did an excellent job designing a very
reliable well thought handover mechanism.
1. When the MN moves to the target access network (nAN) with an active
data session, the MN does not need to worry about uplink traffic nor
downlink and it continues to send uplink traffic as normal. That is why
as soon as the MN moves to the target access network, the uplink
direction of the link from the base station all the way to the LMA is
ready. 

2. In order to avoid any packet loss in the downlink direction, all
downlink traffic continues to go to the pMAG to the pAN and from the pAN
to the nAN and then to the MN.

3. while the data traffic is moving as in 1 and 2, the network is
working on setting up the link for the downlink direction from the LMA
all the way to the nAN. 

4. When the link in the downlink direction is complete and ready, the
LMA switch the tunnel completely to point to the nMAG and nAN.

5. After the LMA switches the tunnel completely, there is no uplink
traffic in-flight to worry about from the pMAG because the uplink
traffic has been going through the nMAG directly to the LMA for
sometime. Only, in-flight downlink traffic which is sent to the pMAG.
But, in that case the pMAG continues to forward that to the pAN, and pAN
to the nAN to the MN.

It is a very smooth mechanism! :)

> 
> So it doesn't matter how you achieve this, the goal is to 
> enable the LMA to receive uplink packets from both the pMAG 
> and the nMAG for a certain amount of time during a handover.
> 
[Ahmad]
Thanks! it does. Please see comments above.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 08:27:39 -0500

Hello Vijay,

After this clarification, may I ask what is the next step?

Thanks in advance!

Regards,
Ahmad

> [mailto:[email-masked]] On Behalf Of Muhanna, Ahmad 
> (RICH1:2H10)
> Sent: Friday, September 11, 2009 12:14 AM
> To: Vijay Devarapalli; Marco Liebsch; Mipshop
> > There is no new use case. The use case, IMO, has always 
> been that the 
> > LMA should accept uplink packets both from the pMAG and the nMAG 
> > during a handover for a certain amount of time.
> explicit signal 
> > from the nMAG to the LMA to accept uplink packets from the 
> nMAG even 
> > though the BCE points to the pMAG.
> cache entry 
> > to point to the nMAG. After that the LMA stops accepting the uplink 
> > packets from the pMAG.
> > 
> > In the static configuration case, the PBU from the nMAG 
> would update 
> > the binding cache entry at the LMA immediately with the proxy CoA 
> > being set to the nMAG. But, the LMA would be configured to accept 
> > uplink packets from the pMAG for a short duration 
> (configured on the 
> > LMA). When the timer for this duration expires, the LMA will accept 
> > uplink packets only from the nMAG.
> [Ahmad]
> I see what you are saying here. But, usecase 1 is a little 
> different. In usecase 1, we are not worried about the uplink 
> data traffic from the pMAG after the 1st PBU with the 
> transient option included. We are worried about the downlink 
> traffic. In other words, in usecase 1, if we allow the LMA to 
> update the BCE with nMAG pCoA immediately, the LMA will start 
> forward downlink traffic to the nMAG immediately and that is 
> a problem for usecase 1. Because, the link between the LMA 
> all the way to the base station in the downlink direction is 
> NOT setup yet.
> 
> In usecase 1, IMO, 3GPP folks did an excellent job designing 
> a very reliable well thought handover mechanism.
> 1. When the MN moves to the target access network (nAN) with 
> an active data session, the MN does not need to worry about 
> uplink traffic nor downlink and it continues to send uplink 
> traffic as normal. That is why as soon as the MN moves to the 
> target access network, the uplink direction of the link from 
> the base station all the way to the LMA is ready. 
> 
> 2. In order to avoid any packet loss in the downlink 
> direction, all downlink traffic continues to go to the pMAG 
> to the pAN and from the pAN to the nAN and then to the MN.
> 
> 3. while the data traffic is moving as in 1 and 2, the 
> network is working on setting up the link for the downlink 
> direction from the LMA all the way to the nAN. 
> 
> 4. When the link in the downlink direction is complete and 
> ready, the LMA switch the tunnel completely to point to the 
> nMAG and nAN.
> 
> 5. After the LMA switches the tunnel completely, there is no 
> uplink traffic in-flight to worry about from the pMAG because 
> the uplink traffic has been going through the nMAG directly 
> to the LMA for sometime. Only, in-flight downlink traffic 
> which is sent to the pMAG.
> But, in that case the pMAG continues to forward that to the 
> pAN, and pAN to the nAN to the MN.
> 
> enable the 
> > LMA to receive uplink packets from both the pMAG and the nMAG for a 
> > certain amount of time during a handover.
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Sep 2009 13:25:44 -0700

Hi Marco,

> description in B1 and B2.

I re-read B1 and B2 sections. Yes, B2 covers what I was talking about.

However, I would like to note that in the static configuration on the LMA
scenario that folks have been talking about, there was never an intention to
handle early uplink traffic from the nMAG. It has always been the case that
the uplink traffic from the nMAG is accepted only after the PBU/PBAck
exchange. I think that's where I got confused. The current B1 talks about
allowing early uplink traffic from the nMAG and argues that it is a bad
idea. It was never considered to be part of the static configuration
solution. :)

Its fine with me if we don't make any changes to B1 and B2.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 16 Sep 2009 16:29:44 -0400

Hello,

I looked at the emails, including the latest draft version that Marco
sent to me offline. I would still like to see the following change done.

OLD:

   Some implementation specific solutions, such as static configuration
   and buffering, can help to address some of the issues identified in
   this draft, which is discussed in Appendix B.  A dynamic solution by
   means of the proposed protocol operation helps to optimize the
   performance for a variety of handover situations and different radio
   characteristics.

NEW:

   Some implementation specific solutions, such as static configuration
   on the LMA to accept uplink packets from both the old MAG and the new
   MAG for a short duration during the handover and buffering and the
new
   MAG, can help to address some of the issues identified in
   this draft, which is discussed in Appendix B.  A dynamic solution by
   means of the proposed protocol operation helps to optimize the
   performance for a variety of handover situations and different radio
   characteristics.

No changes required in appendix B.

After this change, we are good to go.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 17:56:54 -0500

Hi Vijay,

The following sentence is very long and I have problem following what it
is trying to say.

   this draft, which is discussed in Appendix B.

Regards,
Ahmad

> Sent: Wednesday, September 16, 2009 3:30 PM
> To: Muhanna, Ahmad (RICH1:2H10); Marco Liebsch
> Cc: [email-masked]
> Subject: RE: [Mipshop] transient binding draft update
> 
> Hello,
> 
> I looked at the emails, including the latest draft version 
> that Marco sent to me offline. I would still like to see the 
> following change done.
> 
> OLD:
> 
>    MAG for a short duration during the handover and buffering 
> and the new

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 16 Sep 2009 19:10:26 -0400

Splitting up the sentence. Here it is again.

   Some implementation specific solutions, such as static configuration
   on the LMA to accept uplink packets from both the old MAG and the new
   MAG for a short duration during the handover and buffering and the
   new MAG, can help to address some of the issues identified in this 
   draft.  A dynamic solution by means of the proposed protocol 
   operation helps to optimize the performance for a variety of handover

   situations and different radio characteristics. This is discussed in 
   more detail in Appendix B.

Vijay

> From: Ahmad Muhanna [mailto:[email-masked]]
> Sent: Wednesday, September 16, 2009 3:57 PM
> To: Vijay Devarapalli; Marco Liebsch
> Cc: [email-masked]