Subject: Re: [Mipshop] Question on uplink packetindraft-yokota-mipshop-pfmipv6-00

From: Julien Laganier <[email-masked]>
Date: Fri, 12 Sep 2008 11:09:40 +0900

Hi Rajeev,

Koodli, Rajeev wrote:
> Hi Julien,
> 
>> The draft specifies inclusion of the MN-HoA in FPMIPv6 signaling while
>> in PMIPv6 the granularity of addressing is that of an IPv6 prefix.
> Thus
>> I think the Home Network Prefix (HNP) rather than MN-HoA should be
>> present in FPMIPv6 signaling (and the IPv4-MN-HoA if the networks
>> support IPv4 mobile nodes.)
> 
> [RKo:>] Yes. I had revised the ID with this just before the Dublin
> meeting. This will be clear once we submit it the 00 version.

Ok.

>> Regarding the MN pausing transmission of packets after an L2 handoff,
>> when the L2 doesn't hide entirely the L2 handoff, we have to rely on
>> IP-layer movement detection concluding that no IP-layer movement
>> occured:
> 
> [RKo:>] I would say that the MN behavior should be unchanged from a
> "normal" IPv6 behavior. 

Agree. But the issue in that case would be that normal IPv6 behavior 
might not let the MN to start sending uplink packets before it gets an 
RA from the MAG -- see below.

>> - For an IPv6 MN, if the HNP is transferred from the pMAG to the nMAG
>> (in the HI for predictive mode, and in the HAck in reactive mode), the
>> nMAG can then send an RA including the HNP to the MN as soon as the MN
>> completes L2 attachment. As a result, the MN would immediately start
> to
>> transmit uplink packets to the nMAG -- see draft-ietf-dna-simple-02.
>>
> [RKo:>] This (nMAG supplying the HNP) is possible, although it has not
> been our intent here. It is used by nMAG to perform PMIP registration. 
> 
> The general design principle of FMIP is that protocol operations of
> co-existing protocols should be kept separate; we may enable something
> but not actually perform operations that would otherwise be done by a
> different protocol. This allows some predictable behavior for each
> protocol even when they co-exist (and hopefully assist each other), and
> vastly simplifies implementation. 

Agree with the principle.

In practice, though, if the link layer uses addresses, the MN will need 
to receive an RA from the MAG before it can resume transmission to it -- 
otherwise the MN has no idea which link layer address packets should be 
sent to.

If the link layer has no addresses there might be no problem.

>> - For an IPv4-only MN, it's not clear to me how that can be made to
> work
>> since we don't have RAs. RFC4436/DNAv4 relies on unicast ARP probes
> sent
>> to a previous router but it looks like none of the link layers
> supported
>> by PMIPv6 will use ARP, and even if it did, trying to make DNAv4
>> conclude that the IP link hasn't changed would imply that different
> nMAG
>> and pMAG have the same link layer address.
>>
> [RKo:>] Is this specific to PFMIP? How is it done in IPv4 support for
> PMIPv6? (The same comment as above for co-existence here as well)

IPv4 support for PMIPv6 doesn't use DNAv4 optimizations, it relies on 
DHCP signalling to confirm the MN-IPv4-HoA.

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

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 12 Sep 2008 01:13:39 -0400

Hi,

> otherwise the MN has no idea which link layer address packets should
be

[RKo:>] Well, the MN would continue to use the previous router's link
layer address until NUD fails. Change of a link does not necessarily
mean change of default router since the new link may be served by the
same router. 

There is no reason to pause packet transmission while NUD is in
progress.
With PFMIP, uplink packets can be forwarded regardless of when the MN
receives an RA.

> DHCP signalling to confirm the MN-IPv4-HoA.

[RKo:>] Ok.

-Rajeev

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Sep 2008 00:21:58 -0500

Hi Rajeev,

> packetindraft-yokota-mipshop-pfmipv6-00
> 
> Hi,
> > to receive an RA from the MAG before it can resume 
> transmission to it
> --
> [RKo:>] Well, the MN would continue to use the previous 
> router's link layer address until NUD fails. Change of a link 
> does not necessarily mean change of default router since the 
> new link may be served by the same router. 
> 
> There is no reason to pause packet transmission while NUD is 
> in progress.

[Ahmad]
Where is this referenced?

> With PFMIP, uplink packets can be forwarded regardless of 
> when the MN receives an RA.

[Ahmad]
I understand that is your opinion, but is there something out there to
pack what you have just said.
At least looking at the NDA simple draft that Julien quoted, it clearly
contradicts your opinion. I understand that is a standard track IETF wg
draft, but do you have other standard that you can refer us to which
supports your opinion.

Thanks!

Regards,
Ahmad
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>

---

From: Julien Laganier <[email-masked]>
Date: Fri, 12 Sep 2008 14:33:39 +0900

Hi,

Koodli, Rajeev wrote:
>> In practice, though, if the link layer uses addresses, the MN will
>> need to receive an RA from the MAG before it can resume transmission to it
>>  -- otherwise the MN has no idea which link layer address packets should
>> be sent to.
> 

What I had in mind was, in a situation where the MN attaches to a new 
link served by a new router, how could the MN start to send uplink 
packets to the new router as soon as it attaches.

What I understand from your answer is thus that the MN will have to wait 
until it receives an RA (as a result of NUD to the old router failing 
and a RS being sent, or as a result of the MAG sending an RA with the HNP).

Is this a correct understanding?

--julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 12 Sep 2008 14:44:10 -0400

> and a RS being sent, or as a result of the MAG sending an RA with the

[RKo:>] First, let's just remember that the above (and following) is for
the case where MAC addresses are used on the link between MN and the
router. In the other case (likely deployment scenario for PMIP), there
is no issue identified.

[RKo:>] While NUD is in progress, packets can still be sent because the
ND state for the neighbor is STALE. In the meanwhile, RS can also go
out.

The new router may be configured to accept packets sent to a MAC address
it recognizes (as that of the previous router); it may not respond to NS
with that MAC address of course. So, for the NUD probe, the new router
responds with a solicited NA which installs a new MAC address in the NCE
for the MN. 

The RA can also establish the new MAC address for the router, but I
think the entry will be in STALE state (and not in REACHABLE state as in
the case of a solicited NA with 'O'=1). 

I don't understand why the RA must contain the HNP. As long as the RA
contains the same link-local address of the router, the MN continues to
think that it is on the same link as before (which is what you want in
PMIP), and can continue to send packets uplink. 

> Is this a correct understanding?

[RKo:>] The MN should be able to send uplink packets even without
getting an RA with HNP, even for the case where MAC addresses are used. 

-Rajeev

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 12 Sep 2008 14:55:52 -0400

Hi Ahmed,

> Where is this referenced?

[RKo:>] See ND, RFC 4861. 

> pack what you have just said.

[RKo:>] I assume you mean "back" and not "pack".
Yes, in deployments where no MAC addresses are used between the MN and
the MAG, the MN continues to send uplink packets.

Where MAC addresses are used, it performs NUD, and RS. When NUD is done,
it can continue to send packets. I already mentioned this in more than
one e-mail earlier.

> contradicts your opinion.

[RKo:>] Contradicts what? And, how does it clearly contradict? I have
seen the simple DNA draft too. It says do NUD and RS in parallel. 
 
> I understand that is a standard track IETF wg

[RKo:>] RFC 4861. I hope simple DNA sees light one day.

-Rajeev

---

From: "Desire Oulai" <[email-masked]>
Date: Fri, 12 Sep 2008 16:30:15 -0400

Hi Rajeev,

 As I said inprevious mails, the draft needs to point out PFMIP
behaviour with different MN behaviour.  Moreover, I agree with Julien
that if the MN do L2 attach with a new router, it is likely to wait for
a RA. An example is the Handoff between two different interfaces of the
mobile node (HI = 2). I am not sure the new interface will start to send
information without receiving the HNP in a RA. So it is important to
mention this case. 

BR

Desire

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> Sent: September 12, 2008 2:44 PM
> To: Julien Laganier
> Cc: [email-masked]
> Subject: Re: [Mipshop] Question on 
> uplinkpacketindraft-yokota-mipshop-pfmipv6-00
> 
> 
> 
> > and a RS being sent, or as a result of the MAG sending an 
> RA with the 
> > HNP).
> 
> [RKo:>] First, let's just remember that the above (and 
> following) is for the case where MAC addresses are used on 
> the link between MN and the router. In the other case (likely 
> deployment scenario for PMIP), there is no issue identified.
> 
> [RKo:>] While NUD is in progress, packets can still be sent 
> because the ND state for the neighbor is STALE. In the 
> meanwhile, RS can also go out.
> 
> The new router may be configured to accept packets sent to a 
> MAC address it recognizes (as that of the previous router); 
> it may not respond to NS with that MAC address of course. So, 
> for the NUD probe, the new router responds with a solicited 
> NA which installs a new MAC address in the NCE for the MN. 
> 
> The RA can also establish the new MAC address for the router, 
> but I think the entry will be in STALE state (and not in 
> REACHABLE state as in the case of a solicited NA with 'O'=1). 
> 
> I don't understand why the RA must contain the HNP. As long 
> as the RA contains the same link-local address of the router, 
> the MN continues to think that it is on the same link as 
> before (which is what you want in PMIP), and can continue to 
> send packets uplink. 
> 
>  
> [RKo:>] The MN should be able to send uplink packets even 
> without getting an RA with HNP, even for the case where MAC 
> addresses are used. 
> 
> -Rajeev
> 
> > 
> > --julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 12 Sep 2008 16:43:07 -0400

