[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANCP] ANCP Multicast Admission Control
Hi Francois,
For clarification: The text concerning PS-->AN and PS-->NAS-->AN
interactions is based on the proposal sent by Tina and Roberta in
http://www1.ietf.org/mail-archive/web/ancp/current/msg00446.html. At
that point in time, there was no feedback on the proposal yet.
I see you have concerns with the approach. Tina or Roberta, can you
share your point of view?
Regards,
Sven
-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:flefauch at cisco.com]
Sent: donderdag 31 januari 2008 12:37
To: DE CNODDER Stefaan
Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp at ietf.org
Subject: Re: [ANCP] ANCP Multicast Admission Control
Hi Stefaan,
On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote:
>
> Francois,
>
>> In addition, it is not clear to me how useful these additional models
>> are. It also raises a number of questions. For example, if the Policy
>> Server wants to query the AN, should it do so via the NAS instead of
>> directly to AN?
>
> Both are possible, is there any preferred way according to you?
>
> Also, to be able to perform complete Video CAC, the AN
>> would have to maintain user policy information (eg what is the
>> fraction of line bandwidth that can be used for Video for that
>> subscriber at that point in time considering the current DSL train
>> rate). Is this in line with current ANCP model? how is user info made
>> available to AN? What impact does all this have on ANCP?
>> While we can start discussing those questions and the usefulness of
>> such a model, IMHO this should not delay progress of current ANCP
>> documents.
>> So in short, I do _not_ support the additional text below relating to
>> the introduction of the new additional model (PS-->NAS-->AN) and
>> corresponding additional ANCP requirements.
>
> does this mean that you prefer PS-->AN?
No.
I am not expressing any preference for PS-->AN over PS-->NAS-->AN There
seemed to be a lot of additional text proposed below relating to
PS-->NAS-->AN as this involves ANCP more heavily. And I am simply
stating that I do not support adding such text.
The current framework defines PS-->AN and PS-->NAS-->AN as out of scope
for now ("It is therefore beyond the scope of this document.") and I
recommend we do not change scope at this stage if we want to have a
first version of the ANCP protocol in the targeted timeframe.
Those can always be easily added to the scope/protocol once there is
stronger consensus/understanding or their applicability in the group and
when the WG has completed the first base protocol spec.
Francois
> To be honest, for me both options are valid. Is there any specific
> reason why you would not like to have the request going to the NAS?
>
> regards,
> Stefaan
>
>
>> Cheers
>> Francois
>> On 28 Jan 2008, at 14:18, OOGHE Sven wrote:
>>> Hi,
>>>
>>> Based on the discussion on the list, I have prepared the following
>>> text proposal concerning multicast conditional access. I tried to
>>> cover the different scenarios that were identified on the list. This
>>> includes the proposal from Tina and Roberta, and feedback from
>>> Stefaan.
>>>
>>> If nobody objects, I will use the text below to update the text in
>>> section 3.4.2 in the ANCP Framework. I will also add the
>>> corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access
>>> Node) and
>>> 4.8.6 (NAS).
>>>
>>> Regards,
>>> Sven
>>>
>>> ---
>>>
>>> << Section 3.4.2 >>
>>>
>>> 3.4.2. Multicast Admission Control
>>>
>>> << first part of the section remains unchanged. The text from the
>>> second bullet onward is updated with below text >>
>>>
>>> o 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.
>>>
>>> The second scenario can be split in to cases:
>>>
>>> o 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.
>>>
>>> o In case the Policy Server queries the AN indirectly via the
>>> NAS,
>>> the interaction can be handled as an ANCP transaction.
>>> When the
>>> Policy Server queries the NAS, the NAS can use ANCP to query
>>> the
>>> AN, specifying the Access-Loop-Circuit-ID and the required
>>> bandwidth for the requested unicast flow. Upon receiving the
>>> query from the NAS, the AN then performs Admission Control and
>>> responds to the NAS, indicating if this unicast VoD request
>>> can be
>>> accepted or denied.
>>>
>>> 3.4.2.1. When not to perform Admission Control
>>>
>>> In general, the Access Node and NAS may not be aware of all
>>> possible
>>> multicast groups that will be streamed in the access network.
>>> For
>>> instance, it is likely that there will be multicast streams
>>> offered
>>> across the Internet. For these unknown streams, performing
>>> bandwidth
>>> admission control may be challenging.
>>>
>>> To solve this, these requests could be accepted without
>>> performing
>>> Admission Control. This solution works, provided that the
>>> network
>>> handles the streams as best effort, so that other streams are not
>>> impacted at times of congestion.
>>>
>>> Disabling Admission Control for unknown stream can be achieved by
>>> 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, in order to ensure that the streams are handled as best
>>> effort,
>>> the flow must be marked as such when entering the service
>>> provider
>>> network. 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.
>>>
>>> The above concept is applicable beyond the notion of "Internet
>>> streams" or other unknown streams; it can applied to known
>>> multicast
>>> streams as well. In this case, the Access Node or NAS will
>>> accept
>>> the stream even when bandwidth may not be sufficient to support
>>> the
>>> stream. This again requires that the stream is marked as best
>>> effort
>>> traffic before entering the access/aggregation network.
>>>
>>> 3.4.2.2. Multicast Admission Control and White Lists
>>>
>>> As mentioned in section Section 3.4.1, conditional access to
>>> popular
>>> IPTV channels can be achieved by means of a White and Black list
>>> configured on the Access Node. This method allows the Access
>>> Node to
>>> autonomously decide whether or not access can be granted to a
>>> multicast flow.
>>>
>>> IPTV is an example of a service that will not be offered as best
>>> effort, but requires some level of guaranteed Quality of Service.
>>> This requires the use of Multicast Admission Control. Hence, if
>>> the
>>> Access Node wants to autonomously perform the admission process,
>>> it
>>> must be aware of the bandwidth characteristics of multicast
>>> flows.
>>> Otherwise, the Access Node would have to query the NAS for
>>> Multicast
>>> Admission Control; this would defeat the purpose of using a
>>> White and
>>> Black list.
>>>
>>> Some network deployments may combine the use of White list, Black
>>> list
>>> and Grey list. In this case, the AN will be aware of the
>>> portion of
>>> the bandwidth used on the Access Port for flows matching an
>>> entry in
>>> the White list. In order to perform Multicast Admission Control
>>> for
>>> flows matching an entry in the Grey list, the NAS should add the
>>> bandwidth characteristics of the flow in the Admission Response
>>> message. In this model, the AN would query the NAS for
>>> conditional
>>> access, and would then locally perform Multicast Conditional
>>> Access,
>>> using the bandwidth information retrieved from the NAS.
>>>
>>> << Section 4.2: add following requirements >>
>>>
>>> o The ANCP MUST support providing an Access Node with bandwidth
>>> information associated with multicast flows that are part of a
>>> White list.
>>>
>>> o The ANCP SHOULD allow the NAS to indicate the bandwidth
>>> information, associated with the requested multicast flows,
>>> in the
>>> admission decision sent to the AN.
>>>
>>> o In case a unicast and multicast stream share resources on an
>>> Access Port, the ANCP MUST allow the NAS to query the AN to
>>> request an admission decision for a unicast flow to be sent
>>> over that Port.
>>>
>>> << Section 4.7.6: add following requirements >>
>>>
>>> o The AN must be able to perform Admission Control for multicast
>>> streams, using the bandwith information of the requested
>>> multicast
>>> flow. The information may be provisioned by a management
>>> system
>>> or by the NAS (using a Control Reqest message or an Admission
>>> Response message).
>>>
>>> o Upon receiving a query from the NAS to request an admission
>>> decision for a unicast flow to be sent over a particular
>>> Access
>>> Port, the AN must support using ANCP to reply to the NAS,
>>> indicating whether the request is to be honored or denied.
>>>
>>>
>>> << Section 4.8.6: add following requirements >>
>>>
>>> o The NAS should support using ANCP to configure multicast
>>> admission control information to Access Ports on an Access
>>> Node.
>>>
>>> o Upon receiving a query from the AN for a request to replicate
>>> a
>>> multicast flow to a particular Access Port, the NAS should
>>> support
>>> using ANCP to reply to the AN indicating the bandwidth
>>> information,
>>> associated with the requested multicast flow.
>>>
>>> o Upon receiving a request from a Policy Server for a unicast
>>> flow
>>> to be sent over a particular Access Port, the NAS must support
>>> using ANCP to query the AN to receive a response indicating
>>> whether the request is to be honored or denied.
>>>
>>> ---
>>>
>>> Sven Ooghe
>>> Alcatel-Lucent
>>> CTO Office, Access Division
>>> Copernicuslaan 50, 2018 Antwerp, Belgium
>>> tel.: +32 3 240 42 26
>>> fax: +32 3 240 40 73
>>>
>>> This message (including any attachments) contains confidential
>>> information intended for a specific individual and purpose, and is
>>> protected by law. If you are not the intended recipient, you should
>>> delete this message. Any disclosure, copying, or distribution of
>>> this
>>> message, or the taking of any action based on it, is strictly
>>> prohibited
>>> without the prior consent of its author.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp