Subject: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 16 Jul 2007 12:18:07 +0200

Hi,

I would like to initiate a thread related to
draft-maglione-ancp-mcast-00.txt describing how to use ANCP for
multicasting. Here are my thoughts on the described use cases.

Multicast Conditional Access

I agree on using ANCP for the sake of provisioning conditional access
information on an Access Node (AN), so that it can take autonomous
decisions lateron.

It seems to me that even the most complex conditional access control
scenarios can be handled using relatively simple policies in the ANs,
with these policies dynamically altered as needed to address the
conditional aspect. For example, if a subscriber is authorized to view a
particular channel only after 11PM, it seems simpler to me to push a new
policy to the AN at 11PM than to force the AN to query the NAS for every
attempt to join that channel.

I'm therefore not convinced about using ANCP for the AN to query the
NAS, that in turn will respond to the AN indicating whether the join is
to be honored or denied.

Multicast Admission Control

The general notion of resource admission control is an important one.
The draft mentions a number of aspects which are indeed of a concern
when deploying a triple play network architecture with both Video on
Demand and Broadcast TV flows.

The draft proposes that the AN outsources a recource decision for a
multicast stream to the NAS. In my view this is not the best approach.
Normally, it would require signaling from the AN to the NAS at each
channel zap. The draft proposes the introduction of a "Multicast
Flow-Group" to reduce the signaling load; this creates a new problem:
how to signal the termination of the reservation for a flow-group to the
NAS? This requires some time-out mechanism on the AN that releases
resources only after a flow-group has no active flows for some period of
time. However, such a timer would block the startup of unicast flows for
a short window following a leave of the last flow in a group. This
appears a highly undesirable effect.

In my view, the resource admission control aspects for the access line
are instead best handled by the AN. This also calls for some
synchronization mechanism between AN, NAS and policy servers, but
different from what is described in this draft. These CAC concepts must
be addressed in a scope that is much broader than the ANCP WG.

Replication Termination

Similar to the basic notion of Multicast Conditional Access, it should
be possible to revoke authorization to join a channel at any time by
pushing a new policy to the AN that indicates that the subscriber is no
longer allowed to join the channel. Again, this is simpler than
performing an ANCP admission request for each join.

Based on the above, I believe that most of the flows in the draft can be
simplified considerably, while still meeting the objectives set forward
in the ANCP framework.

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 17 Jul 2007 14:59:58 +0200

Hello Sven,

Thanks for kicking off the discussion and sharing your views. Some  
thoughts below:

On 16 Jul 2007, at 12:18, OOGHE Sven wrote:
> Hi,
>
> I would like to initiate a thread related to draft-maglione-ancp- 
> mcast-00.txt describing how to use ANCP for multicasting. Here are  
> my thoughts on the described use cases.
>
> I agree on using ANCP for the sake of provisioning conditional  
> access information on an Access Node (AN), so that it can take  
> autonomous decisions lateron.
>
> It seems to me that even the most complex conditional access  
> control scenarios can be handled using relatively simple policies  
> in the ANs, with these policies dynamically altered as needed to  
> address the conditional aspect. For example, if a subscriber is  
> authorized to view a particular channel only after 11PM, it seems  
> simpler to me to push a new policy to the AN at 11PM than to force  
> the AN to query the NAS for every attempt to join that channel.
>
> I'm therefore not convinced about using ANCP for the AN to query  
> the NAS, that in turn will respond to the AN indicating whether the  
> join is to be honored or denied.
Just to be very clear, the idea is not to force that NAS be  
systematically queried of course. In many cases, a simple Conditional  
policy can be provisioned (or-reprovisioned) via ANCP into the Access  
Node. The proposal includes the White-List/Black-Lists for these  
cases. In fact, one may only use these mechanisms in a given  
environment.
However, some applications call for more flexibility. For example  
some applications appear better served by querying a remote  
authorization server (via NAS). This may be for example because the  
authorized membership is not known ahead of time and changes  
dynamically. We feel ANCP should allow such scenarios.

