[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
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?
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