Subject: [ANCP] ANCP Multicast Admission Control

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 29 Jan 2008 03:06:02 -0500

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:[email-masked]]

> Sent: maandag 26 november 2007 11:42

> To: OOGHE Sven

> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); [email-masked]; 

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 29 Jan 2008 15:23:50 +0100

Sanjay,
 
The model you describe below is covered in the new Spontaneous Admission
Response section, but not yet in the Admission Control section.
 
I will use your proposed text to complete the description in section 3.4
and 3.4.2.
 
Regards,
Sven

________________________________

From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: dinsdag 29 januari 2008 9:06
To: [email-masked]; OOGHE Sven; [email-masked]
Cc: Wojciech Dec (wdec)
Subject: ANCP Multicast Admission Control

Sven, Francois, and All

Thanks

-Sanjay

3.4. Multicast

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Tue, 29 Jan 2008 10:46:38 -0800

Hi Sanjay

Question on this first paragraph and suggestion on the 2nd:

 
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.

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:[email-masked]] 
	Sent: Tuesday, January 29, 2008 3:06 AM
	To: Francois Le Faucheur (flefauch);
[email-masked]; [email-masked]
	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.

	   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.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 29 Jan 2008 15:49:37 -0500

Hi Philippe

  I am not suggesting the approach where CAC is done by the AN, and the
policy server queries AN. This was already in the framework draft (I
actually have misgivings about this approach). I am proposing the
alternative where CAC is done on the NAS. The text that I suggested is
in blue (the rest of the sorrounding text is already in the framework
draft).

I am fine with including your suggestion on policy-server originating an
admission request to the NAS (when triggered via application level
signaling rather than IGMP).

-Sanjay

From: Philippe Champagne (pchamp) [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2008 1:47 PM
To: Sanjay Wadhwa; Francois Le Faucheur (flefauch);
[email-masked]; [email-masked]
Subject: RE: [ANCP] ANCP Multicast Admission Control

Hi Sanjay

 

 

	Sven, Francois, and All

	Thanks

	-Sanjay

	3.4. Multicast

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 11:16:30 +0100

Hello Sanjay,

I support your proposed changes with one small exception which is the  
deletion of the following statement: "In the process, the NAS may  
communicate with the Policy Server". I think we should keep this  
option in (it is only a "may" and is really transparent to ANCP).

I also support the point made by Philippe about other scenarios for  
how the "Join/Leave" information is communicated to NAS.
One editorial suggestion on that topic:
Whether the Join/Leave info is communicated to NAS via direct  
termination of IGMP from subscriber, or via application level  
signaling + via Policy Server, it is really all transparent to ANCP.  
So, as far as text editing is concerned, perhaps all these cases  
could be simply described as one single generic case characterized by  
the fact that NAS processes individual subscriber Join/Leave  
information somehow (and only mention the cases of (i) direct  
subscriber IGMP termination and (ii) user--->web-->Policy-Server-- 
 >NAS,  as practical examples of the generic case).

Cheers

Francois

On 29 Jan 2008, at 21:49, Sanjay Wadhwa wrote:

> Hi Philippe
>   I am not suggesting the approach where CAC is done by the AN, and  
> the policy server queries AN. This was already in the framework  
> draft (I actually have misgivings about this approach). I am  
> proposing the alternative where CAC is done on the NAS. The text  
> that I suggested is in blue (the rest of the sorrounding text is  
> already in the framework draft).
> I am fine with including your suggestion on policy-server  
> originating an admission request to the NAS (when triggered via  
> application level signaling rather than IGMP).
>
> -Sanjay
> 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.
>
>
> replication state on the AN using ANCP. The policy server may query  
> the NAS to
> 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.
> 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.
>
>
>
>
> To: Francois Le Faucheur (flefauch); [email-masked];  
> [email-masked]
>   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) tosections 3.4 and  
> 3.4.2.
>
> Thanks
> -Sanjay
>
>
> 3.4. Multicast
>
>       the available “video” bandwidth maintained by the NAS.
>
> replication state on the AN using ANCP. The policy server may query  
> the NAS to

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 30 Jan 2008 12:17:47 +0100

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:

> 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.
> 
>  
> 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.
> 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:[email-masked]]
>     *Sent:* Tuesday, January 29, 2008 3:06 AM
>     *To:* Francois Le Faucheur (flefauch); [email-masked];
>     [email-masked]
>     *Subject:* [ANCP] ANCP Multicast Admission Control
> 
>     Sven, Francois, and All
> 
>     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
> 
>  
> 
>    single copy of the multicast stream towards the AN. The NAS can perform 
> 
>    conditional access and multicast admission control on IGMP joins, and create 
> 
>    The following subsections describe the different use cases related to multicast.
> 
>      
> 
>       query the NAS to perform admission control on a VoD flow, and update
> 
> 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.
> 
>      
> 
>      
> 
> ------------------------------------------------------------------------
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 13:38:21 +0100

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

>> 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.
>> admitting or denying on the AN a unicast flow rather than  
>> multicast flow...
>> 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  
>> 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.
>>  Another case would be where the subscriber makes the request  
>> using HTTP directly to a web server linked to the policy server,  
>> 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).
>> 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.
>> 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     
>> (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:
>> "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
>> 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
>> 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.
>> 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  
>> 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.

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 30 Jan 2008 14:56:38 +0100

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

regards,
Stefaan

Francois Le Faucheur IMAP wrote:

> 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?
> 
> 
>>> 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.
>>> 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.
>>> NAS
>>> 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).
>>> 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.
>>> 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.
>>> flow. The policy server may       query the NAS to perform  admission 
>>> control on a VoD flow, and update
>>> 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  
>>> 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.
>>> 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.
>>>>  I am also aware of other planned deployments where the Multicast
>>>
>>>     joins
>>>
>>>>  recognize and allow them. Note that this has very little impact on
>>>
>>>     the
>>>

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Wed, 30 Jan 2008 06:07:05 -0800

Hi Stefaan

Francois described this in very good terms in another email. But here is
another way to describe it:

The model is addressed in draft maglione - spontaneous/asynchronous
multicast request where how the request was invoke (HTTP, Radius CoA or
any other method) is outside the scope. The end result is the same where
the AN will handle its execution part for the mcast signaling the same
way as if it had participated in the IGMP join/leave. The only
difference here is the AN needs to specifically create the L2 forwarding
entry on the user VLAN, sort of like if manually configured.

Regards
Phil

>From: Stefaan DE CNODDER [mailto:[email-masked]] 
>Sent: Wednesday, January 30, 2008 6:18 AM
>To: Philippe Champagne (pchamp)
>Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch); 
>Subject: Re: [ANCP] ANCP Multicast Admission Control
>
>
>Hi Phil,
>
>    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 
>> ie: Policy Server quering the AN indirectly via the NAS.  Or 
>you meant that only for the multicast part.
>> 
>>  
>> 
>>  
>> 
>received 
>> 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.
>>     and CAC function is completely contained within the NAS 
>(and doesn't
>> an
>>    state in the AN for efficient multicast replication. The 
>NAS sends 
>> a
>> 
>received

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 30 Jan 2008 15:16:58 +0100

Phil,

I understand that what triggers the sending of the spont adm request is 
out of scope and can be anyting, but more is needed than just sending 
such a message to make it working because also the ethernet switch has 
to forward the multicast stream to the DSLAM, which it wont do if no 
IGMP join was received.  So in the HTTP case, the user will not receive 
any multicast stream even though a spont adm request was sent by the NAS 
to the AN to configure a forwarding entry.  Such examples, that does not 
work, does not make things clearer and should not be in the document.

regards,
Stefaan

Philippe Champagne (pchamp) wrote:

>>>      then query the AN, that in turn will perform unicast 
>>
>>CAC for the
>>
>>>      the AN directly, the approach doesn't require the use 
>>
>>of ANCP.            
>>
>>>pchamp> This paragraph should also add some phrasing to 
>>
>>cover the case
>>
>>>based). For example, the subscriber requesting a given 
>>
>>multicast on a 
>>
>>>    *To:* Francois Le Faucheur (flefauch); 
>>
>>[email-masked];
>>
>>>    [email-masked]
>>>    terminates on the NAS, and the AN does not snoop IGMP 
>>
>>joins. The NAS
>>
>>>    IGMP joins, and controls the replication state on the AN 
>>
>>using ANCP.
>>
>>>    also does not consider the scenario where the bandwidth 
>>
>>accounting
>>
>>>    require complex synchronization between NAS and AN). I 
>>
>>am proposing
>>
>>>   network resources are wasted within the 
>>
>>access/aggregation network.
>>
>>> 
>>>
>>>   and Access Node need to behave as a single logical 
>>
>>device.  This    
>>
>>>   The following subsections describe the different use 
>>
>>cases related to multicast.
>>
>>>     
>>>
>>>   delay sensitive applications like VoIP and Video, but 
>>
>>also the fast
>>
>>>   to validate that there is enough "video" bandwidth 
>>
>>remaining on the
>>
>>>   traffic (irrespective of whether unicast CAC is performed 
>>
>>by NAS or
>>
>>>   o  One approach is for the AN to query the NAS so that 
>>
>>both unicast
>>
>>>      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
>>
>>>      requests for a given user/port for the set of 
>>
>>Multicast flows as
>>
>>>      then query the AN, that in turn will perform unicast 
>>
>>CAC for the
>>
>>>      the AN directly, the approach doesn't require the use 
>>
>>of ANCP.            
>>
>>----------------------------------------------------------------------
>>
>>>--
>>>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 15:24:22 +0100

HI Steefan,

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

> 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

>>> 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.
>> 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
>>>
>>>
>>>> Server queries       the AN directly, the approach doesn't  
>>>> require  the use of ANCP.                  It is therefore  
>>>> beyond the scope  of this document.
>>>> 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,  
>>>> 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  
>>>> 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):
>>>> 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.
>>>>          
>>>> ------------------------------------------------------------------- 
>>>> -- ---
>>>> draft
>>>> (and  doesn’t
>>>>    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).
>>>> 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.
>>>> 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.
>>>> (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:
>>>> "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
>>>>           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
>>>> Server queries       the AN directly, the approach doesn't  
>>>> require  the use of ANCP.                  It is therefore  
>>>> beyond the scope  of this document.
>>>> 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,  
>>>> 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  
>>>> available "video" bandwidth maintained by the  NAS.
>>>> ------------------------------------------------------------------- 
>>>> -- ---

---

From: "Jerome Moisand" <[email-masked]>
Date: Wed, 30 Jan 2008 09:21:13 -0500

Totally agreed with Philippe. SIP has been often discussed to invite
yourself to a multicast 'channel'. This is just another example. Might
not be the fastest "zapping" mechanism in the world, but some scenarios
do not require zapping. Point is there are multiple application-level
constructs allowing to join a multicast source. The cable world also
made a habit of defining other types of join/leave protocols at the
middleware level. 

This can lead to an "IMS-like" construct, where the app layer interacts
with a policy decision function, which interacts with the IP Edge (aka
BNG in DSLF parlance), which pushes explicit "join/leave" requests to
the Access Node via ANCP. If there is any Ethernet switch in-between,
just let them behave in flooding mode since the network has to be sized
anyway for traffic peaks, so it doesn't matter that much if a given
multicast flow goes to an Access Node which doesn't truly need it at a
given point in time. And anyway, the trend is to simplify or eliminate
such Ethernet connectivity, so this increasingly becomes a moot point.

This approach was actually part of the original L2CP "vision" a few
years ago when it all started.

Jerome - the ghost. ;-)

-----Original Message-----
From: Stefaan DE CNODDER [mailto:[email-masked]] 
Sent: Wednesday, January 30, 2008 9:17 AM
To: Philippe Champagne (pchamp)
Cc: [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Admission Control

Phil,

regards,
Stefaan

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 30 Jan 2008 15:35:44 +0100

Hi Jerome,

Thanks for the clarrification.  Now I understand it how it works.

regards,
Stefaan

Jerome Moisand wrote:

>>Francois described this in very good terms in another email. But here
> 
> is
> 
>>multicast request where how the request was invoke (HTTP, Radius CoA
> 
> or
> 
>>any other method) is outside the scope. The end result is the same
> 
> where
> 
>>difference here is the AN needs to specifically create the L2
> 
> forwarding
> 
>>>>>>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
>>>>