Subject: [multimob] Proposals and charter discussion

From: Stig Venaas <[email-masked]>
Date: Fri, 30 Oct 2009 14:30:49 -0700

The main goal of our meeting in Hiroshima is to see if we can adopt
documents for our charter work items. In addition to the technical
evaluation, we also need to consider whether documents are within our
charter. Either whether the document is currently within the charter,
or if it can easily be updated to be within the charter.

For PMIP, we have the following milestone:

Nov 2009 Initial version of a document explaining the use of multicast
in PMIPv6

It might be good to get some discussion on the list prior to the meeting
to see which proposals may be within the charter and a candidate for
this. We will certainly be discussing this in the meeting, but by having
some discussion and analysis on the mailing list before the meeting, we
may be able to have a better discussion at the meeting itself.

You should all read the charter at
http://www.ietf.org/dyn/wg/charter/multimob-charter.html

Some of the important points related to PMIP (this may not be a full
list, so read the charter itself) are:

1. Work requiring modifications to mobility protocols and IGMPv3/MLDv2
    is out of scope in this first stage of this working group.
    Modifications to multicast routing protocols are out of scope.

2. This work will not require any additions or changes to message types
    and parameters specified in RFC 5213,

3. and must assume an unmodified mobile host.

4. The work will employ the remote subscription model. This is a
    mechanism by which a mobile node joins a multicast group and
    receives multicast data forwarded via the local mobility anchor.

I hope I've given managed to point out the main points in the charter in
a fair way. It's the charter text itself that is important, not what I
write here though.

I now hope we can get some discussion on whether the different proposals
match the points above, or if you like, the charter text.

Stig, co-chair hat on

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 30 Oct 2009 23:04:06 +0100

Hi Stig,

if I overlook proposals correctly, there are three contributions that 
comply to the charter:

[Direct Routing Option:]
If native multicast routing reaches all MAGs in a PMIP domain, then 
straight-forward MLD proxying can be applied at MAGs with neither 
participation of the LMAs, nor tunneling.
This is proposed in parts of [draft-sijeon-multimob-mms-pmip6-01], if 
you strip context transfer and predictive operations off the document.

[Dedicated Multicast LMA:]
If all multicast traffic of an entire PMIP domain is managed by a single 
LMA, then all MAGs may choose a tunnel with this particular LMA for 
multicast uplink. There is no need for proxy binding caches and 
MN-specific states at the LMA.
This is proposed in section 3. of [draft-zuniga-multimob-smspmip-00], if 
you strip handover-specifics off the document.

[Proxy instance per LMA:]
If multicast traffic in PMIP should follow unicast paths, then it 
arrives at the MN via MN-specific LMAs and MAGs on the basis of proxy 
binding caches. This approach is a direct extension of unicast, 
facilitated by placing a proxy instance per MAG-LMA uplink on MAGs and 
proposed in [draft-schmidt-multimob-pmipv6-mcast-deployment].

 From my understanding of the available documents, no further 
contributions exist that comply to the charter (i.e., do not change PMIP 
or multicast protocols, or the processing/semantics at corresponding 
routers).

Hope that clarifies the field ;)

Cheers,

Thomas

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 30 Oct 2009 15:13:10 -0700

> participation of the LMAs, nor tunneling.

I think that is nice, when native multicast is available. But would
not direct routing violate the "remote subscription" requirement?
Maybe it's OK for a proposal to have this as an alternative if no added
complexity?

Note that I'm responding as an individual here. Just my personal
opinion.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 30 Oct 2009 23:21:57 +0100

Hi Stig,

Stig Venaas wrote:

> I think that is nice, when native multicast is available. 

I think so, too. This is extremely simple and elegant, when multicast
traffic touches the Access Routers.

> But would

I don't think so: if it is there, you can use it. There is no sense in
neglecting services that are offered at your door, but buy them more
expensive at a remote location.

> Maybe it's OK for a proposal to have this as an alternative if no added
Yes, I believe so: this is a very good "optimization option" in the
presence of appropriate service infrastructure. It of course cannot be
the default, as it would require all operators to establish access
networks that provide full (inter-domain) multicast support.

Thomas

-- 

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 30 Oct 2009 15:33:27 -0700

> traffic touches the Access Routers.

Yes, I agree. I see one maybe minor issue though. Depending on the
network topology, you may have to wait for construction of new branches
on the multicast tree. I mean, if you move to somewhere else in the
topology, then there may be no previous joins from the router you move
to. While when you keep tunneling back to the same LMA, all multicast
tree state can be in place.

> networks that provide full (inter-domain) multicast support.

Right. So we need at least a solution that can work with remote
subscription. I think it would be great to have a solution that easily
can accommodate local subscription and direct routing. But if that means
additional complexity, then I feel that should be documented separately
as possible enhancements.

I think we should mostly ignore direct routing now. But I do have a
personal preference for solutions where that can be a simple future
extension.

I think for the MLD-proxy at MAG proposals, it is simply a matter of
configuring which interface is upstream.

Stig

---

From: "Seil Jeon" <[email-masked]>
Date: Sat, 31 Oct 2009 15:14:09 +0900

Hi Stig,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stig Venaas
Sent: Saturday, October 31, 2009 7:33 AM
To: Thomas C. Schmidt
Cc: [email-masked]
Subject: Re: [multimob] Proposals and charter discussion

Thomas C. Schmidt wrote:
> Hi Stig,
>
> Stig Venaas wrote:
>
>>> if I overlook proposals correctly, there are three contributions
>>> that comply to the charter:
>>>
>>> [Direct Routing Option:]

Yes, I agree. I see one maybe minor issue though. Depending on the network
topology, you may have to wait for construction of new branches on the
multicast tree. I mean, if you move to somewhere else in the topology, then
there may be no previous joins from the router you move to.

=> Yes, it may happen dependent on network topology. To solve join latency,
I proposed pre-join mechanism (context text tranfer).
     However, for real deployment, resource provisioning will be used. That
is, all channel will reach at the multicast router or designated  router.
Then, local multicast router can easily and fastly join the new stream.

While when you keep tunneling back to the same LMA, all multicast tree
state can be in place.

>> Maybe it's OK for a proposal to have this as an alternative if no
>> added complexity?
>>

Right. So we need at least a solution that can work with remote
subscription. I think it would be great to have a solution that easily can
accommodate local subscription and direct routing. But if that means
additional complexity, then I feel that should be documented separately as
possible enhancements.

Stig

---

From: "Seil Jeon" <[email-masked]>
Date: Sat, 31 Oct 2009 15:21:20 +0900

Hi Stig & multimob friends,

For the technical evaluation, I would introduce the effect of tunnel
convergence problem.

We compare and analyze four cases : bi-directioal, MoM, MMG and our PMIPv6
solution.

You can search the document at IEEE Xplore as a following name.

"Mobility Management based on Proxy Mobile IPv6 for Multicasting Services
in Home Networks"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stig Venaas
Sent: Saturday, October 31, 2009 6:31 AM
To: [email-masked]
Subject: [multimob] Proposals and charter discussion

The main goal of our meeting in Hiroshima is to see if we can adopt
documents for our charter work items. In addition to the technical
evaluation, we also need to consider whether documents are within our
charter. Either whether the document is currently within the charter, or if
it can easily be updated to be within the charter.

Nov 2009 Initial version of a document explaining the use of multicast in
PMIPv6

It might be good to get some discussion on the list prior to the meeting to
see which proposals may be within the charter and a candidate for this. We
will certainly be discussing this in the meeting, but by having some
discussion and analysis on the mailing list before the meeting, we may be
able to have a better discussion at the meeting itself.

Some of the important points related to PMIP (this may not be a full list,
so read the charter itself) are:

I hope I've given managed to point out the main points in the charter in a
fair way. It's the charter text itself that is important, not what I write
here though.

Stig, co-chair hat on