Subject: [Mipshop] Comments on I-D draft-ietf-mipshop-transient-bce-pmipv6-03

From: <[email-masked]>
Date: Mon, 8 Jun 2009 21:57:43 +0200

Hello,

A few comments/questions about rev 3 of the I-D:

- In Sec 3.1 :
"   In some active handover scenarios, it is necessary to prepare the
   handover target MAG prior to the completion of the link layer
   handover procedures.  Packets sent by the LMA to the target MAG
   before the completion of the link layer handover procedure will be
   lost or need to be buffered.
"

  The LMA begins forwarding the DL packets to the nMAG only after
  updating the BCE. Why would the nMAG send the PBU to the LMA if it
  is aware that the MN is unable to receive packets on the DL?
  Assuming the nMAG does not want to wait for the MN to be ready to
  receive IP packets, why would it not just cache the packets until
  the link layer procedures are complete?

  And similary if the MN sends UL packets prior to receiving a PBA,
  the nMAG could cache these packets, right?

UL packets received from the pMAG after the BCE at the LMA has been
updated with the address of the nMAG will be dropped. This is as per
MIP6 design. I dont see a strong reason for processing these
packets. Do you have some data to show the amount of packets lost and
the consequence on applications (I am assuming you are looking at VoIP
in this case)?

- In Sec 3.2 :
"   According to
   the PMIPv6 base protocol [RFC5213], the Access Authentication and the
   Proxy Binding Update (PBU) are triggered in the access network by the
   radio attach procedure, transparently for the MN.  In addition, a
   delay for the MN's new interface's address configuration is not
   considered in the handover procedure.  As a consequence, the
   immediate update of the MN's BCE after the PBU from the MN's nMAG has
   been received at the LMA impacts the performance of the MN's downlink
   traffic as well as its uplink traffic."

  - PMIP6 itself makes no assumptions about when or how access
    authentication is done. It merely states that the PBU can be sent
    by the MAG on the completion of access authentication (use it as a
    trigger). PMIP6 assumes no changes to the host. Hence the delays
    in link configuration cannot be optimized by PMIP6 itself. The
    nMAG needs to make a more informed decision of when to send the
    PBU to optimize the performance.

- The DL issues mentioned in Sec 3.2.1 cannot be solved by PMIP6. If
  the latency to complete the link layer setup when the MN moves is a
  second, there is nothing that PMIP6 itself can do to reduce
  this. And since the MN is unaware of PMIP6 being used, it will go
  through the normal IPv6 procedures. You mention that this is not an
  issue in host based mobility protocols wherein the MN can itself
  decide when to send the BU. Similar logic can be applied here as
  well. The nMAG can decide when to send the PBU as an example.

- The issue associated with obtaining the MNs HNP in order to send the
  HNP in the RA can be resolved by having an IF between the pMAG and
  nMAG. Similar to what has been done in FMIP6 and also proposed in
  PFMIP6. 

- In Sec 3.2.2 :
"However, in a PMIPv6 domain the attachment of the MN on IF2 will
   cause the nMAG to send a PBU to the LMA which will cause the LMA to
   update the BCE for this mobility session of the MN.  According to
   section 5.3.5 of the PMIPv6 base specification [RFC5213], the LMA
   will drop all subsequent packets being forwarded by the MN's pMAG due
   to the updated BCE, which refers now to the nMAG as Proxy-CoA.  Thus
   make-before-break handover is currently not supported by PMIPv6.
"

  With an interface between the pMAG and nMAG the nMAG can avoid
  sending a PBU to the LMA until the MN has switched over.

"Such situation can in particular occur
   when the MN's previous link has a high delay (e.g. a GSM link) and is
   slow compared to the handover target link."

   What is the delay that you are refering to on GSM links (air
   interface or latency in the core)? Is this
   the latency in GPRS networks? And how is this applicable in the
   context of PMIP6? And what is the target links latency that you are
   comparing it with?

I-D states: 
"As a result of using transient BCEs,
   excessive packet buffering at the target MAG during the MN's handover
   process is not necessary
