Subject: Re: [multimob] PMIPv6 Requirements Draft

From: <[email-masked]>
Date: Thu, 28 Aug 2008 09:30:19 +0200

Hi Hitoshi, 

Please see inline for comments.

Regards,
Pierrick

> -----Message d'origine-----
> De : Hitoshi Asaeda [mailto:[email-masked]]
> Envoyé : mercredi 27 août 2008 19:13
> À : [email-masked]
> Objet : Re: PMIPv6 Requirements Draft
> 
> (I moved this discussion to the ML. Sorry for some of you guys who
> don't catch the point.)
> 
> Hi Pierrick,
> 
> > MAG subscribing on behalf to the MN is just an example of solution
> > to illustrate the purpose. However this example is not supposed to
> > be in the requirement draft.
> 
> Right.
> 
> > But just to clarify my purpose; this
> > example is inspired from the way a DVB-(T or H) gateway is
> > performing IP multicast management: the gateway subscribes to
> > multicast groups and then broadcasts multicast flows on the radio
> > link.
> 
> Well, this assumption will depend on the service model. So, I think
> the example, "MAG subscribs on behalf to the MN", is not the common
> case described in the requirement draft.
> 
> > > I cannot remember there is a definitive assumption that oMAG and nMAG
> > > have link. It may be possible as an extension for CT, but it depends
> > > on the configuration of PMIP. Am I wrong?
> >
> > You're right, PMIP does not assume interface between MAGs; actually
> > I was thinking to "something" similar to inter-MAG data forwarding
> > as per PFMIP:
> > http://tools.ietf.org/html/draft-yokota-mipshop-pfmipv6-03
> >
> > Anyway, R4.1 and R4.2 are clues for solution and should be out of
> > the scope of the requirement draft. So, the requirement to
> > retain here is only R#4 : Minimise cost on the forwarding link
> > (upstream link from the new MAG)
> 
> Right.
> 
> > > > R#6 scalability: solution must be scalable (basically solution
> > > >  should not consider the LMA as a mulicast traffic bottleneck; the
> > > >  LMA should not have to maintain a list of subscribed groups per all
> > > >  MN in its PMIP domain)
> > >
> > > In my sense, as the requirement, this statement is too strong.
> > > Maybe it is necessary to detail the use case.
> >
> > I agree this is a strong requirement for the solution; clearly the
> > draft should detail the use-case. But rapidly, the idea is that this
> > requirement is linked to Scalability and reliability; as Dirk wrote,
> > the solution should avoid single point of failure. Can we agree on
> > this requirement?
> 
> Sorry, my comment was ambiguous.
> Yes, I agree that the scalability issues should be descrived in the
> requirement draft. The statement that seems to be too strong is;
> "LMA should not have to maintain a list of subscribed groups per all
> MN".
> Because it seems that you imply or imagin some definitive (or
> concrete) service model. I mean, the condition whether LMA maintains
> subscribers groups or not depends on the solution, and hence it's
> better if the statement is changed in order to fit more general
> scenario.

I missed the point, sorry... Ok, I agree

> 
> > > > R#7 access control: the network should be able to perfom admission
> > > > control
> > > > according to:
> > > >                         - resource availability on the access
> network,
> > > >                         - user profile (e.g. user subscription right)
> > > >                         - user preference (e.g. parental control)
> > > >
> > > Well, I'd like to know the detail for it..
> >
> > Well, this is typically an operator requirement for IPTV
> > service. Now I don't know if it affects design of multicast support
> > for PMIP; but I guess it brings requirements on the MAG to perform
> > admission control, as expessed in Hui's proposal (section 4).
> 
> Yes. As you said, it's an operator requirement especially for IPTV
> service. Admission control, accounting, and so on would be the one,
> too. They depend on the service model, not a requirement for
> protocol.
> 
> One question.
> Does this requirement draft include the consideration of service
> models? Or the main aim of this requirement draft is to clarify the
> issues or roles of IP multicast protocols (IGMP/MLD and routing
> protocols) and behaviors for entities of PMIP?
> I thought the latter. (That's why I asked "Is it necessary for the
> requirement for PMIP?" in my previous mail.)
> 
> Folks, what do you think?

I agree that requirement draft is not supposed to include consideration on service. But I suspect that some service features may lead to requirement on PMIP entities; that's why we put some requirements on admission control.
> 
> > > > R#8 security: some multicast flows could be ciphered (same
> > > >  requirement as access control?)
> > >
> > > Is it necessary for the requirement for PMIP?
> >
> > To clarify the context: the use-case here is pay-per-view TV. As
> > preceding, I don't know if it affects design of multicast support
> > for PMIP. But it is clearly a service requirement.
> 
> Right. This is the service requirement.
> 
> > > > R#10 assuming a multi-interface terminal, the solution should
> > > >  support inter-technology handover (the MN should be able to switch
> > > >  multicast flow from one interface to another)
> > >
> > > Is it necessary for the requirement for PMIP?
> >
> > For operators (at least for FT ;-)), inter-technology handover is
> > probably the first use-case for PMIP. It is also true for mobile
> > multicast services. Now, does it bring a requirement for multicast
> > PMIP? I don't know but since this issue is discussing for PMIP I
> > guess we should address the point.
> 
> IMO, this issue is not only for PMIP. Well, the discussion may be
> exciting :), but it may be better to be addressed or described in a
> separate draft.

I definitely agree solution could be addressed later (Of course, I do not expect a solution for October) but we could add inter-tech handover in the requirement draft. I mean, we can try to make requirement draft as exhaustive as possible; then solution draft expected for October could meet only a subset of these requirements. 

> But again, it depends on the goal of this draft. If this draft will
> consider service models, then it'd be possible to be inside of this
> draft.
> 
> Thanks,
> --
> Hitoshi Asaeda

Pierrick
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob