Subject: [multimob] Fw: PMIPv6 Requirements Draft

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 28 Aug 2008 11:30:58 +0900 (JST)

I try to send this again...

Subject: Re: PMIPv6 Requirements Draft
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Date: Thu, 28 Aug 2008 02:13:13 +0900 (JST)

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

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

> > > 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.
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
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 28 Aug 2008 22:35:24 +0800

> Folks, what do you think?
Service model should be out of the scope of this document,
but it may give some influence to current doc which we couldn't ignore,

thanks

-Hui