Subject: [multimob] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source?

From: Aaron Feng <[email-masked]>
Date: Wed, 14 Dec 2011 11:31:18 +0800

Hi,
At first, thank you for your reply!  :)
There are still some questions confusing me. I'm not sure about
whether the mechanism of the protocol or the implemention leads to
such result?
a) If it's the protocol
PMIP and PIM-SM, which shoud be modified or add some new rules to deal with
such scenario? Do we need to treat the scenario of source-mobility
specially?
b) If it's the implemention
If we create PMIP policy-routing info into RIB, I think, it seems not
to work. For the MAG, could the MAG acting as DR for MN(MN acts as the
source) use a soure-routing info in RIB to execute the check of direct
connection?
Besides, though the MAG has routing info about MNs and knows where the
packets of MNs to foward, these routing info about MNs do NOT distribute to
other routers (except LMA). If we create the MN routing info into RIB
entries, is it diffused? If it's diffused, it will be a contradiction to
PMIP protocol.
c) If we modify the PIM about the check of direct connection,  that will
lead to the change of protocol of the PIM, which seems not to be allowed in
MULTIMOB WG.

Regards,
Aaron

---------- Forwarded message ----------
From: Stig Venaas <[email-masked]>
Date: 2011/12/14
Subject: Re: Questions for point-to-point link and the check of directly
connection of the mcast source?
To: Aaron Feng <[email-masked]>

Hi Aaron

This might be good to discuss on the multimob list, but I'll try to
answer here.

On 12/10/2011 5:17 AM, Aaron Feng wrote:

> Hi!
> According to the RFC 5213, the MAG emulates the mobile node’s home
> network on the access link by sending RA with MN's HNP ,so that the MN
> could consider itself at its home network.
> It's a point-to-point link between the MAG and MN.
> However, for the MAG, there's not any physical interfaces assigned with
> MN's HNP. If the MAG acts as the DR for the MN(MN acts as a mcast
> source), according to the RFC4601,
> the MAG needs to check whether the MN is directly connected. In my real
> experiment, the MAG failed to foward the macst data form the MN that
> acts as a mcast source.
> Therefore,I'm not sure about
> 1) how the DR checks whether it's directly connected with the source? By
> checking routing tables or just matching the network prefix of the
> physical interface(that receives the mcast data) with the source address
> or something else?
>

This depends a lot on the implementation. On Cisco IOS and I think also
Linux and BSD etc. you normally in your routing table (RIB) create
routes for each of the interfaces (whether virtual or physical), so that
if an interface is configured with say IP address and mask 10.1.2.1/30,
then a route for 10.1.2.0/30 is added and with some flag saying it is a
connected route. This can then be used by PIM to discover that a source
(in this case 10.1.2.2) is directly connected.

For PMIP it might be that the implementation does not add any such
routes to the RIB. This all depends on the implementation. In that case
PIM would probably not be able to find that they are directly connected.

Since the PMIP routing is somewhat unusual, it could be that the
implementation is done without creating any RIB entries, and IP
addresses for the p-t-p links. If this is the case, then for PIM
to work you may need to either add these entries to the RIB (or
better to the MRIB if PIM can use a separate RIB), or you may need
to modify PIM so it can in some other way know that these addresses
are directly connected.

Please also see what I posted related to this on the multimob list
yesterday and today. Happy to continue this discussion on the list
as it is very much related to the current wg discussions.

Stig

2) how to grasp the concept of the point-to-point link? Does it need two
> nodes with the same network prefix?
> Looking foward to hearing from you back soon!
> Regards,
> Aaron
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 14 Dec 2011 17:11:03 +0900 (JST)

Hi Aaron,

In the recent discussions in the ML, I've not talked about source
mobility for PIM on MAG.

Now let's move on discussion about source mobility in the situation of
PIM-SM on MAG. The followings are my comments for it.

> such scenario? Do we need to treat the scenario of source-mobility

In a nutshell, source mobility for PIM on both MAG and LMA can work if
receiver mobility for PIM works. There is only one issue, aka
"detour", if we take into account routing optimization.

When MAG realizes that the source is directly connected, the MAG can
simply recognize the IIF for the source packets and do PIM register,
etc. If some MNs subscribe a channel sent from an MN connecting the
same MAG, the multicast packets are forwarded to RP or MNs directly.
On the other hand, if other MNs connecting to different MAG subscribe
the channel sent from the MN, the packets are forwarded through LMA.
If we don't care for detour through LMA, no extra function is needed.
(Well, this implies that effective routing (i.e. routing optimization)
on PIM on MAG/LMA would be needed to consider if we propose source
mobility for PIM on MAG/LMA.)

BTW, this "detour" is more headache for MAG having multiple MLD
proxies (i.e. base solution).
When multiple MLD proxy instances may be co-located in a single MAG,
one MLD proxy attaching downstream source needs to inject his
multicast packets to other MLD proxy instances having the
corresponding receivers if we want to avoid detour. Of course, this
behavior has not considered with the standard MLD proxy definition
(rfc4605).

Please also see my mail sent on Dec 9 (for adoption call for the
source mobility draft).

> source) use a soure-routing info in RIB to execute the check of direct

No, MAG is always DR and last hop router for MNs.

> entries, is it diffused? If it's diffused, it will be a contradiction to

MAG never advertises MNs' prefixes.

> lead to the change of protocol of the PIM, which seems not to be allowed in

Well, I don't want to discuss about possibility of PIM-SM protocol
modification for source mobility *optimization*, because it may need
more study. But in general (e.g. with my current proposal), PIM
modification is not required.

Anyway, as you see, this is the reason that it is impossible to judge
the adoption of draft-schmidt-multimob-pmipv6-source-00.txt at this
moment. And I do recommend to concentrate only for source mobility for
base solution for this draft and explicitly say so in the revised
version. IMO, it is only the way to be adopted.

Regards,
--
Hitoshi Asaeda

---

From: Aaron Feng <[email-masked]>
Date: Fri, 16 Dec 2011 09:41:53 +0800

Hi,

> the channel sent from the MN, the packets are forwarded through LMA.
  I think, there's some difference between source mobility and receiver
mobility. For the receiver, when the MN subscribes a channel, it sends a
MLD report message with its link address. It's not a very strong limitation
because all the link address prefix is fe80::/64. However, for the source,
the MN uses its global address to send mcast data. Since the MAG has not
any physical interfaces assigned with MN's HNP, the check of direct
connection might fail if the MAG acts as the DR.

Regards,
Aaron

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 16 Dec 2011 13:10:06 +0900 (JST)

Hi,

> connection might fail if the MAG acts as the DR.

I cannot understand your point.
What does "the check of direct connection might fail if the MAG acts
as the DR" mean?
Why the problem happens only when MAG acts router?
Why the problem happens only for multicast packets?

Regards,
--
Hitoshi Asaeda

---

From: Aaron Feng <[email-masked]>
Date: Fri, 16 Dec 2011 15:23:25 +0800

Hi,
MLD report is the signaling message with only ONE hop, so it uses the link
address. It's not a very strong limitation because all the link address
prefix is fe80::/64.
But for the mcast source, it sends the data with the global address.
MAG acting as MN's DR should first checks whether the MN is in its subnet
or say directly connected using MN's global address.  Since the MAG has not
any physical interfaces assigned with MN's HNP, the check of direct
connection might fail.

Regards,
Aaron

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 16 Dec 2011 16:57:56 +0900 (JST)

> address. It's not a very strong limitation because all the link address

Sure.

> any physical interfaces assigned with MN's HNP, the check of direct

MN-HNP is a prefix assigned to the link between MN and MAG.
MN-HoA is a global unique address from MN-HNP and used as a source
address of MN's unicast and multicast packets.

Regards,
--
Hitoshi Asaeda

---

From: Aaron Feng <[email-masked]>
Date: Fri, 16 Dec 2011 17:08:59 +0800

> address of MN's unicast and multicast packets.
 Sure. When the MN sends Mcast data with the source address MN-HOA to MAG,
the MAG acting as the DR checks whether the HNP is the same with the
physical interface of the MAG. Since the MAG has not any physical
interfaces assigned with MN's HNP, the check of direct connection might
fail.

Regards,
Aaron

---

From: Stig Venaas <[email-masked]>
Date: Wed, 21 Dec 2011 11:15:38 -0800

On 12/16/2011 1:08 AM, Aaron Feng wrote:
> Sure. When the MN sends Mcast data with the source address MN-HOA to
> MAG, the MAG acting as the DR checks whether the HNP is the same
> with the physical interface of the MAG. Since the MAG has not any
> physical interfaces assigned with MN's HNP, the check of direct
> connection might fail.

Whether an interface is physical or not does not matter. What happens
on several implementations (I think probably Linux and BSD as well) is
that if you have an interface with an IP address and mask, you install
a route in the RIB corresponding to this and with some flag marking it
as directly connected (i.e., no next-hop). PIM can then use this to
determine that the source is directly connected.

For PIM to work with PMIP on the MAG, you may need to either ensure that
these routes are installed, or have PIM use other information than just
the RIB.

Is your concern that the MAG may not have an interface corresponding to
the MAG-MN tunnel? I guess this depends on the implementation, and how
the tunnel is realized.

Stig

> Regards,
> Aaron
>
>
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob