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

Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt



On 10 Mar 2008, at 13:23, Stefaan DE CNODDER wrote:

>
> Hi Francois,
>
> Why would on-path CAC signaling query the NAS?  Since it is on- 
> path, it is already on the NAS, so it will never query the NAS?

All I am saying is that, in the case of on-path signaling, the NAS is  
effectively queried by the on-path signaling itself.
I think we're in agreement.

Francois

>
> regards,
> Stefaan
>
>
> Francois Le Faucheur IMAP wrote:
>
>> Hello,
>> Please find below a few comments/suggestions on framework-05.
>> Francois
>> * under section 3.4.2:  first bullet.
>> The following text has been added:
>>       "The NAS may locally maintain available "video"
>>        bandwidth 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 Policy Server  
>> may  also
>>        query the NAS, so that it can perform admission control for  
>> the
>>        unicast flow, and update the available video bandwidth  
>> maintained
>>        by the NAS.
>> "
>> Could we make this slightly more generic and replace the last   
>> sentence with something like:
>> "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."
>> * section 3.4.2: 2nd bullet.
>> Similarly could we replace:
>> "For unicast video services the policy server may query the NAS  
>> to  perform admission control for the unicast flow, and update  
>> the  available video bandwidth maintained by the NAS."
>> by
>> "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."
>> * section 4.7.6
>> The last requirement in the section is intended to reflect the   
>> "Spontaneous Admission Response" functionality described in  
>> section  3.4.4.
>> As agreed, one scenario has been added to section 3.4.4 (ie where  
>> the  NAS is made aware of Join/Leave by other means than ANCP),  
>> and this  scenario needs to be reflected in section 4.7.6. I'd  
>> suggest adding  something like:
>> "   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 whether a  corresponding Admission Request was issued  
>> earlier by the AN or not.
>> "
>> * section 4.7.6:
>> replace:
>> "the AN should support receiving ANCP messages from the NAS   
>> containing conditional access information of multiple multicast  
>> flows"
>> by
>> "the AN should support receiving ANCP messages from the NAS   
>> containing conditional/admission access information of multiple   
>> multicast flows"
>> * section 4.7.6
>> There is one requirement stating that
>> "the AN should support receiving ANCP messages from the NAS   
>> containing conditional access information of multiple multicast  
>> flows."
>> The details of such mechanism is largely left to the protocol  
>> design  team, which is fine.
>> But it may be useful to identify one additional associated   
>> requirement on AN, allowing AN to tell NAS that there is no  
>> longer  any multicast flows joined (within the admitted set of  
>> flows) so the  corresponding bandwidth can be freed up (where CAC  
>> is performed).  This could read :
>> "   o  after receiving ANCP messages from the NAS containing   
>> conditional access information of a set of multicast flows, the  
>> AN  should support using ANCP to notify the NAS when there is no  
>> longer  any multicast flows from that set joined for a  
>> configurable time-out  period."
>> *section 4.8.6:
>> replace:
>> "the NAS should support sending an Admission Response message   
>> containing conditional access information of multiple multicast  
>> flows"
>> by
>> "the NAS should support sending an Admission Response message   
>> containing conditional/admission access information of multiple   
>> multicast flows"
>> * section 4.8.6:
>> there needs to be a requirement here also for spontaneous  
>> admission  response. I would propose:
>> "   o  the NAS may 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 earlier from the AN.
>> "
>> *section 4.8.6
>> I believe the WG agreed that the following text needs to be  
>> confirmed  on the list before it could stay in framework doc.
>> "
>>     o  The ANCP MUST allow the NAS, when replying to an AN  
>> request, to
>>        OPTIONALLY convey information on multiple multicast flows  
>> sharing
>>        the same conditional access rules.  This allows the AN to take
>>        autonomous decisions for these flows later on.
>> "
>> editorial suggestions:
>> ================
>> * Section 3.4:
>> Current text:
>> "The NAS can perform conditional
>>     access and multicast admission control on IGMP joins, and create
>>     replication state in the AN if the flow is admitted by the NAS."
>> Change:
>> replace "IGMP joins" by "joins"
>> Justification:
>> Joins/leaves may be communicated via IGMP or via some other means.
>> * section 3.4.2.2
>> replace:
>> "Otherwise, the Access Node would have to query the NAS for  
>> Multicast  Admission Control"
>> by:
>> "Otherwise, the Access Node would have to query the NAS for  
>> Multicast  Admission Control (as per Grey List behavior)"
>> Typos:
>> =====
>> * section 3.4.2:
>> s/as well as for other a set of multicast flows/as well as for a  
>> set  of multicast flows/
>> * in a few places: replace "lateron" by "later on"
>> _______________________________________________
>> ANCP mailing list
>> ANCP at ietf.org
>> https://www.ietf.org/mailman/listinfo/ancp

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