Hi Desire,

> behaviour with different MN behaviour. 

[RKo:>] I also pointed out in previous e-mail that scenarios where the
MN ends up waiting do not gain the performance that PFMIP can provide.
 
> Moreover, I agree with Julien
> a RA. 

[RKo:>] See my replies as well - this is for the case where the MAC
addresses are used between the MN and the AR. Even so, NUD and packet
transmission can happen in parallel.
 
> An example is the Handoff between two different interfaces of the

[RKo:>] Sure, we can mention that.

Thanks,

-Rajeev

> > > What I understand from your answer is thus that the MN will have
to
> > wait

---

From: Julien Laganier <[email-masked]>
Date: Tue, 16 Sep 2008 18:56:19 +0200

Hi Rajeev,

Follow up from my side below:

On Friday 12 September 2008, Koodli, Rajeev wrote:
> > What I understand from your answer is thus that the MN will have to
> > wait until it receives an RA (as a result of NUD to the old router
> > failing and a RS being sent, or as a result of the MAG sending an
> > RA with the HNP).

Reading your note I realized that so far I haven't differentiated 
between the MN *sending* uplink packets, and the nMAG *receiving* them, 
while I should clearly have. As a result the statement above was 
innacurate.

Thus in the above what I meant was: the MN will have to wait for an RA 
to get knowlegde of the nMAG's link layer adddress, so that it can send 
uplink packets that the router will *receive*.

But the rest of your note made me think that this statement is too 
limiting since I had ruled out the case where the nMAG would reply to 
NUD with a NA containing the new link layer address -- see below:

> [RKo:>] First, let's just remember that the above (and following) is
> for the case where MAC addresses are used on the link between MN and
> the router. In the other case (likely deployment scenario for PMIP),
> there is no issue identified.

Right.

> [RKo:>] While NUD is in progress, packets can still be sent because
> the ND state for the neighbor is STALE. In the meanwhile, RS can also
> go out.

Right. But probably we should acknowledge in the spec that uplink 
packets sent by the MN before it received an RA or an NA will have the 
pMAG's link layer address as destination, thus will not necessarily 
reach the nMAG, unless it is configured to, as you mention below.

> The new router may be configured to accept packets sent to a MAC
> address it recognizes (as that of the previous router); 

This implies that the link layer between the MAG and the MN allows the 
MAG to put its interface in promiscuous mode. Probably we should 
acknowledge that in the spec.

In case this is not possible, uplink packet reception will be disabled 
until the MN's receive the nMAG's RS or RA with its link layer address.

> it may not 
> respond to NS with that MAC address of course. So, for the NUD probe,
> the new router responds with a solicited NA which installs a new MAC
> address in the NCE for the MN.

Good you're pointing this case out. I had previously ruled out the nMAG 
replying to a NUD probe with a sollicited NA with the override flag for 
the MAG link local address (as initially assigned by the LMA, or as 
assigned in the whole domain), and containing the nMAG's link layer 
address.

The reason I ruled that out is that the NS from the NUD probe is an 
unicast NS sent to the cached link layer address, that is, the link 
layer address of the pMAG. 

Thus that NS would not be received and replied to by the nMAG unless, as 
above, the link layer allows the nMAG interface to be in promiscuous 
mode.

In addition to that, for this to be possible prior to exchange of the 
PBU/PBA, the nMAG needs to be provided with the MAG's link local 
address in the HI or the HAck, doesn't it?

> think the entry will be in STALE state (and not in REACHABLE state as
> in the case of a solicited NA with 'O'=1).

Rioght, the entry will be set to STALE, unless in the simple DNA case 
where, if the RA is in reply to a RS it sent, the entry will be in 
state REACHABLE.

> contains the same link-local address of the router, the MN continues
> to think that it is on the same link as before (which is what you
> want in PMIP), and can continue to send packets uplink.

With DNA simple the RA has to come with the same prefixes. 
Otherwise "same link" confirmation comes from the MN sending to the 
router's link layer address a unicast NS for the router's link local 
address, which should be replied to a NA from the router's link layer 
address for the router's link local address.

> getting an RA with HNP, even for the case where MAC addresses are

Right, but as I hope I managed to explain above, on link layers with 
addresses, the MN being able to send uplink packets doesn't necessarily 
means these packets can be received by the nMAG/router.

It seems possible to cover these cases adequatly with 1) promiscuous 
mode on the nMAG, and/or 2) transfer of the MAG link local address b/w 
pMAG and nMAG for use in NUD.

What do you think?

Regards,

--julien

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 14:41:18 -0400

Hi Julien, Rajeev, Ahmad,

RFC 5213, section 6.9.3 says

   If these Router Advertisements are sent
   using a different link-local address or a different link-layer
   address, the mobile node will always detect a new default-router
   after every handoff.  For solving this problem, this specification
   requires all the mobile access gateways in the Proxy Mobile IPv6
   domain to use the same link-local and link-layer address on any of
   the access links wherever the mobile node attaches.

So why would we have a case where the old MAG and the new MAG use
different link layer addresses?

On another issue, I think it is ok for draft-yokota-mipshop-pfmipv6-00
to specify that the router advertisement is sent before the PBU/PBAck
exchange with the LMA. It would just mean that
draft-yokota-mipshop-pfmipv6-00 is modifying the MAG behavior from RFC
5213 that says the router advertisement is sent after the PBU/PBAck
exchange when PFMIPv6 is used. I don't see any issues with that. 

Vijay 

> [mailto:[email-masked]] On Behalf Of Julien Laganier
> Sent: Tuesday, September 16, 2008 9:56 AM
> To: [email-masked]
> as the RA

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 24 Sep 2008 17:00:08 -0500

Hi Vijay,
Please see inline.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, September 24, 2008 8:41 PM
> To: Julien Laganier; Muhanna, Ahmad (RICH1:2H10); Koodli, Rajeev
> Cc: [email-masked]
> Subject: RE: [Mipshop] Question on 
> So why would we have a case where the old MAG and the new MAG 
> use different link layer addresses?

[Ahmad]
I do not think RFC5213 mandates this behavior. I think draft-yokota
needs to capture that and mandate that the link-local and link-layer
need to be the same for all MAG of the same PMIPv6 domain or reference
it in a way or another. IMO, that should not be a problem.

> 
> On another issue, I think it is ok for 
> draft-yokota-mipshop-pfmipv6-00 to specify that the router 
> advertisement is sent before the PBU/PBAck exchange with the 
> LMA. It would just mean that draft-yokota-mipshop-pfmipv6-00 
> is modifying the MAG behavior from RFC
> 5213 that says the router advertisement is sent after the 
> PBU/PBAck exchange when PFMIPv6 is used. I don't see any 
> issues with that. 

[Ahmad]
Okay, that is fine, however, if we allow this change then it will make
sense to document what happens if the PBU/PBA fails. Make sense?

> > to get knowlegde of the nMAG's link layer adddress, so that it can 
> > send uplink packets that the router will *receive*.
> > 
> following) is 
> > Good you're pointing this case out. I had previously ruled out the 
> > nMAG replying to a NUD probe with a sollicited NA with the override 
> > flag for the MAG link local address (as initially assigned 
> by the LMA, 
> > or as assigned in the whole domain), and containing the nMAG's link 
> > layer address.
> > 
> > Thus that NS would not be received and replied to by the 
> nMAG unless, 
> > as above, the link layer allows the nMAG interface to be in 
> > promiscuous mode.
> > 
> > addresses, the MN being able to send uplink packets doesn't 
> > necessarily means these packets can be received by the nMAG/router.
> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 18:08:09 -0400

Hi Ahmad,

> I do not think RFC5213 mandates this behavior. 

It does mandate this behavior. The text says

    this specification

> sense to document what happens if the PBU/PBA fails. Make sense?

Yes.

Vijay

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 26 Sep 2008 15:23:49 +0900

Hi Vijay and Ahmad,

>     the access links wherever the mobile node attaches.

I think this belongs to the PMIPv6 baseline spec regardless of the
handover type (fast or normal).

>> sense to document what happens if the PBU/PBA fails. Make sense?

I think that the situation is similar to the case where the
re-registration by the MAG is failed. The MAG will stop handling the
UL/DL packets from/to the MN and may tear down the link between the MAG
and MN. If this part is worth mentioning, it will be documented in the
next version.

Regards,
-- 
Hidetoshi