Francois,
regards, Stefaan
Francois Le Faucheur IMAP wrote:
Hi Stefaan,
On 30 Jan 2008, at 12:17, Stefaan DE CNODDER wrote:
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 NAs uses "spontaneous Admission Response" to program replication in the AN. Same as described below by Sanjay in the case where the NAs processes IGMP Join/Leave. The mechanism by which NAS is made aware of Join/leave is transparent to ANCP. However, ANCP is involved precisely to allow AN to perform replication.
The model you describe is not really related to ANCP, so maybe better to leave it out to avoid new problems?
As I suggested earlier, my recommendation is to mention that scenario only as another example of situation where NAS processes all join/ leaves and then uses ANCP to facilitate AN-based replication.
Francois
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
_______________________________________________ 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