Subject: Re: [mobile-ip] New BETH Draft

From: James Kempf <[email-masked]>
Date: Tue, 18 Sep 2001 16:17:10 -0700 (PDT)

Hi Rajeev,

Comments embedded.

>thanks for the reply. I would like to summarize this discussion.
>
>1. the MN need not be aware that the ARs support BETH. When this is the case, the
>MN waits for an RtAdv on a non-BETH router.
>

Within a BETH coverage area, yes. Outside of a BETH coverage area, it depends
on whether the MN has been informed that it is leaving the area or not.

>2. the MN may be made aware that the AR it is handing over to is a non-BETH
>router. This could be done via an extension to PrRtAdv.
>

Yes, necessary if the MN is to perform FMIPv6 handover, or, lacking FMIPv6
capability in the new AR, standard MIPv6 handover.

>3. On a BETH AR, unsolicited Router Advertisements must be disabled, at least
>until the BETH session is over.
>

If you mean sending of unsolicited RtAdv from the AR, yes.

>I don't see how a MN can continue sending packets using it's old CoA if it does
>not know that the new AR is a BETH AR. I mean it could send packets with old CoA,
>but they are prone to be discarded due to ingress filtering by the new AR. In
>other words, it *needs* to be informed about the BETH-ability of the new AR, one
>way or the other.
>

Yes, if the AR has no Neighbor Cache entry for the MN, they would likely be
discarded. Like I've been trying to emphasize and like the new draft says,
the MN showing up at an AR where it doesn't know what kind of service
is available is a misconfiguration that may result in suboptimal service.

>In any case,  I see the following requirements.
>
>R1. Due to 1), the MN is required not to send RtSol when it establishes a new
>link.

If you are talking about within the BETH coverage area, yes.

>R2. Due to 2), a L3 message over the air interface is needed.

If you are talking about notifying the MN when it leaves the BETH coverage
area, then yes.

>R3. Due to 3), unsolicited router advertisements cannot be multicast to all-nodes
>multicast address. They need to be sent only at the termination of a BETH session
>to each MN.
>

Right. The draft says this for FMIPv6 handover in both the case where the
MN terminates the BETH session and where the AR terminates the session. It
currently does not state this for standard MIP handover, because there
is currently no way in FMIPv6 to indicate that the MN should use standard
MIP handover.

>To me R1 is undesirable. You would need this requirement in all the MNs.

Only if the MN supports BETH. That will depend on the availability of
L2 triggers and therefore of the radio protocol. If the radio interface
does not support the requirements for BETH, obviously, the MN can't support it.

>R2 of course means bits spent over the air interface; however, this seems
>inevitable.

It is only inevitable when the MN leaves the BETH coverage area. If it is within
a coverage area, there is no reason for it, the network can take care of
the handover.

>I don't see issues with R3 other than defining new method to deliver RtAdvs.
>
>Is this accurate ? If yes, could you add it to the current BETH proposal ?
>
>

I will be happy to add a new code to PrxyRtAdv allowing the AR to inform
the MN when it leaves the BETH coverage area and is moving to a coverage
area where FMIPv6 service is unavailable. I believe the draft already
allows the AR to inform the MN when it is leaving a BETH coverage
area and FMIPv6 service is available. This is standard FMIPv6 handover.

		jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Sep 2001 16:43:50 -0700

Hello again James,

it appears that we are in sync. However, I would like to see clear descriptions of

- what are the requirements for a BETH MN
- what are the requirements for a BETH AR

in the draft, especially if it needs to be part of the FMIPv6 draft. As I understand,
BETH is a very specific optimization with underlying assumptions and associated
requirements. They need to be *clearly* specified, perhaps in an individual section.
If such a thing already exists, please excuse this note.

Regards,

-Rajeev