Dear all,

As requested we have been working on a proposal for updating current DMM Requirements draft, reflecting the work developed in "draft-sfigueiredo-multimob-use-case-dmm-03.txt". We were careful to follow the expressed concerns, mainly by not impacting the current (mostly accepted) draft structure and content.
As such, we propose the following 2 changes:

# Proposal 1 - small update to PS1 #

PS1: Non-optimal routesRouting via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), *or when using IP multicasting*.


# Proposal 2 - Add a new requirement#

REQ8: Flexible multicast distribution

"DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6.

PS6: Duplicate multicast traffic

IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the tunnel's downstream entity (e.g. MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].


Best regards,
Sérgio & Seil


On 11/12/2012 10:49 PM, Seil Jeon wrote:
Hi Pete,

That might be one of them we can take on DMM. Imagine, depending on
deployment of existing IP multicasting standard entities, we can think of
various use cases as presented in
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03.
Direct routing cannot be applied in every scenario.

After I came back from the trip, we (me and Sergio) have been working on
this with priority. After carefully reviewing the requirement from the use
cases, we'll announce it soon.

Regards,
Seil

-----Original Message-----
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter
McCann
Sent: Monday, November 12, 2012 9:53 PM
To: Thomas C. Schmidt
Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org
Subject: Re: [DMM] Multicast requirements

In the DMM case my assumption is that the anchor points are closer to the
access routers and therefore are very likely to be in the same
administrative domain.  In these cases, joining the multicast group directly
from the access router gives you the same access to the same multicast
streams and so tunneling the multicast packets won't be necessary.

-Pete

Thomas C. Schmidt wrote:
Dear Pete,

multicast mobility management is a route adaptation problem. As in the
unicast case, mobility can only be treated by routing dynamics in
trivial cases (re-connect of a tunnel, re-association with next hop).
Otherwise it is unwise to delegate mobility adaptation to routing
protocols (-> OSPF, BGP ...).

Accordingly, if DMM distributes mobility operations, handover
management should foresee easy interconnects to previous distribution
trees - both for receivers and for mobile multicast sources.

I guess, if DMM people are careful, this is not a world-class item and
can be treated along the lines of unicast solutions - an isolated
multicast protocol treatment (as has been previously proposed from
MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment
has turned out to work out simply (-> RFC6224).

Thus my argument: talk to the multicast guys before adopting a
solution ... and make the rest an easy game.

Cheers,

Thomas

On 12.11.2012 21:39, Peter McCann wrote:
jouni korhonen wrote:
Folks,

This mail is to kick off the discussion on multicast requirement(s)
for the draft-ietf-dmm-requirements-02 document. I hope we can nail
down the essential multicast requirement(s) as soon as possible.
To me, multicast in a DMM environment means joining multicast groups
directly from access routers.  It means re-joining the multicast tree
from a new access router after handover.  I would hope that we can
use existing MLD protocols between the MN and its first hop AR to
accomplish this.

-Pete

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to