Subject: [netlmm] Separation of Control and Data Plane for PMIPv6

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 27 Oct 2008 18:42:18 -0400

Hello,

I just submitted a short draft on separating control and data plane end
points. The draft defines a new mobility option for carrying the data
plane address. The draft is at
http://www.ietf.org/internet-drafts/draft-devarapalli-netlmm-pmipv6-data
-plane-00.txt

Comments/reviews are welcome.

Vijay 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Monday, October 27, 2008 3:40 PM
To: Vijay Devarapalli
Subject: New Version Notification for
draft-devarapalli-netlmm-pmipv6-data-plane-00 

A new version of I-D, draft-devarapalli-netlmm-pmipv6-data-plane-00.txt
has been successfuly submitted by Vijay Devarapalli and posted to the
IETF repository.

Filename:	 draft-devarapalli-netlmm-pmipv6-data-plane
Revision:	 00
Title:		 Separating Control and Data Plane for Proxy Mobile IPv6
Creation_date:	 2008-10-27
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
Proxy Mobile IPv6 is a network-based mobility management protocol.
The mobility entities involved in the Proxy Mobile IPv6 protocol, the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA),
setup tunnels dynamically to manage mobility for a mobile node within
the Proxy Mobile IPv6 domain.  This document describes an extension
to the Proxy Mobile IPv6 protocol to register a data plane address,
that is different from the Proxy Care-of Address with the LMA.  This
allows separation of control and data plane.

The IETF Secretariat.

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 27 Oct 2008 16:21:09 -0700

Hi Vijay,

RFC-3775/RFC-5213 clearly allows the use of Alt-CoA option
for the use of control and data plane separation. What is
missing is a parameter in the *conceptual BCE data structure"
related to the persistence of both the CoA and Source address
parameters. As a matter of fact we are missing many params in
this conceptual data structure. These parameters are from the
extension documents and ideally those documents should have
extended the BCE data structure. In any case, its just a
conceptual structure to aid the implementers and the protocol
operation is not strictly tied to the fields in this structure.
One place to fix this is in 3775-bis. Does that work ?

Regards
Sri

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: Monday, October 27, 2008 3:42 PM
> To: [email-masked]
> Subject: [netlmm] Separation of Control and Data Plane for PMIPv6
> 
> Hello,
> 
> A new version of I-D, 
> draft-devarapalli-netlmm-pmipv6-data-plane-00.txt

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 27 Oct 2008 19:37:16 -0400

Hi Sri,

I guess you missed much of the recent discussion that happened on this
topic. Please take a look at that thread again.

First of all, RFC 3775 does not talk about separating the control and
data plane. In fact it does not make sense to separate control and data
plane for a mobile node. :) It describes two uses for the AltCoA option.
1) to be able to bind a topologically incorrect address 2) to protect
the CoA when ESP is used, since ESP does not protect the IPv6 header. To
my knowledge (1) is not used anywhere. (2) is used by MIPv6. FMIPv6 is
the only protocol that I know that sends a BU from the oldCoA, binding
the new CoA with the old CoA. But this is similar to send a BU from the
home link, just before moving to the visited link. 

Second, the missing parameter that you suggest is actually quite
significant. Neither RFC 5213 or 3775 mention that the HA/LMA should
store the source address of the original BU/PBU if the altCoA option is
present. Only the contents of the altCoA is stored in the binding cache
entry. DS-MIPv6, OTOH, says that if the source address on the outer IPv4
header is different from the IPv4 care-of address option (the equivalent
of the AltCoA option), then in fact the source address on the outer IPv4
header should be stored as the CoA. The IPv4 care-of address option
contents are not stored. Therefore, at any time, there is only one
address stored in the binding cache entry. A MAG or a mobile node cannot
be sure that the LMA/HA did store two different addresses. So the
separation of control and data plane will not work. 

Third, any message that is initiated by the HA/LMA will be sent to the
CoA or Proxy CoA. Not to the source address of the original BU/PBU. Even
the BACK/PBACK is not guaranteed to be sent to the source address on the
original BU/PBU. Implementations have done it differently, i.e., used
the contents of the binding cache entry to construct the BACK/PBACK.

Finally, fixing this in 3775-bis does not make sense to me, since I
don't believe a mobile node will ever use this feature. It is not
required for Mobile IPv6. 

Vijay

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Monday, October 27, 2008 4:21 PM
> To: Vijay Devarapalli; [email-masked]
> Subject: RE: [netlmm] Separation of Control and Data Plane for PMIPv6
> 
> Hi Vijay,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Oct 2008 16:58:44 -0700 (PDT)

Hi Vijay,

> topic. Please take a look at that thread again.

No, I did not miss that discussion.

> home link, just before moving to the visited link.

The primary purpose of Alt-CoA option is the control/data plane
seperation. It may certainly have other use-cases. For the same exact
reason, the text related to Alt-CoA option made it to 5213, if you
remember the discussions.

> separation of control and data plane will not work.

