Subject: [ANCP] Events and event flags

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Jun 2008 19:20:08 -0400

I'm in the process of trying to define an extension to ANCP to cover a multicast 
use case that isn't explicit in the framework. I need to define several events 
(e.g. to request more multicast bandwidth). Events seem to be tied closely to 
event flags and flow control flags in GSMPv3, which puts a sharp limit on the 
number of possible events due to limited flag field lengths. Has this been 
thought through in ANCP? What is the strategy, if any, for defining new events?

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

---

From: Tom Taylor <[email-masked]>
Date: Sat, 21 Jun 2008 13:11:32 -0400

Thinking about it further, I suggest that the base ANCP protocol document define 
one or two events. The extension TLV associated with them would contain event 
subtype as a mandatory component. Other components would be defined by the 
individual extension documents.

If there is only one event, it should be "Admission Control Event". However, if 
there is a chance flow control is needed, there should be two events: "Resource 
Request Event" and "Resource Release Event". Obviously one would prefer not to 
flow control the latter, even if conditions are such that some flow control is 
needed.

Tom Taylor wrote:
> I'm in the process of trying to define an extension to ANCP to cover a 
> multicast use case that isn't explicit in the framework. I need to 
> define several events (e.g. to request more multicast bandwidth). Events 
> seem to be tied closely to event flags and flow control flags in GSMPv3, 
> which puts a sharp limit on the number of possible events due to limited 
> flag field lengths. Has this been thought through in ANCP? What is the 
> strategy, if any, for defining new events?
> 
> Tom Taylor

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 23 Jun 2008 08:56:23 +0200

Hi Tom,

I strongly believe that the messaging, besides some of the base header,
deriving from GSMPv3 are of little use. The approach you should consider
is along the lines of the Design Team proposal for multicast control. I
understand that an updated proposal from them is imminent (must be next
week at the latest), but you can observe and follow the concept followed
in the previous one:
http://www.ietf.org/mail-archive/web/ancp/current/msg00548.html

In more detail;
- Define message types which allow re-use across applications
- Define common TLV and wrapper TLVs used in messages.

In particular the flag field and result code ANCP inherited from GSMP in
the base header seem to be particularly unwieldy, and I would encourage
limiting their use or re-defining in a manner that does not cause
compatibility issues with existing ANCP implementations.
Could you share with us the events and flow control requirements that
you see?

Regards,
Woj.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom Taylor
> Sent: 21 June 2008 01:20
> To: [email-masked]
> Subject: [ANCP] Events and event flags
> 
> I'm in the process of trying to define an extension to ANCP 
> to cover a multicast use case that isn't explicit in the 
> framework. I need to define several events (e.g. to request 
> more multicast bandwidth). Events seem to be tied closely to 
> event flags and flow control flags in GSMPv3, which puts a 
> sharp limit on the number of possible events due to limited 
> flag field lengths. Has this been thought through in ANCP? 
> What is the strategy, if any, for defining new events?
> 
> Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Mon, 23 Jun 2008 08:38:16 -0400

I am considering a case where the task of multicast admission control is 
delegated to the Access Node. It is given an allocation of bandwidth for the 
purpose. From time to time it needs to request an increase in its allocation or 
it needs to give some back. In both cases, this requires an 
autonomously-generated message (i.e., an event report).

I see a theoretical possibility that flow control would be needed in high-load 
situations, and of course, there is always the possibility of the misbehaving 
Access Node.

An I-D has been written adopting a solution along the lines I previously 
indicated: a general Admission Control event with event subtypes. This draft is 
currently in the internal comment stage, but I'll share whatever text seems useful.