Subject: [ANCP] ANCP Framework update

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 17 Oct 2008 11:23:26 +0200

Hi,

I've been updating the ANCP framework draft according to the suggested
changes from Roberta and Francois. Below I have copy-pasted the sections
that have undergone changes. Indented text has been changed. I think I
captured the essence of the notion of "bandwidth delegation". Please
review and see if this is capturing the agreements.

Regards,
Sven

3.4.2.  Multicast Admission Control

   The successful delivery of Triple Play Broadband services is quickly
   becoming a big capacity planning challenge for most of the Service
   Providers nowadays.  Solely increasing available bandwidth is not
   always practical, cost-economical and/or sufficient to satisfy end
   user experience given not only the strict requirements of unicast
   delay sensitive applications like VoIP and Video, but also the fast
   growth of multicast interactive applications such as
   videoconferencing, digital TV, digital audio, online movies and
   networked gaming.  These applications are typically characterized by
   a delay sensitive nature, an extremely loss sensitive nature and
   intensive bandwidth requirements.  They are also typically "non-
   elastic", which means that they operate at a fixed bandwidth, that
   cannot be dynamically adjusted to the currently available bandwidth.

   Therefore a Connection Admission Control (CAC) mechanism covering
   admission of multicast traffic over the DSL Broadband access is
   required, in order to avoid oversubscribing the available bandwidth
   and negatively impacting the end user experience.

   Considering specifically admission control over the access line,
   before honoring a user request to join a new multicast flow, the
   combination of AN and NAS MUST ensure admission control is performed
   to validate that there is enough "video" bandwidth remaining on the
   access line to carry the new flow (in addition to all other existing
   multicast and unicast video traffic).  The solution needs to cope
   with multiple flows per access line and needs to allow access line
   bandwidth to be dynamically shared across multicast and unicast
   traffic (irrespective of whether unicast CAC is performed by NAS or
   by some off-path Policy Server).

   Thus, supporting CAC for the access line requires some form of
   synchronization between the entity performing multicast CAC (e.g. the
   NAS or the AN) and the entity performing unicast CAC (e.g. the NAS or
   a Policy Server) and the entity actually enforcing the multicast
   replication (i.e. the AN).  This synchronization can be achieved in a
   number of ways:

   o  One approach is for the AN to query the NAS so that Admission
      Control for the access line is performed by the NAS (possibly with
      interactions with a Policy Server).  This can be done with or
      without "bandwidth delegation" to the AN.

      *  In case of Admission Control without AN Bandwidth Delegation,
         the AN can use ANCP to query the NAS, that in turn performs
         multicast Admission Control check for the new multicast flow
         and responds to the AN indicating whether the join is to be
         honored (and hence replication performed by the AN) or denied.
         The NAS may locally maintain available "video" bandwidth on the
         Access Loop, and perform video bandwidth accounting for the
         Access Loop.  Upon receiving an Admission Request from the AN,
         the NAS can check available "video" bandwidth before admitting
         or denying the multicast flow.  In the process, the NAS may
         communicate with the Policy Server.  For unicast video services
         such as Video on Demand (VoD), the NAS may also be queried (by
         a Policy Server or via on-path CAC signaling), so that it can
         perform admission control for the unicast flow, and update the
         available video bandwidth maintained by the NAS.

      *  In case of Admission Control with AN Bandwidth Delegation, the
         NAS (possibly with interactions with a Policy Server) manages
         total bandwidth for video admission, performs unicast admission
         control and uses ANCP to delegate a certain amount of bandwidth
         for some multicast flows to the Access Node.  In this scenario,
         upon receiving a join to a multicast flow which matches an
         entry in the White or Grey List whose entry is flagged as
         "Bandwidth Delegation", the AN must perform the necessary
         bandwidth admission control check for the new multicast flow,
         before starting the multicast flow replication.

      The ANCP requirements to support this approach are specified in
      this document.

   o  In case the subscriber communicates the "join/leave" information
      with the NAS (e.g. by terminating all subscriber IGMP signaling on
      the NAS, or by using some form of application level signaling),
      the approach is very similar.  In this case, the NAS may locally
      maintain available "video" bandwidth on the Access Loop, perform
      video bandwidth accounting, and perform CAC for unicast and
      multicast flows.  The NAS can set the replication state on the AN
      using ANCP if the flow is admitted.  For unicast video services
      the NAS may be queried (by a policy server or via on-path CAC
      signaling) to perform admission control for the unicast flow, and
      update the available video bandwidth maintained by the NAS.  The
      ANCP requirements to support this approach (where the AN queries
      the NAS) are specified in this document;

   o  In a third approach, the Policy Server queries the AN directly 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.  In this scenario 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.

4.2.  ANCP Multicast Requirements

   o  The ANCP MUST support providing multicast conditional access
      information to Access Ports on an Access Node, using Black, Grey
      and White lists.

   o  The ANCP MUST support binding a particular Black, Grey and White
      List to a given Access Port.

   o  Upon receiving a join to a multicast flow which matches the Grey
      List the ANCP MUST allow the AN to query the NAS to request an
      admission decision for replicating that multicast flow to a
      particular Access Port.

   o  The ANCP MUST allow the NAS to send an admission decision to the
      AN indicating whether or not a multicast flow may be replicated to
      a particular Access Port.

   o  The ANCP must allow the NAS to indicate to the AN whether or not
      Admission Control is needed for some multicast flows on a given
      Access Port and where needed whether or not it is to be performed
      with AN Bandwidth Delegation.

   o  In case of Admission Control without AN Bandwidth Delegation, the
      ANCP must allow the NAS to reply to a query from the AN indicating
      whether or not a multicast flow may be replicated to a particular
      Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation, the
      ANCP must allow the NAS to delegate a certain amount of bandwidth
      to the AN for a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation, the
      ANCP must allow the AN to query the NAS to request additional
      multicast bandwidth on a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation, the
      ANCP must allow the NAS to query (or to instruct) the AN to reduce
      the amount of bandwidth previously delegated on a given Access
      Port.

   o  In case of Admission Control with AN Bandwidth Delegation, the
      ANCP must allow the AN to autonomous release redundant multicast
      bandwidth on a given Access Port.

   o  The ANCP MUST allow the AN to send an Information Report message
      to the NAS whenever replication of a multicast flow on a
      particular Access Port start or ends.

   o  The ANCP MUST allow the AN to send an Information Report message
      to the NAS indicating the multicast traffic volume that has been
      replicated on that port.

   o  The ANCP MUST allow the NAS to indicate to the AN whether or not
      multicast accounting is needed for a multicast flow on a
      particular Access Port.

   o  In case multicast accounting is needed for a multicast flow on a
      particular Access Port, the ANCP MUST allow the NAS to indicate to
      the AN whether or not additional volume accounting information is
      required.

   o  The ANCP MUST allow the NAS to revoke a decision to replicate a
      multicast flow to a particular Access Port, which had been
      conveyed earlier to an AN.

   o  The ANCP MUST support partial updates of the White, Grey and Black
      lists.

   o  The ANCP MUST allow the NAS to query the AN to obtain information
      on what multicast flows are currently being replicated on a given
      Access Port, what Access Ports are currently receiving a given
      multicast flow, or what multicast flows are currently replicated
      on each Access Port.

Access Node multicast requirements (section 4.7.6)

   o  The AN must deny any join to a multicast flow matching the Black
      List for the relevant Access Port.

   o  The AN must accept any join to a multicast flow matching the White
      List and not flagged as "Bandwidth Delegation" for the relevant
      Access Port.

   o  Upon receiving a join to a multicast flow which matches the White
      List whose entry is flagged as "Bandwidth Delegation" for the
      relevant Access Port, the AN must perform the necessary bandwidth
      admission control check for the new flow before starting the
      multicast flow replication.

   o  Upon receiving a join to a multicast flow which matches the Grey
      List whose entry is flagged as "no Bandwidth Delegation" for the
      relevant Access Port, the AN must support using ANCP to query the
      NAS to receive a response indicating whether that join is to be
      honored or denied.  In this case, the NAS will perform both the
      necessary conditional access and the admission control checks for
      the new flow.

   o  Upon receiving a join to a multicast flow which matches the Grey
      List whose entry is flagged as "Bandwidth Delegation" for the
      relevant Access Port, the AN must first perform the necessary
      bandwidth admission control check for the new flow.  If
      successful, the AN must support using ANCP to query the NAS to
      receive a response indicating whether that join is to be honored
      or denied.

   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to notify the NAS when the the user leaves
      the multicast flow.

   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to query the NAS to request additional
      delegated multicast bandwidth on a given Access Port; the AN
      should be able to specify both the minimum and the preferred
      amount of additional multicast bandwidth requested.

   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving a Bandwidth Delegation Request from the NAS querying or
      instructing to decrease the delegated multicast bandwidth on a
      given Access Port, the AN must support using ANCP to send a
      Bandwidth Delegation Response indicating the new delegated
      multicast bandwidth.

   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to send a Bandwidth Release message to the
      NAS in order to release unused delegated multicast bandwidth on a
      given Access Port.

   o  If the requested multicast flow is not part of any list associated
      with the Access Port, the AN must discard the message.

   o  If the requested multicast flow is part of multiple lists
      associated with the Access Port, the AN must use the most specific
      match.

   o  If the requested multicast flow has the same most specific match
      in multiple lists, the AN must give precedence to the Black list,
      followed by the Grey list, and then the White list.

   o  The AN must support configuring a "catch-all" statement in the
      Black, White or Grey list in order to enforce a default behavior
      for a join to a multicast flow which doesn't match any other entry
      in a list for the relevant Access Port.

   o  Upon querying the NAS, the AN must not propagate the join message
      before the successful authorization from the NAS is received.

   o  Upon receiving a leave for a multicast flow which matches the Grey
      List, the AN should be able to autonomously stop replication and
      advertise this event to the NAS.

   o  The AN must support using ANCP to send an Information Report
      message to the NAS whenever replication starts or ends.

   o  The AN should support using ANCP to send an Information Report
      message to the NAS indicating the multicast traffic volume that
      has been replicated on that port.

   o  Upon request by the NAS, the AN must support using ANCP to send an
      Information Report message to the NAS, indicating what multicast
      flows are currently being replicated on a given Access Port.

   o  Upon request by the NAS, the AN must support using ANCP to send an
      Information Report message to the NAS, indicating what Access
      Ports are currently receiving a given multicast flow.

   o  Upon request by the NAS, the AN must support using ANCP to send an
      Information Report message to the NAS, indicating what multicast
      flows are currently being replicated on each Access Port.

   o  Upon receiving an Admission Response from the NAS, indicating that
      replication of a multicast flow is to start or stop on a given
      access port of the AN, the AN must enforce this decision.  This
      decision must be taken irrespective of whether or not a
      corresponding Admission Request was issued by the AN earlier on.

NAS multication requirements (section 4.8.6)

   o  The NAS must support using ANCP to configure multicast conditional
      access information to Access Ports on an Access Node, using Black
      Lists, Grey Lists and White Lists.

   o  The NAS must support using ANCP to indicate to the AN whether or
      not Admission Control is needed for some multicast flows on a
      given Access Port and where needed whether or not it is to be
      performed with AN Bandwidth Delegation.

   o  Upon receiving a query from the AN for a request to replicate a
      multicast flow to a particular Access Port, and no AN Bandwidth
      Delegation is needed for that flow, the NAS must be able to
      perform the necessary checks (conditional access and/or admission
      control) for the new flow.  The NAS must support using ANCP to
      reply to the AN indicating whether the request is to be honored or
      denied.

   o  Upon receiving a query from the AN for a request to replicate a
      multicast flow to a particular Access Port, and Admission Control
      with AN Bandwidth Delegation is needed for that flow, the NAS must
      be able to perform the conditional access checks (if needed), and
      must support using ANCP to delegate a certain amount of bandwidth
      to the AN for a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving a Bandwidth Delegation Request from the AN requesting to
      increase the delegated multicast bandwidth on a given Access Port,
      the NAS must support using ANCP to send a Bandwidth Delegation
      Response indicating the new delegating multicast bandwidth.

   o  In case of Admission Control with AN Bandwidth Delegation, the NAS
      must support using ANCP to send a request the AN to decrease the
      amount of multicast bandwidth previously delegated on a given
      Access Port; the NAS should be able to specify both the minimum
      and the preferred amount decrement of multicast bandwidth
      requested.

   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving an ANCP Bandwidth Release message, the NAS must be able
      to update accordingly its view of the multicast bandwidth
      delegated to the AN.

   o  The NAS must support using ANCP to configure the Access Node with
      the "maximum number of multicast streams" allowed to be received
      concurrently per Access Port.

   o  The NAS must support using ANCP to incrementally add, remove and
      modify individual entries in White, Black and Grey lists.

   o  The NAS must support using ANCP to indicate to the AN whether or
      not multicast accounting is needed for a multicast flow on a
      particular Access Port.

   o  In case multicast accounting is needed for a multicast flow on a
      particular Access Port, the NAS should support using ANCP to
      indicate to the AN whether or not additional volume accounting
      information is required.

   o  The NAS must support using ANCP to query the AN to obtain
      information on what multicast flows are currently replicated on a
      given Access Port.

   o  The NAS must support using ANCP to query the AN to obtain
      information on what Access Ports are currently receiving a given
      multicast flow.

   o  The NAS must support using ANCP to query the AN to obtain
      information on what multicast flows are currently replicated on
      each Access Port.

   o  When Multicast replication occurs on the AN, the NAS must support
      using ANCP to revoke the authorization to replicate a multicast
      flow to a particular Access Port.

   o  The NAS should support using ANCP to indicate to the AN that
      replication of a multicast flow is to start or stop on a given
      access port of the AN, without having received a corresponding
      Admission Request from the AN earlier on.

---

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://www.ietf.org/mailman/listinfo/ancp

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 20 Oct 2008 12:01:20 +0200

Sven and all,

>       necessary conditional access and the admission control checks  

Roberta, Tom and myself have started drafting an I-D that will propose  
ANCP protocol extensions supporting some of those requirements  
(building on top of ancp-mc-multicast).
In doing so, we revisited a point that came up multiple times: do we  
really need to provision a flag in each and every Grey/White List  
entry to activate/deactivate Bandwidth Delegation?

The current approach (as correctly reflected in the updated Framework)  
is:
	* define a flag in each Grey/White List entry
	* assume that this flag will normally either always be set in all  
entries or never set.
	* setting/no-setting the flag is all entries effectively acts as the  
knob to enable/disable Bandwidth Delegation, therefore we did not need  
to specify a specific knob to enable/disable Bandwidth Delegation.

Another approach would be:
	* remove flag from White/Grey list entries
	* define a specific knob to enable/disable Bandwidth Delegation at  
the AN granularity
	* in fact, define a generic AN-level provisioning method that could  
be used to enable/disable BAndwidth delegation, but could also be used  
for provisioning the "Service Profiles" that are currently assumed to  
be configured in AN, as well as provisioning the Multicast White/Grey/ 
Black Profiles

Considering that:
	- we got several times the feedback that per-entry BAndwidth  
Delegation flag was confusing since Bandwidth Delegation granularity  
is more AN-level (and may lead to difficulties if it is set on some  
entries and not on others)
	- it is likely that we'll need, anyways, a mechanism to provision  
things at AN level, that could be easily used to convey Bandwidth  
Delegation enable/disable knob.
we would like to propose to evolve to the newer approach.

Thoughts?

Francois

PS: Sven, if we go for the new approach, we can document in an email  
the deltas that would be needed to reflect that in framework.

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 20 Oct 2008 12:22:02 +0200

Francois,
 
Another approach we could take is to let the framework requirements be
agnostic as to how the Access Node knows whether or not Bandwidth
Delegation applies. We could describe the notion of Bandwidth Delegation
and the respective requirements for the Access Node and NAS in this
case.
 
The details of how the use of Bandwidth Delegation is communicated to
the Access Node - using a flag, some "on/off" knob or both - would be
left to the actual protocol specification work.
 
I think following this path would require relatively small edits to the
document. I'm ok to take a first shot at it.
 
Regards,
Sven

________________________________

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 20 oktober 2008 12:01
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [ANCP] ANCP Framework update

Sven and all, 

	   o  Upon receiving a join to a multicast flow which matches
the Grey 
	      List whose entry is flagged as "no Bandwidth Delegation"
for the 
	      relevant Access Port, the AN must support using ANCP to
query the 
	      NAS to receive a response indicating whether that join is
to be 
	      honored or denied.  In this case, the NAS will perform
both the 
	      necessary conditional access and the admission control
checks for 
	      the new flow.

Roberta, Tom and myself have started drafting an I-D that will propose
ANCP protocol extensions supporting some of those requirements (building
on top of ancp-mc-multicast).
In doing so, we revisited a point that came up multiple times: do we
really need to provision a flag in each and every Grey/White List entry
to activate/deactivate Bandwidth Delegation?

* define a specific knob to enable/disable Bandwidth Delegation at the
AN granularity
* in fact, define a generic AN-level provisioning method that could be
used to enable/disable BAndwidth delegation, but could also be used for
provisioning the "Service Profiles" that are currently assumed to be
configured in AN, as well as provisioning the Multicast White/Grey/Black
Profiles

Considering that:
- we got several times the feedback that per-entry BAndwidth Delegation
flag was confusing since Bandwidth Delegation granularity is more
AN-level (and may lead to difficulties if it is set on some entries and
not on others)
- it is likely that we'll need, anyways, a mechanism to provision things
at AN level, that could be easily used to convey Bandwidth Delegation
enable/disable knob.

Thoughts?

Francois

PS: Sven, if we go for the new approach, we can document in an email the
deltas that would be needed to reflect that in framework.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 20 Oct 2008 12:58:25 +0200

On 20 Oct 2008, at 12:22, OOGHE Sven wrote:

> Francois,
>
> Another approach we could take is to let the framework requirements  
> be agnostic as to how the Access Node knows whether or not Bandwidth  
> Delegation applies. We could describe the notion of Bandwidth  
> Delegation and the respective requirements for the Access Node and  
> NAS in this case.
>
> The details of how the use of Bandwidth Delegation is communicated  
> to the Access Node - using a flag, some "on/off" knob or both -  
> would be left to the actual protocol specification work.

Good idea. It will avoid these cross dependencies between framework  
and protocol, which indeed reflect that we are probably trying to be  
too precise/prescriptive in the framework.

>
> I think following this path would require relatively small edits to  
> the document. I'm ok to take a first shot at it.

That would be good.

Thanks

Francois

> Roberta, Tom and myself have started drafting an I-D that will  
> propose ANCP protocol extensions supporting some of those  
> requirements (building on top of ancp-mc-multicast).
> The current approach (as correctly reflected in the updated  
> Framework) is:
> knob to enable/disable Bandwidth Delegation, therefore we did not  
> need to specify a specific knob to enable/disable Bandwidth  
> Delegation.
>
> be used to enable/disable BAndwidth delegation, but could also be  
> used for provisioning the "Service Profiles" that are currently  
> assumed to be configured in AN, as well as provisioning the  
> Multicast White/Grey/Black Profiles
>
> Considering that:

---

From: "OOGHE Sven" <[email-masked]>
Date: Thu, 23 Oct 2008 12:57:08 +0200

Hi,
 
Here's the updated text. I removed any notion of "flags" or how the
Access Node is told whether or not Bandwidth Delegation applies. I also
covered Thomas' comments. Actually not that much work: the general ANCP
requirements as well as the NAS requirements were written in a
high-level way already. I only had to update the general text and some
of the Access Node requirements. Below the extracted text, let me know
your comments.
 
Regards,
Sven
 
---
 
General text

      *  In case of Admission Control without AN Bandwidth Delegation,
         the AN can use ANCP to query the NAS, that in turn performs
         multicast Admission Control check for the new multicast flow
         and responds to the AN indicating whether the join is to be
         honored (and hence replication performed by the AN) or denied.
         The NAS may locally maintain available "video" bandwidth on the
         Access Loop (as a portion of the Access Loop net data rate),
         and perform video bandwidth accounting for the Access Loop.
         Upon receiving an Admission Request from the AN, the NAS can
         check available "video" bandwidth before admitting or denying
         the multicast flow.  In the process, the NAS may communicate
         with the Policy Server.  For unicast video services such as
         Video on Demand (VoD), the NAS may also be queried (by a Policy
         Server or via on-path CAC signaling), so that it can perform
         admission control for the unicast flow, and update the
         available video bandwidth maintained by the NAS.
 
      *  In case of Admission Control with AN Bandwidth Delegation, the
         NAS (possibly with interactions with a Policy Server) manages
         total bandwidth for video admission, performs unicast admission
         control and uses ANCP to delegate a certain amount of bandwidth
         for some multicast flows to the Access Node.  In this scenario,
         upon receiving a join to a multicast flow which matches an
         entry in the White or Grey List, the AN must perform the
         necessary bandwidth admission control check for the new
         multicast flow, before starting the multicast flow replication.

Access Node requirements

   o  The AN must accept any join to a multicast flow matching the White
      List and for which no Bandwidth Delegation is required.
 
   o  Upon receiving a join to a multicast flow which matches the White
      List whose and for which Bandwidth Delegation is required, the AN
      must perform the necessary bandwidth admission control check for
      the new flow before starting the multicast flow replication.
 
   o  Upon receiving a join to a multicast flow which matches the Grey
      List and for which no Bandwidth Delegation is required, the AN
      must support using ANCP to query the NAS to receive a response
      indicating whether that join is to be honored or denied.  In this
      case, the NAS will perform both the necessary conditional access
      and the admission control checks for the new flow.
 
   o  Upon receiving a join to a multicast flow which matches the Grey
      List and for which Bandwidth Delegation is required, the AN must
      first perform the necessary bandwidth admission control check for
      the new flow.  If successful, the AN must support using ANCP to
      query the NAS to receive a response indicating whether that join
      is to be honored or denied.

 
 
Regards,
Sven

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 20 oktober 2008 12:58
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [ANCP] ANCP Framework update

	Francois,
	 
	Another approach we could take is to let the framework
requirements be agnostic as to how the Access Node knows whether or not
Bandwidth Delegation applies. We could describe the notion of Bandwidth
Delegation and the respective requirements for the Access Node and NAS
in this case.
	 
	The details of how the use of Bandwidth Delegation is
communicated to the Access Node - using a flag, some "on/off" knob or
both - would be left to the actual protocol specification work.

Good idea. It will avoid these cross dependencies between framework and
protocol, which indeed reflect that we are probably trying to be too
precise/prescriptive in the framework.

	I think following this path would require relatively small edits
to the document. I'm ok to take a first shot at it.

That would be good.

Thanks

Francois

	Regards,
	Sven

	Sven and all, 

		   o  Upon receiving a join to a multicast flow which
matches the Grey 
		      List whose entry is flagged as "no Bandwidth
Delegation" for the 
		      relevant Access Port, the AN must support using
ANCP to query the 
		      NAS to receive a response indicating whether that
join is to be 
		      honored or denied.  In this case, the NAS will
perform both the 
		      necessary conditional access and the admission
control checks for 
		      the new flow.

	Roberta, Tom and myself have started drafting an I-D that will
propose ANCP protocol extensions supporting some of those requirements
(building on top of ancp-mc-multicast).
	In doing so, we revisited a point that came up multiple times:
do we really need to provision a flag in each and every Grey/White List
entry to activate/deactivate Bandwidth Delegation?

	* assume that this flag will normally either always be set in
all entries or never set.
	
	* setting/no-setting the flag is all entries effectively acts as
the knob to enable/disable Bandwidth Delegation, therefore we did not
need to specify a specific knob to enable/disable Bandwidth Delegation.

	
	* define a specific knob to enable/disable Bandwidth Delegation
at the AN granularity
	* in fact, define a generic AN-level provisioning method that
could be used to enable/disable BAndwidth delegation, but could also be
used for provisioning the "Service Profiles" that are currently assumed
to be configured in AN, as well as provisioning the Multicast
White/Grey/Black Profiles

	Considering that:
	- we got several times the feedback that per-entry BAndwidth
Delegation flag was confusing since Bandwidth Delegation granularity is
more AN-level (and may lead to difficulties if it is set on some entries
and not on others)
	- it is likely that we'll need, anyways, a mechanism to
provision things at AN level, that could be easily used to convey
Bandwidth Delegation enable/disable knob.

	Thoughts?

	Francois

	PS: Sven, if we go for the new approach, we can document in an
email the deltas that would be needed to reflect that in framework.

---

From: "Reith, Lothar" <[email-masked]>
Date: Sun, 26 Oct 2008 16:46:39 +0100

Dear all,
 
the ANCP Framework contains the word "delegation", which in my mind is key to the whole concept of ANCP. 
 
I would like to suggest that the concept of "delegation" should be made more extensible. 
 
Narrowing it to the term "bandwidth delegation" does not lend itself very well to extensibility.
 
I would rather propose to introduce the more general term of DOA (Delegation of Authority), which is a well known concept in the real world, when a resource owner delegates control over part or all of his resources to someone else - e.g. during a vacation absence.
 
Today, ANCP does not just support delegation in the form of bandwidth delegation, but also in the form of delegation of content access control (delegation occurs for whitelist and blacklist content, but not for the greylist content).
 
I think the extensible concept "DOA" is very powerful when harnessed for Broadband Access using ANCP.
 
While updating the framework it may be worth a consideration to add this hook for extensibility by following means:
 
- replace the term "bandwidth delegation" by "DOA for part of access circuit bandwidth"
 
- introduce the first extension of the DOA concept by making clear that the concepts of  whitelist and blacklist are DOA for Content Access Control.
 
One more point with respect to the recent discussion about renaming the Policy Server.
 
I like to state that I am fine with the current name "policy server".  Historically, I beleive the name was chosen as a compromise between the RADIUS camp and the COPS camp.
 
If - given this background - we still want to change the name of the policy server, then perhaps DOA-server may be another alternative to consider. 
 
An important argument in this case would be, that the concept of "delegation of authority" is well aligned with the proxy concept, similar to a RADIUS Proxy Server, where the delegation of authority happens along a delegation chain which may span multiple RADIUS proxy servers and multiple domains. This aspect is missing in the other proposed names.
 
Best Regards,
 
Lothar Reith
Detecon International GmbH (Deutsche Telekom Group)

Von: [email-masked] im Auftrag von OOGHE Sven
Gesendet: Do 23.10.2008 12:57
An: [email-masked]
Betreff: Re: [ANCP] ANCP Framework update

Hi,
 
Here's the updated text. I removed any notion of "flags" or how the Access Node is told whether or not Bandwidth Delegation applies. I also covered Thomas' comments. Actually not that much work: the general ANCP requirements as well as the NAS requirements were written in a high-level way already. I only had to update the general text and some of the Access Node requirements. Below the extracted text, let me know your comments.
 
Regards,
Sven
 
---
 
General text

 

Access Node requirements

 

 

 
 
Regards,
Sven

	Francois,
	 
	Another approach we could take is to let the framework requirements be agnostic as to how the Access Node knows whether or not Bandwidth Delegation applies. We could describe the notion of Bandwidth Delegation and the respective requirements for the Access Node and NAS in this case.
	 
	The details of how the use of Bandwidth Delegation is communicated to the Access Node - using a flag, some "on/off" knob or both - would be left to the actual protocol specification work.

Good idea. It will avoid these cross dependencies between framework and protocol, which indeed reflect that we are probably trying to be too precise/prescriptive in the framework.

	I think following this path would require relatively small edits to the document. I'm ok to take a first shot at it.

That would be good.

Thanks

Francois

	Regards,
	Sven

	Sven and all, 

	Roberta, Tom and myself have started drafting an I-D that will propose ANCP protocol extensions supporting some of those requirements (building on top of ancp-mc-multicast).
	In doing so, we revisited a point that came up multiple times: do we really need to provision a flag in each and every Grey/White List entry to activate/deactivate Bandwidth Delegation?

	The current approach (as correctly reflected in the updated Framework) is:
	* define a flag in each Grey/White List entry
	
	* assume that this flag will normally either always be set in all entries or never set.
	
	* setting/no-setting the flag is all entries effectively acts as the knob to enable/disable Bandwidth Delegation, therefore we did not need to specify a specific knob to enable/disable Bandwidth Delegation.

	
	* define a specific knob to enable/disable Bandwidth Delegation at the AN granularity
	* in fact, define a generic AN-level provisioning method that could be used to enable/disable BAndwidth delegation, but could also be used for provisioning the "Service Profiles" that are currently assumed to be configured in AN, as well as provisioning the Multicast White/Grey/Black Profiles

	Considering that:
	- we got several times the feedback that per-entry BAndwidth Delegation flag was confusing since Bandwidth Delegation granularity is more AN-level (and may lead to difficulties if it is set on some entries and not on others)
	- it is likely that we'll need, anyways, a mechanism to provision things at AN level, that could be easily used to convey Bandwidth Delegation enable/disable knob.

	Thoughts?

	Francois

	PS: Sven, if we go for the new approach, we can document in an email the deltas that would be needed to reflect that in framework.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 27 Oct 2008 11:41:07 +0100

A few remarks inline.

	From: Fortune HUANG [mailto:[email-masked]] 
	Sent: 25 October 2008 02:45
	To: 'OOGHE Sven'; Francois Le Faucheur (flefauch); Tina TSOU; Tom Taylor; Maglione Roberta; Wojciech Dec (wdec); 'Haag, Thomas'; [email-masked]
	Cc: [email-masked]
	Subject: ??: [ANCP] ANCP Framework update

	Hi all,
	 
	Please see my three comments below, indicated by [Fortune 1/2/3: ...]
	 
	Best Regards,
	Fortune
	
	Huawei Technologies Co., Ltd.   

	Addr: Section F, Huawei Industrial Base, Bantian Longgang, Shenzhen 518129, P.R. China
	Tel: +86-755-28971871
	Fax: +86-755-28972352
	Mobile: +8615013838060
	Email: [email-masked]
	http://www.huawei.com
	-------------------------------------------------------------------------------------------------------------------------------------
	本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
	止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
	的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
	This e-mail and its attachments contain confidential information from HUAWEI, which 
	is intended only for the person or entity whose address is listed above. Any use of the 
	information contained herein in any way (including, but not limited to, total or partial 
	disclosure, reproduction, or dissemination) by persons other than the intended 
	recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
	phone or email immediately and delete it!

	发件人: [email-masked] [mailto:[email-masked]] 代表 OOGHE Sven
	发送时间: 2008年10月17日 17:23
	收件人: [email-masked]
	主题: [ANCP] ANCP Framework update

	Hi, 

	I've been updating the ANCP framework draft according to the suggested changes from Roberta and Francois. Below I have copy-pasted the sections that have undergone changes. Indented text has been changed. I think I captured the essence of the notion of "bandwidth delegation". Please review and see if this is capturing the agreements.

	Regards, 
	Sven 

	   by some off-path Policy Server) [Fortune 1: I suggest to replace "irrespective of whether unicast CAC is performed by NAS or 
	   by some off-path Policy Server" by "the unicast CAC is performed either by NAS or by some off-path Policy Server", because the latter looks clearer to describe the two scenarios

	NOTE: I also suggest we replace "Policy Server/PS" by  other name  as specified in my previous email. And this note applies to the whole document and all my comments.] .  

	Woj> The attractiveness of having the current "Policy Server" term is that it can be different things to different people (which it actually is) without overly affecting ANCP, and it's precise definition as say the RACS or other doesn't appear to be quite necessary in my opinion, neither is a specification that the PS is the sole place where admission control is performed

	[Fortune 2: The admission control is not actually performed by the NAS when there is interactions between NAS and PS. I suggest to replace the above paragraph with the following text: 

	Woj> The admission control can very well be done by the NAS with interactions with a Policy Server. That's what the original text states, and given that we don't want to open up the discussion of "what is a PS" it appears to be fine for now.

	   o  One approach is for the AN to query the NAS so that Admission 
	      Control for the access line is performed by the NAS  or the Policy Server which interacts with the AN via NAS.  This can be done with or 
	      without "bandwidth delegation" to the AN.  

	]

	[Fortune 3: This above paragraph is not clear enough for us to understand the requirement of the NAS in case the NAS communicates with a Policy Server. Actually, the NAS doesn't need to maintain the total bandwidth for video admission and doesn't need to perform unicast admission control. I strongly suggest we describe the two scenarios with or without interaction with a Policy Server in two seperate paragraphs, in order to avoid creating unprecise requirements of NAS and misleading to the NAS implementation. And the interactions between the AN and the NAS/PS are missing here. 

	Woj> Again, the points you make are valid assuming that the PS is the only entity making admission control decisions; it does not capture the model where the PS delegates admission control decision to the NAS. Personally I'd say that we do not want to iterate through descriptions of all the possible scenarios of; Admission control on the AN only; Admission control on the NAS only; Admission control coordinated between AN and NAS; Admission control coordinated between AN and NAS and PS; admission control coordinated between NAS and PS; admission control only on the PS, etc.

	Regards,

	Woj.

	*  In case of Admission Control with AN Bandwidth Delegation, one control scenario is that the 
	         NAS manages total bandwidth for video admission, performs unicast admission 
	         control and uses ANCP to delegate a certain amount of bandwidth 
	         for some multicast flows to the Access Node.  In this scenario, 
	         upon receiving a join to a multicast flow which matches an 
	         entry in the White or Grey List whose entry is flagged as 
	         "Bandwidth Delegation", the AN must perform the necessary 
	         bandwidth admission control check for the new multicast flow, 
	         before starting the multicast flow replication.  
	         When the bandwidth for multicast service is insufficient for the new multicast request,  
	         the AN requests the NAS for more bandwidth to meet the new multicast request. 
	         When the bandwidth for unicast service is insufficient for the new unicast request, 
	         the NAS requests the AN for more bandwidth to meet the new unicast request.

	*  In case of Admission Control with AN Bandwidth Delegation, another control scenario is that the 
	         Policy Server manages total bandwidth for video admission, performs unicast admission 
	         control, delegate a certain amount of bandwidth for some multicast flows to the Access Node via the NAS.  
	         In this scenario, the NAS interacts with the Access Node with the ANCP,  
	         while the protocol between the NAS and the Policy Server is out of scope of this document. 
	         In this scenario, upon receiving a join to a multicast flow which matches an 
	         entry in the White or Grey List whose entry is flagged as 
	         "Bandwidth Delegation", the AN must perform the necessary 
	         bandwidth admission control check for the new multicast flow, 
	         before starting the multicast flow replication. 
	         When the bandwidth for multicast service is insufficient for the new multicast request,  
	         the AN requests the Policy Server for more bandwidth to meet the new multicast request via the NAS. 
	         When the bandwidth for unicast service is insufficient for the new unicast request, 
	         the Policy Server requests the AN for more bandwidth to meet the new unicast request via the NAS.  

	]

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 27 Oct 2008 11:48:44 +0100

Hi Lothar,
 
I think the term "Delegation of Authority" captures the principle of
what bandwidth delegation is about. I'm fine either way, and would like
to ask other people on this list what they think.
 
Regards,
Sven

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reith, Lothar
Sent: zondag 26 oktober 2008 16:47
To: [email-masked]
Subject: [ANCP] DOA (was: ANCP Framework update)

Dear all,
 
the ANCP Framework contains the word "delegation", which in my mind is
key to the whole concept of ANCP. 
 
I would like to suggest that the concept of "delegation" should be made
more extensible. 
 
Narrowing it to the term "bandwidth delegation" does not lend itself
very well to extensibility.
 
I would rather propose to introduce the more general term of DOA
(Delegation of Authority), which is a well known concept in the real
world, when a resource owner delegates control over part or all of his
resources to someone else - e.g. during a vacation absence.
 
Today, ANCP does not just support delegation in the form of bandwidth
delegation, but also in the form of delegation of content access control
(delegation occurs for whitelist and blacklist content, but not for the
greylist content).
 
I think the extensible concept "DOA" is very powerful when harnessed for
Broadband Access using ANCP.
 
While updating the framework it may be worth a consideration to add this
hook for extensibility by following means:
 
- replace the term "bandwidth delegation" by "DOA for part of access
circuit bandwidth"
 
- introduce the first extension of the DOA concept by making clear that
the concepts of  whitelist and blacklist are DOA for Content Access
Control.
 
One more point with respect to the recent discussion about renaming the
Policy Server.
 
I like to state that I am fine with the current name "policy server".
Historically, I beleive the name was chosen as a compromise between the
RADIUS camp and the COPS camp.
 
If - given this background - we still want to change the name of the
policy server, then perhaps DOA-server may be another alternative to
consider. 
 
An important argument in this case would be, that the concept of
"delegation of authority" is well aligned with the proxy concept,
similar to a RADIUS Proxy Server, where the delegation of authority
happens along a delegation chain which may span multiple RADIUS proxy
servers and multiple domains. This aspect is missing in the other
proposed names.
 
Best Regards,
 
Lothar Reith

Hi,

Regards,
Sven
 
---
 
General text

 

Access Node requirements

 

 

 
 
Regards,
Sven

	Francois,

	 

That would be good.

Thanks

Francois

	Regards,
	Sven

	Sven and all, 

	

	

	
	Considering that:

	Thoughts?

	Francois

---

From: "Haag, Thomas" <[email-masked]>
Date: Tue, 28 Oct 2008 09:34:42 +0100

Hi Sven,
 
I also agree on DOA. 
This covers the issue in a better way.
 
Regards
Thomas

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
OOGHE Sven
Gesendet: Montag, 27. Oktober 2008 11:49
An: Reith, Lothar; [email-masked]
Betreff: Re: [ANCP] DOA (was: ANCP Framework update)

Hi Lothar,

Regards,
Sven

Dear all,

 

 

 

 

Best Regards,
 
Lothar Reith

Hi,

Regards,
Sven
 
---
 
General text

 

Access Node requirements

 

 

 
 
Regards,
Sven

	Francois,

	 

That would be good.

Thanks

Francois

	Regards,
	Sven

	Sven and all, 

	

	

	
	Considering that:

	Thoughts?

	Francois

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Oct 2008 09:02:21 -0400

I don't mind. I coined the phrase "bandwidth delegation" to express what was 
happening. The only thing is, "DOA" has unfortunate connotations -- it's a 
notation that appears on ambulance drivers' reports (Dead on Arrival) when their 
patient dies before reaching the hospital. So I'd prefer that "Delegation of 
Authority" be spelled out.

Haag, Thomas wrote:
> ------------------------------------------------------------------------
>

---

From: "Jerome Moisand" <[email-masked]>
Date: Tue, 28 Oct 2008 11:11:08 -0400

Folks,

Actually, in the very early days of L2CP (wasn't called ANCP by then)
discussions in the DSL-Forum, we did come up with the term "Delegation
of Authorization" terminology to describe the essence of the concept.

"Authorization" is a direct reference to AAA concepts, whether this is
an initial authorization (at user session establishment time), or
dynamic change of authorization (i.e. in-session).

We certainly didn't notice the unfortunate side-effect with ambulance
driver reports... But still, I always liked this "Delegation of
Authorization" terminology. A BRAS/BNG is essentially an authorization
enforcer for subscriber/service management. And ANCP is a mechanism to
delegate some of that enforcement to the access node.

Cheers,
Jerome - the ghost

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Taylor
Sent: Tuesday, October 28, 2008 9:02 AM
To: Haag, Thomas
Cc: [email-masked]; [email-masked]
Subject: Re: [ANCP] DOA

I don't mind. I coined the phrase "bandwidth delegation" to express what
was 
happening. The only thing is, "DOA" has unfortunate connotations -- it's
a 
notation that appears on ambulance drivers' reports (Dead on Arrival)
when their 
patient dies before reaching the hospital. So I'd prefer that
"Delegation of 
Authority" be spelled out.

> This covers the issue in a better way.
AN
>    o  In case of Admission Control with AN Bandwidth Delegation, the
AN
>    o  In case of Admission Control with AN Bandwidth Delegation, the
AN
>       NAS in order to release unused delegated multicast bandwidth on
a
and
Delegation.
> used for provisioning the "Service Profiles" that are currently
assumed
> Delegation flag was confusing since Bandwidth Delegation granularity
is

---

From: Peter Arberg <[email-masked]>
Date: Tue, 28 Oct 2008 08:51:32 -0700

I agree on the term Delegation of Authority.  Like Tom I will
like us to spell it out instead of creating a new acronym.

cheers,
peter

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Taylor
> Sent: 28. oktober 2008 06:02
> To: Haag, Thomas
> matches the White

---

From: "Reith, Lothar" <[email-masked]>
Date: Tue, 28 Oct 2008 18:21:53 +0100

Hi Jerome,
 
yes, that was probably in 2004 and maybe you also remember that it was my verbal contribution in my first L2CP telco when I joined the discussions on L2CP. At the time I was working for a vendor in a BRAS business development context.
 
Lothar Reith

Von: [email-masked] im Auftrag von Jerome Moisand
Gesendet: Di 28.10.2008 16:11
An: Tom Taylor; Haag, Thomas
Cc: [email-masked]; [email-masked]
Betreff: Re: [ANCP] DOA

Folks,

Cheers,
Jerome - the ghost

-----Original Message-----

AN
AN
AN
and
Delegation.
assumed
is

---

From: "Alan Kavanagh" <[email-masked]>
Date: Thu, 30 Oct 2008 18:14:47 -0400

Hi all
 
Some comments on Sven's updates on the ANCP Framework draft inline below
marked {A.K.}

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reith, Lothar
Sent: October 26, 2008 11:47 AM
To: [email-masked]
Subject: [ANCP] DOA (was: ANCP Framework update)

Dear all,

 

Today, ANCP does not just support delegation in the form of bandwidth
delegation, but also in the form of delegation of content access control
(delegation occurs for whitelist and blacklist content, but not for the
greylist content). 
{A.K} I see this as a delpoyment choice on whom manages what list and
what list should take local decisions or ask for further authority. I do
not see this as related to the delegation only. I think what we do need
is that when an Authoritive node such as the NAS informs an enforcement
point that this is what has been delegated to it so it can take local
decisions with or without informing/requesting the NAS on that local
decision. 

 

{A.K>} I dont think we need more terms here.

 
 
{A.K} I think the name Policy Server is sufficent in the current ANCP
Framework and we should not start a terminology change/debate on this at
this late stage.

Best Regards,
 
Lothar Reith

Hi,

Regards,
Sven
 
---
 
General text

 

{A.K}--> The AN "MAY" perform the necessary bandwidth adm ctl check, i
think this is more a deployment issue where some Service Providers may
decide that they allocate the max required b/w to satisfy all services
within the White/Grey lists. So if i say that i allocate 16MB od b/w
which should be sufficent for SD adn HD type TV channels, why would i
need to always check for necessary bandwidth, this is not required, and
should be a MAY only.  

Access Node requirements

 
 
{A.K}--> same as my above comment, this is a MAY. 

 

{A.K} I see this as more the NAS informing the AN of additional b/w
available for a given service type, not the AN requesting additional
b/w.  

{A.K}--> wait so here you are saying the NAS will request, same as aboev
comment, this is more about the NAS informing/delegating the AN on what
services it can make local decisions upon and that a given service may
have this associated b/w. I think we just need to make this clearer
here. 

{A.K}--> So this i do not see how this would work if the NAS has
delegated a "given amount of b/w" to the AN, then the AN maintains this
delegated b/w CAP regardless if it is used or not. The AN may inform the
NAS of what b/w is currently consumed from the delageted b/w but nothing
more than this, so i do not agree with this requirement.  
 
Regards,
Sven

	Francois,

	 

That would be good.

Thanks

Francois

	Regards,
	Sven

	From: Francois Le Faucheur IMAP [mailto:[email-masked]
<mailto:[email-masked]> ] 
	Sent: maandag 20 oktober 2008 12:01
	To: OOGHE Sven
	Cc: Francois Le Faucheur IMAP; [email-masked]
<mailto:[email-masked]> 
	Subject: Re: [ANCP] ANCP Framework update

	Sven and all, 

	

	

	
	Considering that:

	Thoughts?

	Francois

---

From: "Alan Kavanagh" <[email-masked]>
Date: Thu, 30 Oct 2008 18:30:41 -0400

Hi All

I think this captures this quite well and support this!
BR
Alan K 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jerome Moisand
Sent: October 28, 2008 11:11 AM
To: Tom Taylor; Haag, Thomas
Cc: [email-masked]; [email-masked]
Subject: Re: [ANCP] DOA

Folks,

Cheers,
Jerome - the ghost

-----Original Message-----

I don't mind. I coined the phrase "bandwidth delegation" to express what
was happening. The only thing is, "DOA" has unfortunate connotations --
it's a notation that appears on ambulance drivers' reports (Dead on
Arrival) when their patient dies before reaching the hospital. So I'd
prefer that "Delegation of Authority" be spelled out.

AN
AN
AN
>       NAS in order to release unused delegated multicast bandwidth on
a
requirements 
> be agnostic as to how the Access Node knows whether or
not

> 	The details of how the use of Bandwidth Delegation is
communicated to 
and
> 	I think following this path would require relatively small edits
to 
> the document. I'm ok to take a first shot at it.
matches the 
> Grey
Delegation" for 
> the
ANCP to query 
> the
join is to 
> be
perform both 
> the
control checks 
> for

> 	* assume that this flag will normally either always be set in
all 
> 	* setting/no-setting the flag is all entries effectively acts as
the 

> 	* define a specific knob to enable/disable Bandwidth Delegation
at 
> 	* in fact, define a generic AN-level provisioning method that
could 
assumed
is
> 	- it is likely that we'll need, anyways, a mechanism to
provision 
> 	PS: Sven, if we go for the new approach, we can document in an
email