Subject: [ANCP] Multicast in ANCP

From: [email-masked]
Date: Tue, 6 Mar 2007 13:49:02 +0000

I would like to start a discussion on what the working group would like to
do with Multicast in ANCP.

Currently the ANCP charter includes multicast as one of the use cases, as
follows:

"When multicast replication for subscriber-bound traffic is performed at
the AN, it off-loads the network between the AN and NAS. However, a
subscriber's policy and configuration for multicast traffic may only be
known at the NAS. ANCP will provide a mechanism to communicate the
necessary information exchange between the AN and NAS so as to allow the AN
to perform subscriber bound multicast group replication in line with the
subscriber's policy and configuration, and also allow the NAS to follow
each subscriber's multicast group membership."

The framework draft (draft-ietf-ancp-framework-01.txt) says that the access
loop configuration mechanisms may be useful for setting the per-Subscriber
multicast channel entitlement information, used for IPTV applications where
the Access Node is performing IGMP snooping or IGMP proxy function. It goes
on to say that a Subscriber's policy and  configuration for multicast
traffic might only be known at the NAS. The Access Node Control Mechanism
could be used to exchange the necessary information between the Access Node
and the NAS so as to allow the Access Node to perform multicast replication
in line with  the Subscriber's policy and configuration, and also allow the
NAS to follow each Subscriber's multicast group membership.

None of these multicast mechanisms are defined in the ANCP protocol draft,
and I think there is insufficient detail in the framework draft to fully
specify this use case.

There has been very little work on this since the charter discussions, but
the ANCP working group needs to clarify what it wants to do (if anything)
with multicast for the framework can move forward. I think there are two
choices: Either we should clarify the use case and specify the ANCP
protocol to support it, or we should remove the multicast use case from the
framework for now.

Please post your opinions to the list. We plan to have a discussion on this
in Prague, and to try to reach a consensus at around that time.

Best regards,

Matthew

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 12:07:43 +0530

My view on use of ANCP for multicast is as follows:

As defined the ANCP framework draft, the Access Node could get the
subscribers configuration for Multicast from the NAS. This would
typically include the list of channels authorized to view by the
subscribers connected to user ports.

Having said that, whether the Access Node gets the subscribers
configuration list from the NAS using PUSH or PULL mechanism and whether
Access Node gets the list statically or dynamically (or every few time
intervals) should be left to implementation specific. I think we don't
need to mention about this in any of ANCP drafts. The objective is to
get the configuration information from the NAS.

Now, what Access Node can possibly do with the subscriber configuration
(specically channel entitlement list)? The main usage of this list I see
is, the Access Node (which is performing IGMP snoop or IGMP proxy) can
start replicating the channel to a suscriber based on the channel
entitlement list. 

Consider a case, if user post '5' is already subscribed to channel 'x',
if user port '10' issue a join message to receive channel 'x', the
Access Node could decide to replicate the channel 'x' to user port '10'
based on the authorization list. This way the channel zap time would be
faster.

Again an optimization could be that Access Node after exchancing channel
authorization list could subscribe to all/all the premium channels which
user ports are entitiled to join, and start replicating to user ports
(based on authorization list)as when the join requests come. This is
debatable and asolutely an implementation issue. We don't need to cover
this in any of ANCP drafts.

On the downside of ANCP use case for multicast, I see ANCP serves no
purpose, when two subscribers (two Set-Top-Boxes) are attached to a
single user port, where application based authorization (based on
encryption/decryption) would be a better choice.

My answer to Mtthew's point in below mail below would be,

1. I don't see a need to specify any use case in the framework draft,
since this draft already talks about exchanging the subscriber related
information between Access Node and NAS for multicast purposes at high
level. It should be left to implementation how this information is used
in Access Node or how this information is exchanced with NAS.

2. Never the less, the protocol draft could include message type, format
and associated TLVs for exchanging the multicast related subscriber
information between the Access Node and NAS.

Comments are welcome.

Rgds,
Sathiya

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 7:19 PM
To: [email-masked]
Subject: [ANCP] Multicast in ANCP

I would like to start a discussion on what the working group would like
to do with Multicast in ANCP.

Currently the ANCP charter includes multicast as one of the use cases,
as
follows:

"When multicast replication for subscriber-bound traffic is performed at
the AN, it off-loads the network between the AN and NAS. However, a
subscriber's policy and configuration for multicast traffic may only be
known at the NAS. ANCP will provide a mechanism to communicate the
necessary information exchange between the AN and NAS so as to allow the
AN to perform subscriber bound multicast group replication in line with
the subscriber's policy and configuration, and also allow the NAS to
follow each subscriber's multicast group membership."

The framework draft (draft-ietf-ancp-framework-01.txt) says that the
access loop configuration mechanisms may be useful for setting the
per-Subscriber multicast channel entitlement information, used for IPTV
applications where the Access Node is performing IGMP snooping or IGMP
proxy function. It goes on to say that a Subscriber's policy and
configuration for multicast traffic might only be known at the NAS. The
Access Node Control Mechanism could be used to exchange the necessary
information between the Access Node and the NAS so as to allow the
Access Node to perform multicast replication in line with  the
Subscriber's policy and configuration, and also allow the NAS to follow
each Subscriber's multicast group membership.

None of these multicast mechanisms are defined in the ANCP protocol
draft, and I think there is insufficient detail in the framework draft
to fully specify this use case.

There has been very little work on this since the charter discussions,
but the ANCP working group needs to clarify what it wants to do (if
anything) with multicast for the framework can move forward. I think
there are two
choices: Either we should clarify the use case and specify the ANCP
protocol to support it, or we should remove the multicast use case from
the framework for now.

Please post your opinions to the list. We plan to have a discussion on
this in Prague, and to try to reach a consensus at around that time.

Best regards,

Matthew

---

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 7 Mar 2007 17:40:52 +0100

Hello,
	I have a different opinion on using ANCP for multicast traffic,
in particular I have in mind a couple of scenarios where ANCP could be
very useful to deal with multicast replication on Access Node.

1. What I think is currently missing is a standard authentication
mechanism that could be used by the Access Node to control the delivery
of the multicast traffic to the end user; in particular the capability
to associate a subscriber's multicast replication service profile with a
user session and a mechanism to provide conditional authorization for
multicast traffic. I don't think the mechanism used to exchange
authentication info related to channels white/black lists between Access
Node and NAS are implementation issues, IMHO this should be part of ANCP
job. 

2. An additional scenario where ANCP could be useful for multicast
traffic is for accounting purposes both time-based accounting and
prepaid accounting;   what I'm thinking is a mechanism to trigger
generation of accounting start and stop records based on multicast
replication.

3. A scenario where Dynamic Multicast replication stop is required; for
example if a user is currently watching a movie and the SP would like to
send him a sort of advertisement; a capability to stop the current
multicast replication on the Access Node is required.

4. Additional application could be a scenario where a network operator
would like to control bandwidth admission requests for a contended
shared unicast and multicast bandwidth pool on the access link .

These are just starting points but IMHO I think ANCP is valuable
protocol to be used to address these type of scenarios that's why I
think we should not remove Multicast section from ANCP charter, instead
we should try to start working more on this topic.

Best regards,
Roberta   

--------------------------------------------------------------------
Roberta Maglione
Telecom Italia - T.IE.AFT.BI
Broadband Network Service Innovation
Via G. Reiss Romoli 274
10148 Torino - Italy
Phone: +39 011 228 5007
e-mail: [email-masked]
-------------------------------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 2:49 PM
To: [email-masked]
Subject: [ANCP] Multicast in ANCP

to

AN

The framework draft (draft-ietf-ancp-framework-01.txt) says that the
access
loop configuration mechanisms may be useful for setting the
per-Subscriber
multicast channel entitlement information, used for IPTV applications
where
the Access Node is performing IGMP snooping or IGMP proxy function. It
goes
on to say that a Subscriber's policy and  configuration for multicast
traffic might only be known at the NAS. The Access Node Control
Mechanism
could be used to exchange the necessary information between the Access
Node
and the NAS so as to allow the Access Node to perform multicast
replication
in line with  the Subscriber's policy and configuration, and also allow
the
NAS to follow each Subscriber's multicast group membership.

draft,

but
the ANCP working group needs to clarify what it wants to do (if
anything)
the
framework for now.

this

Best regards,

Matthew

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "bharat_joshi" <[email-masked]>
Date: Wed, 7 Mar 2007 22:18:47 +0530

Hi Matthew,

    I have some suggestions. Please see in line.

Thanks & Regards,
Bharat

as
per-Subscriber
Mechanism
draft,
> and I think there is insufficient detail in the framework draft to
fully

Yes. I think we need to enhance the existing details to be more specific
on what kind of information we would want an NAS to be sending to AN.

I think there are two cases which we should consider:

* IGMP Snooping is not enabled in AN: In this case, Access Node does not
snoop IGMP packets and so it is NAS which verify the authorization of a
user if he can join a group and if it passes, NAS sends an ANCP message
to the AN and ask it to create a forwarding state for this group. Once
NAS receives a leave message, NAS sends another message to AN to remove
the forwarding state.

* IGMP Snooping is enabled in AN: In this case, Access node snoops IGMP
packet but does not have the subscriber related information to authorize
the user if it can join the group. So what we can do in this case is
that as soon as a line comes up, NAS can forward the subscriber related
information to AN using ANCP messages. AN can make use of this
information to create the forwarding state. AN removes the forwarding
state when it snoops a leave message.

I think we should consider both the cases above and defined ANCP
messages accordingly. In both the above cases, we would also need to
send following things defined:

* Till what time these entries are valid? Will there be a periodic
update?

but
anything)
> protocol to support it, or we should remove the multicast use case
from

I think we should keep it in the framework document and at least add the
possible scenarios where ANCP shall be used.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Mon, 12 Mar 2007 17:13:44 +0100

Hi All,

(chair hat off)

I propose that the ANCP multicast requirements should cover the
following 3 areas:

1. Dynamic configuration
There appears to be a need to be able to control the multicast
replication at the access-node in accordance with per user or per
circuit-id policies known at the controller, and do so in a dynamic vs a
one time provisioned manner. Currently operators do so by statically
configuring an ingress IGMP filtering ACL on a given circuit-id, which
is not amenable to dynamic changes. By dynamic changes it's meant that
they are ones that are quickly executed in response to other system
events, eg a subscriber session coming up/down, the expiration of a
quota or timer, or a policy trigger, or even operator command. 
ANCP would need to be able to install such ACLs through an efficient
transaction mechanism. Two forms of installation appear to be worthwhile
of consideration: 
i) overwrite - a complete ACL is applied in a transaction on a target
circuit-id
ii) add/remove - one or more entries are added/removed in a transaction
on a target circuit-id.

2. Reporting
Several service providers currently run operational procedures that rely
on an operator being able to issue/troubleshoot a subscriber's problems
from a BNG. Classic examples of these are ATM OAM, and ip ping tests,
with the ANCP OAM "use-case" being an extension there of. It appears to
be quite laborious, and often problematic due to the crossing of
organizational boundaries, to have the procedure performed at the
access-node. Troubleshooting of multicast delivery is as yet a bit of a
black art to many providers that are only begging to deploy access-nodes
capable of L2 multicast replication.
It would thus appear to be desirable, in order to aid operations in such
deployments, to introduce into ANCP a set of multicast reporting
commands, that would allow a BNG operator to gain knowledge of the per
circuit-id multicast replication state on the access-node. This would be
a simple query/response mechanism, communicating from the access-node to
the BNG the currently active multicast groups on a given target
(circuit-id) along with applicable counters (eg time/byte count).
 
3. Change of L2 forwarding
The current notions of multicast replication on a L2 element are limited
to the following two options: flood all multicast with IGMP snooping
disabled, or snoop IGMP and immediately replicate/stop-replicating
multicast.
It appears sensible to consider introducing a third notion that involves
ANCP, and provides a more granular per multicast group control approach
instead of the all or nothing options above. This would consist having a
list of specific groups for which the access node would not flood the
multicast traffic to a port, but neither would it do IGMP snooping,
rather it would pass IGMP transparently and commence or stop replication
when instructed via ANCP. 
Various optimizations can be introduced to this scheme, but the
principle remains the same; the L2 multicast replication mechanism, for
a given group or range, would be driven by ANCP signalling.
Depending on the deployment scenario, this would appear to be a good
tool to utilize when multicast authorization, accounting, or
asynchronous operator requests affecting multicast forwarding are
desired.

Regards,
Woj.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: 06 March 2007 14:49
To: [email-masked]
Subject: [ANCP] Multicast in ANCP

Best regards,

Matthew

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Mon, 12 Mar 2007 15:41:04 -0400

I would like to extend my support for all the three use cases. #1 and #3
have also been discussed and debated in DSL forum. One comment on #3 is
that we shouldn't define this case to preclude snooping on the
access-node, even when creation of replication state is being controlled
by NAS via ANCP. There could be varying degress of control exercised by
the NAS in manipulating the replication state on the access-node. 

-Sanjay

>From: Wojciech Dec (wdec) [mailto:[email-masked]]
>Sent: Monday, March 12, 2007 11:14 AM
>To: [email-masked]; [email-masked]
>Subject: RE: [ANCP] Multicast in ANCP
>
>
>Hi All,
>
>(chair hat off)
>

---

From: [email-masked]
Date: Tue, 13 Mar 2007 10:22:55 +0100

Currently the use of IGMP filtering mechanisms based on Access Control 
Lists are quite common. They allow control over the multicast 
replication process; the ACLs are provisioned via network management.

It could be desirable to extend this concept to allow for ACL 
installation/removal upon establishing or terminating a PPP/DHCP 
session. That would require a mechanism to bring down the ACLs from a 
RADIUS or DHCP server to the points of IGMP processing and multicast 
replication. When a NAS receives the ACLs via RADIUS or DHCP, ANCP could 
then be used for bringing the ACLs from the NAS to the Access Node.

I propose to scope the ANCP framework multicast requirements to cover 
the following:

- supporting on the Access Node an ACL indicating for a particular
access port which multicast groups/streams are allowed resp. not allowed
to be sent to that port;
- using ANCP for configuring these ACLs on the Access Node at PPP/DHCP 
session start/stop. The ACLs could be sent in RADIUS / DHCP / ANCP 
explicitly via new ACL attributes/options or implicitly using a pointer 
to a preprovisioned ACL profile on the Access Node (details to be 
discussed further on the list).

This lines up with the first area mentioned in Woj's email, i.e. 
"dynamic configuration". I am supportive of this.

In terms of using ANCP for multicast reporting, I would rather make use 
of the IGMP Query mechanism to determine replication state throughout 
the network.

I am not in favor of using ANCP for configuration of the layer 2 
replication state (be it for some or for all channels) in the 
access/aggregation network and disabling IGMP processing throughout the 
network for these channels.

Regards,
Sven

---

From: "Ashwin Shimoga" <[email-masked]>
Date: Tue, 13 Mar 2007 15:38:56 +0530

Hi,

  I have some general questions regarding ANCP framework for multicast
requirements.

1. Will the draft specify to what extent ACL will be supported in Access
Node? Or is it implementation dependent? 
2. Bringing ACLs downto Access Node involves keeping the whole path of
RADIUS->PPP/DHCP->ANCP on NAS->AN in sync. Will this increase the number
of message exchanges between different network elements or is there an
easier way to do this?
3. When a new user comes up can the Access node query NAS and pull ACL
related information? 

For Reporting purposes a simple request/reply mechanism from NAS to AN
based on circuit-id should do the job. A set of reporting commands is
not needed. The message format can be extended to contain TLV's for all
the reporting parameters.

The changes proposed by Wojciech for changes in L2 forwarding are more
suitable for IPTV requirements. They provide more granularity at AN
level to control multicast replication.

Thanks
Ashwin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Tuesday, March 13, 2007 2:53 PM
To: [email-masked]
Subject: Re: [ANCP] Multicast in ANCP

Regards,
Sven

as
access
per-Subscriber
where
goes
Mechanism
Node
replication
draft,
but
anything)
this

---

From: <[email-masked]>
Date: Tue, 13 Mar 2007 20:15:41 +0530

Hello all,

The proposed use cases look fine, some comments:

Use case 1 - dynamic configuration can include not only ACL
installation, but also pushing QoS policy configuration
for a channel and channel admission control bandwidth configuration to
the access node.

Use case 2 - Reporting can be extended to include the following:

i. With IGMP proxy on the access node, subscriber information can be
communicated to BNG.
Along with the time/counter information this can be used for accounting
per subscriber that is not
visible to BNG otherwise

ii. It can be used to synchronize multicast parameters between the
access node and BNG.
Any change in access node multicast parameter configuration through a
local management system
can be reported to BNG.

Use case 3 - L2 forwarding changes

It looks like this is within the scope of use case 1. Perhaps, a dynamic
policy update and configuration
is what is required.

A general comment:

It needs to be seen if there is a need to control the point of content
injection for subscribers dynamically through ANCP,
either to force or to fallback on.

Thanks,
Kirubaharan

-----Original Message-----
From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 1:11 AM
To: Wojciech Dec (wdec); [email-masked];
[email-masked]

-Sanjay

>this in Prague, and to try to reach a consensus at around that time.

[Ignore any disclaimer auto inserted]
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "Maglione Roberta" <[email-masked]>
Date: Tue, 13 Mar 2007 16:49:59 +0100

Hi All,
	I would like to support all three use cases proposed, because
they cover the 
main topics we are interesting in:
- the flexibility given by the capability to dynamically modify
configuration parameters based on external events such as session coming
up/down, the expiration of a quota or timer, or a policy trigger, or
even operator command;
- the service granularity related to the possibility to allow or deny
per user multicast replication;
- the possibility to perform multicast authorization and time/volume
based accounting.

Thanks,
Roberta
 
Broadband Network Services Innovation

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 3:46 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [ANCP] Multicast in ANCP

Hello all,

A general comment:

Thanks,
Kirubaharan

-----Original Message-----
From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 1:11 AM
To: Wojciech Dec (wdec); [email-masked];
[email-masked]

-Sanjay

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Voigt, Norbert" <[email-masked]>
Date: Wed, 14 Mar 2007 15:05:23 +0100

Hi all,

I fully support Sven's view saying there seems to be a need for
controling multicast content at the Access Node, i.e.:
1)For enabling multicast at AN ports, ACLs shall be provided per AN
port. The ACL shall contain multicast entitlement data in order to
provide dedicated IP multicast groups to the user.
I also support the idea to configure these ACLs by means of ANCP at
DHCP/PPPoE session start/stop.

2)Regarding the reporting function Wojciech proposed, I have
difficulties seeing the need for it. I would prefer the IGMP query
mechanism to gain knowledge of the per port multicast replication state
on the Access Node.

3)Regarding the use of ANCP for configuration of the L2 replication
state without IGMP procesing for some dedicated ports, I'm not very
supportive. I would like to see whether the intended use case could be
covered by the already mentioned ACLs to allow/disallow mc content to be
sent to that port.

Regards,
Norbert.

as
access
per-Subscriber
where
goes
Mechanism
Node
replication
draft,
but
anything)
this

---

From: "Haag, T" <[email-masked]>
Date: Wed, 14 Mar 2007 16:45:13 +0100

Hi all,

Thanks for pointing out several options dealing with ANCP and Multicast.

Some points are interesting raising new requirements, some points bringing up new concerns regarding interoperability AN/NAS, extending the existing charter by introducing new requirements which may have impact to already existing requirements and use cases. ANCP can do many things but the operational impact as well as impact on interaction between NAS and AN which is out of scope of a protocol specification but needs to be taken into account too.

Below I tried to summarize it step by step:

1.	I support option 1 enabling MC per AN port by configuring entitlement 	data of an AN in order control ACL in conjunction with session 	start/stop. I also support the idea to consider PPPoE as well as 	DHCP.

2.	I support also using the OAM feature as it is described now by using 	ANCP as trigger an report function between AN and NAS to enable 	OAM 	fault management between AN and CPE at  DSL line such as e.g. ATM 	F5 LB Port Status message or equivalent Ethernet feature. These 	functions are still used in a point to point manner checking a 	connection.

	I have some concerns and don't support the idea to mix the sense of 	these OAM features with Multicast OAM which is total different. 
	The difference is here to poll a state of a Multicast Point which is 	not any more an OAM feature enabling line testing towards the DSL CPE. 	This is a function which needs state awareness which is a new field 	which is not considered so far and has some drawbacks to already 	existing use cases. 

	So from my point of view it needs to be considered but goes beyond the 	charter and the use case Multicast itself.

3.	Using ANCP in a way to control Multicast per multicast group seems 	from a flexible service delivery standpoint as an option.
	But considering the impact which the dynamic interaction between AN 	and NAS will bring I have strong concerns regarding performance and 	timing issues with respect to channel change time if customer is 	zapping. Also in case of failure this scenario maintenance can not 	performed successfully. 

	Taking this into account I don't support option 3 which describes 	configuration of the L2 replication state without IGMP processing for 	some dedicated ports.

Regards
 
Thomas Haag

-----Ursprüngliche Nachricht-----
Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Montag, 12. März 2007 17:14
An: [email-masked]; [email-masked]
Betreff: RE: [ANCP] Multicast in ANCP

Hi All,

(chair hat off)

1. Dynamic configuration

2. Reporting

Regards,
Woj.

-----Original Message-----

Best regards,

Matthew

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 14 Mar 2007 18:09:56 +0100

Hi,

I would also like to extend my support for all the three use cases,
as I can see they will be very useful and I think they are well
covered with the existing charter.

I think #2 is very useful, and can not rely on IGMP Query as proposed
earlier, as in a access node with IGMP proxy, I can't see how the
IGMP Query will give you a "subscriber" or DSL home view of the replication.

And I agree with Sanjays comment that #3 that we shouldn't define this 
case to preclude snooping on the access-node, even when creation of 
replication state is being controlled by NAS via ANCP.

cheers,
Peter

> Sent: 12. marts 2007 17:14

---

From: "Curtis Sherbo" <[email-masked]>
Date: Wed, 14 Mar 2007 10:10:59 -0700

Greetings,

With respect to the multicast use case currently in the ANCP charter, I
support keeping it in scope, with clarifications, and specifying the ANCP
protocol to support it.

Here are my thoughts around several multicast problems that could be nicely
solved with a mechanism such as ANCP.

Multicast Replication
Today there are varying implementations of multicast replication in Access
Nodes, making it difficult for Service Providers to implement a uniform
model across the network.  Add to this the ability to uniformly enact policy
and/or accounting, and you have a very large problem that today would
require a complex OSS solution.  As already brought forward, it would be
simpler to utilize existing functions on the NAS for both policy and
accounting with enchantments that include the use of ANCP to signal L2
replication state on the AN.  Sheer volume of ANs to NASs deployed, make it
logical from a policy control perspective to centralize this function on the
NAS.  Enacting Policy on a large scale to varying AN types and vendors is a
daunting task.  I agree with an earlier statement that the potential
function of ANCP to signal L2 replication state should not preclude the use
of IGMP snooping.  I just think it would be a valuable option in moving the
functionality of the network beyond supporting basic broadcast television
support.

Fast Channel Change
Although not yet commonly discussed in current working groups, perhaps this
is an opportunity to discuss potential solutions.  Some known Middleware
implementations utilize a unicast stream at time of channel change, and
switch to the multicast stream at a secondary point in time.  This two part
channel change makes simple access lists and straight IGMP snooping a little
less useful.  Perhaps some opportunities for optimization would present
themselves if the decision making process was left up to the NAS.

Access Control (Simple Policy)
I think it is easily agreed that a basic form of Multicast (IGMP) Filtering
on an Access Node is a good idea.  The debatable point is whether these
lists are dynamic or not.  In the simplest case, dynamic means installed at
the start of a subscriber session.  In the more advanced case, dynamic would
mean some sort of real time function where the AN could query the real time
Authorization of a particular Multicast group.

Accounting
Use cases are starting to be discussed that would require accounting for
multicast traffic.  Since Accounting is typically performed on the NAS, with
existing systems setup to collect this info from the NAS, it only makes
sense to aggregate the records that account for the multicast traffic on the
NAS and utilize existing systems to collect this data.

Bandwidth Control
The NAS has the best view of available network resources in both an upstream
and downstream perspective.  A hot topic for discussion today is a bandwidth
admission function, that should account for both Multicast and Unicast
traffic.  Utilizing the NASs position in the network, and knowledge of
subscriber state, make this a logical point for providing feedback on
resources, as well as querying/signaling of downstream elements for the
purpose of optimizing available bandwidth.

I look forward to further discussion.

Regards,
Curtis Sherbo

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 5:49 AM
To: [email-masked]
Subject: [ANCP] Multicast in ANCP

"When multicast replication for subscriber-bound traffic is performed at the
AN, it off-loads the network between the AN and NAS. However, a subscriber's
policy and configuration for multicast traffic may only be known at the NAS.
ANCP will provide a mechanism to communicate the necessary information
exchange between the AN and NAS so as to allow the AN to perform subscriber
bound multicast group replication in line with the subscriber's policy and
configuration, and also allow the NAS to follow each subscriber's multicast
group membership."

There has been very little work on this since the charter discussions, but
the ANCP working group needs to clarify what it wants to do (if anything)
with multicast for the framework can move forward. I think there are two
choices: Either we should clarify the use case and specify the ANCP protocol
to support it, or we should remove the multicast use case from the framework
for now.

Best regards,

Matthew

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Wed, 14 Mar 2007 18:35:09 +0100

Hi Norbert, Sven

Could you elaborate how you see the IGMP query mechanism working instead
of the reporting feature proposed?

Regards,
Woj. 

-----Original Message-----
From: Voigt, Norbert [mailto:[email-masked]] 
Sent: 14 March 2007 15:05
To: [email-masked]
Subject: RE: [ANCP] Multicast in ANCP

Hi all,

Regards,
Norbert.

as
access
per-Subscriber
where
goes
Mechanism
Node
replication
draft,
but
anything)
this

---

From: [email-masked]
Date: Thu, 15 Mar 2007 10:07:49 +0100

Woj,

My comments on your 3 cases below:

1) dynamic configuration of ACLs: looks interesting

2) OAM: I have some doubts about it, although not a strong position. 
The question is on how far you want to go with the troubleshooting of 
the AN from the NAS.  There are so many things that can be done but 
where will it stop.

3) it looks like that this causes a lot of load on both the AN and the 
NAS.  Should we really consider this?

When looking to all the emails on this subject, I come to the conclusion 
that on the first case, there is a very good consensus.  For the other 2 
  cases more discussion is needed.  So it looks that this discussion is 
a good start for the multicast usecase and it looks that we can already 
make it more concrete in framework and protocol with on which there is 
already consensus and continue the discussion on the rest.

regards,
Stefaan

---

From: [email-masked]
Date: Thu, 15 Mar 2007 14:20:33 +0100

Woj,

I guess it is be sending a query to the host?  See section 4.1.12 of 
RFC3376.

regards,
Stefaan

Wojciech Dec (wdec) wrote:
>>I would like to start a discussion on what the working group would
> 
> like to
> 
>>"When multicast replication for subscriber-bound traffic is performed
> 
> at
> 
>>subscriber's policy and configuration for multicast traffic may only
> 
> be
> 
>>necessary information exchange between the AN and NAS so as to allow
> 
> the AN
> 
>>to perform subscriber bound multicast group replication in line with
> 
> the
> 
>>subscriber's policy and configuration, and also allow the NAS to
> 
> follow
> 
>>in line with  the Subscriber's policy and configuration, and also
> 
> allow the
> 
>>and I think there is insufficient detail in the framework draft to
> 
> fully
> 
>>specify this use case.
>>
>>with multicast for the framework can move forward. I think there are
> 
> two
> 
>>protocol to support it, or we should remove the multicast use case
> 
> from the
> 
>>framework for now.
>>

---

From: "Peter Arberg" <[email-masked]>
Date: Thu, 15 Mar 2007 15:09:51 +0100

So if you can be a little more specific, and explain how a 
query send to a host if the Access Node is running in a 
IGMP proxy model (or snooping with proxy reporting as it also
is called) will be able to inform what DSL line is receiving the
multicast group ?

In TR-101 the "snooping with proxy reporting" describe the IGMP
query as:
---
Report suppression: intercepts, absorbs and summarizes
IGMP reports coming from IGMP hosts. IGMP reports are
relayed upstream only when necessary, i.e. when the first user
joins a multicast group, and once only per multicast group in
response to an IGMP query.
---

So with IGMP Query if I understand the functionality will
only tell the NAS if the AN has joined the multicast group, it will
not be able to identify if a particular DSL line has joined the group.

thanks,
Peter

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 15. marts 2007 14:21
> To: Wojciech Dec (wdec)
> Cc: [email-masked]

---

From: "Moti Morgenstern" <[email-masked]>
Date: Thu, 15 Mar 2007 19:16:29 +0200

Hi all,

Having experience in managing multicast services in the AN I have the following thoughts regarding the 3 topics in Wojciech's mail:

1) Configuration
- NAS will (dynamically) configure the ACLs at the AN per each circuit-ID, based on any criteria it implements. 
- The ANCP could also be used to (dynamically) configure the maximum number of multicast channels and aggregate bandwidth allowed for each circuit-ID for multicast channels.

2) Reporting
- If IGMP snooping is being used at the AN then all accounting data (volume/time) may be known at the NAS.
- IGMP proxy is being used normally for flat-rate service.
- Hence, ANCP is not needed for reporting as IGMP itself has the right modes to help support multicast records at the NAS, if required. 

3) L2 Forwarding
- As already stated, the fastest response to zapping requests is by utilizing a set of dynamically updated ACLs residing at the AN, closer to the customer. 
- I share the concerns of Thomas Haag regarding performance and timing issues. It is obvious that the NAS-AN interface adds a delay to zapping time not to mention the fact that NAS will need to handle many more concurrent IGMP requests to be treated in real-time. If performed at the AN the IGMP join/leave requests load is distributed between all ANs.
- Finally, from a service reliability point-of-view, when the ANCP is not available for any reason the AN can still use the most updated ACLs it has and the service is unaffected.

Regards,
Moti Morgenstern

-----Original Message-----
From: Haag, T [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 5:45 PM
To: [email-masked]
Cc: Busser, M
Subject: AW: [ANCP] Multicast in ANCP

Hi all,

Regards
 
Thomas Haag

-----Ursprüngliche Nachricht-----
Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Montag, 12. März 2007 17:14
An: [email-masked]; [email-masked]
Betreff: RE: [ANCP] Multicast in ANCP

Hi All,

(chair hat off)

1. Dynamic configuration

2. Reporting

Regards,
Woj.

-----Original Message-----

Best regards,

Matthew

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Thu, 15 Mar 2007 14:33:51 -0400

Moti
  One of the motivation for NAS to control replication state on the AN is to subject it to admission control (based on multiple services being delivered to the same local-loop). The NAS needs per-subscriber IGMP visibility to do this. Once it gets this visibilty, per-subscriber accounting and dynamic management of QoS for the local-loop comes as a bonus. In this case IGMP state machine is running between RG and NAS. So, IGMP query is good enough to figure out the state on RG. 
However, the last point of replication in the network is the AN. I take use-case #2 as a means to help with troubleshooting when say an RG is not recieving a multicast stream. In this case the operator from the NAS can use ANCP to trigger AN to provide stats such as "dropped and forwarded multicast packets or bytes" per local-loop (ACI) or can trigger it to report the MAC based multicast filter entries for an access-loop. If we implement use-case #3, then I think #2 is a pre-requisite. I also think if we do use-case #3, then high-availability based on "ANCP graceful restart" is a pre-requisite for both AN and NAS. Without these two, we don't have a carrier-grade solution.

Regards
-Sanjay

>2) Reporting
>- If IGMP snooping is being used at the AN then all accounting 
>data (volume/time) may be known at the NAS.
>- Hence, ANCP is not needed for reporting as IGMP itself has 
>the right modes to help support multicast records at the NAS, 
>if required. 

>From: Moti Morgenstern [mailto:[email-masked]]
>Sent: Thursday, March 15, 2007 1:16 PM
>To: [email-masked]
>Having experience in managing multicast services in the AN I 
>have the following thoughts regarding the 3 topics in Wojciech's mail:
>
>1) Configuration
>- NAS will (dynamically) configure the ACLs at the AN per each 
>circuit-ID, based on any criteria it implements. 
>- The ANCP could also be used to (dynamically) configure the 
>maximum number of multicast channels and aggregate bandwidth 
>allowed for each circuit-ID for multicast channels.
>
>2) Reporting
>- If IGMP snooping is being used at the AN then all accounting 
>data (volume/time) may be known at the NAS.
>- Hence, ANCP is not needed for reporting as IGMP itself has 
>the right modes to help support multicast records at the NAS, 
>if required. 
>
>3) L2 Forwarding
>- As already stated, the fastest response to zapping requests 
>is by utilizing a set of dynamically updated ACLs residing at 
>the AN, closer to the customer. 
>- I share the concerns of Thomas Haag regarding performance 
>and timing issues. It is obvious that the NAS-AN interface 
>adds a delay to zapping time not to mention the fact that NAS 
>will need to handle many more concurrent IGMP requests to be 
>treated in real-time. If performed at the AN the IGMP 
>join/leave requests load is distributed between all ANs.
>- Finally, from a service reliability point-of-view, when the 
>ANCP is not available for any reason the AN can still use the 
>most updated ACLs it has and the service is unaffected.
>
>Regards,
>Moti Morgenstern
>
>Some points are interesting raising new requirements, some 
>points bringing up new concerns regarding interoperability 
>AN/NAS, extending the existing charter by introducing new 
>requirements which may have impact to already existing 
>requirements and use cases. ANCP can do many things but the 
>operational impact as well as impact on interaction between 
>NAS and AN which is out of scope of a protocol specification 
>but needs to be taken into account too.
>
>1.	I support option 1 enabling MC per AN port by 
>configuring entitlement 	data of an AN in order control 
>ACL in conjunction with session 	start/stop. I also 
>support the idea to consider PPPoE as well as 	DHCP.
>
>2.	I support also using the OAM feature as it is described 
>now by using 	ANCP as trigger an report function between AN 
>and NAS to enable 	OAM 	fault management between AN and 
>CPE at  DSL line such as e.g. ATM 	F5 LB Port Status 
>message or equivalent Ethernet feature. These 	functions are 
>still used in a point to point manner checking a 	connection.
>
>	I have some concerns and don't support the idea to mix 
>the sense of 	these OAM features with Multicast OAM which is 
>total different. 
>	The difference is here to poll a state of a Multicast 
>Point which is 	not any more an OAM feature enabling 
>line testing towards the DSL CPE. 	This is a function 
>which needs state awareness which is a new field 	which 
>is not considered so far and has some drawbacks to already 	
>existing use cases. 
>
>	So from my point of view it needs to be considered but 
>goes beyond the 	charter and the use case Multicast itself.
>
>3.	Using ANCP in a way to control Multicast per multicast 
>group seems 	from a flexible service delivery standpoint as 
>an option.
>	But considering the impact which the dynamic 
>interaction between AN 	and NAS will bring I have 
>strong concerns regarding performance and 	timing issues 
>with respect to channel change time if customer is 	
>zapping. Also in case of failure this scenario maintenance can 
>not 	performed successfully. 
>
>	Taking this into account I don't support option 3 which 
>describes 	configuration of the L2 replication state 
>without IGMP processing for 	some dedicated ports.
>
>Regards
> 
>Thomas Haag
> 
>

---

From: "pavan_kurapati" <[email-masked]>
Date: Fri, 16 Mar 2007 10:35:15 +0530

I support all the 3 cases raised by Woj. If Access node is using proxy mechanism then query  would not help. It works only in the case of transparent IGMP snooping mechanism.

Even if Access node is not aggregating the reports (as is the case with transparent snooping), some clients send reports with source IP address of 0.0.0.0. Though it is a rare scenario, it does occur and in such cases NAS cannot identify the subscriber properly through queries. The only way to get the information reliably is by using a separate mechanism through ANCP.

Another use case that I can think of is pushing multicast CAC information to the AN. This is the list of priority and non-priority channels with bandwidth information. This will help the Access node to maintain a list of system wide priority & non-priority channels with their corresponding bandwidths. If the allocated bandwidth for multicast is exhausted then access node can reject the subsequent Joins generated by subscribers.  Unlike other cases, this has to be pushed by NAS as soon as it detects the AN (i.e it is not done at subscriber level). If a particular channel's attribute is changed (i.e either priority or bandwidth is changed) then that change can be pushed by the NAS through ANCP message to the AN.

Thanks,
Pavan

-----Original Message-----
From: Peter Arberg [mailto:[email-masked]]
Sent: Thu 3/15/2007 7:39 PM
To: [email-masked]; 'Wojciech Dec (wdec)'
Cc: [email-masked]
Subject: RE: [ANCP] Multicast in ANCP

thanks,
Peter

---

From: [email-masked]
Date: Fri, 16 Mar 2007 12:22:47 +0100

Sanjay,

It looks you are proposing new functionality in ANCP for more detailed 
troubleshooting in the AN from the NAS, but then the question is where 
it stops, and it looks to me that such a detailed troubleshooting should 
be better done at the AN itself.  Look to the current OAM: there is just 
some indication of the state of the DSL line and nothing more and the 
detailed troubleshooting (spectrum analyis, ...) is to be done on the AN 
itself.  In fact, for multicast, I have done lots of troubleshooting in 
live networks and whatever you do in ANCP, the most important 
functionality such as protocol tracing, detailed error counters, ... 
will be very hard to support in ANCP.  The proposed extension by Woj on 
getting visibility on the multicast forwarding table in the AN, will not 
help a lot in futher isolating the problem.  If the entry is there or 
not, then the problem can be still anywhere in the network and up to the 
application layer.  And if the problem is in the AN (a bug, or whatever) 
the information given in ANCP could be faulty information.

regards,
Stefaan

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Fri, 16 Mar 2007 09:04:15 -0400

Stefaan
  Remote troubleshooting from NAS for basic fault isolation seems useful to me in case of multicast too. I am not sure why it is very hard (as you say) to get visibility via ANCP into some basic multicast data counters for a port, which an AN would normally maintain. And same with MAC level multicast entries. As currently defined ANCP OAM allows returning more than just state. 

Regards
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 7:23 AM
To: Sanjay Wadhwa
Cc: [email-masked]
Subject: Re: [ANCP] Multicast in ANCP

Sanjay,

regards,
Stefaan

---

From: [email-masked]
Date: Fri, 16 Mar 2007 14:55:19 +0100

Sanjay,

see inline...

Sanjay Wadhwa wrote:

> Stefaan
>   Remote troubleshooting from NAS for basic fault isolation seems useful to me in case of multicast too.

definitely troubleshooting is important, but the question is whether 
troubleshooting from the NAS via ANCP is the right way of doing this.

I like the current OAM in the draft because it can indicate whether the 
problem has to be further investigated on the AN/DSLAM or not, but can 
the same be achieved for multicast in a simply way such that the 
protocol does get "overspecified" with all kinds of counters and other 
information?  If yes, very good for me in that case but with exporting 
only some basic information, I am not sure that a big problem is solved 
which is worth having additional functionality in ANCP.

I am not sure why it is very hard (as you say) to get visibility via 
ANCP into some basic multicast data counters

basic counters are not difficult, see my email below.  Which information 
looks sufficient to you that can be retrieved in such a request/response 
mechanism?  Are the multicast entries on a particular line be sufficient?

regards,
Stefaan

  for a port, which an AN would normally maintain. And same with MAC 
level multicast entries. As currently defined ANCP OAM allows returning 
more than just state.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Fri, 16 Mar 2007 21:48:37 -0400

>information?  

Stefaan, I believe in case of multicast too, we can do enough to isolate a problem to AN, which then possibly serves as a trigger for further investigation on the AN (just like current OAM use-case in the draft).
AN can have smarts to look at it's raw stats or any local conditions and condense these into relevant notification back to the NAS when triggered OR where it makes sense, it can report raw stats (e.g. incoming/outgoing multicast packets/bytes, <per-stream, per-circuit>). We can figure this out better if don't summarily dismiss this use-case.

Regards
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 9:55 AM
To: Sanjay Wadhwa
Cc: [email-masked]
Subject: Re: [ANCP] Multicast in ANCP

Sanjay,

see inline...

regards,
Stefaan

---

From: "Michel Platnic" <[email-masked]>
Date: Mon, 19 Mar 2007 18:22:02 +0200

Hi All,
 
 The ANCP MIB Draft 'draft-decnodder-ancp-mib-an-01' defines that a
Partition ID can be associated to several session IDs. This allows an AN
to receive commands from several NAS. 
 
Question 1: How does the reporting from the AN to the NAS works? Shall
it send the results only to the requester (NAS which sent the command)
or to all NAS connected to the partition ID (depending on the session
negotiated capabilities with the NAS)?

In case several Partitions are used per AN a high number of Sessions can
potentially be terminated at the NAS. Allowing to associate one Session
ID to several Partitions may help reduce the number of Sessions. 
 
Question 2: The MIB defines that a Partition ID can be associated to
several Sessions IDs, should we, in addition to this, allow one Session
ID to be connected to several Partition IDs?
 
Regards,
Michel.

---

From: [email-masked]
Date: Mon, 19 Mar 2007 18:50:21 +0100

Hi Michel,

see inline...

> _Question 1:_ How does the reporting from the AN to the NAS works? Shall 

That's how I understand it.  The framework document says: "The Access 
Node SHOULD be able to work with redundant controllers."  How this works 
is not further specified but it looks to me that in this case, one 
partition can have multiple ANCP sessions.  When there are 2 sessions, 
then I would expect that they are treated independently from each other, 
i.e., what is send over one session is the same as if the other session 
was not there.  Previously, "functional partitioning" was also discussed 
on this mailing list a while ago, and in that case, you might have a NAS 
per capability, and hence a session per capability.

> _Question 2:_ The MIB defines that a Partition ID can be associated to 

I am all open for it but I am not sure if there is a good case where 1 
session need to control multiple partitions.  In fact, partioning is a 
quite hard separation of the access node and I am not sure if it is good 
that 2 partitions are sharing the same session.  Why would you make 2 
partitions in this case?  Would it not be better to make one partition 
of it?

As MIB impact, I see that in the configuration instead of 1 partition ID 
per session we need multiple partition IDs per session, meaning another 
table.  If there are good cases for it, it is ok for me.  Note that ANCP 
is based on GSMP, and also the ANCP MIB is (more or less) based on the 
GSMP MIB, and the current ANCP MIB has taken this from the GSMP MIB.

Thanks,

Stefaan

> Regards,
> Michel.
> 
>  
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Michel Platnic" <[email-masked]>
Date: Tue, 20 Mar 2007 15:31:50 +0200

Hi Stefaan,

About Question 1:
I also support your views regarding the overall mechanism. Tough, if we
agree that each session is autonomous, I am not sure that 'functional
partitioning' is a must anymore. If one NAS requests access attributes,
the AN sends results only to this NAS, if later on an other NAS
connected to the same partition via an other session sends the same
request, it may receive, in its turn, the requested attributes. There
might be some operational limitations for the configuration use-case,
but details for this use-case are not defined yet so its too early to
say.

About Question 2:
The main idea to have several partitions sharing the same session is on
one hand to reduce the number of sessions and on the other hand to allow
a separation between the different ISPs. Indeed, several ISPs might be
connected to one NAS but could use only one single session to address
the relevant partitions. Limitation: all ISPs using a single session
should support a common set of capabilities.
This proposal is only one of several other possible solutions to reduce
the number of sessions. It adds some level of complexity to the model
but seems a good comprise compared to other solutions such as an
aggregation switch ANCP proxy to implement same feature for example.

Regards,
Michel.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Monday, March 19, 2007 7:50 PM
To: Michel Platnic
Cc: [email-masked]
Subject: Re: [ANCP] ANCP MIB - Connection between Partition IDs and
Session IDs

Hi Michel,

see inline...

Thanks,

Stefaan

---

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 14 Mar 2007 16:21:52 -0500

I agree: We need all three cases.

The following is also a good set of problem definitions, which can be
solved by ANCP multicast extensions.

-----Original Message-----
From: Curtis Sherbo [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 12:11 PM
To: [email-masked]
Subject: RE: [ANCP] Multicast in ANCP

Greetings,

With respect to the multicast use case currently in the ANCP charter, I
support keeping it in scope, with clarifications, and specifying the
ANCP
protocol to support it.

Here are my thoughts around several multicast problems that could be
nicely
solved with a mechanism such as ANCP.

Multicast Replication
Today there are varying implementations of multicast replication in
Access
Nodes, making it difficult for Service Providers to implement a uniform
model across the network.  Add to this the ability to uniformly enact
policy
and/or accounting, and you have a very large problem that today would
require a complex OSS solution.  As already brought forward, it would be
simpler to utilize existing functions on the NAS for both policy and
accounting with enchantments that include the use of ANCP to signal L2
replication state on the AN.  Sheer volume of ANs to NASs deployed, make
it
logical from a policy control perspective to centralize this function on
the
NAS.  Enacting Policy on a large scale to varying AN types and vendors
is a
daunting task.  I agree with an earlier statement that the potential
function of ANCP to signal L2 replication state should not preclude the
use
of IGMP snooping.  I just think it would be a valuable option in moving
the
functionality of the network beyond supporting basic broadcast
television
support.

Fast Channel Change
Although not yet commonly discussed in current working groups, perhaps
this
is an opportunity to discuss potential solutions.  Some known Middleware
implementations utilize a unicast stream at time of channel change, and
switch to the multicast stream at a secondary point in time.  This two
part
channel change makes simple access lists and straight IGMP snooping a
little
less useful.  Perhaps some opportunities for optimization would present
themselves if the decision making process was left up to the NAS.

Access Control (Simple Policy)
I think it is easily agreed that a basic form of Multicast (IGMP)
Filtering
on an Access Node is a good idea.  The debatable point is whether these
lists are dynamic or not.  In the simplest case, dynamic means installed
at
the start of a subscriber session.  In the more advanced case, dynamic
would
mean some sort of real time function where the AN could query the real
time
Authorization of a particular Multicast group.

Accounting
Use cases are starting to be discussed that would require accounting for
multicast traffic.  Since Accounting is typically performed on the NAS,
with
existing systems setup to collect this info from the NAS, it only makes
sense to aggregate the records that account for the multicast traffic on
the
NAS and utilize existing systems to collect this data.

Bandwidth Control
The NAS has the best view of available network resources in both an
upstream
and downstream perspective.  A hot topic for discussion today is a
bandwidth
admission function, that should account for both Multicast and Unicast
traffic.  Utilizing the NASs position in the network, and knowledge of
subscriber state, make this a logical point for providing feedback on
resources, as well as querying/signaling of downstream elements for the
purpose of optimizing available bandwidth.

Regards,
Curtis Sherbo

-----Original Message-----

"When multicast replication for subscriber-bound traffic is performed at
the
AN, it off-loads the network between the AN and NAS. However, a
subscriber's
policy and configuration for multicast traffic may only be known at the
NAS.
ANCP will provide a mechanism to communicate the necessary information
exchange between the AN and NAS so as to allow the AN to perform
subscriber
bound multicast group replication in line with the subscriber's policy
and
configuration, and also allow the NAS to follow each subscriber's
multicast
group membership."

protocol
to support it, or we should remove the multicast use case from the
framework
for now.

Best regards,

Matthew

---

From: [email-masked]
Date: Mon, 26 Mar 2007 14:38:16 +0200

Hi Michel,

see inline...

> should support a common set of capabilities.

In this case I would suggest to group all DSL lines that belongs to the 
same NAS (though belonging to multiple ISPs) in one partition.  A 
partition more belongs to a session and not necessarily to an ISP.  A 
partition is meant to define the lines subject to a particular 
partition, so that's why I would think that an ANCP session should not 
handle multiple partitions.

regards,
Stefaan

>>Partition ID can be associated to several session IDs. This allows an
> 
> AN 
> 
>>_Question 1:_ How does the reporting from the AN to the NAS works?
> 
> Shall 
> 
>>In case several Partitions are used per AN a high number of Sessions
> 
> can 
> 
>>potentially be terminated at the NAS. Allowing to associate one
> 
> Session 
> 
>>several Sessions IDs, should we, in addition to this, allow one
> 
> Session 
>