Subject: Re: [multimob] PMIPv6 Requirements Draft Updated

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 17 Sep 2008 17:24:15 +0200 (CEST)

Hi Hitoshi et al,

I would like to take some counter positions:

Am Mi, 17.09.2008, 16:23, schrieb Hitoshi Asaeda:
>> > 1. 3.1
>> >    "R1 - PMIPv6 multicast mobility management MUST transparently
>> support
>> >    the reception of ASM and SSM channels."
>> >    Why MUST? It's too strong assumption. Some SPs may want to support
only SSM. In my sense, SSM is MUST, ASM is MAY.
>> ==> if I replace "and" by "or", does it remove your concern?
>
> No, not really. ASM and SSM are independent.
> In fact, I'd rather simply say, "SSM must be supported in PMIPv6
multicast."

ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and
currently we see an IPTV  deployment on the basis of ASM (SSM strength is
interdomain transparency, which is not needed nor desired in
provider-bound IPTV offers).

Anyway, the multicast flavor to actually deploy is the choice of any 
individual provider ... but we want to define protocols (multicast
extensions to PMIPv6), which enable such deployment. Therefore we should
offer both multicast flavors and preserve the choice.

Also: from the client perspective, ASM is easier to implement. Since we
are not heading to re-define multicast core routing (I suppose), we don't
have to worry about ASM-specific problems in the inter-domain. That we can
leave to the providers ... and to the work of the multicast routing WGs.

>> > 3. 4.2
>> >    "Hence support of MLDv2 [RFC3810] is required at the MAG." I
prefer to say, "MLDv2 or LW-MLDv2 is required". This document only
discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not needed?
>> ==> fine, thanks
>
> Since this document only discusses ipv6, so only saying MLDv2 and
LW-MLDv2 is fine.

There have been earlier (striking) arguments by Patrick to keep the MLD
debate(s) out of this document. The issue here is the version 2, which is
needed for SSM. Otherwise I would agree with Patrick to remain agnostic of
MLD flavors and optimizations.

>> >    CAC is common word except with ATM? :)
>> ==> Sure, but prefer remove "CAC", keep "Connection Admission Control"
>>
>> >    Anyway, we should put more functional statements; what functions
are needed, and why.
>> ==> Please try to propose it, thanks,
>
> Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA
should be preserved at LMA".
> Sect.4.2 says "CAC is supported at MAG, Network Attachment Control
should be supported at MAG".
>
> In my feeling, the current statements require implementing these
functions in multicast protocols used in PMIPv6.
> At first, these statements should be explained from operators
> viewpoint. Not "LMA should control bw, MAG supports CAC", but
> "Controlling bw is an operational requirement and may be implemented at
LMA". Then improve the whole sentence. (What are other operators'
requirement and why.)

Here I agree with Hitoshi: The whole section 4 is problematic, if it is
taken to be more than a general Caveat of the type "Here are things we
also should consider".

May be it should be rephrased as "General Architectural Background", or so.

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: <[email-masked]>
Date: Thu, 18 Sep 2008 11:21:26 +0200

Hi Thomas and Hitoshi,

I see your concern about section 4, so I suggest the following rewording:

------------------------------------------

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.

   - 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.

   - Network Attachment Control: the attachment control should be
   supported by a multicast control function and multicast replication
   function.

- 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.

--------------------------------------

What do you think?

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Thomas C. Schmidt
> Envoyé : mercredi 17 septembre 2008 17:24
> À : Hitoshi Asaeda
> Cc : [email-masked]
> Objet : Re: [multimob] PMIPv6 Requirements Draft Updated
> 
> Hi Hitoshi et al,
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 18 Sep 2008 11:50:42 +0200 (CEST)

Hi Pierrick,

thanks for the proposal: I'm fine with your formulation!

Best regards,

Thomas

Am Do, 18.09.2008, 11:21, schrieb [email-masked]:
>    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,
>    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.
>
>    - 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.
>
> - 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.
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 19 Sep 2008 12:59:02 +0900 (JST)

Hi Pierrick,

Looks better now. Thanks.

Several small comments below.

>    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,
>    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

This is not "multicast session control", which includes many general
meanings.
"AAA functions" is straightforward for your statement.

>    - 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?

>    supported by a multicast control function and multicast replication

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?

> - 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.

Thanks,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Mon, 29 Sep 2008 09:42:46 +0200

Hi Hitoshi,

Thanks fo the comments and sorry for the late reply, please see inline for clarifications.

Regards,
Pierrick

> De : Hitoshi Asaeda [mailto:[email-masked]]
> Envoyé : vendredi 19 septembre 2008 05:59
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]

I agree, we will fix that in next release. 

> 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.   

> it's up to other members' opinions.

I have no religion on that...