> The general notion of resource admission control is an important  
> one. The draft mentions a number of aspects which are indeed of a  
> concern when deploying a triple play network architecture with both  
> Video on Demand and Broadcast TV flows.
>
> multicast stream to the NAS. In my view this is not the best  
> approach. Normally, it would require signaling from the AN to the  
> NAS at each channel zap. The draft proposes the introduction of a  
> "Multicast Flow-Group" to reduce the signaling load; this creates a  
> new problem: how to signal the termination of the reservation for a  
> flow-group to the NAS? This requires some time-out mechanism on the  
> AN that releases resources only after a flow-group has no active  
> flows for some period of time. However, such a timer would block  
> the startup of unicast flows for a short window following a leave  
> of the last flow in a group. This appears a highly undesirable effect.
>
> In my view, the resource admission control aspects for the access  
> line are instead best handled by the AN. This also calls for some  
> different from what is described in this draft. These CAC concepts  
> must be addressed in a scope that is much broader than the ANCP WG.
While I agree that defining the overall CAC solution is broader than  
the ANCP WG, the "black-box principle" agreed in Prague suggests that  
ANCP needs to provide the necessary flow of information across the  
boxes (where some functions are done by one box but affect the other  
one). For Video CAC to work across the two boxes with full  
functionality, this includes allowing sharing of bandwidth between  
unicast CAC and multicast CAC.

The ANCP Requirements & Framework I-D seems to be assuming this too :
"
    Specifically, when performing multicast replication in the access/ 
aggregation network, the following features must remain supported by
    the logical NAS:
...
    o  Connection admission control (CAC) for multicast and/or  
unicast services
"

With respect to resource admission control for the access line, I  
suspect that different deployment approaches will be selected for  
different networks. Some of these deployment approaches involve  
handling bandwidth allocation for unicast CAC on the NAS, some  
involve synchronizing to a remote server doing unicast CAC via NAS.  
We feel that ANCP should not preclude these important deployment  
models. Again, the corresponding mechanisms do not have to be used in  
all deployments.

> Replication Termination
>
> Similar to the basic notion of Multicast Conditional Access, it  
> should be possible to revoke authorization to join a channel at any  
> time by pushing a new policy to the AN that indicates that the  
> subscriber is no longer allowed to join the channel. Again, this is  
> simpler than performing an ANCP admission request for each join.
As you said: this is tied to the discussion on Conditional Access  
above. If we accept that, _for some applications_, it is more  
efficient to query a more centralised authorization repository than  
try dynamically permanently change/rechange the corresponding policy  
rules on every AN, then I think it is useful to have the  
corresponding ability to selectively revoke an earlier authorization.  
If we don't accept it, then the revoke mechanism is not needed.

> Based on the above, I believe that most of the flows in the draft  
> can be simplified considerably, while still meeting the objectives  
> set forward in the ANCP framework.
Well, I think there is agreement that the current Framework &  
Requirements I-D does yet not fully cover the Multicast use cases.  
Right?
This is why the proposal suggests Multicast specific extensions for  
the ANCP Framework & Requirement document.

Cheers

Francois

---

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

Hi Francois,
 
Thanks for the feedback. See my comments inline.
 
________________________________

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: dinsdag 17 juli 2007 15:00
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Comments on draft-maglione-ancp-mcast-00.txt

Hello Sven, 

	Hi, 

	It seems to me that even the most complex conditional access
control scenarios can be handled using relatively simple policies in the
ANs, with these policies dynamically altered as needed to address the
conditional aspect. For example, if a subscriber is authorized to view a
particular channel only after 11PM, it seems simpler to me to push a new
policy to the AN at 11PM than to force the AN to query the NAS for every
attempt to join that channel.

	I'm therefore not convinced about using ANCP for the AN to query
the NAS, that in turn will respond to the AN indicating whether the join
is to be honored or denied.

Just to be very clear, the idea is not to force that NAS be
systematically queried of course. In many cases, a simple Conditional
policy can be provisioned (or-reprovisioned) via ANCP into the Access
Node. The proposal includes the White-List/Black-Lists for these cases.
In fact, one may only use these mechanisms in a given environment. 
 
Agreed. All I'm saying above is that in my view, this approach is
sufficient to cover all cases mentioned in the bullet points in the ANCP
Framework & Requirements draft.
 
However, some applications call for more flexibility. For example some
applications appear better served by querying a remote authorization
server (via NAS). This may be for example because the authorized
membership is not known ahead of time and changes dynamically. We feel
ANCP should allow such scenarios. 
 
In my view, whenever an IGMP message needs to be processed by an Access
Node, aggregation switch or NAS, the policy/resource information should
be readily available. That's why I am advocating the
White-List/Black-List model for multicast applications. Perhaps for
other applications the flexibility could be useful, but at least in the
case of multicast, I remain to be convinced of what those applications
are.

	The draft proposes that the AN outsources a recource decision
for a multicast stream to the NAS. In my view this is not the best
approach. Normally, it would require signaling from the AN to the NAS at
each channel zap. The draft proposes the introduction of a "Multicast
Flow-Group" to reduce the signaling load; this creates a new problem:
how to signal the termination of the reservation for a flow-group to the
NAS? This requires some time-out mechanism on the AN that releases
resources only after a flow-group has no active flows for some period of
time. However, such a timer would block the startup of unicast flows for
a short window following a leave of the last flow in a group. This
appears a highly undesirable effect.

	In my view, the resource admission control aspects for the
access line are instead best handled by the AN. This also calls for some
synchronization mechanism between AN, NAS and policy servers, but
different from what is described in this draft. These CAC concepts must
be addressed in a scope that is much broader than the ANCP WG.

While I agree that defining the overall CAC solution is broader than the
ANCP WG, the "black-box principle" agreed in Prague suggests that ANCP
needs to provide the necessary flow of information across the boxes
(where some functions are done by one box but affect the other one). 
 
I agree that ANCP plays a role in making sure that the AN+NAS tandem
behaves as a single black box. The framework draft was updated to
reflect this principle and highlight the top-level objectives of the
multicast architecture.
 
 For Video CAC to work across the two boxes with full functionality,
this includes allowing sharing of bandwidth between unicast CAC and
multicast CAC.  
 
I also agree that the sharing of bandwidth amongst unicast and multicast
CAC is a requirement in some network architectures. With the Access Node
being aware of the access line and multicast signaling, and the policy
system / NAS being aware of the aggregation network and unicast
resources, this indeed calls for a synchronziation mechanisms amongst
Access Node, NAS and Policy Server. This draft focuses on the Access
Node and NAS components, but I think we also need to look at the Policy
Server as part of the network architecture. This gives rise to other
possible solutions, which are broader than the scope of the ANCP WG. For
sure we need to address this, perhaps by involving other standards
organizations working on this.

The ANCP Requirements & Framework I-D seems to be assuming this too :
"
   Specifically, when performing multicast replication in the
access/aggregation network, the following features must remain supported
by
   the logical NAS:
...
   o  Connection admission control (CAC) for multicast and/or unicast
services
"
Sure, these are the top-level requirements. The framework doesn't state
how these are to be filled in. ANCP plays a role here, but nowhere is it
implied what specific message flow is being used.

With respect to resource admission control for the access line, I
suspect that different deployment approaches will be selected for
different networks. Some of these deployment approaches involve handling
bandwidth allocation for unicast CAC on the NAS, some involve
synchronizing to a remote server doing unicast CAC via NAS. We feel that
ANCP should not preclude these important deployment models. 
 
I agree that we need to cover cases where unicast and multicast CAC are
either done on separate or shared resources. I think there's different
ways to do this, each with their pros and cons. 
 
 Again, the corresponding mechanisms do not have to be used in all
deployments.

	Replication Termination 

	Similar to the basic notion of Multicast Conditional Access, it
should be possible to revoke authorization to join a channel at any time
by pushing a new policy to the AN that indicates that the subscriber is
no longer allowed to join the channel. Again, this is simpler than
performing an ANCP admission request for each join.

As you said: this is tied to the discussion on Conditional Access above.
If we accept that, _for some applications_, it is more efficient to
query a more centralised authorization repository than try dynamically
permanently change/rechange the corresponding policy rules on every AN,
then I think it is useful to have the corresponding ability to
selectively revoke an earlier authorization. If we don't accept it, then
the revoke mechanism is not needed.

	Based on the above, I believe that most of the flows in the
draft can be simplified considerably, while still meeting the objectives
set forward in the ANCP framework.

We aimed to update the framework to stay high level, yet reflect the key
requirements that the architecture needs to fulfill. I agree that this
leaves the details of the architecture, message flows and protocol
design open. These can be worked out while keeping the framework
document at the hig level.
 
Regards,
Sven
 
This is why the proposal suggests Multicast specific extensions for the
ANCP Framework & Requirement document.

Cheers

Francois

	Regards, 
	Sven

---

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

Sven and all,

> We aimed to update the framework to stay high level, yet reflect  
> the key requirements that the architecture needs to fulfill. I  
> agree that this leaves the details of the architecture, message  
> flows and protocol design open. These can be worked out while  
> keeping the framework document at the hig level.

My assumption is that the "Framework and Requirements" document is  
intended to define not just the ANCP high level requirements but also  
the key message flows so that the protocol can be designed based on  
this.
This is exactly what has been done for the use cases currently  
covered (3.1, 3.2 and 3.3). For each of those, there is a description  
of what sort of primitives (query/response) are needed between AN and  
NAS and what are the key parameters for those.

Do we not agree that the objective is exactly the same for the  
Multicast use case (ie identify the message flow and key parameters)?

Thanks

Francois

---

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

Hi Francois,

Sent: dinsdag 17 juli 2007 18:21

Sven and all, 

	We aimed to update the framework to stay high level, yet reflect
the key requirements that the architecture needs to fulfill. I agree
that this leaves the details of the architecture, message flows and
protocol design open. These can be worked out while keeping the
framework document at the hig level.

My assumption is that the "Framework and Requirements" document is
intended to define not just the ANCP high level requirements but also
the key message flows so that the protocol can be designed based on
this.
This is exactly what has been done for the use cases currently covered
(3.1, 3.2 and 3.3). For each of those, there is a description of what
sort of primitives (query/response) are needed between AN and NAS and
what are the key parameters for those.

Do we not agree that the objective is exactly the same for the Multicast
use case (ie identify the message flow and key parameters)?
 
We need to work out the details of multcast, that's for sure. The
framework stays at a high level, and the reason for doing that is that
we tried to reflect the concensus of the last IETF meeting, cf. minutes
below:
 
http://www3.ietf.org/proceedings/07mar/minutes/ancp.txt
 
"1. Framework text to be added on two boxes (NAS and AN) connected via
ANCP that functionally look like one black box 
2. For multicast section framework text needs black box level multicast
use-cases that follow the principle of multicast replication on the AN
but no loss of functionality. CAC is part of this, but addressing the
full unicast+multicast CAC system solution is not in scope of ANCP WG.
The existence of the CAC use-case is to be noted and ANCP mechanism
designed to fit as best as possible. 
3. More detailed solution proposals to be brought in as part of the ANCP
protocol specification work."
 
Regards,
Sven

Thanks

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 18 Jul 2007 12:49:20 +0200

Hello Sven,

On 18 Jul 2007, at 11:27, OOGHE Sven wrote:

> intended to define not just the ANCP high level requirements but  
> also the key message flows so that the protocol can be designed  
> based on this.
> covered (3.1, 3.2 and 3.3). For each of those, there is a  
> description of what sort of primitives (query/response) are needed  
> between AN and NAS and what are the key parameters for those.
> framework stays at a high level, and the reason for doing that is  
> that we tried to reflect the concensus of the last IETF meeting,  
> cf. minutes below:

I agree that the updated "Framework and Requirements" document did  
the right thing in only documenting the high level multicast  
requirements _for now_, because that is the level where there is  
agreement at this stage. But I don't agree that this is the end goal.

In my opinion, we should aim at progressing towards agreement at the  
next level of details (ie key primitives + key parameters for the  
multicast use case + protocol requirements) and document those in the  
"Framework and Requirements"  document.
Protocol extensions can only be defined if the protocol requirements  
are described to that level first. To me this is a fundamental  
objective of the "Framework and Requirements" document. This is why  
it is indeed called "Framework and Requirements"  and not just  
"Framework". This is exactly what has been done for all the other use  
cases. This is what should also be done for multicast.

But why don't we ask for guidance from the WG chairs on this?
(I'll do that right away in a separate message).

Francois

> "1. Framework text to be added on two boxes (NAS and AN) connected  
> via ANCP that functionally look like one black box
> 2. For multicast section framework text needs black box level  
> multicast use-cases that follow the principle of multicast  
> replication on the AN but no loss of functionality. CAC is part of  
> this, but addressing the full unicast+multicast CAC system solution  
> is not in scope of ANCP WG. The existence of the CAC use-case is to  
> be noted and ANCP mechanism designed to fit as best as possible.
> 3. More detailed solution proposals to be brought in as part of the  
> ANCP protocol specification work."
>
> Regards,
> Sven
>
> Thanks
>
> Francois
>
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 18 Jul 2007 12:54:51 +0200

Woj, Matthew,

Could you provide guidance on the topic below:
should the "Framework & Requirements" document aim at describing ANCP  
protocol requirements for the multicast use case, to the same level  
as already done for the other use cases (e.g. discuss the key  
primitives, key parameters for these primitives)?

Thanks

Francois

>>> Requirements I-D does yet not fully cover the Multicast use  
>>> cases. Right?
>>>
> In my opinion, we should aim at progressing towards agreement at  
> the next level of details (ie key primitives + key parameters for  
> the multicast use case + protocol requirements) and document those  
> in the "Framework and Requirements"  document.
> Protocol extensions can only be defined if the protocol  
> requirements are described to that level first. To me this is a  
> fundamental objective of the "Framework and Requirements" document.  
> This is why it is indeed called "Framework and Requirements"  and  
> not just "Framework". This is exactly what has been done for all  
> the other use cases. This is what should also be done for multicast.
>