Subject: Re: [ANCP] ANCP Framework update

From: "Haag, Thomas" <[email-masked]>
Date: Wed, 22 Oct 2008 12:42:01 +0200

Hi Sven,
 
please see my comments inline. 
 
Regards 
Thomas Haag 
Deutsche Telekom AG
Zentrum Technik Einführung
TE5-22, Internationale Standardisierung
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2088 (Tel.)
+49 521 9210-8411 (Fax)
+49 171 56 44 739 (Mobil)
Neu: Email: [email-masked]
http://www.telekom.com <http://www.telekom.com/>  

________________________________

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von OOGHE Sven
Gesendet: Freitag, 17. Oktober 2008 11:23
An: [email-masked]
Betreff: [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 

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  [T.H.: Is that correct as stated "NAS or Policy server"?; My understanding: Policy Server: Policy decission point; NAS controls AN by ANCP;AN: policy enforcement point]  
   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  [T.H.:]  (net data rate) 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  [T.H:] or fails . 

   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: Tina TSOU <[email-masked]>
Date: Wed, 22 Oct 2008 19:52:15 +0800

Hi all,
I agree with Thomas' comments.

B. R.
Tina

Messengers:

MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU     
Jabber: [email-masked]    Google talk: [email-masked]

+86-755-28971872 (Office)    +86-13922884380(Mobile)

On Oct 22, 2008, at 6:42 PM, Haag, Thomas wrote:

> http://www.telekom.com
> 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
>
>
>    a Policy Server) and the entity actually enforcing the multicast   
> [T.H.: Is that correct as stated "NAS or Policy server"?; My  
> understanding: Policy Server: Policy decission point; NAS controls  
> AN by ANCP;AN: policy enforcement point]
> AN
> AN
> AN
> NAS
> 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.
>

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 24 Oct 2008 11:55:45 +0800

Hi all,

The name "PS/Policy Server" used in this draft is also kind of confusing to me in this draft.
 
The entity descriped in this draft is actually an entity which manages (part of) the network bandwidth/resource and performs admission control for the unicast service. These functionalites are not quite clearly reflected by the name "Policy Server".
 
Therefore, I suggest we find a better name for this entity.
 
My proposal is to replace the "PS/Policy Server" with "RACS / Resource and Admission Control Subsystem" which is defined in ETSI TISPAN.
I think the name "RACS"can reflect the requirement for this entity precisely.

Best Regards,
Fortune

Huawei Technologies Co., Ltd. huawei_logo 

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!

  _____  

发件人: Tina TSOU [mailto:[email-masked]] 
发送时间: 2008年10月22日 19:52
收件人: Haag, Thomas
抄送: [email-masked]; [email-masked]
主题: Re: [ANCP] ANCP Framework update

Hi all,

B. R.
Tina

Messengers:

MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]    Google talk: [email-masked]

Hi Sven,

Regards 
Thomas Haag 
Deutsche Telekom AG
 <http://www.telekom.com/> http://www.telekom.com

  _____  

Hi,

Regards, 
Sven

---

Sven Ooghe 
Alcatel-Lucent

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 24 Oct 2008 14:13:59 +0200

Fortune,

I don't think it is a good idea to refer to this entity as RACS because:
	* as a general practise we don't want to depend on definition from  
external bodies
	* i don't believe the RACS terminology is that well known in IETF  
community
	* I would argue that in some scenarios some of the function performed  
by the NAS belong to the RACS functional entity (so that it is not  
correct to model the RACS as entirely outside the NAS)

As far as alternatives, perhaps we could use Policy Decision Point?  
that is an existing IETF concept and suggests that the entity makes  
admission decisions, some of which being bandwidth based.

In any case, the interactions with the Policy Server/Policy Decision  
Point/xxx   are outside the scope of ANCP of course, so we only need  
to indicate that optional communication with an entity involved in the  
admission decision is possible.

Francois

On 24 Oct 2008, at 05:55, Fortune HUANG wrote:

> The entity descriped in this draft is actually an entity which  
> manages (part of) the network bandwidth/resource and performs  
> admission control for the unicast service. These functionalites are  
> not quite clearly reflected by the name "Policy Server".
>
> My proposal is to replace the "PS/Policy Server" with "RACS /  
> Resource and Admission Control Subsystem" which is defined in ETSI  
> TISPAN.
> Huawei Technologies Co., Ltd. 
>
>
>>    a Policy Server) and the entity actually enforcing the  
>> multicast  [T.H.: Is that correct as stated "NAS or Policy  
>> server"?; My understanding: Policy Server: Policy decission point;  
>> NAS controls AN by ANCP;AN: policy enforcement point]
>> 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.
>>

---

From: Fortune HUANG <[email-masked]>
Date: Sat, 25 Oct 2008 10:22:25 +0800

Hi Francois,
 
I think there are no obvious Policy decision Point and Policy Enforcement Point in the model of the bidirectional bandwidth negotiation.
The entity performs admission control for unicast, but doesn't enforce any policy to the AN.
 
If the name "RACS" is not acceptable, I would provide another alternative called external Resource and Admission Control Entity (external RACE). This name is not yet defined in other bodies and it can also clearly reflect the functionalities in a very straightforward way. 

Best Reagards,
Fortune

  _____  

发件人: Francois Le Faucheur IMAP [mailto:[email-masked]] 
发送时间: 2008年10月24日 20:14
收件人: Fortune HUANG
抄送: Francois Le Faucheur IMAP; 'Tina TSOU'; 'Haag, Thomas'; [email-masked]
主题: Re: [ANCP] 答复: ANCP Framework update

Fortune, 

I don't think it is a good idea to refer to this entity as RACS because:
* as a general practise we don't want to depend on definition from external bodies

* i don't believe the RACS terminology is that well known in IETF community

* I would argue that in some scenarios some of the function performed by the NAS belong to the RACS functional entity (so that it is not correct to model the RACS as entirely outside the NAS)

As far as alternatives, perhaps we could use Policy Decision Point? that is an existing IETF concept and suggests that the entity makes admission decisions, some of which being bandwidth based.

In any case, the interactions with the Policy Server/Policy Decision Point/xxx   are outside the scope of ANCP of course, so we only need to indicate that optional communication with an entity involved in the admission decision is possible.

Francois  

Hi all,

 

Best Regards,
Fortune

  _____  

Hi all,

B. R.
Tina

Messengers:

Hi Sven,

Regards 
Thomas Haag 
Deutsche Telekom AG

  _____  

Hi,

Regards, 
Sven

---

Sven Ooghe 
Alcatel-Lucent