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