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

From: "Reith, Lothar" <[email-masked]>
Date: Wed, 29 Oct 2008 18:50:26 +0100

Hi Fortune,
 
I agree, that we have to be pragmatic. 
 
I recommend to check the meaning of bandwidth delegation, in order make the live of operators easier, who deploy ANs from multiple manufacturers. 
 
Based on my over 20 years experience in packet switching, I am afraid that there may be a risk of different interpretation of what "bandwidth" means.
 
Just stating kilobit/sec is not enough, you also have to state what you count  and how you enforce, with- our without buffering and how deep the buffer is.
 
In other words, while you delegate the authority for bandwidth control, you better also specify the meter used to control the bandwidth, for example by specifying the two parameters of the token bucket used, which defines the height and refill rate of the token bucket.
 
I assume there is consensus between the Access Node vendors on what is being counted, like the IP packet including the header ??? or PPPoE ???? or Ethernet ???? or only the payload ???
 
The point is, yes, you can do this bandwidth delegation by agreeing on the meter. And pragmatically, that is probably a good idea to meet delivery deadlines.  But it would be more flexible and extensible if the delegation of authority explicitly defines the meter as well, which the AN shall use for enforcement.
 
Best Regards 
 
Lothar Reith
Detecon International GmbH (Deutsche Telekom Group)

 

________________________________

	Von: Fortune HUANG [mailto:[email-masked]] 
	Gesendet: Mittwoch, 29. Oktober 2008 05:21
	An: Reith, Lothar; [email-masked]; 'OOGHE Sven'; 'Francois Le Faucheur (flefauch)'; Tina TSOU; Tom Taylor; Maglione Roberta; Wojciech Dec (wdec); Haag, Thomas; [email-masked]
	Betreff: 答复: [ANCP] DOA (was: ANCP Framework update)

	Hi Lothar,
	 
	Thank you very for your comments.
	 
	I can accept to extend the bandwidth delegation to Delegation of Authority conceptually in this draft. 
	As I said before, I know the latter would be more generic. 
	 
	However, since the bandwidth delegation is so important in implementation, I strongly suggest we also specify the bandwidth delegation as an explicit instance. The first reason is that I believe the bandwidth delegation is the most shining point of the Delegation of Authority. The second reason is that the bandwidth delegation will have actuall impact on the parameters and encoding of the ANCP messages, which we do care very much for we have to implement it.

	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!

________________________________

	发件人: Reith, Lothar [mailto:[email-masked]] 
	发送时间: 2008年10月29日 1:09
	收件人: Fortune HUANG; [email-masked]
	主题: AW: [ANCP] DOA (was: ANCP Framework update)

	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

---

From: "OOGHE Sven" <[email-masked]>
Date: Thu, 30 Oct 2008 11:07:45 +0100

Thomas, Lothar,
 
I agree that we should be clear on the terminology used. The actual net data rate defines the "bitpipe" that is conveyed from the Access Node to the NAS. It enables the NAS to use the bitpipe as it sees fit. In an Ethernet network, it would fill the bitpipe with Ethernet frames (regardless of higher layer protocols, PPPoE, IPoE, IPv4/IPv6 etc).
 
In terms of bandwidth delegation, I think we are referring to "delegation of authority to perform admission control on a subset of the actual net data rate". That's a mouthful but should be the most accurate description.
 
In my understanding, "bandwidth" refers to the notion of filling this "bitpipe". So when referring to 
 
"The NAS may locally maintain available "video" bandwidth  on the Access Loop, and perform video bandwidth accounting..."
 
I think this is actually correct. "video bandwidth" refers to a portion of the "bitpipe" that is used for video applications. How the NAS converts video bitrates into Ethernet frame rates and corresponding "video bandwidth" is IMHO beyond the scope of the ANCP framework.
 
Basically, I would prefer maintaining the definitions of net data rate and the existing text on "video bandwidth", clarifying that the latter can be a subset of the net data rate.
 
Regards,
Sven

From: Haag, Thomas [mailto:[email-masked]] 
Sent: donderdag 30 oktober 2008 9:12
To: [email-masked]; [email-masked]; [email-masked]; OOGHE Sven; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; DE CNODDER Stefaan
Subject: AW: [ANCP] DOA (was: ANCP Framework update)

All,
 
from my point of view we should not start a discussion about fundamentals which already defined.
 
The terminology "Actual data rate Up- and Downstream" is defined in TR-101 Table 3 and WT-147 Table 1. Actual Data Rate refers to ITU-T G.997.1 section 7.5.2.1 which means net data rate which is a common standardized reference. The terminology of bandwidth is not defined which is really a risk Lothar already mentioned.
 
Please see also my comment:
 
...The NAS may locally maintain available "video" bandwidth  [T.H.:]  (net data rate) on the 
         Access Loop, and perform video bandwidth accounting for the 

So considering the definition mentioned above reflecting the discussion about bandwidth delegation I think this does not match in detail.
 
Bandwidth delegation is used in a sense of video servcie oriented bandwidth. NAS works on layer3 which is different to AN net data rate which is reported by ANCP.
 
So I think delegation of bandwidth is misleading due to non harmonized definitions. 
>From my point of view the only way out is to refer to already standardized defintions having a common agreed reference.

Regards 
Thomas Haag 
Deutsche Telekom AG

Von: Reith, Lothar 
Gesendet: Mittwoch, 29. Oktober 2008 18:50
An: Fortune HUANG; [email-masked]; OOGHE Sven; Francois Le Faucheur (flefauch); Tina TSOU; Tom Taylor; Maglione Roberta; Wojciech Dec (wdec); Haag, Thomas; [email-masked]
Betreff: AW: [ANCP] DOA (was: ANCP Framework update)

Hi Fortune,

 

 

Best Regards 
 
Lothar Reith

 

	Hi Lothar,

	 

	Best Regards,
	Fortune

	Hi Fortune,

	 

	 

	 

	Hi Sven, Lothar et al,

	Best Regards,

	Fortune

	

	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