Subject: [ANCP] New multicast capability -- Committed multicast bandwidth reporting

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Jul 2010 09:12:47 -0400

Apologies to Kristian for taking so long to understand his use case. The basic 
requirement is to keep the NAS aware of the total amount of multicast bandwidth 
that the AN has allocated to each access line. The NAS uses this information to 
tune its scheduling as a router. To meet this requirement, the following is 
proposed:

1) Define a new capability, Committed multicast bandwidth reporting (0xTBD).

2) Implementation of this capability requires support of:

- the Provisioning message;

- a new message, Multicast Bandwidth Usage Report;

- two new TLVs, Bandwidth-Usage, and Bandwidth-Report-Delay.

3) The Multicast Bandwidth Usage Report message is sent from the AN to NAS. It 
contains one or more instances of the Bandwidth-Usage TLV.

The AN MUST send a Multicast Bandwidth Usage Report message whenever the total 
multicast bandwidth allocated to a given access line changes. Within the 
message, the AN MUST identify the access line and indicate the total multicast 
bandwidth amount by including an instance of the Bandwidth-Usage TLV.

To reduce the messaging rate, the NAS MAY provision a buffering period by 
including the Bandwidth-Report-Delay TLV in a Provisioning message sent to the 
AN. If a non-zero value is provided in the Bandwidth-Report-Delay TLV, the AN at 
any given moment is in one of two states: not-buffering, or buffering. The AN 
enters buffering state if it is in not-buffering state and the multicast 
bandwidth amount allocated to some access line changes. It leaves buffering 
state when the AN sends a Multicast Bandwidth Usage Report.

Upon entry to the buffering state, the AN MUST start a buffering timer and 
create a Multicast Bandwidth Usage Report message containing a Bandwidth-Usage 
TLV for the triggering access line, but MUST NOT send it. If a multicast 
bandwidth change occurs for another access line, the AN MUST add a new 
Bandwidth-Usage TLV to the message for that additional line. If a multicast 
bandwidth change occurs for a line for which a Bandwidth-Usage TLV is already 
present in the buffered report, the AN MUST update the Bandwidth-Usage TLV to 
contain the new value, rather than adding another Bandwidth-Usage TLV for the 
same access line.

The buffering timer expires after the period provided by the 
Bandwidth-Report-Delay TLV. When it expires, the AN MUST send the Multicast 
Bandwidth Usage Report message that it has been accumulating to the NAS. The AN 
MAY choose to send the message before the timer expires, in which case it MUST 
clear the buffering timer when the message is sent. In either case, the AN 
enters the not-buffering state as a result.

    Report buffering implies that NAS reaction to changes in multicast
    bandwidth usage is delayed by the amount of the buffering period.
    The choice of buffering period must take this into consideration.

4) The Bandwidth-Usage TLV contains a 32-bit multicast bandwidth amount 
(kbits/s), followed by a Target TLV identifying the access line for which a 
total multicast bandwidth amount is being reported.

5) The Bandwidth-Report-Delay TLV contains a 32-bit unsigned integer giving the 
amount of time (ms) a Multicast Bandwidth Usage Report message must be buffered 
before it is sent, as described above.

There is no interaction between this capability and the others described in the 
multicast extensions document.

Please comment.

Tom Taylor

---

From: "Reith, Lothar" <[email-masked]>
Date: Wed, 28 Jul 2010 17:17:34 +0200

Dear all,

I would like to request alignment of the terminology with the ANCP framework.

For example the term  "committed multicast bandwidth" should be replaced by "delegated multicast bandwidth". 

With regards to the term "usage" I would like to request clarification, if it is rather a reporting about a change in the amount of delegated multicast bandwidth, and not about actual usage of that bandwidth e.g. for a certain channel or with a certain amount of usage bytes transmitted. I believe, that the word "usage" may be inappropriate, if the reporting is just a reporting about a change in the amount of delegated multicast bandwidth, which strictly speaking would be a change in bandwidth reservation, but not necessarily in actual bandwidth usage.

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Mittwoch, 28. Juli 2010 15:13
An: [email-masked]; Poscic, Kristian (Kristian)
Betreff: [ANCP] New multicast capability -- Committed multicast bandwidthreporting

Apologies to Kristian for taking so long to understand his use case. The basic requirement is to keep the NAS aware of the total amount of multicast bandwidth that the AN has allocated to each access line. The NAS uses this information to tune its scheduling as a router. To meet this requirement, the following is
proposed:

3) The Multicast Bandwidth Usage Report message is sent from the AN to NAS. It contains one or more instances of the Bandwidth-Usage TLV.

The AN MUST send a Multicast Bandwidth Usage Report message whenever the total multicast bandwidth allocated to a given access line changes. Within the message, the AN MUST identify the access line and indicate the total multicast bandwidth amount by including an instance of the Bandwidth-Usage TLV.

To reduce the messaging rate, the NAS MAY provision a buffering period by including the Bandwidth-Report-Delay TLV in a Provisioning message sent to the AN. If a non-zero value is provided in the Bandwidth-Report-Delay TLV, the AN at any given moment is in one of two states: not-buffering, or buffering. The AN enters buffering state if it is in not-buffering state and the multicast bandwidth amount allocated to some access line changes. It leaves buffering state when the AN sends a Multicast Bandwidth Usage Report.

Upon entry to the buffering state, the AN MUST start a buffering timer and create a Multicast Bandwidth Usage Report message containing a Bandwidth-Usage TLV for the triggering access line, but MUST NOT send it. If a multicast bandwidth change occurs for another access line, the AN MUST add a new Bandwidth-Usage TLV to the message for that additional line. If a multicast bandwidth change occurs for a line for which a Bandwidth-Usage TLV is already present in the buffered report, the AN MUST update the Bandwidth-Usage TLV to contain the new value, rather than adding another Bandwidth-Usage TLV for the same access line.

The buffering timer expires after the period provided by the Bandwidth-Report-Delay TLV. When it expires, the AN MUST send the Multicast Bandwidth Usage Report message that it has been accumulating to the NAS. The AN MAY choose to send the message before the timer expires, in which case it MUST clear the buffering timer when the message is sent. In either case, the AN enters the not-buffering state as a result.

4) The Bandwidth-Usage TLV contains a 32-bit multicast bandwidth amount (kbits/s), followed by a Target TLV identifying the access line for which a total multicast bandwidth amount is being reported.

5) The Bandwidth-Report-Delay TLV contains a 32-bit unsigned integer giving the amount of time (ms) a Multicast Bandwidth Usage Report message must be buffered before it is sent, as described above.

There is no interaction between this capability and the others described in the multicast extensions document.

Please comment.

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

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Jul 2010 11:33:16 -0400

This is about reporting the amount of multicast bandwidth actually used. This is 
independent of (has nothing to do with) delegated bandwidth. The latter, if 
negotiated, provides a limit on how much bandwidth the AN can allocate, but does 
not say how much is actually in use.