What is stored and what is not stored is an implementation issue. From
the perspective of protocol interoperability, we require a given message
to be sent to a specific address. If that address that is obtained in
the prior state of the protocol is cached or not, is not a protocol
issue, its an implementation issue. The conceptual data structure is a
general recommendation/aid to implementations, its presence/absence has
no bearing on the wire protocol messages. Many protocols dont have this
conceptual structure at all, its a good practice to provide that in the
specs.

> the contents of the binding cache entry to construct the BACK/PBACK.

When the BU/PBU that triggered the registration has an Alt-CoA option,
any explicit signaling messages should be sent to the source address and
not to the CoA/Proxy-CoA.

> required for Mobile IPv6.

Alt-CoA option is specified in 3775 and the related parameters have to
added to that spec and even if its not used by a mobile node.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Oct 2008 17:13:28 -0700

Hi Sri,

> seperation. 

Where is this explained in RFC 3775? I repeat, separation of control and 
  data plane for a Mobile IPv6 mobile node does not make sense.

> What is stored and what is not stored is an implementation issue. 

It is not. Unless the MAG knows that the LMA did store both addresses, 
the MAG cannot be sure the LMA does support this.

From
> not to the CoA/Proxy-CoA.

Where is this specified?

> added to that spec and even if its not used by a mobile node.

This defies logic. :)

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Oct 2008 17:37:50 -0700 (PDT)

Hi Vijay,

>  data plane for a Mobile IPv6 mobile node does not make sense.

Its not about the presence of the phrase "Control Plane/Data Plane
seperation". The option can be used that way and cant see why it
wont work. If not, why is the use of Alt-CoA even made it to 5213 ?
Again, refer to discussions from Anand Bedekar and others.

> It is not. Unless the MAG knows that the LMA did store both addresses, the 
> MAG cannot be sure the LMA does support this.
>

If the option is present, the LMA must preserve it, else its a software
defect. When there is Alt-CoA option in the BU request, if the client
does not store it, where is the BA message being sent ?

>>  not to the CoA/Proxy-CoA.

Again, where is BA message sent when this option is present ?

>>  added to that spec and even if its not used by a mobile node.

The option that is defined in 3775 is the sole reason why the source
and CoA addresses would be different and so it must be defined there.
Where else ?

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Oct 2008 11:32:43 -0700

Hi Sri,

Sri Gundavelli wrote:
> wont work. 

This is actually a mis-use of the AltCoA option. It was not intended for 
  supporting the separation of control and data plane. Even if you do 
want to use the AltCoA option for this purpose, the specifications are 
missing. More below.

> If not, why is the use of Alt-CoA even made it to 5213 ?

RFC 5213 does not specify the separation of control and data plane. For 
instance, see the following text fragments from 5213.

Section 5.3.6

    o  The Destination Address field in the IPv6 header of the message
       MUST be set to the source address of the received Proxy Binding
       Update message.  When there is no Alternate Care-of Address option
       present in the request, the destination address is the same as the
       Proxy-CoA; otherwise, the address may not be the same as the
       Proxy-CoA.

What does "may not be the same" mean? If you had intended to use this 
for control and data plane separation, the above paragraph should have 
said, if there is an alternate care-of address option present and if the 
address in the option is different from the source address of the 
received PBU, then the destination address on the PBACK MUST be set to 
the source address of the received PBU. Otherwise it is not guaranteed 
to work. It becomes LMA implementation specific.

Section 6.9.1.5

    o  The Source Address field in the IPv6 header of the message MUST be
       set to the global address configured on the egress interface of
       the mobile access gateway.  When there is no Alternate Care-of
       Address option present in the request, this address will be
       considered as the Proxy-CoA for this Proxy Binding Update message.
       However, when there is an Alternate Care-of Address option present
       in the request, this address will be not be considered as the
       Proxy-CoA, but the address in the Alternate Care-of Address option
       will be considered as the Proxy-CoA.

The above paragraph tells me that the contents of the AltCoA option 
should be stored as the Proxy CoA. When the LMA needs to send a binding 
revocation message, where would it send the message to? There is no 
guarantee that the LMA will store the source address of the original 
PBU, since none of the specifications told the LMA to do this. Another 
example is the HA/LMA Switch Message [RFC 5142]. Where would this 
message be sent to?

IMO, it is not possible to implement separation of control and data 
plane using RFC 5213 and the alternate CoA option. You have to make a 
lot of assumptions. Perhaps you had it figured out how to implement 
this, but it is not specified in the document.

One option is to revise RFC 5213 and describe clearly how to use the 
AltCoA option to separate control and data plane. Another option is to 
develop a clean solution to separate the concepts of Proxy CoA and Data 
Plane Address. The Proxy CoA would be used for all control plane 
signaling and the Data Plane address would be used for tunneling data 
traffic. I of course prefer the cleaner solution.

> Again, refer to discussions from Anand Bedekar and others.

The mailing list or the off line discussions? We had a lot of 
discussions on the separation of control and data plane when PMIPv6 was 
being adopted by the NETLMM WG. We decided to come back to this later 
after specifying the basic PMIPv6 protocol assuming the control and data 
plane end-points are co-located. And thats what we did. Do you remember 
something different?

Vijay