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

["Hui Deng" <[e-mail]>]

Hi, Thomas

It seems my question wasn't answer, does PMIP6 need extention to support
local routing?

Regarding to your suggestion, that scenario in pmip solution is just
briefly mentioned.
other than our figure plus detail description. It might be ok that we could
describe local routing with similar word number like pmip6 rfc?

thanks

-Hui


2008/11/1 Thomas C. Schmidt <[e-mail]>

> Hi Hui,
>
> if I see things correctly, this scenario is already used in the pmipv6
> solution draft ... so it is probably helpful to first properly identify it
> in the requirements document.
>
> IMHO, as the main objective, the requirements document should clearly
> identify the "world we work in", i.e., all the requirements & constraints,
> as well as the general scenarios.
>
> If we suppress relevant issues here and bring them up in the solutions
> later, the might be neither transparent nor helpful.
>
> Best regards,
>
> Thomas
>
> Hui Deng wrote:
>
>> 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 <[e-mail] <mailto:
>> [e-mail]>>
>>
>>    Hi Behcet,
>>
>>    Behcet Sarikaya wrote:
>>
>>        [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.
>>
>>
>>    [thomas] This is a misunderstanding: Fig 2 does *not* refer to
>>    sender mobility.
>>
>>
>>        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.
>>
>>
>>    [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
>>
>>    --
>>    ° Prof. Dr. Thomas C. Schmidt
>>    ° HAW Hamburg, Dept. Informatik
>>    ° University of Applied Sciences
>>    ° Berliner Tor 7, D 20099 Hamburg, Germany
>>    ° Fon: [phone], Fax: -8409
>>    ° http://www.informatik.haw-hamburg.de/~schmidt
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multimob
>>
>

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