Subject: Re: [multimob] PMIPv6 Requirements Draft Updated

From: "Hui Deng" <[email-masked]>
Date: Wed, 1 Oct 2008 20:39:27 +0800

Hello, all

For ASM/SSM, since there is no persistant argument here, I plan to
keep SSM only, not mention ASM at the moment, see future other inputs.

For multicast control function and multicast replication function, this is a
more
IPTV related, doesn't clearly operate in our current scenario, I agree
Pierrick's
suggestion to group the two statements. Please Pierrick update the section
4.

I will update and submit it after shortly,

Many thanks for all your work.
Best regards,

-Hui

2008/9/29 <[email-masked]>

> Hi Hitoshi,
>
> Thanks fo the comments and sorry for the late reply, please see inline for
> clarifications.
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : Hitoshi Asaeda [mailto:[email-masked]]
> > Envoyé : vendredi 19 septembre 2008 05:59
> > À : SEITE Pierrick RD-RESA-REN
> > Cc : [email-masked]
> > Objet : Re: [multimob] PMIPv6 Requirements Draft Updated
> >
> > Hi Pierrick,
> >
> > Looks better now. Thanks.
> >
> > Several small comments below.
> >
> > > 4. Architecture requirements
> > >
> > >    Deployment of mobile multicast services for listeners,
> > > e.g. Mobile IPTV, may lead to operational requirements which MAY
> > > impact PMIPv6 architectural entities. These potential features are
> > > sketched in the following and may come in addition to protocol
> > > requirements, as listed in the preceding section:
> > >
> > >    - Multicast Bandwidth Control: the system should be able to
> > > control the total bandwidth of a user port that can be used for
> > > multicast service,
> > >    thereby monitoring the fraction of the total bandwidth consumed by
> > >    multicast.  This requirement may lead for the LMA to support a
> > > range of different service classes with various QoS requirements.
> > >
> > >    - Multicast session control: AAA functions, which may reside at
> > > the LMA, in particular admission control and accounting, SHOULD be
> > > preserved and applicable under multicast services.
> >
> > This is not "multicast session control", which includes many general
> > meanings.
> > "AAA functions" is straightforward for your statement.
>
> I agree, we will fix that in next release.
>
> >
> > >    - Connection Admission Control (CAC): it is an operational
> > > requirement that Connection Admission Control should be based on
> > > available resources.  This feature may be supported at the MAG.
> >
> > I don't recommend to use the word "CAC". As I said, it may not be
> > a common term except with ATM, no?
> > And the statement is a little ambiguous. What function do you require?
> >
> > >    - Network Attachment Control: the attachment control should be
> > >    supported by a multicast control function and multicast replication
> > >    function.
> >
> > This is also a bit ambiguous.
> > Multicast control means traffic control? Quality control? What
> > information is needed for what?
> > And what does multicast replication mean?
> >
>
> To clarify, I would suggest to group the two above statements in a single
> "access control" (or something like that) requirement. But it's typically an
> operational requirement, so, it would be valuable to hear Hui's opinion
> before modifying.
>
> > > - Considering deployment, it is foreseeable that the MAG MAY act as
> > > a multicast designated router.  Hence support of MLDv2 [RFC3810] MAY
> > > be required at the MAG.
> >
> > As I said, I perfer to also say "or LW-MLDv2" with MLDv2 here, but
> > it's up to other members' opinions.
> >
>
> I have no religion on that...
>
> > Thanks,
> > --
> > Hitoshi Asaeda
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob