Re: [ANCP] ANCP Multicast Admission Control

[Francois Le Faucheur IMAP <flefauch at cisco.com>]

HI Steefan,

On 30 Jan 2008, at 14:56, Stefaan DE CNODDER wrote:

> Francois,
>
> The use of "spontaneous Admission Response" is clear to me but my  
> question is how the multicast streams gets to the DSLAM if the  
> Ethernet switches in between do not receive an IGMP message.

I got you now. Sorry I misunderstood your question earlier.

My assumption was that the multicast stream can be present at AN  
either via static joins or via the AN issuing an IGMP Join itself (if  
it gets an ANCP Admission Response for a flow that it is not yet  
receiving).

> Just programming multicast replication in the DSLAM is not enough.   
> Although ANCP does not care why a NAS is sending a "spontaneous  
> Admission Response" and examples may be added to the framework  
> document for extra illustration, the framework document should not  
> describe examples that do not work.

that sounds right.

Regards

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



_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp