Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Oct 2008 13:36:27 -0700 (PDT)

Hi Thomas,

----- Original Message ----
From: Thomas C. Schmidt <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Hui Deng <[email-masked]>; [email-masked]
Sent: Thursday, October 23, 2008 3:16:10 AM
Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

Hi Behcet,

Behcet Sarikaya wrote:

> It is not exactly clear why you state "Figure 2 depicts local routing
> as something totally different" ??? -
> what is expressed here: a content source local to the PMIP-domain - but
> not local to a particular MAP.
> 
> [behcet] In PMIP6 there is no MAP. You mean MAG here?

[thomas] Yes, sorry for the misprint.
> 
> And in consequence a (multicast) routing
>   within the PMIP domain without LMA-MAG tunneling. That's what the text
> says, as well.
> 
> [behcet] In PMIP6, the nodes between MAG and LMA do not matter because 
> all traffic is tunneled.

[thomas] except for the local routing option as described in section 
6.10.3 of RFC 5213. Here a local routing is foreseen between two unicast 
nodes on the same access link.

> Local routing in Fig. 2 would refer to a packet sent from MN1 to MN2 
> being routed by MAG1 locally without tunneling it to LMA1.
> If the packet MN1 sends is a multicast packet, RFC 5213 does not 
> describe how such a packet would be routed. Is this what you are trying 
> to address?
> 
[thomas] RFC5213 does not address multicast routing (that's why we are 
discussing it). The scenario described in fig 2 is *not* addressing 
mobile multicast senders, 

[behcet] Then I think the text and figure on the local routing is not needed because local routing in PMIPv6 refers to the routing of packets coming from the uplink and as you said this would be multicast sender situation which you left out in the requirements draft.

but a typical content distribution setting as 
for instance used in a provider-centric IPTV service. This means, a 
provider issues multicast streams from within his network domain, aiming 
at an efficient way to preserve (his own) network resources.

From the minimal perspective of RFC5213 (unicast routing) there is no 
efficient way to do this. That's why we are trying to identify protocol 
extensions that smoothly cooperate with RFC 5213.

[behcet] The situation you are talking about could become valid if route optimization is used with PMIPv6. In that case the content server in between MAG and LMA would send directly to MAG. If route optimization is not used then all traffic goes through LMA-MAG tunnel. Route optimization for PMIPv6 is some future work, there are drafts but we don't know if the standardization will go ahead.
Route optimization with multicasting is even more complicated problem. If you wish to state some requirements for this very complicated case please go ahead.
Best regards,

Behcet

Best regards,

Thomas

-- 

° Prof. Dr. Thomas C. Schmidt
° HAW Hamburg, Dept. Informatik
° University of Applied Sciences
° Berliner Tor 7, D 20099 Hamburg, Germany
° Fon: +49-40-42875-8452, Fax: -8409
° http://www.informatik.haw-hamburg.de/~schmidt

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 23 Oct 2008 22:59:12 +0200

Hi Behcet,

Behcet Sarikaya wrote:

> [behcet] Then I think the text and figure on the local routing is not 
> needed because local routing in PMIPv6 refers to the routing of packets 
> coming from the uplink and as you said this would be multicast sender 
> situation which you left out in the requirements draft.
>

[thomas] This is a misunderstanding: Fig 2 does *not* refer to sender 
mobility.

> [behcet] The situation you are talking about could become valid if route 
> optimization is used with PMIPv6. In that case the content server in 
> between MAG and LMA would send directly to MAG. If route optimization is 
> not used then all traffic goes through LMA-MAG tunnel. Route 
> optimization for PMIPv6 is some future work, there are drafts but we 
> don't know if the standardization will go ahead.
> Route optimization with multicasting is even more complicated problem. 
> If you wish to state some requirements for this very complicated case 
> please go ahead.

[thomas] Hmm, I'm not trying to add complicated requirements. This is 
the overview about possible scenarios.
  We're all just trying to think of a reasonable scope to address and 
solve the problem (so does the recent pmip6-extension-draft ... see also 
the last mail from Hitoshi).

If multicast on PMIPv6 is supposed to serve as a solution for 
large-scale content distribution (like in IPTV applications), then we 
should not just propose to tunnel all traffic from one LMA to the MAGs. 
That's a bitter pill for those who have to pay for the infrastructure.

Best regards,

Thomas

--

---

From: "Hui Deng" <[email-masked]>
Date: Sat, 1 Nov 2008 11:08:14 +0800

Hi,  Thomas,

I agree this scenario works for some deployment, but question here is
whether we need extend any pmip6 protocol to support this scenario?

thanks

-Hui

2008/10/24 Thomas C. Schmidt <[email-masked]>

>> optimization is used with PMIPv6. In that case the content server in between
>> MAG and LMA would send directly to MAG. If route optimization is not used
>> then all traffic goes through LMA-MAG tunnel. Route optimization for PMIPv6
>> is some future work, there are drafts but we don't know if the
>> standardization will go ahead.
>> Route optimization with multicasting is even more complicated problem. If
>> you wish to state some requirements for this very complicated case please go
>> ahead.
>>
>
> [thomas] Hmm, I'm not trying to add complicated requirements. This is the
> overview about possible scenarios.
>  We're all just trying to think of a reasonable scope to address and solve
> the problem (so does the recent pmip6-extension-draft ... see also the last
> mail from Hitoshi).
>
> If multicast on PMIPv6 is supposed to serve as a solution for large-scale
> content distribution (like in IPTV applications), then we should not just
> propose to tunnel all traffic from one LMA to the MAGs. That's a bitter pill
> for those who have to pay for the infrastructure.
>
>
> Best regards,
>
> Thomas
>
> --
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 01 Nov 2008 14:31:37 +0900 (JST)

Hi,

> whether we need extend any pmip6 protocol to support this scenario?

The protocol extension should be as simple as possible. And if the
base protocols such as PMIPv6/MLD/PIM do not support the functions we
have been discussing, then we should carefully identify the issues.
The key for identifying the issues is to recognize not only the
effectiveness of the protocol extension but also the generality and
independency of multicast services. I mean, the protocol extension
must be generally applicable and beneficial in a common mobile
multicast communication scenario, not only for some special cases/
services.

So, I'd like to again ask the question especially to operators who
plan to or may prepare PMIPv6 multicast services; Is there a big
impact or problem if all multicast traffic goes through an LMA-MAG
tunnel?

Note that our PMIPv6 multicast extension draft tentatively supports
the local routing, but I personally think it can be removed if
consensus.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 01 Nov 2008 14:41:05 +0900 (JST)

> the local routing, but I personally think it can be removed if

Well, it may not be necessary to completely remove the possibility
from the document, but specify "optional" as the minor case. Same for
the requirement draft.
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob