Subject: [multimob] Fwd: PMIPv6 extension for multicast

From: seil jeon <[email-masked]>
Date: Mon, 1 Aug 2011 17:15:24 +0900

Hi Hitoshi,

In your draft, GRE tunnel between a MAG and an LMA is used for multicat data
transmission.
I guess this tunnel is regardless of the association of the MN and the LMA.
So, it can establish only one tunnel between MAG and LMA and avoid tunnel
convergence issue.
But following conversation gives me confusion to understand your idea.
Could you clarify what I'm confused?

Your regards

---------- Forwarded message ----------
From: Thomas C. Schmidt <[email-masked]>
Date: 2011/7/27
Subject: Re: [multimob] PMIPv6 extension for multicast
To: Hitoshi Asaeda <[email-masked]>
Cc: [email-masked]

 Now following your answers and the presentation/discussion in the group,
>> the following seems to be clarified:
>>
>>  * You span static tunnels between all LMA-MAG pairs that are in the
>> deployment scenario you consider. (This is what we called a mesh, but
>> mesh is only a word.) In typical cases, you will add some hundreds of
>> multicast-initiated tunnel end points to a single LMA ...
>>
>
> As I said, it is not necessary to create static M-Tunnels to all
> LMA-MAG pairs. How many M-tunnels is set up is operators decision; it
> would be same to or less than the number of association between
> LMA-MAG. It can be adjusted by operators.
>
>
Thomas> Well, your solution builds on this M x N tunnel mesh. Of course, an
operator can choose not to deploy it :-)

______________________________**_________________
 multimob mailing list
[email-masked]
https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 01 Aug 2011 18:14:55 +0900 (JST)

Hi Seil,

> In your draft, GRE tunnel between a MAG and an LMA is used for multicat data

Establishing M-Tunnel is operator's demand.
If operators configure M-Tunnel to set up special mroutes, then the
mroutes using M-Tunnel will be inserted into MRIB and PIM-SM on MAG
uses the MRIB.
If they do not configure M-Tunnel (as they don't need to distinguish
multicast path and unicast path or they decide to inherit RIB to
MRIB), then PIM-SM on MAG simply selects the regular IPv6-IPv6 tunnel
by the RPF.

> I guess this tunnel is regardless of the association of the MN and the LMA.

Right. It does not depend on the MN-LMA association.

> So, it can establish only one tunnel between MAG and LMA and avoid tunnel

No, the tunnel convergence problem is solved by the RPF, not M-tunnel.

> Could you clarify what I'm confused?

Well, I recognize M-Tunnel makes people confuse. And it is not the
mandatory function for our solution. So I will remove it from the next
revision.

Sorry for your confusion.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Aug 2011 14:04:53 -0700 (PDT)

Hi Hitoshi,
  Two cases need to be clarified, I think. One is PIM-SM 
at the MAG for multicast traffic to/from MNs and the other one is 
so-called local routing or how to connect the multicast source to the 
MAG as PIM-SM router.

As far as I can see, the first case is more
 or less clarified, i.e. PIM-SM can probably work with MAG routing 
tables and it would also avoid the tunnel convergence problem.

I am not sure about the second one.

Regards,

Behcet

PS. sorry for the duplicates.

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 09 Aug 2011 18:16:32 +0900 (JST)

Hi Behcet,

> I am not sure about the second one.

This draft does not describe source mobility and local routing.
What this draft says is that if MAG can coordinate appropriate
MRIB, PIM-SM on MAG can cooperate with local routing to deliver IP
multicast packets for mobile nodes.

I guess the discussion how to coordinate appropriate MRIB *for local
routing* in PMIPv6 should be discussed in a separate draft, whose
title would be "Localized multicast routing for PIM-SM capable
PMIPv6". This draft work definitively needs to refer to
draft-ietf-netext-pmip-lr.
I'm happy to work on this topic after our PMIPv6 extension draft
becomes the WG draft (because that draft will be also referred).

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 9 Aug 2011 09:34:32 -0700 (PDT)

> becomes the WG draft (because that draft will be also referred).

In my latest discussion with Stig, Stig mentioned that PIM-SM assumes 
that the source is directly connected. What do you think about this?
If we assume this then we don't need another draft.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 10 Aug 2011 02:05:57 +0900 (JST)

> In my latest discussion with Stig, Stig mentioned that PIM-SM
> assumes that the source is directly connected. What do you think
> about this?

Source is directly connected to what? MAG?
If source is directly connected to MAG, then the localized routing
situation should be considered, right?

Let's see, except the case that a mobile node is a multicast source,
our PMIPv6 extension solution works well, I think.
But for that case, because HNP is routed to LMA, all MN's traffic goes
through LMA and then LMA forwards the traffic to the downstream
routers (e.g. MAG). This route causes higher delay and congestion in
the network and requires the localized routing solution discussed as
in draft-ietf-netext-pmip-lr.

> If we assume this then we don't need another draft.

I'll follow the WG decision.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 9 Aug 2011 11:15:58 -0700 (PDT)

> situation should be considered, right?

Yes.
Directly connected source to the MAG becomes a problem for RFC 6224 for which probably there is no solution.

> in draft-ietf-netext-pmip-lr.

Source mobility issue is a bit away from the current concerns.

draft-ietf-netext-pmip-lr is about LMA authorized  routing by the MAG to other MAGs. 
If the destination is one of the MNs downstream, MAG can send it directly as per RFC 5213.

Regards,

Behcet

---

From: seil jeon <[email-masked]>
Date: Wed, 10 Aug 2011 14:48:18 +0900

Hi Behcet and Hitoshi,

Please see the below.

2011/8/10 Behcet Sarikaya <[email-masked]>

> which probably there is no solution.

Our "Direct/Local Routing" technique is well-suited for this case. In
particular, our solution includes the case that MR is integrated together
with MAG as we presented the description and slide in Quebec meeting.

> If the destination is one of the MNs downstream, MAG can send it directly
I aggre with Behcet's opinion. I think we're discussing which is appropriate
solution to solve tunnel convergence problem derived from "Base Solution" of
PMIPv6 multicasting. I believe that topic may be covered in the slot of
source mobility.

Your regards,

Seil Jeon

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 10 Aug 2011 17:50:19 +0900 (JST)

> Source mobility issue is a bit away from the current concerns.

Right.
I only reply your question; "so-called local routing", "how to connect
the multicast source to the MAG as PIM-SM router?"

Once again, I said;

1. our PMIPv6 extension draft does not describe localozed routing and
   source mobility (while our solution has good affinity with these
   functions, I believe)
2. if there is the request for localized routing and source mobility
   with our approach, I will work for providing the corresponding new
   document for localized routing along with our current solution.
   (but if not, I won't do for it at the current stage.)

>  directly as per RFC 5213.

I don't think RFC5213 provides the complete localized routing
function; it only mentions "the mobile access gateway MAY optimize on
the delivery efforts by locally routing the packets and by not reverse
tunneling them to the mobile node's local mobility anchor."

According to RFC6279 (problem statement) and draft-ietf-netext-pmip-lr, 
four scenarios for localized routing should be considered; A11: Two
MNs attached to the same MAG and LMA, A12: Two MNs attached to
different MAGs but same LMA, A21: Two MNs attached to the same MAG
with different LMAs, and A22: Two MNs attached to the different MAGs
with different LMAs.
In fact, RFC5213 describes EnableMAGLocalRouting flag, which could
become a localized routing handler. However, this flag only supports
A11 case *potentially*. (*Potentially* means, as said above, RFC5213
does not mention the detail procedure even for A11.)

This is the reason that if our solution that inherits RFC5213 as the
PMIPv6 base spec needs to support localized routing (i.e. A11 to A22),
it is necessary to provide a new document ("Localized multicast routing
for PIM-SM capable PMIPv6") or put a major section describing localized
routing in our current draft.
(I think the latter is not a good idea, though.)

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Aug 2011 08:35:24 -0700 (PDT)

Hi Seil,
  Yes, if you integrate MR with MAG, "local routing" would work. 

I think that for PIM-SM at the MAG, MR should be directly connected.

Regards,

Behcet

>Our "Direct/Local Routing" technique is well-suited for this case. In particular, our solution includes the case that MR is integrated together with MAG as we presented the description and slide in Quebec meeting.
> 
>>
>I aggre with Behcet's opinion. I think we're discussing which is appropriate solution to solve tunnel convergence problem derived from "Base Solution" of PMIPv6 multicasting. I believe that topic may be covered in the slot of source mobility.
> 
> 
>Your regards,
> 
>Seil Jeon
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Aug 2011 08:53:03 -0700 (PDT)

Hi Hitoshi,
  It seems like you are confused about the local routing. I meant in the sense of locally routing the multicast traffic, not unicast. Basically it is referring to Seil's draft.

What you are referring to below is probably in the context of source mobility. My suggestion is to take a look at the solution draft. PS draft has more scenarios and solution document addressed only some of the scenarios. Checking Shuai's draft might be helpful.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 11 Aug 2011 01:33:52 +0900 (JST)

Behcet,

>   It seems like you are confused about the local routing. I meant in
> the sense of locally routing the multicast traffic, not
> unicast. Basically it is referring to Seil's draft.

See section 6.10.3 of RFC5213. It mentions "Local Routing".
And also, please check RFC6279. The document title is "PMIPv6 Localized
Routing PS".
These RFCs clearly define the local (or localized) routing (and
draft-ietf-netext-pmip-lr tries to provide the solution).

It seems Seil wants to discuss "direct routing", in which MAG
communicates with MR located in PMIPv6 domain without LMA's
interaction.
Don't you and Seil mix local routing and direct routing?

BTW, what does "in the sense of locally routing the multicast traffic,
not unicast." mean? I cannot understand this statement.

> What you are referring to below is probably in the context of source
> mobility. My suggestion is to take a look at the solution draft. PS
> draft has more scenarios and solution document addressed only some
> of the scenarios. Checking Shuai's draft might be helpful.

Source mobility in PMIPv6 means the way to support that a source
mobile node moves from p-MAG to n-MAG. Source mobility requires PMIPv6
to support localized routing and needs to discuss how sourced contents
could be seamlessly served to listener MNs during handover.
Localized routing is the core function of source mobility.

This is my understanding.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Aug 2011 09:57:38 -0700 (PDT)

> Don't you and Seil mix local routing and direct routing?

Maybe you are right, it should be called direct routing. I used to call it locally available multicast.
Local routing is PMIPv6 term referring to the unicast routing.

> not unicast." mean? I cannot understand this statement.

PMIPv6 documents you mentioned above are about unicast routing. 
What I was talking about is locally available multicast.

> Localized routing is the core function of source mobility.

No. 

Source mobility is MN is multicast source and of course MN maybe moving.

This is the subject of Shuai and Thomas drafts.

Is everything clear now?

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 11 Aug 2011 02:24:11 +0900 (JST)

> Local routing is PMIPv6 term referring to the unicast routing.

Ok, slightly agreed.
But local routing is also appricable for multicast in the same
concept.

> PMIPv6 documents you mentioned above are about unicast routing. 

Of course. Because RFC5213 does not mention multicast. But the same
terminology and concept for localized routing are used for multicast.
So, my comment is for both unicast and multicast.

> What I was talking about is locally available multicast.

What is "locally available multicast"? Who is the source?
If the source is MN attached to MAG, then localized routing should be
considered.
If the source is not MN, then our current draft works well.

>> Localized routing is the core function of source mobility.

Why No? :)

> Source mobility is MN is multicast source and of course MN maybe moving.

I said the same thing above (with more explanation).

> This is the subject of Shuai and Thomas drafts.

Sorry, maybe I'm not clear your thought.

>    (but if not, I won't do for it at the current stage.)

What is the problem for you? What do you ask for our draft?

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Aug 2011 11:34:57 -0700 (PDT)

> If the source is MN attached to MAG, then localized routing should be

Locally available multicast means the source is in the access network, 
multicast data is not coming from LMA. Or what you call direct routing. 

I agree that it should not be called local routing, Seil please take note. Seil also uses direct routing which is OK.

> If the source is not MN, then our current draft works well.

I am not sure, it needs to be clarified as to how it works. It seems like the source directly connected to MAG will work.

> I said the same thing above (with more explanation).

We are in agreement then.

Regards,

Behcet

---

From: seil jeon <[email-masked]>
Date: Thu, 11 Aug 2011 16:07:33 +0900

Hi Behcet and Hitoshi,

Please see the below.

2011/8/11 Behcet Sarikaya <[email-masked]>

> I agree that it should not be called local routing, Seil please take note.
> Seil also uses direct routing which is OK.
>
> I am not sure, it needs to be clarified as to how it works. It seems like
> the source directly connected to MAG will work.
>
>

According to the shared meaning through multimob discussion, I think Behcet
is correct here. To avoid confusion of the meanings of direct routing and
local routing, the definitions of two terms were given through my slide in
Quebec meeting. (Of course, those were defined by me.)

- Direct routing
: multicast data is transmitted from a source to a MN using "Native
Multicasting Infrastructure" within operator's network

- Local routing
: content source is directly connected a MAG. There's no need of multicast
routing protocol to retrieve multicast data but MLD proxy function is needed
on a MAG to exchange MLD signaling and multicast data between an MN and a
source.

When we follow the definition of local routing, there's actually no issue of
"routing" because "routing" is not used in here. Somewhat  "Local Content
Delivery" may be much closer. Now, we call it "local routing" simply.

For local contents delivery, it seems that there's no reason for the
operators to provide the contents through the LMA but direct connection with
a MAG is natural.

Now, we go back the Behcet's original question. Behcet is asking your
solution is feasible for local routing case or not.Isn't it, Behcet?

---

From: seil jeon <[email-masked]>
Date: Thu, 11 Aug 2011 18:50:41 +0900

Hi Behcet,

> I think that for PIM-SM at the MAG, MR should be directly connected.

That's right.

But in the case, any MR protocol is possible as well as PIM-SM because
there's no need of "routing" action.

Regards,

Seil Jeon