Sent: Wednesday, January 30, 2008 6:18 AM
To: Philippe Champagne (pchamp)
Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch);
Sven.Ooghe at alcatel-lucent.be; ancp at ietf.org
Subject: Re: [ANCP] ANCP Multicast Admission Control
Hi Phil,
How is in the case of HTTP the multicast stream delivered to
the DSLAMs?
The ethernet switches do not receive an IGMP message, so
their IGMP proxy/snooping will not see the new join. The
model you describe is not really related to ANCP, so maybe
better to leave it out to avoid new problems?
regards,
Stefaan
Philippe Champagne (pchamp) wrote:
Hi Sanjay
Question on this first paragraph and suggestion on the 2nd:
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. 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.
pchamp> So, this means ANCP will need to cover the case of
admitting or denying on the AN a unicast flow rather than
multicast flow...
ie: Policy Server quering the AN indirectly via the NAS. Or
you meant that only for the multicast part.
In case the NAS terminates IGMP signaling from the subscriber and
controls the
replication state on the AN, the CAC function can be completely
contained within
the NAS. NAS may locally maintain available "video" bandwidth on the
access-loop,
perform "video" bandwidth accounting, and perform CAC on the
received
IGMP. Based
on the available bandwidth, if the IGMP join can be honored, the NAS
can set the
replication state on the AN using ANCP. The policy server may query
the NAS to
perform admission control on a VoD flow, and update the available
"video" bandwidth
maintained by the NAS.
pchamp> This paragraph should also add some phrasing to
cover the case
where IGMP is not involved but rather an out of band protocol (HTTP
based). For example, the subscriber requesting a given
multicast on a
web page linked to the policy server. In turn it would
direct the NAS
to submit an admission control to the AN for that given
multicast flow.
This could be done by adding to the 2nd paragraph, the following
statement (or close to it):
Another case would be where the subscriber makes the request using
HTTP directly to a web server linked to the policy server, bypassing
both AN and NAS. In such case, the admission request would originate
from the policy server towards the NAS.
---------------------------------------------------------------
---------
*From:* Sanjay Wadhwa [mailto:swadhwa at juniper.net]
*Sent:* Tuesday, January 29, 2008 3:06 AM
*To:* Francois Le Faucheur (flefauch);
Sven.Ooghe at alcatel-lucent.be;
ancp at ietf.org
*Subject:* [ANCP] ANCP Multicast Admission Control
Sven, Francois, and All
We agreed in the attached thread below that the framework draft
needs to cover the case where IGMP signaling from the subscriber
terminates on the NAS, and the AN does not snoop IGMP
joins. The NAS
performs conditional access and admission control on the received
IGMP joins, and controls the replication state on the AN
using ANCP.
However, this is not adequately reflected in the draft. The draft
also does not consider the scenario where the bandwidth
accounting
and CAC function is completely contained within the NAS
(and doesn't
require complex synchronization between NAS and AN). I
am proposing
the following additions (in blue) to sections 3.4 and 3.4.2.
Thanks
-Sanjay
3.4. Multicast
With the rise of supporting IPTV services in a resource efficient
way, multicast services are getting increasingly important.
In case of an ATM access/aggregation network, such as the
reference
architecture specified in DSL Forum [TR-059], multicast traffic
replication is performed in the NAS. In this model,
typically IGMP
is used to control the multicast replication process towards the
subscribers. The NAS terminates and processes IGMP signaling
messages sent by the subscribers; towards the Regional
Network, the
NAS typically uses a multicast routing protocol such as PIM. The
ATM
Access Nodes and aggregation switches don't perform IGMP
processing,
nor do they perform multicast traffic replication. As a result,
network resources are wasted within the
access/aggregation network.
To overcome this resource inefficiency, the Access Node,
aggregation
node(s) and the NAS must all be involved in the multicast
replication process. This avoids that several copies of the same
stream are sent within the access/aggregation network. In case of
an
Ethernet-based access/aggregation network, this may, for example,
be
achieved by means of IGMP snooping or IGMP proxy in the
Access Node
and aggregation node(s).
By introducing IGMP processing in the access/aggregation
nodes, the
multicast replication process is now divided between the NAS, the
aggregation node(s) and Access Nodes. In order to ensure backward
compatibility with the ATM-based model, the NAS, aggregation node
and Access Node need to behave as a single logical
device. This
logical device must have exactly the same functionality as the NAS
in the ATM access/aggregation network. The Access Node Control
Mechanism can be used to make sure that this logical/functional
equivalence is achieved by exchanging the necessary information
between the Access Node and the NAS.
Another option is for NAS to terminate IGMP signaling from the
subscriber. In this scenario, NAS can use ANCP to create
replication
state in the AN for efficient multicast replication. The
NAS sends
a
single copy of the multicast stream towards the AN. The NAS can
perform
conditional access and multicast admission control on IGMP joins,
and create
replication state in the AN if the flow is admitted by the NAS.
The following subsections describe the different use
cases related to multicast.
3.4.2. Multicast Admission Control
The successful delivery of Triple Play Broadband services is
quickly
becoming a big capacity planning challenge for most of the Service
Providers nowadays. Solely increasing available bandwidth is not
always practical, cost-economical and/or sufficient to satisfy end
user experience given not only the strict requirements of unicast
delay sensitive applications like VoIP and Video, but
also the fast
growth of multicast interactive applications such as
videoconferencing, digital TV, digital audio, online movies and
networked gaming. These applications are typically characterized
by
a delay sensitive nature, an extremely loss sensitive nature and
intensive bandwidth requirements. They are also typically "non-
elastic", which means that they operate at a fixed bandwidth, that
cannot be dynamically adjusted to the currently available
bandwidth.
Therefore a Connection Admission Control (CAC) mechanism covering
admission of multicast traffic over the DSL Broadband access is
required, in order to avoid oversubscribing the available
bandwidth
and negatively impacting the end user experience.
Considering specifically admission control over the access line,
before honoring a user request to join a new multicast flow, the
combination of AN and NAS MUST ensure admission control is
performed
to validate that there is enough "video" bandwidth
remaining on the
access line to carry the new flow (in addition to all other
existing
multicast and unicast video traffic). The solution needs to cope
with multiple flows per access line and needs to allow access line
bandwidth to be dynamically shared across multicast and unicast
traffic (irrespective of whether unicast CAC is performed
by NAS or
by some off-path Policy Server).
Thus, supporting CAC for the access line requires some form of
synchronization between the entity performing multicast CAC (e.g.
the NAS or the AN) and the entity performing unicast CAC (e.g. the
NAS or a Policy Server) and the entity actually enforcing the
multicast replication (i.e. the AN). This synchronization can be
achieved in a number of ways:
o One approach is for the AN to query the NAS so that
both unicast
and multicast CAC for the access line are performed by the NAS.
In this case, the AN can use ANCP to query the NAS,
that in turn
performs multicast CAC and responds to the AN
indicating whether
the join is to be honored (and hence replication performed by
the
AN) or denied. In the process, the NAS may communicate with a
Policy Server. The NAS may locally maintain available
"video"
bandwidth on the access-loop, and perform "video" bandwidth
accounting for the access-loop. On receiving an admission
request
from the AN, the NAS can check available "video" bandwidth
before
admitting or denying the multicast flow. The policy server may
query the NAS to perform admission control on a VoD flow, and
update
the available "video" bandwidth maintained by the NAS.
Similarly to what has been discussed in the Conditional Access
use case, in response to a Admission Request from the AN for
admission control of a multicast flow, the NAS may send back an
Admission Response message to the AN, including admission
control
information for that multicast flow, as well as for other a set
of multicast flows sharing the same admission control rules.
The AN can then autonomously honor or deny
requests for a given user/port for the set of
Multicast flows as
indicated in the Admission Response message. The ANCP
requirements to support this approach (where the AN queries the
NAS) are specified in this document;
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. 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.
In case the NAS terminates IGMP signaling from the subscriber and
controls the
replication state on the AN, the CAC function can be completely
contained within
the NAS. NAS may locally maintain available "video" bandwidth on the
access-loop,
perform "video" bandwidth accounting, and perform CAC on the
received
IGMP. Based
on the available bandwidth, if the IGMP join can be honored, the NAS
can set the
replication state on the AN using ANCP. The policy server may query
the NAS to
perform admission control on a VoD flow, and update the available
"video" bandwidth
maintained by the NAS.
-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:flefauch at cisco.com]
Sent: maandag 26 november 2007 11:42
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp at ietf.org;
Maglione Roberta
Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG
follow-up)
Hi Sven,
On 26 Nov 2007, at 11:06, OOGHE Sven wrote:
Woj,
From what I can find on the email list, the proposed change
to section
3.4.4 is related to the following remark from Sanjay (mid
September
2007):
"The option I alluded to is IGMP from RG to BNG, and replication
on
the AN. The replication state on the AN created/controlled
via ANCP by BNG.
An optimization could be optional transparent snooping of
IGMP on the
AN to act on IGMP reports for leave only (to implement
"fast leave")."
Right. This is what initiated the thread.
I am also aware of other planned deployments where the Multicast
joins
are processed by the device behaving as the ANCP-controller (as
opposed to the AN).
As these ANCP deployments will exist, the ANCP specs ought to
recognize and allow them. Note that this has very little impact on
the
ANCP protocol anyways (since "spontaneous Admission Responses"
are already explicitly allowed anyways for multicast termination)
----------------------------------------------------------------------
--
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp