[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Unicast/Multicast BW Admission Control
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 at cisco.com>
To: "Stefaan DE CNODDER" <stefaan.de_cnodder at alcatel-lucent.be>
Cc: "OOGHE Sven" <Sven.Ooghe at alcatel-lucent.be>; <ancp at 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 at ietf.org
>>https://www1.ietf.org/mailman/listinfo/ancp
>
>
>
>
>_______________________________________________
>ANCP mailing list
>ANCP at ietf.org
>https://www1.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp
--
---
Toerless Eckert, eckert at cisco.com
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp