[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANCP] Events and event flags

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. 

Wojciech Dec (wdec) wrote:

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.


_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp