Subject: [ANCP] ANCP Multicast Admission Control

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 28 Jan 2008 14:18:35 +0100

Hi,

Based on the discussion on the list, I have prepared the following text
proposal concerning multicast conditional access. I tried to cover the
different scenarios that were identified on the list. This includes the
proposal from Tina and Roberta, and feedback from Stefaan.

If nobody objects, I will use the text below to update the text in
section 3.4.2 in the ANCP Framework. I will also add the corresponding
requirements in section 4.2 (ANCP), 4.7.6 (Access Node) and 4.8.6 (NAS).

Regards,
Sven

---

<< Section 3.4.2 >>

3.4.2.  Multicast Admission Control

<< first part of the section remains unchanged. The text from the second
bullet onward is updated with below text >>

  o  Another approach is the reverse: it consists of the Policy Server
      querying the AN (either directly, or indirectly via the NAS) so
      that both unicast and multicast CAC for the access line are
      performed by the AN.  In this case, a subscriber request for a
      unicast flow (e.g. a Video on Demand session) will trigger a
      resource request message towards a Policy Server; the latter will
      then query the AN, that in turn will perform unicast CAC for the
      access line and respond, indicating whether the unicast request is
      to be honored or denied.

   The second scenario can be split in to cases:

   o  In case the Policy Server queries the AN directly, the approach
      doesn't require the use of ANCP.  It is therefore beyond the scope
      of this document.

   o  In case the Policy Server queries the AN indirectly via the NAS,
      the interaction can be handled as an ANCP transaction.  When the
      Policy Server queries the NAS, the NAS can use ANCP to query the
      AN, specifying the Access-Loop-Circuit-ID and the required
      bandwidth for the requested unicast flow.  Upon receiving the
      query from the NAS, the AN then performs Admission Control and
      responds to the NAS, indicating if this unicast VoD request can be
      accepted or denied.

3.4.2.1.  When not to perform Admission Control

   In general, the Access Node and NAS may not be aware of all possible
   multicast groups that will be streamed in the access network.  For
   instance, it is likely that there will be multicast streams offered
   across the Internet.  For these unknown streams, performing bandwidth
   admission control may be challenging.

   To solve this, these requests could be accepted without performing
   Admission Control.  This solution works, provided that the network
   handles the streams as best effort, so that other streams are not
   impacted at times of congestion.

   Disabling Admission Control for unknown stream can be achieved by
   adding a "catch-all statement" in the Access Node white list or grey
   list.  In case the Access Node queries the NAS, the NAS on his turn
   will have to accept the request.  That way, the unknown streams are
   not blocked by default.

   Next, in order to ensure that the streams are handled as best effort,
   the flow must be marked as such when entering the service provider
   network.  This way, whenever congestion occurs somewhere in the
   access/aggregation network, this stream will be kicked out before the
   access provider's own premium content.

   The above concept is applicable beyond the notion of "Internet
   streams" or other unknown streams; it can applied to known multicast
   streams as well.  In this case, the Access Node or NAS will accept
   the stream even when bandwidth may not be sufficient to support the
   stream.  This again requires that the stream is marked as best effort
   traffic before entering the access/aggregation network.

3.4.2.2.  Multicast Admission Control and White Lists

   As mentioned in section Section 3.4.1, conditional access to popular
   IPTV channels can be achieved by means of a White and Black list
   configured on the Access Node.  This method allows the Access Node to
   autonomously decide whether or not access can be granted to a
   multicast flow.

   IPTV is an example of a service that will not be offered as best
   effort, but requires some level of guaranteed Quality of Service.
   This requires the use of Multicast Admission Control.  Hence, if the
   Access Node wants to autonomously perform the admission process, it
   must be aware of the bandwidth characteristics of multicast flows.
   Otherwise, the Access Node would have to query the NAS for Multicast
   Admission Control; this would defeat the purpose of using a White and
   Black list.

   Some network deployments may combine the use of White list, Black
list
   and Grey list.  In this case, the AN will be aware of the portion of
   the bandwidth used on the Access Port for flows matching an entry in
   the White list.  In order to perform Multicast Admission Control for
   flows matching an entry in the Grey list, the NAS should add the
   bandwidth characteristics of the flow in the Admission Response
   message.  In this model, the AN would query the NAS for conditional
   access, and would then locally perform Multicast Conditional Access,
   using the bandwidth information retrieved from the NAS.

<< Section 4.2: add following requirements >>

   o  The ANCP MUST support providing an Access Node with bandwidth
      information associated with multicast flows that are part of a
      White list.

   o  The ANCP SHOULD allow the NAS to indicate the bandwidth
      information, associated with the requested multicast flows, in the
      admission decision sent to the AN.

   o  In case a unicast and multicast stream share resources on an
      Access Port, the ANCP MUST allow the NAS to query the AN to
      request an admission decision for a unicast flow to be sent
      over that Port.

