Subject: Re: [ANCP] DOA (was: ANCP Framework update)

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

Hi Fortune,
 
regarding your statement:
 
The bandwidth can be negotiated dynamically in quantity. When the bandwidth on AN is insufficient, AN can ask for more from NAS/PS; when the bandwidth is insufficient, NAS/PS can ask for more from AN.
 
I would like to comment as follows:
 
Like in the real world, there is a hierarchy with the root being the legal owner of the resource, who is also the owner of the authority to control the resource. He delegates this authority  downwards through a chain of "Delegation of Authority" actions towards some enforcement point - in this case the AN. You may well imagine, that the root authority over all resource of a telco is with the shareholder annual assembly, which delegates it to the Management board, those to the CTO, and further to some line managers who delegate the control to some Policy Server, where our scope begins.
 
What you refer to as negotiation, is rather a delegation of authority which is quantized with a certain amount of bandwidth. Note that the PS may have delegated authority to control the full bandwidth to the NAS, but the NAS delegates only part of that bandwidth onwards to the AN. 
 
 And yes, the AN may ask for that Delegation of Authority specifying the amount desired, and the NAS may grant it. However, if the NAS needs some of the delegated authority back for his own purposes, he withdraws part of the quantized authority by claiming back part of the previously delegated authority over access circuit bandwidth.
 
The point is:  There is no real negotiation, because the AN and the NAS/PS are not peers. 
 
The AN has to obey to whatever the NAS grants, and is not allowed to exceed the delegated quantity of authority.  Note that the authority could be quantized in many ways, e.g. a time limited delegation of authority is just one example. Or a volume limited delegation of authority. This is still in line with the concept of "delegation of authority" in real life, and shows that this extensibility is very powerful indeed. 

Best Regards, Lothar Reith
Detecon International GmbH (Deutsche Telekom Group)

________________________________

Von: Fortune HUANG [mailto:[email-masked]]
Gesendet: Di 28.10.2008 15:41
An: 'OOGHE Sven'; Reith, Lothar; [email-masked]
Betreff: ??: [ANCP] DOA (was: ANCP Framework update)

Hi Sven, Lothar et al,

Yes, the "Delegation of Authority" is more generic than "Bandwidth Delegation" and I fully agree with the example from Lothar was that not only the bandwidth can be delegated but also the content access control can be delegated.

However, we have to pay attention to the difference of the delegation of bandwidth and the delegation of content access control.

The bandwidth can be negotiated dynamically in quantity. When the bandwidth on AN is insufficient, AN can ask for more from NAS/PS; when the bandwidth is insufficient, NAS/PS can ask for more from AN.

But this negotiation can not be applied for the content access control properly.

That is to say, if we extend the "bandwidth delegation" to "delegation of authority", the negotiation still needs to be specified specially for the bandwidth.

Best Regards,

Fortune

________________________________

???: [email-masked] [mailto:[email-masked]] ?? OOGHE Sven
????: 2008?10?27? 18:49
???: Reith, Lothar; [email-masked]
??: Re: [ANCP] DOA (was: ANCP Framework update)

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

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

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

   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.

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

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

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?

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.

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