Subject: [netlmm] PMIP Binding Error

From: Heikki Mahkonen <[email-masked]>
Date: Wed, 13 Aug 2008 10:23:04 +0300

Hi All,

    The current PMIPv6 draft doesn't say anything about sending or 
receiving Binding Errors. Therefore, I think it is meant that the 
RFC3775 way should be used for BE message?

    However, IMO the BE message handling in RFC3775 doesn't work for 
PMIPv6. The BE message holds only status, reserved, HoA, and mobility 
option fields. If PBU results into BE the HoA field must be zero 
(right?). So when MAG will receive such a BE message it cannot know to 
which BUL entry (which UE registration) this BE is reply to as there is 
no matching information in the message. The PMIPv6 draft/RFC should 
probably say that the BE message MUST have at least the MN ID option 
from PBU message (if possible - PBU message not broken). In addition, if 
MAG receives BE without MN ID option it should ignore it - or what?

Any thoughts?

BR,

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 00:40:54 -0700 (PDT)

On Wed, 13 Aug 2008, Heikki Mahkonen wrote:

> Hi All,
>
>   The current PMIPv6 draft doesn't say anything about sending or receiving 
> Binding Errors. Therefore, I think it is meant that the RFC3775 way should be 
> used for BE message?
>
>   However, IMO the BE message handling in RFC3775 doesn't work for PMIPv6. 
> The BE message holds only status, reserved, HoA, and mobility option fields. 
> If PBU results into BE the HoA field must be zero (right?). So when MAG will 
> receive such a BE message it cannot know to which BUL entry (which UE 
> registration) this BE is reply to as there is no matching information in the 
> message. The PMIPv6 draft/RFC should probably say that the BE message MUST 
> have at least the MN ID option from PBU message (if possible - PBU message 
> not broken). In addition, if MAG receives BE without MN ID option it should 
> ignore it - or what?
>

BE message is generally for the CN usage. I'm not sure in the context
of PMIP6, when this message would be needed and so we did not state
on the option requirements for that message.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 14:09:42 -0400

> on the option requirements for that message.

The Binding Error message actually has two uses. One is for the CN to
tell the MN that there is no corresponding binding cache entry when it
receives a route optimized packet from the MN. The second is for the HA
or the CN to indicate an unknown Mobility Header Message Type. 

The first one is not applicable for the base PMIPv6 spec, since we
assumed that the LMA would just silently drop the packets if there is no
corresponding binding cache entry. The second one can be used for PMIPv6
as is, without any additional PMIPv6-specific text.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 11:15:24 -0700 (PDT)

> as is, without any additional PMIPv6-specific text.

Given that there is no support for return routability test or RO in Proxy
Mobile IPv6, there is currently no need for this message.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 14:48:59 -0400

> Mobile IPv6, there is currently no need for this message.

Sri, there is still the second case. The LMA would send a binding error
message with status set to '2' to indicate an unknown mobility header
message type from the MAG. For example, if the LMA does not support the
Heartbeat mechanism and it gets a Heartbeat Request from the MAG, it
would be sending an binding error to indicate that it does not
understand the Heartbeat mobility header message type. 

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 12:08:02 -0700 (PDT)

Hi Vijay,

> understand the Heartbeat mobility header message type.

We are dealing with PBU/PBA in this spec, for general errors of other
MH types, we are not mandating the options for those messages and hence
I dont see the relevance for that error message here. Any new docs that
define new messages have to specify the use of this message along with
the mandatory options. The same is valid for Heart beat message.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 15:15:43 -0400

Sri, 

> the mandatory options. The same is valid for Heart beat message.

Even if your LMA implementation just implements the base PMIPv6 spec
with none of the other extensions, you would still need to implement the
binding error message with status '2', so that you can send that when
you receive a mobility header message type you don't understand. I
assume this is what Heikki was talking about.

I do agree that we don't need any additional text in RFC 5213 to be able
to send a binding error for this purpose. RFC 3775 suffices.

Vijay

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 14 Aug 2008 08:20:19 +0300

Hi Sri,

> the mandatory options. The same is valid for Heart beat message.
I think that the question is. Should the LMA send BE message for any 
reason? I know that there might only one conceivable reason 
(unrecognizable MH type). If the LMA should never send BE message for 
any reason then PMIPv6 RFC should probably say that this is different 
from the RFC 3775 - right? It should say that LMA must silently discard 
any message that has unrecognizable MH type, or something like that... 
If it should send BE message for any reason my question is. What should 
be in that BE message for it to be useful to the receiver of that message?

BR,

Heikki

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 14 Aug 2008 08:32:05 +0300

HI Vijay,

> assume this is what Heikki was talking about.
==> Yes this was what I meant. Should you send it sometimes/never?

> to send a binding error for this purpose. RFC 3775 suffices
==> Yes, but is the RFC 3775 BE message and the fields in it enough. For 
instance if MAG receives BE message and has sent any number of messages 
to the LMA. How would it know what message triggered the BE? With the 
information in the BE message it cannot perform BUL entry lookup so it 
must ignore the BE.

BR,

Heikki Mahkonen