Hi All,
There are scenarios where AN is capable of doing unicast and
multicast Admission Control for the access line. In these cases, a
subscriber request for a unicast flow (e.g. a Video on Demand session)
will trigger a resource request message towards a Policy Server; the
latter will then query the AN, that in turn will perform unicast CAC for
the access line and respond, indicating whether the unicast request is
to be honored or denied.
Current ANCP framework draft already mentions the described scenario
proposing two possible approaches:
1. Policy Server querying the AN directly (the approach doesn't require
the use of ANCP.  It is therefore beyond the scope of this document)
2. Policy Server querying the AN indirectly via the NAS.

The second approach requires a control messages exchange between NAS and
AN thus it could fit in the ANCP framework. For the purpose of
flexibility and completeness we believe it would be worth to include
this use case and the related requirements in the current ANCP framework
draft.

Please see the text proposal for the described use case and requirements
below.
Feedback and comments are welcome.

Thanks and best regards,
Tina and Roberta

Section 3.4.2
Current text:
"Another approach is the reverse: it consists of the Policy Server
      querying the AN (either directly, or indirectly via the NAS) so
      that both unicast and multicast CAC for the access line are
      performed by the AN.  In this case, a subscriber request for a
      unicast flow (e.g. a Video on Demand session) will trigger a
      resource request message towards a Policy Server; the latter will
      then query the AN, that in turn will perform unicast CAC for the
      access line and respond, indicating whether the unicast request is
      to be honored or denied.  In case the Policy Server queries the AN
      directly, the approach doesn't require the use of ANCP.  It is
      therefore beyond the scope of this document."

Adding:

"In case the Policy Server queries the AN indirectly via the NAS this
interaction can be handled as an ANCP transaction, in particular the
Policy Server queries the NAS using a protocol that is out of scope of
this document, then the NAS uses ANCP to query the AN specifying the
Access-Loop-Circuit-ID and the required Bandwidth for the requested
unicast flow. The AN on receiving the query from the NAS performs the
Admission Control check and in turn responds indicating if this unicast
VoD request needs to be accepted or denied.

Protocol Requirements
Section 4.2
The ANCP MUST allow the NAS to query the AN to request an admission
decision for a unicast flow that will contend the bandwidth with the
multicast streams for a particular Access Port.

AN Requirements
Section 4.7.6
Upon receiving a query from the NAS for a unicast flow (e.g. a Video on
Demand session) request contending the bandwidth with the multicast
streams for a particular Access Port, the AN MUST support using ANCP to
reply to the NAS indicating whether the request is to be accepted or
denied.

NAS Requirements
Section 4.8.6
Upon receiving a request for a unicast flow (e.g. a Video on Demand
session) for a specific Access Port,  from the Policy Server, the NAS
MUST support using ANCP to query the AN to receive a response indicating
whether this unicast flow is to be accepted  or denied.


----- Original Message ----- 
From: "Toerless Eckert" <eckert@cisco.com>
To: "Stefaan DE CNODDER" <stefaan.de_cnodder@alcatel-lucent.be>
Cc: "OOGHE Sven" <Sven.Ooghe@alcatel-lucent.be>; <ancp@ietf.org>
Sent: Thursday, January 17, 2008 12:18 AM
Subject: Re: [ANCP] Multicast BW Admission Control


> Stefann,
>
> I am a bit confused about the Cc'ed and your prior mail, because i
> think they contradict each other. Aka:
>
> a) In the first mail i thought to understood that you wanted a
>   usage case of internet video for which no admission control is done,
>   and because there may be other video traffic for which admission
>   control IS done, the idea is to have the non-CACed video use simply
>   "best-effort" DSCP marking.
>
>   Correct ?
>
>   So, then i conclude that
>
>    I) this "intern video" traffic would somehow get DSCP best-effort
>       marked. We can probably keep the whee and why of that marking
>       outside of the scope of ANCP, even if it happens (orthogonal to 
> ANCP)
>       in the NAS. Correct ?
>
>    II) To make sure that this best-effort traffic would not cause
>        congestion/packet-loss of actually admission controlled video,
>        the AN would need to support well enough some form of DSCP-class
>        based queuing, by which some part of the bandwidth is prioritized
>        for DSCP-video-class traffic, which is the class for which ANCP
>        would also do admission control, eg: via grey-list.
>        The best-effort-DSCP video traffic might use this bandwidth,
>        but only when no DSCP-video-class traffic needs it.
>
>        Correct ? Which of these AN side queuing behavior do you think
>        should be documented by ANCP ?
>
>    III) The way that ANCP would cope withsuch trafic that wouldnot be
>         subject to it's admission control would as far as i  understand
>         it best be to just whitelist it. So the "internet-video" with
>         DSCP-best-effort would be part of the whitelist. In addition,
>         if we feel that such "internet-video" traffic might have
>         "unpredictable" addresses, then one might want to have matching
>         against whitelist be done by default, but if the adress of
>         a channel matches tthe greylist, then that greylist should
>         trace precedence.
>
>         Correct ?
>
> b) Now, in your second mail, you indicate that the NAS should provide
>   to the AN per-flow bandwidth information, such that the AN can do
>   add up on it's own bandwidth of flows to make admission control 
> decisions.
>   This seems to be a diffeent approach to what i thought was expressed
>   by the first mail.
>
> Can you calrify ??
>
> Thanks
>    Toerless
>
> P.S.: just returning from longer vacations, so i may be more confused than
> usual ;-))
>
>
> On Tue, Jan 15, 2008 at 02:31:18PM +0100, Stefaan DE CNODDER wrote:
>>
>> Hi Sven, Francois,
>>
>> see below...
>>
>> Francois Le Faucheur IMAP wrote:
>>
>> >Hi Sven,
>> >
>> >Thanks for the clarification.
>> >The approach you describe below seems fine to me.
>> >I think the key point it brings is to clarify that it it can make  sense
>> >to perform CAC on some flows and not on others (and the non- CACed flows
>> >will not break the CACed flows).
>> >
>>
>> How do I have interprete this CAC?  From the email discussion I
>> understand that the AN will not do any CAC on joins not matching with
>> any white/grey/black list, assuming that this is an Internet multicast
>> flow marked as best effort somewhere by an edge router.  Then I
>> understand that when the join matches a grey list, then all checks
>> including the bandwidth CAC checks are perfomed in the NAS, and when it
>> matches a white list, the NAS is not queried and hence the AN is doing
>> all the checks.  This is then done without querying the NAS, but still
>> under control by the NAS, i.e., the NAS configures the AN via ANCP such
>> that the AN can do all the checks.  The latter means that the NAS must
>> provision the AN with the necessary information to let the AN to make
>> the decisions: in a white list the NAS configures the multicast groups
>> (with masks), sources, bandwidth, and possibly other information (e.g.,
>> related to accounting).
>>
>> If this is what we all understand, then it looks good.
>>
>> regards,
>> Stefaan
>>
>>
>> >One small point. When you say "the NAS must make sure that the
>> >multicast content is marked as best-effort", I wasn't sure if you
>> >implied that the NAS would remark the flow. While that may be an
>> >option, a more common case if probably that the flow got marked best-
>> >effort somewhere upstream (eg when flow enters the SP network). I  think
>> >it would be worth clarifying.
>> >
>> >Also, I would suggest that the text uses "Internet/Unkown" channels
>> >just as an example of where this sort of approach may be used, but  make
>> >it clear it is a generic capability (e.g. the best-effort  approach can
>> >be used on known flows also).
>> >
>> >Cheers
>> >
>> >Francois
>> >
>> >On 8 Jan 2008, at 16:02, OOGHE Sven wrote:
>> >
>> >>Hi,
>> >>
>> >>In the Vancouver meeting minutes there is mention about multicast
>> >>bandwidth admission control, and what to do with "best effort" 
>> >>streams.
>> >>Apparently there is some confusion on the concept. This email is the
>> >>clarify my view on this.
>> >>
>> >>As already described in section 3.4.2, there is a need - next to 
>> >>policy
>> >>based admission control - to perform CAC for the video content being
>> >>streamed across the access network. The different options to do so are
>> >>already defined in the framework document.
>> >>
>> >>Now, the point I wanted to bring up is that in general, the Access 
>> >>Node
>> >>and NAS cannot be aware of all possible multicast groups. It is likely
>> >>that there may be multicast channels offered across the Internet. For
>> >>these streams, performing bandwidth admission control may be
>> >>challenging.
>> >>
>> >>To solve this, these requests should by default be accepted, but the
>> >>network should handle the traffic as best effort. This can be done by
>> >>first of all adding a "catch-all statement" in the Access Node white
>> >>list or grey list. In case the Access Node queries the NAS, the NAS on
>> >>his turn will have to accept the request. That way, the unknown 
>> >>streams
>> >>are not blocked by default. Next, the NAS must make sure that the
>> >>multicast content coming from the Internet is marked as best effort
>> >>traffic. This way, whenever congestion occurs somewhere in the
>> >>access/aggregation network, this stream will be kicked out before the
>> >>access provider's own premium content.
>> >>
>> >>If people agree with this, I suggest to add the above discussion to 
>> >>the
>> >>framework document.
>> >>
>> >>Regards,
>> >>Sven
>> >>
>> >>
>> >>_______________________________________________
>> >>ANCP mailing list
>> >>ANCP@ietf.org
>> >>https://www1.ietf.org/mailman/listinfo/ancp
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >ANCP mailing list
>> >ANCP@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/ancp
>>
>>
>> _______________________________________________
>> ANCP mailing list
>> ANCP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ancp
>
> -- 
> ---
> Toerless Eckert, eckert@cisco.com
> Cisco NSSTG Systems & Technology Architecture
> "The strategy is what you do, not what you write" - Wesley Clark
>
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp 



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp