>> 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