Subject: [ANCP] Comments on draft-maglione

From: "Curtis Sherbo" <[email-masked]>
Date: Mon, 16 Jul 2007 15:07:41 -0700

Greetings,

I think the flexibility of the solution proposed in
draft-maglione-ancp-mcast-00.txt is necessary when you consider applications
beyond simple broadcast IPTV.

I think it is useful in certain scenarios in IPTV, but I also think it is
useful in a few other applications as listed below:

1) Nomadicity/Roaming - whether wired or wireless it would be more effective
to have a centralized policy decision as opposed to a distributed one.  This
is especially true in a wireless instance where a client may be moving from
one access point to another, the session would need to be handed off, would
you want to see a full authentication step each hop so that you can refresh
policies on the access point?

2) Video Conferencing - As conferences would likely be ad-hoc, where the
multicast groups may not be known in advance, it would likely be more
efficient to update data centrally and query it as a participants join
conferences.

3) Future Over the Top Video Partnerships - Service providers may choose to
partner with internet video providers to provide QoS and multicast
capabilities through a partnership on a per event basis.  Like the video
conferencing scenario, this would be somewhat ad-hoc where the multicast
group mappings may not be known in advance, or may be reused for different
content in succession, requiring repeated policy refresh.  Again, a
centralized approach would appear to be more scalable for this model.

To be noted, zap time is less of an issue with these three applications, as
there is typically an accepted processing time.

Obviously it is not the job of the IETF to define these services or business
models, but I thought it might be helpful for us to consider services beyond
the starting point of IPTV.  

As suggested by others on this list, the existing framework may be able to
fulfill some of the requirements put forward by this draft, but I argue that
there is validity in the flexibility that the draft brings for IPTV as well
as support for the applications I have discussed here.

I welcome your comments.

Cheers,
Curtis

Curtis Sherbo, P.Eng
Product Line Manager
Redback Networks Canada Inc.
Phone: (604)629-7357
Mobile: (604)250-0672

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 17 Jul 2007 16:12:08 +0200

Hi,
 
Please find my comments inline.
 
Regards,
Sven

________________________________

From: Curtis Sherbo [mailto:[email-masked]] 
Sent: dinsdag 17 juli 2007 0:08
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [ANCP] Comments on draft-maglione

Greetings, 

I think the flexibility of the solution proposed in
draft-maglione-ancp-mcast-00.txt is necessary when you consider
applications beyond simple broadcast IPTV.

I think it is useful in certain scenarios in IPTV, but I also think it
is useful in a few other applications as listed below:

1) Nomadicity/Roaming - whether wired or wireless it would be more
effective to have a centralized policy decision as opposed to a
distributed one.  This is especially true in a wireless instance where a
client may be moving from one access point to another, the session would
need to be handed off, would you want to see a full authentication step
each hop so that you can refresh policies on the access point? 

I agree that there will be some central system that holds the subscriber
policy information. In the case of nomadicity, this system will be in
the "home network" (I don't mean customer premises network) and will
need to be contacted by the "visiting network". This could be done in a
push mode - bringing the relevant policy information to the network
elements in the visiting network - or in a pull mode - outsourcing the
decision to the home network. In my view, in the case of multicast, the
push model leads to less signaling than the pull model (unless some
special tricks based on session grouping with timeouts are introduced in
access platforms - but these have their own issues as I highlighted in
my previous email). Hence I'm more in favor of using the push model even
in nomadic/roaming cases.

See next point.

3) Future Over the Top Video Partnerships - Service providers may choose
to partner with internet video providers to provide QoS and multicast
capabilities through a partnership on a per event basis.  Like the video
conferencing scenario, this would be somewhat ad-hoc where the multicast
group mappings may not be known in advance, or may be reused for
different content in succession, requiring repeated policy refresh.
Again, a centralized approach would appear to be more scalable for this
model.

I agree that these are channels which may not be known to the access
provider in advance. There's however an easy way to solve this case:
thanks to IGMPv3 SSM, it is possible to create two categories of
channels:

- those with a known IP source address: these would include e.g. the
access/service provider's own IPTV offering

- those with an unknown IP source address: these would include over the
top video, or video conferencing

The Access Node can use the IP source address to filter IGMPv3's in
different replication contexts (e.g. IPTV, Internet TV). Within this
context, it could then decide to offer the content with the required
QoS, and decide whether or not to accept or reject the channel.

To be noted, zap time is less of an issue with these three applications,
as there is typically an accepted processing time. 

Can you clarify what you mean with this? 

Obviously it is not the job of the IETF to define these services or
business models, but I thought it might be helpful for us to consider
services beyond the starting point of IPTV.  

As suggested by others on this list, the existing framework may be able
to fulfill some of the requirements put forward by this draft, but I
argue that there is validity in the flexibility that the draft brings
for IPTV as well as support for the applications I have discussed here.

I welcome your comments. 

Cheers, 
Curtis 

Curtis Sherbo, P.Eng 
Product Line Manager

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 17 Jul 2007 18:05:51 +0200

Hi Sven,

On 17 Jul 2007, at 16:12, OOGHE Sven wrote:

> 3) Future Over the Top Video Partnerships - Service providers may  
> choose to partner with internet video providers to provide QoS and  
> multicast capabilities through a partnership on a per event basis.   
> Like the video conferencing scenario, this would be somewhat ad-hoc  
> where the multicast group mappings may not be known in advance, or  
> may be reused for different content in succession, requiring  
> repeated policy refresh.  Again, a centralized approach would  
> appear to be more scalable for this model.
>
> I agree that these are channels which may not be known to the  
> access provider in advance. There's however an easy way to solve  
> this case: thanks to IGMPv3 SSM, it is possible to create two  
> categories of channels:
>
> - those with a known IP source address: these would include e.g.  
> the access/service provider's own IPTV offering
>
> - those with an unknown IP source address: these would include over  
> the top video, or video conferencing
>
> different replication contexts (e.g. IPTV, Internet TV). Within  
> this context, it could then decide to offer the content with the  
> required QoS, and decide whether or not to accept or reject the  
> channel.
I don't quite see how that solves the core issues mentioned by Curtis:
What you describes allow to separate out the provider's channels from  
everything else (the Internet OTT services, Video Conference). But we  
still have to deal with the dynamic allocation/reallocation of  
channels to the "Everything else" applications with possibly large  
and fast changing membership. For those, it seems more efficient to  
use a "more centralized" repository than attempting to permanently  
update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all  
affected ANs/AN-ports.
Am I missing something?

Thanks

Francois

---

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 18 Jul 2007 11:22:21 +0200

Hi Francois,

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: dinsdag 17 juli 2007 18:06
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; Curtis Sherbo; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [ANCP] Comments on draft-maglione

Hi Sven, 

	3) Future Over the Top Video Partnerships - Service providers
may choose to partner with internet video providers to provide QoS and
multicast capabilities through a partnership on a per event basis.  Like
the video conferencing scenario, this would be somewhat ad-hoc where the
multicast group mappings may not be known in advance, or may be reused
for different content in succession, requiring repeated policy refresh.
Again, a centralized approach would appear to be more scalable for this
model.

	I agree that these are channels which may not be known to the
access provider in advance. There's however an easy way to solve this
case: thanks to IGMPv3 SSM, it is possible to create two categories of
channels:

	- those with an unknown IP source address: these would include
over the top video, or video conferencing

	The Access Node can use the IP source address to filter IGMPv3's
in different replication contexts (e.g. IPTV, Internet TV). Within this
context, it could then decide to offer the content with the required
QoS, and decide whether or not to accept or reject the channel.

I don't quite see how that solves the core issues mentioned by Curtis:
What you describes allow to separate out the provider's channels from
everything else (the Internet OTT services, Video Conference). But we
still have to deal with the dynamic allocation/reallocation of channels
to the "Everything else" applications with possibly large and fast
changing membership. 
 
Correct, I should have made this more explicit in my previous reply.
When using IGMPv3 with SSM, the information to locally decide whether or
not to accept an IGMP report may or may not be present in the
replication context on the Access Node.
 
 For those, it seems more efficient to use a "more centralized"
repository than attempting to permanently
update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all
affected ANs/AN-ports. 
Am I missing something?
 
Well, perhaps we should do the math and count the amount of messages...
 
. In case of configuring the White-List/Black-List info, you'd configure
the info at subscription time or when the IP session starts/ends.
Typical example is the establishment of a PPP connection or DHCP lease.
At this point, the AAA system will be contacted, which would be linked
to the policy system containing the user's multicast viewing rights.
Those would then be sent to the Access Node, and need to be released
when the session ends. There's indeed some updating and re-updating
going on. But typically, a session can last for one or several hours (or
could even be always-on), and the policy information may well be stable
for long periods of time within that session.
 
. In case of contacting the central repository upon receiving an IGMP,
you would have such an exchange at every channel zap. Whithin the
session, it is likely that a subscriber will issue several IGMP messages
to zap through channels. The number of message exchanges with the
central respository will then be higher than in the first case.
To reduce the message load, one could make use of some form of channel
grouping to send a bulk of policy information to the Access Node (cf.
what is mentioned in the draft), but in my view this brings us very
close to the first case again, and makes me wonder if it would not be
simpler to send all required channel information to the Access Node at
the start of the session. There may still be a need to do some
in-session policy configuration changes on the Access Node, but even
with this additional load, the resulting message load will never be
higher than in the case of checking with the central policy server.
 
Regards,
Sven 

Thanks

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 18 Jul 2007 14:13:16 +0200

>> multicast capabilities through a partnership on a per event  
>> basis.  Like the video conferencing scenario, this would be  
>> somewhat ad-hoc where the multicast group mappings may not be  
>> known in advance, or may be reused for different content in  
>> succession, requiring repeated policy refresh.  Again, a  
>> in different replication contexts (e.g. IPTV, Internet TV). Within  
> What you describes allow to separate out the provider's channels  
> from everything else (the Internet OTT services, Video Conference).  
> But we still have to deal with the dynamic allocation/reallocation  
> of channels to the "Everything else" applications with possibly  
> large and fast changing membership.
>
> Correct, I should have made this more explicit in my previous  
> reply. When using IGMPv3 with SSM, the information to locally  
> decide whether or not to accept an IGMP report may or may not be  
> present in the replication context on the Access Node.
>
> repository than attempting to permanently update/re-update/re-re- 
> update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.
> Am I missing something?
>
> . In case of configuring the White-List/Black-List info, you'd  
> configure the info at subscription time or when the IP session  
> starts/ends. Typical example is the establishment of a PPP  
> connection or DHCP lease. At this point, the AAA system will be  
> contacted, which would be linked to the policy system containing  
> the user's multicast viewing rights. Those would then be sent to  
> the Access Node, and need to be released when the session ends.  
> There's indeed some updating and re-updating going on. But  
> typically, a session can last for one or several hours (or could  
> even be always-on), and the policy information may well be stable  
> . In case of contacting the central repository upon receiving an  
> IGMP, you would have such an exchange at every channel zap. Whithin  
> the session, it is likely that a subscriber will issue several IGMP  
> messages to zap through channels. The number of message exchanges  
> with the central respository will then be higher than in the first  
> case.
> To reduce the message load, one could make use of some form of  
> channel grouping to send a bulk of policy information to the Access  
> Node (cf. what is mentioned in the draft), but in my view this  
> brings us very close to the first case again, and makes me wonder  
> if it would not be simpler to send all required channel information  
> to the Access Node at the start of the session. There may still be  
> a need to do some in-session policy configuration changes on the  
> Access Node, but even with this additional load, the resulting  
> message load will never be higher than in the case of checking with  
> the central policy server.

Sven,

Your comparison above assumes a "regular" scenario where the  
conditional access rules are known ahead of time at session setup.
For such regular scenarios, we agree that the Black-List/White-List  
mechanisms works well. That is why those are defined in our proposal,  
and the expectation is that they would be used for the regular  
scenarios.

But again, the interesting question is for other scenarios, for  
example, as mentioned earlier, for those involving large and fast  
changing membership. Just for argument sake, let's imagine that an  
application is offering on-demand multicast-based services (eg video  
conferencing, video-push) and want to rely on multicast to do this  
and want to rely on the network to enforce who is allowed to join  
which video conf. Then, it may be that there are many "channels"  
created/terminated all the time, with new members coming and going  
all the time. Some would allow multicast communications within small  
groups (eg one for me to send my latest video to my parents and  
uncle, one for you to send stuff to your brothers and sisters). Some  
would allow multicast communication within very large groups (eg one  
allowing all shareholders of company X to watch from home the company  
results announcement live video). For _that_ application (and not for  
each and every channel), just for that application, it appears more  
efficient to allow the NAS to query a more central conditional access  
repository than try to try update White-List/Black-List in every AN ,  
and for all affected AN-ports as their membership changes all the  
time. In particular, for the groups authorizing communication within  
a very large community (but perhaps where only a small number will  
actually ever join).

Perhaps, I should restate that the proposal is not about using Black- 
List/White-List for all channels/port OR querying NAS for all  
channels/ports. The proposal is about having the flexibility to use  
the most appropriate mechanism for each channel/port. So, in case of  
the example on-demand application discussed above, one may use Black- 
List/White-List for all channels/port except the channel(s) allocated  
to that particular application.

Cheers

Francois

---

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 18 Jul 2007 16:58:56 +0200

Hi Francois,

		I agree that these are channels which may not be known
to the access provider in advance. There's however an easy way to solve
this case: thanks to IGMPv3 SSM, it is possible to create two categories
of channels:

		- those with a known IP source address: these would
include e.g. the access/service provider's own IPTV offering

		- those with an unknown IP source address: these would
include over the top video, or video conferencing

		The Access Node can use the IP source address to filter
IGMPv3's in different replication contexts (e.g. IPTV, Internet TV).
Within this context, it could then decide to offer the content with the
required QoS, and decide whether or not to accept or reject the channel.

	I don't quite see how that solves the core issues mentioned by
Curtis:
	What you describes allow to separate out the provider's channels
from everything else (the Internet OTT services, Video Conference). But
we still have to deal with the dynamic allocation/reallocation of
channels to the "Everything else" applications with possibly large and
fast changing membership. 
	 
	Correct, I should have made this more explicit in my previous
reply. When using IGMPv3 with SSM, the information to locally decide
whether or not to accept an IGMP report may or may not be present in the
replication context on the Access Node.

	Well, perhaps we should do the math and count the amount of
messages...
	 
	. In case of configuring the White-List/Black-List info, you'd
configure the info at subscription time or when the IP session
starts/ends. Typical example is the establishment of a PPP connection or
DHCP lease. At this point, the AAA system will be contacted, which would
be linked to the policy system containing the user's multicast viewing
rights. Those would then be sent to the Access Node, and need to be
released when the session ends. There's indeed some updating and
re-updating going on. But typically, a session can last for one or
several hours (or could even be always-on), and the policy information
may well be stable for long periods of time within that session.
	 
	. In case of contacting the central repository upon receiving an
IGMP, you would have such an exchange at every channel zap. Whithin the
session, it is likely that a subscriber will issue several IGMP messages
to zap through channels. The number of message exchanges with the
central respository will then be higher than in the first case.
	To reduce the message load, one could make use of some form of
channel grouping to send a bulk of policy information to the Access Node
(cf. what is mentioned in the draft), but in my view this brings us very
close to the first case again, and makes me wonder if it would not be
simpler to send all required channel information to the Access Node at
the start of the session. There may still be a need to do some
in-session policy configuration changes on the Access Node, but even
with this additional load, the resulting message load will never be
higher than in the case of checking with the central policy server.

Sven,

Your comparison above assumes a "regular" scenario where the conditional
access rules are known ahead of time at session setup.
For such regular scenarios, we agree that the Black-List/White-List
mechanisms works well. That is why those are defined in our proposal,
and the expectation is that they would be used for the regular
scenarios.

But again, the interesting question is for other scenarios, for example,
as mentioned earlier, for those involving large and fast changing
membership. Just for argument sake, let's imagine that an application is
offering on-demand multicast-based services (eg video conferencing,
video-push) and want to rely on multicast to do this and want to rely on
the network to enforce who is allowed to join which video conf. Then, it
may be that there are many "channels" created/terminated all the time,
with new members coming and going all the time. Some would allow
multicast communications within small groups (eg one for me to send my
latest video to my parents and uncle, one for you to send stuff to your
brothers and sisters). Some would allow multicast communication within
very large groups (eg one allowing all shareholders of company X to
watch from home the company results announcement live video). For _that_
application (and not for each and every channel), just for that
application, it appears more efficient to allow the NAS to query a more
central conditional access repository than try to try update
White-List/Black-List in every AN , and for all affected AN-ports as
their membership changes all the time. In particular, for the groups
authorizing communication within a very large community (but perhaps
where only a small number will actually ever join).
 
I think I understand your reasoning.You're saying that for things like
video conferencing, over the top video or video push features you would
contact the central policy system because the access node doesn't have
the information to decide locally. For IPTV services offered by the
access/service provider, some Black-List/White-List info is pushed to
the Access Node.
 
In this case, I would think that the Access Node could e.g. use IGMPv3
SSM to distinguish between these two categories of services, based on a
(or a few) known IP source address (for IPTV) or unknown IP source
address (the "Everything else" mentioned by Curtis). That would imply to
me that for everything which is IPTV, you could handle things locally,
and for "Everything else", you would have to query the central policy
server. This is because the Access Node doesn't know whether this user
is allowed to watch e.g. the company's results broadcast vs any other
Internet TV stream. So each time I would try to join a non-IPTV stream,
the central policy server needs to check if the stream is a known one
which is authorized, or some other Internet stream. Wouldn't this lead
to scaling issues?

Perhaps, I should restate that the proposal is not about using
Black-List/White-List for all channels/port OR querying NAS for all
channels/ports. The proposal is about having the flexibility to use the
most appropriate mechanism for each channel/port. So, in case of the
example on-demand application discussed above, one may use
Black-List/White-List for all channels/port except the channel(s)
allocated to that particular application.

Cheers

Francois 
   
Regards,
Sven

---

From: "Curtis Sherbo" <[email-masked]>
Date: Thu, 19 Jul 2007 11:11:41 -0700

Hi Sven, comments inline.
 
Cheers,
Curtis

  _____  

From: OOGHE Sven [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 7:12 AM
To: Curtis Sherbo; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [ANCP] Comments on draft-maglione

Hi,

Regards,
Sven

  _____  

Greetings, 

I agree that there will be some central system that holds the subscriber
policy information. In the case of nomadicity, this system will be in the
"home network" (I don't mean customer premises network) and will need to be
contacted by the "visiting network". This could be done in a push mode -
bringing the relevant policy information to the network elements in the
visiting network - or in a pull mode - outsourcing the decision to the home
network. In my view, in the case of multicast, the push model leads to less
signaling than the pull model (unless some special tricks based on session
grouping with timeouts are introduced in access platforms - but these have
their own issues as I highlighted in my previous email). Hence I'm more in
favor of using the push model even in nomadic/roaming cases. 

<CS> I think I can agree somewhat on the nomadic case.  But I still think in
the roaming case, where you have an active session that is handed off from
one Access Point to another, that it isn't scalable or seamless to push a
full policy down to the Access Point.

See next point.

I agree that these are channels which may not be known to the access
provider in advance. There's however an easy way to solve this case: thanks
to IGMPv3 SSM, it is possible to create two categories of channels:

- those with an unknown IP source address: these would include over the top
video, or video conferencing

The Access Node can use the IP source address to filter IGMPv3's in
different replication contexts (e.g. IPTV, Internet TV). Within this
context, it could then decide to offer the content with the required QoS,
and decide whether or not to accept or reject the channel. 

<CS> I don't know if I follow you here.  I think you are saying for the OTT
Video, the receiver would send a Join for a group with an empty source list.
I fail to see how the AN can make an appropriate policy decision with only
this information.  My train of thought on this was that the application
would know the MC Group for the event and send the join with the Group and
the Source, or even the just the group, and the AN via ANCP via the NAS
would query a AAA database to see that the customer either just purchased
the event or if there is open access to the group.  I'm thinking a service
provider may reuse a MC Group with differing sources as you mention above,
and the QoS aspect could hold true as you say, but the event based
authorization I believe is best handled with the centralized approach. I
also believe this application requires the Termination function proposed in
the draft.

<CS>In one of the earlier arguments, I believe put forward by Thomas, he
mentioned that Zap time would be lengthened with this extra authorization
step.  I agree that this is the case, but my point is that these
applications don't have a expected rapid response time such is the case with
IPTV channel change.  I believe these applications will have a different
application interface with an experience similar to clicking on a web link,
where a user is accustomed to waiting for a page to load, they will not be
surprised by the extra processing time of the authorization check.

I welcome your comments. 

Cheers, 
Curtis 

Curtis Sherbo, P.Eng 
Product Line Manager

---

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 20 Jul 2007 13:49:20 +0200

Hi Curtis,
 
feedback inline.
 
Regards,
Sven

From: Curtis Sherbo [mailto:[email-masked]] 
Sent: donderdag 19 juli 2007 20:12
To: OOGHE Sven; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [ANCP] Comments on draft-maglione

Cheers,
Curtis

Hi,

Regards,
Sven

Greetings, 

<CS> I think I can agree somewhat on the nomadic case.  But I still
think in the roaming case, where you have an active session that is
handed off from one Access Point to another, that it isn't scalable or
seamless to push a full policy down to the Access Point. 

<Sven> The mobility/roaming case is one I handnt't thought of before.
The amount of signaling for push mode are greater than in the nomadic
case, that's clear. I think that the use of multicast applications in a
wireless network (e.g. 802.11 or 802.16) is something where the folks
from Mobile IP as well as from CAPWAP need to be involved. For L3
mobility (i.e. moving from one subnet to another), Mobile IP defines a
number of techniques to tunnel traffic from the Foreign Agent to the
Home Agent; perhaps extensions are needed for allowing pull and/or push
models. Similarly, I've seen that CAPWAP defines techniques to configure
MAC ACLs on wireless access points. Maybe CAPWAP would need to be
extended to include pull and/or push models for mobility of multicast
applications.

See next point.

<CS> I don't know if I follow you here.  I think you are saying for the
OTT Video, the receiver would send a Join for a group with an empty
source list.  I fail to see how the AN can make an appropriate policy
decision with only this information.  My train of thought on this was
that the application would know the MC Group for the event and send the
join with the Group and the Source, or even the just the group, and the
AN via ANCP via the NAS would query a AAA database to see that the
customer either just purchased the event or if there is open access to
the group.  I'm thinking a service provider may reuse a MC Group with
differing sources as you mention above, and the QoS aspect could hold
true as you say, but the event based authorization I believe is best
handled with the centralized approach. I also believe this application
requires the Termination function proposed in the draft.  

<Sven> The idea I had in mind was that the access node could hold
White-List/Black-List policies for the well-known senders (e.g. the IPTV
content servers, or some server in the Internet for which the service
provider has some contract with the access provider). Upon receiving an
IGMP join, the Access Node could first check if the source IP address
was a known one (using IGMPv3 SSM). If so, then it would look at the
White-List/Black-List information and decide locally. If on the other
hand the source IP address would not be not known, it could be basically
anything (over the top video, video conferencing, some Internet TV
channel in Japan,...). In this case the Access Node could do two things

- simply accept, and handle access control at some other layer (e.g.
using encryption)

- outsource to let a central system decide

I think that there may be scaling issues with outsourcing everyting
else. Instead, I think it's better to rely on SSM as a first filtering
technique. Black/White lists could be used for further filtering of the
known sources.

<CS>In one of the earlier arguments, I believe put forward by Thomas, he
mentioned that Zap time would be lengthened with this extra
authorization step.  I agree that this is the case, but my point is that
these applications don't have a expected rapid response time such is the
case with IPTV channel change.  I believe these applications will have a
different application interface with an experience similar to clicking
on a web link, where a user is accustomed to waiting for a page to load,
they will not be surprised by the extra processing time of the
authorization check.

<Sven> ok, got it, thanks.

I welcome your comments. 

Cheers, 
Curtis 

Curtis Sherbo, P.Eng 
Product Line Manager

---

From: "Michel Platnic" <[email-masked]>
Date: Mon, 23 Jul 2007 16:22:47 +0300

Hi Francois, Sven and All,
 
Please find my comments inline in green.

From: OOGHE Sven [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 5:59 PM
To: Francois Le Faucheur IMAP
Cc: [email-masked]; [email-masked]
Subject: RE: [ANCP] Comments on draft-maglione

Hi Francois,

	 

	 

Sven,

 

<Michel> Using access control capabilities within the access network
provides the two main following benefits:
- refrain from sending any content to a customer that was not paid for
(mostly relevant when Encryption is not used)
- provides a filter against end-user applications/hackers that may send
IGMP requests with invalid IP address
 
A solution where all the IP addresses that are not part of either the
Black-list or the White-List are sent to a central policy server for
authorization gives me some concerns regarding the robustness of the
whole system. Same concern regarding the treatment of unknown IP source
addresses ('Everything else').
 
I understand that some applications may require sophisticated policy
decision making and that, as a matter of fact, some AN/central policy
server synchronization mechanism should to be proposed, but the solution
must be Robust and Scalable.
For now I am not convinced that solution proposed is either Robust or
Scalable.
 
Regards,
Michel.

Cheers

Francois 
   
Regards,
Sven

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 23 Jul 2007 10:23:52 -0500

Hi Michel,

>
> <Michel> Using access control capabilities within the access  
> network provides the two main following benefits:
> - refrain from sending any content to a customer that was not paid  
> for (mostly relevant when Encryption is not used)
> - provides a filter against end-user applications/hackers that may  
> send IGMP requests with invalid IP address
>
> A solution where all the IP addresses that are not part of either  
> the Black-list or the White-List are sent to a central policy  
> server for authorization gives me some concerns regarding the  
> robustness of the whole system. Same concern regarding the  
> treatment of unknown IP source addresses ('Everything else').

Agreed. We had these concerns in mind also. This is why the Black- 
Lists and White-Lists include the ability to define arbitrarily large  
ranges/masks. In particular, as an example, one can easily define a  
Black-List which contains a single "catch-all" entry that matches any  
Multicast address & Source. Then you can define a White-List with the  
explicit channels you want to allow. This effectively implements a  
policy whereby everything is blocked by AN, except the channels that  
have been explicitly allowed in the White-List.
In other words, the Black-List can be used for explicit listing of  
channels, or it can easily be used as a "catch-all" (for all, or for  
arbitrarily large ranges of channels).

This should address your concern of making sure that the "default"  
behavior for any non-explicitly defined channel is not to query NAS/ 
Central_server.

See in draft-maglione:
"
The White List and Black List can contain entries allowing:
    o  an exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>)
    o  an exact match for a (S,G) SSM channel (e.g.  
<S=s.t.u.v,G=g.h.i.l>
    o  a mask-based range match for a (*,G) ASM group (e.g.
       <G=g.h.i.l/Mask>)
    o  a mask-based range match for a (S,G) SSM channel (e.g.
       <S=s.t.u.v/Mask,G=g.h.i.l/Mask>
"

>
> I understand that some applications may require sophisticated  
> policy decision making and that, as a matter of fact, some AN/ 
> central policy server synchronization mechanism should to be proposed,
> but the solution must be Robust and Scalable.
> For now I am not convinced that solution proposed is either Robust  
> or Scalable.

Let us know if you have specific robustness/scalability concerns  
(beyond the one discussed above)?
Then we could work together on addressing those.

Thanks

Francois

---

From: "Maglione Roberta" <[email-masked]>
Date: Mon, 23 Jul 2007 17:51:49 +0200

Hi Sven, Michel and All,

   Thanks for your comments on the draft. I agree with you that there
are scenarios where a "push model" could be used (this is the reason why
we introduced white and black lists concept), while there are cases
where a "pull model" better fits the needs. In my opinion ANCP should be
flexible enough to cover both models. 

As  far as conditional access in my opinion scenarios that could be
better developed using pull model are cases where Network Service
Provider and Content Service Provider are two different entities and the
AN is part of NSP while authorization function needs to be performed by
CP. In these scenarios AN needs to be able to query AAA Server in CP
network in order to get authorization to receive the multicast flow.
Prepaid Service can be one example: in particular I think it would be
more efficient having the information related to the remaining credit
centralized on AAA Server and leaving the authorization function
centralized instead of spread it around and overloading the AN with  all
different policies. 

As far as admission control thinking about triple play services where
synchronization between unicast and multicast admission control is
required in order to be able to efficiently share the available
bandwidth on the access line in my opinion a pull approach would be more
flexible than a push model, because it would allow to perform
synchronized admission control on the fly having a NAS, as centralized
control point, talking with a Policy Server in order to take decision
about the new flow. 

Regards,

Roberta

-------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia
------------------------------------------------- 

From: OOGHE Sven [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 4:59 PM
To: Francois Le Faucheur IMAP
Cc: Curtis Sherbo; [email-masked]; Maglione Roberta; Garofalo Angelo
Subject: RE: [ANCP] Comments on draft-maglione

Hi Francois,

	Am I missing something?

Sven,

Cheers

Francois 

Regards,

Sven

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

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 24 Jul 2007 08:52:46 -0400

Maglione et al..
  At a high level the proposals in the draft are reasonable and in line
with the framework and discussions in the DSLF. More specific comments
from myself and Derek on the draft and responses to some of the issues
raised on the mailing list included below:
 
4.2 Conditional access and admission control with NAS decision
It is not clear what information is required / envisaged for the
Admission Request / Response messages - 
Multicast Flow and ACI at a minimum seems to be needed. It will be
useful to clarify that the NAS is expected to know the BW information
for the multicast flow (flow-group) for which admission control is being
requested. This could be locally configured on the NAS, could be
provided at auth time from radius/policy server, or could be dynamically
auto-sensed (measured) on the NAS.
 
4.3 Multicast Accounting. 
This section implies that accounting is triggered by Admission Response,
which implies that CAC to the NAS must have been performed to trigger
accounting. One would think accounting could be required also for other
flows in the flow-group than the one which triggered admission
request/response. There probably needs to be a separate mechanism.
Or are we stipulating that another criterion (beyond bandwidth) to group
flows in the flow-group is also based on the need (or lack of) for
accounting.  It is probably worth-while to state that grouping of flows
into flow-groups is the function of the NAS and how the grouping is done
is transparent to AN.
 
Also, should consider some form of mechanism for bulk accounting such
that multiple accounting events can be reported in one message.
 
4.4 Conditional access and admission control...
Item 12 should have an explicit reference to the ANCP capabilities
negotiation, as one assumes there will be an impact there.
 
5.1.1 Provisioning AN with White/Black lists...
Whether here or elsewhere, there needs to be some clarification on how
are multiple users / sessions per port handled
This may be:
(a) Multiple subscribers - i.e. real users - e.g. multiple sessions from
PCs ( PPPoE or DHCP ) and bridged DSL CPE
(b) One subscriber but multiple devices - e.g. separate sessions for PC,
VoIP/Voice, STB.
(c) Combination of (a) and (b)
 
There seems to be an assumption of a DSL line / AN port and a subscriber
as having a 1:1 mapping which is not always the case.
 
5.1.2 Provisioning AN..
How does the NAS know which ports are active on an AN and therefore
require data - the push mechanism implies that the NAS would
pre-provision, but consider: 
(i) the AN has say 100 ports 
(ii) only 17 of these have been "turned up" - i.e. activated yet
=> Does the NAS send data for all 100 ports?
=> If the NAS only sends for the active ports, how does it know which
ones these are?
 
5.2.2 Multicast Flow with NAS decision....
The message flows indicate that the replication always starts for a
given flow on reception of an "Admission Response" for that flow. This
might not always be true. There are atleast two conditions here:
(a) A Join for a different flow in the same flow-group is received by
the AN due to a channel change, before the admission response is
received for the pending request. In this case one would assume the
admission response is still applicable (since it is for the flow-group)
and the replication for the new flow can commence.
(b) A new Join for a different flow in a different flow-group (e.g.
going from an SD to a HD flow) might be received while admission
response for the old join is still pending. In this case another
admission request is generated and no replication happens.
Message flows or text is needed to indicate these scenarios.
 
Comments on discussion points raised on the list:
 
1. Multicast Conditional Access
We see the benefit in having a mechanism whereby AN can be selectively
forced to query a NAS for permission, rather than a PUSH model. Based on
some of the responses, it might be useful to explicitly indicate that
the white and black lists also provide a mechanism to distinguish
between flows that can arise and flows that are never expected to arise.
 
2. Multicast Admission Control.
 
It has been pointed out:
 
>> CAC discussion goes beyond the ANCP WG. 
 
This might be true. However, there are many models today whereby the NAS
performs admission control for the DSL line for unicast traffic, and
given the ANCP scope which is defined as: "enabling NAS and AN to
functionally behave as one single black box, while replication is
performed on the AN, but without any loss of functionality compared to
if replication was performed on NAS",  then it would seem consistent to
have ANCP allow the admission control to be performed on the NAS but use
replication on the AN, rather than forcing the admission control to be
done on the AN. This is just as a  NAS can today use an IGMP join to
perform BW adjustment for multicast traffic, one should be able to use
information from the AN on multicast status to perform admission control
at the NAS. 
In terms of general models the DSL Forum has always defined a QoS aware
function in the NAS/BNG/ for shaping traffic towards the user so as not
to flood any network between NAS and AN with traffic that is later
discarded. Again, we see it as a valid goal to keep this functionality
(and indeed the current QoS architecture in many providers networks ),
while having the advantages of fully distributed replication.  This
unified admission control can be achieved using mechanisms such as IGMP
forking in the CPE / AN, but this is not always applicable / available. 
 
Other standard bodies are defining reference architectures that call out
functions and interfaces between different entities for CAC and access
control. The functions themselves can be instantiated on different
network elements, and the reference interfaces are between these
different functions (rather than between network elements themselves).
It is easy to imagine ANCP fitting the bill for one or more of these
reference interfaces. If needed, ANCP WG can generate liaison statements
to some of these other standard bodies.
 
Thanks
-Sanjay/Derek

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: Monday, July 23, 2007 11:52 AM
To: OOGHE Sven
Cc: Garofalo Angelo; [email-masked]
Subject: RE: [ANCP] Comments on draft-maglione

Hi Sven, Michel and All,

Regards,

Roberta

  _____  

Hi Francois,

Am I missing something?

Sven,

Cheers

Francois 

Regards,

Sven

--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to  <mailto:[email-masked]>
[email-masked].
        Thank you
                                         <http://www.telecomitalia.it>
www.telecomitalia.it
--------------------------------------------------------------------

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 24 Jul 2007 16:02:33 +0200

Hi Roberta,
 
See feedback inline.
 
Regards,
Sven

From: Maglione Roberta [mailto:[email-masked]] 
Sent: maandag 23 juli 2007 17:52
To: OOGHE Sven
Cc: Curtis Sherbo; [email-masked]; Garofalo Angelo; Francois Le Faucheur
IMAP
Subject: RE: [ANCP] Comments on draft-maglione

Hi Sven, Michel and All,

I think I understand your point of view regarding the desire to keep
some policy information at a central location and refer to it only when
needed. In this thread, people discussed several applications
(nomadicity, mobility, over the top video, video conferencing, pre-paid
services, Internet TV,...). They were categorized in the "Everything
Else" group, which was put next to the Broadcast TV applications, for
which it appears the Black-List/White-List mechanism is adequate. Did I
capture this correctly?

In my view, the Access Node could hold White-List/Black-List policies
for the well-known senders (e.g. the IPTV content servers of the CSP).
Upon receiving an IGMP join, the Access Node could first check if the
source IP address was a known one (using IGMPv3 SSM). If so, then it
would look at the White-List/Black-List information and decide locally.
If the source IP address would not be not known, it could be basically
anything (over the top video, video conferencing, Internet TV,...). In
this case the Access Node could do two things 

I think that there may be scaling issues with outsourcing everything
else. Instead, I think it's better to rely on SSM as a first filtering
technique. Black/White lists could be used for further filtering of the
known sources.

BTW, Pre-paid service can also done in a push model by using a
time-based policy which times out. This can then be done with a single
policy configuration message to the Access Node; when the policy times
out, it is automatically removed on the Access Node without any
signaling.

I have some concerns on the admission control case. On one hand it is
stated by some people that the pull model can be made scalable, since it
only needs to be performed for applications that require it. On the
other hand, it is also stated that it is important to have synchronized
unicast/multicast admission control. But that implies you need to use
the pull model for all applications, especially Broadcast TV (because
this is where unicast and multicast resources are most likely to be
shared on the first mile).

The use of flow groups to reduce signaling isn't really a solution in my
view, because it creates new issues on its own related to lack of
synchronization between the Access Node, NAS and Policy System.

I do agree that the network model must support with RAC in a combined
unicast/multicast model. But I think we should be looking for solutions
that achieve this with minimal signaling, while avoiding any
synchronization issues between the Access Node, NAS and Policy System.

 Regards,

Roberta

Hi Francois,

	Am I missing something?

Sven,

Cheers

Francois 

Regards,

Sven

replying to [email-masked]
<mailto:[email-masked]> .

---

From: "Maglione Roberta" <[email-masked]>
Date: Tue, 24 Jul 2007 18:23:02 +0200

Hi Sven,

   thanks for your comments, please see answers inline.

Regards,

Roberta

From: OOGHE Sven [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 4:03 PM
To: Maglione Roberta
Cc: Curtis Sherbo; [email-masked]; Garofalo Angelo; Francois Le Faucheur
IMAP
Subject: RE: [ANCP] Comments on draft-maglione

Hi Roberta,

See feedback inline.

Regards,

Sven

Hi Sven, Michel and All,

[RM] Yes you did; my point is that ANCP framework should be flexible
enough to be applied to both kind of applications: allowing a pull
approach for what you called "Everything Else" (nomadicity, mobility,
videoconf, etc..)  while keeping a push model for applications like
Broadcast TV.

[RM] It is not very clear to me this type of approach with SSM: I
understand you are proposing to use SSM to differentiate between known
and unknown sources, in order to decide when decision can be taken
locally on AN on when additionally info is needed. But in my opinion
this model does not solve the problem mentioned by other people on list
regarding how to handle dynamic allocation/reallocation of channels for
applications like video conference that are characterized by frequent
fast membership changes and where the multicast group mappings may not
be known in advance.       

[RM] Yes you are right you can do either with pull or push model, but I
still think pull approach would be more efficient for two reasons:

1.	let's consider a case where a user buys 24 hours credit and he
watches a movies that lasts in 2 hours. In this case user has still 22
hours credit, but this doesn't mean he has to watch movies continuously
for other 22 hours. So the AN needs to be able to track when user is
watching the movie and he is using the credit and when he does not watch
it in order to keep the policy updated. It seems to me that keeping
remaining credit info is AAA server job; I would prefer having the AN
just signaling start and stop time and having the AAA updating the
remaining credit info.
2.	if you extend the scenario I described in 1. to a nomadic user:
this case would requires to distribute an keep up to date a distributed
policy... To me a centralized works better.

[RM] I do agree with you that there are some details about Flow Group
concept we still need to work on in order to have a robust solution, but
I think we do need centralized synchronized unicast and muticast CAC on
the access line because, as also Sanjay said, there is no point to
overload to link between NAS and AN with Multicast traffic that
eventually will be dropped by AN as this multicast traffic will only be
stealing bandwidth to other valuable unicast traffic.

I understand there can be other ways to perform CAC but I still think
provided synchronized CAC is part of the ANCP objectives as stated in
ANCP framework draft. 

The purpose of this document is to define a framework for an Access
   Node Control Mechanism between a Network Access Server (NAS) and an
   Access Node (e.g. a Digital Subscriber Line Access Multiplexer
   (DSLAM)) in a multi-service reference architecture in order to
   perform QoS-related, service-related and Subscriber-related
   operations

 

 Regards,

Roberta

Hi Francois,

	Am I missing something?

Sven,

Cheers

Francois 

Regards,

Sven

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Michel Platnic" <[email-masked]>
Date: Tue, 24 Jul 2007 21:22:18 +0300

Hi Francois,
Please see my comments inline,
Regards,
Michel.

From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: Mon 7/23/2007 6:23 PM
To: Michel Platnic
Cc: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked]; [email-masked]
Subject: Re: [ANCP] Comments on draft-maglione

Hi Michel, 

	<Michel> Using access control capabilities within the access network provides the two main following benefits:
	- refrain from sending any content to a customer that was not paid for (mostly relevant when Encryption is not used)
	- provides a filter against end-user applications/hackers that may send IGMP requests with invalid IP address
	 
	A solution where all the IP addresses that are not part of either the Black-list or the White-List are sent to a central policy server for authorization gives me some concerns regarding the robustness of the whole system. Same concern regarding the treatment of unknown IP source addresses ('Everything else').

Agreed. We had these concerns in mind also. This is why the Black-Lists and White-Lists include the ability to define arbitrarily large ranges/masks. In particular, as an example, one can easily define a Black-List which contains a single "catch-all" entry that matches any Multicast address & Source. Then you can define a White-List with the explicit channels you want to allow. This effectively implements a policy whereby everything is blocked by AN, except the channels that have been explicitly allowed in the White-List.
In other words, the Black-List can be used for explicit listing of channels, or it can easily be used as a "catch-all" (for all, or for arbitrarily large ranges of channels).

This should address your concern of making sure that the "default" behavior for any non-explicitly defined channel is not to query NAS/Central_server.

See in draft-maglione:
"
The White List and Black List can contain entries allowing:
   o  an exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>) 
   o  an exact match for a (S,G) SSM channel (e.g. <S=s.t.u.v,G=g.h.i.l> 
   o  a mask-based range match for a (*,G) ASM group (e.g. 
      <G=g.h.i.l/Mask>) 
   o  a mask-based range match for a (S,G) SSM channel (e.g. 
      <S=s.t.u.v/Mask,G=g.h.i.l/Mask> 
"
 <Michel> Let me try to rephrase your proposal; there would be a default state wherein any channel being neither part of White-list nor Black-list would be discarded. 
If its the case I agree with you that this solution solves the security issue.
 
But what about when AN is not in this default state?
If "Accept everything else" is used then again same problem of security is encountered, and any hacker or application can overload the policy server with requests. 
To my understanding, the model proposed, where the NAS is getting the customer request for authorization, requires this mode of operation.
So we still have the same problem.
Did I miss anything?

______________________________________________________________________________

	I understand that some applications may require sophisticated policy decision making and that, as a matter of fact, some AN/central policy server synchronization mechanism should to be proposed,

	but the solution must be Robust and Scalable.
	For now I am not convinced that solution proposed is either Robust or Scalable.

Let us know if you have specific robustness/scalability concerns (beyond the one discussed above)?
Then we could work together on addressing those. 
 
 <Michel> Well, there is still this scalable issue when duplicating the messages that need to be treated in real-time by the NAS. Sven already made some counting regarding this topic. I believe this point could lead to scalability issues. If we had the above described potential disaster, then we end-up getting serious Robustness issues.

Thanks

Francois

	Regards,
	Michel.