<< Section 4.7.6: add following requirements >>

   o  The AN must be able to perform Admission Control for multicast
      streams, using the bandwith information of the requested multicast
      flow.  The information may be provisioned by a management system
      or by the NAS (using a Control Reqest message or an Admission
      Response message).

   o  Upon receiving a query from the NAS to request an admission
      decision for a unicast flow to be sent over a particular Access
      Port, the AN must support using ANCP to reply to the NAS,
      indicating whether the request is to be honored or denied.

<< Section 4.8.6: add following requirements >>

   o  The NAS should support using ANCP to configure multicast
      admission control information to Access Ports on an Access Node.

   o  Upon receiving a query from the AN for a request to replicate a
      multicast flow to a particular Access Port, the NAS should support
      using ANCP to reply to the AN indicating the bandwidth
information,
      associated with the requested multicast flow.

   o  Upon receiving a request from a Policy Server for a unicast flow
      to be sent over a particular Access Port, the NAS must support
      using ANCP to query the AN to receive a response indicating
      whether the request is to be honored or denied.

---

Sven Ooghe
Alcatel-Lucent
CTO Office, Access Division
Copernicuslaan 50, 2018 Antwerp, Belgium
tel.: +32 3 240 42 26
fax: +32 3 240 40 73

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law.  If you are not the intended recipient, you should
delete this message.  Any disclosure, copying, or distribution of this
message, or the taking of any action based on it, is strictly prohibited
without the prior consent of its author.

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 11:52:50 +0100

Hello Sven,

The first bullet point in section 3.4.2 (starting by "One approach is  
for the AN to query the NAS so that both unicast and multicast CAC  
for the access line are performed by the NAS") was introduced to  
discuss the scenario of immediate interest for ANCP and to be covered  
by the first version of the ANCP requirement & protocol specs. This  
is why that bullet point finishes by the following statement:
"The ANCP requirements to support this approach (where the AN queries  
the NAS) are specified in this document;"