"

  What do you consider as excessive buffering? Buffering can be used
  as a technique to alleviate packet loss. And even with tBCE type of
  approach it is not a given that buffering would not be required.

- Sec 4.7 states:
" One solution is that the MN signals its intent
   for transient bindings to the MAG, either using radio layer protocols
   between MN and MAG or with dedicated IP-based signaling.
"

   I do not believe it is possible to specify link layer specific
   signaling messages. This is out of scope of an IETF I-D. Secondly
   the PMIP6 protocol is intended to work with no modifications needed
   on the host. This change is contrary to that design principle.

In summary I think the basis for specifying tBCE are not entirely
justified. The problem statement lacks the necessary data and is based
on assumptions and speculation. I know some of these issues have been raised
before, but I have not yet seen a satisfactory set of reasons for specifying
such an approach.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 8 Jun 2009 16:26:11 -0500

Hi Raj,
Thanks for the review and comments. Let me try if I can answer some of
your comments and concern.

Regards,
Ahmad

> -----Original Message-----
> Subject: [Mipshop] Comments on I-D 
> draft-ietf-mipshop-transient-bce-pmipv6-03
> 
> 
> Hello,
> 
[Ahmad]
I assume that your question here about the PBU with the TBO?
That is why the MAG is sending the PBU (with TBO) to indicate to the LMA
that only UL traffic can be forwarded to the nMAG pCoA at this point.
So, I do not see any contradiction. The MAG is aware that only UL can be
forwarded from the nMAG pCoA and it uses the PBU to inform the LMA with
this.

>   the link layer procedures are complete?
[Ahmad]
Good question. When active handover is progressing and sensitive data is
exchanged, I believe some type of traffic justify a handover
optimization. Is the point here that you think that handover
optimization is NOT needed and the nMAG can buffer the data without any
negative impact to the quality of the traffic?

>   the nMAG could cache these packets, right?
[Ahmad]
The same point as above:)

> 
> UL packets received from the pMAG after the BCE at the LMA 
> has been updated with the address of the nMAG will be 
> dropped. This is as per
> packets. Do you have some data to show the amount of packets 
> lost and the consequence on applications (I am assuming you 
> are looking at VoIP in this case)?

[Ahmad]
It is exactly that same reason which justify the establishment of a
lateral tunnel between the pMAG and nMAG. If there is no need here, then
I believe there is no need there. In other words, the question comes
back to the same point, do we need a handover optimization in this case
or you think it is not necessary?:)

> In summary I think the basis for specifying tBCE are not 
> entirely justified. The problem statement lacks the necessary 
> data and is based on assumptions and speculation. I know some 
> of these issues have been raised before, but I have not yet 
> seen a satisfactory set of reasons for specifying such an approach.
> 
> -Raj
> 
> 
> 
>  
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>

---

From: <[email-masked]>
Date: Mon, 8 Jun 2009 23:47:12 +0200

Hi Ahmad,

Comments inline

> I assume that your question here about the PBU with the TBO?

No.. I meant a regular PBU.

> forwarded from the nMAG pCoA and it uses the PBU to inform the LMA with

How can the MAG be aware that it can only send UL packets? A MAG can send UL
packets only when it receives a PBA. I don't see a good reason why the MAG
should start sending UL packets before receiving the PBA. A scenario where
you would need to do this would be good to understand. (And lets not do this
simply because GTP does it).

> negative impact to the quality of the traffic?

I don't disagree on the need for optimizing the handover scenario. But is'nt
the ability to buffer the DL packets until the MN can receive packets an
optimization already? Would it not be sufficient to buffer the packets in
case of a HO to overcome the latency of link establishment at the MN?

> The same point as above:)

If the MN is able to send UL packets to the nMAG, then the link between the
MN and MAG is up, right? One of the arguments has been that the latency in
link establishment is the reason to send a PBU with TBO. But the MAG can
send a regular PBU during the link establishment phase in which case you
could expect a PBA before the MN is able to send packets on the UL. And in
case the PBA has not yet arrived, the nMAG could buffer it. IMO, this
optimization would be sufficient.

> lateral tunnel between the pMAG and nMAG.

The lateral tunnel does not break the security model.

> If there is no need here, then

IMO it is not feasible to optimize HOs without an interface between the pMAG
and nMAG. And the reason being the transient-binding approach relies on
layer 2, AAA etc. mentioned in the I-D which are beyond the scope of a
generic solution.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 8 Jun 2009 17:47:16 -0500

Hi Raj,
please see clarification inline.

Regards,
Ahmad

> No.. I meant a regular PBU.
[Ahmad]
Hmmmm... Then I missed what you are trying to say.
Because that is the whole purpose of creating a transitional state. Or I
am missing something here?

> 
> > That is why the MAG is sending the PBU (with TBO) to 
> indicate to the 
> > LMA that only UL traffic can be forwarded to the nMAG pCoA 
> at this point.
> > So, I do not see any contradiction. The MAG is aware that 
> only UL can 
> > be forwarded from the nMAG pCoA and it uses the PBU to 
> inform the LMA 
> > with this.
> 
> How can the MAG be aware that it can only send UL packets? A 
> MAG can send UL packets only when it receives a PBA. I don't 
> see a good reason why the MAG should start sending UL packets 
> before receiving the PBA. A scenario where you would need to 
> do this would be good to understand. (And lets not do this 

[Ahmad]
Sure. The MAG SHOULD send UL after receiving a PBA.
The nMAG does not get triggered to send PBU (with TBO) based on
receiving an UL data packet from the MN, for example. No that will be
controlled in an out-of-scope mechanism. This PBU is sent in preparation
to enable the LMA to legally accept UL traffic when the MN is in active
handoff starts sending them from a new nMAG pCoA.

> > Good question. When active handover is progressing and 
> sensitive data 
> > is exchanged, I believe some type of traffic justify a handover 
> > optimization is NOT needed and the nMAG can buffer the data without 
> > any negative impact to the quality of the traffic?
> 
> I don't disagree on the need for optimizing the handover 
> scenario. But is'nt the ability to buffer the DL packets 
> until the MN can receive packets an optimization already?

[Ahmad]
I am not sure about this. It seems these two sentences are contradicting
each other. In one hand, HO optimization is needed while on the other
one, buffering the DL is a good enough optimization mechanism :) or you
have a specific HO optimization in mind:)
 
> Would it not be sufficient to buffer the packets in case of a 
> HO to overcome the latency of link establishment at the MN?
> 
> > 
> >> 
> If the MN is able to send UL packets to the nMAG, then the 
> link between the MN and MAG is up, right? 

[Ahmad]
We are talking about a specific HO optimization procedure in here. So
the answer to your question is: Yes in the Uplink direction BUT NO in
the downlink direction. So, a MN in active handoff moves from the pMAG
to the nMAG and continues sending UL traffic. IMO, the case of this HO
which is already deployed and tested (using a different protocol) relies
on doing the HO in a smart:) way while optimizing the air resources.

Let us remember, there is a link between the previous RNC (let me call
it that) and the next RNC for allowing the DL traffic to get to the MN.
Right?

However, using that link in two direction is expensive while another
link is able to handle the UL traffic through the nMAG anyway. The
question, why not making use of that link portion for the uplink which
is ready? 

> One of the 
> arguments has been that the latency in link establishment is 
> the reason to send a PBU with TBO. 

[Ahmad]
I am not sure if that argument was made for this case:)

> But the MAG can send a 
> regular PBU during the link establishment phase in which case 
> you could expect a PBA before the MN is able to send packets 
> on the UL. And in case the PBA has not yet arrived, the nMAG 
> could buffer it. IMO, this optimization would be sufficient.

[Ahmad]
I disagree:)
Please see clarification above. Again, the same can be said about all
other HO optimization mechanism that intend to handle PMIPv6 HO
optimization. Or you believe this is a specific case?

> has been 
> >> MIP6 design. I dont see a strong reason for processing 
> these packets. 
> >> Do you have some data to show the amount of packets lost and the 
> >> consequence on applications (I am assuming you are looking 
> at VoIP in 
> >> this case)?
> > 
> > [Ahmad]

[Ahmad]
NOR allowing the UL traffic after a secure exchange PBU(with TBO)/PBA.

> > back to the same point, do we need a handover optimization in this 
> > case or you think it is not necessary?:)
> > 
> 
> IMO it is not feasible to optimize HOs without an interface 
> between the pMAG and nMAG. And the reason being the 
> transient-binding approach relies on layer 2, AAA etc. 
> mentioned in the I-D which are beyond the scope of a generic 
> solution. 

[Ahmad]
We can debate that offline:)
But let me understand what you are saying here.

You believe that there is a compelling need for PMIPv6 HO optimization
and it needs a lateral tunnel between the pMAG and the nMAG. Right?

I agree too. However, there are two ways of achieving this:

1. Is to have a lateral bi-directional layer-3 tunnel between the pMAG
and nMAG, which apparently is your favorite approach:)

2. Another smart mechanism of tunneling can be explained as follows:
2.1. a DL layer-2 tunnel between the peNB and neNB. (This portion takes
care of the DL portion of item No. 1; Right?)

2.2. Since uplink traffic in all cases has to come from the MN, this HO
optimization prepare the uplink direction of the link layer before the
MN arrives at the neNB and as soon the MN is there, uplink traffic
starts flowing using that portion of the link which is already prepared.
Using this ready portion of the link layer, IMO, more efficient way of
communicating UPLINK traffic than reversing the traffic over a lateral
bi-directional layer-3 tunnel as in case 1.

BTW: I happen to believe that optimization No. 2 is more effective, I do
not have data to back my belief, but that could be a good topic for
research :)

> 
> >> 
> >> - In Sec 3.2 :
> >> "   According to
> >>    the PMIPv6 base protocol [RFC5213], the Access 
> Authentication and 
> >> the
> >>    Proxy Binding Update (PBU) are triggered in the access 
> network by 
> >> the
> >>    immediate update of the MN's BCE after the PBU from the 
> MN's nMAG 
> >> has
> >>    will drop all subsequent packets being forwarded by the 
> MN's pMAG 
> >> due
> >> justified. The problem statement lacks the necessary data and is 
> >> based on assumptions and speculation. I know some of these issues 
> >> have been raised before, but I have not yet seen a 
> satisfactory set 
> >> of reasons for specifying such an approach.
> >> 
> >> -Raj
> >> 
> >> 
> >> 
> >> 
> >>

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 09 Jun 2009 09:50:12 +0800

Dear all,

I noticed the description of MIPSHOP charter:

"The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and
the necessary extensions to improve these protocols. The MIPSHOP
WG will also identify missing components that are required for
deploying these protocols and standardize the necessary extensions."

I think the MAP reliability is missing so I write this draft to fulfill the charter of MIPSHOP.

A URL for this Internet-Draft is:

 http://tools.ietf.org/html/draft-cui-mipshop-map-reliability-00  

What do you think about this draft?  Is there anybody interested in this item?

If you have any comments or problems please let me know.

Thanks in advance.

Xiangsong

华为技术有限公司  

地址：深圳市龙岗区坂田华为基地 邮编：518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

----- Original Message ----- 
From: IETF I-D Submission Tool 
To: [email-masked] 
Sent: Monday, June 08, 2009 4:10 PM
Subject: New Version Notification for draft-cui-mipshop-map-reliability-00

A new version of I-D, draft-cui-mipshop-map-reliability-00.txt has been successfuly submitted by Xiangsong Cui and posted to the IETF repository.

Filename: draft-cui-mipshop-map-reliability
Revision: 00
Title: Mobility Anchor Point (MAP) Reliability Extension
Creation_date: 2009-06-08
WG ID: Independent Submission
Number_of_pages: 10

Abstract:
This document introduces an extension to allow an adapted multiple
binding in hierarchical mobile network. Mobile node registers its
RCoA and LCoA in the home agent at same time to get two separate
connections between the mobile node and the home agent, or between
the mobile node and the correspondent node in Route Optimization
scenario. These connections provide a robust communication between
the mobile node and correspondent nodes and mobile node can overcome
the failure on MAP.

The IETF Secretariat.

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 12 Jun 2009 12:01:42 +0200

Hi Raj,

please find also some feedback to your remaining comments inline.

Ahmad Muhanna schrieb:
>> Authentication and the
>> network by the
>> MN's nMAG has
Well, PMIPv6 sends the PBU as a result of an MN's attach. The base spec 
assumes that the
MAG has means to learn about the LMA where to send the PBU to.Relevant 
for the
problem we describe is that the MAG uses the PBU/PBA to retrive 
configuration data
for the MN from the LMA. Hence, link configuration can be done only 
after receiving the
PBA, whereas the associated handshake causes the issues we describe and 
solve with
transient BCE.

>>   well. The nMAG can decide when to send the PBU as an example.
The MN expects an HNP and can start using the new IF after set up of the 
IF and after the
address has been completed. It has no control yet to when the path 
switch is performed.
Regarding the MAG's choice when to send the PBU, it's not too flexible 
as the MAG
retrives configuration data for the MN from the LMA. As the LMA 
authorizes the
mobility session, this handshake comes before any IP address or bearer 
can be set up.

>>   nMAG. Similar to what has been done in FMIP6 and also proposed in
That's one very specific solution with many dependencies, such as a 
complex CT protocol
and the assumption about an existing SA between MAGs to protect 
associated signaling.
Transient BCE solves the same thing much simpler with the same effect 
and without
mandating anything between MAGs.

>> MN's pMAG due
Same as above, that puts additional assumptions on the interface between 
MAGs and
introduces additional protocol complexity. Transient BCE solves this by 
re-using
existing protocol interfaces and SAs.

>>    context of PMIP6? And what is the target links latency that you are
That has been posted some time ago and I remember RTTs on GSM about 
150ms. Yes, this
problem you refer to assumes that the RTT on the target link is less.

>>   approach it is not a given that buffering would not be required.
Well, for a streaming application, buffers need to be really huge if you 
want to
reduce packet loss for these problems.At the same time you introducce a 
huge jitter.
There are always alternative protocols and solutions.. But why not 
taking the
one with least complexity and most benefit ;-) ?

>>    on the host. This change is contrary to that design principle.
Well, that's what we say: It's out of scope. And the specification does 
not depend
on any MN signaling... at least not more as RFC5213 does.

marco

---

From: <[email-masked]>
Date: Fri, 12 Jun 2009 19:14:57 +0200

Hi Marco,

Continuing the thread inline:

> PBA, whereas the associated handshake causes the issues we describe and

The nMAG may receive the assigned prefix as part of access authentication
response from the AAA. So it is possible that the nMAG does not have to wait
for the PBA to receive the prefix to advertise in the RA on the target link.
The point is that as per RFC5213 (or even MIP6/MIP4), a PBU/BU essentially
modifies the BCE and causes the tunnel to be switched. The tBCE option is
changing this behavior. It would be better to take the MCoA approach which
allows the BCE to point to multiple tunnel end-points and delete CoAs when
they are no longer needed. My concern is with the "transient" nature of the
binding :) 

> IF and after the address has been completed.

Right... And if the MAG were to obtain the prefix (either via CT from the
pMAG) or from AAA as a result of access authentication, it could send the RA
to the MN and not rely on the PBA to obtain the prefix info.

> It has no control yet to when the path switch is performed.
> retrives configuration data for the MN from the LMA.

Not necessarily.. And especially not in the case of a HO (see above).

> As the LMA  authorizes the