The second bullet point in section 3.4.2 (starting by "Another  
approach is the reverse") had really been added as background  
information discussing alternative approaches for achieving CAC, that  
were outside the scope of the first version of the ANCP requirement &  
protocol specs. This is why that bullet point finishes by the  
following statement:
"It is therefore beyond the scope of this document."

I recommend we do not change the scope of the first version of the  
ANCP documents at this stage and do not try to cover additional  
models. It seems there is enough in scope for the protocol design  
team to address in targeted timeframe for first version. If the WG  
decides later that those are useful additional models, they can be  
added then.

In addition, it is not clear to me how useful these additional models  
are. It also raises a number of questions. For example, if the Policy  
Server wants to query the AN, should it do so via the NAS instead of  
directly to AN? Also, to be able to perform complete Video CAC, the  
AN would have to maintain user policy information (eg what is the  
fraction of line bandwidth that can be used for Video for that  
subscriber at that point in time considering the current DSL train  
rate). Is this in line with current ANCP model? how is user info made  
available to AN? What impact does all this have on ANCP?
While we can start discussing those questions and the usefulness of  
such a model, IMHO this should not delay progress of current ANCP  
documents.

So in short, I do _not_ support the additional text below relating to  
the introduction of the new additional model (PS-->NAS-->AN) and  
corresponding additional ANCP requirements.

Cheers

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 12:05:21 +0100

Hi again Sven,

I support introduction of the text you propose below for section  
3.4.2.1 (related to our earlier agreement on being able to do CAC on  
some flows and not on others).

Minor suggestions:
	- could change title into something like "By-passing admission  
control for some flows" or "When not to perform admission control for  
a subset of flows". The idea being that the title makes it clear that  
we don't do CAC on some flows BUT still do CAC on others.
	- s/"so that other streams are not impacted"/"so that other streams  
(that are subject to admission control) are not impacted"/

Thanks

Francois

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 30 Jan 2008 18:32:00 +0100

Francois,

> directly to AN?

Both are possible, is there any preferred way according to you?

  Also, to be able to perform complete Video CAC, the  AN
> would have to maintain user policy information (eg what is the  fraction 
> of line bandwidth that can be used for Video for that  subscriber at 
> that point in time considering the current DSL train  rate). Is this in 
> line with current ANCP model? how is user info made  available to AN? 
> What impact does all this have on ANCP?

does this mean that you prefer PS-->AN?  To be honest, for me both 
options are valid.  Is there any specific reason why you would not like 
to have the request going to the NAS?

regards,
Stefaan

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 31 Jan 2008 12:36:49 +0100

Hi Stefaan,

On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote:

>
> Francois,
>
>> In addition, it is not clear to me how useful these additional  
>> models  are. It also raises a number of questions. For example, if  
>> the Policy  Server wants to query the AN, should it do so via the  
>> NAS instead of  directly to AN?
>
>> would have to maintain user policy information (eg what is the   
>> subscriber at that point in time considering the current DSL  
>> train  rate). Is this in line with current ANCP model? how is user  
>> info made  available to AN? What impact does all this have on ANCP?
>> While we can start discussing those questions and the usefulness  
>> of  such a model, IMHO this should not delay progress of current  
>> ANCP  documents.
>> So in short, I do _not_ support the additional text below relating  
>> to  the introduction of the new additional model (PS-->NAS-->AN)  
>> and  corresponding additional ANCP requirements.
>
> does this mean that you prefer PS-->AN?

No.
I am not expressing any preference for PS-->AN over PS-->NAS-->AN
There seemed to be a lot of additional text proposed below relating  
to PS-->NAS-->AN as this involves ANCP more heavily. And I am simply  
stating that I do not support adding such text.

The current framework defines PS-->AN and PS-->NAS-->AN as out of  
scope for now ("It is therefore beyond the scope of this document.")  
and I recommend we do not change scope at this stage if we want to  
have a first version of the ANCP protocol in the targeted timeframe.  
Those can always be easily added to the scope/protocol once there is  
stronger consensus/understanding or their applicability in the group  
and when the WG has completed the first base protocol spec.

Francois

> To be honest, for me both options are valid.  Is there any specific  
> reason why you would not like to have the request going to the NAS?
>
> regards,
> Stefaan
>
>
>> Cheers
>> Francois

---

From: "OOGHE Sven" <[email-masked]>
Date: Thu, 31 Jan 2008 13:19:21 +0100

Hi Francois,

For clarification: The text concerning PS-->AN and PS-->NAS-->AN
interactions is based on the proposal sent by Tina and Roberta in
http://www1.ietf.org/mail-archive/web/ancp/current/msg00446.html. At
that point in time, there was no feedback on the proposal yet.

I see you have concerns with the approach. Tina or Roberta, can you
share your point of view?

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: donderdag 31 januari 2008 12:37
To: DE CNODDER Stefaan
Cc: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Admission Control

Hi Stefaan,

> does this mean that you prefer PS-->AN?

No.
I am not expressing any preference for PS-->AN over PS-->NAS-->AN There
seemed to be a lot of additional text proposed below relating to
PS-->NAS-->AN as this involves ANCP more heavily. And I am simply
stating that I do not support adding such text.

The current framework defines PS-->AN and PS-->NAS-->AN as out of scope
for now ("It is therefore beyond the scope of this document.") and I
recommend we do not change scope at this stage if we want to have a
first version of the ANCP protocol in the targeted timeframe.  
Those can always be easily added to the scope/protocol once there is
stronger consensus/understanding or their applicability in the group and
when the WG has completed the first base protocol spec.

Francois

>>> Based on the discussion on the list, I have prepared the following  
>>> text proposal concerning multicast conditional access. I tried to 
>>> cover the different scenarios that were identified on the list. This

>>> includes  the proposal from Tina and Roberta, and feedback from 
>>> Stefaan.
>>>
>>> section 3.4.2 in the ANCP Framework. I will also add the 
>>> corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access 
>>> Node) and
>>> 4.8.6  (NAS).
>>>
>>> Regards,
>>> Sven
>>>
>>> ---
>>>
>>> << Section 3.4.2 >>
>>>
>>> << first part of the section remains unchanged. The text from the  
>>> second bullet onward is updated with below text >>
>>>
>>>    This requires the use of Multicast Admission Control.  Hence, if

>>> the

>>>    the White list.  In order to perform Multicast Admission Control

>>> for

---

From: "OOGHE Sven" <[email-masked]>
Date: Thu, 31 Jan 2008 13:20:35 +0100

Hi Francois,

I'm ok with both suggested changes. They better reflect what I intended
to write.

Regards,
Sven 

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: woensdag 30 januari 2008 12:05
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Admission Control

Hi again Sven,

Minor suggestions:
	- could change title into something like "By-passing admission
control for some flows" or "When not to perform admission control for a
subset of flows". The idea being that the title makes it clear that we
don't do CAC on some flows BUT still do CAC on others.
	- s/"so that other streams are not impacted"/"so that other
streams (that are subject to admission control) are not impacted"/

Thanks

Francois