Yes, with the PFMIP6 approach there is a bidirectional tunnel for traffic as
well as signaling to set to set it up and do CT. With this approach you do
not have to modify the behavior of the LMA in the sense that it is
processing UL packets without a proper BCE (breaking the MIP model). Such an
optimized HO scenario is most likely to be used in networks which are within
an administrative domain and hence the security between MAGs is not really a
concern. 
I guess it boils down to whether changes at the MAG to support HOs are more
optimal as opposed to changes at the LMA.

> existing protocol interfaces and SAs.

Interface between pMAG and nMAG is also being reused. It is based on the
FMIP6 HO RFC. There is no additional protocol complexity as you say.

> one with least complexity and most benefit ;-) ?

There are multiple ways of how the jitter can be reduced and where the
buffering is done. Buffering needed would be in the order of 100~200 ms. I
do not believe this will result in the node having a huge buffering
requirement. And again the buffering capacity is based on the % of nodes
that would be in a HO at any given time. It would vary with your network
topology and network deployment planning.
So if you really need a protocol that has the most benefit to optimize such
HOs, then there is really no alternative than to have a sideways tunnel
between the MAGs (at least IMO).

> on any MN signaling... at least not more as RFC5213 does.

Right... The I-D does mention it being out of scope. But from reading the
details there is an assumption that the MN would provide information at L2
which would be used to optimize the HO.

-Raj

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 15 Jun 2009 10:36:34 +0200

Hi Raj,

please see inline for feedback.

[email-masked] schrieb:
> response from the AAA. 
Now I am confused, as you argue above that PMIPv6 does not make any 
assumption
on access authentication...

> So it is possible that the nMAG does not have to wait
Using multiple CoA approach does not work for handover, as the CoA needs 
to be the
same for the source and the target interface to achieve session 
continuity. Further, using
a multiple CoA approach with twice the same CoA (?) simply during a 
handover is too
much overhead, in my opinion, as in addition to the bindings you have to 
signal forwarding
policies to the LMA. This is intrinsic with the transient BCE apporach 
and handover can be
optimized with a single option. I think that's worth it. W.r.t your 
concern with the "transient"
nature of the binding, well, a handover *is* transient. This is very 
different from a multiple
CoA approach, which you do not use for handover, but for flow 
distribution etc., hence it
has a more long term nature.

> to the MN and not rely on the PBA to obtain the prefix info.
As in a dual radio handover the target interface is not initialized yet, 
we should follow the
PMIPv6 policy which sais that the LMA should be under control of the 
assigned prefix.
Simply using CT with the assumption that its ok to assign the same 
prefix on the
target interface, conflicts somehow.

> Not necessarily.. And especially not in the case of a HO (see above).
Again, we should not rely or even depend on external systems, such as 
AAA for access authentication.
Just take RFC5213 as base, where we provide an optimization to.

> optimal as opposed to changes at the LMA.
As we showed in MIPSHOP some time ago, we see some use cases for PFMIP, 
but we also see
the advantage of using transient BCE for some use cases. I don't think 
you can use a single protocol
to solve all handover issues. At least not if you argue from a technical 
perspective.
If there are advantages of using a simple mechanism to get a large 
benefit with big advantages
in some use cases without adding complexity and dependencies, I think 
that justifies the existence
of such mechanism.

> FMIP6 HO RFC. There is no additional protocol complexity as you say.
Same as above, you cannot assume always the existence of such interface, 
in particular not
if you handover between different systems.

> between the MAGs (at least IMO).
Why do we work on handover optimization then? We could simply mandate 
all applications
to use reliable transport and rely on retransmission capability and on 
an overprovisioned system....
I don't think your argument holds, as there are always alternatives. But 
it's a question of costs,
complexity, overhead and dependencies.

> which would be used to optimize the HO.
If you want to read it that way, looks like the text is confusing. So 
maybe we should take it
out of the spec to not confise more readers. Thanks for the hint.
Just as note: If you look at other PMIPv6 handover optimization 
protocols, they are much
more concrete regarding signaling and associated dependency from the MN :-)
Transient BCE is simply not.

marco