From ancp-bounces@ietf.org Wed Jan 02 08:31:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA3hH-0007ta-Jx; Wed, 02 Jan 2008 08:31:51 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JA3hG-0007tU-BI for ancp-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 08:31:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA3hG-0007tM-1H for ancp@ietf.org; Wed, 02 Jan 2008 08:31:50 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA3h1-0001uh-BJ for ancp@ietf.org; Wed, 02 Jan 2008 08:31:50 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m02DTfE3025230 for ; Wed, 2 Jan 2008 14:29:41 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Jan 2008 14:31:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jan 2008 14:31:32 +0100 Message-ID: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vancouver minutes Thread-Index: AchNQ8mvJfCBpvp7TqWNIfIlzjjJqw== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 02 Jan 2008 13:31:33.0873 (UTC) FILETIME=[CAAFDE10:01C84D43] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8506cd99a2b34fd8177504aff14605e Subject: [ANCP] Vancouver minutes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0586197209==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0586197209== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84D43.CA49B0BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84D43.CA49B0BD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Please find attached the draft minutes from Vancouver. Please let me know if you have any comments by Friday 4th Jan. Many thanks to Curtis for taking the notes. Regards, Matthew Thursday, December 6th, 2007 - 13:00 - 15:00 ----------------------------------- CHAIRS: Wojciech Dec (Absent) & Matthew Bocci SCRIBE: Curtis Sherbo WG Status and Update - Chairs ------------------------------------- Milestones: Security threats review, only 4 of 5 responses received Sanjay Wadhwa: proposed delaying MIB last call since protocol work is ongoing, Matthew agreed Protocol draft: Chairs have asked a small design team to produce text for protocol extensions and/or modification of requirements of multicast control Ensure protocol meets the requirements/framework Implement comments for the list Target of march 08 Francois Le Faucheur: Agree with proposal, would like a couple of iterations of progress for comment. Agreed. Design team will produce iterations for review on WG list. Design team: Roberta Maglione, Stefaan De Cnodder, Sanjay Wadhwa, Philippe Champagne ANCP gaps from WT 147 liaison from DSLF: Topology Discovery -Access node uplink Access port configuration -Configuration of parameters beyond the dsl modem traint rate, eg. acls, vlan assignment, .1p mapping parameters, policer -Opening and closing of access loop Multicast -Assignment of multicast vlan -Periodic membership reporting Other gaps from wg alias Link bundling (Bonding) NAS MIB: Francois Le Faucher: Topology discovery link from the NAS, thinks it is important Stefaan de Cnodder: NAS MIB is planned, but further out Sanjay Wadhwa: Assignment of mcast vlan is important for wholesale Mark Townsley: 147 is a set of requirements from DSLF for L2CP. What is the opinion of the industry how to solve these problems? No answer. Stefaan de Cnodder: Link bundling question, link bonding on dsl line, added to protocol, but not yet in framework Mark Townsley: what do we do about gaps? Need these items formulated a bit better to understand them. Matthew noted what has been supported by attendees Mark Townsley: We should track these gaps, and not proceed until they are addressed. Action: take to list Matthew; additionally, some extensibility guidelines should also be laid down e.g. vendor specific code space Matthew, suggest design team tackle these and come up with a proposal Peter Arberg, vendor specific attribute capability, draft on the list after the meeting ANCP Framework and Requirements - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/html/draft-ietf-ancp-framework-04 -------------------------------------------------------- History: 04 is the latest version Version 3: multicast use case updated, bonding, notify NAS of access loop configuration change due to EMS. 04 changes: small terminology consistency change ("net data rate") New sections: Section 3 use case multicast Section 4 requirements, multicast security Definitions update in section 1.2 Reference architecture two new messages, admission requests and admission response Use case conditional acceess Admission control Accounting Termination Sanjay Wadhwa: Third option of admission control discussed on list, IGMP from routed gateway to NAS direct, NAS decide and asynchronous message to access node. Agreed should be included as third option Sanjay Wadhwa: Same comment for accounting Next steps - update based on comments Francois le Faucher: The max number of entries in list was put in doc prematurely, Sven sent to list, one comment, received. Should go to list for more support, minimum threshold,=20 Matthew doesn't want it removed, then discussed, want it discussed first, then decide what to do, Matthew will raise on list again.=20 Francois: Criteria to keep it in need to be more than "no one objects". If no one cares, then it should be off. Multicast Issues - Roberta Maglione (roberta.maglione@telecomitalia.it) http://tools.ietf.org/html/draft-ietf-ancp-framework-04 http://tools.ietf.org/wg/ancp/draft-maglione-ancp-mcast-00.txt -------------------------------------------------------------- Grey list and default behaviour Spontaneous admission response Grey list to reduce NAS load according to WG discussion in Chicago A grey list identifies the multicast flows for which the access node can join before queries for further authorization What does wg prefer for default behaviour for a join that does not match any list: deny, allow ? Operator can override with wildcard General case is where ANCP not used to convey join /leave Detailed changes title 3.4.4=20 Use case in 3.4.4 Add modifications related requirement in section 4.2 Accounting Enhance multicast accounting section NAS preference to time and /or volume accounting is needed For mcast flows controlled by NAS (GreyList) at time of message sent to an For mcast flows controlled by access node white list can convey NAS during white list provision phase information report message used by an to communicate accounting information to the NAS AN can consolidate multiple sets of accounting information inside a single ancp message to reduce the number of information report messages sent from the an to the NAS Detailed changed modify use case 3.4.3 add/modify requirements multicast reporting=20 add capability for NAS to query the an to obtain instantaneous report status relate to multicast flows currently replicated by the an such a reporting function could be useful for troubleshooting and monitoring purposes three different types of report-query port report query multicast flow report query an global report query detail replace 3.4.3 title add use case 3.4.3 requirement s4.2, 4.7.6 and 4.8.6 Stefaan de Cnodder, comment on default behavior, missing option accept on best effort basis Francois le Faucher: discussion started on list, more discussion to occur, assume that particular mcast, to that particular port ? to Stefaan Stefaan de Cnodder, don't do any BW admission control, queue in switch, just do best effort Francois le Faucher: question will you always send high priority before the best effort?=20 Stefaan: depends on the Marking Francois le Faucher, who is remarking Toerless: There is a difference between allow and best effort Stefaan de Cnodder: allowed if best effort, if there is enough BW, check if sub has subscription,=20 Francois : response to an for access control, based on bw, suspect that is not what Sven meant Stefaan, just want third option covered Peter color names confusing, support Stefaans proposal to be one list, change names to permit deny query Sanjay Wadhwa, nas send only whitelist, assume all the rest, traverse lists Peter, if keep as three lists, need priority of lists, should be one list with no priority,=20 Toerless, means ordered list, does this mean more than three lists Peter, not same thing, should be like an access list in a router, ordered list, first match behaviour Toerless, if separate lists, using priority is same behaviour, how much complexity should be allowed, should be three lists, for interop without differing definitions across vendors,=20 Peter, agree that if lists, need priority Sanjay Wadhwa, logical single list, an could do three best match lookups, another default action should be query nas Francois le faucher, comment on, keep definition as is in requirement doc, it is understood, protocol should define it, agreement and resolution in protocol document, wrt to default behaviour, default default, needs decision, directed towards Sanjay Wadhwa, query default. Agreement; there needs to be a default-default (when nothing is configured) and a configurable default. That latter can be allow/deny/query. Stefaan, comment on reporting, port report query, support, maybe not agree on all attributes, concern how many (timestamps) need to be tracked by an global reporting, too much information, might not fit in gsmp Toerless, how does report relate to graceful restart Stefaan, question for Toerless, does it mean the acls, align state of an with nas, not sure if this is good idea, needs to be examined in graceful restart Francois le Faucher, question, clear cases where nas has time based info, volume info, cases both, therefore maybe nas tell an do volume based acct or time based, question is that useful, or is easier for an to always maintain and report both? Stefaan, understand an sends start and stop to nas, Francois le Faucher, an give all info when queried Stefaan, an not counting packets, nas counts bytes, an tells nas to start counting Toerless, packet counting, no sync between forwarding and signalling, an already replicating before nas receives message, question of accuracy Stefaan, also unicast, sends sync rate, line down, packets lost, accounting already done on NAS, no different Toerless, are you saying it won't work well, but compatible with unicast Sanjay Wadhwa NAS might not be in data path Toerless, does dslf require AN to count packets, if an does, then why not mcast Stefaan, not sure, but believes motivation for ancp was to do it in a centralized way Francois le Faucher, current text does not reflect this behaviour; assumption is that AN can count packets. Matthew, discusion needed on list ANCP Access Node MIB - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/html/draft-ietf-ancp-mib-an-01 -------------------------------------------------------- 01 submitted in November 00 changes: partitioning, added a scalar to configure wherher partitions are used or not interface config table notifications, up and down notifications can be enabled/disabled per session modifiying attributes 01 session index=20 ip address=20 port number configuration possible ANCP Security Threats - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://tools.ietf.org/html/draft-ietf-ancp-security-threats-03 ----------------------------------------------------------------- WG LC in October Version 3 as a result Changes, editorial, acknowledgment, admin domain clarification, potential, attacks against ancp clarifing text, multicast use-case added, security requirements updated Matthew, last meeting, discussed waiting for framework to complete before sending security to iesg, send both together Hasanna, to keep alive, submit a new version,=20 Matthew, any more comments can be considered part of previous last call Mark Townsley: when do framework last call, redo last call on security ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 Discuss protocol draft updates and ANCP graceful restart. ---------------------------------------------------------- consistency with framework new section 2.1 on terminology net data rate used new multipair bonding text text for topology discovery extensions 5.4.2 clarified message format in line configuration extension, section 5.4.3 concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. Common notion is for BRAS to pass TLV transparently into Radius. Changes held back. Doesn't see issue as colliding values have been changed previously. access loop remote id and sub tlv access loop encapsulation suggest not deprecate these tlvs, keep them alive Peter, why did Woj want this deprecated, agrees that these shouldn't be deprecated.=20 Sanjay, reason was to depreciate to avoid overlap, but ROI is small in this case. graceful restart draft updated, support for multicast use cased agreed upon by the WG. Matthew, should graceful restart be a separate draft going forward, Sanjay agreed Matthew, graceful restart not on charter, need to add to milestones ------_=_NextPart_001_01C84D43.CA49B0BD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Vancouver minutes

Please find attached the draft = minutes from Vancouver.

Please let me know if you have = any comments by Friday 4th Jan.

Many thanks to Curtis for taking = the notes.

Regards,

Matthew


Thursday, December 6th, 2007 = – 13:00 – 15:00
-----------------------------------
CHAIRS: Wojciech Dec (Absent) = & Matthew Bocci
SCRIBE: Curtis Sherbo

WG Status and Update – = Chairs
-------------------------------------
Milestones:
Security threats review, only 4 = of 5 responses received
Sanjay Wadhwa: proposed delaying = MIB last call since protocol work is ongoing, Matthew agreed

Protocol draft:
Chairs have asked a small design = team to produce text for protocol extensions and/or modification of = requirements of multicast control

Ensure protocol meets the = requirements/framework
Implement comments for the = list
Target of march 08
Francois Le Faucheur: Agree with = proposal, would like a couple of iterations of progress for comment. = Agreed. Design team will produce iterations for review on WG = list.

Design team: Roberta Maglione, = Stefaan De Cnodder, Sanjay Wadhwa, Philippe Champagne

ANCP gaps from WT 147 liaison = from DSLF:

Topology Discovery
-Access node uplink
Access port configuration
-Configuration of parameters = beyond the dsl modem traint rate, eg. acls, vlan assignment, .1p mapping = parameters, policer

-Opening and closing of access = loop
Multicast
-Assignment of multicast = vlan
-Periodic membership = reporting
Other gaps from wg alias
Link bundling (Bonding)

NAS MIB:
Francois Le Faucher: Topology = discovery link from the NAS, thinks it is important
Stefaan de Cnodder: NAS MIB is = planned, but further out
Sanjay Wadhwa: Assignment of = mcast vlan is important for wholesale
Mark Townsley: 147 is a set of = requirements from DSLF for L2CP. What is the opinion of the industry how = to solve these problems? No answer.

Stefaan de Cnodder: Link bundling = question, link bonding on dsl line, added to protocol, but not yet in = framework
Mark Townsley: what do we do = about gaps? Need these items formulated a bit better to understand = them.
Matthew noted what has been = supported by attendees
Mark Townsley: We should track = these gaps, and not proceed until they are addressed.
Action: take to list
Matthew; additionally, some = extensibility guidelines should also be laid down
e.g. vendor specific code = space
Matthew, suggest design team = tackle these and come up with a proposal
Peter Arberg, vendor specific = attribute capability, draft on the list after the meeting

ANCP Framework and Requirements = – Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
--------------------------------------------------------
History: 04 is the latest = version
Version 3: multicast use case = updated, bonding, notify NAS of access loop configuration change due to = EMS.
04 changes: small terminology = consistency change ("net data rate")

New sections:
Section 3 use case = multicast
Section 4 requirements, = multicast security
Definitions update in section = 1.2
Reference architecture two new = messages, admission requests and admission response
Use case conditional = acceess
Admission control
Accounting
Termination
Sanjay Wadhwa: Third option of = admission control discussed on list, IGMP from routed gateway to NAS = direct, NAS decide and asynchronous message to access node. Agreed = should be included as third option

Sanjay Wadhwa: Same comment for = accounting
Next steps - update based on = comments
Francois le Faucher: The max = number of entries in list was put in doc prematurely, Sven sent to list, = one comment, received. Should go to list for more support, minimum = threshold,

Matthew doesn't want it removed, = then discussed, want it discussed first, then decide what to do,
Matthew will raise on list = again.
Francois:  Criteria to keep = it in need to be more than "no one objects". If no one cares, = then it should be off.

Multicast Issues - Roberta = Maglione (roberta.maglione@telecomitalia.it)
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
<= U>http://tools.ietf.org/wg/ancp/draft-maglione-ancp-mcast-00.txt
--------------------------------------------------------------
Grey list and default = behaviour
Spontaneous admission = response
Grey list to reduce NAS load = according to WG discussion in Chicago
A grey list identifies the = multicast flows for which the access node can join before queries for = further authorization
What does wg prefer for default = behaviour for a join that does not match any list: deny, allow ?
Operator can override with = wildcard
General case is where ANCP not = used to convey join /leave
Detailed changes title 3.4.4 =
Use case in 3.4.4
Add modifications related = requirement in section 4.2
Accounting
Enhance multicast accounting = section
NAS preference to time and /or = volume accounting is needed
For mcast flows controlled by = NAS (GreyList) at time of message sent to an
For mcast flows controlled by = access node white list can convey NAS during white list provision = phase
information report message used = by an to communicate accounting information to the NAS
AN can consolidate multiple sets = of accounting information inside a single ancp message to reduce the = number of information report messages sent from the an to the = NAS

Detailed changed modify use case = 3.4.3
add/modify requirements
multicast reporting
add capability for NAS to query = the an to obtain instantaneous report status relate to multicast flows = currently replicated by the an

such a reporting function could = be useful for troubleshooting and monitoring purposes
three different types of = report-query
port report query
multicast flow report = query
an global report query

detail replace 3.4.3 title
add use case 3.4.3
requirement s4.2, 4.7.6 and = 4.8.6

Stefaan de Cnodder, comment on = default behavior, missing option accept on best effort basis
Francois le Faucher: discussion = started on list, more discussion to occur, assume that particular mcast, = to that particular port ? to Stefaan

Stefaan de Cnodder, don't do any = BW admission control, queue in switch, just do best effort
Francois le Faucher: question = will you always send high priority before the best effort?
Stefaan: depends on the = Marking
Francois le Faucher, who is = remarking
Toerless: There is a difference = between allow and best effort
Stefaan de Cnodder: allowed if = best effort, if there is enough BW, check if sub has subscription, =
Francois : response to an for = access control, based on bw, suspect that is not what Sven meant
Stefaan, just want third option = covered
Peter  color names = confusing, support Stefaans proposal to be one list, change names to = permit deny query
Sanjay Wadhwa, nas send only = whitelist, assume all the rest, traverse lists
Peter, if keep as three lists, = need priority of lists, should be one list with no priority,
Toerless, means ordered list, = does this mean more than three lists
Peter, not same thing, should be = like an access list in a router, ordered list, first match = behaviour
Toerless, if separate lists, = using priority is same behaviour, how much complexity should be allowed, = should be three lists, for interop without differing definitions across = vendors,

Peter, agree that if lists, need = priority
Sanjay Wadhwa, logical single = list, an could do three best match lookups, another default action = should be query nas
Francois le faucher, comment on, = keep definition as is in requirement doc, it is understood, protocol = should define it, agreement and resolution in protocol = document,

wrt to default behaviour, default = default, needs decision, directed towards Sanjay Wadhwa, query default. = Agreement; there needs to be a default-default (when nothing is = configured) and a configurable default. That latter can be = allow/deny/query.

Stefaan, comment on reporting, = port report query, support, maybe not agree on all attributes, concern = how many (timestamps) need to be tracked by an global reporting, too = much information, might not fit in gsmp

Toerless, how does report relate = to graceful restart
Stefaan, question for Toerless, = does it mean the acls, align state of an with nas, not sure if this is = good idea, needs to be examined in graceful restart

Francois le Faucher, question, = clear cases where nas has time based info, volume info, cases both, = therefore maybe nas tell an do volume based acct or time based, question = is that useful, or is easier for an to always maintain and report = both?

Stefaan, understand an sends = start and stop to nas,
Francois le Faucher, an give all = info when queried
Stefaan, an not counting = packets, nas counts bytes, an tells nas to start counting
Toerless, packet counting, no = sync between forwarding and signalling, an already replicating before = nas receives message, question of accuracy

Stefaan, also unicast, sends sync = rate, line down, packets lost, accounting already done on NAS, no = different
Toerless, are you saying it = won't work well, but compatible with unicast
Sanjay Wadhwa NAS might not be = in data path
Toerless, does dslf require AN = to count packets, if an does, then why not mcast
Stefaan, not sure, but believes = motivation for ancp was to do it in a centralized way
Francois le Faucher, current = text does not reflect this behaviour; assumption is that AN can count = packets.
Matthew, discusion needed on = list

ANCP Access = Node MIB – Stefaan de Cnodder = (stefaan.de_cnodder@alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-mib-an-01
--------------------------------------------------------
01 = submitted in November
00 = changes:
partitioning, added a scalar to configure wherher partitions are = used or not
interface = config table
notifications, up and down notifications can be enabled/disabled = per session
modifiying = attributes
01 session = index
ip address =
port number = configuration possible

ANCP = Security Threats – Hassnaa Moustafa = (hassnaa.moustafa@orange-ftgroup.com)
<= SPAN LANG=3D"en-gb">http://tools.ietf.org/html/draft-ietf-ancp-security-threats-03
-----------------------------------------------------------------
WG LC in = October
Version 3 = as a result
Changes, = editorial, acknowledgment, admin domain clarification, potential, = attacks against ancp clarifing text, multicast use-case added, security = requirements updated

Matthew, = last meeting, discussed waiting for framework to complete before sending = security to iesg, send both together
Hasanna, to = keep alive, submit a new version,
Matthew, = any more comments can be considered part of previous last = call
Mark = Townsley: when do framework last call, redo last call on = security

ANCP = Protocol Draft – Sanjay Wadhwa (swadhwa@juniper.net)
http://tools.ietf.org/html/draft-ietf-ancp-protocol-01
Discuss = protocol draft updates and ANCP graceful restart.
----------------------------------------------------------
consistency = with framework
new section = 2.1 on terminology
net data = rate used
new = multipair bonding text
text for = topology discovery extensions 5.4.2
clarified = message format in line configuration extension, section = 5.4.3
concern = over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. Common = notion is for BRAS to pass TLV transparently into Radius. Changes held = back. Doesn't see issue as colliding values have been changed = previously.

access loop = remote id and sub tlv access loop encapsulation
suggest not = deprecate these tlvs, keep them alive
Peter, why = did Woj want this deprecated, agrees that these shouldn't be deprecated. =
Sanjay, = reason was to depreciate to avoid overlap, but ROI is small in this = case.
graceful = restart draft updated, support for multicast use cased agreed upon by = the WG.
Matthew, = should graceful restart be a separate draft going forward, Sanjay = agreed
Matthew, = graceful restart not on charter, need to add to milestones

------_=_NextPart_001_01C84D43.CA49B0BD-- --===============0586197209== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0586197209==-- From ancp-bounces@ietf.org Wed Jan 02 09:02:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA4B1-0001wD-V7; Wed, 02 Jan 2008 09:02:36 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JA4B1-0001w5-5H for ancp-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 09:02:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA4B0-0001vx-Rp for ancp@ietf.org; Wed, 02 Jan 2008 09:02:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA4Az-0002P2-AE for ancp@ietf.org; Wed, 02 Jan 2008 09:02:34 -0500 X-IronPort-AV: E=Sophos;i="4.24,234,1196636400"; d="scan'208,217";a="2030678" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jan 2008 15:02:25 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m02E2OZ1027323; Wed, 2 Jan 2008 15:02:24 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m02E2GBJ024394; Wed, 2 Jan 2008 14:02:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 15:01:27 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 15:01:27 +0100 In-Reply-To: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Vancouver minutes Date: Wed, 2 Jan 2008 15:01:26 +0100 To: "BOCCI Matthew" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 02 Jan 2008 14:01:27.0093 (UTC) FILETIME=[F7878650:01C84D47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3317; t=1199282544; x=1200146544; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Vancouver=20minutes |Sender:=20; bh=Pwp5WgBKluBnnYRGrQAYbXlO6CkViIvK3bOgCXn8nwg=; b=pXsMhh31wgWUhrksDfbCqO5Fyi+Gej1a+1plc2mSpS8+Q+9/68gA1dH1TM 03SsYpBIqzxxQt1EhxT23PwDtR7/A7XTDlumQJpSAYSSfcHZMKJvo5QYkKD9 UWjR+qwyVJ; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0232092760==" Errors-To: ancp-bounces@ietf.org --===============0232092760== Content-Type: multipart/alternative; boundary=Apple-Mail-7--215529130 --Apple-Mail-7--215529130 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Matthew, Small suggestions: Regarding: > Stefaan de Cnodder, don't do any BW admission control, queue in > switch, just do best effort > Francois le Faucher: question will you always send high priority > before the best effort? > Stefaan: depends on the Marking > Francois le Faucher, who is remarking > Toerless: There is a difference between allow and best effort > Stefaan de Cnodder: allowed if best effort, if there is enough BW, > check if sub has subscription, > Francois : response to an for access control, based on bw, suspect > that is not what Sven meant > Stefaan, just want third option covered > I think the conclusion was that the notion of "admit as best effort" was not well defined and was interpreted differently by different people. Hence, I believe the plan was to have this notion discussed on the list first (in particular to get from Sven a description of how he understood it in his proposal). Also please s/Le Faucher/Le Faucheur/ in a few places. Thanks Francois --Apple-Mail-7--215529130 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Hello Matthew,

Small = suggestions:

Regarding:

Stefaan de = Cnodder, don't do any BW admission control, queue in switch, just do = best effort
Francois le = Faucher: question will you always send high priority before the best = effort?
Stefaan: = depends on the Marking
Francois le Faucher, who is remarking
Toerless: There is a difference between allow and = best effort
Stefaan de = Cnodder: allowed if best effort, if there is enough BW, check if sub has = subscription,
Francois = : response to an for access control, based on bw, suspect that is not = what Sven meant
Stefaan, just want third option covered

I think the conclusion = was that the notion of "admit as best effort" was not well defined and = was interpreted differently by different people. Hence, I believe the = plan was to have this notion discussed on the list first (in particular = to get from Sven a description of how he understood it in his = proposal).


Also please s/Le = Faucher/Le Faucheur/ in a few places.

Thanks

Francois
= --Apple-Mail-7--215529130-- --===============0232092760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0232092760==-- From ancp-bounces@ietf.org Fri Jan 04 06:08:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAkQ0-0003Qh-Iu; Fri, 04 Jan 2008 06:08:52 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JAkPy-0003OO-H6 for ancp-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 06:08:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAkPy-0003My-5C for ancp@ietf.org; Fri, 04 Jan 2008 06:08:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAkPx-0006P9-F7 for ancp@ietf.org; Fri, 04 Jan 2008 06:08:50 -0500 X-IronPort-AV: E=Sophos;i="4.24,245,1196636400"; d="scan'208";a="2173650" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Jan 2008 12:08:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m04B8m8R010249; Fri, 4 Jan 2008 12:08:48 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m04B8mBF029977; Fri, 4 Jan 2008 11:08:48 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 12:08:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jan 2008 12:08:45 +0100 Message-ID: In-Reply-To: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Depreciation of TLVs ... again Thread-Index: AchNQ8mvJfCBpvp7TqWNIfIlzjjJqwBdhukQ References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 04 Jan 2008 11:08:48.0020 (UTC) FILETIME=[2DDDED40:01C84EC2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3900; t=1199444928; x=1200308928; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20Depreciation=20of=20TLVs=20...=20again |Sender:=20; bh=H8bPwjdJu9rlnglIDSAe3yWIgVxZuYFoyChY22A/UWo=; b=lBbdlJPVx2/1fQ3IOlUhV+Hk4pLBnyjeZ5qjF96b9Kfla29AeFfRAE6s86 AvvUmSLCnV1ppB4pkxnfUR74zBNXb2mGrFhFhiI4fIZTFKH8WqQvxrE6q14C mWmIXsQy5h; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: swadhwa@cisco.com Subject: [ANCP] Depreciation of TLVs ... again X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Folks, =20 the Vancouver meeting saw some renewed discussions regarding TLV changes.=20 For the record I will (once again) provide the reasons why this problem needs to be addressed (whether through depreciation or other means). The problem is likely to cause interoperability problems with any new ANCP implementations. The options as I see it are (if there are others, lets hear them): 1a. Do not depreciate TLVs, and assume that all implementations and users will follow the latest ANCP draft (i.e. assume that draft-l2cp problems never happened). 1b. Do not depreciate TLVs, but introduce a "known caveats" in the appendix of the protocol draft, describing the potential legacy implementation interoperability problem. 2. Depreciate TLVs. Now, given that option 2 appears to have just recently been presented with a reasonable argument against it (see Vancouver minutes below), I call for the WG to decide on 1a or 1b.=20 Some background: The problem was introduced in edits made between pre-ANCP WG drafts to draft-wadhwa-gsmp-l2control-configuration-00.=20 Version 00 of this draft dated August 2, 2005 saw the PORT-UP message TLV 0x02 assigned to "Access-Aggregation-Circuit-ID-Binary". The next version 01, dated September 2006, saw the same TLV assigned to "Access-Loop-Remote-Id". A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw it's meaning changed between drafts. The ANCP protocol draft is derived from the 01 version. It so happens however that most known implementations are based on the 00 draft, which presents an interoperability problem to anyone who implemented the 00 definition and those that implement the latest ANCP draft. Hacks aside, a long term fix needs to be devised.=20 NOTE: There is no known way to distinguish l2cp draft 00, 01 or ANCP draft speakers other than trough hacks, which current 00 implementations are known to have adopted as a "workaround" to *ONE* of the problem. Now the original proposal of a solution was drafted in http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and the WG provided no objections. Furthermore the topic was also discussed during IETF 69 back in March 2007 (minutes here: http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html). Again no objections were raised by any of the WG participants. Hence the decision to *depreciate* conflicting TLVs was previously made by the WG (and claims of this being otherwise are removed from the truth).=20 =20 ---snip--- =20 ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net)=20 http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 =20 Discuss protocol draft updates and ANCP graceful restart.=20 ----------------------------------------------------------=20 consistency with framework=20 new section 2.1 on terminology=20 net data rate used=20 new multipair bonding text=20 text for topology discovery extensions 5.4.2=20 clarified message format in line configuration extension, section 5.4.3=20 concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. Common notion is for BRAS to pass TLV transparently into Radius. Changes held back. Doesn't see issue as colliding values have been changed previously. access loop remote id and sub tlv access loop encapsulation=20 suggest not deprecate these tlvs, keep them alive=20 Peter, why did Woj want this deprecated, agrees that these shouldn't be deprecated.=20 Sanjay, reason was to depreciate to avoid overlap, but ROI is small in this case.=20 graceful restart draft updated, support for multicast use cased agreed upon by the WG.=20 Matthew, should graceful restart be a separate draft going forward, Sanjay agreed=20 Matthew, graceful restart not on charter, need to add to milestones=20 ---snip-- Regards, Woj. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jan 04 06:11:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAkSY-0004b8-4E; Fri, 04 Jan 2008 06:11:30 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JAkSX-0004aJ-1d for ancp-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 06:11:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAkSW-0004YX-Jt for ancp@ietf.org; Fri, 04 Jan 2008 06:11:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAkSV-0006Un-TT for ancp@ietf.org; Fri, 04 Jan 2008 06:11:28 -0500 X-IronPort-AV: E=Sophos;i="4.24,245,1196636400"; d="scan'208";a="2173898" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Jan 2008 12:11:27 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m04BBRLG018540; Fri, 4 Jan 2008 12:11:27 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m04BBJBF000897; Fri, 4 Jan 2008 11:11:19 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 12:11:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jan 2008 12:10:59 +0100 Message-ID: In-Reply-To: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Depreciation of TLVs ... again Thread-Index: AchNQ8mvJfCBpvp7TqWNIfIlzjjJqwBdhukQ References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 04 Jan 2008 11:11:08.0296 (UTC) FILETIME=[817A5880:01C84EC2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3900; t=1199445087; x=1200309087; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20Depreciation=20of=20TLVs=20...=20again |Sender:=20; bh=H8bPwjdJu9rlnglIDSAe3yWIgVxZuYFoyChY22A/UWo=; b=k/9NPMZIrUPLOY2RwQaDEI/nS4StdikvEdi0EKMBo2HIy09MaHCEkpZc6f eMoUlnhv1c8+942aVAkePrHY0U/IGvk1h7dC0XGSOP2ZtLr+7Zh8qx28w4jE EVTIg7Lk20; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [ANCP] Depreciation of TLVs ... again X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Folks, =20 the Vancouver meeting saw some renewed discussions regarding TLV changes.=20 For the record I will (once again) provide the reasons why this problem needs to be addressed (whether through depreciation or other means). The problem is likely to cause interoperability problems with any new ANCP implementations. The options as I see it are (if there are others, lets hear them): 1a. Do not depreciate TLVs, and assume that all implementations and users will follow the latest ANCP draft (i.e. assume that draft-l2cp problems never happened). 1b. Do not depreciate TLVs, but introduce a "known caveats" in the appendix of the protocol draft, describing the potential legacy implementation interoperability problem. 2. Depreciate TLVs. Now, given that option 2 appears to have just recently been presented with a reasonable argument against it (see Vancouver minutes below), I call for the WG to decide on 1a or 1b.=20 Some background: The problem was introduced in edits made between pre-ANCP WG drafts to draft-wadhwa-gsmp-l2control-configuration-00.=20 Version 00 of this draft dated August 2, 2005 saw the PORT-UP message TLV 0x02 assigned to "Access-Aggregation-Circuit-ID-Binary". The next version 01, dated September 2006, saw the same TLV assigned to "Access-Loop-Remote-Id". A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw it's meaning changed between drafts. The ANCP protocol draft is derived from the 01 version. It so happens however that most known implementations are based on the 00 draft, which presents an interoperability problem to anyone who implemented the 00 definition and those that implement the latest ANCP draft. Hacks aside, a long term fix needs to be devised.=20 NOTE: There is no known way to distinguish l2cp draft 00, 01 or ANCP draft speakers other than trough hacks, which current 00 implementations are known to have adopted as a "workaround" to *ONE* of the problem. Now the original proposal of a solution was drafted in http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and the WG provided no objections. Furthermore the topic was also discussed during IETF 69 back in March 2007 (minutes here: http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html). Again no objections were raised by any of the WG participants. Hence the decision to *depreciate* conflicting TLVs was previously made by the WG (and claims of this being otherwise are removed from the truth).=20 =20 ---snip--- =20 ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net)=20 http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 =20 Discuss protocol draft updates and ANCP graceful restart.=20 ----------------------------------------------------------=20 consistency with framework=20 new section 2.1 on terminology=20 net data rate used=20 new multipair bonding text=20 text for topology discovery extensions 5.4.2=20 clarified message format in line configuration extension, section 5.4.3=20 concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. Common notion is for BRAS to pass TLV transparently into Radius. Changes held back. Doesn't see issue as colliding values have been changed previously. access loop remote id and sub tlv access loop encapsulation=20 suggest not deprecate these tlvs, keep them alive=20 Peter, why did Woj want this deprecated, agrees that these shouldn't be deprecated.=20 Sanjay, reason was to depreciate to avoid overlap, but ROI is small in this case.=20 graceful restart draft updated, support for multicast use cased agreed upon by the WG.=20 Matthew, should graceful restart be a separate draft going forward, Sanjay agreed=20 Matthew, graceful restart not on charter, need to add to milestones=20 ---snip-- Regards, Woj. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 07 09:06:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBscz-0007JP-AZ; Mon, 07 Jan 2008 09:06:57 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JBscy-0007JJ-A9 for ancp-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 09:06:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBscx-0007JB-Sj for ancp@ietf.org; Mon, 07 Jan 2008 09:06:56 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBscw-0008EF-WE for ancp@ietf.org; Mon, 07 Jan 2008 09:06:55 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m07E2A9u028748; Mon, 7 Jan 2008 15:02:10 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Jan 2008 15:06:50 +0100 Message-ID: <478231F9.9010305@alcatel-lucent.be> Date: Mon, 07 Jan 2008 15:06:49 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Depreciation of TLVs ... again References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2008 14:06:50.0742 (UTC) FILETIME=[8C813160:01C85136] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org > > 1a. Do not depreciate TLVs, and assume that all implementations and > users will follow the latest ANCP draft (i.e. assume that draft-l2cp > problems never happened). You cannot assume that. > 1b. Do not depreciate TLVs, but introduce a "known caveats" in the > appendix of the protocol draft, describing the potential legacy > implementation interoperability problem. Important changes that may lead to interop issues when implementations implement different versions of the same draft should be documented properly in the appendix. But this should be avoided as much as possible... Maybe it should be looked at case by case. If a number changes of a TLV that is not important, then it will not harm a lot, but if it happens to important TLVs like the ones carrying bandwidth or ACIs, then it should be avoided and if not possible to avoid, describe it very well in the appendix. regards, Stefaan > 2. Depreciate TLVs. > > Now, given that option 2 appears to have just recently been presented > with a reasonable argument against it (see Vancouver minutes below), I > call for the WG to decide on 1a or 1b. > > Some background: > > The problem was introduced in edits made between pre-ANCP WG drafts to > draft-wadhwa-gsmp-l2control-configuration-00. > Version 00 of this draft dated August 2, 2005 saw the PORT-UP message > TLV 0x02 assigned to "Access-Aggregation-Circuit-ID-Binary". The next > version 01, dated September 2006, saw the same TLV assigned to > "Access-Loop-Remote-Id". > A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw it's > meaning changed between drafts. The ANCP protocol draft is derived from > the 01 version. > > It so happens however that most known implementations are based on the > 00 draft, which presents an interoperability problem to anyone who > implemented the 00 definition and those that implement the latest ANCP > draft. Hacks aside, a long term fix needs to be devised. > NOTE: There is no known way to distinguish l2cp draft 00, 01 or ANCP > draft speakers other than trough hacks, which current 00 implementations > are known to have adopted as a "workaround" to *ONE* of the problem. > > Now the original proposal of a solution was drafted in > http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and the > WG provided no objections. Furthermore the topic was also discussed > during IETF 69 back in March 2007 (minutes here: > http://tools.ietf.org/wg/ancp/minutes?item=minutes68.html). Again no > objections were raised by any of the WG participants. > Hence the decision to *depreciate* conflicting TLVs was previously made > by the WG (and claims of this being otherwise are removed from the > truth). > > > ---snip--- > > ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) > http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 > > Discuss protocol draft updates and ANCP graceful restart. > ---------------------------------------------------------- > consistency with framework > new section 2.1 on terminology > net data rate used > new multipair bonding text > text for topology discovery extensions 5.4.2 > clarified message format in line configuration extension, section 5.4.3 > concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. > Common notion is for BRAS to pass TLV transparently into Radius. Changes > held back. Doesn't see issue as colliding values have been changed > previously. > > access loop remote id and sub tlv access loop encapsulation > suggest not deprecate these tlvs, keep them alive > Peter, why did Woj want this deprecated, agrees that these > shouldn't be deprecated. > Sanjay, reason was to depreciate to avoid overlap, but ROI is > small in this case. > graceful restart draft updated, support for multicast use cased > agreed upon by the WG. > Matthew, should graceful restart be a separate draft going > forward, Sanjay agreed > Matthew, graceful restart not on charter, need to add to > milestones > > ---snip-- > > Regards, > Woj. > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 07 09:18:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBsnv-0002UU-IN; Mon, 07 Jan 2008 09:18:15 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JBsnt-0002Qq-Ne for ancp-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 09:18:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBsnt-0002QT-BT for ancp@ietf.org; Mon, 07 Jan 2008 09:18:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBsns-00005w-DP for ancp@ietf.org; Mon, 07 Jan 2008 09:18:13 -0500 X-IronPort-AV: E=Sophos;i="4.24,253,1196636400"; d="scan'208";a="2335408" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2008 15:18:11 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m07EIBVp021165; Mon, 7 Jan 2008 15:18:11 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m07EIBBF007175; Mon, 7 Jan 2008 14:18:11 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 15:18:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Depreciation of TLVs ... again Date: Mon, 7 Jan 2008 15:18:06 +0100 Message-ID: In-Reply-To: <478231F9.9010305@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Depreciation of TLVs ... again Thread-Index: AchRNpRSu5kyJj4BTGGZYwQIX/0FcwAAIjdg References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <478231F9.9010305@alcatel-lucent.be> From: "Wojciech Dec (wdec)" To: "Stefaan DE CNODDER" X-OriginalArrivalTime: 07 Jan 2008 14:18:11.0400 (UTC) FILETIME=[22355C80:01C85138] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5377; t=1199715491; x=1200579491; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Depreciation=20of=20TLVs=20... =20again |Sender:=20; bh=bKHQicOaL5ZxWphQ6jsiH3PaGdz43/hBSZu1gUOxLUA=; b=dJI2HK1OdwBqC/ef+OG+cvhl+H83OHIqLFdEiI/xl5mF2C9pZ3RVl1T0UU m5KSROo5ypia+Ve541VYdhXclGB+Quan0gXq6OHBoD1XuYZwM7PxPNxZ2z3p 2WvzKKr2wO; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Stefaan, are you behind option 1b then? The case if currently for : PORT-UP message TLV Type 0x02 PORT-UP message TLV 0x04 sub-TLV 0x90 Both of which I beleive are currenly implemented (based on the conflicting definition in draft-wadhwa-00). BTW. I naturally meant depricate not depreciate ;-) -Woj. =20 > -----Original Message----- > From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: 07 January 2008 15:07 > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Depreciation of TLVs ... again >=20 >=20 >=20 > >=20 > > 1a. Do not depreciate TLVs, and assume that all implementations and=20 > > users will follow the latest ANCP draft (i.e. assume that=20 > draft-l2cp=20 > > problems never happened). >=20 > You cannot assume that. >=20 > > 1b. Do not depreciate TLVs, but introduce a "known caveats" in the=20 > > appendix of the protocol draft, describing the potential legacy=20 > > implementation interoperability problem. >=20 > Important changes that may lead to interop issues when=20 > implementations implement different versions of the same=20 > draft should be documented properly in the appendix. But=20 > this should be avoided as much as possible... Maybe it=20 > should be looked at case by case. If a number changes of a=20 > TLV that is not important, then it will not harm a lot, but=20 > if it happens to important TLVs like the ones carrying=20 > bandwidth or ACIs, then it should be avoided and if not=20 > possible to avoid, describe it very well in the appendix. >=20 > regards, > Stefaan >=20 >=20 > > 2. Depreciate TLVs. > >=20 > > Now, given that option 2 appears to have just recently been=20 > presented=20 > > with a reasonable argument against it (see Vancouver=20 > minutes below), I=20 > > call for the WG to decide on 1a or 1b. > >=20 > > Some background: > >=20 > > The problem was introduced in edits made between pre-ANCP=20 > WG drafts to=20 > > draft-wadhwa-gsmp-l2control-configuration-00. > > Version 00 of this draft dated August 2, 2005 saw the=20 > PORT-UP message=20 > > TLV 0x02 assigned to=20 > "Access-Aggregation-Circuit-ID-Binary". The next=20 > > version 01, dated September 2006, saw the same TLV assigned to=20 > > "Access-Loop-Remote-Id". > > A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw=20 > > it's meaning changed between drafts. The ANCP protocol draft is=20 > > derived from the 01 version. > >=20 > > It so happens however that most known implementations are=20 > based on the=20 > > 00 draft, which presents an interoperability problem to anyone who=20 > > implemented the 00 definition and those that implement the=20 > latest ANCP=20 > > draft. Hacks aside, a long term fix needs to be devised. > > NOTE: There is no known way to distinguish l2cp draft 00,=20 > 01 or ANCP=20 > > draft speakers other than trough hacks, which current 00=20 > > implementations are known to have adopted as a "workaround"=20 > to *ONE* of the problem. > >=20 > > Now the original proposal of a solution was drafted in=20 > >=20 > http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and=20 > > the WG provided no objections. Furthermore the topic was also=20 > > discussed during IETF 69 back in March 2007 (minutes here: > > http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html).=20 > Again no=20 > > objections were raised by any of the WG participants. > > Hence the decision to *depreciate* conflicting TLVs was previously=20 > > made by the WG (and claims of this being otherwise are removed from=20 > > the truth). > >=20 > > =20 > > ---snip--- > > =20 > > ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) > > http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 > > > > Discuss protocol draft updates and ANCP graceful restart.=20 > > ---------------------------------------------------------- > > consistency with framework > > new section 2.1 on terminology > > net data rate used > > new multipair bonding text > > text for topology discovery extensions 5.4.2 clarified=20 > message format=20 > > in line configuration extension, section 5.4.3 concern over tlv=20 > > changes, diverges from tr-101 and rfc 4679 in TLV#. > > Common notion is for BRAS to pass TLV transparently into Radius.=20 > > Changes held back. Doesn't see issue as colliding values have been=20 > > changed previously. > >=20 > > access loop remote id and sub tlv access loop encapsulation=20 > > suggest not deprecate these tlvs, keep them alive=20 > > Peter, why did Woj want this deprecated, agrees that=20 > these shouldn't=20 > > be deprecated. > > Sanjay, reason was to depreciate to avoid overlap, but=20 > ROI is small=20 > > in this case. > > graceful restart draft updated, support for multicast use cased=20 > > agreed upon by the WG. > > Matthew, should graceful restart be a separate draft=20 > going forward,=20 > > Sanjay agreed > > Matthew, graceful restart not on charter, need to add=20 > to milestones > >=20 > > ---snip-- > >=20 > > Regards, > > Woj. > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 07 09:50:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtIw-0005cs-FM; Mon, 07 Jan 2008 09:50:18 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JBtIv-0005TY-Fg for ancp-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 09:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtIv-0005Qp-4S for ancp@ietf.org; Mon, 07 Jan 2008 09:50:17 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtIt-0007JC-1V for ancp@ietf.org; Mon, 07 Jan 2008 09:50:17 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m07Elomu007696; Mon, 7 Jan 2008 15:47:50 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Jan 2008 15:49:46 +0100 Message-ID: <47823C09.4060709@alcatel-lucent.be> Date: Mon, 07 Jan 2008 15:49:45 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Depreciation of TLVs ... again References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <478231F9.9010305@alcatel-lucent.be> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2008 14:49:46.0307 (UTC) FILETIME=[8BA93930:01C8513C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Woj, Let's say that I am against 1a. It also requires that all ANs and all NASes are upgraded at the same time which is unlikely. It depends on which node is typically upgraded first. Are ISPs first upgrading the NAS or first the AN? I would expect first the NAS. If that's true, then it looks to me that it should be like this: If I see correctly "PORT-UP message TLV Type 0x02" changed meaning and the original data that was in TLV 0x02 is now in 0x06. However, this is an optional TLV and does not look that important, and to avoid interop problems, a NAS should not interprete TLV 0x02 "for some time", except in displaying this information or other things that does not break the correct operation of ANCP. This until we are sure that there are no implementations that use the old spec. This should be described in an appendix of the draft. subTLV 0x90 is renumbered to 0x91. Here the BRAS should, to avoid interop problems, interprete both 0x90 and 0x91 in the same way. If both are there, then only 0x91 should be interpreted. Also this should be described clearly in the appendix. In the future it would be better that the numbering is kept as it is. For instance, for TLV 0x02 it should never have been moved to 0x06 and then using 0x02 for something else... This could have been avoided, but if it cannot be avoided, then it should be described explicetely in the appendix. regards, Stefaan Wojciech Dec (wdec) wrote: > Stefaan, are you behind option 1b then? > > The case if currently for : > > PORT-UP message TLV Type 0x02 > PORT-UP message TLV 0x04 sub-TLV 0x90 > > Both of which I beleive are currenly implemented (based on the > conflicting definition in draft-wadhwa-00). > > BTW. I naturally meant depricate not depreciate ;-) > > -Woj. > > > >>-----Original Message----- >>From: Stefaan DE CNODDER >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Sent: 07 January 2008 15:07 >>To: Wojciech Dec (wdec) >>Cc: ancp@ietf.org >>Subject: Re: [ANCP] Depreciation of TLVs ... again >> >> >> >> >>>1a. Do not depreciate TLVs, and assume that all implementations and >>>users will follow the latest ANCP draft (i.e. assume that >> >>draft-l2cp >> >>>problems never happened). >> >>You cannot assume that. >> >> >>>1b. Do not depreciate TLVs, but introduce a "known caveats" in the >>>appendix of the protocol draft, describing the potential legacy >>>implementation interoperability problem. >> >>Important changes that may lead to interop issues when >>implementations implement different versions of the same >>draft should be documented properly in the appendix. But >>this should be avoided as much as possible... Maybe it >>should be looked at case by case. If a number changes of a >>TLV that is not important, then it will not harm a lot, but >>if it happens to important TLVs like the ones carrying >>bandwidth or ACIs, then it should be avoided and if not >>possible to avoid, describe it very well in the appendix. >> >>regards, >>Stefaan >> >> >> >>>2. Depreciate TLVs. >>> >>>Now, given that option 2 appears to have just recently been >> >>presented >> >>>with a reasonable argument against it (see Vancouver >> >>minutes below), I >> >>>call for the WG to decide on 1a or 1b. >>> >>>Some background: >>> >>>The problem was introduced in edits made between pre-ANCP >> >>WG drafts to >> >>>draft-wadhwa-gsmp-l2control-configuration-00. >>>Version 00 of this draft dated August 2, 2005 saw the >> >>PORT-UP message >> >>>TLV 0x02 assigned to >> >>"Access-Aggregation-Circuit-ID-Binary". The next >> >>>version 01, dated September 2006, saw the same TLV assigned to >>>"Access-Loop-Remote-Id". >>>A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw >>>it's meaning changed between drafts. The ANCP protocol draft is >>>derived from the 01 version. >>> >>>It so happens however that most known implementations are >> >>based on the >> >>>00 draft, which presents an interoperability problem to anyone who >>>implemented the 00 definition and those that implement the >> >>latest ANCP >> >>>draft. Hacks aside, a long term fix needs to be devised. >>>NOTE: There is no known way to distinguish l2cp draft 00, >> >>01 or ANCP >> >>>draft speakers other than trough hacks, which current 00 >>>implementations are known to have adopted as a "workaround" >> >>to *ONE* of the problem. >> >>>Now the original proposal of a solution was drafted in >>> >> >>http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and >> >>>the WG provided no objections. Furthermore the topic was also >>>discussed during IETF 69 back in March 2007 (minutes here: >>>http://tools.ietf.org/wg/ancp/minutes?item=minutes68.html). >> >>Again no >> >>>objections were raised by any of the WG participants. >>>Hence the decision to *depreciate* conflicting TLVs was previously >>>made by the WG (and claims of this being otherwise are removed from >>>the truth). >>> >>> >>>---snip--- >>> >>> ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) >>>http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 >>> >>>Discuss protocol draft updates and ANCP graceful restart. >>>---------------------------------------------------------- >>>consistency with framework >>>new section 2.1 on terminology >>>net data rate used >>>new multipair bonding text >>>text for topology discovery extensions 5.4.2 clarified >> >>message format >> >>>in line configuration extension, section 5.4.3 concern over tlv >>>changes, diverges from tr-101 and rfc 4679 in TLV#. >>>Common notion is for BRAS to pass TLV transparently into Radius. >>>Changes held back. Doesn't see issue as colliding values have been >>>changed previously. >>> >>> access loop remote id and sub tlv access loop encapsulation >>> suggest not deprecate these tlvs, keep them alive >>> Peter, why did Woj want this deprecated, agrees that >> >>these shouldn't >> >>>be deprecated. >>> Sanjay, reason was to depreciate to avoid overlap, but >> >>ROI is small >> >>>in this case. >>> graceful restart draft updated, support for multicast use cased >>>agreed upon by the WG. >>> Matthew, should graceful restart be a separate draft >> >>going forward, >> >>>Sanjay agreed >>> Matthew, graceful restart not on charter, need to add >> >>to milestones >> >>>---snip-- >>> >>>Regards, >>>Woj. >>> >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ancp >> > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 07 17:32:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0Vt-00031Z-FO; Mon, 07 Jan 2008 17:32:09 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JC0Vt-00031T-04 for ancp-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:32:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0Vs-0002za-LN for ancp@ietf.org; Mon, 07 Jan 2008 17:32:08 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0Vq-00028G-Ms for ancp@ietf.org; Mon, 07 Jan 2008 17:32:08 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 7 Jan 2008 23:32:05 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 23:32:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] Depreciation of TLVs ... again Date: Mon, 7 Jan 2008 23:32:49 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C93781C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Depreciation of TLVs ... again Thread-Index: AchNQ8mvJfCBpvp7TqWNIfIlzjjJqwBdhukQALBDIGA= References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> From: "Haag, T" To: X-OriginalArrivalTime: 07 Jan 2008 22:32:04.0903 (UTC) FILETIME=[21271370:01C8517D] X-Spam-Score: -1.0 (-) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Busser, M" , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Woj, Thanks for bringing up this issue. >From an operator's point of view which currently runs L2C implementation = in large scale network option 1a is not acceptable at all. Option 1b as compromise is helpful to point out interoperability = problems although option 2 fits best in current running L2C = implementations in large scale networks in conjunction with version = control.=20 The need for version control was discussed several times to find = acceptance. The options you address show to me that the need for version control is = always present although IETF WG discussions have shown a different view. = Regards Thomas Haag =20 T-Systems Enterprise Services GmbH Systems Integration -----Urspr=FCngliche Nachricht----- Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Freitag, 4. Januar 2008 12:11 An: ancp@ietf.org Betreff: [ANCP] Depreciation of TLVs ... again Hi Folks, =20 the Vancouver meeting saw some renewed discussions regarding TLV changes.=20 For the record I will (once again) provide the reasons why this problem needs to be addressed (whether through depreciation or other means). The problem is likely to cause interoperability problems with any new ANCP implementations. The options as I see it are (if there are others, lets hear them): 1a. Do not depreciate TLVs, and assume that all implementations and users will follow the latest ANCP draft (i.e. assume that draft-l2cp problems never happened). 1b. Do not depreciate TLVs, but introduce a "known caveats" in the appendix of the protocol draft, describing the potential legacy implementation interoperability problem. 2. Depreciate TLVs. Now, given that option 2 appears to have just recently been presented with a reasonable argument against it (see Vancouver minutes below), I call for the WG to decide on 1a or 1b.=20 Some background: The problem was introduced in edits made between pre-ANCP WG drafts to draft-wadhwa-gsmp-l2control-configuration-00.=20 Version 00 of this draft dated August 2, 2005 saw the PORT-UP message TLV 0x02 assigned to "Access-Aggregation-Circuit-ID-Binary". The next version 01, dated September 2006, saw the same TLV assigned to "Access-Loop-Remote-Id". A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw it's meaning changed between drafts. The ANCP protocol draft is derived from the 01 version. It so happens however that most known implementations are based on the 00 draft, which presents an interoperability problem to anyone who implemented the 00 definition and those that implement the latest ANCP draft. Hacks aside, a long term fix needs to be devised.=20 NOTE: There is no known way to distinguish l2cp draft 00, 01 or ANCP draft speakers other than trough hacks, which current 00 implementations are known to have adopted as a "workaround" to *ONE* of the problem. Now the original proposal of a solution was drafted in http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and the WG provided no objections. Furthermore the topic was also discussed during IETF 69 back in March 2007 (minutes here: http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html). Again no objections were raised by any of the WG participants. Hence the decision to *depreciate* conflicting TLVs was previously made by the WG (and claims of this being otherwise are removed from the truth).=20 =20 ---snip--- =20 ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net)=20 http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 =20 Discuss protocol draft updates and ANCP graceful restart.=20 ----------------------------------------------------------=20 consistency with framework=20 new section 2.1 on terminology=20 net data rate used=20 new multipair bonding text=20 text for topology discovery extensions 5.4.2=20 clarified message format in line configuration extension, section 5.4.3=20 concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. Common notion is for BRAS to pass TLV transparently into Radius. Changes held back. Doesn't see issue as colliding values have been changed previously. access loop remote id and sub tlv access loop encapsulation=20 suggest not deprecate these tlvs, keep them alive=20 Peter, why did Woj want this deprecated, agrees that these shouldn't be deprecated.=20 Sanjay, reason was to depreciate to avoid overlap, but ROI is small in this case.=20 graceful restart draft updated, support for multicast use cased agreed upon by the WG.=20 Matthew, should graceful restart be a separate draft going forward, Sanjay agreed=20 Matthew, graceful restart not on charter, need to add to milestones=20 ---snip-- Regards, Woj. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jan 08 08:13:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEGq-0000Yk-UG; Tue, 08 Jan 2008 08:13:32 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JCEGp-0000Yf-6t for ancp-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:13:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEGh-0000Y6-S6 for ancp@ietf.org; Tue, 08 Jan 2008 08:13:23 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCEGh-0002iR-1s for ancp@ietf.org; Tue, 08 Jan 2008 08:13:23 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m08D8R8A023254 for ; Tue, 8 Jan 2008 14:08:27 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Jan 2008 14:13:17 +0100 Message-ID: <478376EC.6060404@alcatel-lucent.be> Date: Tue, 08 Jan 2008 14:13:16 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2008 13:13:17.0788 (UTC) FILETIME=[3BD911C0:01C851F8] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [ANCP] Multicast Accounting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, At the last IETF meeting, there was a discussion about multicast accounting is supposed to work. Currently, the framework document mentions 2 options in section 3.4.3: --- o The AN keeps track of when replication starts or stops, and generates the time and/or volume based accounting information per Access Loop and per multicast flow, before sending it to a central accounting system for logging. Since the AN communicates with this accounting system directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document; o The AN keeps track of when replication starts or stops, and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the AN to the NAS. This can be done with the Information Report message. The NAS can then generate the appropriate time and/or volume accounting information per Access Loop and per multicast flow, to be sent to the accounting system. The ANCP requirements to support this approach are specified in this document. --- Is everyone Ok with this? Is more needed, or less, or more clarrification on what it means? Personally, it looks Ok to me but I have a comment for extra clarrification on the first bullet: Does it require any impact on the ANCP protocol? For the second bullet, I would expect that in a white list entry there is a flag indicating whether accounting is needed or not. Is something similar needed to support the first bullet in a white list entry (e.g., need for time and/or volume based accounting with the IP address of acct server)? Whatever is fine for me, but it has to be decided. regards, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jan 08 08:36:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEcP-00055F-4p; Tue, 08 Jan 2008 08:35:49 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JCEcO-000552-D7 for ancp-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEcO-00052n-1Q for ancp@ietf.org; Tue, 08 Jan 2008 08:35:48 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCEcI-0000L1-3X for ancp@ietf.org; Tue, 08 Jan 2008 08:35:48 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9C76FB4239C for ; Tue, 8 Jan 2008 05:35:31 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16134-09 for ; Tue, 8 Jan 2008 05:35:31 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 43679B42398 for ; Tue, 8 Jan 2008 05:35:29 -0800 (PST) Message-ID: <47837C20.3020007@redback.com> Date: Tue, 08 Jan 2008 05:35:28 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Depreciation of TLVs ... again References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <478231F9.9010305@alcatel-lucent.be> <47823C09.4060709@alcatel-lucent.be> In-Reply-To: <47823C09.4060709@alcatel-lucent.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org If a change in a TLV or the addition of a new TLV will cause incorrect operation in a receiver that implements a previous version of the protocol, then the new version requires a new version number. Then the version negotiation can be used to avoid the incorrect operation in case not all peers support the new version. I do not understand the reluctance to bump version numbers. There is enough number space to accommodate the most trivial changes. Stefaan DE CNODDER wrote: > > Woj, > > Let's say that I am against 1a. It also requires that all ANs and all > NASes are upgraded at the same time which is unlikely. > > It depends on which node is typically upgraded first. Are ISPs first > upgrading the NAS or first the AN? I would expect first the NAS. If > that's true, then it looks to me that it should be like this: > > If I see correctly "PORT-UP message TLV Type 0x02" changed meaning and > the original data that was in TLV 0x02 is now in 0x06. However, this is > an optional TLV and does not look that important, and to avoid interop > problems, a NAS should not interprete TLV 0x02 "for some time", except > in displaying this information or other things that does not break the > correct operation of ANCP. This until we are sure that there are no > implementations that use the old spec. This should be described in an > appendix of the draft. > > subTLV 0x90 is renumbered to 0x91. Here the BRAS should, to avoid > interop problems, interprete both 0x90 and 0x91 in the same way. If > both are there, then only 0x91 should be interpreted. Also this should > be described clearly in the appendix. > > In the future it would be better that the numbering is kept as it is. > For instance, for TLV 0x02 it should never have been moved to 0x06 and > then using 0x02 for something else... This could have been avoided, but > if it cannot be avoided, then it should be described explicetely in the > appendix. > > regards, > Stefaan > > > Wojciech Dec (wdec) wrote: > >> Stefaan, are you behind option 1b then? >> >> The case if currently for : >> >> PORT-UP message TLV Type 0x02 >> PORT-UP message TLV 0x04 sub-TLV 0x90 >> >> Both of which I beleive are currenly implemented (based on the >> conflicting definition in draft-wadhwa-00). >> >> BTW. I naturally meant depricate not depreciate ;-) >> >> -Woj. >> >> >> >>> -----Original Message----- >>> From: Stefaan DE CNODDER >>> [mailto:stefaan.de_cnodder@alcatel-lucent.be] Sent: 07 January 2008 >>> 15:07 >>> To: Wojciech Dec (wdec) >>> Cc: ancp@ietf.org >>> Subject: Re: [ANCP] Depreciation of TLVs ... again >>> >>> >>> >>> >>>> 1a. Do not depreciate TLVs, and assume that all implementations and >>>> users will follow the latest ANCP draft (i.e. assume that >>> >>> draft-l2cp >>>> problems never happened). >>> >>> You cannot assume that. >>> >>> >>>> 1b. Do not depreciate TLVs, but introduce a "known caveats" in the >>>> appendix of the protocol draft, describing the potential legacy >>>> implementation interoperability problem. >>> >>> Important changes that may lead to interop issues when >>> implementations implement different versions of the same draft should >>> be documented properly in the appendix. But this should be avoided >>> as much as possible... Maybe it should be looked at case by case. >>> If a number changes of a TLV that is not important, then it will not >>> harm a lot, but if it happens to important TLVs like the ones >>> carrying bandwidth or ACIs, then it should be avoided and if not >>> possible to avoid, describe it very well in the appendix. >>> >>> regards, >>> Stefaan >>> >>> >>> >>>> 2. Depreciate TLVs. >>>> >>>> Now, given that option 2 appears to have just recently been >>> >>> presented >>>> with a reasonable argument against it (see Vancouver >>> >>> minutes below), I >>>> call for the WG to decide on 1a or 1b. >>>> >>>> Some background: >>>> >>>> The problem was introduced in edits made between pre-ANCP >>> >>> WG drafts to >>>> draft-wadhwa-gsmp-l2control-configuration-00. >>>> Version 00 of this draft dated August 2, 2005 saw the >>> >>> PORT-UP message >>>> TLV 0x02 assigned to >>> >>> "Access-Aggregation-Circuit-ID-Binary". The next >>>> version 01, dated September 2006, saw the same TLV assigned to >>>> "Access-Loop-Remote-Id". >>>> A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw >>>> it's meaning changed between drafts. The ANCP protocol draft is >>>> derived from the 01 version. >>>> >>>> It so happens however that most known implementations are >>> >>> based on the >>>> 00 draft, which presents an interoperability problem to anyone who >>>> implemented the 00 definition and those that implement the >>> >>> latest ANCP >>>> draft. Hacks aside, a long term fix needs to be devised. >>>> NOTE: There is no known way to distinguish l2cp draft 00, >>> >>> 01 or ANCP >>>> draft speakers other than trough hacks, which current 00 >>>> implementations are known to have adopted as a "workaround" >>> >>> to *ONE* of the problem. >>> >>>> Now the original proposal of a solution was drafted in >>> >>> http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and >>>> the WG provided no objections. Furthermore the topic was also >>>> discussed during IETF 69 back in March 2007 (minutes here: >>>> http://tools.ietf.org/wg/ancp/minutes?item=minutes68.html). >>> >>> Again no >>>> objections were raised by any of the WG participants. >>>> Hence the decision to *depreciate* conflicting TLVs was previously >>>> made by the WG (and claims of this being otherwise are removed from >>>> the truth). >>>> >>>> >>>> ---snip--- >>>> >>>> ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) >>>> http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 >>>> >>>> Discuss protocol draft updates and ANCP graceful restart. >>>> ---------------------------------------------------------- >>>> consistency with framework >>>> new section 2.1 on terminology >>>> net data rate used >>>> new multipair bonding text >>>> text for topology discovery extensions 5.4.2 clarified >>> >>> message format >>>> in line configuration extension, section 5.4.3 concern over tlv >>>> changes, diverges from tr-101 and rfc 4679 in TLV#. >>>> Common notion is for BRAS to pass TLV transparently into Radius. >>>> Changes held back. Doesn't see issue as colliding values have been >>>> changed previously. >>>> >>>> access loop remote id and sub tlv access loop encapsulation >>>> suggest not deprecate these tlvs, keep them alive Peter, why >>>> did Woj want this deprecated, agrees that >>> >>> these shouldn't >>>> be deprecated. >>>> Sanjay, reason was to depreciate to avoid overlap, but >>> >>> ROI is small >>>> in this case. >>>> graceful restart draft updated, support for multicast use cased >>>> agreed upon by the WG. >>>> Matthew, should graceful restart be a separate draft >>> >>> going forward, >>>> Sanjay agreed >>>> Matthew, graceful restart not on charter, need to add >>> >>> to milestones >>> >>>> ---snip-- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jan 08 09:03:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCF3Q-0004i1-CT; Tue, 08 Jan 2008 09:03:44 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JCF3P-0004hu-NX for ancp-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 09:03:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCF3P-0004hm-Ax for ancp@ietf.org; Tue, 08 Jan 2008 09:03:43 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCF3N-0004JJ-Ta for ancp@ietf.org; Tue, 08 Jan 2008 09:03:43 -0500 X-IronPort-AV: E=Sophos;i="4.24,258,1196636400"; d="scan'208";a="2450179" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2008 15:03:41 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m08E3fCl012783; Tue, 8 Jan 2008 15:03:41 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m08E3aWs015289; Tue, 8 Jan 2008 14:03:36 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:03:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Depreciation of TLVs ... again Date: Tue, 8 Jan 2008 15:03:29 +0100 Message-ID: In-Reply-To: <47837C20.3020007@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Depreciation of TLVs ... again Thread-Index: AchR+8fKAAeAzQsOTuGNCe+C1DYCPAAAhpoQ References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <478231F9.9010305@alcatel-lucent.be> <47823C09.4060709@alcatel-lucent.be> <47837C20.3020007@redback.com> From: "Wojciech Dec (wdec)" To: "Jakob Heitz" , X-OriginalArrivalTime: 08 Jan 2008 14:03:36.0390 (UTC) FILETIME=[43132E60:01C851FF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10422; t=1199801021; x=1200665021; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Depreciation=20of=20TLVs=20... =20again |Sender:=20; bh=ga2vR3/KdLOqeV3zf7k13IW6AfnQ8ZseshV9RO1X0m4=; b=EetSuRxJQ99YhzRV7brBkgPGlDL4u7XDzEy2tLqHxpif2+LDkL9D6biDhu JipsuYNpXrsAkB6n7ViMldT6/FA0lqkf7v6Kp6BCtgiaK0H/hic9RUN2rDEz 5uJr8zDeyW; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Previously posted versioning strategy accepted by the WG: --snip-- The conclusion that we reached is that any protocol version or sub-version change are to be done primarily to address substantial protocol changes that will render previous versions incompatible - this is best practice, besides common sense that is used throughout the IETF community. It will be for the WG group, backed by technical advice when required, to decide when this stage is actually reached. In view of our WG's chartered work, such a stage may actually come towards the end of the protocol specification where we could, for example decide to use a modified protocol state-machine, protocol transport, and/or transport port. The following list is deemed to not qualify as substantial protocol changes, and thus will not be considered as sufficient ground for changing/revising the ANCP version, or sub-version number: i) a new revision of the protocol spec* ii) a conflicting TLV or sub-TLVs iii) incompatibilities arising from implementations of pre-RFC drafts. iv) new negotiable protocol capabilities (eg Bulk message capability) * Unless the revised draft diverges so far in protocol compatibility from its origin as to render it incompatible, for example a new protocol RFC If and when the WG agrees that substantial changes have been made to the protocol, a new protocol version will require an IANA version registry change.=20 --snip--- The problem in this case is that the known problems stem from pre-RFC draft implementations, and even if doing a version change, any deployed "pre ANCP draft" devices would be rendered incompatible unless one introduced in the "next version draft" clauses about backwards compatibility to "pre-rfc" implementations - this is an oxymoron.=20 That said, if the WG is ready to agree and bite the bullet in versioning-up, that option is also possible, but for the reasons above (shouldn't have an RFC dictating backward compatibility to a pre-RFC implementation) not trivial. -Woj. > -----Original Message----- > From: Jakob Heitz [mailto:jheitz@redback.com]=20 > Sent: 08 January 2008 14:35 > To: ancp@ietf.org > Subject: Re: [ANCP] Depreciation of TLVs ... again >=20 > If a change in a TLV or the addition of a new TLV will cause=20 > incorrect operation in a receiver that implements a previous=20 > version of the protocol, then the new version requires a new=20 > version number. >=20 > Then the version negotiation can be used to avoid the=20 > incorrect operation in case not all peers support the new version. >=20 > I do not understand the reluctance to bump version numbers.=20 > There is enough number space to accommodate the most trivial changes. >=20 > Stefaan DE CNODDER wrote: > >=20 > > Woj, > >=20 > > Let's say that I am against 1a. It also requires that all=20 > ANs and all=20 > > NASes are upgraded at the same time which is unlikely. > >=20 > > It depends on which node is typically upgraded first. Are=20 > ISPs first=20 > > upgrading the NAS or first the AN? I would expect first=20 > the NAS. If=20 > > that's true, then it looks to me that it should be like this: > >=20 > > If I see correctly "PORT-UP message TLV Type 0x02" changed=20 > meaning and=20 > > the original data that was in TLV 0x02 is now in 0x06. =20 > However, this=20 > > is an optional TLV and does not look that important, and to avoid=20 > > interop problems, a NAS should not interprete TLV 0x02 "for some=20 > > time", except in displaying this information or other=20 > things that does=20 > > not break the correct operation of ANCP. This until we are=20 > sure that=20 > > there are no implementations that use the old spec. This should be=20 > > described in an appendix of the draft. > >=20 > > subTLV 0x90 is renumbered to 0x91. Here the BRAS should, to avoid=20 > > interop problems, interprete both 0x90 and 0x91 in the same=20 > way. If=20 > > both are there, then only 0x91 should be interpreted. Also this=20 > > should be described clearly in the appendix. > >=20 > > In the future it would be better that the numbering is kept=20 > as it is.=20 > > For instance, for TLV 0x02 it should never have been moved=20 > to 0x06 and=20 > > then using 0x02 for something else... This could have been=20 > avoided,=20 > > but if it cannot be avoided, then it should be described=20 > explicetely=20 > > in the appendix. > >=20 > > regards, > > Stefaan > >=20 > >=20 > > Wojciech Dec (wdec) wrote: > >=20 > >> Stefaan, are you behind option 1b then? > >> > >> The case if currently for : > >> > >> PORT-UP message TLV Type 0x02 > >> PORT-UP message TLV 0x04 sub-TLV 0x90 > >> > >> Both of which I beleive are currenly implemented (based on the=20 > >> conflicting definition in draft-wadhwa-00). > >> > >> BTW. I naturally meant depricate not depreciate ;-) > >> > >> -Woj. > >> =20 > >> > >> > >>> -----Original Message----- > >>> From: Stefaan DE CNODDER > >>> [mailto:stefaan.de_cnodder@alcatel-lucent.be] Sent: 07=20 > January 2008 > >>> 15:07 > >>> To: Wojciech Dec (wdec) > >>> Cc: ancp@ietf.org > >>> Subject: Re: [ANCP] Depreciation of TLVs ... again > >>> > >>> > >>> > >>> > >>>> 1a. Do not depreciate TLVs, and assume that all=20 > implementations and=20 > >>>> users will follow the latest ANCP draft (i.e. assume that > >>> > >>> draft-l2cp > >>>> problems never happened). > >>> > >>> You cannot assume that. > >>> > >>> > >>>> 1b. Do not depreciate TLVs, but introduce a "known=20 > caveats" in the=20 > >>>> appendix of the protocol draft, describing the potential legacy=20 > >>>> implementation interoperability problem. > >>> > >>> Important changes that may lead to interop issues when=20 > >>> implementations implement different versions of the same draft=20 > >>> should be documented properly in the appendix. But this=20 > should be=20 > >>> avoided as much as possible... Maybe it should be looked=20 > at case by case. > >>> If a number changes of a TLV that is not important, then=20 > it will not=20 > >>> harm a lot, but if it happens to important TLVs like the ones=20 > >>> carrying bandwidth or ACIs, then it should be avoided and if not=20 > >>> possible to avoid, describe it very well in the appendix. > >>> > >>> regards, > >>> Stefaan > >>> > >>> > >>> > >>>> 2. Depreciate TLVs. > >>>> > >>>> Now, given that option 2 appears to have just recently been > >>> > >>> presented > >>>> with a reasonable argument against it (see Vancouver > >>> > >>> minutes below), I > >>>> call for the WG to decide on 1a or 1b. > >>>> > >>>> Some background: > >>>> > >>>> The problem was introduced in edits made between pre-ANCP > >>> > >>> WG drafts to > >>>> draft-wadhwa-gsmp-l2control-configuration-00. > >>>> Version 00 of this draft dated August 2, 2005 saw the > >>> > >>> PORT-UP message > >>>> TLV 0x02 assigned to > >>> > >>> "Access-Aggregation-Circuit-ID-Binary". The next > >>>> version 01, dated September 2006, saw the same TLV assigned to=20 > >>>> "Access-Loop-Remote-Id". > >>>> A similar story applies to PORT-UP TLV 0x04 sub-TLV=20 > 0x90, which saw=20 > >>>> it's meaning changed between drafts. The ANCP protocol draft is=20 > >>>> derived from the 01 version. > >>>> > >>>> It so happens however that most known implementations are > >>> > >>> based on the > >>>> 00 draft, which presents an interoperability problem to=20 > anyone who=20 > >>>> implemented the 00 definition and those that implement the > >>> > >>> latest ANCP > >>>> draft. Hacks aside, a long term fix needs to be devised. > >>>> NOTE: There is no known way to distinguish l2cp draft 00, > >>> > >>> 01 or ANCP > >>>> draft speakers other than trough hacks, which current 00=20 > >>>> implementations are known to have adopted as a "workaround" > >>> > >>> to *ONE* of the problem. > >>> > >>>> Now the original proposal of a solution was drafted in > >>> > >>>=20 > http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and > >>>> the WG provided no objections. Furthermore the topic was also=20 > >>>> discussed during IETF 69 back in March 2007 (minutes here: > >>>> http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html).=20 > >>> > >>> Again no > >>>> objections were raised by any of the WG participants. > >>>> Hence the decision to *depreciate* conflicting TLVs was=20 > previously=20 > >>>> made by the WG (and claims of this being otherwise are=20 > removed from=20 > >>>> the truth). > >>>> > >>>> > >>>> ---snip--- > >>>> > >>>> ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) > >>>> http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 > >>>> > >>>> Discuss protocol draft updates and ANCP graceful restart.=20 > >>>> ---------------------------------------------------------- > >>>> consistency with framework > >>>> new section 2.1 on terminology > >>>> net data rate used > >>>> new multipair bonding text > >>>> text for topology discovery extensions 5.4.2 clarified > >>> > >>> message format > >>>> in line configuration extension, section 5.4.3 concern over tlv=20 > >>>> changes, diverges from tr-101 and rfc 4679 in TLV#. > >>>> Common notion is for BRAS to pass TLV transparently into Radius.=20 > >>>> Changes held back. Doesn't see issue as colliding values=20 > have been=20 > >>>> changed previously. > >>>> > >>>> access loop remote id and sub tlv access loop encapsulation=20 > >>>> suggest not deprecate these tlvs, keep them alive =20 > Peter, why=20 > >>>> did Woj want this deprecated, agrees that > >>> > >>> these shouldn't > >>>> be deprecated. > >>>> Sanjay, reason was to depreciate to avoid overlap, but > >>> > >>> ROI is small > >>>> in this case. > >>>> graceful restart draft updated, support for=20 > multicast use cased=20 > >>>> agreed upon by the WG. > >>>> Matthew, should graceful restart be a separate draft > >>> > >>> going forward, > >>>> Sanjay agreed > >>>> Matthew, graceful restart not on charter, need to add > >>> > >>> to milestones > >>> > >>>> ---snip-- >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jan 08 10:02:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFyi-00089c-Mf; Tue, 08 Jan 2008 10:02:56 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JCFyh-00089X-9E for ancp-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 10:02:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFyg-00089E-Vg for ancp@ietf.org; Tue, 08 Jan 2008 10:02:54 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCFyg-0001rv-Du for ancp@ietf.org; Tue, 08 Jan 2008 10:02:54 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m08F0vgX019356 for ; Tue, 8 Jan 2008 16:00:57 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Jan 2008 16:02:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jan 2008 16:02:52 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast BW Admission Control Thread-Index: AchNSCPAh/2yCePiR8uiFuECicuB3AEuduWA References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> From: "OOGHE Sven" To: X-OriginalArrivalTime: 08 Jan 2008 15:02:53.0540 (UTC) FILETIME=[8B4D3240:01C85207] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [ANCP] Multicast BW Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, In the Vancouver meeting minutes there is mention about multicast bandwidth admission control, and what to do with "best effort" streams. Apparently there is some confusion on the concept. This email is the clarify my view on this. As already described in section 3.4.2, there is a need - next to policy based admission control - to perform CAC for the video content being streamed across the access network. The different options to do so are already defined in the framework document. Now, the point I wanted to bring up is that in general, the Access Node and NAS cannot be aware of all possible multicast groups. It is likely that there may be multicast channels offered across the Internet. For these streams, performing bandwidth admission control may be challenging. To solve this, these requests should by default be accepted, but the network should handle the traffic as best effort. This can be done by first of all adding a "catch-all statement" in the Access Node white list or grey list. In case the Access Node queries the NAS, the NAS on his turn will have to accept the request. That way, the unknown streams are not blocked by default. Next, the NAS must make sure that the multicast content coming from the Internet is marked as best effort traffic. This way, whenever congestion occurs somewhere in the access/aggregation network, this stream will be kicked out before the access provider's own premium content. If people agree with this, I suggest to add the above discussion to the framework document. Regards, Sven _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jan 11 08:04:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDJYW-0006Gz-FF; Fri, 11 Jan 2008 08:04:16 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JDJYV-00066j-B5 for ancp-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 08:04:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDJYV-00064T-0D for ancp@ietf.org; Fri, 11 Jan 2008 08:04:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDJYU-0004Qt-MI for ancp@ietf.org; Fri, 11 Jan 2008 08:04:14 -0500 X-IronPort-AV: E=Sophos;i="4.24,271,1196636400"; d="scan'208,217";a="2768323" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jan 2008 14:04:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0BD49Jb026345 for ; Fri, 11 Jan 2008 14:04:09 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0BD49Ws020794 for ; Fri, 11 Jan 2008 13:04:09 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:04:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jan 2008 14:04:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda items for IETF71 ANCP WG meeting Thread-Index: AchUUQtbSvlJlJPeRGysqgny0e3nCQ== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 11 Jan 2008 13:04:09.0625 (UTC) FILETIME=[745B4890:01C85452] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1158; t=1200056649; x=1200920649; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20Agenda=20items=20for=20IETF71=20ANCP=20WG=20mee ting=20 |Sender:=20; bh=eDfmfvQIviTEliXBthBUoI0rJuZOd76mpEDarEWQcMw=; b=V+HWklWe7WliwkqmExO6FNlTD+E3eRR68sPCSa9TQxjDDljfY2A11Bjp91 Q2oAz6s8ElOOcHt2XtN2+uwZpY6wILjq6wJk/kaEH5FTkxYx18d09bWxJ/QH R5QLA4V1Ff; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [ANCP] Agenda items for IETF71 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0039135629==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0039135629== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85452.744735FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85452.744735FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We're taking requests for slots in the agenda for our next ANCP WG meeting. Please respond with any tentative requests by February 8. Thanks, Matthew & Woj ------_=_NextPart_001_01C85452.744735FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda items for IETF71 ANCP WG meeting

We're taking requests for slots = in the agenda for our next ANCP WG meeting.  Please respond with = any tentative requests by February 8.

Thanks,
Matthew & Woj

------_=_NextPart_001_01C85452.744735FE-- --===============0039135629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0039135629==-- From ancp-bounces@ietf.org Mon Jan 14 06:36:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENbs-00022A-13; Mon, 14 Jan 2008 06:36:08 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JENbr-00021P-5Q for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 06:36:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENbq-00021H-S0 for ancp@ietf.org; Mon, 14 Jan 2008 06:36:06 -0500 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JENbo-0001OX-TG for ancp@ietf.org; Mon, 14 Jan 2008 06:36:06 -0500 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F97318062 for ; Mon, 14 Jan 2008 17:06:00 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 5F36A1805E for ; Mon, 14 Jan 2008 17:06:00 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 17:06:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jan 2008 17:06:02 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast Admission Control issues. thread-index: AchWo2iz2JGNbXHXQ86q1Ur0MRGd1Q== From: To: X-OriginalArrivalTime: 14 Jan 2008 11:36:02.0687 (UTC) FILETIME=[A455D0F0:01C856A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [ANCP] Multicast Admission Control issues. X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, The protocol defined in draft-maglione-ancp-mcast-00.txt may not scale well for multiple flows per Access Port. There exists a scenario where the user (behind the Access Port) can request for a new channel when the first channel is still being streamed on his Access Port, that is, a join is sent by the user for the 2nd flow without leave being sent for the 1st flow. As per the draft, AN will honor the 2nd flow as that flow group was already authorized/authenticated by the NAS, when Admission Request was sent for the 1st flow (by AN to NAS) for the 1st flow of that flow group. This will cause issues if sum of the bandwidth demanded by 1st and 2nd flow exceeds the DSL synch up rate of the Access Port. A similar issue might exist with White list configuration as well. As per the draft, AN does not need to consult with NAS for channels listed in white list. In this case,=20 * The bandwidth demanded by a channel in White list may be more than the DSL sync up rate on the Access Port. * The sum of the bandwidth demanded by the 1st and subsequent White list channels on an Access Port may be more than the DSL sync up rate on the Access Port. In both the scenarios, explained above, NAS is not aware of the Access Port bandwidth used by, * White list channels Joined. * 2nd and subsequent flows (of an already authenticated Flow group) Joined. NOTE: The protocol seems to address only the "Conditional Access" requirement but not the "Admission control" for multiple flows. Also the "Multicast Accounting" requirement for "Joins of White list channels" and "Joins of 2nd and subsequent flows of a flow group" are not addressed, as there is no NAS-AN communication for these cases. Regards, Peter _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 07:06:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEO4r-0005Ob-2f; Mon, 14 Jan 2008 07:06:05 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JEO4q-0005OL-68 for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 07:06:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEO4p-0005O9-RY for ancp@ietf.org; Mon, 14 Jan 2008 07:06:03 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEO4p-0001qE-Ai for ancp@ietf.org; Mon, 14 Jan 2008 07:06:03 -0500 X-IronPort-AV: E=Sophos;i="4.24,281,1196636400"; d="scan'208";a="2920453" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2008 13:05:56 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0EC5uCK005959; Mon, 14 Jan 2008 13:05:56 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0EC5UhQ006189; Mon, 14 Jan 2008 12:05:54 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:05:50 +0100 Received: from [10.0.0.45] ([10.61.66.187]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:05:50 +0100 In-Reply-To: <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Multicast BW Admission Control Date: Mon, 14 Jan 2008 13:05:41 +0100 To: OOGHE Sven X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 14 Jan 2008 12:05:50.0554 (UTC) FILETIME=[CDFCABA0:01C856A5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2794; t=1200312356; x=1201176356; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Multicast=20BW=20Admission=20C ontrol |Sender:=20; bh=wGuXmMG3oppyyd3H357S7Zpy0IE2vkCdAguSTjvrq1k=; b=iQz/pMX8lqe5boC9B8BPT4JpshZ/YFWZqbaoZS7u6Y9ftYOeM0xax2Zyp4 Vy2Pfl10oFwUSUmeEsfZYo7RoQBHYEDkm7OrUMs+F0646l4tZ9CPCR9q+NqQ K/ZnLP/Q1T; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Sven, Thanks for the clarification. The approach you describe below seems fine to me. I think the key point it brings is to clarify that it it can make sense to perform CAC on some flows and not on others (and the non- CACed flows will not break the CACed flows). One small point. When you say "the NAS must make sure that the multicast content is marked as best-effort", I wasn't sure if you implied that the NAS would remark the flow. While that may be an option, a more common case if probably that the flow got marked best- effort somewhere upstream (eg when flow enters the SP network). I think it would be worth clarifying. Also, I would suggest that the text uses "Internet/Unkown" channels just as an example of where this sort of approach may be used, but make it clear it is a generic capability (e.g. the best-effort approach can be used on known flows also). Cheers Francois On 8 Jan 2008, at 16:02, OOGHE Sven wrote: > Hi, > > In the Vancouver meeting minutes there is mention about multicast > bandwidth admission control, and what to do with "best effort" > streams. > Apparently there is some confusion on the concept. This email is the > clarify my view on this. > > As already described in section 3.4.2, there is a need - next to > policy > based admission control - to perform CAC for the video content being > streamed across the access network. The different options to do so are > already defined in the framework document. > > Now, the point I wanted to bring up is that in general, the Access > Node > and NAS cannot be aware of all possible multicast groups. It is likely > that there may be multicast channels offered across the Internet. For > these streams, performing bandwidth admission control may be > challenging. > > To solve this, these requests should by default be accepted, but the > network should handle the traffic as best effort. This can be done by > first of all adding a "catch-all statement" in the Access Node white > list or grey list. In case the Access Node queries the NAS, the NAS on > his turn will have to accept the request. That way, the unknown > streams > are not blocked by default. Next, the NAS must make sure that the > multicast content coming from the Internet is marked as best effort > traffic. This way, whenever congestion occurs somewhere in the > access/aggregation network, this stream will be kicked out before the > access provider's own premium content. > > If people agree with this, I suggest to add the above discussion to > the > framework document. > > Regards, > Sven > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 07:41:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOdQ-0007Um-PV; Mon, 14 Jan 2008 07:41:48 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JEOdP-0007Ug-4O for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 07:41:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOdO-0007UY-P4 for ancp@ietf.org; Mon, 14 Jan 2008 07:41:46 -0500 Received: from mailm.telecomitalia.it ([217.169.121.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEOdN-0008JJ-U3 for ancp@ietf.org; Mon, 14 Jan 2008 07:41:46 -0500 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:41:40 +0100 Received: from PTPEVS103RM001.idc.cww.telecomitalia.it ([156.54.208.22]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:41:40 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jan 2008 13:41:39 +0100 Message-ID: <6FCF06DE599E7C4690E588F22B45AE1C024A821D@PTPEVS103RM001.idc.cww.telecomitalia.it> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast Admission Control issues. thread-index: AchWo2iz2JGNbXHXQ86q1Ur0MRGd1QABumcQ References: From: "Maglione Roberta" To: , X-OriginalArrivalTime: 14 Jan 2008 12:41:40.0291 (UTC) FILETIME=[CF548130:01C856AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Subject: [ANCP] RE: Multicast Admission Control issues. X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Peter,=20 Your comments regarding to the admission control for multiple flows are absolutely correct, in fact the draft does not complete address the scenarios that you mentioned. What we first had in mind for these cases was to give the NAS the capability to specify how many multicast flows belonging to the same flow group can be simultaneously accepted by AN, but there were some additional comments on flow group concept raised by Sanjay on the mailing list (see below) thus I think we may need more discussion and inputs from the working group in order to finalize what will be the admission control mechanism for multiple flow. =20 Thanks and best regards, Roberta The message flows indicate that the replication always starts for a given flow on reception of an "Admission Response" for that flow. This might not always be true. There are atleast two conditions here: (a) A Join for a different flow in the same flow-group is received by the AN due to a channel change, before the admission response is received for the pending request. In this case one would assume the admission response is still applicable (since it is for the flow-group) and the replication for the new flow can commence. (b) A new Join for a different flow in a different flow-group (e.g. going from an SD to a HD flow) might be received while admission response for the old join is still pending. In this case another admission request is generated and no replication happens. Message flows or text is needed to indicate these scenarios. ------------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia=20 Broadband Network Services Innovation ------------------------------------------------------- -----Original Message----- From: peter.naveen@wipro.com [mailto:peter.naveen@wipro.com]=20 Sent: Monday, January 14, 2008 12:36 PM To: ancp@ietf.org Cc: Maglione Roberta; Garofalo Angelo Subject: Multicast Admission Control issues. Hi, The protocol defined in draft-maglione-ancp-mcast-00.txt may not scale well for multiple flows per Access Port. There exists a scenario where the user (behind the Access Port) can request for a new channel when the first channel is still being streamed on his Access Port, that is, a join is sent by the user for the 2nd flow without leave being sent for the 1st flow. As per the draft, AN will honor the 2nd flow as that flow group was already authorized/authenticated by the NAS, when Admission Request was sent for the 1st flow (by AN to NAS) for the 1st flow of that flow group. This will cause issues if sum of the bandwidth demanded by 1st and 2nd flow exceeds the DSL synch up rate of the Access Port. A similar issue might exist with White list configuration as well. As per the draft, AN does not need to consult with NAS for channels listed in white list. In this case,=20 * The bandwidth demanded by a channel in White list may be more than the DSL sync up rate on the Access Port. * The sum of the bandwidth demanded by the 1st and subsequent White list channels on an Access Port may be more than the DSL sync up rate on the Access Port. In both the scenarios, explained above, NAS is not aware of the Access Port bandwidth used by, * White list channels Joined. * 2nd and subsequent flows (of an already authenticated Flow group) Joined. NOTE: The protocol seems to address only the "Conditional Access" requirement but not the "Admission control" for multiple flows. Also the "Multicast Accounting" requirement for "Joins of White list channels" and "Joins of 2nd and subsequent flows of a flow group" are not addressed, as there is no NAS-AN communication for these cases. Regards, Peter The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------------------------------------------------------------- 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 = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 07:47:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOiS-0001Uh-7b; Mon, 14 Jan 2008 07:47:00 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JEOiQ-0001Qw-RL for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 07:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOiQ-0001Qg-HT for ancp@ietf.org; Mon, 14 Jan 2008 07:46:58 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEOiP-0002Uy-Ks for ancp@ietf.org; Mon, 14 Jan 2008 07:46:58 -0500 X-IronPort-AV: E=Sophos;i="4.24,282,1196636400"; d="scan'208";a="2926149" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2008 13:46:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0ECkug0013031; Mon, 14 Jan 2008 13:46:56 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0ECkvgo024298; Mon, 14 Jan 2008 12:46:57 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 13:46:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast Accounting Date: Mon, 14 Jan 2008 13:46:50 +0100 Message-ID: In-Reply-To: <478376EC.6060404@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast Accounting Thread-Index: AchR+FAwG84D+O92RBCni7peYtL15QEq+kKA References: <478376EC.6060404@alcatel-lucent.be> From: "Wojciech Dec (wdec)" To: "Stefaan DE CNODDER" , X-OriginalArrivalTime: 14 Jan 2008 12:46:56.0813 (UTC) FILETIME=[8BFDEDD0:01C856AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3891; t=1200314817; x=1201178817; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Multicast=20Accounting |Sender:=20; bh=fJg7cEL/WcbT6cEAkHI8Acd14p3F36LMCfjNz3Q5LV0=; b=T7LM7KAiVmAbAvP8WkT8r3PFwKMnAjZ2jRAJwCbCuTZSTMhFNm2uuL2fm/ un5LXul4bhnve7Ar5dPm76ewe8tNB8KHBPyw6TiN/MnXr1U5mywyprVViYGi YzD1uSfCBy; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Stefaan, it doesn't seem that we have agreement on this text, and an alternative proposal is presented in http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. ---snip--- in Section "3.4.3 Multicast Accounting" replace: " o The AN keeps track of when replication starts or stops, and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the AN to the NAS. This can be done with the Information Report message. The NAS can then generate the appropriate time and/or volume accounting information per Access Loop and per multicast flow, to be sent to the accounting system. The ANCP requirements to support this approach are specified in this document. " by " o The AN keeps track of when replication for a given multicast flow starts or stops and then the AN can convey time and/or volume information to the NAS for further processing. This approach relies on ANCP and is discussed below.=20 ---snip--- In general for accounting to be of use it needs to be fairly accurate, hence it is highly desirable for the access node to present to the NAS the time and/or volume information for further processing. Granted that if access nodes are not capable of providing such information, they will only signal simple start/stop events. I however don't see why the framework and protocol should be limited only to this latter variant. Is there a reason why the proposal presented by Francois is inadequate? Regards, Woj. > -----Original Message----- > From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: 08 January 2008 14:13 > To: ancp@ietf.org > Subject: [ANCP] Multicast Accounting >=20 >=20 > Hi, >=20 > At the last IETF meeting, there was a discussion about=20 > multicast accounting is supposed to work. Currently, the=20 > framework document mentions 2 options in section 3.4.3: >=20 > --- > o The AN keeps track of when replication starts or stops, and > generates the time and/or volume based accounting=20 > information per > Access Loop and per multicast flow, before sending it=20 > to a central > accounting system for logging. Since the AN communicates with > this accounting system directly, the approach doesn't=20 > require the > use of ANCP. It is therefore beyond the scope of this=20 > document; >=20 > o The AN keeps track of when replication starts or stops, and > reports this information to the NAS for further processing. In > this case, ANCP can be used to send the information=20 > from the AN to > the NAS. This can be done with the Information Report message. > The NAS can then generate the appropriate time and/or volume > accounting information per Access Loop and per=20 > multicast flow, to > be sent to the accounting system. The ANCP requirements to > support this approach are specified in this document. > --- >=20 > Is everyone Ok with this? Is more needed, or less, or more=20 > clarrification on what it means? >=20 > Personally, it looks Ok to me but I have a comment for extra=20 > clarrification on the first bullet: Does it require any=20 > impact on the ANCP protocol? For the second bullet, I would=20 > expect that in a white list entry there is a flag indicating=20 > whether accounting is needed or not. Is something similar=20 > needed to support the first bullet in a white list entry=20 > (e.g., need for time and/or volume based accounting with the=20 > IP address of acct server)? Whatever is fine for me, but it=20 > has to be decided. >=20 > regards, > Stefaan >=20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 08:00:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOvR-0002c7-3w; Mon, 14 Jan 2008 08:00:25 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JEOvP-0002bh-EU for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 08:00:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOvP-0002bO-2e for ancp@ietf.org; Mon, 14 Jan 2008 08:00:23 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEOvO-0000GR-Ac for ancp@ietf.org; Mon, 14 Jan 2008 08:00:22 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0ECsNKo010221; Mon, 14 Jan 2008 13:54:23 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Jan 2008 14:00:16 +0100 Message-ID: <478B5CDC.3070303@alcatel-lucent.be> Date: Mon, 14 Jan 2008 14:00:12 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Multicast Accounting References: <478376EC.6060404@alcatel-lucent.be> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2008 13:00:16.0211 (UTC) FILETIME=[68786230:01C856AD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Woj, The framework draft currently does not exclude anything. Both options are possible. The case where the AN is counting the packets and measuring the time is also in the framework and this information can be sent directly from the AN to the accounting server (which might be the NAS itself of course) with another protocol than ANCP like Radius for instance. Actually, section 3.4.3 has to be read as whole and not just the part I copy/pasted in the email. The question is basically if this section is Ok for everyone. From a protocol point of view, this means that each entry in the white list has the following information: indication whether accounting is needed or not, and if needed, whehter the accounting is performed by the NAS or by the AN. In the latter case, also the IP address of the accounting servers are specified. regards, Stefaan Wojciech Dec (wdec) wrote: > Hi Stefaan, > > it doesn't seem that we have agreement on this text, and an alternative > proposal is presented in > http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. > > ---snip--- > in Section "3.4.3 Multicast Accounting" > > > replace: > " > o The AN keeps track of when replication starts or stops, and > reports this information to the NAS for further processing. In > this case, ANCP can be used to send the information from the AN to > the NAS. This can be done with the Information Report message. > The NAS can then generate the appropriate time and/or volume > accounting information per Access Loop and per multicast flow, to > be sent to the accounting system. The ANCP requirements to > support this approach are specified in this document. > " > by > " > o The AN keeps track of when replication for a given multicast flow > starts or stops and then the AN can convey time and/or volume > information to > the NAS for further processing. This approach relies on ANCP and is > discussed below. > > ---snip--- > > In general for accounting to be of use it needs to be fairly accurate, > hence it is highly desirable for the access node to present to the NAS > the time and/or volume information for further processing. Granted that > if access nodes are not capable of providing such information, they will > only signal simple start/stop events. I however don't see why the > framework and protocol should be limited only to this latter variant. Is > there a reason why the proposal presented by Francois is inadequate? > > Regards, > Woj. > > >>-----Original Message----- >>From: Stefaan DE CNODDER >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Sent: 08 January 2008 14:13 >>To: ancp@ietf.org >>Subject: [ANCP] Multicast Accounting >> >> >>Hi, >> >>At the last IETF meeting, there was a discussion about >>multicast accounting is supposed to work. Currently, the >>framework document mentions 2 options in section 3.4.3: >> >>--- >> o The AN keeps track of when replication starts or stops, and >> generates the time and/or volume based accounting >>information per >> Access Loop and per multicast flow, before sending it >>to a central >> accounting system for logging. Since the AN communicates with >> this accounting system directly, the approach doesn't >>require the >> use of ANCP. It is therefore beyond the scope of this >>document; >> >> o The AN keeps track of when replication starts or stops, and >> reports this information to the NAS for further processing. In >> this case, ANCP can be used to send the information >>from the AN to >> the NAS. This can be done with the Information Report message. >> The NAS can then generate the appropriate time and/or volume >> accounting information per Access Loop and per >>multicast flow, to >> be sent to the accounting system. The ANCP requirements to >> support this approach are specified in this document. >>--- >> >>Is everyone Ok with this? Is more needed, or less, or more >>clarrification on what it means? >> >>Personally, it looks Ok to me but I have a comment for extra >>clarrification on the first bullet: Does it require any >>impact on the ANCP protocol? For the second bullet, I would >>expect that in a white list entry there is a flag indicating >>whether accounting is needed or not. Is something similar >>needed to support the first bullet in a white list entry >>(e.g., need for time and/or volume based accounting with the >>IP address of acct server)? Whatever is fine for me, but it >>has to be decided. >> >>regards, >>Stefaan >> >> >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>https://www1.ietf.org/mailman/listinfo/ancp > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 08:22:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPGs-0004DM-Gj; Mon, 14 Jan 2008 08:22:34 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JEPGq-00046Z-Of for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 08:22:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPGp-00046Q-Vt for ancp@ietf.org; Mon, 14 Jan 2008 08:22:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEPGp-0000lk-1y for ancp@ietf.org; Mon, 14 Jan 2008 08:22:31 -0500 X-IronPort-AV: E=Sophos;i="4.24,282,1196636400"; d="scan'208";a="2931634" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2008 14:22:29 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0EDMTho001434; Mon, 14 Jan 2008 14:22:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0EDMTgs011285; Mon, 14 Jan 2008 13:22:29 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 14:22:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast Accounting Date: Mon, 14 Jan 2008 14:22:26 +0100 Message-ID: In-Reply-To: <478B5CDC.3070303@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast Accounting Thread-Index: AchWrXHkkJf93V8tQUqziJnFa51VIgAAuKSA References: <478376EC.6060404@alcatel-lucent.be> <478B5CDC.3070303@alcatel-lucent.be> From: "Wojciech Dec (wdec)" To: "Stefaan DE CNODDER" X-OriginalArrivalTime: 14 Jan 2008 13:22:29.0457 (UTC) FILETIME=[83259410:01C856B0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5869; t=1200316949; x=1201180949; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Multicast=20Accounting |Sender:=20; bh=DwfVcWNWDhmP+a1jqpqqki82x82t+0VhZ82cMcD1Hfk=; b=iRGuqtScEmQtO0+TzjY3WofZMVureKZasqZAHo0LScUXmwiH5uG9zvP19O I2nWYx6WSDZL0LVg+JlXLmJgGUVHNPsNwwxEEhyPt/ek9u5nHUNyIe1z68YZ zuE1UZtlj6; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Stefaan, then you're saying that you agree with Francois' proposal for Section 3.4.3? -Woj.=20 > -----Original Message----- > From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: 14 January 2008 14:00 > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Multicast Accounting >=20 >=20 > Woj, >=20 > The framework draft currently does not exclude anything. =20 > Both options are possible. The case where the AN is counting=20 > the packets and measuring the time is also in the framework=20 > and this information can be sent directly from the AN to the=20 > accounting server (which might be the NAS itself of course)=20 > with another protocol than ANCP like Radius for instance. =20 > Actually, section 3.4.3 has to be read as whole and not just=20 > the part I copy/pasted in the email. The question is=20 > basically if this section is Ok for everyone. >=20 > From a protocol point of view, this means that each entry in=20 > the white list has the following information: indication=20 > whether accounting is needed or not, and if needed, whehter=20 > the accounting is performed by the NAS or by the AN. In the=20 > latter case, also the IP address of the accounting servers=20 > are specified. >=20 > regards, > Stefaan >=20 >=20 > Wojciech Dec (wdec) wrote: > > Hi Stefaan, > >=20 > > it doesn't seem that we have agreement on this text, and an=20 > > alternative proposal is presented in=20 > > http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. > >=20 > > ---snip--- > > in Section "3.4.3 Multicast Accounting" > >=20 > >=20 > > replace: > > " > > o The AN keeps track of when replication starts or stops,=20 > and reports=20 > > this information to the NAS for further processing. In this=20 > case, ANCP=20 > > can be used to send the information from the AN to the NAS.=20 > This can=20 > > be done with the Information Report message. > > The NAS can then generate the appropriate time and/or volume=20 > > accounting information per Access Loop and per multicast=20 > flow, to be=20 > > sent to the accounting system. The ANCP requirements to=20 > support this=20 > > approach are specified in this document. > > " > > by > > " > > o The AN keeps track of when replication for a given multicast flow=20 > > starts or stops and then the AN can convey time and/or volume=20 > > information to the NAS for further processing. This=20 > approach relies on=20 > > ANCP and is discussed below. > >=20 > > ---snip--- > >=20 > > In general for accounting to be of use it needs to be=20 > fairly accurate,=20 > > hence it is highly desirable for the access node to present=20 > to the NAS=20 > > the time and/or volume information for further processing. Granted=20 > > that if access nodes are not capable of providing such information,=20 > > they will only signal simple start/stop events. I however don't see=20 > > why the framework and protocol should be limited only to=20 > this latter=20 > > variant. Is there a reason why the proposal presented by=20 > Francois is inadequate? > >=20 > > Regards, > > Woj. > >=20 > >=20 > >>-----Original Message----- > >>From: Stefaan DE CNODDER > >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > >>Sent: 08 January 2008 14:13 > >>To: ancp@ietf.org > >>Subject: [ANCP] Multicast Accounting > >> > >> > >>Hi, > >> > >>At the last IETF meeting, there was a discussion about multicast=20 > >>accounting is supposed to work. Currently, the framework document=20 > >>mentions 2 options in section 3.4.3: > >> > >>--- > >> o The AN keeps track of when replication starts or stops, and > >> generates the time and/or volume based accounting=20 > information=20 > >>per > >> Access Loop and per multicast flow, before sending it to a=20 > >>central > >> accounting system for logging. Since the AN=20 > communicates with > >> this accounting system directly, the approach=20 > doesn't require=20 > >>the > >> use of ANCP. It is therefore beyond the scope of this=20 > >>document; > >> > >> o The AN keeps track of when replication starts or stops, and > >> reports this information to the NAS for further=20 > processing. In > >> this case, ANCP can be used to send the information=20 > from the AN=20 > >>to > >> the NAS. This can be done with the Information=20 > Report message. > >> The NAS can then generate the appropriate time and/or volume > >> accounting information per Access Loop and per=20 > multicast flow,=20 > >>to > >> be sent to the accounting system. The ANCP requirements to > >> support this approach are specified in this document. > >>--- > >> > >>Is everyone Ok with this? Is more needed, or less, or more=20 > >>clarrification on what it means? > >> > >>Personally, it looks Ok to me but I have a comment for extra=20 > >>clarrification on the first bullet: Does it require any=20 > impact on the=20 > >>ANCP protocol? For the second bullet, I would expect that=20 > in a white=20 > >>list entry there is a flag indicating whether accounting is=20 > needed or=20 > >>not. Is something similar needed to support the first bullet in a=20 > >>white list entry (e.g., need for time and/or volume based=20 > accounting=20 > >>with the IP address of acct server)? Whatever is fine for=20 > me, but it=20 > >>has to be decided. > >> > >>regards, > >>Stefaan > >> > >> > >> > >>_______________________________________________ > >>ANCP mailing list > >>ANCP@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 08:56:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPo4-00041d-RQ; Mon, 14 Jan 2008 08:56:52 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JEPo3-000405-7Z for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 08:56:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEPo2-0003xQ-SD for ancp@ietf.org; Mon, 14 Jan 2008 08:56:50 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEPo1-0003bW-Nf for ancp@ietf.org; Mon, 14 Jan 2008 08:56:50 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0EDoF8u014304; Mon, 14 Jan 2008 14:50:32 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Jan 2008 14:56:25 +0100 Message-ID: <478B6A08.1020508@alcatel-lucent.be> Date: Mon, 14 Jan 2008 14:56:24 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Multicast Accounting References: <478376EC.6060404@alcatel-lucent.be> <478B5CDC.3070303@alcatel-lucent.be> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2008 13:56:25.0364 (UTC) FILETIME=[40A45540:01C856B5] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Woj, From a functional point of view it is Ok but the comment was to change the second bullet of section 3.4.3 into what is already in the first bullet of section 3.4.3 (although there it is generalised that the AN can send this info to any acct server and not just the NAS). My question is whether we can remove the first bullet. If the AN has to do the multicast accounting, then it can also do the unicast accounting and I thought ANCP was about moving all of this to the NAS. And if the AN can do the unicast accounting, then it can do the appropriate QoS queueing as well.... Anyhow, I am fine with the current text in the framework and if we believe that the comment below was on the wrong bullet, then it is all Ok. I have more problems with the capabilities negotiated with ANCP. Implementation will not support all or nothing but that is what is negotiated in the capabilities. Have the capabilities to be more fine-grained or should support/non-support be reflected in error codes? regards, Stefaan Wojciech Dec (wdec) wrote: > Stefaan, > > then you're saying that you agree with Francois' proposal for Section > 3.4.3? > > -Woj. > > >>-----Original Message----- >>From: Stefaan DE CNODDER >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Sent: 14 January 2008 14:00 >>To: Wojciech Dec (wdec) >>Cc: ancp@ietf.org >>Subject: Re: [ANCP] Multicast Accounting >> >> >>Woj, >> >>The framework draft currently does not exclude anything. >>Both options are possible. The case where the AN is counting >>the packets and measuring the time is also in the framework >>and this information can be sent directly from the AN to the >>accounting server (which might be the NAS itself of course) >>with another protocol than ANCP like Radius for instance. >>Actually, section 3.4.3 has to be read as whole and not just >>the part I copy/pasted in the email. The question is >>basically if this section is Ok for everyone. >> >> From a protocol point of view, this means that each entry in >>the white list has the following information: indication >>whether accounting is needed or not, and if needed, whehter >>the accounting is performed by the NAS or by the AN. In the >>latter case, also the IP address of the accounting servers >>are specified. >> >>regards, >>Stefaan >> >> >>Wojciech Dec (wdec) wrote: >> >>>Hi Stefaan, >>> >>>it doesn't seem that we have agreement on this text, and an >>>alternative proposal is presented in >>>http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. >>> >>>---snip--- >>>in Section "3.4.3 Multicast Accounting" >>> >>> >>>replace: >>>" >>>o The AN keeps track of when replication starts or stops, >> >>and reports >> >>>this information to the NAS for further processing. In this >> >>case, ANCP >> >>>can be used to send the information from the AN to the NAS. >> >>This can >> >>>be done with the Information Report message. >>>The NAS can then generate the appropriate time and/or volume >>>accounting information per Access Loop and per multicast >> >>flow, to be >> >>>sent to the accounting system. The ANCP requirements to >> >>support this >> >>>approach are specified in this document. >>>" >>>by >>>" >>>o The AN keeps track of when replication for a given multicast flow >>>starts or stops and then the AN can convey time and/or volume >>>information to the NAS for further processing. This >> >>approach relies on >> >>>ANCP and is discussed below. >>> >>>---snip--- >>> >>>In general for accounting to be of use it needs to be >> >>fairly accurate, >> >>>hence it is highly desirable for the access node to present >> >>to the NAS >> >>>the time and/or volume information for further processing. Granted >>>that if access nodes are not capable of providing such information, >>>they will only signal simple start/stop events. I however don't see >>>why the framework and protocol should be limited only to >> >>this latter >> >>>variant. Is there a reason why the proposal presented by >> >>Francois is inadequate? >> >>>Regards, >>>Woj. >>> >>> >>> >>>>-----Original Message----- >>>>From: Stefaan DE CNODDER >>>>[mailto:stefaan.de_cnodder@alcatel-lucent.be] >>>>Sent: 08 January 2008 14:13 >>>>To: ancp@ietf.org >>>>Subject: [ANCP] Multicast Accounting >>>> >>>> >>>>Hi, >>>> >>>>At the last IETF meeting, there was a discussion about multicast >>>>accounting is supposed to work. Currently, the framework document >>>>mentions 2 options in section 3.4.3: >>>> >>>>--- >>>> o The AN keeps track of when replication starts or stops, and >>>> generates the time and/or volume based accounting >> >>information >> >>>>per >>>> Access Loop and per multicast flow, before sending it to a >>>>central >>>> accounting system for logging. Since the AN >> >>communicates with >> >>>> this accounting system directly, the approach >> >>doesn't require >> >>>>the >>>> use of ANCP. It is therefore beyond the scope of this >>>>document; >>>> >>>> o The AN keeps track of when replication starts or stops, and >>>> reports this information to the NAS for further >> >>processing. In >> >>>> this case, ANCP can be used to send the information >> >>from the AN >> >>>>to >>>> the NAS. This can be done with the Information >> >>Report message. >> >>>> The NAS can then generate the appropriate time and/or volume >>>> accounting information per Access Loop and per >> >>multicast flow, >> >>>>to >>>> be sent to the accounting system. The ANCP requirements to >>>> support this approach are specified in this document. >>>>--- >>>> >>>>Is everyone Ok with this? Is more needed, or less, or more >>>>clarrification on what it means? >>>> >>>>Personally, it looks Ok to me but I have a comment for extra >>>>clarrification on the first bullet: Does it require any >> >>impact on the >> >>>>ANCP protocol? For the second bullet, I would expect that >> >>in a white >> >>>>list entry there is a flag indicating whether accounting is >> >>needed or >> >>>>not. Is something similar needed to support the first bullet in a >>>>white list entry (e.g., need for time and/or volume based >> >>accounting >> >>>>with the IP address of acct server)? Whatever is fine for >> >>me, but it >> >>>>has to be decided. >>>> >>>>regards, >>>>Stefaan >>>> >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ancp >>> >>> >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>https://www1.ietf.org/mailman/listinfo/ancp > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 10:39:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JERPD-0005ac-Vq; Mon, 14 Jan 2008 10:39:19 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JERPC-0005Yk-Ch for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 10:39:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JERPB-0005XA-VW for ancp@ietf.org; Mon, 14 Jan 2008 10:39:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JERPA-0004Zj-Pn for ancp@ietf.org; Mon, 14 Jan 2008 10:39:17 -0500 X-IronPort-AV: E=Sophos;i="4.24,282,1196636400"; d="scan'208";a="2952429" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2008 16:39:13 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0EFdDmc012966; Mon, 14 Jan 2008 16:39:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0EFdDgo013869; Mon, 14 Jan 2008 15:39:13 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 16:39:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast Accounting Date: Mon, 14 Jan 2008 16:39:10 +0100 Message-ID: In-Reply-To: <478B6A08.1020508@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast Accounting Thread-Index: AchWtVjd9pqIhQ7VSFaPeTAJDQNqlQAAeY2A References: <478376EC.6060404@alcatel-lucent.be> <478B5CDC.3070303@alcatel-lucent.be> <478B6A08.1020508@alcatel-lucent.be> From: "Wojciech Dec (wdec)" To: "Stefaan DE CNODDER" X-OriginalArrivalTime: 14 Jan 2008 15:39:13.0518 (UTC) FILETIME=[9D25F0E0:01C856C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9105; t=1200325153; x=1201189153; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Multicast=20Accounting |Sender:=20; bh=/Bc81x/gUgSfQBWGBwYfhhpE2wc2f/Oibn+zNbWLsuY=; b=HTdsayxW5d0L30Z/Cf9XT77mgoG10m7acfaH5IZ0br4R1E/e8fMjydkyeK bozvKZ6YvRcK46WZts0erPrsAgETIrVuY6fNr/Na7P1oFe73J3WyIjeBcBXF lnzWJhRjmK; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Stefaan, I'll let Francois & Roberta comment on whether their proposal was to obly replace a bullet in Sec3.4.3, or both of them. In either case however, the proposal is very clear in removing the restrcition that mcast traffic accounting is out of scope, hence based on that reading the *current* framework text is not agreed to. As for the philosphy behind ANCP, it's useful to keep in mind the black box principle: ANCP should provide functionality to make the combination of NAS + L2 Access-Node look like one black box. Hence, irrespective of whether the AN can or cannot do unicat accounting, for the purpose of ANCP and multicast it appears rather useful to address the scenario where an AN *is* able to provide detailed mcast replication stats per port, beyond the basic case where it isn't. In terms of capabilities, such detailed stat reports could indeed be the subject of an additional negotiated capability, but on this I'd like the WG to provide some comments.=20 - Does anyone forsee a use for only simple start/stop mcast ANCP accounting messages vs start/stop accounting with detailed info?=20 - And does anyone forsee a deployment model where a mix of the modes is used, eg AN1 supporting detailed-mode and AN2 supporting not-detailed-mode? Regards, Woj. > -----Original Message----- > From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: 14 January 2008 14:56 > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Multicast Accounting >=20 >=20 > Woj, >=20 > From a functional point of view it is Ok but the comment was=20 > to change the second bullet of section 3.4.3 into what is=20 > already in the first bullet of section 3.4.3 (although there=20 > it is generalised that the AN can send this info to any acct=20 > server and not just the NAS). >=20 > My question is whether we can remove the first bullet. If=20 > the AN has to do the multicast accounting, then it can also=20 > do the unicast accounting and I thought ANCP was about moving=20 > all of this to the NAS. And if the AN can do the unicast=20 > accounting, then it can do the appropriate QoS queueing as=20 > well.... Anyhow, I am fine with the current text in the=20 > framework and if we believe that the comment below was on the=20 > wrong bullet, then it is all Ok. >=20 > I have more problems with the capabilities negotiated with ANCP.=20 > Implementation will not support all or nothing but that is=20 > what is negotiated in the capabilities. Have the=20 > capabilities to be more fine-grained or should=20 > support/non-support be reflected in error codes? >=20 > regards, > Stefaan >=20 >=20 > Wojciech Dec (wdec) wrote: >=20 > > Stefaan, > >=20 > > then you're saying that you agree with Francois' proposal=20 > for Section=20 > > 3.4.3? > >=20 > > -Woj.=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Stefaan DE CNODDER > >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > >>Sent: 14 January 2008 14:00 > >>To: Wojciech Dec (wdec) > >>Cc: ancp@ietf.org > >>Subject: Re: [ANCP] Multicast Accounting > >> > >> > >>Woj, > >> > >>The framework draft currently does not exclude anything. =20 > >>Both options are possible. The case where the AN is counting the=20 > >>packets and measuring the time is also in the framework and this=20 > >>information can be sent directly from the AN to the=20 > accounting server=20 > >>(which might be the NAS itself of course) with another=20 > protocol than=20 > >>ANCP like Radius for instance. > >>Actually, section 3.4.3 has to be read as whole and not=20 > just the part=20 > >>I copy/pasted in the email. The question is basically if=20 > this section=20 > >>is Ok for everyone. > >> > >> From a protocol point of view, this means that each entry in the=20 > >>white list has the following information: indication whether=20 > >>accounting is needed or not, and if needed, whehter the=20 > accounting is=20 > >>performed by the NAS or by the AN. In the latter case, also the IP=20 > >>address of the accounting servers are specified. > >> > >>regards, > >>Stefaan > >> > >> > >>Wojciech Dec (wdec) wrote: > >> > >>>Hi Stefaan, > >>> > >>>it doesn't seem that we have agreement on this text, and an=20 > >>>alternative proposal is presented in=20 > >>>http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. > >>> > >>>---snip--- > >>>in Section "3.4.3 Multicast Accounting" > >>> > >>> > >>>replace: > >>>" > >>>o The AN keeps track of when replication starts or stops, > >> > >>and reports > >> > >>>this information to the NAS for further processing. In this > >> > >>case, ANCP > >> > >>>can be used to send the information from the AN to the NAS.=20 > >> > >>This can > >> > >>>be done with the Information Report message. > >>>The NAS can then generate the appropriate time and/or volume=20 > >>>accounting information per Access Loop and per multicast > >> > >>flow, to be > >> > >>>sent to the accounting system. The ANCP requirements to > >> > >>support this > >> > >>>approach are specified in this document. > >>>" > >>>by > >>>" > >>>o The AN keeps track of when replication for a given=20 > multicast flow=20 > >>>starts or stops and then the AN can convey time and/or volume=20 > >>>information to the NAS for further processing. This > >> > >>approach relies on > >> > >>>ANCP and is discussed below. > >>> > >>>---snip--- > >>> > >>>In general for accounting to be of use it needs to be > >> > >>fairly accurate, > >> > >>>hence it is highly desirable for the access node to present > >> > >>to the NAS > >> > >>>the time and/or volume information for further processing. Granted=20 > >>>that if access nodes are not capable of providing such=20 > information,=20 > >>>they will only signal simple start/stop events. I however=20 > don't see=20 > >>>why the framework and protocol should be limited only to > >> > >>this latter > >> > >>>variant. Is there a reason why the proposal presented by > >> > >>Francois is inadequate? > >> > >>>Regards, > >>>Woj. > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Stefaan DE CNODDER > >>>>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > >>>>Sent: 08 January 2008 14:13 > >>>>To: ancp@ietf.org > >>>>Subject: [ANCP] Multicast Accounting > >>>> > >>>> > >>>>Hi, > >>>> > >>>>At the last IETF meeting, there was a discussion about multicast=20 > >>>>accounting is supposed to work. Currently, the framework=20 > document=20 > >>>>mentions 2 options in section 3.4.3: > >>>> > >>>>--- > >>>> o The AN keeps track of when replication starts or stops, and > >>>> generates the time and/or volume based accounting > >> > >>information > >> > >>>>per > >>>> Access Loop and per multicast flow, before sending it to a=20 > >>>>central > >>>> accounting system for logging. Since the AN > >> > >>communicates with > >> > >>>> this accounting system directly, the approach > >> > >>doesn't require > >> > >>>>the > >>>> use of ANCP. It is therefore beyond the scope of this=20 > >>>>document; > >>>> > >>>> o The AN keeps track of when replication starts or stops, and > >>>> reports this information to the NAS for further > >> > >>processing. In > >> > >>>> this case, ANCP can be used to send the information > >> > >>from the AN > >> > >>>>to > >>>> the NAS. This can be done with the Information > >> > >>Report message. > >> > >>>> The NAS can then generate the appropriate time and/or volume > >>>> accounting information per Access Loop and per > >> > >>multicast flow, > >> > >>>>to > >>>> be sent to the accounting system. The ANCP requirements to > >>>> support this approach are specified in this document. > >>>>--- > >>>> > >>>>Is everyone Ok with this? Is more needed, or less, or more=20 > >>>>clarrification on what it means? > >>>> > >>>>Personally, it looks Ok to me but I have a comment for extra=20 > >>>>clarrification on the first bullet: Does it require any > >> > >>impact on the > >> > >>>>ANCP protocol? For the second bullet, I would expect that > >> > >>in a white > >> > >>>>list entry there is a flag indicating whether accounting is > >> > >>needed or > >> > >>>>not. Is something similar needed to support the first=20 > bullet in a=20 > >>>>white list entry (e.g., need for time and/or volume based > >> > >>accounting > >> > >>>>with the IP address of acct server)? Whatever is fine for > >> > >>me, but it > >> > >>>>has to be decided. > >>>> > >>>>regards, > >>>>Stefaan > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>ANCP mailing list > >>>>ANCP@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/ancp > >>> > >>> > >> > >>_______________________________________________ > >>ANCP mailing list > >>ANCP@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 14 10:43:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JERTH-0004W1-J6; Mon, 14 Jan 2008 10:43:31 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JERTG-0004Vl-Ds for ancp-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 10:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JERTG-0004Vd-48 for ancp@ietf.org; Mon, 14 Jan 2008 10:43:30 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JERTF-0006NP-Aq for ancp@ietf.org; Mon, 14 Jan 2008 10:43:30 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0EFaXES014145; Mon, 14 Jan 2008 16:36:57 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Jan 2008 16:42:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast BW Admission Control Date: Mon, 14 Jan 2008 16:42:43 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E380025FE55D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast BW Admission Control Thread-Index: AchWpdcE7o7GsCbXR9ykfXduzgw/HQAHaGgA References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 14 Jan 2008 15:42:45.0289 (UTC) FILETIME=[1B5FA190:01C856C4] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Francois, see inline.=20 Regards, Sven -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: maandag 14 januari 2008 13:06 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; ancp@ietf.org Subject: Re: [ANCP] Multicast BW Admission Control Hi Sven, Thanks for the clarification. The approach you describe below seems fine to me. I think the key point it brings is to clarify that it it can make sense to perform CAC on some flows and not on others (and the non- CACed flows will not break the CACed flows). Yes, I agree with this One small point. When you say "the NAS must make sure that the multicast content is marked as best-effort", I wasn't sure if you implied that the NAS would remark the flow. While that may be an option, a more common case if probably that the flow got marked best- effort somewhere upstream (eg when flow enters the SP network). I think it would be worth clarifying. Correct, this is what I meant. In my rationale the NAS was the entry point of the service provider network. But indeed, that may well be another node Also, I would suggest that the text uses "Internet/Unkown" channels just as an example of where this sort of approach may be used, but make it clear it is a generic capability (e.g. the best-effort approach can be used on known flows also). I am working on an updated framework version, which will include the above notion for both known and unknown streams. Cheers Francois On 8 Jan 2008, at 16:02, OOGHE Sven wrote: > Hi, > > In the Vancouver meeting minutes there is mention about multicast=20 > bandwidth admission control, and what to do with "best effort" > streams. > Apparently there is some confusion on the concept. This email is the=20 > clarify my view on this. > > As already described in section 3.4.2, there is a need - next to=20 > policy based admission control - to perform CAC for the video content=20 > being streamed across the access network. The different options to do=20 > so are already defined in the framework document. > > Now, the point I wanted to bring up is that in general, the Access=20 > Node and NAS cannot be aware of all possible multicast groups. It is=20 > likely that there may be multicast channels offered across the=20 > Internet. For these streams, performing bandwidth admission control=20 > may be challenging. > > To solve this, these requests should by default be accepted, but the=20 > network should handle the traffic as best effort. This can be done by=20 > first of all adding a "catch-all statement" in the Access Node white=20 > list or grey list. In case the Access Node queries the NAS, the NAS on > his turn will have to accept the request. That way, the unknown=20 > streams are not blocked by default. Next, the NAS must make sure that=20 > the multicast content coming from the Internet is marked as best=20 > effort traffic. This way, whenever congestion occurs somewhere in the=20 > access/aggregation network, this stream will be kicked out before the=20 > access provider's own premium content. > > If people agree with this, I suggest to add the above discussion to=20 > the framework document. > > Regards, > Sven > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jan 15 08:31:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElt7-0008PW-HQ; Tue, 15 Jan 2008 08:31:33 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JElt6-0008PK-7x for ancp-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 08:31:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElt5-0008Ln-Pn for ancp@ietf.org; Tue, 15 Jan 2008 08:31:31 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JElt4-00029P-Vx for ancp@ietf.org; Tue, 15 Jan 2008 08:31:31 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0FDPF4Z020574; Tue, 15 Jan 2008 14:25:17 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jan 2008 14:31:18 +0100 Message-ID: <478CB5A6.2040803@alcatel-lucent.be> Date: Tue, 15 Jan 2008 14:31:18 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Le Faucheur IMAP , OOGHE Sven Subject: Re: [ANCP] Multicast BW Admission Control References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> In-Reply-To: <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2008 13:31:18.0970 (UTC) FILETIME=[E92C99A0:01C8577A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Sven, Francois, see below... Francois Le Faucheur IMAP wrote: > Hi Sven, > > Thanks for the clarification. > The approach you describe below seems fine to me. > I think the key point it brings is to clarify that it it can make sense > to perform CAC on some flows and not on others (and the non- CACed flows > will not break the CACed flows). > How do I have interprete this CAC? From the email discussion I understand that the AN will not do any CAC on joins not matching with any white/grey/black list, assuming that this is an Internet multicast flow marked as best effort somewhere by an edge router. Then I understand that when the join matches a grey list, then all checks including the bandwidth CAC checks are perfomed in the NAS, and when it matches a white list, the NAS is not queried and hence the AN is doing all the checks. This is then done without querying the NAS, but still under control by the NAS, i.e., the NAS configures the AN via ANCP such that the AN can do all the checks. The latter means that the NAS must provision the AN with the necessary information to let the AN to make the decisions: in a white list the NAS configures the multicast groups (with masks), sources, bandwidth, and possibly other information (e.g., related to accounting). If this is what we all understand, then it looks good. regards, Stefaan > One small point. When you say "the NAS must make sure that the > multicast content is marked as best-effort", I wasn't sure if you > implied that the NAS would remark the flow. While that may be an > option, a more common case if probably that the flow got marked best- > effort somewhere upstream (eg when flow enters the SP network). I think > it would be worth clarifying. > > Also, I would suggest that the text uses "Internet/Unkown" channels > just as an example of where this sort of approach may be used, but make > it clear it is a generic capability (e.g. the best-effort approach can > be used on known flows also). > > Cheers > > Francois > > On 8 Jan 2008, at 16:02, OOGHE Sven wrote: > >> Hi, >> >> In the Vancouver meeting minutes there is mention about multicast >> bandwidth admission control, and what to do with "best effort" streams. >> Apparently there is some confusion on the concept. This email is the >> clarify my view on this. >> >> As already described in section 3.4.2, there is a need - next to policy >> based admission control - to perform CAC for the video content being >> streamed across the access network. The different options to do so are >> already defined in the framework document. >> >> Now, the point I wanted to bring up is that in general, the Access Node >> and NAS cannot be aware of all possible multicast groups. It is likely >> that there may be multicast channels offered across the Internet. For >> these streams, performing bandwidth admission control may be >> challenging. >> >> To solve this, these requests should by default be accepted, but the >> network should handle the traffic as best effort. This can be done by >> first of all adding a "catch-all statement" in the Access Node white >> list or grey list. In case the Access Node queries the NAS, the NAS on >> his turn will have to accept the request. That way, the unknown streams >> are not blocked by default. Next, the NAS must make sure that the >> multicast content coming from the Internet is marked as best effort >> traffic. This way, whenever congestion occurs somewhere in the >> access/aggregation network, this stream will be kicked out before the >> access provider's own premium content. >> >> If people agree with this, I suggest to add the above discussion to the >> framework document. >> >> Regards, >> Sven >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 16 02:32:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF2l8-0007KS-D5; Wed, 16 Jan 2008 02:32:26 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JF2l7-0007Jk-EY for ancp-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 02:32:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF2l7-0007JZ-3T for ancp@ietf.org; Wed, 16 Jan 2008 02:32:25 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF2l4-00078C-M2 for ancp@ietf.org; Wed, 16 Jan 2008 02:32:25 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 16 Jan 2008 08:32:20 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 08:32:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] Depreciation of TLVs ... again Date: Wed, 16 Jan 2008 08:32:19 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C106738@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47823C09.4060709@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Depreciation of TLVs ... again thread-index: AchRPLarKi8+RY7iQluEMuuoWLb32gG0+1XQ From: "Busser, M" To: , X-OriginalArrivalTime: 16 Jan 2008 07:32:20.0259 (UTC) FILETIME=[ED83DF30:01C85811] X-Spam-Score: -1.0 (-) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org All. I fully agree with Stefaan. We can not assume 1a, so i am aganinst it. I also think, that TLV Type 0x02 is not that important. It is also an = optional TLV.=20 So ignoring it for a while at the NAS as Stefaan suggests is an = acceptable solution for me. It it also not used by RAM or OAM at the moment (as far as I know), so = we shouldn't have problems with that. With subTLV 0x90 renumbered to 0x91, we can proceed as follows:=20 Lets assume, we have a AN running with an "old" version of the draft = (e.g. Dec. 2005).=20 Those systems will never send a subTLV 0x91. If the NAS receives a = subTLV 0x90,=20 it should interpret this subTLV as DSL-Type. If we have a AN running a later version of the draft, the NAS will at = least receive a=20 subTLV 0x91 because this is mandatory. It may also receive a subTLV = 0x90, wich is optional.=20 In this case, the NAS should interpret 0x90 as Access-Loop-Encapsulation = and 0x91 as DSL-Type. The only thing, we have to take care of is that the NAS have to be = updated to this behaviour first.=20 After that, the AN vendors can change their implementations whenever the = want. I also agree with Stefaan, that we schould describe this in detail in an = appendix.=20 The other changes we made, concerns the length of some parameters. This = can be solved by the AN vendors,=20 as long as we have different implementations at the NAS side in that = specific detail. This is actually already the case as far as i know. I think, 1b is the way to go. Some other useful information for a "known caveats" appendix: OAM-Loopback-Test-Parameter=3D0x07 The length of the parameter has changed from 8 to 4 bytes. Depending on the implementation at the NAS, a AN can receive the = OAM-Loopback-Test-Parameter with length=3D8 as well as with length=3D4 = byte. AN vendors should take this into account. The other way of course is to have a kind of a version number wich is = our preference. But even if the group decide to have an ANCP version number, we need an agreement, how to proceed from the actually running implementations.=20 Best Regards Michael Busser T-Systems Enterprise Services GmbH Systems Integration=20 =20 -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Gesendet: Montag, 7. Januar 2008 15:50 An: Wojciech Dec (wdec) Cc: ancp@ietf.org Betreff: Re: [ANCP] Depreciation of TLVs ... again Woj, Let's say that I am against 1a. It also requires that all ANs and all=20 NASes are upgraded at the same time which is unlikely. It depends on which node is typically upgraded first. Are ISPs first=20 upgrading the NAS or first the AN? I would expect first the NAS. If=20 that's true, then it looks to me that it should be like this: If I see correctly "PORT-UP message TLV Type 0x02" changed meaning and=20 the original data that was in TLV 0x02 is now in 0x06. However, this is = an optional TLV and does not look that important, and to avoid interop=20 problems, a NAS should not interprete TLV 0x02 "for some time", except=20 in displaying this information or other things that does not break the=20 correct operation of ANCP. This until we are sure that there are no=20 implementations that use the old spec. This should be described in an=20 appendix of the draft. subTLV 0x90 is renumbered to 0x91. Here the BRAS should, to avoid=20 interop problems, interprete both 0x90 and 0x91 in the same way. If=20 both are there, then only 0x91 should be interpreted. Also this should=20 be described clearly in the appendix. In the future it would be better that the numbering is kept as it is.=20 For instance, for TLV 0x02 it should never have been moved to 0x06 and=20 then using 0x02 for something else... This could have been avoided, but = if it cannot be avoided, then it should be described explicetely in the=20 appendix. regards, Stefaan Wojciech Dec (wdec) wrote: > Stefaan, are you behind option 1b then? >=20 > The case if currently for : >=20 > PORT-UP message TLV Type 0x02 > PORT-UP message TLV 0x04 sub-TLV 0x90 >=20 > Both of which I beleive are currenly implemented (based on the=20 > conflicting definition in draft-wadhwa-00). >=20 > BTW. I naturally meant depricate not depreciate ;-) >=20 > -Woj. > =20 >=20 >=20 >>-----Original Message----- >>From: Stefaan DE CNODDER >>[mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 >>Sent: 07 January 2008 15:07 >>To: Wojciech Dec (wdec) >>Cc: ancp@ietf.org >>Subject: Re: [ANCP] Depreciation of TLVs ... again >> >> >> >> >>>1a. Do not depreciate TLVs, and assume that all implementations and >>>users will follow the latest ANCP draft (i.e. assume that=20 >> >>draft-l2cp >> >>>problems never happened). >> >>You cannot assume that. >> >> >>>1b. Do not depreciate TLVs, but introduce a "known caveats" in the >>>appendix of the protocol draft, describing the potential legacy=20 >>>implementation interoperability problem. >> >>Important changes that may lead to interop issues when >>implementations implement different versions of the same=20 >>draft should be documented properly in the appendix. But=20 >>this should be avoided as much as possible... Maybe it=20 >>should be looked at case by case. If a number changes of a=20 >>TLV that is not important, then it will not harm a lot, but=20 >>if it happens to important TLVs like the ones carrying=20 >>bandwidth or ACIs, then it should be avoided and if not=20 >>possible to avoid, describe it very well in the appendix. >> >>regards, >>Stefaan >> >> >> >>>2. Depreciate TLVs. >>> >>>Now, given that option 2 appears to have just recently been >> >>presented >> >>>with a reasonable argument against it (see Vancouver >> >>minutes below), I >> >>>call for the WG to decide on 1a or 1b. >>> >>>Some background: >>> >>>The problem was introduced in edits made between pre-ANCP >> >>WG drafts to >> >>>draft-wadhwa-gsmp-l2control-configuration-00. >>>Version 00 of this draft dated August 2, 2005 saw the >> >>PORT-UP message >> >>>TLV 0x02 assigned to >> >>"Access-Aggregation-Circuit-ID-Binary". The next >> >>>version 01, dated September 2006, saw the same TLV assigned to >>>"Access-Loop-Remote-Id". >>>A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw=20 >>>it's meaning changed between drafts. The ANCP protocol draft is=20 >>>derived from the 01 version. >>> >>>It so happens however that most known implementations are >> >>based on the >> >>>00 draft, which presents an interoperability problem to anyone who >>>implemented the 00 definition and those that implement the=20 >> >>latest ANCP >> >>>draft. Hacks aside, a long term fix needs to be devised. >>>NOTE: There is no known way to distinguish l2cp draft 00, >> >>01 or ANCP >> >>>draft speakers other than trough hacks, which current 00 >>>implementations are known to have adopted as a "workaround"=20 >> >>to *ONE* of the problem. >> >>>Now the original proposal of a solution was drafted in >>> >> >>http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and >> >>>the WG provided no objections. Furthermore the topic was also >>>discussed during IETF 69 back in March 2007 (minutes here: >>>http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html).=20 >> >>Again no >> >>>objections were raised by any of the WG participants. >>>Hence the decision to *depreciate* conflicting TLVs was previously >>>made by the WG (and claims of this being otherwise are removed from=20 >>>the truth). >>> >>>=20 >>>---snip--- >>>=20 >>> ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net)=20 >>>http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 >>> >>>Discuss protocol draft updates and ANCP graceful restart. >>>---------------------------------------------------------- >>>consistency with framework >>>new section 2.1 on terminology >>>net data rate used >>>new multipair bonding text >>>text for topology discovery extensions 5.4.2 clarified=20 >> >>message format >> >>>in line configuration extension, section 5.4.3 concern over tlv >>>changes, diverges from tr-101 and rfc 4679 in TLV#. >>>Common notion is for BRAS to pass TLV transparently into Radius.=20 >>>Changes held back. Doesn't see issue as colliding values have been=20 >>>changed previously. >>> >>> access loop remote id and sub tlv access loop encapsulation=20 >>> suggest not deprecate these tlvs, keep them alive=20 >>> Peter, why did Woj want this deprecated, agrees that >> >>these shouldn't >> >>>be deprecated. >>> Sanjay, reason was to depreciate to avoid overlap, but >> >>ROI is small >> >>>in this case. >>> graceful restart draft updated, support for multicast use cased >>>agreed upon by the WG. >>> Matthew, should graceful restart be a separate draft=20 >> >>going forward, >> >>>Sanjay agreed >>> Matthew, graceful restart not on charter, need to add >> >>to milestones >> >>>---snip-- >>> >>>Regards, >>>Woj. >>> >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ancp >> >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 16 10:20:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA3o-0005pT-ER; Wed, 16 Jan 2008 10:20:12 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFA3n-0005o1-8C for ancp-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA3m-0005ls-JF for ancp@ietf.org; Wed, 16 Jan 2008 10:20:10 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFA3k-0000Nu-QA for ancp@ietf.org; Wed, 16 Jan 2008 10:20:10 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2008 07:20:08 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0GFK80V031954; Wed, 16 Jan 2008 07:20:08 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GFK7nj024974; Wed, 16 Jan 2008 15:20:07 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA13708; Wed, 16 Jan 2008 07:18:05 -0800 (PST) Date: Wed, 16 Jan 2008 07:18:05 -0800 From: Toerless Eckert To: Stefaan DE CNODDER Subject: Re: [ANCP] Multicast BW Admission Control Message-ID: <20080116151805.GJ14463@cisco.com> References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> <478CB5A6.2040803@alcatel-lucent.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478CB5A6.2040803@alcatel-lucent.be> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7140; t=1200496808; x=1201360808; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[ANCP]=20Multicast=20BW=20Admission=20C ontrol |Sender:=20; bh=2QBvYB9y/n9vOo14mXSbUIvXfJnx1gr6mfeiVYuCPR8=; b=vBqSc9AmDKIueN0Ao5lxbAxSWz9Ybnh+olXOc1utDYoxh+pFEH2fYwCoD+ kRWOEsLxIH/owYiSzNVWkO2MRbfBF+kY6YsA5XNTNXTDUEK4SLhDRc7Zm5PM LyEuqmI1bc; Authentication-Results: sj-dkim-3; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: OOGHE Sven , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Stefann, I am a bit confused about the Cc'ed and your prior mail, because i think they contradict each other. Aka: a) In the first mail i thought to understood that you wanted a usage case of internet video for which no admission control is done, and because there may be other video traffic for which admission control IS done, the idea is to have the non-CACed video use simply "best-effort" DSCP marking. Correct ? So, then i conclude that I) this "intern video" traffic would somehow get DSCP best-effort marked. We can probably keep the whee and why of that marking outside of the scope of ANCP, even if it happens (orthogonal to ANCP) in the NAS. Correct ? II) To make sure that this best-effort traffic would not cause congestion/packet-loss of actually admission controlled video, the AN would need to support well enough some form of DSCP-class based queuing, by which some part of the bandwidth is prioritized for DSCP-video-class traffic, which is the class for which ANCP would also do admission control, eg: via grey-list. The best-effort-DSCP video traffic might use this bandwidth, but only when no DSCP-video-class traffic needs it. Correct ? Which of these AN side queuing behavior do you think should be documented by ANCP ? III) The way that ANCP would cope withsuch trafic that wouldnot be subject to it's admission control would as far as i understand it best be to just whitelist it. So the "internet-video" with DSCP-best-effort would be part of the whitelist. In addition, if we feel that such "internet-video" traffic might have "unpredictable" addresses, then one might want to have matching against whitelist be done by default, but if the adress of a channel matches tthe greylist, then that greylist should trace precedence. Correct ? b) Now, in your second mail, you indicate that the NAS should provide to the AN per-flow bandwidth information, such that the AN can do add up on it's own bandwidth of flows to make admission control decisions. This seems to be a diffeent approach to what i thought was expressed by the first mail. Can you calrify ?? Thanks Toerless P.S.: just returning from longer vacations, so i may be more confused than usual ;-)) On Tue, Jan 15, 2008 at 02:31:18PM +0100, Stefaan DE CNODDER wrote: > > Hi Sven, Francois, > > see below... > > Francois Le Faucheur IMAP wrote: > > >Hi Sven, > > > >Thanks for the clarification. > >The approach you describe below seems fine to me. > >I think the key point it brings is to clarify that it it can make sense > >to perform CAC on some flows and not on others (and the non- CACed flows > >will not break the CACed flows). > > > > How do I have interprete this CAC? From the email discussion I > understand that the AN will not do any CAC on joins not matching with > any white/grey/black list, assuming that this is an Internet multicast > flow marked as best effort somewhere by an edge router. Then I > understand that when the join matches a grey list, then all checks > including the bandwidth CAC checks are perfomed in the NAS, and when it > matches a white list, the NAS is not queried and hence the AN is doing > all the checks. This is then done without querying the NAS, but still > under control by the NAS, i.e., the NAS configures the AN via ANCP such > that the AN can do all the checks. The latter means that the NAS must > provision the AN with the necessary information to let the AN to make > the decisions: in a white list the NAS configures the multicast groups > (with masks), sources, bandwidth, and possibly other information (e.g., > related to accounting). > > If this is what we all understand, then it looks good. > > regards, > Stefaan > > > >One small point. When you say "the NAS must make sure that the > >multicast content is marked as best-effort", I wasn't sure if you > >implied that the NAS would remark the flow. While that may be an > >option, a more common case if probably that the flow got marked best- > >effort somewhere upstream (eg when flow enters the SP network). I think > >it would be worth clarifying. > > > >Also, I would suggest that the text uses "Internet/Unkown" channels > >just as an example of where this sort of approach may be used, but make > >it clear it is a generic capability (e.g. the best-effort approach can > >be used on known flows also). > > > >Cheers > > > >Francois > > > >On 8 Jan 2008, at 16:02, OOGHE Sven wrote: > > > >>Hi, > >> > >>In the Vancouver meeting minutes there is mention about multicast > >>bandwidth admission control, and what to do with "best effort" streams. > >>Apparently there is some confusion on the concept. This email is the > >>clarify my view on this. > >> > >>As already described in section 3.4.2, there is a need - next to policy > >>based admission control - to perform CAC for the video content being > >>streamed across the access network. The different options to do so are > >>already defined in the framework document. > >> > >>Now, the point I wanted to bring up is that in general, the Access Node > >>and NAS cannot be aware of all possible multicast groups. It is likely > >>that there may be multicast channels offered across the Internet. For > >>these streams, performing bandwidth admission control may be > >>challenging. > >> > >>To solve this, these requests should by default be accepted, but the > >>network should handle the traffic as best effort. This can be done by > >>first of all adding a "catch-all statement" in the Access Node white > >>list or grey list. In case the Access Node queries the NAS, the NAS on > >>his turn will have to accept the request. That way, the unknown streams > >>are not blocked by default. Next, the NAS must make sure that the > >>multicast content coming from the Internet is marked as best effort > >>traffic. This way, whenever congestion occurs somewhere in the > >>access/aggregation network, this stream will be kicked out before the > >>access provider's own premium content. > >> > >>If people agree with this, I suggest to add the above discussion to the > >>framework document. > >> > >>Regards, > >>Sven > >> > >> > >>_______________________________________________ > >>ANCP mailing list > >>ANCP@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ancp > > > > > > > > > >_______________________________________________ > >ANCP mailing list > >ANCP@ietf.org > >https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture "The strategy is what you do, not what you write" - Wesley Clark _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 16 10:21:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA4c-0001Mm-3K; Wed, 16 Jan 2008 10:21:02 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFA4b-0001Mh-HK for ancp-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:21:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA4b-0001MT-4a for ancp@ietf.org; Wed, 16 Jan 2008 10:21:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFA4Z-0005uV-UF for ancp@ietf.org; Wed, 16 Jan 2008 10:21:01 -0500 X-IronPort-AV: E=Sophos;i="4.24,293,1196636400"; d="scan'208";a="3175898" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jan 2008 16:20:59 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GFKxSd005632; Wed, 16 Jan 2008 16:20:59 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GFKhgq002884; Wed, 16 Jan 2008 15:20:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 16:20:52 +0100 Received: from [144.254.53.136] ([144.254.53.136]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 16:20:48 +0100 In-Reply-To: <478B6A08.1020508@alcatel-lucent.be> References: <478376EC.6060404@alcatel-lucent.be> <478B5CDC.3070303@alcatel-lucent.be> <478B6A08.1020508@alcatel-lucent.be> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Multicast Accounting Date: Wed, 16 Jan 2008 16:20:43 +0100 To: Stefaan DE CNODDER X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 16 Jan 2008 15:20:48.0900 (UTC) FILETIME=[5F921C40:01C85853] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9257; t=1200496859; x=1201360859; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Multicast=20Accounting |Sender:=20; bh=o9zpwI9kBKAFLMFR7GhxorzndCoUKLY/Dy+VC0tiSpU=; b=E5vVK+PPHNuMOrpF/p9n4cBMptudooTgpjgYHEh99vlQ8yqDZY8a9h3qZT qhp3IkoZ6F3hffSeWXeVe4Jlm2RKN8l3HRndalGLtqd9uBFtZ+2Xb721Yh3U fMJEa48Yed; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Stefaan, I have trouble parsing the message below (eg when you say "if we believe that the comment below was on the wrong bullet, then it is all Ok."). So, let's break it into separate bits: 1) 2nd bullet: Accounting done by AN and reported to NAS (excluding the question of volume accounting done on AN) ======================================================================== ================ Leaving aside the question of whether the AN is to perform volume accounting itself or not, could you identify if you see any specific issues with proposal in : >>> http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. and if needed propose changes? 2) 2nd bullet: Accounting done by AN and reported to NAS (the question of volume accounting done on AN) ======================================================================== ================ Focusing on the question of whether the AN is to perform volume accounting itself or not. I think you're saying that we know of some ANs that are not capable of performing such volume accounting so we can not just assume this capability always exist. That's a valid point. So ANCP needs to support the model where volume accounting is done on NAS. Now, is it likely that some ANs would support such capability today or in the future? If yes, perhaps ANCP should also support that model, no? I think you mentioned something about DSL Forum position on that in Vancouver. Could you summarize DSL Forum position on this? 3) 1st bullet: Accounting done by AN and reported directly to Server ================================================= I think you suggest we could remove this as it does not affect ANCP. I don't have a strong view. I lean towards keeping it in because it because it does clarify where ANCP plays and doesn't play. Francois On 14 Jan 2008, at 14:56, Stefaan DE CNODDER wrote: > > Woj, > > From a functional point of view it is Ok but the comment was to > change the second bullet of section 3.4.3 into what is already in > the first bullet of section 3.4.3 (although there it is generalised > that the AN can send this info to any acct server and not just the > NAS). > > My question is whether we can remove the first bullet. If the AN > has to do the multicast accounting, then it can also do the unicast > accounting and I thought ANCP was about moving all of this to the > NAS. And if the AN can do the unicast accounting, then it can do > the appropriate QoS queueing as well.... Anyhow, I am fine with > the current text in the framework and if we believe that the > comment below was on the wrong bullet, then it is all Ok. > > I have more problems with the capabilities negotiated with ANCP. > Implementation will not support all or nothing but that is what is > negotiated in the capabilities. Have the capabilities to be more > fine-grained or should support/non-support be reflected in error > codes? > > regards, > Stefaan > > > Wojciech Dec (wdec) wrote: > >> Stefaan, >> then you're saying that you agree with Francois' proposal for Section >> 3.4.3? >> -Woj. >>> -----Original Message----- >>> From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel- >>> lucent.be] Sent: 14 January 2008 14:00 >>> To: Wojciech Dec (wdec) >>> Cc: ancp@ietf.org >>> Subject: Re: [ANCP] Multicast Accounting >>> >>> >>> Woj, >>> >>> The framework draft currently does not exclude anything. Both >>> options are possible. The case where the AN is counting the >>> packets and measuring the time is also in the framework and this >>> information can be sent directly from the AN to the accounting >>> server (which might be the NAS itself of course) with another >>> protocol than ANCP like Radius for instance. Actually, section >>> 3.4.3 has to be read as whole and not just the part I copy/pasted >>> in the email. The question is basically if this section is Ok >>> for everyone. >>> >>> From a protocol point of view, this means that each entry in the >>> white list has the following information: indication whether >>> accounting is needed or not, and if needed, whehter the >>> accounting is performed by the NAS or by the AN. In the latter >>> case, also the IP address of the accounting servers are specified. >>> >>> regards, >>> Stefaan >>> >>> >>> Wojciech Dec (wdec) wrote: >>> >>>> Hi Stefaan, >>>> >>>> it doesn't seem that we have agreement on this text, and an >>>> alternative proposal is presented in http://www1.ietf.org/mail- >>>> archive/web/ancp/current/msg00408.html. >>>> >>>> ---snip--- >>>> in Section "3.4.3 Multicast Accounting" >>>> >>>> >>>> replace: >>>> " >>>> o The AN keeps track of when replication starts or stops, >>> >>> and reports >>>> this information to the NAS for further processing. In this >>> >>> case, ANCP >>>> can be used to send the information from the AN to the NAS. >>> >>> This can >>>> be done with the Information Report message. >>>> The NAS can then generate the appropriate time and/or volume >>>> accounting information per Access Loop and per multicast >>> >>> flow, to be >>>> sent to the accounting system. The ANCP requirements to >>> >>> support this >>>> approach are specified in this document. >>>> " >>>> by >>>> " >>>> o The AN keeps track of when replication for a given multicast >>>> flow starts or stops and then the AN can convey time and/or >>>> volume information to the NAS for further processing. This >>> >>> approach relies on >>>> ANCP and is discussed below. >>>> >>>> ---snip--- >>>> >>>> In general for accounting to be of use it needs to be >>> >>> fairly accurate, >>>> hence it is highly desirable for the access node to present >>> >>> to the NAS >>>> the time and/or volume information for further processing. >>>> Granted that if access nodes are not capable of providing such >>>> information, they will only signal simple start/stop events. I >>>> however don't see why the framework and protocol should be >>>> limited only to >>> >>> this latter >>>> variant. Is there a reason why the proposal presented by >>> >>> Francois is inadequate? >>> >>>> Regards, >>>> Woj. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stefaan DE CNODDER >>>>> [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>>>> Sent: 08 January 2008 14:13 >>>>> To: ancp@ietf.org >>>>> Subject: [ANCP] Multicast Accounting >>>>> >>>>> >>>>> Hi, >>>>> >>>>> At the last IETF meeting, there was a discussion about >>>>> multicast accounting is supposed to work. Currently, the >>>>> framework document mentions 2 options in section 3.4.3: >>>>> >>>>> --- >>>>> o The AN keeps track of when replication starts or stops, and >>>>> generates the time and/or volume based accounting >>> >>> information >>>>> per >>>>> Access Loop and per multicast flow, before sending it to a >>>>> central >>>>> accounting system for logging. Since the AN >>> >>> communicates with >>> >>>>> this accounting system directly, the approach >>> >>> doesn't require >>>>> the >>>>> use of ANCP. It is therefore beyond the scope of this >>>>> document; >>>>> >>>>> o The AN keeps track of when replication starts or stops, and >>>>> reports this information to the NAS for further >>> >>> processing. In >>> >>>>> this case, ANCP can be used to send the information >>> >>> from the AN >>>>> to >>>>> the NAS. This can be done with the Information >>> >>> Report message. >>> >>>>> The NAS can then generate the appropriate time and/or volume >>>>> accounting information per Access Loop and per >>> >>> multicast flow, >>>>> to >>>>> be sent to the accounting system. The ANCP requirements to >>>>> support this approach are specified in this document. >>>>> --- >>>>> >>>>> Is everyone Ok with this? Is more needed, or less, or more >>>>> clarrification on what it means? >>>>> >>>>> Personally, it looks Ok to me but I have a comment for extra >>>>> clarrification on the first bullet: Does it require any >>> >>> impact on the >>>>> ANCP protocol? For the second bullet, I would expect that >>> >>> in a white >>>>> list entry there is a flag indicating whether accounting is >>> >>> needed or >>>>> not. Is something similar needed to support the first bullet >>>>> in a white list entry (e.g., need for time and/or volume based >>> >>> accounting >>>>> with the IP address of acct server)? Whatever is fine for >>> >>> me, but it >>>>> has to be decided. >>>>> >>>>> regards, >>>>> Stefaan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> ANCP mailing list >>>>> ANCP@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ancp >>>> >>>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 16 14:17:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDlg-0005RA-2J; Wed, 16 Jan 2008 14:17:44 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFDle-0005R5-1S for ancp-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 14:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDld-0005Qx-HY for ancp@ietf.org; Wed, 16 Jan 2008 14:17:41 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFDlc-000714-BM for ancp@ietf.org; Wed, 16 Jan 2008 14:17:41 -0500 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0GJBEvU015309; Wed, 16 Jan 2008 20:11:14 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 16 Jan 2008 20:17:30 +0100 Message-ID: <478E584A.7090802@alcatel-lucent.be> Date: Wed, 16 Jan 2008 20:17:30 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toerless Eckert Subject: Re: [ANCP] Multicast BW Admission Control References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> <478CB5A6.2040803@alcatel-lucent.be> <20080116151805.GJ14463@cisco.com> In-Reply-To: <20080116151805.GJ14463@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 19:17:30.0840 (UTC) FILETIME=[70962D80:01C85874] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: OOGHE Sven , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Toerless, The confusion probably comes from the fact that 2 discussions are mixed: Initial question: what should the AN do when an IGMP join does not match any white/black/grey list? There the assumption is that such a join is for an unknown Internet video stream, which is best effort and also marked as best effort (using 802.1p bits is more appropriate than DSCP since the AN is a switch). Hence, the AN can accept this join without doing any further CAC. Note: since in any list you can configure a "catch-all" entry, we have a "configurable default" but also this needs a default. This discussion raised a second question on the need for CAC and how CAC should be done. There may also be a number of premium content channels that are offered by the service provider. The premium content channels will not be offered as best effort, and will require CAC to be performed. DSL lines are of limited bandwidth and CAC on such links is useful. Today, such CAC in performed by ANs and used by many service providers because it is an easy and simple solution. These premium channels may also be part of the white list, in particular the popular channels, and channels for which the authorization information is not changing frequently. The white list contains the multicast streams for which the AN can decide autonomously, and therefore, the AN also needs the information to do this. Therefore, just listing the multicast streams in the white list is just not sufficient and the AN needs the bandwidth in the white list as well. I feel there is a need to describe this into more detail in the framework document to make sure we understand all the same. Also, the explanation above also does not provide the whole story on CAC, and all details should be in the framework. Is this also your understanding because then we have to work on describing all the details. regards, Stefaan Toerless Eckert wrote: > Stefann, > > I am a bit confused about the Cc'ed and your prior mail, because i > think they contradict each other. Aka: > > a) In the first mail i thought to understood that you wanted a > usage case of internet video for which no admission control is done, > and because there may be other video traffic for which admission > control IS done, the idea is to have the non-CACed video use simply > "best-effort" DSCP marking. > > Correct ? > > So, then i conclude that > > I) this "intern video" traffic would somehow get DSCP best-effort > marked. We can probably keep the whee and why of that marking > outside of the scope of ANCP, even if it happens (orthogonal to ANCP) > in the NAS. Correct ? > > II) To make sure that this best-effort traffic would not cause > congestion/packet-loss of actually admission controlled video, > the AN would need to support well enough some form of DSCP-class > based queuing, by which some part of the bandwidth is prioritized > for DSCP-video-class traffic, which is the class for which ANCP > would also do admission control, eg: via grey-list. > The best-effort-DSCP video traffic might use this bandwidth, > but only when no DSCP-video-class traffic needs it. > > Correct ? Which of these AN side queuing behavior do you think > should be documented by ANCP ? > > III) The way that ANCP would cope withsuch trafic that wouldnot be > subject to it's admission control would as far as i understand > it best be to just whitelist it. So the "internet-video" with > DSCP-best-effort would be part of the whitelist. In addition, > if we feel that such "internet-video" traffic might have > "unpredictable" addresses, then one might want to have matching > against whitelist be done by default, but if the adress of > a channel matches tthe greylist, then that greylist should > trace precedence. > > Correct ? > > b) Now, in your second mail, you indicate that the NAS should provide > to the AN per-flow bandwidth information, such that the AN can do > add up on it's own bandwidth of flows to make admission control decisions. > This seems to be a diffeent approach to what i thought was expressed > by the first mail. > > Can you calrify ?? > > Thanks > Toerless > > P.S.: just returning from longer vacations, so i may be more confused than > usual ;-)) > > > On Tue, Jan 15, 2008 at 02:31:18PM +0100, Stefaan DE CNODDER wrote: > >>Hi Sven, Francois, >> >>see below... >> >>Francois Le Faucheur IMAP wrote: >> >> >>>Hi Sven, >>> >>>Thanks for the clarification. >>>The approach you describe below seems fine to me. >>>I think the key point it brings is to clarify that it it can make sense >>>to perform CAC on some flows and not on others (and the non- CACed flows >>>will not break the CACed flows). >>> >> >>How do I have interprete this CAC? From the email discussion I >>understand that the AN will not do any CAC on joins not matching with >>any white/grey/black list, assuming that this is an Internet multicast >>flow marked as best effort somewhere by an edge router. Then I >>understand that when the join matches a grey list, then all checks >>including the bandwidth CAC checks are perfomed in the NAS, and when it >>matches a white list, the NAS is not queried and hence the AN is doing >>all the checks. This is then done without querying the NAS, but still >>under control by the NAS, i.e., the NAS configures the AN via ANCP such >>that the AN can do all the checks. The latter means that the NAS must >>provision the AN with the necessary information to let the AN to make >>the decisions: in a white list the NAS configures the multicast groups >>(with masks), sources, bandwidth, and possibly other information (e.g., >>related to accounting). >> >>If this is what we all understand, then it looks good. >> >>regards, >>Stefaan >> >> >> >>>One small point. When you say "the NAS must make sure that the >>>multicast content is marked as best-effort", I wasn't sure if you >>>implied that the NAS would remark the flow. While that may be an >>>option, a more common case if probably that the flow got marked best- >>>effort somewhere upstream (eg when flow enters the SP network). I think >>>it would be worth clarifying. >>> >>>Also, I would suggest that the text uses "Internet/Unkown" channels >>>just as an example of where this sort of approach may be used, but make >>>it clear it is a generic capability (e.g. the best-effort approach can >>>be used on known flows also). >>> >>>Cheers >>> >>>Francois >>> >>>On 8 Jan 2008, at 16:02, OOGHE Sven wrote: >>> >>> >>>>Hi, >>>> >>>>In the Vancouver meeting minutes there is mention about multicast >>>>bandwidth admission control, and what to do with "best effort" streams. >>>>Apparently there is some confusion on the concept. This email is the >>>>clarify my view on this. >>>> >>>>As already described in section 3.4.2, there is a need - next to policy >>>>based admission control - to perform CAC for the video content being >>>>streamed across the access network. The different options to do so are >>>>already defined in the framework document. >>>> >>>>Now, the point I wanted to bring up is that in general, the Access Node >>>>and NAS cannot be aware of all possible multicast groups. It is likely >>>>that there may be multicast channels offered across the Internet. For >>>>these streams, performing bandwidth admission control may be >>>>challenging. >>>> >>>>To solve this, these requests should by default be accepted, but the >>>>network should handle the traffic as best effort. This can be done by >>>>first of all adding a "catch-all statement" in the Access Node white >>>>list or grey list. In case the Access Node queries the NAS, the NAS on >>>>his turn will have to accept the request. That way, the unknown streams >>>>are not blocked by default. Next, the NAS must make sure that the >>>>multicast content coming from the Internet is marked as best effort >>>>traffic. This way, whenever congestion occurs somewhere in the >>>>access/aggregation network, this stream will be kicked out before the >>>>access provider's own premium content. >>>> >>>>If people agree with this, I suggest to add the above discussion to the >>>>framework document. >>>> >>>>Regards, >>>>Sven >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ancp >>> >>> >>> >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ancp >> >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>https://www1.ietf.org/mailman/listinfo/ancp > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 17 04:00:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQba-0007pV-HV; Thu, 17 Jan 2008 04:00:10 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFQbZ-0007pC-4p for ancp-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 04:00:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQbY-0007p3-Ly for ancp@ietf.org; Thu, 17 Jan 2008 04:00:08 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFQbX-00068v-E5 for ancp@ietf.org; Thu, 17 Jan 2008 04:00:08 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUS00HMB6C5YF@lhrga01-in.huawei.com> for ancp@ietf.org; Thu, 17 Jan 2008 09:00:06 +0000 (GMT) Received: from jys3105121962 ([118.32.138.143]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUS00A5K6BX3S@lhrga01-in.huawei.com> for ancp@ietf.org; Thu, 17 Jan 2008 09:00:05 +0000 (GMT) Date: Thu, 17 Jan 2008 17:59:53 +0900 From: Tina TSOU Subject: Re: [ANCP] Unicast/Multicast BW Admission Control To: Stefaan DE CNODDER , Toerless Eckert Message-id: <019f01c858e7$5735ea60$7dd3a179@jys3105121962> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> <478CB5A6.2040803@alcatel-lucent.be> <20080116151805.GJ14463@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: ancp@ietf.org, OOGHE Sven X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi All, There are scenarios where AN is capable of doing unicast and multicast Admission Control for the access line. In these cases, 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. Current ANCP framework draft already mentions the described scenario proposing two possible approaches: 1. Policy Server querying the AN directly (the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document) 2. Policy Server querying the AN indirectly via the NAS. The second approach requires a control messages exchange between NAS and AN thus it could fit in the ANCP framework. For the purpose of flexibility and completeness we believe it would be worth to include this use case and the related requirements in the current ANCP framework draft. Please see the text proposal for the described use case and requirements below. Feedback and comments are welcome. Thanks and best regards, Tina and Roberta Section 3.4.2 Current text: "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." Adding: "In case the Policy Server queries the AN indirectly via the NAS this interaction can be handled as an ANCP transaction, in particular the Policy Server queries the NAS using a protocol that is out of scope of this document, then the NAS uses ANCP to query the AN specifying the Access-Loop-Circuit-ID and the required Bandwidth for the requested unicast flow. The AN on receiving the query from the NAS performs the Admission Control check and in turn responds indicating if this unicast VoD request needs to be accepted or denied. Protocol Requirements Section 4.2 The ANCP MUST allow the NAS to query the AN to request an admission decision for a unicast flow that will contend the bandwidth with the multicast streams for a particular Access Port. AN Requirements Section 4.7.6 Upon receiving a query from the NAS for a unicast flow (e.g. a Video on Demand session) request contending the bandwidth with the multicast streams for a particular Access Port, the AN MUST support using ANCP to reply to the NAS indicating whether the request is to be accepted or denied. NAS Requirements Section 4.8.6 Upon receiving a request for a unicast flow (e.g. a Video on Demand session) for a specific Access Port, from the Policy Server, the NAS MUST support using ANCP to query the AN to receive a response indicating whether this unicast flow is to be accepted or denied. ----- Original Message ----- From: "Toerless Eckert" To: "Stefaan DE CNODDER" Cc: "OOGHE Sven" ; Sent: Thursday, January 17, 2008 12:18 AM Subject: Re: [ANCP] Multicast BW Admission Control > Stefann, > > I am a bit confused about the Cc'ed and your prior mail, because i > think they contradict each other. Aka: > > a) In the first mail i thought to understood that you wanted a > usage case of internet video for which no admission control is done, > and because there may be other video traffic for which admission > control IS done, the idea is to have the non-CACed video use simply > "best-effort" DSCP marking. > > Correct ? > > So, then i conclude that > > I) this "intern video" traffic would somehow get DSCP best-effort > marked. We can probably keep the whee and why of that marking > outside of the scope of ANCP, even if it happens (orthogonal to > ANCP) > in the NAS. Correct ? > > II) To make sure that this best-effort traffic would not cause > congestion/packet-loss of actually admission controlled video, > the AN would need to support well enough some form of DSCP-class > based queuing, by which some part of the bandwidth is prioritized > for DSCP-video-class traffic, which is the class for which ANCP > would also do admission control, eg: via grey-list. > The best-effort-DSCP video traffic might use this bandwidth, > but only when no DSCP-video-class traffic needs it. > > Correct ? Which of these AN side queuing behavior do you think > should be documented by ANCP ? > > III) The way that ANCP would cope withsuch trafic that wouldnot be > subject to it's admission control would as far as i understand > it best be to just whitelist it. So the "internet-video" with > DSCP-best-effort would be part of the whitelist. In addition, > if we feel that such "internet-video" traffic might have > "unpredictable" addresses, then one might want to have matching > against whitelist be done by default, but if the adress of > a channel matches tthe greylist, then that greylist should > trace precedence. > > Correct ? > > b) Now, in your second mail, you indicate that the NAS should provide > to the AN per-flow bandwidth information, such that the AN can do > add up on it's own bandwidth of flows to make admission control > decisions. > This seems to be a diffeent approach to what i thought was expressed > by the first mail. > > Can you calrify ?? > > Thanks > Toerless > > P.S.: just returning from longer vacations, so i may be more confused than > usual ;-)) > > > On Tue, Jan 15, 2008 at 02:31:18PM +0100, Stefaan DE CNODDER wrote: >> >> Hi Sven, Francois, >> >> see below... >> >> Francois Le Faucheur IMAP wrote: >> >> >Hi Sven, >> > >> >Thanks for the clarification. >> >The approach you describe below seems fine to me. >> >I think the key point it brings is to clarify that it it can make sense >> >to perform CAC on some flows and not on others (and the non- CACed flows >> >will not break the CACed flows). >> > >> >> How do I have interprete this CAC? From the email discussion I >> understand that the AN will not do any CAC on joins not matching with >> any white/grey/black list, assuming that this is an Internet multicast >> flow marked as best effort somewhere by an edge router. Then I >> understand that when the join matches a grey list, then all checks >> including the bandwidth CAC checks are perfomed in the NAS, and when it >> matches a white list, the NAS is not queried and hence the AN is doing >> all the checks. This is then done without querying the NAS, but still >> under control by the NAS, i.e., the NAS configures the AN via ANCP such >> that the AN can do all the checks. The latter means that the NAS must >> provision the AN with the necessary information to let the AN to make >> the decisions: in a white list the NAS configures the multicast groups >> (with masks), sources, bandwidth, and possibly other information (e.g., >> related to accounting). >> >> If this is what we all understand, then it looks good. >> >> regards, >> Stefaan >> >> >> >One small point. When you say "the NAS must make sure that the >> >multicast content is marked as best-effort", I wasn't sure if you >> >implied that the NAS would remark the flow. While that may be an >> >option, a more common case if probably that the flow got marked best- >> >effort somewhere upstream (eg when flow enters the SP network). I think >> >it would be worth clarifying. >> > >> >Also, I would suggest that the text uses "Internet/Unkown" channels >> >just as an example of where this sort of approach may be used, but make >> >it clear it is a generic capability (e.g. the best-effort approach can >> >be used on known flows also). >> > >> >Cheers >> > >> >Francois >> > >> >On 8 Jan 2008, at 16:02, OOGHE Sven wrote: >> > >> >>Hi, >> >> >> >>In the Vancouver meeting minutes there is mention about multicast >> >>bandwidth admission control, and what to do with "best effort" >> >>streams. >> >>Apparently there is some confusion on the concept. This email is the >> >>clarify my view on this. >> >> >> >>As already described in section 3.4.2, there is a need - next to >> >>policy >> >>based admission control - to perform CAC for the video content being >> >>streamed across the access network. The different options to do so are >> >>already defined in the framework document. >> >> >> >>Now, the point I wanted to bring up is that in general, the Access >> >>Node >> >>and NAS cannot be aware of all possible multicast groups. It is likely >> >>that there may be multicast channels offered across the Internet. For >> >>these streams, performing bandwidth admission control may be >> >>challenging. >> >> >> >>To solve this, these requests should by default be accepted, but the >> >>network should handle the traffic as best effort. This can be done by >> >>first of all adding a "catch-all statement" in the Access Node white >> >>list or grey list. In case the Access Node queries the NAS, the NAS on >> >>his turn will have to accept the request. That way, the unknown >> >>streams >> >>are not blocked by default. Next, the NAS must make sure that the >> >>multicast content coming from the Internet is marked as best effort >> >>traffic. This way, whenever congestion occurs somewhere in the >> >>access/aggregation network, this stream will be kicked out before the >> >>access provider's own premium content. >> >> >> >>If people agree with this, I suggest to add the above discussion to >> >>the >> >>framework document. >> >> >> >>Regards, >> >>Sven >> >> >> >> >> >>_______________________________________________ >> >>ANCP mailing list >> >>ANCP@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/ancp >> > >> > >> > >> > >> >_______________________________________________ >> >ANCP mailing list >> >ANCP@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ancp >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > "The strategy is what you do, not what you write" - Wesley Clark > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 17 07:02:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTSM-0001Oh-Et; Thu, 17 Jan 2008 07:02:50 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFTSL-0001IW-S3 for ancp-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 07:02:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTSL-0001CF-A3 for ancp@ietf.org; Thu, 17 Jan 2008 07:02:49 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFTSJ-0003Qi-PS for ancp@ietf.org; Thu, 17 Jan 2008 07:02:49 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0HBtTXY031316; Thu, 17 Jan 2008 12:55:53 +0100 Received: from [172.31.131.65] ([172.31.131.65]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Jan 2008 13:02:17 +0100 Message-ID: <478F43C8.1000205@alcatel-lucent.be> Date: Thu, 17 Jan 2008 13:02:16 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tina TSOU Subject: Re: [ANCP] Unicast/Multicast BW Admission Control References: <2E17595838F96949AB1F0FD9A8EC5ED030C16D@FRVELSMBS14.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002565538@FRVELSMBS22.ad2.ad.alcatel.com> <3941D6FF-E201-490C-9E64-EB2E2593C00C@cisco.com> <478CB5A6.2040803@alcatel-lucent.be> <20080116151805.GJ14463@cisco.com> <019f01c858e7$5735ea60$7dd3a179@jys3105121962> In-Reply-To: <019f01c858e7$5735ea60$7dd3a179@jys3105121962> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2008 12:02:17.0399 (UTC) FILETIME=[CE2D0C70:01C85900] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: Toerless Eckert , ancp@ietf.org, OOGHE Sven X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Tina, That's indeed a good description of what we need. see below for more comments.... Tina TSOU wrote: > Hi All, > There are scenarios where AN is capable of doing unicast and > multicast Admission Control for the access line. In these cases, 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. If the AN is doing the CAC, it also need to have the information to do this CAC. So here the current proposal is that in case of a white list, the NAS adds the bandwidth information to the multicast stream, such that upon receiving a join that matches the white list, the AN can do all checks including bandwidth check. Something similar can be done for grey list. Is this also how you think about it? > Current ANCP framework draft already mentions the described scenario > proposing two possible approaches: > 1. Policy Server querying the AN directly (the approach doesn't require > the use of ANCP. It is therefore beyond the scope of this document) > 2. Policy Server querying the AN indirectly via the NAS. > Sounds good to me. A small question: for case 2 is it "MUST be ANCP", or "Can be any protocol like in 1 and ANCP is not excluded"? Thanks, Stefaan > The second approach requires a control messages exchange between NAS and > AN thus it could fit in the ANCP framework. For the purpose of > flexibility and completeness we believe it would be worth to include > this use case and the related requirements in the current ANCP framework > draft. > > Please see the text proposal for the described use case and requirements > below. > Feedback and comments are welcome. > > Thanks and best regards, > Tina and Roberta > > Section 3.4.2 > Current text: > "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." > > Adding: > > "In case the Policy Server queries the AN indirectly via the NAS this > interaction can be handled as an ANCP transaction, in particular the > Policy Server queries the NAS using a protocol that is out of scope of > this document, then the NAS uses ANCP to query the AN specifying the > Access-Loop-Circuit-ID and the required Bandwidth for the requested > unicast flow. The AN on receiving the query from the NAS performs the > Admission Control check and in turn responds indicating if this unicast > VoD request needs to be accepted or denied. > > Protocol Requirements > Section 4.2 > The ANCP MUST allow the NAS to query the AN to request an admission > decision for a unicast flow that will contend the bandwidth with the > multicast streams for a particular Access Port. > > AN Requirements > Section 4.7.6 > Upon receiving a query from the NAS for a unicast flow (e.g. a Video on > Demand session) request contending the bandwidth with the multicast > streams for a particular Access Port, the AN MUST support using ANCP to > reply to the NAS indicating whether the request is to be accepted or > denied. > > NAS Requirements > Section 4.8.6 > Upon receiving a request for a unicast flow (e.g. a Video on Demand > session) for a specific Access Port, from the Policy Server, the NAS > MUST support using ANCP to query the AN to receive a response indicating > whether this unicast flow is to be accepted or denied. > > > ----- Original Message ----- From: "Toerless Eckert" > To: "Stefaan DE CNODDER" > Cc: "OOGHE Sven" ; > Sent: Thursday, January 17, 2008 12:18 AM > Subject: Re: [ANCP] Multicast BW Admission Control > > >> Stefann, >> >> I am a bit confused about the Cc'ed and your prior mail, because i >> think they contradict each other. Aka: >> >> a) In the first mail i thought to understood that you wanted a >> usage case of internet video for which no admission control is done, >> and because there may be other video traffic for which admission >> control IS done, the idea is to have the non-CACed video use simply >> "best-effort" DSCP marking. >> >> Correct ? >> >> So, then i conclude that >> >> I) this "intern video" traffic would somehow get DSCP best-effort >> marked. We can probably keep the whee and why of that marking >> outside of the scope of ANCP, even if it happens (orthogonal to >> ANCP) >> in the NAS. Correct ? >> >> II) To make sure that this best-effort traffic would not cause >> congestion/packet-loss of actually admission controlled video, >> the AN would need to support well enough some form of DSCP-class >> based queuing, by which some part of the bandwidth is prioritized >> for DSCP-video-class traffic, which is the class for which ANCP >> would also do admission control, eg: via grey-list. >> The best-effort-DSCP video traffic might use this bandwidth, >> but only when no DSCP-video-class traffic needs it. >> >> Correct ? Which of these AN side queuing behavior do you think >> should be documented by ANCP ? >> >> III) The way that ANCP would cope withsuch trafic that wouldnot be >> subject to it's admission control would as far as i understand >> it best be to just whitelist it. So the "internet-video" with >> DSCP-best-effort would be part of the whitelist. In addition, >> if we feel that such "internet-video" traffic might have >> "unpredictable" addresses, then one might want to have matching >> against whitelist be done by default, but if the adress of >> a channel matches tthe greylist, then that greylist should >> trace precedence. >> >> Correct ? >> >> b) Now, in your second mail, you indicate that the NAS should provide >> to the AN per-flow bandwidth information, such that the AN can do >> add up on it's own bandwidth of flows to make admission control >> decisions. >> This seems to be a diffeent approach to what i thought was expressed >> by the first mail. >> >> Can you calrify ?? >> >> Thanks >> Toerless >> >> P.S.: just returning from longer vacations, so i may be more confused >> than >> usual ;-)) >> >> >> On Tue, Jan 15, 2008 at 02:31:18PM +0100, Stefaan DE CNODDER wrote: >> >>> >>> Hi Sven, Francois, >>> >>> see below... >>> >>> Francois Le Faucheur IMAP wrote: >>> >>> >Hi Sven, >>> > >>> >Thanks for the clarification. >>> >The approach you describe below seems fine to me. >>> >I think the key point it brings is to clarify that it it can make >>> sense >>> >to perform CAC on some flows and not on others (and the non- CACed >>> flows >>> >will not break the CACed flows). >>> > >>> >>> How do I have interprete this CAC? From the email discussion I >>> understand that the AN will not do any CAC on joins not matching with >>> any white/grey/black list, assuming that this is an Internet multicast >>> flow marked as best effort somewhere by an edge router. Then I >>> understand that when the join matches a grey list, then all checks >>> including the bandwidth CAC checks are perfomed in the NAS, and when it >>> matches a white list, the NAS is not queried and hence the AN is doing >>> all the checks. This is then done without querying the NAS, but still >>> under control by the NAS, i.e., the NAS configures the AN via ANCP such >>> that the AN can do all the checks. The latter means that the NAS must >>> provision the AN with the necessary information to let the AN to make >>> the decisions: in a white list the NAS configures the multicast groups >>> (with masks), sources, bandwidth, and possibly other information (e.g., >>> related to accounting). >>> >>> If this is what we all understand, then it looks good. >>> >>> regards, >>> Stefaan >>> >>> >>> >One small point. When you say "the NAS must make sure that the >>> >multicast content is marked as best-effort", I wasn't sure if you >>> >implied that the NAS would remark the flow. While that may be an >>> >option, a more common case if probably that the flow got marked best- >>> >effort somewhere upstream (eg when flow enters the SP network). I >>> think >>> >it would be worth clarifying. >>> > >>> >Also, I would suggest that the text uses "Internet/Unkown" channels >>> >just as an example of where this sort of approach may be used, but >>> make >>> >it clear it is a generic capability (e.g. the best-effort approach can >>> >be used on known flows also). >>> > >>> >Cheers >>> > >>> >Francois >>> > >>> >On 8 Jan 2008, at 16:02, OOGHE Sven wrote: >>> > >>> >>Hi, >>> >> >>> >>In the Vancouver meeting minutes there is mention about multicast >>> >>bandwidth admission control, and what to do with "best effort" >>> >>streams. >>> >>Apparently there is some confusion on the concept. This email is the >>> >>clarify my view on this. >>> >> >>> >>As already described in section 3.4.2, there is a need - next to >>> >>policy >>> >>based admission control - to perform CAC for the video content being >>> >>streamed across the access network. The different options to do so are >>> >>already defined in the framework document. >>> >> >>> >>Now, the point I wanted to bring up is that in general, the Access >>> >>Node >>> >>and NAS cannot be aware of all possible multicast groups. It is likely >>> >>that there may be multicast channels offered across the Internet. For >>> >>these streams, performing bandwidth admission control may be >>> >>challenging. >>> >> >>> >>To solve this, these requests should by default be accepted, but the >>> >>network should handle the traffic as best effort. This can be done by >>> >>first of all adding a "catch-all statement" in the Access Node white >>> >>list or grey list. In case the Access Node queries the NAS, the NAS on >>> >>his turn will have to accept the request. That way, the unknown >>> >>streams >>> >>are not blocked by default. Next, the NAS must make sure that the >>> >>multicast content coming from the Internet is marked as best effort >>> >>traffic. This way, whenever congestion occurs somewhere in the >>> >>access/aggregation network, this stream will be kicked out before the >>> >>access provider's own premium content. >>> >> >>> >>If people agree with this, I suggest to add the above discussion to >>> >>the >>> >>framework document. >>> >> >>> >>Regards, >>> >>Sven >>> >> >>> >> >>> >>_______________________________________________ >>> >>ANCP mailing list >>> >>ANCP@ietf.org >>> >>https://www1.ietf.org/mailman/listinfo/ancp >>> > >>> > >>> > >>> > >>> >_______________________________________________ >>> >ANCP mailing list >>> >ANCP@ietf.org >>> >https://www1.ietf.org/mailman/listinfo/ancp >>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp >> >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com >> Cisco NSSTG Systems & Technology Architecture >> "The strategy is what you do, not what you write" - Wesley Clark >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 17 08:02:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFUNm-00073n-AJ; Thu, 17 Jan 2008 08:02:10 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFUNk-0006vz-Hj for ancp-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 08:02:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFUNj-0006vc-G1 for ancp@ietf.org; Thu, 17 Jan 2008 08:02:07 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFUNi-0001tT-72 for ancp@ietf.org; Thu, 17 Jan 2008 08:02:07 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Thu, 17 Jan 2008 05:00:34 PST Received: from emailfeemea1.jnpr.net ([172.26.192.140]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jan 2008 05:01:20 -0800 Received: from emailemea5.jnpr.net ([172.26.192.134]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jan 2008 13:01:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast Accounting Date: Thu, 17 Jan 2008 12:53:29 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast Accounting Thread-Index: AchWtVjd9pqIhQ7VSFaPeTAJDQNqlQAAeY2AAJPJZUA= From: "Derek Harkness" To: "Wojciech Dec \(wdec\)" , "Stefaan DE CNODDER" X-OriginalArrivalTime: 17 Jan 2008 13:01:12.0434 (UTC) FILETIME=[09389520:01C85909] X-Spam-Score: -4.0 (----) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org I lost some of the the thread of the text alternatives, but can only absolutely agree on the black box principle - AN & NAS is one multicast node. - Does anyone forsee a use for only simple start/stop mcast ANCP accounting messages vs start/stop accounting with detailed info?=20 There are multiple uses for this info: (1) Who is using what channels. This can help you with network planning / overbooking, but also to enable targetted advertising, for which you only may only need to know which mcast channels they watch - i.e. start/stop. (2) Charging for delivery of the mcast traffic - for which you may want detailed info, as you are charging on volume basis and time basis ( i.e. peak time volume will be more expensive ). This would apply for a e.g. wholesale network provider charging a retailer for delivery. - And does anyone forsee a deployment model where a mix of the modes is used, eg AN1 supporting detailed-mode and AN2 supporting not-detailed-mode?=20 Less so, I think, unless you want the detailed mode from all but the AN2 doesn't support it yet - so this is back to the capabilities discussion i think. From an application scenario this seems to make less sense. Accounting models tend to be application or network global rather than network element or regionally specific, in my experience. Cheers, Derek. +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ Derek Harkness Juniper Networks=20 Nymphenburger Strasse 13-15 80335 Munich Germany Tel: +49 89 5529 4916 Mobile: +49 172 843 6621 Email: DHarkness@juniper.net +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+=20 -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 14 January 2008 16:39 To: Stefaan DE CNODDER Cc: ancp@ietf.org Subject: RE: [ANCP] Multicast Accounting Stefaan, I'll let Francois & Roberta comment on whether their proposal was to obly replace a bullet in Sec3.4.3, or both of them. In either case however, the proposal is very clear in removing the restrcition that mcast traffic accounting is out of scope, hence based on that reading the *current* framework text is not agreed to. As for the philosphy behind ANCP, it's useful to keep in mind the black box principle: ANCP should provide functionality to make the combination of NAS + L2 Access-Node look like one black box. Hence, irrespective of whether the AN can or cannot do unicat accounting, for the purpose of ANCP and multicast it appears rather useful to address the scenario where an AN *is* able to provide detailed mcast replication stats per port, beyond the basic case where it isn't. In terms of capabilities, such detailed stat reports could indeed be the subject of an additional negotiated capability, but on this I'd like the WG to provide some comments.=20 - Does anyone forsee a use for only simple start/stop mcast ANCP accounting messages vs start/stop accounting with detailed info?=20 - And does anyone forsee a deployment model where a mix of the modes is used, eg AN1 supporting detailed-mode and AN2 supporting not-detailed-mode? Regards, Woj. > -----Original Message----- > From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: 14 January 2008 14:56 > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Multicast Accounting >=20 >=20 > Woj, >=20 > From a functional point of view it is Ok but the comment was=20 > to change the second bullet of section 3.4.3 into what is=20 > already in the first bullet of section 3.4.3 (although there=20 > it is generalised that the AN can send this info to any acct=20 > server and not just the NAS). >=20 > My question is whether we can remove the first bullet. If=20 > the AN has to do the multicast accounting, then it can also=20 > do the unicast accounting and I thought ANCP was about moving=20 > all of this to the NAS. And if the AN can do the unicast=20 > accounting, then it can do the appropriate QoS queueing as=20 > well.... Anyhow, I am fine with the current text in the=20 > framework and if we believe that the comment below was on the=20 > wrong bullet, then it is all Ok. >=20 > I have more problems with the capabilities negotiated with ANCP.=20 > Implementation will not support all or nothing but that is=20 > what is negotiated in the capabilities. Have the=20 > capabilities to be more fine-grained or should=20 > support/non-support be reflected in error codes? >=20 > regards, > Stefaan >=20 >=20 > Wojciech Dec (wdec) wrote: >=20 > > Stefaan, > >=20 > > then you're saying that you agree with Francois' proposal=20 > for Section=20 > > 3.4.3? > >=20 > > -Woj.=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Stefaan DE CNODDER > >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > >>Sent: 14 January 2008 14:00 > >>To: Wojciech Dec (wdec) > >>Cc: ancp@ietf.org > >>Subject: Re: [ANCP] Multicast Accounting > >> > >> > >>Woj, > >> > >>The framework draft currently does not exclude anything. =20 > >>Both options are possible. The case where the AN is counting the=20 > >>packets and measuring the time is also in the framework and this=20 > >>information can be sent directly from the AN to the=20 > accounting server=20 > >>(which might be the NAS itself of course) with another=20 > protocol than=20 > >>ANCP like Radius for instance. > >>Actually, section 3.4.3 has to be read as whole and not=20 > just the part=20 > >>I copy/pasted in the email. The question is basically if=20 > this section=20 > >>is Ok for everyone. > >> > >> From a protocol point of view, this means that each entry in the=20 > >>white list has the following information: indication whether=20 > >>accounting is needed or not, and if needed, whehter the=20 > accounting is=20 > >>performed by the NAS or by the AN. In the latter case, also the IP=20 > >>address of the accounting servers are specified. > >> > >>regards, > >>Stefaan > >> > >> > >>Wojciech Dec (wdec) wrote: > >> > >>>Hi Stefaan, > >>> > >>>it doesn't seem that we have agreement on this text, and an=20 > >>>alternative proposal is presented in=20 > >>>http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. > >>> > >>>---snip--- > >>>in Section "3.4.3 Multicast Accounting" > >>> > >>> > >>>replace: > >>>" > >>>o The AN keeps track of when replication starts or stops, > >> > >>and reports > >> > >>>this information to the NAS for further processing. In this > >> > >>case, ANCP > >> > >>>can be used to send the information from the AN to the NAS.=20 > >> > >>This can > >> > >>>be done with the Information Report message. > >>>The NAS can then generate the appropriate time and/or volume=20 > >>>accounting information per Access Loop and per multicast > >> > >>flow, to be > >> > >>>sent to the accounting system. The ANCP requirements to > >> > >>support this > >> > >>>approach are specified in this document. > >>>" > >>>by > >>>" > >>>o The AN keeps track of when replication for a given=20 > multicast flow=20 > >>>starts or stops and then the AN can convey time and/or volume=20 > >>>information to the NAS for further processing. This > >> > >>approach relies on > >> > >>>ANCP and is discussed below. > >>> > >>>---snip--- > >>> > >>>In general for accounting to be of use it needs to be > >> > >>fairly accurate, > >> > >>>hence it is highly desirable for the access node to present > >> > >>to the NAS > >> > >>>the time and/or volume information for further processing. Granted=20 > >>>that if access nodes are not capable of providing such=20 > information,=20 > >>>they will only signal simple start/stop events. I however=20 > don't see=20 > >>>why the framework and protocol should be limited only to > >> > >>this latter > >> > >>>variant. Is there a reason why the proposal presented by > >> > >>Francois is inadequate? > >> > >>>Regards, > >>>Woj. > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Stefaan DE CNODDER > >>>>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > >>>>Sent: 08 January 2008 14:13 > >>>>To: ancp@ietf.org > >>>>Subject: [ANCP] Multicast Accounting > >>>> > >>>> > >>>>Hi, > >>>> > >>>>At the last IETF meeting, there was a discussion about multicast=20 > >>>>accounting is supposed to work. Currently, the framework=20 > document=20 > >>>>mentions 2 options in section 3.4.3: > >>>> > >>>>--- > >>>> o The AN keeps track of when replication starts or stops, and > >>>> generates the time and/or volume based accounting > >> > >>information > >> > >>>>per > >>>> Access Loop and per multicast flow, before sending it to a=20 > >>>>central > >>>> accounting system for logging. Since the AN > >> > >>communicates with > >> > >>>> this accounting system directly, the approach > >> > >>doesn't require > >> > >>>>the > >>>> use of ANCP. It is therefore beyond the scope of this=20 > >>>>document; > >>>> > >>>> o The AN keeps track of when replication starts or stops, and > >>>> reports this information to the NAS for further > >> > >>processing. In > >> > >>>> this case, ANCP can be used to send the information > >> > >>from the AN > >> > >>>>to > >>>> the NAS. This can be done with the Information > >> > >>Report message. > >> > >>>> The NAS can then generate the appropriate time and/or volume > >>>> accounting information per Access Loop and per > >> > >>multicast flow, > >> > >>>>to > >>>> be sent to the accounting system. The ANCP requirements to > >>>> support this approach are specified in this document. > >>>>--- > >>>> > >>>>Is everyone Ok with this? Is more needed, or less, or more=20 > >>>>clarrification on what it means? > >>>> > >>>>Personally, it looks Ok to me but I have a comment for extra=20 > >>>>clarrification on the first bullet: Does it require any > >> > >>impact on the > >> > >>>>ANCP protocol? For the second bullet, I would expect that > >> > >>in a white > >> > >>>>list entry there is a flag indicating whether accounting is > >> > >>needed or > >> > >>>>not. Is something similar needed to support the first=20 > bullet in a=20 > >>>>white list entry (e.g., need for time and/or volume based > >> > >>accounting > >> > >>>>with the IP address of acct server)? Whatever is fine for > >> > >>me, but it > >> > >>>>has to be decided. > >>>> > >>>>regards, > >>>>Stefaan > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>ANCP mailing list > >>>>ANCP@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/ancp > >>> > >>> > >> > >>_______________________________________________ > >>ANCP mailing list > >>ANCP@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 17 10:50:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFX13-0007bI-G8; Thu, 17 Jan 2008 10:50:53 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFX11-0007PS-Is for ancp-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 10:50:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFX10-0007PJ-PO for ancp@ietf.org; Thu, 17 Jan 2008 10:50:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFX0z-0004Ih-Bv for ancp@ietf.org; Thu, 17 Jan 2008 10:50:50 -0500 X-IronPort-AV: E=Sophos;i="4.24,301,1196636400"; d="scan'208";a="3284117" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2008 16:50:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0HFomwQ020058; Thu, 17 Jan 2008 16:50:48 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0HFomgo024752; Thu, 17 Jan 2008 15:50:48 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 16:50:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Depreciation of TLVs ... again Date: Thu, 17 Jan 2008 16:49:31 +0100 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C106738@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Depreciation of TLVs ... again Thread-Index: AchRPLarKi8+RY7iQluEMuuoWLb32gG0+1XQAEPCJAA= References: <47823C09.4060709@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C106738@S4DE8PSAANK.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Busser, M" , X-OriginalArrivalTime: 17 Jan 2008 15:50:48.0492 (UTC) FILETIME=[BA9FCEC0:01C85920] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11064; t=1200585048; x=1201449048; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Depreciation=20of=20TLVs=20... =20again |Sender:=20; bh=y7JAzf53CWLNihMuhBI8hYSGvkVIueml/W3h12BbVws=; b=hgQpCFBm9fuy9TLQoJZYNurd4G2RUgdRJnfIJGrjGqwLo/KCd2GfWi0CeW F59lLYZ9G/KXrQD6zCVph5fzV6HXl1C7cRvJoTEWj4EXP1avugO64pMrPZL2 xJ0mCQt55+; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Michael, All thanks for you feedback and the additional caveat. It seems that 1b is = the preferred way forward, so unless someone objects between now and the = end of January, it's settled. A small remark about this "known caveats" = section; it should be clearly stated that it is not normative, and not = required to implement ANCP on either the NAS or the AN. Regards, Woj. > -----Original Message----- > From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 > Sent: 16 January 2008 08:32 > To: stefaan.de_cnodder@alcatel-lucent.be; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: AW: [ANCP] Depreciation of TLVs ... again >=20 > All. >=20 > I fully agree with Stefaan. > We can not assume 1a, so i am aganinst it. >=20 > I also think, that TLV Type 0x02 is not that important. It is=20 > also an optional TLV.=20 > So ignoring it for a while at the NAS as Stefaan suggests is=20 > an acceptable solution for me. > It it also not used by RAM or OAM at the moment (as far as I=20 > know), so we shouldn't have problems with that. >=20 > With subTLV 0x90 renumbered to 0x91, we can proceed as follows:=20 >=20 > Lets assume, we have a AN running with an "old" version of=20 > the draft (e.g. Dec. 2005).=20 > Those systems will never send a subTLV 0x91. If the NAS=20 > receives a subTLV 0x90, it should interpret this subTLV as DSL-Type. >=20 > If we have a AN running a later version of the draft, the NAS=20 > will at least receive a subTLV 0x91 because this is=20 > mandatory. It may also receive a subTLV 0x90, wich is optional.=20 > In this case, the NAS should interpret 0x90 as=20 > Access-Loop-Encapsulation and 0x91 as DSL-Type. >=20 > The only thing, we have to take care of is that the NAS have=20 > to be updated to this behaviour first.=20 > After that, the AN vendors can change their implementations=20 > whenever the want. >=20 > I also agree with Stefaan, that we schould describe this in=20 > detail in an appendix.=20 > The other changes we made, concerns the length of some=20 > parameters. This can be solved by the AN vendors, as long as=20 > we have different implementations at the NAS side in that=20 > specific detail. > This is actually already the case as far as i know. >=20 > I think, 1b is the way to go. >=20 >=20 > Some other useful information for a "known caveats" appendix: >=20 > OAM-Loopback-Test-Parameter=3D0x07 > The length of the parameter has changed from 8 to 4 bytes. > Depending on the implementation at the NAS, a AN can receive=20 > the OAM-Loopback-Test-Parameter with length=3D8 as well as with=20 > length=3D4 byte. > AN vendors should take this into account. >=20 >=20 > The other way of course is to have a kind of a version number=20 > wich is our preference. > But even if the group decide to have an ANCP version number,=20 > we need an agreement, how to proceed from the actually=20 > running implementations.=20 >=20 > Best Regards >=20 > Michael Busser >=20 > T-Systems Enterprise Services GmbH > Systems Integration=20 >=20 > =20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Montag, 7. Januar 2008 15:50 > An: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Betreff: Re: [ANCP] Depreciation of TLVs ... again >=20 >=20 >=20 > Woj, >=20 > Let's say that I am against 1a. It also requires that all=20 > ANs and all=20 > NASes are upgraded at the same time which is unlikely. >=20 > It depends on which node is typically upgraded first. Are ISPs first=20 > upgrading the NAS or first the AN? I would expect first the NAS. If=20 > that's true, then it looks to me that it should be like this: >=20 > If I see correctly "PORT-UP message TLV Type 0x02" changed=20 > meaning and=20 > the original data that was in TLV 0x02 is now in 0x06. =20 > However, this is=20 > an optional TLV and does not look that important, and to=20 > avoid interop=20 > problems, a NAS should not interprete TLV 0x02 "for some=20 > time", except=20 > in displaying this information or other things that does not=20 > break the=20 > correct operation of ANCP. This until we are sure that there are no=20 > implementations that use the old spec. This should be=20 > described in an=20 > appendix of the draft. >=20 > subTLV 0x90 is renumbered to 0x91. Here the BRAS should, to avoid=20 > interop problems, interprete both 0x90 and 0x91 in the same way. If=20 > both are there, then only 0x91 should be interpreted. Also=20 > this should=20 > be described clearly in the appendix. >=20 > In the future it would be better that the numbering is kept as it is.=20 > For instance, for TLV 0x02 it should never have been moved to=20 > 0x06 and=20 > then using 0x02 for something else... This could have been=20 > avoided, but=20 > if it cannot be avoided, then it should be described=20 > explicetely in the=20 > appendix. >=20 > regards, > Stefaan >=20 >=20 > Wojciech Dec (wdec) wrote: >=20 > > Stefaan, are you behind option 1b then? > >=20 > > The case if currently for : > >=20 > > PORT-UP message TLV Type 0x02 > > PORT-UP message TLV 0x04 sub-TLV 0x90 > >=20 > > Both of which I beleive are currenly implemented (based on the=20 > > conflicting definition in draft-wadhwa-00). > >=20 > > BTW. I naturally meant depricate not depreciate ;-) > >=20 > > -Woj. > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Stefaan DE CNODDER > >>[mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > >>Sent: 07 January 2008 15:07 > >>To: Wojciech Dec (wdec) > >>Cc: ancp@ietf.org > >>Subject: Re: [ANCP] Depreciation of TLVs ... again > >> > >> > >> > >> > >>>1a. Do not depreciate TLVs, and assume that all implementations and > >>>users will follow the latest ANCP draft (i.e. assume that=20 > >> > >>draft-l2cp > >> > >>>problems never happened). > >> > >>You cannot assume that. > >> > >> > >>>1b. Do not depreciate TLVs, but introduce a "known caveats" in the > >>>appendix of the protocol draft, describing the potential legacy=20 > >>>implementation interoperability problem. > >> > >>Important changes that may lead to interop issues when > >>implementations implement different versions of the same=20 > >>draft should be documented properly in the appendix. But=20 > >>this should be avoided as much as possible... Maybe it=20 > >>should be looked at case by case. If a number changes of a=20 > >>TLV that is not important, then it will not harm a lot, but=20 > >>if it happens to important TLVs like the ones carrying=20 > >>bandwidth or ACIs, then it should be avoided and if not=20 > >>possible to avoid, describe it very well in the appendix. > >> > >>regards, > >>Stefaan > >> > >> > >> > >>>2. Depreciate TLVs. > >>> > >>>Now, given that option 2 appears to have just recently been > >> > >>presented > >> > >>>with a reasonable argument against it (see Vancouver > >> > >>minutes below), I > >> > >>>call for the WG to decide on 1a or 1b. > >>> > >>>Some background: > >>> > >>>The problem was introduced in edits made between pre-ANCP > >> > >>WG drafts to > >> > >>>draft-wadhwa-gsmp-l2control-configuration-00. > >>>Version 00 of this draft dated August 2, 2005 saw the > >> > >>PORT-UP message > >> > >>>TLV 0x02 assigned to > >> > >>"Access-Aggregation-Circuit-ID-Binary". The next > >> > >>>version 01, dated September 2006, saw the same TLV assigned to > >>>"Access-Loop-Remote-Id". > >>>A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90,=20 > which saw=20 > >>>it's meaning changed between drafts. The ANCP protocol draft is=20 > >>>derived from the 01 version. > >>> > >>>It so happens however that most known implementations are > >> > >>based on the > >> > >>>00 draft, which presents an interoperability problem to anyone who > >>>implemented the 00 definition and those that implement the=20 > >> > >>latest ANCP > >> > >>>draft. Hacks aside, a long term fix needs to be devised. > >>>NOTE: There is no known way to distinguish l2cp draft 00, > >> > >>01 or ANCP > >> > >>>draft speakers other than trough hacks, which current 00 > >>>implementations are known to have adopted as a "workaround"=20 > >> > >>to *ONE* of the problem. > >> > >>>Now the original proposal of a solution was drafted in > >>> > >> > >>http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and > >> > >>>the WG provided no objections. Furthermore the topic was also > >>>discussed during IETF 69 back in March 2007 (minutes here: > >>>http://tools.ietf.org/wg/ancp/minutes?item=3Dminutes68.html).=20 > >> > >>Again no > >> > >>>objections were raised by any of the WG participants. > >>>Hence the decision to *depreciate* conflicting TLVs was previously > >>>made by the WG (and claims of this being otherwise are=20 > removed from=20 > >>>the truth). > >>> > >>>=20 > >>>---snip--- > >>>=20 > >>> ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net)=20 > >>>http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 > >>> > >>>Discuss protocol draft updates and ANCP graceful restart. > >>>---------------------------------------------------------- > >>>consistency with framework > >>>new section 2.1 on terminology > >>>net data rate used > >>>new multipair bonding text > >>>text for topology discovery extensions 5.4.2 clarified=20 > >> > >>message format > >> > >>>in line configuration extension, section 5.4.3 concern over tlv > >>>changes, diverges from tr-101 and rfc 4679 in TLV#. > >>>Common notion is for BRAS to pass TLV transparently into Radius.=20 > >>>Changes held back. Doesn't see issue as colliding values have been=20 > >>>changed previously. > >>> > >>> access loop remote id and sub tlv access loop encapsulation=20 > >>> suggest not deprecate these tlvs, keep them alive=20 > >>> Peter, why did Woj want this deprecated, agrees that > >> > >>these shouldn't > >> > >>>be deprecated. > >>> Sanjay, reason was to depreciate to avoid overlap, but > >> > >>ROI is small > >> > >>>in this case. > >>> graceful restart draft updated, support for multicast use cased > >>>agreed upon by the WG. > >>> Matthew, should graceful restart be a separate draft=20 > >> > >>going forward, > >> > >>>Sanjay agreed > >>> Matthew, graceful restart not on charter, need to add > >> > >>to milestones > >> > >>>---snip-- > >>> > >>>Regards, > >>>Woj. > >>> > >>> > >>>_______________________________________________ > >>>ANCP mailing list > >>>ANCP@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ancp > >> > >=20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jan 18 05:23:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoNJ-0003lf-B2; Fri, 18 Jan 2008 05:23:01 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JFoNH-0003kM-JA for ancp-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 05:22:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoNA-0003jm-QE for ancp@ietf.org; Fri, 18 Jan 2008 05:22:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFoN9-00073g-96 for ancp@ietf.org; Fri, 18 Jan 2008 05:22:52 -0500 X-IronPort-AV: E=Sophos;i="4.25,215,1199660400"; d="scan'208";a="3345255" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Jan 2008 11:22:50 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0IAMoTn002658; Fri, 18 Jan 2008 11:22:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0IAMfgs026940; Fri, 18 Jan 2008 10:22:46 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 11:22:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast Accounting Date: Fri, 18 Jan 2008 11:22:39 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast Accounting Thread-Index: AchWtVjd9pqIhQ7VSFaPeTAJDQNqlQAAeY2AAJPJZUAALUJUMA== References: From: "Wojciech Dec (wdec)" To: "Derek Harkness" , "Stefaan DE CNODDER" X-OriginalArrivalTime: 18 Jan 2008 10:22:42.0856 (UTC) FILETIME=[0F7BE280:01C859BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12599; t=1200651770; x=1201515770; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Multicast=20Accounting |Sender:=20; bh=SHK1tZ9ji4GJmpMY2C/vi4iCHPTrY0Vb2ZoB2Fqd1Og=; b=CQ8FzdBjB1Gu6yprLj2XZtBsWxsi6gCrvXCXk5d5RBywzBLIYG/INr4ls+ Zd0vxY3ZlD1EcL1kogoeNGQzAJx8Uj5Cod/FUCorNINr6570FShIw9k9UxAM w0Z8vc8wkX; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org It thus seems that allowing for ANCP mcast accounting detail capability negotiation seems as the way forward, with two main capabilities: simple (start/stops only), detailed (start/stops with byte count). Arguably time info can also be added, but appears to be implicit in the start/stop info already. -Woj. > -----Original Message----- > From: Derek Harkness [mailto:dharkness@juniper.net]=20 > Sent: 17 January 2008 13:53 > To: Wojciech Dec (wdec); Stefaan DE CNODDER > Cc: ancp@ietf.org > Subject: RE: [ANCP] Multicast Accounting >=20 > I lost some of the the thread of the text alternatives, but=20 > can only absolutely agree on the black box principle - AN &=20 > NAS is one multicast node. >=20 > - Does anyone forsee a use for only simple start/stop mcast=20 > ANCP accounting messages vs start/stop accounting with detailed info?=20 >=20 > There are multiple uses for this info: > (1) Who is using what channels. This can help you with=20 > network planning / overbooking, but also to enable targetted=20 > advertising, for which you only may only need to know which=20 > mcast channels they watch - i.e. > start/stop. >=20 > (2) Charging for delivery of the mcast traffic - for which=20 > you may want detailed info, as you are charging on volume=20 > basis and time basis ( i.e. > peak time volume will be more expensive ). This would apply for a e.g. > wholesale network provider charging a retailer for delivery. >=20 > - And does anyone forsee a deployment model where a mix of=20 > the modes is used, eg AN1 supporting detailed-mode and AN2=20 > supporting not-detailed-mode?=20 >=20 > Less so, I think, unless you want the detailed mode from all=20 > but the AN2 doesn't support it yet - so this is back to the=20 > capabilities discussion i think. From an application scenario=20 > this seems to make less sense. > Accounting models tend to be application or network global=20 > rather than network element or regionally specific, in my experience. >=20 > Cheers, >=20 > Derek. >=20 > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ > Derek Harkness > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ >=20 > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 > Sent: 14 January 2008 16:39 > To: Stefaan DE CNODDER > Cc: ancp@ietf.org > Subject: RE: [ANCP] Multicast Accounting >=20 > Stefaan, >=20 > I'll let Francois & Roberta comment on whether their proposal was to > obly replace a bullet in Sec3.4.3, or both of them. In either case > however, the proposal is very clear in removing the restrcition that > mcast traffic accounting is out of scope, hence based on that reading > the *current* framework text is not agreed to. >=20 > As for the philosphy behind ANCP, it's useful to keep in mind=20 > the black > box principle: ANCP should provide functionality to make the=20 > combination > of NAS + L2 Access-Node look like one black box. Hence,=20 > irrespective of > whether the AN can or cannot do unicat accounting, for the purpose of > ANCP and multicast it appears rather useful to address the scenario > where an AN *is* able to provide detailed mcast replication stats per > port, beyond the basic case where it isn't. >=20 > In terms of capabilities, such detailed stat reports could=20 > indeed be the > subject of an additional negotiated capability, but on this=20 > I'd like the > WG to provide some comments.=20 > - Does anyone forsee a use for only simple start/stop mcast ANCP > accounting messages vs start/stop accounting with detailed info?=20 > - And does anyone forsee a deployment model where a mix of=20 > the modes is > used, eg AN1 supporting detailed-mode and AN2 supporting > not-detailed-mode? >=20 > Regards, > Woj. >=20 >=20 > > -----Original Message----- > > From: Stefaan DE CNODDER=20 > > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > > Sent: 14 January 2008 14:56 > > To: Wojciech Dec (wdec) > > Cc: ancp@ietf.org > > Subject: Re: [ANCP] Multicast Accounting > >=20 > >=20 > > Woj, > >=20 > > From a functional point of view it is Ok but the comment was=20 > > to change the second bullet of section 3.4.3 into what is=20 > > already in the first bullet of section 3.4.3 (although there=20 > > it is generalised that the AN can send this info to any acct=20 > > server and not just the NAS). > >=20 > > My question is whether we can remove the first bullet. If=20 > > the AN has to do the multicast accounting, then it can also=20 > > do the unicast accounting and I thought ANCP was about moving=20 > > all of this to the NAS. And if the AN can do the unicast=20 > > accounting, then it can do the appropriate QoS queueing as=20 > > well.... Anyhow, I am fine with the current text in the=20 > > framework and if we believe that the comment below was on the=20 > > wrong bullet, then it is all Ok. > >=20 > > I have more problems with the capabilities negotiated with ANCP.=20 > > Implementation will not support all or nothing but that is=20 > > what is negotiated in the capabilities. Have the=20 > > capabilities to be more fine-grained or should=20 > > support/non-support be reflected in error codes? > >=20 > > regards, > > Stefaan > >=20 > >=20 > > Wojciech Dec (wdec) wrote: > >=20 > > > Stefaan, > > >=20 > > > then you're saying that you agree with Francois' proposal=20 > > for Section=20 > > > 3.4.3? > > >=20 > > > -Woj.=20 > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: Stefaan DE CNODDER > > >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >>Sent: 14 January 2008 14:00 > > >>To: Wojciech Dec (wdec) > > >>Cc: ancp@ietf.org > > >>Subject: Re: [ANCP] Multicast Accounting > > >> > > >> > > >>Woj, > > >> > > >>The framework draft currently does not exclude anything. =20 > > >>Both options are possible. The case where the AN is counting the=20 > > >>packets and measuring the time is also in the framework and this=20 > > >>information can be sent directly from the AN to the=20 > > accounting server=20 > > >>(which might be the NAS itself of course) with another=20 > > protocol than=20 > > >>ANCP like Radius for instance. > > >>Actually, section 3.4.3 has to be read as whole and not=20 > > just the part=20 > > >>I copy/pasted in the email. The question is basically if=20 > > this section=20 > > >>is Ok for everyone. > > >> > > >> From a protocol point of view, this means that each entry in the=20 > > >>white list has the following information: indication whether=20 > > >>accounting is needed or not, and if needed, whehter the=20 > > accounting is=20 > > >>performed by the NAS or by the AN. In the latter case,=20 > also the IP=20 > > >>address of the accounting servers are specified. > > >> > > >>regards, > > >>Stefaan > > >> > > >> > > >>Wojciech Dec (wdec) wrote: > > >> > > >>>Hi Stefaan, > > >>> > > >>>it doesn't seem that we have agreement on this text, and an=20 > > >>>alternative proposal is presented in=20 > > >>>http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html. > > >>> > > >>>---snip--- > > >>>in Section "3.4.3 Multicast Accounting" > > >>> > > >>> > > >>>replace: > > >>>" > > >>>o The AN keeps track of when replication starts or stops, > > >> > > >>and reports > > >> > > >>>this information to the NAS for further processing. In this > > >> > > >>case, ANCP > > >> > > >>>can be used to send the information from the AN to the NAS.=20 > > >> > > >>This can > > >> > > >>>be done with the Information Report message. > > >>>The NAS can then generate the appropriate time and/or volume=20 > > >>>accounting information per Access Loop and per multicast > > >> > > >>flow, to be > > >> > > >>>sent to the accounting system. The ANCP requirements to > > >> > > >>support this > > >> > > >>>approach are specified in this document. > > >>>" > > >>>by > > >>>" > > >>>o The AN keeps track of when replication for a given=20 > > multicast flow=20 > > >>>starts or stops and then the AN can convey time and/or volume=20 > > >>>information to the NAS for further processing. This > > >> > > >>approach relies on > > >> > > >>>ANCP and is discussed below. > > >>> > > >>>---snip--- > > >>> > > >>>In general for accounting to be of use it needs to be > > >> > > >>fairly accurate, > > >> > > >>>hence it is highly desirable for the access node to present > > >> > > >>to the NAS > > >> > > >>>the time and/or volume information for further=20 > processing. Granted=20 > > >>>that if access nodes are not capable of providing such=20 > > information,=20 > > >>>they will only signal simple start/stop events. I however=20 > > don't see=20 > > >>>why the framework and protocol should be limited only to > > >> > > >>this latter > > >> > > >>>variant. Is there a reason why the proposal presented by > > >> > > >>Francois is inadequate? > > >> > > >>>Regards, > > >>>Woj. > > >>> > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Stefaan DE CNODDER > > >>>>[mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >>>>Sent: 08 January 2008 14:13 > > >>>>To: ancp@ietf.org > > >>>>Subject: [ANCP] Multicast Accounting > > >>>> > > >>>> > > >>>>Hi, > > >>>> > > >>>>At the last IETF meeting, there was a discussion about=20 > multicast=20 > > >>>>accounting is supposed to work. Currently, the framework=20 > > document=20 > > >>>>mentions 2 options in section 3.4.3: > > >>>> > > >>>>--- > > >>>> o The AN keeps track of when replication starts or=20 > stops, and > > >>>> generates the time and/or volume based accounting > > >> > > >>information > > >> > > >>>>per > > >>>> Access Loop and per multicast flow, before=20 > sending it to a=20 > > >>>>central > > >>>> accounting system for logging. Since the AN > > >> > > >>communicates with > > >> > > >>>> this accounting system directly, the approach > > >> > > >>doesn't require > > >> > > >>>>the > > >>>> use of ANCP. It is therefore beyond the scope of this=20 > > >>>>document; > > >>>> > > >>>> o The AN keeps track of when replication starts or=20 > stops, and > > >>>> reports this information to the NAS for further > > >> > > >>processing. In > > >> > > >>>> this case, ANCP can be used to send the information > > >> > > >>from the AN > > >> > > >>>>to > > >>>> the NAS. This can be done with the Information > > >> > > >>Report message. > > >> > > >>>> The NAS can then generate the appropriate time=20 > and/or volume > > >>>> accounting information per Access Loop and per > > >> > > >>multicast flow, > > >> > > >>>>to > > >>>> be sent to the accounting system. The ANCP=20 > requirements to > > >>>> support this approach are specified in this document. > > >>>>--- > > >>>> > > >>>>Is everyone Ok with this? Is more needed, or less, or more=20 > > >>>>clarrification on what it means? > > >>>> > > >>>>Personally, it looks Ok to me but I have a comment for extra=20 > > >>>>clarrification on the first bullet: Does it require any > > >> > > >>impact on the > > >> > > >>>>ANCP protocol? For the second bullet, I would expect that > > >> > > >>in a white > > >> > > >>>>list entry there is a flag indicating whether accounting is > > >> > > >>needed or > > >> > > >>>>not. Is something similar needed to support the first=20 > > bullet in a=20 > > >>>>white list entry (e.g., need for time and/or volume based > > >> > > >>accounting > > >> > > >>>>with the IP address of acct server)? Whatever is fine for > > >> > > >>me, but it > > >> > > >>>>has to be decided. > > >>>> > > >>>>regards, > > >>>>Stefaan > > >>>> > > >>>> > > >>>> > > >>>>_______________________________________________ > > >>>>ANCP mailing list > > >>>>ANCP@ietf.org > > >>>>https://www1.ietf.org/mailman/listinfo/ancp > > >>> > > >>> > > >> > > >>_______________________________________________ > > >>ANCP mailing list > > >>ANCP@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/ancp > > >=20 > > >=20 > >=20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 28 08:12:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJTmz-0008EG-9I; Mon, 28 Jan 2008 08:12:41 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JJTmy-0008EB-Kj for ancp-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 08:12:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJTmy-0008CQ-90 for ancp@ietf.org; Mon, 28 Jan 2008 08:12:40 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJTmx-0007aP-9G for ancp@ietf.org; Mon, 28 Jan 2008 08:12:40 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0SD4DVV029601 for ; Mon, 28 Jan 2008 14:04:18 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 28 Jan 2008 14:12:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jan 2008 14:12:36 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA1EC3E1@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <7168964CAC5C144685272595141B6DBA1EBFA2@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Accounting Thread-Index: AchengJqjn57bKGVR/W9VAlM7dqf7wAyBmmQAABgPBAAAHzW4ACQ5mKw References: <7168964CAC5C144685272595141B6DBA1B0552@FRVELSMBS22.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA1EBF7C@FRVELSMBS22.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA1EBF86@FRVELSMBS22.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA1EBFA2@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: X-OriginalArrivalTime: 28 Jan 2008 13:12:37.0257 (UTC) FILETIME=[73F38790:01C861AF] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [ANCP] ANCP Accounting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, Based on the discussion on the list, I have prepared the following text proposal concerning multicast accounting. If nobody objects, I will use the text below to update the text in section 3.4.3 in the ANCP Framework. I will also add the corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access Node) and 4.8.6 (NAS). Regards, Sven --- << Section 3.4.3 >> 3.4.3. Multicast Accounting It may be desirable to perform time and/or volume based accounting for certain multicast flows sent on particular Access Ports. In case the AN is performing the traffic replication process, it knows when replication of a multicast flow to a particular Access Port or user start and stops. Multicast accounting can be addressed in two ways: o The AN keeps track of when replication for a given multicast flow starts or ends on a specified Access Port, and generates time and/or volume based accounting information per Access Port and per multicast flow, before sending it to a central accounting system for logging. Given that the AN communicates with the accounting system directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document; o The AN keeps track of when replication for a given multicast flow starts or ends on a specified Access Port, and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the AN to the NAS. This will be discussed in the remainder of this document. The Access Node can send multicast accounting information to the NAS using the Information Report message. A distinction can be made between two cases: o Basic accounting: the Access Node informs the NAS whenever replication starts or ends for a given multicast flow on a particular Access Port; o Detailed accounting: the Access Node not only informs the NAS when replication starts or ends, but also informs the NAS about the multicast traffic volume replicated on the Access Port for that multicast flow. This is done by adding a byte count in the Information Report message which is sent to the NAS when replication ends. Upon receiving the Information Report messages, the NAS generates the appropriate time and/or volume accounting information per Access Loop and per multicast flow, to be sent to the accounting system. The NAS should inform the Access Node about the type of accounting is needed for a given multicast flow on a particular Access Port: o No reporting messages need to be sent to the NAS o Basic accounting is required o Detailed accounting is required The actual type of accounting should be negotiated between the Access Node and the NAS during the establishment of the Adjacency. In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN can consolidate multiple sets of accounting information inside a single Information Report message. The ANCP requirements to support this use case are specified below in this document. << Section 4.2 >> o The ANCP MUST allow the AN to send an Information Report message to the NAS whenever replication of a multicast flow on a particular Access Port start or ends. o The ANCP MUST allow the AN to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port. o The ANCP MUST allow the AN and the NAS to agree on the type of multicast accounting that can be used (time and/or volume based); this is part of the Capability Negotiation procedure. o The ANCP MUST allow the NAS to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port. o In case multicast accounting is needed for a multicast flow on a particular Access Port, the ANCP MUST allow the NAS to indicate to the AN whether or not additional volume accounting information is required. o The ANCP MUST support indicating the type of accounting in the Control Request message for entries in the White list, and in the Admission Response message for entries in the Grey list. << Section 4.7.6 >> o The AN must support using ANCP to send an Information Report message to the NAS whenever replication starts or ends. o The AN should support using ANCP to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port. << Section 4.8.6 >> o The NAS must support using ANCP to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port. o In case multicast accounting is needed for a multicast flow on a particular Access Port, the NAS should support using ANCP to indicate to the AN whether or not additional volume accounting information is required. --- Sven Ooghe Alcatel-Lucent CTO Office, Access Division Copernicuslaan 50, 2018 Antwerp, Belgium tel.: +32 3 240 42 26 fax: +32 3 240 40 73 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 28 08:18:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJTsn-0003sN-Rf; Mon, 28 Jan 2008 08:18:41 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JJTsm-0003rC-Ou for ancp-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 08:18:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJTsm-0003qo-EG for ancp@ietf.org; Mon, 28 Jan 2008 08:18:40 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJTsk-0007gs-BX for ancp@ietf.org; Mon, 28 Jan 2008 08:18:40 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0SDGQG1002665 for ; Mon, 28 Jan 2008 14:16:26 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 28 Jan 2008 14:18:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jan 2008 14:18:35 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast Admission Control Thread-Index: AchengJqjn57bKGVR/W9VAlM7dqf7wAvhBnwAJNYxhAAAMbRcAAAANHw From: "OOGHE Sven" To: X-OriginalArrivalTime: 28 Jan 2008 13:18:37.0094 (UTC) FILETIME=[4A6E4C60:01C861B0] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [ANCP] ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, Based on the discussion on the list, I have prepared the following text proposal concerning multicast conditional access. I tried to cover the different scenarios that were identified on the list. This includes the proposal from Tina and Roberta, and feedback from Stefaan. If nobody objects, I will use the text below to update the text in section 3.4.2 in the ANCP Framework. I will also add the corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access Node) and 4.8.6 (NAS). Regards, Sven --- << Section 3.4.2 >> 3.4.2. Multicast Admission Control << first part of the section remains unchanged. The text from the second bullet onward is updated with below text >> 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. The second scenario can be split in to cases: o 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. o In case the Policy Server queries the AN indirectly via the NAS, the interaction can be handled as an ANCP transaction. When the Policy Server queries the NAS, the NAS can use ANCP to query the AN, specifying the Access-Loop-Circuit-ID and the required bandwidth for the requested unicast flow. Upon receiving the query from the NAS, the AN then performs Admission Control and responds to the NAS, indicating if this unicast VoD request can be accepted or denied. 3.4.2.1. When not to perform Admission Control In general, the Access Node and NAS may not be aware of all possible multicast groups that will be streamed in the access network. For instance, it is likely that there will be multicast streams offered across the Internet. For these unknown streams, performing bandwidth admission control may be challenging. To solve this, these requests could be accepted without performing Admission Control. This solution works, provided that the network handles the streams as best effort, so that other streams are not impacted at times of congestion. Disabling Admission Control for unknown stream can be achieved by adding a "catch-all statement" in the Access Node white list or grey list. In case the Access Node queries the NAS, the NAS on his turn will have to accept the request. That way, the unknown streams are not blocked by default. Next, in order to ensure that the streams are handled as best effort, the flow must be marked as such when entering the service provider network. This way, whenever congestion occurs somewhere in the access/aggregation network, this stream will be kicked out before the access provider's own premium content. The above concept is applicable beyond the notion of "Internet streams" or other unknown streams; it can applied to known multicast streams as well. In this case, the Access Node or NAS will accept the stream even when bandwidth may not be sufficient to support the stream. This again requires that the stream is marked as best effort traffic before entering the access/aggregation network. 3.4.2.2. Multicast Admission Control and White Lists As mentioned in section Section 3.4.1, conditional access to popular IPTV channels can be achieved by means of a White and Black list configured on the Access Node. This method allows the Access Node to autonomously decide whether or not access can be granted to a multicast flow. IPTV is an example of a service that will not be offered as best effort, but requires some level of guaranteed Quality of Service. This requires the use of Multicast Admission Control. Hence, if the Access Node wants to autonomously perform the admission process, it must be aware of the bandwidth characteristics of multicast flows. Otherwise, the Access Node would have to query the NAS for Multicast Admission Control; this would defeat the purpose of using a White and Black list. Some network deployments may combine the use of White list, Black list and Grey list. In this case, the AN will be aware of the portion of the bandwidth used on the Access Port for flows matching an entry in the White list. In order to perform Multicast Admission Control for flows matching an entry in the Grey list, the NAS should add the bandwidth characteristics of the flow in the Admission Response message. In this model, the AN would query the NAS for conditional access, and would then locally perform Multicast Conditional Access, using the bandwidth information retrieved from the NAS. << Section 4.2: add following requirements >> o The ANCP MUST support providing an Access Node with bandwidth information associated with multicast flows that are part of a White list. o The ANCP SHOULD allow the NAS to indicate the bandwidth information, associated with the requested multicast flows, in the admission decision sent to the AN. o In case a unicast and multicast stream share resources on an Access Port, the ANCP MUST allow the NAS to query the AN to request an admission decision for a unicast flow to be sent over that Port. << Section 4.7.6: add following requirements >> o The AN must be able to perform Admission Control for multicast streams, using the bandwith information of the requested multicast flow. The information may be provisioned by a management system or by the NAS (using a Control Reqest message or an Admission Response message). o Upon receiving a query from the NAS to request an admission decision for a unicast flow to be sent over a particular Access Port, the AN must support using ANCP to reply to the NAS, indicating whether the request is to be honored or denied. << Section 4.8.6: add following requirements >> o The NAS should support using ANCP to configure multicast admission control information to Access Ports on an Access Node. o Upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port, the NAS should support using ANCP to reply to the AN indicating the bandwidth information, associated with the requested multicast flow. o Upon receiving a request from a Policy Server for a unicast flow to be sent over a particular Access Port, the NAS must support using ANCP to query the AN to receive a response indicating whether the request is to be honored or denied. --- Sven Ooghe Alcatel-Lucent CTO Office, Access Division Copernicuslaan 50, 2018 Antwerp, Belgium tel.: +32 3 240 42 26 fax: +32 3 240 40 73 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jan 29 03:07:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJlUq-0006NK-Ch; Tue, 29 Jan 2008 03:07:08 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JJlUo-0006N9-Vn for ancp-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 03:07:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJlUo-0006N0-H9 for ancp@ietf.org; Tue, 29 Jan 2008 03:07:06 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJlUn-0003n7-6i for ancp@ietf.org; Tue, 29 Jan 2008 03:07:06 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 29 Jan 2008 00:03:05 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jan 2008 00:06:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jan 2008 03:06:02 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast Admission Control Thread-Index: AchiTcpQdkZkcJZHSPqNoeRqWG3TkQ== From: "Sanjay Wadhwa" To: , , X-OriginalArrivalTime: 29 Jan 2008 08:06:04.0183 (UTC) FILETIME=[CB3CEA70:01C8624D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2696b5382f263e6d2b082a0a0572f4b8 Cc: Subject: [ANCP] ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0674164950==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0674164950== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8624D.CABBECF0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8624D.CABBECF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.=20 =20 Thanks -Sanjay =20 =20 3.4. Multicast =20 With the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important. =20 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. =20 To overcome this resource inefficiency, the Access Node, aggregation node(s) and the NAS must all be involved in the multicast =20 replication process. This avoids that several copies of the same=20 stream are sent within the access/aggregation network. In case of an=20 Ethernet-based access/aggregation network, this may, for example, be=20 achieved by means of IGMP snooping or IGMP proxy in the Access Node=20 and aggregation node(s). =20 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=20 and Access Node need to behave as a single logical device. This =20 logical device must have exactly the same functionality as the NAS=20 in the ATM access/aggregation network. The Access Node Control=20 Mechanism can be used to make sure that this logical/functional=20 equivalence is achieved by exchanging the necessary information=20 between the Access Node and the NAS. =20 Another option is for NAS to terminate IGMP signaling from the=20 subscriber. In this scenario, NAS can use ANCP to create replication=20 state in the AN for efficient multicast replication. The NAS sends a=20 single copy of the multicast stream towards the AN. The NAS can perform=20 conditional access and multicast admission control on IGMP joins, and create=20 replication state in the AN if the flow is admitted by the NAS. =20 The following subsections describe the different use cases related to multicast. =20 3.4.2. Multicast Admission Control =20 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. =20 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. =20 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). =20 Thus, supporting CAC for the access line requires some form of synchronization between the entity performing multicast CAC (e.g.=20 the NAS or the AN) and the entity performing unicast CAC (e.g. the=20 NAS or a Policy Server) and the entity actually enforcing the=20 multicast replication (i.e. the AN). This synchronization can be=20 achieved in a number of ways: =20 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" =20 bandwidth on the access-loop, and perform "video" bandwidth=20 accounting for the access-loop. On receiving an admission request=20 from the AN, the NAS can check available "video" bandwidth before=20 admitting or denying the multicast flow. The policy server may=20 query the NAS to perform admission control on a VoD flow, and update the available "video" bandwidth maintained by the NAS. =20 Similarly to what has been discussed in the Conditional Access=20 use case, in response to a Admission Request from the AN for=20 admission control of a multicast flow, the NAS may send back an=20 Admission Response message to the AN, including admission control=20 information for that multicast flow, as well as for other a set=20 of multicast flows sharing the same admission control rules. =20 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; =20 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=20 is to be honored or denied. In case the Policy Server queries=20 the AN directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document. =20 In case the NAS terminates IGMP signaling from the subscriber and controls the=20 replication state on the AN, the CAC function can be completely contained within=20 the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,=20 perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based=20 on the available bandwidth, if the IGMP join can be honored, the NAS can set the=20 replication state on the AN using ANCP. The policy server may query the NAS to=20 perform admission control on a VoD flow, and update the available "video" bandwidth=20 maintained by the NAS. =20 =20 -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 11:42 > To: OOGHE Sven > Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org;=20 > Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hi Sven, >=20 > On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >=20 > > 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=20 > > 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")." >=20 > Right. This is what initiated the thread. >=20 > I am also aware of other planned deployments where the Multicast joins > are processed by the device behaving as the ANCP-controller (as=20 > opposed to the AN). >=20 > As these ANCP deployments will exist, the ANCP specs ought to=20 > 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) >=20 > > =20 =20 =20 ------_=_NextPart_001_01C8624D.CABBECF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 
      informatio=
n for that multicast flow, as well as for other a set =

      of =
multicast flows sharing the same admission control rules.  =

      The AN =
can then autonomously honor or =
deny
      requests for a =
given user/port for the set of Multicast flows =
as
      indicated in =
the Admission Response message.  The =
ANCP
      requirements =
to support this approach (where the AN queries =
the
      NAS) are =
specified in this document;
 
   o  Another approach is the =
reverse: it consists of the Policy =
Server
      querying the =
AN (either directly, or indirectly via the NAS) =
so
      that both =
unicast and multicast CAC for the access line =
are
      performed by =
the AN.  In this case, a subscriber request for =
a
      unicast flow =
(e.g. a Video on Demand session) will trigger =
a
      resource =
request message towards a Policy Server; the latter =
will
      then query the =
AN, that in turn will perform unicast CAC for =
the
      access line =
and respond, indicating whether the unicast request =

      is to be =
honored or denied.  In case the Policy Server queries =

      the AN =
directly, the approach doesn't require the use of =
ANCP.            =

      It is =
therefore beyond the scope of this =
document.
 
In case the NAS terminates IGMP signaling from =
the subscriber and controls the 
replication state on the AN, the =
CAC function can be completely contained within =

the NAS. NAS may locally maintain =
available "video" bandwidth on the access-loop, =

perform "video" =
bandwidth accounting, and perform CAC on the received IGMP. =
Based 
on the available bandwidth, if the =
IGMP join can be honored, the NAS can set the 
replication state on the AN using =
ANCP. The policy server may query the NAS to =

perform admission control on a VoD =
flow, and update the available "video" bandwidth =

maintained by the =
NAS.



 



 



-----Original =
Message-----



> From: Francois =
Le
Faucheur IMAP [mailto:flefauch@cisco.com]



> Sent: maandag =
26
november 2007 11:42



> To: OOGHE =
Sven



> Cc: Francois =
Le
Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; =




> Maglione =
Roberta



> Subject: Re:
Spontaneous Admission Response (was
Re: [ANCP] ANCP WG



> =
follow-up)



> =




> Hi =
Sven,



> =




> On 26 Nov =
2007, at
11:06, OOGHE Sven wrote:



> =




> > =
Woj,



> =
>



> > From what =
I can
find on the email list, the proposed
change



> to =
section



> > 3.4.4 is =
related
to the following remark from Sanjay (mid =
September



> > =
2007):



> =
>



> > "The =
option I
alluded to is IGMP from RG to BNG, and replication on =




> > the AN. =
The replication
state on the AN created/controlled



> via ANCP by =
BNG.



> > An =
optimization
could be optional transparent snooping of



> IGMP on =
the



> > AN to act =
on IGMP
reports for leave only (to implement



> "fast
leave")."



> =




> Right. This is =
what
initiated the thread.



> =




> I am also =
aware of
other planned deployments where the Multicast joins =




> are =
processed by the device behaving as the =
ANCP-controller
(as 



> =
opposed to the =
AN).



> =




> As =
these ANCP deployments will exist, the ANCP =
specs ought
to 



> recognize and =
allow
them. Note that this has very little impact on the =




> ANCP protocol =
anyways
(since "spontaneous Admission Responses"



> are already =
explicitly
allowed anyways for multicast termination)



> =




> =
>



 



 



 
------_=_NextPart_001_01C8624D.CABBECF0-- --===============0674164950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0674164950==-- From ancp-bounces@ietf.org Tue Jan 29 09:23:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrNW-0000zd-Fn; Tue, 29 Jan 2008 09:23:58 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JJrNV-0000wz-An for ancp-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 09:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrNU-0000wr-R0 for ancp@ietf.org; Tue, 29 Jan 2008 09:23:56 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJrNT-000409-EM for ancp@ietf.org; Tue, 29 Jan 2008 09:23:56 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0TENjio011667; Tue, 29 Jan 2008 15:23:47 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Jan 2008 15:23:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jan 2008 15:23:50 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA1ECA7F@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast Admission Control Thread-Index: AchiTcpQdkZkcJZHSPqNoeRqWG3TkQANEBLQ References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> From: "OOGHE Sven" To: "Sanjay Wadhwa" , X-OriginalArrivalTime: 29 Jan 2008 14:23:51.0181 (UTC) FILETIME=[91D253D0:01C86282] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17d07dd202acd5ddc1032aa43098523 Cc: Subject: [ANCP] RE: ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1591563642==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1591563642== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86282.9185C2D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86282.9185C2D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Sanjay, =20 The model you describe below is covered in the new Spontaneous Admission Response section, but not yet in the Admission Control section. =20 I will use your proposed text to complete the description in section 3.4 and 3.4.2. =20 Regards, Sven ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: dinsdag 29 januari 2008 9:06 To: flefauch@cisco.com; OOGHE Sven; ancp@ietf.org Cc: Wojciech Dec (wdec) Subject: 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.=20 =20 Thanks -Sanjay =20 =20 3.4. Multicast =20 With the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important. =20 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. =20 To overcome this resource inefficiency, the Access Node, aggregation node(s) and the NAS must all be involved in the multicast =20 replication process. This avoids that several copies of the same=20 stream are sent within the access/aggregation network. In case of an=20 Ethernet-based access/aggregation network, this may, for example, be=20 achieved by means of IGMP snooping or IGMP proxy in the Access Node=20 and aggregation node(s). =20 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=20 and Access Node need to behave as a single logical device. This =20 logical device must have exactly the same functionality as the NAS=20 in the ATM access/aggregation network. The Access Node Control=20 Mechanism can be used to make sure that this logical/functional=20 equivalence is achieved by exchanging the necessary information=20 between the Access Node and the NAS. =20 Another option is for NAS to terminate IGMP signaling from the=20 subscriber. In this scenario, NAS can use ANCP to create replication=20 state in the AN for efficient multicast replication. The NAS sends a=20 single copy of the multicast stream towards the AN. The NAS can perform=20 conditional access and multicast admission control on IGMP joins, and create=20 replication state in the AN if the flow is admitted by the NAS. =20 The following subsections describe the different use cases related to multicast. =20 3.4.2. Multicast Admission Control =20 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. =20 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. =20 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). =20 Thus, supporting CAC for the access line requires some form of synchronization between the entity performing multicast CAC (e.g.=20 the NAS or the AN) and the entity performing unicast CAC (e.g. the=20 NAS or a Policy Server) and the entity actually enforcing the=20 multicast replication (i.e. the AN). This synchronization can be=20 achieved in a number of ways: =20 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" =20 bandwidth on the access-loop, and perform "video" bandwidth=20 accounting for the access-loop. On receiving an admission request=20 from the AN, the NAS can check available "video" bandwidth before=20 admitting or denying the multicast flow. The policy server may=20 query the NAS to perform admission control on a VoD flow, and update the available "video" bandwidth maintained by the NAS. =20 Similarly to what has been discussed in the Conditional Access=20 use case, in response to a Admission Request from the AN for=20 admission control of a multicast flow, the NAS may send back an=20 Admission Response message to the AN, including admission control=20 information for that multicast flow, as well as for other a set=20 of multicast flows sharing the same admission control rules. =20 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; =20 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=20 is to be honored or denied. In case the Policy Server queries=20 the AN directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document. =20 In case the NAS terminates IGMP signaling from the subscriber and controls the=20 replication state on the AN, the CAC function can be completely contained within=20 the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,=20 perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based=20 on the available bandwidth, if the IGMP join can be honored, the NAS can set the=20 replication state on the AN using ANCP. The policy server may query the NAS to=20 perform admission control on a VoD flow, and update the available "video" bandwidth=20 maintained by the NAS. =20 =20 -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 11:42 > To: OOGHE Sven > Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org;=20 > Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hi Sven, >=20 > On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >=20 > > 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=20 > > 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")." >=20 > Right. This is what initiated the thread. >=20 > I am also aware of other planned deployments where the Multicast joins > are processed by the device behaving as the ANCP-controller (as=20 > opposed to the AN). >=20 > As these ANCP deployments will exist, the ANCP specs ought to=20 > 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) >=20 > > =20 =20 =20 ------_=_NextPart_001_01C86282.9185C2D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Sanjay,
 
The model you describe below is covered in the = new=20 Spontaneous Admission Response section, but not yet in the Admission = Control=20 section.
 
I will use your proposed text to complete the = description=20 in section 3.4 and 3.4.2.
 
Regards,
Sven

From: Sanjay Wadhwa = [mailto:swadhwa@juniper.net]=20
Sent: dinsdag 29 januari 2008 9:06
To: = flefauch@cisco.com;=20 OOGHE Sven; ancp@ietf.org
Cc: Wojciech Dec = (wdec)
Subject:=20 ANCP Multicast Admission Control

Sven, Francois, and=20 All

  We agreed in the = attached=20 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=20 conditional access and admission control on the received IGMP joins, and = controls the replication state on the AN using ANCP. However, this is = not=20 adequately reflected in the draft. The draft also does not consider the = scenario=20 where the bandwidth accounting and CAC function is completely contained = within=20 the NAS (and doesn’t require complex synchronization between NAS = and AN). I am=20 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=20 Message-----

> From: = Francois Le=20 Faucheur IMAP [mailto:flefauch@cisco.com]

> Sent: maandag = 26=20 november 2007 11:42

> To: OOGHE=20 Sven

> Cc: Francois = Le=20 Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; =

> Maglione=20 Roberta

> Subject: Re:=20 Spontaneous Admission Response (was=20 Re: [ANCP] ANCP WG

>=20 follow-up)

>=20

> Hi=20 Sven,

>=20

> On 26 Nov = 2007, at=20 11:06, OOGHE Sven wrote:

>=20

> >=20 Woj,

>=20 >

> > From = what I can=20 find on the email list, the proposed=20 change

> to = section

> > 3.4.4 is = related=20 to the following remark from Sanjay (mid = September

> >=20 2007):

>=20 >

> > "The = option I=20 alluded to is IGMP from RG to BNG, and replication on=20

> > the AN. = The=20 replication state on the AN = created/controlled

> via ANCP by=20 BNG.

> > An = optimization=20 could be optional transparent snooping of

> IGMP on=20 the

> > AN to = act on IGMP=20 reports for leave only (to implement

> "fast=20 leave")."

>=20

> Right. This = is what=20 initiated the thread.

>=20

> I am also = aware of=20 other planned deployments where the Multicast joins=20

> are=20 processed by the device = behaving as=20 the ANCP-controller (as

> = opposed to the = AN).

>=20

> As = these ANCP deployments will exist, the ANCP = specs ought=20 to

> recognize and = allow=20 them. Note that this has very little impact on the =

> ANCP protocol = anyways=20 (since "spontaneous Admission Responses"

> are already = explicitly=20 allowed anyways for multicast termination)

>=20

>=20 >

 

 

 

------_=_NextPart_001_01C86282.9185C2D0-- --===============1591563642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1591563642==-- From ancp-bounces@ietf.org Tue Jan 29 13:46:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJvTs-0008TW-5o; Tue, 29 Jan 2008 13:46:48 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JJvTr-0008TQ-I7 for ancp-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 13:46:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJvTr-0008TI-7t for ancp@ietf.org; Tue, 29 Jan 2008 13:46:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJvTZ-0007z1-A6 for ancp@ietf.org; Tue, 29 Jan 2008 13:46:47 -0500 X-IronPort-AV: E=Sophos;i="4.25,270,1199692800"; d="scan'208,217";a="10446745" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 29 Jan 2008 10:46:28 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0TIkSY4017930; Tue, 29 Jan 2008 10:46:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m0TIkRox009855; Tue, 29 Jan 2008 18:46:28 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 10:46:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] ANCP Multicast Admission Control Date: Tue, 29 Jan 2008 10:46:38 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: AchiTcpQdkZkcJZHSPqNoeRqWG3TkQAVmpeA References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> From: "Philippe Champagne (pchamp)" To: "Sanjay Wadhwa" , "Francois Le Faucheur (flefauch)" , , X-OriginalArrivalTime: 29 Jan 2008 18:46:28.0342 (UTC) FILETIME=[41D24960:01C862A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=62162; t=1201632388; x=1202496388; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=EWsDMcokoe+lKGqQg925dh9XNq7sDW7iW1qwk7MLrkQ=; b=L1iqmcmAFu/6zeXcr0rtM4iMrZLJ1/MvSIPavSZcAWjRz9KkbBu+K69Bn/ gGdAqjX3YkMH+TkPn87aKhsi2h5nUYmf4uSt/1+7ILfPecFX/6RKcqHNcvEK LgFa22MBrB; Authentication-Results: sj-dkim-2; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 601f0d117306debc16e29ec95c56316a Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2088674247==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2088674247== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C862A7.4180CF1D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C862A7.4180CF1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sanjay Question on this first paragraph and suggestion on the 2nd: =20 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=20 is to be honored or denied. In case the Policy Server queries=20 the AN directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document. =20 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. =20 =20 In case the NAS terminates IGMP signaling from the subscriber and controls the=20 replication state on the AN, the CAC function can be completely contained within=20 the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,=20 perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based=20 on the available bandwidth, if the IGMP join can be honored, the NAS can set the=20 replication state on the AN using ANCP. The policy server may query the NAS to=20 perform admission control on a VoD flow, and update the available "video" bandwidth=20 maintained by the NAS. =20 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): =20 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.=20 =20 =20 =20 ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: Tuesday, January 29, 2008 3:06 AM To: Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: [ANCP] ANCP Multicast Admission Control =09 =09 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.=20 =20 Thanks -Sanjay =20 =20 3.4. Multicast =20 With the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important. =20 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. =20 To overcome this resource inefficiency, the Access Node, aggregation node(s) and the NAS must all be involved in the multicast =20 replication process. This avoids that several copies of the same=20 stream are sent within the access/aggregation network. In case of an=20 Ethernet-based access/aggregation network, this may, for example, be=20 achieved by means of IGMP snooping or IGMP proxy in the Access Node=20 and aggregation node(s). =20 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=20 and Access Node need to behave as a single logical device. This =20 logical device must have exactly the same functionality as the NAS=20 in the ATM access/aggregation network. The Access Node Control=20 Mechanism can be used to make sure that this logical/functional=20 equivalence is achieved by exchanging the necessary information=20 between the Access Node and the NAS. =20 Another option is for NAS to terminate IGMP signaling from the=20 subscriber. In this scenario, NAS can use ANCP to create replication=20 state in the AN for efficient multicast replication. The NAS sends a=20 single copy of the multicast stream towards the AN. The NAS can perform=20 conditional access and multicast admission control on IGMP joins, and create=20 replication state in the AN if the flow is admitted by the NAS. =20 The following subsections describe the different use cases related to multicast. =20 3.4.2. Multicast Admission Control =20 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. =20 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. =20 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). =20 Thus, supporting CAC for the access line requires some form of synchronization between the entity performing multicast CAC (e.g.=20 the NAS or the AN) and the entity performing unicast CAC (e.g. the=20 NAS or a Policy Server) and the entity actually enforcing the multicast replication (i.e. the AN). This synchronization can be=20 achieved in a number of ways: =20 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" =20 bandwidth on the access-loop, and perform "video" bandwidth=20 accounting for the access-loop. On receiving an admission request=20 from the AN, the NAS can check available "video" bandwidth before=20 admitting or denying the multicast flow. The policy server may=20 query the NAS to perform admission control on a VoD flow, and update the available "video" bandwidth maintained by the NAS. =20 Similarly to what has been discussed in the Conditional Access=20 use case, in response to a Admission Request from the AN for=20 admission control of a multicast flow, the NAS may send back an=20 Admission Response message to the AN, including admission control=20 information for that multicast flow, as well as for other a set=20 of multicast flows sharing the same admission control rules. =20 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; =20 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=20 is to be honored or denied. In case the Policy Server queries=20 the AN directly, the approach doesn't require the use of ANCP. =20 It is therefore beyond the scope of this document. =20 In case the NAS terminates IGMP signaling from the subscriber and controls the=20 replication state on the AN, the CAC function can be completely contained within=20 the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,=20 perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based=20 on the available bandwidth, if the IGMP join can be honored, the NAS can set the=20 replication state on the AN using ANCP. The policy server may query the NAS to=20 perform admission control on a VoD flow, and update the available "video" bandwidth=20 maintained by the NAS. =20 =20 -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 11:42 > To: OOGHE Sven > Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org;=20 > Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hi Sven, >=20 > On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >=20 > > 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=20 > > 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")." >=20 > Right. This is what initiated the thread. >=20 > I am also aware of other planned deployments where the Multicast joins=20 > are processed by the device behaving as the ANCP-controller (as=20 > opposed to the AN). >=20 > As these ANCP deployments will exist, the ANCP specs ought to=20 > recognize and allow them. Note that this has very little impact on the=20 > ANCP protocol anyways (since "spontaneous Admission Responses" > are already explicitly allowed anyways for multicast termination) >=20 > > =20 =20 =20 ------_=_NextPart_001_01C862A7.4180CF1D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sanjay

Question on this first paragraph and = suggestion on=20 the 2nd:
 
o  Another approach is the reverse: it consists of the Policy=20 Server
      querying the AN =
(either directly, or indirectly via the NAS) =
so
      that both =
unicast and multicast CAC for the access line =
are
      performed by =
the AN.  In this case, =
a subscriber request for a
      unicast flow (e.g. a Video on =
Demand session) will =
trigger a
      =
resource request message towards a Policy Server; the latter =
will
      then query the =
AN, that in turn will perform unicast CAC for =
the
      access line and =
respond, indicating whether the unicast request =

      is to be =
honored or denied.  In case the Policy Server queries =

      the AN =
directly, the approach doesn't require the use of =
ANCP.            =

      It is =
therefore beyond the scope of this =
document.
 
pchamp> So, this means ANCP will need to =
cover the case of admitting or denying on the AN a unicast flow rather =
than multicast flow...
ie: =
Policy Server quering the AN indirectly via the NAS.  Or you meant that =
only for the multicast part.
 
 
In case the =
NAS terminates IGMP signaling from the subscriber and controls the =

replication state on the AN, the CAC function can be completely =
contained within 
the NAS. NAS may locally maintain =
available "video" bandwidth on the access-loop, =

perform "video" bandwidth accounting, and perform CAC on the =
received IGMP. Based =

on the =
available bandwidth, if the IGMP join can be honored, the NAS can =
set the =

replication state on the AN using ANCP. The policy server may query the NAS to =

perform admission control on a VoD flow, and update the available =
"video" bandwidth 
maintained by the =
NAS.
 
pchamp> This paragraph should also add = some phrasing=20 to cover the case where IGMP is not involved but rather an out of band = protocol=20 (HTTP based). For example, the subscriber requesting a given = multicast on a=20 web page linked to the policy server. In turn it would direct the NAS to = submit=20 an admission control to the AN for that given multicast=20 flow.
This could be done by adding to the 2nd = paragraph,=20 the following statement (or close to it):
 
Another case would be where the subscriber = makes the=20 request using HTTP directly to a web server linked to the policy = server,=20 bypassing both AN and NAS. In such case, the admission request would = originate=20 from the policy server towards the NAS.
 
 
 

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: Tuesday, January 29, = 2008 3:06=20 AM
To: Francois Le Faucheur (flefauch);=20 Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org
Subject: [ANCP] = ANCP=20 Multicast Admission Control

Sven, Francois, and=20 All

  We agreed in the = attached=20 thread below that the framework draft needs to cover the = case where IGMP signaling from the = subscriber=20 terminates on the NAS, and the AN does not snoop IGMP joins. The NAS = performs=20 conditional access and admission control on the received IGMP joins, = and=20 controls the replication state on the AN using ANCP. However, this is = not=20 adequately reflected in the draft. The draft also does not consider = the=20 scenario where the bandwidth accounting and CAC function is completely = contained within the NAS (and doesn’t require complex = synchronization between=20 NAS and AN). I am proposing the following additions (in blue) to=20 sections 3.4 and 3.4.2.=20

 

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=20 Message-----

> From: = Francois Le=20 Faucheur IMAP [mailto:flefauch@cisco.com]

> Sent: = maandag 26=20 november 2007 11:42

> To: OOGHE=20 Sven

> Cc: = Francois Le=20 Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org;=20

> Maglione=20 Roberta

> Subject: = Re:=20 Spontaneous Admission Response (was=20 Re: [ANCP] ANCP WG

>=20 follow-up)

>=20

> Hi=20 Sven,

>=20

> On 26 Nov = 2007, at=20 11:06, OOGHE Sven wrote:

>=20

> >=20 Woj,

>=20 >

> > From = what I can=20 find on the email list, the proposed change

> to = section

> > 3.4.4 = is related=20 to the following remark from Sanjay (mid=20 September

> >=20 2007):

>=20 >

> > "The = option I=20 alluded to is IGMP from RG to BNG, and replication on=20

> > the = AN. The=20 replication state on the AN = created/controlled

> via ANCP by = BNG.

> > An = optimization=20 could be optional transparent snooping of

> IGMP on=20 the

> > AN to = act on=20 IGMP reports for leave only (to implement

> "fast=20 leave")."

>=20

> Right. This = is what=20 initiated the thread.

>=20

> I am also = aware of=20 other planned deployments where the Multicast joins=20

> are=20 processed by the device = behaving as=20 the ANCP-controller (as

> = opposed to the = AN).

>=20

> As = these ANCP deployments will exist, the ANCP = specs=20 ought to

> recognize = and allow=20 them. Note that this has very little impact on the=20

> ANCP = protocol anyways=20 (since "spontaneous Admission Responses"

> are already = explicitly allowed anyways for multicast=20 termination)

>=20

>=20 >

 

 

 

------_=_NextPart_001_01C862A7.4180CF1D-- --===============2088674247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============2088674247==-- From ancp-bounces@ietf.org Tue Jan 29 15:50:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJxPV-00057m-3O; Tue, 29 Jan 2008 15:50:25 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JJxPT-00053p-2K for ancp-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 15:50:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJxPS-000516-Ew for ancp@ietf.org; Tue, 29 Jan 2008 15:50:22 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJxPA-0005Pb-L3 for ancp@ietf.org; Tue, 29 Jan 2008 15:50:22 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Tue, 29 Jan 2008 12:49:57 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 12:49:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] ANCP Multicast Admission Control Date: Tue, 29 Jan 2008 15:49:37 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280CB25BDB@proton.jnpr.net> In-Reply-To: <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: AchiTcpQdkZkcJZHSPqNoeRqWG3TkQAVmpeAAATI3tA= References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> From: "Sanjay Wadhwa" To: "Philippe Champagne (pchamp)" , "Francois Le Faucheur (flefauch)" , , X-OriginalArrivalTime: 29 Jan 2008 20:49:49.0826 (UTC) FILETIME=[7D731E20:01C862B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ca2720074b80ba3fb5425b384f2e7fce Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0043131051==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0043131051== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C862B8.764E3A36" This is a multi-part message in MIME format. ------_=_NextPart_001_01C862B8.764E3A36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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). =20 -Sanjay ________________________________ From: Philippe Champagne (pchamp) [mailto:pchamp@cisco.com]=20 Sent: Tuesday, January 29, 2008 1:47 PM To: Sanjay Wadhwa; Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: RE: [ANCP] ANCP Multicast Admission Control =20 Hi Sanjay Question on this first paragraph and suggestion on the 2nd: =20 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=20 is to be honored or denied. In case the Policy Server queries=20 the AN directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document. =20 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. =20 =20 In case the NAS terminates IGMP signaling from the subscriber and controls the=20 replication state on the AN, the CAC function can be completely contained within=20 the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,=20 perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based=20 on the available bandwidth, if the IGMP join can be honored, the NAS can set the=20 replication state on the AN using ANCP. The policy server may query the NAS to=20 perform admission control on a VoD flow, and update the available "video" bandwidth=20 maintained by the NAS. =20 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): =20 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.=20 =20 =20 =20 =20 =09 ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: Tuesday, January 29, 2008 3:06 AM To: Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: [ANCP] ANCP Multicast Admission Control Sven, Francois, and All We agreed in the attached thread below that the framework draft needs to cover the case where IGMP signaling from the subscriber terminates on the NAS, and the AN does not snoop IGMP joins. The NAS performs conditional access and admission control on the received IGMP joins, and controls the replication state on the AN using ANCP. However, this is not adequately reflected in the draft. The draft also does not consider the scenario where the bandwidth accounting and CAC function is completely contained within the NAS (and doesn't require complex synchronization between NAS and AN). I am proposing the following additions (in blue) to sections 3.4 and 3.4.2.=20 =20 Thanks -Sanjay =20 =20 3.4. Multicast =20 With the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important. =20 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. =20 To overcome this resource inefficiency, the Access Node, aggregation node(s) and the NAS must all be involved in the multicast =20 replication process. This avoids that several copies of the same=20 stream are sent within the access/aggregation network. In case of an=20 Ethernet-based access/aggregation network, this may, for example, be=20 achieved by means of IGMP snooping or IGMP proxy in the Access Node=20 and aggregation node(s). =20 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=20 and Access Node need to behave as a single logical device. This =20 logical device must have exactly the same functionality as the NAS=20 in the ATM access/aggregation network. The Access Node Control=20 Mechanism can be used to make sure that this logical/functional=20 equivalence is achieved by exchanging the necessary information=20 between the Access Node and the NAS. =20 Another option is for NAS to terminate IGMP signaling from the=20 subscriber. In this scenario, NAS can use ANCP to create replication=20 state in the AN for efficient multicast replication. The NAS sends a=20 single copy of the multicast stream towards the AN. The NAS can perform=20 conditional access and multicast admission control on IGMP joins, and create=20 replication state in the AN if the flow is admitted by the NAS. =20 The following subsections describe the different use cases related to multicast. =20 3.4.2. Multicast Admission Control =20 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. =20 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. =20 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). =20 Thus, supporting CAC for the access line requires some form of synchronization between the entity performing multicast CAC (e.g.=20 the NAS or the AN) and the entity performing unicast CAC (e.g. the=20 NAS or a Policy Server) and the entity actually enforcing the multicast replication (i.e. the AN). This synchronization can be=20 achieved in a number of ways: =20 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" =20 bandwidth on the access-loop, and perform "video" bandwidth=20 accounting for the access-loop. On receiving an admission request=20 from the AN, the NAS can check available "video" bandwidth before=20 admitting or denying the multicast flow. The policy server may=20 query the NAS to perform admission control on a VoD flow, and update the available "video" bandwidth maintained by the NAS. =20 Similarly to what has been discussed in the Conditional Access=20 use case, in response to a Admission Request from the AN for=20 admission control of a multicast flow, the NAS may send back an=20 Admission Response message to the AN, including admission control=20 information for that multicast flow, as well as for other a set=20 of multicast flows sharing the same admission control rules. =20 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; =20 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=20 is to be honored or denied. In case the Policy Server queries=20 the AN directly, the approach doesn't require the use of ANCP. =20 It is therefore beyond the scope of this document. =20 In case the NAS terminates IGMP signaling from the subscriber and controls the=20 replication state on the AN, the CAC function can be completely contained within=20 the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,=20 perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based=20 on the available bandwidth, if the IGMP join can be honored, the NAS can set the=20 replication state on the AN using ANCP. The policy server may query the NAS to=20 perform admission control on a VoD flow, and update the available "video" bandwidth=20 maintained by the NAS. =20 =20 -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 11:42 > To: OOGHE Sven > Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org;=20 > Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hi Sven, >=20 > On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >=20 > > 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=20 > > 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")." >=20 > Right. This is what initiated the thread. >=20 > I am also aware of other planned deployments where the Multicast joins=20 > are processed by the device behaving as the ANCP-controller (as=20 > opposed to the AN). >=20 > As these ANCP deployments will exist, the ANCP specs ought to=20 > recognize and allow them. Note that this has very little impact on the=20 > ANCP protocol anyways (since "spontaneous Admission Responses" > are already explicitly allowed anyways for multicast termination) >=20 > > =20 =20 =20 ------_=_NextPart_001_01C862B8.764E3A36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:pchamp@cisco.com]
Sent: Tuesday, January = 29, 2008 1:47 PM
To: Sanjay Wadhwa; = Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org
Subject: RE: [ANCP] ANCP = Multicast Admission Control

 

Hi Sanjay


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

 

o  Another approach is the reverse: it consists = of the Policy Server

      querying the =
AN (either directly, or indirectly via the NAS) =
so
      that both =
unicast and multicast CAC for the access line =
are
      performed by =
the AN.  In this case, a subscriber request for =
a
      unicast flow =
(e.g. a Video on Demand session) will trigger =
a
      resource =
request message towards a Policy Server; the latter =
will
      then query the =
AN, that in turn will perform unicast CAC for =
the
      access line =
and respond, indicating whether the unicast request =

      is to be =
honored or denied.  In case the Policy Server queries =

      the AN =
directly, the approach doesn't require the use of =
ANCP.            =

      It is =
therefore beyond the scope of this =
document.
 
pchamp> So, this means ANCP will need to =
cover the case of admitting or denying on the AN a =
unicast flow rather than multicast =
flow...
ie: =
Policy Server quering the AN indirectly via the NAS.  Or you meant =
that only for the multicast =
part.
 
 
In case the NAS terminates IGMP signaling from =
the subscriber and controls the 
replication state on the AN, the =
CAC function can be completely contained within =

the NAS. NAS may locally maintain =
available "video" bandwidth on the access-loop, =

perform "video" =
bandwidth accounting, and perform CAC on the received IGMP. =
Based 
on the available bandwidth, if the =
IGMP join can be honored, the NAS can set the 
replication state on the AN using =
ANCP. The policy server may query the NAS to =

perform admission control on a VoD =
flow, and update the available "video" bandwidth =

maintained by the =
NAS.



 



pchamp> This paragraph should =
also add
some phrasing to cover the case where
IGMP is not involved but rather an out of band protocol =
(HTTP based). For example, the subscriber =
requesting a given
multicast on a web page linked to the policy server.
In turn it would direct the NAS to submit an admission control to the AN =
for
that given multicast flow.



This could be done by adding =
to the
2nd paragraph, the following statement (or close
to it):



 



Another case
would be where the subscriber makes the request using HTTP directly =
to a
web server linked to the =
policy server, bypassing both AN and NAS. In such =
case, the admission request would originate =
from the
policy server towards the =
NAS. 



 



 



 






 












From: Sanjay
Wadhwa [mailto:swadhwa@juniper.net] 

Sent: Tuesday, January =
29, 2008
3:06 AM

To: Francois Le Faucheur
(flefauch); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org

Subject: [ANCP] ANCP =
Multicast
Admission Control



Sven, Francois, and All



  We agreed in the attached thread below that =
the
framework draft needs to cover the case
where IGMP signaling from the subscriber terminates on the NAS, and the =
AN does
not snoop IGMP joins. The NAS performs conditional access and admission =
control
on the received IGMP joins, and controls the replication state on the AN =
using
ANCP. However, this is not adequately reflected in the draft. The draft =
also
does not consider the scenario where the bandwidth accounting and CAC =
function
is completely contained within the NAS (and doesn’t require =
complex
synchronization between NAS and AN). I am proposing the following =
additions (in
blue) to sections 3.4 and =
3.4.2. 



 



Thanks



-Sanjay



 



 



3.4. =
Multicast
 
   With the rise of supporting IPTV services in a resource =
efficient
   way, multicast services are getting increasingly =
important.
 
   In case of an ATM access/aggregation network, =
such as the reference
   architecture specified in DSL =
Forum [TR-059], multicast =
traffic
   replication is performed in the =
NAS.  In this model, typically =
IGMP
   is used to control the multicast replication =
process towards the
   subscribers.  The NAS =
terminates and processes IGMP =
signaling
   messages sent by the subscribers; towards the =
Regional Network, the
   NAS typically uses a multicast routing protocol such as =
PIM. The ATM
   Access Nodes and aggregation =
switches don't perform IGMP =
processing,
   nor do they perform multicast =
traffic replication.  As a =
result,
   network resources are wasted =
within the access/aggregation =
network.
 
   To overcome this resource =
inefficiency, the Access Node, =
aggregation
   node(s) and the NAS must all be =
involved in the multicast   =

   replication process. This =
avoids that several copies of the same =

   stream are sent within the access/aggregation network. =
In case of an =

   Ethernet-based access/aggregation network, this may, =
for example, be 
   achieved by means of IGMP =
snooping or IGMP proxy in the Access Node =

   and aggregation =
node(s).
 
   By introducing IGMP processing =
in the access/aggregation nodes, =
the
   multicast replication process is =
now divided between the NAS, =
the
   aggregation node(s) and Access =
Nodes.  In order to ensure =
backward
   compatibility with the =
ATM-based model, the NAS, aggregation node =

   and Access Node need to =
behave as a single logical device.  This    =

   logical device must have =
exactly the same functionality as the NAS =

   in the ATM =
access/aggregation network. The Access Node Control =

   Mechanism can be =
used to make sure that this =
logical/functional 
   equivalence is achieved by =
exchanging the necessary information =

   between the Access Node and =
the NAS.
 
   Another option is for NAS to =
terminate IGMP signaling from the =

   subscriber. In =
this scenario, NAS can use ANCP to create replication =

   state in the AN =
for efficient multicast replication. The NAS sends a =

   single copy of =
the multicast stream towards the AN. The NAS can perform =

   conditional =
access and multicast admission control on IGMP joins, and create =

   replication =
state in the AN if the flow is admitted by the =
NAS.
   =

   The following =
subsections describe the different =
use cases related to =
multicast.



 



3.4.2. Multicast Admission =
Control
 
   The successful delivery of =
Triple Play Broadband services is =
quickly
   becoming a big capacity planning =
challenge for most of the =
Service
   Providers nowadays.  Solely =
increasing available bandwidth is =
not
   always practical, =
cost-economical and/or sufficient to satisfy =
end
   user experience given not only the strict =
requirements of unicast
   delay sensitive applications like VoIP and Video, =
but also the fast
   growth of multicast interactive =
applications such as
   videoconferencing, digital TV, =
digital audio, online movies =
and
   networked gaming.  =
These applications are typically characterized =
by
 =
  a delay sensitive nature, an extremely loss =
sensitive nature =
and
   intensive bandwidth =
requirements.  They are also typically =
"non-
   elastic", which means that =
they operate at a fixed bandwidth, =
that
   cannot be dynamically adjusted =
to the currently available =
bandwidth.
 
   Therefore a Connection Admission =
Control (CAC) mechanism =
covering
   admission of multicast traffic =
over the DSL Broadband access =
is
   required, in order to avoid =
oversubscribing the available =
bandwidth
   and negatively impacting the end =
user =
experience.
 
   Considering specifically =
admission control over the access =
line,
   before honoring a =
user request to join a new multicast flow, =
the
   combination of AN and NAS MUST =
ensure admission control is =
performed
   to validate that there is enough =
"video" bandwidth remaining on =
the
   access line to carry the new =
flow (in addition to all other =
existing
   multicast and unicast video =
traffic).  The solution needs to =
cope
   with multiple flows per access =
line and needs to allow access =
line
   bandwidth to be dynamically =
shared across multicast and =
unicast
   traffic (irrespective of whether =
unicast CAC is performed by NAS =
or
   by some off-path Policy =
Server).
 
   Thus, supporting CAC for the =
access line requires some form =
of
   synchronization between the =
entity performing multicast CAC (e.g. =

   the NAS or the AN) =
and the entity performing unicast CAC (e.g. the =

   NAS or a Policy Server) and =
the entity actually enforcing the =

   multicast replication (i.e. =
the AN). This synchronization can be =

   achieved in a number of =
ways:
 
   o  One approach is for the =
AN to query the NAS so that both =
unicast
      and multicast =
CAC for the access line are performed by the =
NAS.
      In this =
case, the AN can use ANCP to query the NAS, that in =
turn
      performs =
multicast CAC and responds to the AN indicating =
whether
      the join is to =
be honored (and hence replication performed by =
the
      AN) or =
denied.  In the process, the NAS may =
communicate with =
a
      Policy =
Server.  The NAS may locally maintain =
available "video"  =

      =
;bandwidth on the access-loop, and perform "video" bandwidth =

      =
;accounting for the access-loop. On receiving an admission request =

      =
;from the AN, the NAS can check available "video" bandwidth =
before 
      =
;admitting or denying the multicast flow. The policy server may =

      =
;query the NAS to perform admission control on a VoD flow, and =
update
      the =
available “video” bandwidth maintained by the =
NAS.
    =

      Similarly =
to what has been discussed in the Conditional Access =

      use case, in response to a Admission Request from the AN for =

      admission =
control of a multicast flow, the NAS may send back an =

      Admission =
Response message to the AN, including admission =
control 
      informatio=
n for that multicast flow, as well as for other a set =

      of =
multicast flows sharing the same admission control rules.  =

      The AN =
can then autonomously honor or =
deny
      requests for a =
given user/port for the set of Multicast flows =
as
      indicated in =
the Admission Response message.  The =
ANCP
      requirements =
to support this approach (where the AN queries =
the
      NAS) are =
specified in this document;
 
   o  Another approach is the =
reverse: it consists of the Policy =
Server
      querying the =
AN (either directly, or indirectly via the NAS) =
so
      that both =
unicast and multicast CAC for the access line =
are
      performed by =
the AN.  In this case, a subscriber request for =
a
      unicast flow =
(e.g. a Video on Demand session) will trigger =
a
      resource =
request message towards a Policy Server; the latter =
will
      then query the =
AN, that in turn will perform unicast CAC for =
the
      access line =
and respond, indicating whether the unicast request =

      is to be =
honored or denied.  In case the Policy Server queries =

      the AN =
directly, the approach doesn't require the use of =
ANCP.            =

      It is =
therefore beyond the scope of this =
document.
 
In case the NAS terminates IGMP signaling from =
the subscriber and controls the 
replication state on the AN, the =
CAC function can be completely contained within =

the NAS. NAS may locally maintain =
available "video" bandwidth on the access-loop, =

perform "video" =
bandwidth accounting, and perform CAC on the received IGMP. =
Based 
on the available bandwidth, if the =
IGMP join can be honored, the NAS can set the 
replication state on the AN using =
ANCP. The policy server may query the NAS to =

perform admission control on a VoD =
flow, and update the available "video" bandwidth =

maintained by the =
NAS.



 



 



-----Original =
Message-----



> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]



> Sent: maandag 26 november 2007 =
11:42



> To: OOGHE =
Sven



> Cc: Francois Le Faucheur IMAP; Wojciech =
Dec
(wdec); ancp@ietf.org; 



> Maglione =
Roberta



> Subject: Re: Spontaneous Admission =
Response (was Re: [ANCP] ANCP =
WG



> follow-up)



> 



> Hi Sven,



> 



> On 26 Nov 2007, at 11:06, OOGHE Sven =
wrote:



> 



> > Woj,



> >



> > From what I can find on the email =
list,
the proposed =
change



> to section



> > 3.4.4 is related to the following =
remark
from Sanjay (mid September



> > 2007):



> >



> > "The option I alluded to is =
IGMP from
RG to BNG, and replication on 



> > the AN. The replication state on =
the AN
created/controlled



> via ANCP by =
BNG.



> > An optimization could be optional
transparent snooping of



> IGMP on the



> > AN to act on IGMP reports for leave =
only
(to implement



> "fast =
leave")."



> 



> Right. This is what initiated the =
thread.



> 



> I am also aware of other planned =
deployments
where the Multicast joins 



> are processed
by the device behaving as the ANCP-controller (as =




> opposed
to the AN).



> 



> As these
ANCP deployments will exist, the ANCP specs ought to =




> recognize and allow them. Note that this =
has
very little impact on the 



> ANCP protocol anyways (since =
"spontaneous
Admission Responses"



> are already explicitly allowed anyways =
for
multicast termination)



> 



> >



 



 



 
------_=_NextPart_001_01C862B8.764E3A36-- --===============0043131051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0043131051==-- From ancp-bounces@ietf.org Wed Jan 30 05:16:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK9zx-0003u4-1s; Wed, 30 Jan 2008 05:16:53 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JK9zv-0003tx-W6 for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 05:16:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK9zv-0003to-Fk for ancp@ietf.org; Wed, 30 Jan 2008 05:16:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK9zq-0006No-7W for ancp@ietf.org; Wed, 30 Jan 2008 05:16:51 -0500 X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="scan'208,217";a="4360939" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2008 11:16:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0UAGjEv026173; Wed, 30 Jan 2008 11:16:45 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0UAGHlV016217; Wed, 30 Jan 2008 10:16:36 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 11:16:35 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 11:16:34 +0100 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280CB25BDB@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> <9BD5D7887235424FA97DFC223CAE3C280CB25BDB@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 11:16:30 +0100 To: Sanjay Wadhwa X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 30 Jan 2008 10:16:34.0653 (UTC) FILETIME=[30F990D0:01C86329] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=100263; t=1201688205; x=1202552205; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=dYVrbLlSz06fE39W+fGA44I7ENYiFDk9okSVMFpgjSA=; b=JPadfUFObOOyVHqJecxBBlf/f7oNd6yy+2RO3DQEer6/c717u2Wa/gyOYE 5yTies1WtzSD02rsQeBwNzVTd0ruJI0veB21D77aTiOgxxVPnWwWPrig9MZC UPtLxYCdWJ; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 3.0 (+++) X-Scan-Signature: 24b769f8c6a8f12549776dc2ab453761 Cc: ancp@ietf.org, Sven.Ooghe@alcatel-lucent.be X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716749760==" Errors-To: ancp-bounces@ietf.org --===============0716749760== Content-Type: multipart/alternative; boundary=Apple-Mail-2-42691172 --Apple-Mail-2-42691172 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hello Sanjay, I support your proposed changes with one small exception which is the =20= deletion of the following statement: "In the process, the NAS may =20 communicate with the Policy Server". I think we should keep this =20 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 =20 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 =20 termination of IGMP from subscriber, or via application level =20 signaling + via Policy Server, it is really all transparent to ANCP. =20 So, as far as text editing is concerned, perhaps all these cases =20 could be simply described as one single generic case characterized by =20= the fact that NAS processes individual subscriber Join/Leave =20 information somehow (and only mention the cases of (i) direct =20 subscriber IGMP termination and (ii) user--->web-->Policy-Server--=20 >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 =20= > the policy server queries AN. This was already in the framework =20 > draft (I actually have misgivings about this approach). I am =20 > proposing the alternative where CAC is done on the NAS. The text =20 > that I suggested is in blue (the rest of the sorrounding text is =20 > already in the framework draft). > I am fine with including your suggestion on policy-server =20 > originating an admission request to the NAS (when triggered via =20 > application level signaling rather than IGMP). > > -Sanjay > From: Philippe Champagne (pchamp) [mailto:pchamp@cisco.com] > Sent: Tuesday, January 29, 2008 1:47 PM > To: Sanjay Wadhwa; Francois Le Faucheur (flefauch); =20 > Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org > Subject: RE: [ANCP] ANCP Multicast Admission Control > > Hi Sanjay > > Question on this first paragraph and suggestion on the 2nd: > > o Another approach is the reverse: it consists of the Policy Server > querying the AN (either directly, or indirectly via the NAS) so > that both unicast and multicast CAC for the access line are > performed by the AN. In this case, a subscriber request for a > unicast flow (e.g. a Video on Demand session) will trigger a > resource request message towards a Policy Server; the latter =20 > will > then query the AN, that in turn will perform unicast CAC for the > access line and respond, indicating whether the unicast request > is to be honored or denied. In case the Policy Server queries > the AN directly, the approach doesn't require the use of ANCP. > It is therefore beyond the scope of this document. > > pchamp> So, this means ANCP will need to cover the case of =20 > admitting or denying on the AN a unicast flow rather than multicast =20= > flow... > ie: Policy Server quering the AN indirectly via the NAS. Or you =20 > meant that only for the multicast part. > > > In case the NAS terminates IGMP signaling from the subscriber and =20 > controls the > replication state on the AN, the CAC function can be completely =20 > contained within > the NAS. NAS may locally maintain available "video" bandwidth on =20 > the access-loop, > perform "video" bandwidth accounting, and perform CAC on the =20 > received IGMP. Based > on the available bandwidth, if the IGMP join can be honored, the =20 > NAS can set the > replication state on the AN using ANCP. The policy server may query =20= > the NAS to > perform admission control on a VoD flow, and update the available =20 > "video" bandwidth > maintained by the NAS. > > pchamp> This paragraph should also add some phrasing to cover the =20 > case where IGMP is not involved but rather an out of band protocol =20 > (HTTP based). For example, the subscriber requesting a given =20 > multicast on a web page linked to the policy server. In turn it =20 > would direct the NAS to submit an admission control to the AN for =20 > that given multicast flow. > This could be done by adding to the 2nd paragraph, the following =20 > statement (or close to it): > > Another case would be where the subscriber makes the request using =20 > HTTP directly to a web server linked to the policy server, =20 > bypassing both AN and NAS. In such case, the admission request =20 > would originate from the policy server towards the NAS. > > > > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: Tuesday, January 29, 2008 3:06 AM > To: Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be; =20 > ancp@ietf.org > Subject: [ANCP] ANCP Multicast Admission Control > Sven, Francois, and All > We agreed in the attached thread below that the framework draft =20 > needs to cover the case where IGMP signaling from the subscriber =20 > terminates on the NAS, and the AN does not snoop IGMP joins. The =20 > NAS performs conditional access and admission control on the =20 > received IGMP joins, and controls the replication state on the AN =20 > using ANCP. However, this is not adequately reflected in the draft. =20= > The draft also does not consider the scenario where the bandwidth =20 > accounting and CAC function is completely contained within the NAS =20 > (and doesn=92t require complex synchronization between NAS and AN). I =20= > am proposing the following additions (in blue) tosections 3.4 and =20 > 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 =20= > ATM > Access Nodes and aggregation switches don't perform IGMP =20 > 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, =20 > 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 =20 > of an > Ethernet-based access/aggregation network, this may, for =20 > 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 =20 > replication > state in the AN for efficient multicast replication. The NAS =20 > sends a > single copy of the multicast stream towards the AN. The NAS can =20 > perform > conditional access and multicast admission control on IGMP =20 > joins, and create > replication state in the AN if the flow is admitted by the NAS. > > The following subsections describe the different use cases =20 > related to multicast. > > 3.4.2. Multicast Admission Control > > The successful delivery of Triple Play Broadband services is =20 > 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 =20 > 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 =20 > 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 =20 > performed > to validate that there is enough "video" bandwidth remaining on the > access line to carry the new flow (in addition to all other =20 > 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 =20= > 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 =20 > request > from the AN, the NAS can check available "video" bandwidth =20 > before > admitting or denying the multicast flow. The policy server may > query the NAS to perform admission control on a VoD flow, and =20= > update > the available =93video=94 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 =20 > 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 =20 > 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 =20 > 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 =20 > controls the > replication state on the AN, the CAC function can be completely =20 > contained within > the NAS. NAS may locally maintain available "video" bandwidth on =20 > the access-loop, > perform "video" bandwidth accounting, and perform CAC on the =20 > received IGMP. Based > on the available bandwidth, if the IGMP join can be honored, the =20 > NAS can set the > replication state on the AN using ANCP. The policy server may query =20= > the NAS to > perform admission control on a VoD flow, and update the available =20 > "video" bandwidth > maintained by the NAS. > > > -----Original Message----- > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > > Sent: maandag 26 november 2007 11:42 > > To: OOGHE Sven > > Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; > > Maglione Roberta > > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > > follow-up) > > > > Hi Sven, > > > > On 26 Nov 2007, at 11:06, OOGHE Sven wrote: > > > > > Woj, > > > > > > =46rom 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 =20 > September > > > 2007): > > > > > > "The option I alluded to is IGMP from RG to BNG, and =20 > 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 =20 > 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 =20 > on the > > ANCP protocol anyways (since "spontaneous Admission Responses" > > are already explicitly allowed anyways for multicast termination) > > > > > > > > --Apple-Mail-2-42691172 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 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.=A0
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=A0characterized=A0by=A0the=A0fact 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, =A0as practical examples of = the generic case).

Cheers

Francois



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

Hi = Philippe
=A0 I am not suggesting the approach where CAC is done by = the AN, and the policy=A0server 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).
=A0
=A0Philippe Champagne (pchamp) = [mailto:pchamp@cisco.com]=A0
Sent:=A0Tuesday, January 29, 2008 1:47 = PM
To:=A0Sanjay Wadhwa; Francois Le = Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be<= /a>; ancp@ietf.org
Subject:=A0RE: [ANCP] ANCP Multicast = Admission Control
=A0
Hi Sanjay

Question on this first paragraph and = suggestion on the 2nd:
=A0
o=A0 Another approach is the reverse: it = consists of the Policy Server
=A0=A0=A0=A0=A0 that both unicast =
and multicast CAC for the access line =
are
=A0=A0=A0=A0=A0 performed by the =
AN.=A0 In this case, a subscriber request for =
a
=A0=A0=A0=A0=A0 unicast flow =
(e.g. a Video on Demand session) will trigger =
a
=A0=A0=A0=A0=A0 resource request =
message towards a Policy Server; the latter =
will
=A0=A0=A0=A0=A0 then query the =
AN, that in turn will perform unicast CAC for =
the
=A0=A0=A0=A0=A0 access line and =
respond, indicating whether the unicast request =

=A0=A0=A0=A0=A0=A0is to be =
honored or denied.=A0 In case the Policy Server queries =

=A0=A0=A0=A0=A0=A0the AN =
directly, the approach doesn't require the use of ANCP.=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 
=A0=A0=A0=A0=A0=A0I=
t is therefore beyond the scope of this =
document.
pchamp> So, this means ANCP =
will need to cover the case =
of admitting or denying on the AN a unicast flow rather than multicast =
flow...
ie: Policy Server quering the AN =
indirectly via the NAS.=A0 Or you meant that only for the multicast =
part.
In =
case the NAS terminates =
IGMP signaling from the subscriber and controls the =

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 =

=A0
pchamp> = This paragraph should also add some phrasing to cover the = case=A0where IGMP is not involved but = rather an out of band protocol (HTTP=A0based). For example, the subscriber = requesting a given multicast on a web page linked to the policy=A0server. 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=A0the 2nd paragraph, the = following statement (or close=A0to = it):
Another case=A0would be where the subscriber = makes the request using HTTP=A0directly to a web=A0server linked to the policy=A0server, bypassing both AN and NAS. In such = case, the admission request = would originate from the policy=A0server towards the = NAS.
=A0
From:=A0Sanjay Wadhwa [mailto:swadhwa@juniper.net]=A0
Sent:=A0Tuesday, January 29, 2008 3:06 = AM
To:=A0Francois Le Faucheur = (flefauch); Sven.Ooghe@alcatel-lucent.be<= /a>; ancp@ietf.org
Subject:=A0[ANCP] ANCP Multicast = Admission Control
=A0 We agreed in the attached thread below = that the framework draft needs to cover the case=A0where 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=92t = require complex synchronization between NAS and AN). I am proposing the = following additions (in blue) tosections 3.4 and = 3.4.2.
3.4. = Multicast
=A0=A0 With the rise of supporting IPTV services in a resource =
efficient
=A0=A0 way, multicast =
services are getting =
increasingly important.
=A0=A0 In case of an ATM access/aggregation network, =
such as the reference
=A0=A0 replication is performed =
in the NAS.=A0 In this model, typically =
IGMP
=A0=A0 is used to control the multicast replication =
process towards the
ses IGMP =
signaling
=A0=A0 messages sent by the subscribers; towards the =
Regional Network, the
ses =
a multicast routing protocol such as PIM. The =
ATM
=A0=A0 Access Nodes and =
aggregation switches don't perform IGMP =
processing,
=A0=A0 nor do they perform =
multicast traffic replication.=A0 As a =
result,
=A0=A0 network resources are =
wasted within the access/aggregation =
network.
=A0=A0 To overcome this resource =
inefficiency, the Access Node, =
aggregation
=A0=A0 node(s) and the NAS must =
all be involved in the multicast=A0=A0 =

=A0=A0=A0replication process. =
This avoids that several =
copies of the same 
sent =
within the access/aggregation network. In case of an =

=A0=A0=A0Ethernet-based access/aggregation network, this may, =
for example, be 
=A0=A0=A0achieved =
by means of IGMP snooping or IGMP proxy in the Access Node =

=A0=A0=A0and aggregation =
node(s).
=A0=A0 By introducing IGMP =
processing in the access/aggregation nodes, =
the
=A0=A0 multicast replication =
process is now divided between the NAS, =
the
=A0=A0 aggregation node(s) and =
Access Nodes.=A0 In order to ensure =
backward
=A0=A0 compatibility with the =
ATM-based model, the NAS, =
aggregation node 
=A0=A0=A0and =
Access Node need to behave as a single logical device.=A0 This=A0=A0=A0 =

=A0=A0=A0logical device must have =
exactly the same functionality as the NAS =

=A0=A0=A0in the ATM =
access/aggregation network. The Access Node Control =

=A0=A0=A0Mechanism can be =
used to make sure that this =
logical/functional 
=A0=A0=A0between =
the Access Node and the NAS.
=A0=A0 Another option is for NAS to terminate IGMP =
signaling from the 
=A0=A0=A0subscriber. In this =
scenario, NAS can use ANCP =
to create replication 
=A0=A0=A0state in the AN for =
efficient multicast replication. The NAS sends a 
=A0=A0=A0single copy of the =
multicast stream towards the AN. The NAS can perform =

=A0=A0=A0replication state in the AN if the flow is =
admitted by the NAS.
=A0=A0=A0The following =
subsections describe the =
different use =
cases related to =
multicast.
3.4.2. Multicast Admission = Control
=A0=A0 The successful delivery of =
Triple Play Broadband services is =
quickly
=A0=A0 becoming a big capacity =
planning challenge for most of the =
Service
=A0=A0 Providers nowadays.=A0 =
Solely increasing available bandwidth is =
not
=A0=A0 always practical, =
cost-economical and/or sufficient to satisfy =
end
=A0=A0 user experience given not only the strict =
requirements of unicast
sensitive =
applications like VoIP and Video, but also the =
fast
=A0=A0 growth of multicast =
interactive applications such as
=A0=A0 networked gaming.=A0 =
These applications are =
typically characterized by
sensitive =
nature, an extremely loss sensitive nature =
and
=A0=A0 intensive bandwidth =
requirements.=A0 They are also typically =
"non-
=A0=A0 elastic", which means that =
they operate at a fixed bandwidth, =
that
=A0=A0 cannot be dynamically =
adjusted to the currently available =
bandwidth.
=A0=A0 Therefore a Connection =
Admission Control (CAC) mechanism =
covering
=A0=A0 admission of multicast =
traffic over the DSL Broadband access =
is
=A0=A0 required, in order to =
avoid oversubscribing the available =
bandwidth
=A0=A0 and negatively impacting =
the end user =
experience.
=A0=A0 Considering specifically =
admission control over the access =
line,
=A0=A0 before honoring a =
user request to join a new =
multicast flow, the
=A0=A0 to validate that there is =
enough "video" bandwidth remaining on =
the
=A0=A0 access line to carry the =
new flow (in addition to all other =
existing
=A0=A0 multicast and unicast =
video traffic).=A0 The solution needs to =
cope
=A0=A0 with multiple flows per =
access line and needs to allow access =
line
=A0=A0 bandwidth to be =
dynamically shared across multicast and =
unicast
=A0=A0 traffic (irrespective of =
whether unicast CAC is performed by NAS =
or
=A0=A0 by some off-path Policy =
Server).
=A0=A0 Thus, supporting CAC for =
the access line requires some form of
=A0=A0=A0the NAS or the AN) and the entity =
performing unicast CAC (e.g. the 
=A0=A0=A0multicast replication =
(i.e. the AN). This synchronization can be =

=A0=A0=A0achieved in a number of =
ways:
=A0=A0 o=A0 One approach is for =
the AN to query the NAS so that both =
unicast
=A0=A0=A0=A0=A0 and multicast CAC =
for the access line are performed by the =
NAS.
=A0=A0=A0=A0=A0 In this =
case, the AN can =
use ANCP to query the NAS, =
that in turn
=A0=A0=A0=A0=A0 =
performs multicast CAC and responds to the AN indicating =
whether
=A0=A0=A0=A0=A0 the join is to be =
honored (and hence replication performed by =
the
=A0=A0=A0=A0=A0 AN) or denied.=A0 =
In the process, =
the NAS may communicate with =
a
The NAS may locally maintain available "video"=A0 =

=A0=A0=A0=A0=A0=A0bandwidth on the access-loop, and =
perform "video" bandwidth 
=A0=A0=A0=A0=A0=A0accounting =
for the access-loop. On receiving an admission request =

=A0=A0=A0=A0=A0=A0admitting or denying the multicast =
flow. The policy server may =

=A0=A0=A0=A0=A0 the available =93video=94 bandwidth =
maintained by the NAS.
=A0=A0=A0=A0=A0=A0S=
imilarly to what has been discussed in the Conditional Access =

=A0=A0=A0=A0=A0=A0use case, in response to a Admission Request from the AN for =

=A0=A0=A0=A0=A0=A0admission =
control of a multicast flow, the NAS may send back an =

=A0=A0=A0=A0=A0=A0Admission =
Response message to the AN, =
including admission control 
set =

=A0=A0=A0=A0=A0=A0of multicast =
flows sharing the same admission control rules.=A0 =

=A0=A0=A0=A0=A0=A0The AN can then =
autonomously honor or deny
ser/port for the set of Multicast flows =
as
=A0=A0=A0=A0=A0 indicated in the =
Admission Response =
message.=A0 The ANCP
=A0=A0=A0=A0=A0 NAS) are =
specified in this document;
=A0=A0 o=A0 Another approach is =
the reverse: it consists of =
the Policy Server
=A0=A0=A0=A0=A0 =
querying the AN (either directly, or indirectly via the NAS) =
so
=A0=A0=A0=A0=A0 that both unicast =
and multicast CAC for the access line =
are
=A0=A0=A0=A0=A0 performed by the =
AN.=A0 In this case, a =
subscriber request for a
session) will trigger =
a
=A0=A0=A0=A0=A0 resource request =
message towards a Policy Server; the latter =
will
=A0=A0=A0=A0=A0 then query the =
AN, that in turn will perform unicast CAC for =
the
=A0=A0=A0=A0=A0 access line and =
respond, indicating whether the unicast request =

=A0=A0=A0=A0=A0=A0is to be =
honored or denied.=A0 In case=
 the Policy Server queries 
se of ANCP.=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 
=A0=A0=A0=A0=A0=A0I=
t is therefore beyond the scope of this =
document.
In =
case the NAS terminates =
IGMP signaling from the subscriber and controls the =

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 =

=A0
=A0
-----Original = Message-----
> From: Francois Le Faucheur IMAP [> Sent: maandag 26 november 2007 = 11:42
> Cc: Francois Le Faucheur IMAP; Wojciech Dec = (wdec); ancp@ietf.org;<= /div>
> Maglione = Roberta
> = Subject: Re: Spontaneous Admission Response=A0(was Re: [ANCP] ANCP = WG
> = follow-up)
> = Hi Sven,
> = On 26 Nov 2007, at 11:06, OOGHE Sven = wrote:
> = > Woj,
> = >
> = > =46rom what I can find on the email list, the proposed = change
> = to=A0section
> > 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=A0ANCP 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)
> = >
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAYv-0007kP-I4; Wed, 30 Jan 2008 05:53:01 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKAYu-0007kD-Nn for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 05:53:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAYu-0007k4-BJ for ancp@ietf.org; Wed, 30 Jan 2008 05:53:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKAYs-0007J8-TU for ancp@ietf.org; Wed, 30 Jan 2008 05:53:00 -0500 X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="scan'208";a="4367133" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2008 11:52:58 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0UAqvqT030468; Wed, 30 Jan 2008 11:52:57 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0UAqtlJ003181; Wed, 30 Jan 2008 10:52:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 11:52:55 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 11:52:54 +0100 In-Reply-To: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 11:52:50 +0100 To: OOGHE Sven X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 30 Jan 2008 10:52:54.0774 (UTC) FILETIME=[446DA160:01C8632E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10769; t=1201690377; x=1202554377; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=3qrouwF9+WBOgwHeGNYde46QFFHWVsA9s28bLf67juU=; b=lvT6lRwld6mpczBuwJJWVEz/EdA2EG9W19j9UNf4P2HuLI7SQa75ZSvBBe 4bYPBeWQQT5yeJ+7Cw80SrZRFo1yVKY5W/bhxTm0mPuO1lqLuqsTS+PqXtci mEZALqPQf5; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hello Sven, The first bullet point in section 3.4.2 (starting by "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") was introduced to discuss the scenario of immediate interest for ANCP and to be covered by the first version of the ANCP requirement & protocol specs. This is why that bullet point finishes by the following statement: "The ANCP requirements to support this approach (where the AN queries the NAS) are specified in this document;" The second bullet point in section 3.4.2 (starting by "Another approach is the reverse") had really been added as background information discussing alternative approaches for achieving CAC, that were outside the scope of the first version of the ANCP requirement & protocol specs. This is why that bullet point finishes by the following statement: "It is therefore beyond the scope of this document." I recommend we do not change the scope of the first version of the ANCP documents at this stage and do not try to cover additional models. It seems there is enough in scope for the protocol design team to address in targeted timeframe for first version. If the WG decides later that those are useful additional models, they can be added then. In addition, it is not clear to me how useful these additional models are. It also raises a number of questions. For example, if the Policy Server wants to query the AN, should it do so via the NAS instead of directly to AN? Also, to be able to perform complete Video CAC, the AN would have to maintain user policy information (eg what is the fraction of line bandwidth that can be used for Video for that subscriber at that point in time considering the current DSL train rate). Is this in line with current ANCP model? how is user info made available to AN? What impact does all this have on ANCP? While we can start discussing those questions and the usefulness of such a model, IMHO this should not delay progress of current ANCP documents. So in short, I do _not_ support the additional text below relating to the introduction of the new additional model (PS-->NAS-->AN) and corresponding additional ANCP requirements. Cheers Francois On 28 Jan 2008, at 14:18, OOGHE Sven wrote: > Hi, > > Based on the discussion on the list, I have prepared the following > text > proposal concerning multicast conditional access. I tried to cover the > different scenarios that were identified on the list. This includes > the > proposal from Tina and Roberta, and feedback from Stefaan. > > If nobody objects, I will use the text below to update the text in > section 3.4.2 in the ANCP Framework. I will also add the corresponding > requirements in section 4.2 (ANCP), 4.7.6 (Access Node) and 4.8.6 > (NAS). > > Regards, > Sven > > --- > > << Section 3.4.2 >> > > 3.4.2. Multicast Admission Control > > << first part of the section remains unchanged. The text from the > second > bullet onward is updated with below text >> > > 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. > > The second scenario can be split in to cases: > > o 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. > > o In case the Policy Server queries the AN indirectly via the NAS, > the interaction can be handled as an ANCP transaction. When the > Policy Server queries the NAS, the NAS can use ANCP to query the > AN, specifying the Access-Loop-Circuit-ID and the required > bandwidth for the requested unicast flow. Upon receiving the > query from the NAS, the AN then performs Admission Control and > responds to the NAS, indicating if this unicast VoD request > can be > accepted or denied. > > 3.4.2.1. When not to perform Admission Control > > In general, the Access Node and NAS may not be aware of all > possible > multicast groups that will be streamed in the access network. For > instance, it is likely that there will be multicast streams offered > across the Internet. For these unknown streams, performing > bandwidth > admission control may be challenging. > > To solve this, these requests could be accepted without performing > Admission Control. This solution works, provided that the network > handles the streams as best effort, so that other streams are not > impacted at times of congestion. > > Disabling Admission Control for unknown stream can be achieved by > adding a "catch-all statement" in the Access Node white list or > grey > list. In case the Access Node queries the NAS, the NAS on his turn > will have to accept the request. That way, the unknown streams are > not blocked by default. > > Next, in order to ensure that the streams are handled as best > effort, > the flow must be marked as such when entering the service provider > network. This way, whenever congestion occurs somewhere in the > access/aggregation network, this stream will be kicked out > before the > access provider's own premium content. > > The above concept is applicable beyond the notion of "Internet > streams" or other unknown streams; it can applied to known > multicast > streams as well. In this case, the Access Node or NAS will accept > the stream even when bandwidth may not be sufficient to support the > stream. This again requires that the stream is marked as best > effort > traffic before entering the access/aggregation network. > > 3.4.2.2. Multicast Admission Control and White Lists > > As mentioned in section Section 3.4.1, conditional access to > popular > IPTV channels can be achieved by means of a White and Black list > configured on the Access Node. This method allows the Access > Node to > autonomously decide whether or not access can be granted to a > multicast flow. > > IPTV is an example of a service that will not be offered as best > effort, but requires some level of guaranteed Quality of Service. > This requires the use of Multicast Admission Control. Hence, if > the > Access Node wants to autonomously perform the admission process, it > must be aware of the bandwidth characteristics of multicast flows. > Otherwise, the Access Node would have to query the NAS for > Multicast > Admission Control; this would defeat the purpose of using a > White and > Black list. > > Some network deployments may combine the use of White list, Black > list > and Grey list. In this case, the AN will be aware of the > portion of > the bandwidth used on the Access Port for flows matching an > entry in > the White list. In order to perform Multicast Admission Control > for > flows matching an entry in the Grey list, the NAS should add the > bandwidth characteristics of the flow in the Admission Response > message. In this model, the AN would query the NAS for conditional > access, and would then locally perform Multicast Conditional > Access, > using the bandwidth information retrieved from the NAS. > > << Section 4.2: add following requirements >> > > o The ANCP MUST support providing an Access Node with bandwidth > information associated with multicast flows that are part of a > White list. > > o The ANCP SHOULD allow the NAS to indicate the bandwidth > information, associated with the requested multicast flows, > in the > admission decision sent to the AN. > > o In case a unicast and multicast stream share resources on an > Access Port, the ANCP MUST allow the NAS to query the AN to > request an admission decision for a unicast flow to be sent > over that Port. > > << Section 4.7.6: add following requirements >> > > o The AN must be able to perform Admission Control for multicast > streams, using the bandwith information of the requested > multicast > flow. The information may be provisioned by a management system > or by the NAS (using a Control Reqest message or an Admission > Response message). > > o Upon receiving a query from the NAS to request an admission > decision for a unicast flow to be sent over a particular Access > Port, the AN must support using ANCP to reply to the NAS, > indicating whether the request is to be honored or denied. > > > << Section 4.8.6: add following requirements >> > > o The NAS should support using ANCP to configure multicast > admission control information to Access Ports on an Access Node. > > o Upon receiving a query from the AN for a request to replicate a > multicast flow to a particular Access Port, the NAS should > support > using ANCP to reply to the AN indicating the bandwidth > information, > associated with the requested multicast flow. > > o Upon receiving a request from a Policy Server for a unicast flow > to be sent over a particular Access Port, the NAS must support > using ANCP to query the AN to receive a response indicating > whether the request is to be honored or denied. > > --- > > Sven Ooghe > Alcatel-Lucent > CTO Office, Access Division > Copernicuslaan 50, 2018 Antwerp, Belgium > tel.: +32 3 240 42 26 > fax: +32 3 240 40 73 > > This message (including any attachments) contains confidential > information intended for a specific individual and purpose, and is > protected by law. If you are not the intended recipient, you should > delete this message. Any disclosure, copying, or distribution of this > message, or the taking of any action based on it, is strictly > prohibited > without the prior consent of its author. > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 06:05:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAl3-0003sD-Cy; Wed, 30 Jan 2008 06:05:33 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKAl1-0003ra-MU for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 06:05:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAl0-0003qo-Uy for ancp@ietf.org; Wed, 30 Jan 2008 06:05:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKAl0-0007fQ-F2 for ancp@ietf.org; Wed, 30 Jan 2008 06:05:30 -0500 X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="4369061" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2008 12:05:28 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0UB5Qmq002759; Wed, 30 Jan 2008 12:05:26 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0UB5Hlb008729; Wed, 30 Jan 2008 11:05:26 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 12:05:25 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 12:05:24 +0100 In-Reply-To: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BE48792-AB5D-40D4-98BA-50B073352DEE@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 12:05:21 +0100 To: OOGHE Sven X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 30 Jan 2008 11:05:25.0005 (UTC) FILETIME=[0399CBD0:01C86330] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2442; t=1201691126; x=1202555126; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=XX06ALTpOPrxWpgGjUUZ+GFrzWrhe+pDjwVigiJOBcI=; b=A2rS/vO14kKb8aAaawKzxH8Oq/H+zYSZthqDAOpNBigqU1NO8aq57bJWr8 XeAPZMQEzCDW5NhZ85tkFORbX3gKH534ojJ7pefwzC9DFwgpleiDt/5YC83J +YSU3llgXP; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi again Sven, I support introduction of the text you propose below for section 3.4.2.1 (related to our earlier agreement on being able to do CAC on some flows and not on others). Minor suggestions: - could change title into something like "By-passing admission control for some flows" or "When not to perform admission control for a subset of flows". The idea being that the title makes it clear that we don't do CAC on some flows BUT still do CAC on others. - s/"so that other streams are not impacted"/"so that other streams (that are subject to admission control) are not impacted"/ Thanks Francois > > 3.4.2.1. When not to perform Admission Control > > In general, the Access Node and NAS may not be aware of all > possible > multicast groups that will be streamed in the access network. For > instance, it is likely that there will be multicast streams offered > across the Internet. For these unknown streams, performing > bandwidth > admission control may be challenging. > > To solve this, these requests could be accepted without performing > Admission Control. This solution works, provided that the network > handles the streams as best effort, so that other streams are not > impacted at times of congestion. > > Disabling Admission Control for unknown stream can be achieved by > adding a "catch-all statement" in the Access Node white list or > grey > list. In case the Access Node queries the NAS, the NAS on his turn > will have to accept the request. That way, the unknown streams are > not blocked by default. > > Next, in order to ensure that the streams are handled as best > effort, > the flow must be marked as such when entering the service provider > network. This way, whenever congestion occurs somewhere in the > access/aggregation network, this stream will be kicked out > before the > access provider's own premium content. > > The above concept is applicable beyond the notion of "Internet > streams" or other unknown streams; it can applied to known > multicast > streams as well. In this case, the Access Node or NAS will accept > the stream even when bandwidth may not be sufficient to support the > stream. This again requires that the stream is marked as best > effort > traffic before entering the access/aggregation network. > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 06:17:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAx4-00017G-Eu; Wed, 30 Jan 2008 06:17:58 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKAx3-00017A-2G for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 06:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAx2-000171-Ol for ancp@ietf.org; Wed, 30 Jan 2008 06:17:56 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKAwz-0005pe-Ru for ancp@ietf.org; Wed, 30 Jan 2008 06:17:56 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UB98NZ027626; Wed, 30 Jan 2008 12:09:11 +0100 Received: from [159.23.133.226] ([159.23.133.226]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 12:17:48 +0100 Message-ID: <47A05CDB.7010909@alcatel-lucent.be> Date: Wed, 30 Jan 2008 12:17:47 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Philippe Champagne (pchamp)" Subject: Re: [ANCP] ANCP Multicast Admission Control References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> In-Reply-To: <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 30 Jan 2008 11:17:48.0470 (UTC) FILETIME=[BEBD8D60:01C86331] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id m0UB98NZ027626 X-Spam-Score: 0.0 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: Sven.Ooghe@alcatel-lucent.be, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Phil, How is in the case of HTTP the multicast stream delivered to the DSLAMs?=20 The ethernet switches do not receive an IGMP message, so their IGMP=20 proxy/snooping will not see the new join. The model you describe is not=20 really related to ANCP, so maybe better to leave it out to avoid new=20 problems? regards, Stefaan Philippe Champagne (pchamp) wrote: > Hi Sanjay >=20 > Question on this first paragraph and suggestion on the 2nd: > =20 > o Another approach is the reverse: it consists of the Policy Server >=20 > querying the AN (either directly, or indirectly via the NAS) so >=20 > that both unicast and multicast CAC for the access line are >=20 > performed by the AN. In this case, a subscriber request for a >=20 > unicast flow (e.g. a Video on Demand session) will trigger a >=20 > resource request message towards a Policy Server; the latter will >=20 > then query the AN, that in turn will perform unicast CAC for the >=20 > access line and respond, indicating whether the unicast request=20 >=20 > is to be honored or denied. In case the Policy Server queries=20 >=20 > the AN directly, the approach doesn't require the use of ANCP. = =20 >=20 > It is therefore beyond the scope of this document. >=20 > =20 >=20 > 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... >=20 > ie: Policy Server quering the AN indirectly via the NAS. Or you meant = that only for the multicast part. >=20 > =20 >=20 > =20 >=20 > In case the NAS terminates IGMP signaling from the subscriber and contr= ols the=20 >=20 > replication state on the AN, the CAC function can be completely contain= ed within=20 >=20 > the NAS. NAS may locally maintain available "video" bandwidth on the ac= cess-loop,=20 >=20 > perform "video" bandwidth accounting, and perform CAC on the received I= GMP. Based=20 >=20 > on the available bandwidth, if the IGMP join can be honored, the NAS ca= n set the=20 >=20 > replication state on the AN using ANCP. The policy server may query the= NAS to=20 >=20 > perform admission control on a VoD flow, and update the available "vide= o" bandwidth=20 >=20 > maintained by the NAS. >=20 > =20 > pchamp> This paragraph should also add some phrasing to cover the case=20 > where IGMP is not involved but rather an out of band protocol=20 > (HTTP based). For example, the subscriber requesting a given multicast=20 > on a web page linked to the policy server. In turn it would direct the=20 > NAS to submit an admission control to the AN for that given multicast f= low. > This could be done by adding to the 2nd paragraph, the following=20 > statement (or close to it): > =20 > Another case would be where the subscriber makes the request using=20 > HTTP directly to a web server linked to the policy server, bypassing=20 > both AN and NAS. In such case, the admission request would originate=20 > from the policy server towards the NAS. > =20 > =20 > =20 >=20 > -------------------------------------------------------------------= ----- > *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > *Sent:* Tuesday, January 29, 2008 3:06 AM > *To:* Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-lucent.be= ; > ancp@ietf.org > *Subject:* [ANCP] ANCP Multicast Admission Control >=20 > Sven, Francois, and All >=20 > 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 NA= S > 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=92= t > require complex synchronization between NAS and AN). I am proposing > the following additions (in blue) to sections 3.4 and 3.4.2. >=20 > =20 >=20 > Thanks >=20 > -Sanjay >=20 > =20 >=20 > =20 >=20 > 3.4. Multicast >=20 > =20 >=20 > With the rise of supporting IPTV services in a resource efficient >=20 > way, multicast services are getting increasingly important. >=20 > =20 >=20 > In case of an ATM access/aggregation network, such as the reference >=20 > architecture specified in DSL Forum [TR-059], multicast traffic >=20 > replication is performed in the NAS. In this model, typically IGMP >=20 > is used to control the multicast replication process towards the >=20 > subscribers. The NAS terminates and processes IGMP signaling >=20 > messages sent by the subscribers; towards the Regional Network, the >=20 > NAS typically uses a multicast routing protocol such as PIM. The ATM >=20 > Access Nodes and aggregation switches don't perform IGMP processing, >=20 > nor do they perform multicast traffic replication. As a result, >=20 > network resources are wasted within the access/aggregation network. >=20 > =20 >=20 > To overcome this resource inefficiency, the Access Node, aggregation >=20 > node(s) and the NAS must all be involved in the multicast =20 >=20 > replication process. This avoids that several copies of the same=20 >=20 > stream are sent within the access/aggregation network. In case of an= =20 >=20 > Ethernet-based access/aggregation network, this may, for example, be= =20 >=20 > achieved by means of IGMP snooping or IGMP proxy in the Access Node=20 >=20 > and aggregation node(s). >=20 > =20 >=20 > By introducing IGMP processing in the access/aggregation nodes, the >=20 > multicast replication process is now divided between the NAS, the >=20 > aggregation node(s) and Access Nodes. In order to ensure backward >=20 > compatibility with the ATM-based model, the NAS, aggregation node=20 >=20 > and Access Node need to behave as a single logical device. This =20 >=20 > logical device must have exactly the same functionality as the NAS=20 >=20 > in the ATM access/aggregation network. The Access Node Control=20 >=20 > Mechanism can be used to make sure that this logical/functional=20 >=20 > equivalence is achieved by exchanging the necessary information=20 >=20 > between the Access Node and the NAS. >=20 > =20 >=20 > Another option is for NAS to terminate IGMP signaling from the=20 >=20 > subscriber. In this scenario, NAS can use ANCP to create replication= =20 >=20 > state in the AN for efficient multicast replication. The NAS sends a= =20 >=20 > single copy of the multicast stream towards the AN. The NAS can perf= orm=20 >=20 > conditional access and multicast admission control on IGMP joins, an= d create=20 >=20 > replication state in the AN if the flow is admitted by the NAS. >=20 > =20 >=20 > The following subsections describe the different use cases related t= o multicast. >=20 > =20 >=20 > 3.4.2. Multicast Admission Control >=20 > =20 >=20 > The successful delivery of Triple Play Broadband services is quickly >=20 > becoming a big capacity planning challenge for most of the Service >=20 > Providers nowadays. Solely increasing available bandwidth is not >=20 > always practical, cost-economical and/or sufficient to satisfy end >=20 > user experience given not only the strict requirements of unicast >=20 > delay sensitive applications like VoIP and Video, but also the fast >=20 > growth of multicast interactive applications such as >=20 > videoconferencing, digital TV, digital audio, online movies and >=20 > networked gaming. These applications are typically characterized by >=20 > a delay sensitive nature, an extremely loss sensitive nature and >=20 > intensive bandwidth requirements. They are also typically "non- >=20 > elastic", which means that they operate at a fixed bandwidth, that >=20 > cannot be dynamically adjusted to the currently available bandwidth. >=20 > =20 >=20 > Therefore a Connection Admission Control (CAC) mechanism covering >=20 > admission of multicast traffic over the DSL Broadband access is >=20 > required, in order to avoid oversubscribing the available bandwidth >=20 > and negatively impacting the end user experience. >=20 > =20 >=20 > Considering specifically admission control over the access line, >=20 > before honoring a user request to join a new multicast flow, the >=20 > combination of AN and NAS MUST ensure admission control is performed >=20 > to validate that there is enough "video" bandwidth remaining on the >=20 > access line to carry the new flow (in addition to all other existing >=20 > multicast and unicast video traffic). The solution needs to cope >=20 > with multiple flows per access line and needs to allow access line >=20 > bandwidth to be dynamically shared across multicast and unicast >=20 > traffic (irrespective of whether unicast CAC is performed by NAS or >=20 > by some off-path Policy Server). >=20 > =20 >=20 > Thus, supporting CAC for the access line requires some form of >=20 > synchronization between the entity performing multicast CAC (e.g.=20 >=20 > the NAS or the AN) and the entity performing unicast CAC (e.g. the=20 >=20 > NAS or a Policy Server) and the entity actually enforcing the=20 >=20 > multicast replication (i.e. the AN). This synchronization can be=20 >=20 > achieved in a number of ways: >=20 > =20 >=20 > o One approach is for the AN to query the NAS so that both unicast >=20 > and multicast CAC for the access line are performed by the NAS. >=20 > In this case, the AN can use ANCP to query the NAS, that in turn >=20 > performs multicast CAC and responds to the AN indicating whether >=20 > the join is to be honored (and hence replication performed by the >=20 > AN) or denied. In the process, the NAS may communicate with a >=20 > Policy Server. The NAS may locally maintain available "video" =20 >=20 > bandwidth on the access-loop, and perform "video" bandwidth=20 >=20 > accounting for the access-loop. On receiving an admission request= =20 >=20 > from the AN, the NAS can check available "video" bandwidth before= =20 >=20 > admitting or denying the multicast flow. The policy server may=20 >=20 > query the NAS to perform admission control on a VoD flow, and upd= ate >=20 > the available =93video=94 bandwidth maintained by the NAS. >=20 > =20 >=20 > Similarly to what has been discussed in the Conditional Access=20 >=20 > use case, in response to a Admission Request from the AN for=20 >=20 > admission control of a multicast flow, the NAS may send back an=20 >=20 > Admission Response message to the AN, including admission control= =20 >=20 > information for that multicast flow, as well as for other a set=20 >=20 > of multicast flows sharing the same admission control rules. =20 >=20 > The AN can then autonomously honor or deny >=20 > requests for a given user/port for the set of Multicast flows as >=20 > indicated in the Admission Response message. The ANCP >=20 > requirements to support this approach (where the AN queries the >=20 > NAS) are specified in this document; >=20 > =20 >=20 > o Another approach is the reverse: it consists of the Policy Server >=20 > querying the AN (either directly, or indirectly via the NAS) so >=20 > that both unicast and multicast CAC for the access line are >=20 > performed by the AN. In this case, a subscriber request for a >=20 > unicast flow (e.g. a Video on Demand session) will trigger a >=20 > resource request message towards a Policy Server; the latter will >=20 > then query the AN, that in turn will perform unicast CAC for the >=20 > access line and respond, indicating whether the unicast request=20 >=20 > is to be honored or denied. In case the Policy Server queries=20 >=20 > the AN directly, the approach doesn't require the use of ANCP. = =20 >=20 > It is therefore beyond the scope of this document. >=20 > =20 >=20 > In case the NAS terminates IGMP signaling from the subscriber and contr= ols the=20 >=20 > replication state on the AN, the CAC function can be completely contain= ed within=20 >=20 > the NAS. NAS may locally maintain available "video" bandwidth on the ac= cess-loop,=20 >=20 > perform "video" bandwidth accounting, and perform CAC on the received I= GMP. Based=20 >=20 > on the available bandwidth, if the IGMP join can be honored, the NAS ca= n set the=20 >=20 > replication state on the AN using ANCP. The policy server may query the= NAS to=20 >=20 > perform admission control on a VoD flow, and update the available "vide= o" bandwidth=20 >=20 > maintained by the NAS. >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >=20 >> Sent: maandag 26 november 2007 11:42 >=20 >> To: OOGHE Sven >=20 >> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >=20 >> Maglione Roberta >=20 >> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >=20 >> follow-up) >=20 >> >=20 >> Hi Sven, >=20 >> >=20 >> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >=20 >> >=20 >> > Woj, >=20 >> > >=20 >> > From what I can find on the email list, the proposed change >=20 >> to section >=20 >> > 3.4.4 is related to the following remark from Sanjay (mid September >=20 >> > 2007): >=20 >> > >=20 >> > "The option I alluded to is IGMP from RG to BNG, and replication on >=20 >> > the AN. The replication state on the AN created/controlled >=20 >> via ANCP by BNG. >=20 >> > An optimization could be optional transparent snooping of >=20 >> IGMP on the >=20 >> > AN to act on IGMP reports for leave only (to implement >=20 >> "fast leave")." >=20 >> >=20 >> Right. This is what initiated the thread. >=20 >> >=20 >> I am also aware of other planned deployments where the Multicast > joins >=20 >> are processed by the device behaving as the ANCP-controller (as >=20 >> opposed to the AN). >=20 >> >=20 >> As these ANCP deployments will exist, the ANCP specs ought to >=20 >> recognize and allow them. Note that this has very little impact on > the >=20 >> ANCP protocol anyways (since "spontaneous Admission Responses" >=20 >> are already explicitly allowed anyways for multicast termination) >=20 >> >=20 >> > >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 07:38:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCDA-00068L-Uf; Wed, 30 Jan 2008 07:38:40 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKCD9-00068A-ER for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 07:38:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCD8-00064e-Mr for ancp@ietf.org; Wed, 30 Jan 2008 07:38:38 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKCD5-00084U-Vl for ancp@ietf.org; Wed, 30 Jan 2008 07:38:38 -0500 X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="4381430" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2008 13:38:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0UCcZk1002104; Wed, 30 Jan 2008 13:38:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0UCcQlT016065; Wed, 30 Jan 2008 12:38:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 13:38:26 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 13:38:26 +0100 In-Reply-To: <47A05CDB.7010909@alcatel-lucent.be> References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> <47A05CDB.7010909@alcatel-lucent.be> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <22232F82-E9D0-4ABB-A6EF-02D3F8C2B821@cisco.com> Content-Transfer-Encoding: quoted-printable From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 13:38:21 +0100 To: Stefaan DE CNODDER X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 30 Jan 2008 12:38:26.0142 (UTC) FILETIME=[0237B7E0:01C8633D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15527; t=1201696715; x=1202560715; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=VsExJzW53n3wA6Yux8vU822gO/EkeEiMSf/oEIhLzEg=; b=J0NOcMa2FyB2zslFqgXDnUzcwIoIbvaqKVNzAUz28fQpWtbON8vs9vbJbH px6exHtGnHX4T6XdP1n+lGjHOMnMYuJNjkD579JQi8GGUvPC/2HbhuHtblKQ yYTjepakGJ; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: ancp@ietf.org, Sven.Ooghe@alcatel-lucent.be X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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 =20 > DSLAMs? The ethernet switches do not receive an IGMP message, so =20= > their IGMP proxy/snooping will not see the new join. The NAs uses "spontaneous Admission Response" to program replication =20 in the AN. Same as described below by Sanjay in the case where the =20 NAs processes IGMP Join/Leave. The mechanism by which NAS is made =20 aware of Join/leave is transparent to ANCP. However, ANCP is involved =20= precisely to allow AN to perform replication. > The model you describe is not really related to ANCP, so maybe =20 > better to leave it out to avoid new problems? As I suggested earlier, my recommendation is to mention that scenario =20= only as another example of situation where NAS processes all join/=20 leaves and then uses ANCP to facilitate AN-based replication. Francois > > regards, > Stefaan > > > Philippe Champagne (pchamp) wrote: > >> Hi Sanjay >> Question on this first paragraph and suggestion on the 2nd: >> o Another approach is the reverse: it consists of the Policy Server >> querying the AN (either directly, or indirectly via the NAS) so >> that both unicast and multicast CAC for the access line are >> performed by the AN. In this case, a subscriber request for a >> unicast flow (e.g. a Video on Demand session) will trigger a >> resource request message towards a Policy Server; the latter =20= >> will >> then query the AN, that in turn will perform unicast CAC for =20= >> the >> access line and respond, indicating whether the unicast =20 >> request is to be honored or denied. In case the Policy =20 >> Server queries the AN directly, the approach doesn't require =20= >> the use of ANCP. It is therefore beyond the scope =20= >> of this document. >> pchamp> So, this means ANCP will need to cover the case of =20 >> admitting or denying on the AN a unicast flow rather than =20 >> multicast flow... >> ie: Policy Server quering the AN indirectly via the NAS. Or you =20 >> meant that only for the multicast part. >> In case the NAS terminates IGMP signaling from the subscriber =20 >> and controls the replication state on the AN, the CAC function can =20= >> be completely contained within the NAS. NAS may locally maintain =20 >> available "video" bandwidth on the access-loop, perform "video" =20 >> bandwidth accounting, and perform CAC on the received IGMP. Based =20 >> on the available bandwidth, if the IGMP join can be honored, the =20 >> NAS can set the replication state on the AN using ANCP. The policy =20= >> server may query the NAS to perform admission control on a VoD =20 >> flow, and update the available "video" bandwidth maintained by the =20= >> NAS. >> pchamp> This paragraph should also add some phrasing to cover the =20= >> case where IGMP is not involved but rather an out of band protocol =20= >> (HTTP based). For example, the subscriber requesting a given =20 >> multicast on a web page linked to the policy server. In turn it =20 >> would direct the NAS to submit an admission control to the AN for =20 >> that given multicast flow. >> This could be done by adding to the 2nd paragraph, the following =20 >> statement (or close to it): >> Another case would be where the subscriber makes the request =20 >> using HTTP directly to a web server linked to the policy server, =20 >> bypassing both AN and NAS. In such case, the admission request =20 >> would originate from the policy server towards the NAS. >> =20 >> ---------------------------------------------------------------------=20= >> --- >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >> *Sent:* Tuesday, January 29, 2008 3:06 AM >> *To:* Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-=20 >> lucent.be; >> ancp@ietf.org >> *Subject:* [ANCP] ANCP Multicast Admission Control >> Sven, Francois, and All >> We agreed in the attached thread below that the framework draft >> needs to cover the case where IGMP signaling from the subscriber >> terminates on the NAS, and the AN does not snoop IGMP joins. =20 >> The NAS >> performs conditional access and admission control on the received >> IGMP joins, and controls the replication state on the AN using =20= >> ANCP. >> However, this is not adequately reflected in the draft. The draft >> also does not consider the scenario where the bandwidth =20 >> accounting >> and CAC function is completely contained within the NAS (and =20 >> doesn=92t >> require complex synchronization between NAS and AN). I am =20 >> 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 =20 >> reference >> architecture specified in DSL Forum [TR-059], multicast traffic >> replication is performed in the NAS. In this model, typically =20 >> 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, =20= >> the >> NAS typically uses a multicast routing protocol such as PIM. =20 >> The ATM >> Access Nodes and aggregation switches don't perform IGMP =20 >> processing, >> nor do they perform multicast traffic replication. As a result, >> network resources are wasted within the access/aggregation =20 >> network. >> To overcome this resource inefficiency, the Access Node, =20 >> aggregation >> node(s) and the NAS must all be involved in the multicast =20 >> replication process. This avoids that several copies of the =20 >> same stream are sent within the access/aggregation network. In =20 >> case of an Ethernet-based access/aggregation network, this may, =20= >> for example, be achieved by means of IGMP snooping or IGMP =20 >> proxy in the Access Node and aggregation node(s). >> By introducing IGMP processing in the access/aggregation =20 >> 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 =20 >> node and Access Node need to behave as a single logical =20 >> device. This logical device must have exactly the same =20 >> functionality as the NAS in the ATM access/aggregation network. =20= >> The Access Node Control Mechanism can be used to make sure that =20= >> this logical/functional equivalence is achieved by exchanging =20 >> the necessary information between the Access Node and the NAS. >> Another option is for NAS to terminate IGMP signaling from =20 >> the subscriber. In this scenario, NAS can use ANCP to create =20 >> replication state in the AN for efficient multicast =20 >> replication. The NAS sends a single copy of the multicast =20 >> stream towards the AN. The NAS can perform conditional access =20 >> and multicast admission control on IGMP joins, and create =20 >> replication state in the AN if the flow is admitted by the NAS. >> The following subsections describe the different use cases =20 >> related to multicast. >> 3.4.2. Multicast Admission Control >> The successful delivery of Triple Play Broadband services is =20 >> 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 =20 >> fast >> growth of multicast interactive applications such as >> videoconferencing, digital TV, digital audio, online movies and >> networked gaming. These applications are typically =20 >> 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 =20 >> 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 =20 >> 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 =20 >> performed >> to validate that there is enough "video" bandwidth remaining on =20= >> the >> access line to carry the new flow (in addition to all other =20 >> 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 =20 >> 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 =20 >> (e.g. the NAS or the AN) and the entity performing unicast CAC =20 >> (e.g. the NAS or a Policy Server) and the entity actually =20 >> enforcing the multicast replication (i.e. the AN). This =20 >> synchronization can be achieved in a number of ways: >> o One approach is for the AN to query the NAS so that both =20 >> 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 =20 >> turn >> performs multicast CAC and responds to the AN indicating =20 >> whether >> the join is to be honored (and hence replication performed =20 >> by the >> AN) or denied. In the process, the NAS may communicate with a >> Policy Server. The NAS may locally maintain available =20 >> "video" bandwidth on the access-loop, and perform "video" =20 >> bandwidth accounting for the access-loop. On receiving an =20 >> admission request from the AN, the NAS can check available =20 >> "video" bandwidth before admitting or denying the multicast =20 >> flow. The policy server may query the NAS to perform =20 >> admission control on a VoD flow, and update >> the available =93video=94 bandwidth maintained by the NAS. >> Similarly to what has been discussed in the Conditional =20 >> Access use case, in response to a Admission Request from the =20= >> AN for admission control of a multicast flow, the NAS may =20 >> send back an Admission Response message to the AN, including =20= >> admission control information for that multicast flow, as =20 >> well as for other a set of multicast flows sharing the same =20 >> admission control rules. The AN can then autonomously honor =20= >> or deny >> requests for a given user/port for the set of Multicast =20 >> 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 =20 >> 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 =20= >> will >> then query the AN, that in turn will perform unicast CAC for =20= >> the >> access line and respond, indicating whether the unicast =20 >> request is to be honored or denied. In case the Policy =20 >> Server queries the AN directly, the approach doesn't require =20= >> the use of ANCP. It is therefore beyond the scope =20= >> of this document. >> In case the NAS terminates IGMP signaling from the subscriber and =20= >> controls the replication state on the AN, the CAC function can be =20 >> completely contained within the NAS. NAS may locally maintain =20 >> available "video" bandwidth on the access-loop, perform "video" =20 >> bandwidth accounting, and perform CAC on the received IGMP. Based =20 >> on the available bandwidth, if the IGMP join can be honored, the =20 >> NAS can set the replication state on the AN using ANCP. The policy =20= >> server may query the NAS to perform admission control on a VoD =20 >> flow, and update the available "video" bandwidth maintained by the =20= >> NAS. >> -----Original Message----- >>> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>> Sent: maandag 26 november 2007 11:42 >>> To: OOGHE Sven >>> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >>> Maglione Roberta >>> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >>> follow-up) >>> >>> Hi Sven, >>> >>> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>> >>> > Woj, >>> > >>> > =46rom 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 =20 >>> September >>> > 2007): >>> > >>> > "The option I alluded to is IGMP from RG to BNG, and =20 >>> 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) >>> >>> > >> =20 >> ---------------------------------------------------------------------=20= >> --- >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 08:56:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDQt-0003XZ-SU; Wed, 30 Jan 2008 08:56:55 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKDQs-0003XS-T7 for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 08:56:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDQs-0003XJ-GX for ancp@ietf.org; Wed, 30 Jan 2008 08:56:54 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKDQq-0006lA-NR for ancp@ietf.org; Wed, 30 Jan 2008 08:56:54 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UDm2rT030230; Wed, 30 Jan 2008 14:48:08 +0100 Received: from [159.23.133.226] ([159.23.133.226]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 14:56:39 +0100 Message-ID: <47A08216.5080204@alcatel-lucent.be> Date: Wed, 30 Jan 2008 14:56:38 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> <47A05CDB.7010909@alcatel-lucent.be> <22232F82-E9D0-4ABB-A6EF-02D3F8C2B821@cisco.com> In-Reply-To: <22232F82-E9D0-4ABB-A6EF-02D3F8C2B821@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 30 Jan 2008 13:56:39.0313 (UTC) FILETIME=[EF90C810:01C86347] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id m0UDm2rT030230 X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: ancp@ietf.org, Sven.Ooghe@alcatel-lucent.be X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Francois, The use of "spontaneous Admission Response" is clear to me but my=20 question is how the multicast streams gets to the DSLAM if the Ethernet=20 switches in between do not receive an IGMP message. Just programming=20 multicast replication in the DSLAM is not enough. Although ANCP does=20 not care why a NAS is sending a "spontaneous Admission Response" and=20 examples may be added to the framework document for extra illustration,=20 the framework document should not describe examples that do not work. regards, Stefaan Francois Le Faucheur IMAP wrote: > Hi Stefaan, >=20 > On 30 Jan 2008, at 12:17, Stefaan DE CNODDER wrote: >=20 >> >> Hi Phil, >> >> How is in the case of HTTP the multicast stream delivered to the =20 >> DSLAMs? The ethernet switches do not receive an IGMP message, so =20 >> their IGMP proxy/snooping will not see the new join. >=20 >=20 > The NAs uses "spontaneous Admission Response" to program replication i= n=20 > the AN. Same as described below by Sanjay in the case where the NAs=20 > processes IGMP Join/Leave. The mechanism by which NAS is made aware of= =20 > Join/leave is transparent to ANCP. However, ANCP is involved precisely= =20 > to allow AN to perform replication. >=20 >> The model you describe is not really related to ANCP, so maybe better= =20 >> to leave it out to avoid new problems? >=20 >=20 > As I suggested earlier, my recommendation is to mention that scenario =20 > only as another example of situation where NAS processes all join/=20 > leaves and then uses ANCP to facilitate AN-based replication. >=20 > Francois >=20 >> >> regards, >> Stefaan >> >> >> Philippe Champagne (pchamp) wrote: >> >>> Hi Sanjay >>> Question on this first paragraph and suggestion on the 2nd: >>> o Another approach is the reverse: it consists of the Policy Server >>> querying the AN (either directly, or indirectly via the NAS) so >>> that both unicast and multicast CAC for the access line are >>> performed by the AN. In this case, a subscriber request for a >>> unicast flow (e.g. a Video on Demand session) will trigger a >>> resource request message towards a Policy Server; the latter w= ill >>> then query the AN, that in turn will perform unicast CAC for t= he >>> access line and respond, indicating whether the unicast =20 >>> request is to be honored or denied. In case the Policy Server= =20 >>> queries the AN directly, the approach doesn't require the use=20 >>> of ANCP. It is therefore beyond the scope of this=20 >>> document. >>> pchamp> So, this means ANCP will need to cover the case of =20 >>> admitting or denying on the AN a unicast flow rather than multicast=20 >>> flow... >>> ie: Policy Server quering the AN indirectly via the NAS. Or you =20 >>> meant that only for the multicast part. >>> In case the NAS terminates IGMP signaling from the subscriber and=20 >>> controls the replication state on the AN, the CAC function can be=20 >>> completely contained within the NAS. NAS may locally maintain =20 >>> available "video" bandwidth on the access-loop, perform "video" =20 >>> bandwidth accounting, and perform CAC on the received IGMP. Based on= =20 >>> the available bandwidth, if the IGMP join can be honored, the NAS=20 >>> can set the replication state on the AN using ANCP. The policy =20 >>> server may query the NAS to perform admission control on a VoD flow,= =20 >>> and update the available "video" bandwidth maintained by the NAS. >>> pchamp> This paragraph should also add some phrasing to cover the =20 >>> case where IGMP is not involved but rather an out of band protocol =20 >>> (HTTP based). For example, the subscriber requesting a given =20 >>> multicast on a web page linked to the policy server. In turn it =20 >>> would direct the NAS to submit an admission control to the AN for =20 >>> that given multicast flow. >>> This could be done by adding to the 2nd paragraph, the following =20 >>> statement (or close to it): >>> Another case would be where the subscriber makes the request using=20 >>> HTTP directly to a web server linked to the policy server, bypassing= =20 >>> both AN and NAS. In such case, the admission request would originate= =20 >>> from the policy server towards the NAS. >>> =20 >>> ---------------------------------------------------------------------= =20 >>> --- >>> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>> *Sent:* Tuesday, January 29, 2008 3:06 AM >>> *To:* Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel-=20 >>> lucent.be; >>> ancp@ietf.org >>> *Subject:* [ANCP] ANCP Multicast Admission Control >>> Sven, Francois, and All >>> We agreed in the attached thread below that the framework draft >>> needs to cover the case where IGMP signaling from the subscriber >>> terminates on the NAS, and the AN does not snoop IGMP joins. The= =20 >>> NAS >>> performs conditional access and admission control on the received >>> IGMP joins, and controls the replication state on the AN using =20 >>> ANCP. >>> However, this is not adequately reflected in the draft. The draft >>> also does not consider the scenario where the bandwidth accounti= ng >>> and CAC function is completely contained within the NAS (and =20 >>> doesn=92t >>> require complex synchronization between NAS and AN). I am propos= ing >>> 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 refere= nce >>> architecture specified in DSL Forum [TR-059], multicast traffic >>> replication is performed in the NAS. In this model, typically IG= MP >>> 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, t= he >>> NAS typically uses a multicast routing protocol such as PIM. The = ATM >>> Access Nodes and aggregation switches don't perform IGMP processi= ng, >>> nor do they perform multicast traffic replication. As a result, >>> network resources are wasted within the access/aggregation networ= k. >>> To overcome this resource inefficiency, the Access Node, =20 >>> aggregation >>> node(s) and the NAS must all be involved in the multicast =20 >>> replication process. This avoids that several copies of the same =20 >>> stream are sent within the access/aggregation network. In case of=20 >>> an Ethernet-based access/aggregation network, this may, for=20 >>> example, be achieved by means of IGMP snooping or IGMP proxy in=20 >>> 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 =20 >>> node and Access Node need to behave as a single logical device. =20 >>> This logical device must have exactly the same functionality=20 >>> as the NAS in the ATM access/aggregation network. The Access Node= =20 >>> Control Mechanism can be used to make sure that this=20 >>> logical/functional equivalence is achieved by exchanging the=20 >>> necessary information between the Access Node and the NAS. >>> Another option is for NAS to terminate IGMP signaling from =20 >>> the subscriber. In this scenario, NAS can use ANCP to create =20 >>> replication state in the AN for efficient multicast replication.=20 >>> The NAS sends a single copy of the multicast stream towards the=20 >>> AN. The NAS can perform conditional access and multicast=20 >>> admission control on IGMP joins, and create replication state in=20 >>> the AN if the flow is admitted by the NAS. >>> The following subsections describe the different use cases =20 >>> related to multicast. >>> 3.4.2. Multicast Admission Control >>> The successful delivery of Triple Play Broadband services is =20 >>> 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 fa= st >>> 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 bandwid= th. >>> 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 bandwid= th >>> 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 perfor= med >>> to validate that there is enough "video" bandwidth remaining on t= he >>> access line to carry the new flow (in addition to all other exist= ing >>> 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 =20 >>> (e.g. the NAS or the AN) and the entity performing unicast CAC =20 >>> (e.g. the NAS or a Policy Server) and the entity actually =20 >>> enforcing the multicast replication (i.e. the AN). This =20 >>> synchronization can be achieved in a number of ways: >>> o One approach is for the AN to query the NAS so that both unic= ast >>> 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 tu= rn >>> performs multicast CAC and responds to the AN indicating wheth= er >>> 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 =20 >>> "video" bandwidth on the access-loop, and perform "video" =20 >>> bandwidth accounting for the access-loop. On receiving an =20 >>> admission request from the AN, the NAS can check available =20 >>> "video" bandwidth before admitting or denying the multicast =20 >>> flow. The policy server may query the NAS to perform admission= =20 >>> control on a VoD flow, and update >>> the available =93video=94 bandwidth maintained by the NAS. >>> Similarly to what has been discussed in the Conditional =20 >>> Access use case, in response to a Admission Request from the =20 >>> AN for admission control of a multicast flow, the NAS may send= =20 >>> back an Admission Response message to the AN, including =20 >>> admission control information for that multicast flow, as well= =20 >>> as for other a set of multicast flows sharing the same =20 >>> admission control rules. The AN can then autonomously honor =20 >>> 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 =20 >>> 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 w= ill >>> then query the AN, that in turn will perform unicast CAC for t= he >>> access line and respond, indicating whether the unicast =20 >>> request is to be honored or denied. In case the Policy Server= =20 >>> queries the AN directly, the approach doesn't require the use=20 >>> of ANCP. It is therefore beyond the scope of this=20 >>> document. >>> In case the NAS terminates IGMP signaling from the subscriber and =20 >>> controls the replication state on the AN, the CAC function can be =20 >>> completely contained within the NAS. NAS may locally maintain =20 >>> available "video" bandwidth on the access-loop, perform "video" =20 >>> bandwidth accounting, and perform CAC on the received IGMP. Based on= =20 >>> the available bandwidth, if the IGMP join can be honored, the NAS=20 >>> can set the replication state on the AN using ANCP. The policy =20 >>> server may query the NAS to perform admission control on a VoD flow,= =20 >>> and update the available "video" bandwidth maintained by the NAS. >>> -----Original Message----- >>> >>>> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>>> Sent: maandag 26 november 2007 11:42 >>>> To: OOGHE Sven >>>> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >>>> Maglione Roberta >>>> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >>>> follow-up) >>>> >>>> Hi Sven, >>>> >>>> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>>> >>>> > Woj, >>>> > >>>> > From what I can find on the email list, the proposed change >>>> to section >>>> > 3.4.4 is related to the following remark from Sanjay (mid Septem= ber >>>> > 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) >>>> >>>> > >>> >>> =20 >>> ---------------------------------------------------------------------= =20 >>> --- >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp >> >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp >=20 >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 09:06:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDad-00037K-3N; Wed, 30 Jan 2008 09:06:59 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKDab-00037D-TY for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 09:06:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDaa-00036n-Px for ancp@ietf.org; Wed, 30 Jan 2008 09:06:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKDaX-00076c-OE for ancp@ietf.org; Wed, 30 Jan 2008 09:06:56 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jan 2008 06:06:53 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0UE6rfu023464; Wed, 30 Jan 2008 06:06:53 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0UE6qj7029330; Wed, 30 Jan 2008 14:06:52 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 06:06:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 06:07:05 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C050CE5F2@xmb-sjc-222.amer.cisco.com> In-Reply-To: <47A05CDB.7010909@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: AchjMcQDP3lDPMOESkyZLWxGBIgeSQAE9S4Q References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> <47A05CDB.7010909@alcatel-lucent.be> From: "Philippe Champagne (pchamp)" To: "Stefaan DE CNODDER" X-OriginalArrivalTime: 30 Jan 2008 14:06:52.0917 (UTC) FILETIME=[5D4D5250:01C86349] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17165; t=1201702013; x=1202566013; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=4D1jO+Ki10o/n6/d2hxPWJOQZZgQg4b07VjOAK40w3I=; b=T2QJ1Ffa5+FnWhOZ0/P2jQifj7wGcMwthBEFJQj5gI7x0AqKvKCK1vsEi4 N8fOexn77TDcyrwsfMDsEhWxIsnoH4CsVkHXOQwqYWCNIXNUK4eB2nXykAPm 3m3pIjITip; Authentication-Results: sj-dkim-2; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1b82b4ba484bbe86cdae6d5f8b2d2ccb Cc: Sven.Ooghe@alcatel-lucent.be, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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 >-----Original Message----- >From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 >Sent: Wednesday, January 30, 2008 6:18 AM >To: Philippe Champagne (pchamp) >Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch);=20 >Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org >Subject: Re: [ANCP] ANCP Multicast Admission Control > > >Hi Phil, > >How is in the case of HTTP the multicast stream delivered to=20 >the DSLAMs?=20 > The ethernet switches do not receive an IGMP message, so=20 >their IGMP proxy/snooping will not see the new join. The=20 >model you describe is not really related to ANCP, so maybe=20 >better to leave it out to avoid new problems? > >regards, >Stefaan > > >Philippe Champagne (pchamp) wrote: > >> Hi Sanjay >>=20 >> Question on this first paragraph and suggestion on the 2nd: >> =20 >> o Another approach is the reverse: it consists of the Policy Server >>=20 >> querying the AN (either directly, or indirectly via the NAS) so >>=20 >> that both unicast and multicast CAC for the access line are >>=20 >> performed by the AN. In this case, a subscriber request for a >>=20 >> unicast flow (e.g. a Video on Demand session) will trigger a >>=20 >> resource request message towards a Policy Server; the latter=20 >> will >>=20 >> then query the AN, that in turn will perform unicast=20 >CAC for the >>=20 >> access line and respond, indicating whether the unicast request >>=20 >> is to be honored or denied. In case the Policy Server queries >>=20 >> the AN directly, the approach doesn't require the use=20 >of ANCP. =20 >>=20 >> It is therefore beyond the scope of this document. >>=20 >> =20 >>=20 >> pchamp> So, this means ANCP will need to cover the case of=20 >admitting or denying on the AN a unicast flow rather than=20 >multicast flow... >>=20 >> ie: Policy Server quering the AN indirectly via the NAS. Or=20 >you meant that only for the multicast part. >>=20 >> =20 >>=20 >> =20 >>=20 >> In case the NAS terminates IGMP signaling from the subscriber and=20 >> controls the >>=20 >> replication state on the AN, the CAC function can be completely=20 >> contained within >>=20 >> the NAS. NAS may locally maintain available "video" bandwidth on the=20 >> access-loop, >>=20 >> perform "video" bandwidth accounting, and perform CAC on the=20 >received=20 >> IGMP. Based >>=20 >> on the available bandwidth, if the IGMP join can be honored, the NAS=20 >> can set the >>=20 >> replication state on the AN using ANCP. The policy server may query=20 >> the NAS to >>=20 >> perform admission control on a VoD flow, and update the available=20 >> "video" bandwidth >>=20 >> maintained by the NAS. >>=20 >> =20 >> pchamp> This paragraph should also add some phrasing to=20 >cover the case >> where IGMP is not involved but rather an out of band protocol (HTTP=20 >> based). For example, the subscriber requesting a given=20 >multicast on a=20 >> web page linked to the policy server. In turn it would=20 >direct the NAS=20 >> to submit an admission control to the AN for that given=20 >multicast flow. >> This could be done by adding to the 2nd paragraph, the following=20 >> statement (or close to it): >> =20 >> Another case would be where the subscriber makes the request using=20 >> HTTP directly to a web server linked to the policy server, bypassing=20 >> both AN and NAS. In such case, the admission request would originate=20 >> from the policy server towards the NAS. >> =20 >> =20 >> =20 >>=20 >> =20 >--------------------------------------------------------------- >--------- >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >> *Sent:* Tuesday, January 29, 2008 3:06 AM >> *To:* Francois Le Faucheur (flefauch);=20 >Sven.Ooghe@alcatel-lucent.be; >> ancp@ietf.org >> *Subject:* [ANCP] ANCP Multicast Admission Control >>=20 >> Sven, Francois, and All >>=20 >> 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=20 >joins. The NAS >> performs conditional access and admission control on the received >> IGMP joins, and controls the replication state on the AN=20 >using ANCP. >> However, this is not adequately reflected in the draft. The draft >> also does not consider the scenario where the bandwidth=20 >accounting >> and CAC function is completely contained within the NAS=20 >(and doesn't >> require complex synchronization between NAS and AN). I=20 >am proposing >> the following additions (in blue) to sections 3.4 and 3.4.2. >>=20 >> =20 >>=20 >> Thanks >>=20 >> -Sanjay >>=20 >> =20 >>=20 >> =20 >>=20 >> 3.4. Multicast >>=20 >> =20 >>=20 >> With the rise of supporting IPTV services in a resource efficient >>=20 >> way, multicast services are getting increasingly important. >>=20 >> =20 >>=20 >> In case of an ATM access/aggregation network, such as the=20 >reference >>=20 >> architecture specified in DSL Forum [TR-059], multicast traffic >>=20 >> replication is performed in the NAS. In this model,=20 >typically IGMP >>=20 >> is used to control the multicast replication process towards the >>=20 >> subscribers. The NAS terminates and processes IGMP signaling >>=20 >> messages sent by the subscribers; towards the Regional=20 >Network, the >>=20 >> NAS typically uses a multicast routing protocol such as PIM. The=20 >> ATM >>=20 >> Access Nodes and aggregation switches don't perform IGMP=20 >> processing, >>=20 >> nor do they perform multicast traffic replication. As a result, >>=20 >> network resources are wasted within the=20 >access/aggregation network. >>=20 >> =20 >>=20 >> To overcome this resource inefficiency, the Access Node,=20 >> aggregation >>=20 >> node(s) and the NAS must all be involved in the multicast =20 >>=20 >> replication process. This avoids that several copies of the same >>=20 >> stream are sent within the access/aggregation network. In case of=20 >> an >>=20 >> Ethernet-based access/aggregation network, this may, for example,=20 >> be >>=20 >> achieved by means of IGMP snooping or IGMP proxy in the=20 >Access Node >>=20 >> and aggregation node(s). >>=20 >> =20 >>=20 >> By introducing IGMP processing in the access/aggregation=20 >nodes, the >>=20 >> multicast replication process is now divided between the NAS, the >>=20 >> aggregation node(s) and Access Nodes. In order to ensure backward >>=20 >> compatibility with the ATM-based model, the NAS, aggregation node >>=20 >> and Access Node need to behave as a single logical=20 >device. This =20 >>=20 >> logical device must have exactly the same functionality as the NAS >>=20 >> in the ATM access/aggregation network. The Access Node Control >>=20 >> Mechanism can be used to make sure that this logical/functional >>=20 >> equivalence is achieved by exchanging the necessary information >>=20 >> between the Access Node and the NAS. >>=20 >> =20 >>=20 >> Another option is for NAS to terminate IGMP signaling from the >>=20 >> subscriber. In this scenario, NAS can use ANCP to create=20 >> replication >>=20 >> state in the AN for efficient multicast replication. The=20 >NAS sends=20 >> a >>=20 >> single copy of the multicast stream towards the AN. The NAS can=20 >> perform >>=20 >> conditional access and multicast admission control on IGMP joins,=20 >> and create >>=20 >> replication state in the AN if the flow is admitted by the NAS. >>=20 >> =20 >>=20 >> The following subsections describe the different use=20 >cases related to multicast. >>=20 >> =20 >>=20 >> 3.4.2. Multicast Admission Control >>=20 >> =20 >>=20 >> The successful delivery of Triple Play Broadband services is=20 >> quickly >>=20 >> becoming a big capacity planning challenge for most of the Service >>=20 >> Providers nowadays. Solely increasing available bandwidth is not >>=20 >> always practical, cost-economical and/or sufficient to satisfy end >>=20 >> user experience given not only the strict requirements of unicast >>=20 >> delay sensitive applications like VoIP and Video, but=20 >also the fast >>=20 >> growth of multicast interactive applications such as >>=20 >> videoconferencing, digital TV, digital audio, online movies and >>=20 >> networked gaming. These applications are typically characterized=20 >> by >>=20 >> a delay sensitive nature, an extremely loss sensitive nature and >>=20 >> intensive bandwidth requirements. They are also typically "non- >>=20 >> elastic", which means that they operate at a fixed bandwidth, that >>=20 >> cannot be dynamically adjusted to the currently available=20 >bandwidth. >>=20 >> =20 >>=20 >> Therefore a Connection Admission Control (CAC) mechanism covering >>=20 >> admission of multicast traffic over the DSL Broadband access is >>=20 >> required, in order to avoid oversubscribing the available=20 >bandwidth >>=20 >> and negatively impacting the end user experience. >>=20 >> =20 >>=20 >> Considering specifically admission control over the access line, >>=20 >> before honoring a user request to join a new multicast flow, the >>=20 >> combination of AN and NAS MUST ensure admission control is=20 >> performed >>=20 >> to validate that there is enough "video" bandwidth=20 >remaining on the >>=20 >> access line to carry the new flow (in addition to all other=20 >> existing >>=20 >> multicast and unicast video traffic). The solution needs to cope >>=20 >> with multiple flows per access line and needs to allow access line >>=20 >> bandwidth to be dynamically shared across multicast and unicast >>=20 >> traffic (irrespective of whether unicast CAC is performed=20 >by NAS or >>=20 >> by some off-path Policy Server). >>=20 >> =20 >>=20 >> Thus, supporting CAC for the access line requires some form of >>=20 >> synchronization between the entity performing multicast CAC (e.g.=20 >>=20 >> the NAS or the AN) and the entity performing unicast CAC (e.g. the >>=20 >> NAS or a Policy Server) and the entity actually enforcing the >>=20 >> multicast replication (i.e. the AN). This synchronization can be >>=20 >> achieved in a number of ways: >>=20 >> =20 >>=20 >> o One approach is for the AN to query the NAS so that=20 >both unicast >>=20 >> and multicast CAC for the access line are performed by the NAS. >>=20 >> In this case, the AN can use ANCP to query the NAS,=20 >that in turn >>=20 >> performs multicast CAC and responds to the AN=20 >indicating whether >>=20 >> the join is to be honored (and hence replication performed by=20 >> the >>=20 >> AN) or denied. In the process, the NAS may communicate with a >>=20 >> Policy Server. The NAS may locally maintain available=20 >"video" =20 >>=20 >> bandwidth on the access-loop, and perform "video" bandwidth >>=20 >> accounting for the access-loop. On receiving an admission=20 >> request >>=20 >> from the AN, the NAS can check available "video" bandwidth=20 >> before >>=20 >> admitting or denying the multicast flow. The policy server may >>=20 >> query the NAS to perform admission control on a VoD flow, and=20 >> update >>=20 >> the available "video" bandwidth maintained by the NAS. >>=20 >> =20 >>=20 >> Similarly to what has been discussed in the Conditional Access >>=20 >> use case, in response to a Admission Request from the AN for >>=20 >> admission control of a multicast flow, the NAS may send back an >>=20 >> Admission Response message to the AN, including admission=20 >> control >>=20 >> information for that multicast flow, as well as for other a set >>=20 >> of multicast flows sharing the same admission control rules. =20 >>=20 >> The AN can then autonomously honor or deny >>=20 >> requests for a given user/port for the set of=20 >Multicast flows as >>=20 >> indicated in the Admission Response message. The ANCP >>=20 >> requirements to support this approach (where the AN queries the >>=20 >> NAS) are specified in this document; >>=20 >> =20 >>=20 >> o Another approach is the reverse: it consists of the Policy=20 >> Server >>=20 >> querying the AN (either directly, or indirectly via the NAS) so >>=20 >> that both unicast and multicast CAC for the access line are >>=20 >> performed by the AN. In this case, a subscriber request for a >>=20 >> unicast flow (e.g. a Video on Demand session) will trigger a >>=20 >> resource request message towards a Policy Server; the latter=20 >> will >>=20 >> then query the AN, that in turn will perform unicast=20 >CAC for the >>=20 >> access line and respond, indicating whether the unicast request >>=20 >> is to be honored or denied. In case the Policy Server queries >>=20 >> the AN directly, the approach doesn't require the use=20 >of ANCP. =20 >>=20 >> It is therefore beyond the scope of this document. >>=20 >> =20 >>=20 >> In case the NAS terminates IGMP signaling from the subscriber and=20 >> controls the >>=20 >> replication state on the AN, the CAC function can be completely=20 >> contained within >>=20 >> the NAS. NAS may locally maintain available "video" bandwidth on the=20 >> access-loop, >>=20 >> perform "video" bandwidth accounting, and perform CAC on the=20 >received=20 >> IGMP. Based >>=20 >> on the available bandwidth, if the IGMP join can be honored, the NAS=20 >> can set the >>=20 >> replication state on the AN using ANCP. The policy server may query=20 >> the NAS to >>=20 >> perform admission control on a VoD flow, and update the available=20 >> "video" bandwidth >>=20 >> maintained by the NAS. >>=20 >> =20 >>=20 >> =20 >>=20 >> -----Original Message----- >>=20 >>> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>=20 >>> Sent: maandag 26 november 2007 11:42 >>=20 >>> To: OOGHE Sven >>=20 >>> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >>=20 >>> Maglione Roberta >>=20 >>> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >>=20 >>> follow-up) >>=20 >>> >>=20 >>> Hi Sven, >>=20 >>> >>=20 >>> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>=20 >>> >>=20 >>> > Woj, >>=20 >>> > >>=20 >>> > From what I can find on the email list, the proposed change >>=20 >>> to section >>=20 >>> > 3.4.4 is related to the following remark from Sanjay (mid=20 >>> September >>=20 >>> > 2007): >>=20 >>> > >>=20 >>> > "The option I alluded to is IGMP from RG to BNG, and replication=20 >>> on >>=20 >>> > the AN. The replication state on the AN created/controlled >>=20 >>> via ANCP by BNG. >>=20 >>> > An optimization could be optional transparent snooping of >>=20 >>> IGMP on the >>=20 >>> > AN to act on IGMP reports for leave only (to implement >>=20 >>> "fast leave")." >>=20 >>> >>=20 >>> Right. This is what initiated the thread. >>=20 >>> >>=20 >>> I am also aware of other planned deployments where the Multicast >> joins >>=20 >>> are processed by the device behaving as the ANCP-controller (as >>=20 >>> opposed to the AN). >>=20 >>> >>=20 >>> As these ANCP deployments will exist, the ANCP specs ought to >>=20 >>> recognize and allow them. Note that this has very little impact on >> the >>=20 >>> ANCP protocol anyways (since "spontaneous Admission Responses" >>=20 >>> are already explicitly allowed anyways for multicast termination) >>=20 >>> >>=20 >>> > >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >>=20 >>=20 >---------------------------------------------------------------------- >> -- >>=20 >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 09:17:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDkk-0006Kp-Pg; Wed, 30 Jan 2008 09:17:26 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKDkj-0006Kh-Pb for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 09:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDkj-0006KZ-Fo for ancp@ietf.org; Wed, 30 Jan 2008 09:17:25 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKDkh-0003MB-6T for ancp@ietf.org; Wed, 30 Jan 2008 09:17:25 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UEGmHc002553; Wed, 30 Jan 2008 15:16:48 +0100 Received: from [159.23.133.226] ([159.23.133.226]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 15:16:59 +0100 Message-ID: <47A086DA.8050204@alcatel-lucent.be> Date: Wed, 30 Jan 2008 15:16:58 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Philippe Champagne (pchamp)" Subject: Re: [ANCP] ANCP Multicast Admission Control References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> <47A05CDB.7010909@alcatel-lucent.be> <48214755113BB04F84D958B4F0DE261C050CE5F2@xmb-sjc-222.amer.cisco.com> In-Reply-To: <48214755113BB04F84D958B4F0DE261C050CE5F2@xmb-sjc-222.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2008 14:16:59.0141 (UTC) FILETIME=[C6A3C350:01C8634A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: f1dd3a65e68371b02f99ed5567ad74d9 Cc: Sven.Ooghe@alcatel-lucent.be, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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: > 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 > > >>-----Original Message----- >>From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Sent: Wednesday, January 30, 2008 6:18 AM >>To: Philippe Champagne (pchamp) >>Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch); >>Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org >>Subject: Re: [ANCP] ANCP Multicast Admission Control >> >> >>Hi Phil, >> >>How is in the case of HTTP the multicast stream delivered to >>the DSLAMs? >> The ethernet switches do not receive an IGMP message, so >>their IGMP proxy/snooping will not see the new join. The >>model you describe is not really related to ANCP, so maybe >>better to leave it out to avoid new problems? >> >>regards, >>Stefaan >> >> >>Philippe Champagne (pchamp) wrote: >> >> >>>Hi Sanjay >>> >>>Question on this first paragraph and suggestion on the 2nd: >>> >>>o Another approach is the reverse: it consists of the Policy Server >>> >>> querying the AN (either directly, or indirectly via the NAS) so >>> >>> that both unicast and multicast CAC for the access line are >>> >>> performed by the AN. In this case, a subscriber request for a >>> >>> unicast flow (e.g. a Video on Demand session) will trigger a >>> >>> resource request message towards a Policy Server; the latter >>>will >>> >>> then query the AN, that in turn will perform unicast >> >>CAC for the >> >>> access line and respond, indicating whether the unicast request >>> >>> is to be honored or denied. In case the Policy Server queries >>> >>> the AN directly, the approach doesn't require the use >> >>of ANCP. >> >>> It is therefore beyond the scope of this document. >>> >>> >>> >>>pchamp> So, this means ANCP will need to cover the case of >> >>admitting or denying on the AN a unicast flow rather than >>multicast flow... >> >>>ie: Policy Server quering the AN indirectly via the NAS. Or >> >>you meant that only for the multicast part. >> >>> >>> >>> >>> >>>In case the NAS terminates IGMP signaling from the subscriber and >>>controls the >>> >>>replication state on the AN, the CAC function can be completely >>>contained within >>> >>>the NAS. NAS may locally maintain available "video" bandwidth on the >>>access-loop, >>> >>>perform "video" bandwidth accounting, and perform CAC on the >> >>received >> >>>IGMP. Based >>> >>>on the available bandwidth, if the IGMP join can be honored, the NAS >>>can set the >>> >>>replication state on the AN using ANCP. The policy server may query >>>the NAS to >>> >>>perform admission control on a VoD flow, and update the available >>>"video" bandwidth >>> >>>maintained by the NAS. >>> >>> >>>pchamp> This paragraph should also add some phrasing to >> >>cover the case >> >>>where IGMP is not involved but rather an out of band protocol (HTTP >>>based). For example, the subscriber requesting a given >> >>multicast on a >> >>>web page linked to the policy server. In turn it would >> >>direct the NAS >> >>>to submit an admission control to the AN for that given >> >>multicast flow. >> >>>This could be done by adding to the 2nd paragraph, the following >>>statement (or close to it): >>> >>>Another case would be where the subscriber makes the request using >>>HTTP directly to a web server linked to the policy server, bypassing >>>both AN and NAS. In such case, the admission request would originate >>>from the policy server towards the NAS. >>> >>> >>> >>> >>> >> >>--------------------------------------------------------------- >>--------- >> >>> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>> *Sent:* Tuesday, January 29, 2008 3:06 AM >>> *To:* Francois Le Faucheur (flefauch); >> >>Sven.Ooghe@alcatel-lucent.be; >> >>> ancp@ietf.org >>> *Subject:* [ANCP] ANCP Multicast Admission Control >>> >>> Sven, Francois, and All >>> >>> We agreed in the attached thread below that the framework draft >>> needs to cover the case where IGMP signaling from the subscriber >>> terminates on the NAS, and the AN does not snoop IGMP >> >>joins. The NAS >> >>> performs conditional access and admission control on the received >>> IGMP joins, and controls the replication state on the AN >> >>using ANCP. >> >>> However, this is not adequately reflected in the draft. The draft >>> also does not consider the scenario where the bandwidth >> >>accounting >> >>> and CAC function is completely contained within the NAS >> >>(and doesn't >> >>> require complex synchronization between NAS and AN). I >> >>am proposing >> >>> the following additions (in blue) to sections 3.4 and 3.4.2. >>> >>> >>> >>> Thanks >>> >>> -Sanjay >>> >>> >>> >>> >>> >>>3.4. Multicast >>> >>> >>> >>> With the rise of supporting IPTV services in a resource efficient >>> >>> way, multicast services are getting increasingly important. >>> >>> >>> >>> In case of an ATM access/aggregation network, such as the >> >>reference >> >>> architecture specified in DSL Forum [TR-059], multicast traffic >>> >>> replication is performed in the NAS. In this model, >> >>typically IGMP >> >>> is used to control the multicast replication process towards the >>> >>> subscribers. The NAS terminates and processes IGMP signaling >>> >>> messages sent by the subscribers; towards the Regional >> >>Network, the >> >>> NAS typically uses a multicast routing protocol such as PIM. The >>>ATM >>> >>> Access Nodes and aggregation switches don't perform IGMP >>>processing, >>> >>> nor do they perform multicast traffic replication. As a result, >>> >>> network resources are wasted within the >> >>access/aggregation network. >> >>> >>> >>> To overcome this resource inefficiency, the Access Node, >>>aggregation >>> >>> node(s) and the NAS must all be involved in the multicast >>> >>> replication process. This avoids that several copies of the same >>> >>> stream are sent within the access/aggregation network. In case of >>>an >>> >>> Ethernet-based access/aggregation network, this may, for example, >>>be >>> >>> achieved by means of IGMP snooping or IGMP proxy in the >> >>Access Node >> >>> and aggregation node(s). >>> >>> >>> >>> By introducing IGMP processing in the access/aggregation >> >>nodes, the >> >>> multicast replication process is now divided between the NAS, the >>> >>> aggregation node(s) and Access Nodes. In order to ensure backward >>> >>> compatibility with the ATM-based model, the NAS, aggregation node >>> >>> and Access Node need to behave as a single logical >> >>device. This >> >>> logical device must have exactly the same functionality as the NAS >>> >>> in the ATM access/aggregation network. The Access Node Control >>> >>> Mechanism can be used to make sure that this logical/functional >>> >>> equivalence is achieved by exchanging the necessary information >>> >>> between the Access Node and the NAS. >>> >>> >>> >>> Another option is for NAS to terminate IGMP signaling from the >>> >>> subscriber. In this scenario, NAS can use ANCP to create >>>replication >>> >>> state in the AN for efficient multicast replication. The >> >>NAS sends >> >>>a >>> >>> single copy of the multicast stream towards the AN. The NAS can >>>perform >>> >>> conditional access and multicast admission control on IGMP joins, >>>and create >>> >>> replication state in the AN if the flow is admitted by the NAS. >>> >>> >>> >>> The following subsections describe the different use >> >>cases related to multicast. >> >>> >>> >>>3.4.2. Multicast Admission Control >>> >>> >>> >>> The successful delivery of Triple Play Broadband services is >>>quickly >>> >>> becoming a big capacity planning challenge for most of the Service >>> >>> Providers nowadays. Solely increasing available bandwidth is not >>> >>> always practical, cost-economical and/or sufficient to satisfy end >>> >>> user experience given not only the strict requirements of unicast >>> >>> delay sensitive applications like VoIP and Video, but >> >>also the fast >> >>> growth of multicast interactive applications such as >>> >>> videoconferencing, digital TV, digital audio, online movies and >>> >>> networked gaming. These applications are typically characterized >>>by >>> >>> a delay sensitive nature, an extremely loss sensitive nature and >>> >>> intensive bandwidth requirements. They are also typically "non- >>> >>> elastic", which means that they operate at a fixed bandwidth, that >>> >>> cannot be dynamically adjusted to the currently available >> >>bandwidth. >> >>> >>> >>> Therefore a Connection Admission Control (CAC) mechanism covering >>> >>> admission of multicast traffic over the DSL Broadband access is >>> >>> required, in order to avoid oversubscribing the available >> >>bandwidth >> >>> and negatively impacting the end user experience. >>> >>> >>> >>> Considering specifically admission control over the access line, >>> >>> before honoring a user request to join a new multicast flow, the >>> >>> combination of AN and NAS MUST ensure admission control is >>>performed >>> >>> to validate that there is enough "video" bandwidth >> >>remaining on the >> >>> access line to carry the new flow (in addition to all other >>>existing >>> >>> multicast and unicast video traffic). The solution needs to cope >>> >>> with multiple flows per access line and needs to allow access line >>> >>> bandwidth to be dynamically shared across multicast and unicast >>> >>> traffic (irrespective of whether unicast CAC is performed >> >>by NAS or >> >>> by some off-path Policy Server). >>> >>> >>> >>> Thus, supporting CAC for the access line requires some form of >>> >>> synchronization between the entity performing multicast CAC (e.g. >>> >>> the NAS or the AN) and the entity performing unicast CAC (e.g. the >>> >>> NAS or a Policy Server) and the entity actually enforcing the >>> >>> multicast replication (i.e. the AN). This synchronization can be >>> >>> achieved in a number of ways: >>> >>> >>> >>> o One approach is for the AN to query the NAS so that >> >>both unicast >> >>> and multicast CAC for the access line are performed by the NAS. >>> >>> In this case, the AN can use ANCP to query the NAS, >> >>that in turn >> >>> performs multicast CAC and responds to the AN >> >>indicating whether >> >>> the join is to be honored (and hence replication performed by >>>the >>> >>> AN) or denied. In the process, the NAS may communicate with a >>> >>> Policy Server. The NAS may locally maintain available >> >>"video" >> >>> bandwidth on the access-loop, and perform "video" bandwidth >>> >>> accounting for the access-loop. On receiving an admission >>>request >>> >>> from the AN, the NAS can check available "video" bandwidth >>>before >>> >>> admitting or denying the multicast flow. The policy server may >>> >>> query the NAS to perform admission control on a VoD flow, and >>>update >>> >>> the available "video" bandwidth maintained by the NAS. >>> >>> >>> >>> Similarly to what has been discussed in the Conditional Access >>> >>> use case, in response to a Admission Request from the AN for >>> >>> admission control of a multicast flow, the NAS may send back an >>> >>> Admission Response message to the AN, including admission >>>control >>> >>> information for that multicast flow, as well as for other a set >>> >>> of multicast flows sharing the same admission control rules. >>> >>> The AN can then autonomously honor or deny >>> >>> requests for a given user/port for the set of >> >>Multicast flows as >> >>> indicated in the Admission Response message. The ANCP >>> >>> requirements to support this approach (where the AN queries the >>> >>> NAS) are specified in this document; >>> >>> >>> >>> o Another approach is the reverse: it consists of the Policy >>>Server >>> >>> querying the AN (either directly, or indirectly via the NAS) so >>> >>> that both unicast and multicast CAC for the access line are >>> >>> performed by the AN. In this case, a subscriber request for a >>> >>> unicast flow (e.g. a Video on Demand session) will trigger a >>> >>> resource request message towards a Policy Server; the latter >>>will >>> >>> then query the AN, that in turn will perform unicast >> >>CAC for the >> >>> access line and respond, indicating whether the unicast request >>> >>> is to be honored or denied. In case the Policy Server queries >>> >>> the AN directly, the approach doesn't require the use >> >>of ANCP. >> >>> It is therefore beyond the scope of this document. >>> >>> >>> >>>In case the NAS terminates IGMP signaling from the subscriber and >>>controls the >>> >>>replication state on the AN, the CAC function can be completely >>>contained within >>> >>>the NAS. NAS may locally maintain available "video" bandwidth on the >>>access-loop, >>> >>>perform "video" bandwidth accounting, and perform CAC on the >> >>received >> >>>IGMP. Based >>> >>>on the available bandwidth, if the IGMP join can be honored, the NAS >>>can set the >>> >>>replication state on the AN using ANCP. The policy server may query >>>the NAS to >>> >>>perform admission control on a VoD flow, and update the available >>>"video" bandwidth >>> >>>maintained by the NAS. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> >>>> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>> >>>> Sent: maandag 26 november 2007 11:42 >>> >>>> To: OOGHE Sven >>> >>>> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >>> >>>> Maglione Roberta >>> >>>> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >>> >>>> follow-up) >>> >>>> Hi Sven, >>> >>>> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>> >>>> > Woj, >>> >>>> > >>> >>>> > From what I can find on the email list, the proposed change >>> >>>> to section >>> >>>> > 3.4.4 is related to the following remark from Sanjay (mid >>>>September >>> >>>> > 2007): >>> >>>> > >>> >>>> > "The option I alluded to is IGMP from RG to BNG, and replication >>>>on >>> >>>> > the AN. The replication state on the AN created/controlled >>> >>>> via ANCP by BNG. >>> >>>> > An optimization could be optional transparent snooping of >>> >>>> IGMP on the >>> >>>> > AN to act on IGMP reports for leave only (to implement >>> >>>> "fast leave")." >>> >>>> Right. This is what initiated the thread. >>> >>>> I am also aware of other planned deployments where the Multicast >>> >>> joins >>> >>> >>>> are processed by the device behaving as the ANCP-controller (as >>> >>>> opposed to the AN). >>> >>>> As these ANCP deployments will exist, the ANCP specs ought to >>> >>>> recognize and allow them. Note that this has very little impact on >>> >>> the >>> >>> >>>> ANCP protocol anyways (since "spontaneous Admission Responses" >>> >>>> are already explicitly allowed anyways for multicast termination) >>> >>>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ancp > >> _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 09:24:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDrf-0007Gw-CX; Wed, 30 Jan 2008 09:24:35 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKDrd-0007Gn-Kj for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 09:24:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDrd-0007Gf-Au for ancp@ietf.org; Wed, 30 Jan 2008 09:24:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKDra-0003Ta-8j for ancp@ietf.org; Wed, 30 Jan 2008 09:24:33 -0500 X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="4395859" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2008 15:24:29 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0UEOT7l005959; Wed, 30 Jan 2008 15:24:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0UEOSlJ029590; Wed, 30 Jan 2008 14:24:28 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 15:24:28 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 15:24:28 +0100 In-Reply-To: <47A08216.5080204@alcatel-lucent.be> References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net> <48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com> <47A05CDB.7010909@alcatel-lucent.be> <22232F82-E9D0-4ABB-A6EF-02D3F8C2B821@cisco.com> <47A08216.5080204@alcatel-lucent.be> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 15:24:22 +0100 To: Stefaan DE CNODDER X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 30 Jan 2008 14:24:28.0057 (UTC) FILETIME=[D236E890:01C8634B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17750; t=1201703069; x=1202567069; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=kbAkA4MriaBizMVjGnKa/A+4AUkJdE53uO5s3MABGUU=; b=Ys0+GLkeemJS+HVUVYjb/uiohKfPVpC2ywvwORZieVLsindXEANsvIHwEw EY3OKkb6DIoSvFRdyO3bSsy0GFUjWoS9WG3DDuTfSSwWmFWdFfczgx4LRsSU KpZvqravKh; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: ancp@ietf.org, Sven.Ooghe@alcatel-lucent.be X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org HI Steefan, On 30 Jan 2008, at 14:56, Stefaan DE CNODDER wrote: > > Francois, > > The use of "spontaneous Admission Response" is clear to me but my =20 > question is how the multicast streams gets to the DSLAM if the =20 > 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 =20 either via static joins or via the AN issuing an IGMP Join itself (if =20= it gets an ANCP Admission Response for a flow that it is not yet =20 receiving). > Just programming multicast replication in the DSLAM is not enough. =20= > Although ANCP does not care why a NAS is sending a "spontaneous =20 > Admission Response" and examples may be added to the framework =20 > document for extra illustration, the framework document should not =20 > describe examples that do not work. that sounds right. Regards Francois > > regards, > Stefaan > > Francois Le Faucheur IMAP wrote: > >> Hi Stefaan, >> On 30 Jan 2008, at 12:17, Stefaan DE CNODDER wrote: >>> >>> Hi Phil, >>> >>> How is in the case of HTTP the multicast stream delivered to the =20= >>> DSLAMs? The ethernet switches do not receive an IGMP message, =20 >>> so their IGMP proxy/snooping will not see the new join. >> The NAs uses "spontaneous Admission Response" to program =20 >> replication in the AN. Same as described below by Sanjay in the =20 >> case where the NAs processes IGMP Join/Leave. The mechanism by =20 >> which NAS is made aware of Join/leave is transparent to ANCP. =20 >> However, ANCP is involved precisely to allow AN to perform =20 >> replication. >>> The model you describe is not really related to ANCP, so maybe =20 >>> better to leave it out to avoid new problems? >> As I suggested earlier, my recommendation is to mention that =20 >> scenario only as another example of situation where NAS processes =20= >> all join/ leaves and then uses ANCP to facilitate AN-based =20 >> replication. >> Francois >>> >>> regards, >>> Stefaan >>> >>> >>> Philippe Champagne (pchamp) wrote: >>> >>>> Hi Sanjay >>>> Question on this first paragraph and suggestion on the 2nd: >>>> o Another approach is the reverse: it consists of the Policy =20 >>>> Server >>>> querying the AN (either directly, or indirectly via the =20 >>>> NAS) so >>>> that both unicast and multicast CAC for the access line are >>>> performed by the AN. In this case, a subscriber request =20 >>>> for a >>>> unicast flow (e.g. a Video on Demand session) will trigger a >>>> resource request message towards a Policy Server; the =20 >>>> latter will >>>> then query the AN, that in turn will perform unicast CAC =20 >>>> for the >>>> access line and respond, indicating whether the unicast =20 >>>> request is to be honored or denied. In case the Policy =20 >>>> Server queries the AN directly, the approach doesn't =20 >>>> require the use of ANCP. It is therefore =20 >>>> beyond the scope of this document. >>>> pchamp> So, this means ANCP will need to cover the case of =20 >>>> admitting or denying on the AN a unicast flow rather than =20 >>>> multicast flow... >>>> ie: Policy Server quering the AN indirectly via the NAS. Or =20 >>>> you meant that only for the multicast part. >>>> In case the NAS terminates IGMP signaling from the subscriber =20= >>>> and controls the replication state on the AN, the CAC function =20 >>>> can be completely contained within the NAS. NAS may locally =20 >>>> maintain available "video" bandwidth on the access-loop, =20 >>>> perform "video" bandwidth accounting, and perform CAC on the =20 >>>> received IGMP. Based on the available bandwidth, if the IGMP =20 >>>> join can be honored, the NAS can set the replication state on =20 >>>> the AN using ANCP. The policy server may query the NAS to =20 >>>> perform admission control on a VoD flow, and update the =20 >>>> available "video" bandwidth maintained by the NAS. >>>> pchamp> This paragraph should also add some phrasing to cover =20 >>>> the case where IGMP is not involved but rather an out of band =20 >>>> protocol (HTTP based). For example, the subscriber requesting a =20= >>>> given multicast on a web page linked to the policy server. In =20 >>>> turn it would direct the NAS to submit an admission control to =20 >>>> the AN for that given multicast flow. >>>> This could be done by adding to the 2nd paragraph, the =20 >>>> following statement (or close to it): >>>> Another case would be where the subscriber makes the request =20 >>>> using HTTP directly to a web server linked to the policy =20 >>>> server, bypassing both AN and NAS. In such case, the admission =20 >>>> request would originate from the policy server towards the NAS. >>>> =20 >>>> -------------------------------------------------------------------=20= >>>> -- --- >>>> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>>> *Sent:* Tuesday, January 29, 2008 3:06 AM >>>> *To:* Francois Le Faucheur (flefauch); Sven.Ooghe@alcatel- =20 >>>> lucent.be; >>>> ancp@ietf.org >>>> *Subject:* [ANCP] ANCP Multicast Admission Control >>>> Sven, Francois, and All >>>> We agreed in the attached thread below that the framework =20 >>>> draft >>>> needs to cover the case where IGMP signaling from the =20 >>>> subscriber >>>> terminates on the NAS, and the AN does not snoop IGMP =20 >>>> joins. The NAS >>>> performs conditional access and admission control on the =20 >>>> received >>>> IGMP joins, and controls the replication state on the AN =20 >>>> using ANCP. >>>> However, this is not adequately reflected in the draft. The =20 >>>> draft >>>> also does not consider the scenario where the bandwidth =20 >>>> accounting >>>> and CAC function is completely contained within the NAS =20 >>>> (and doesn=92t >>>> require complex synchronization between NAS and AN). I am =20 >>>> 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 =20 >>>> efficient >>>> way, multicast services are getting increasingly important. >>>> In case of an ATM access/aggregation network, such as the =20 >>>> reference >>>> architecture specified in DSL Forum [TR-059], multicast traffic >>>> replication is performed in the NAS. In this model, =20 >>>> 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 =20 >>>> Network, the >>>> NAS typically uses a multicast routing protocol such as PIM. =20= >>>> The ATM >>>> Access Nodes and aggregation switches don't perform IGMP =20 >>>> processing, >>>> nor do they perform multicast traffic replication. As a result, >>>> network resources are wasted within the access/aggregation =20 >>>> network. >>>> To overcome this resource inefficiency, the Access Node, =20 >>>> aggregation >>>> node(s) and the NAS must all be involved in the =20 >>>> multicast replication process. This avoids that several =20 >>>> copies of the same stream are sent within the access/=20 >>>> aggregation network. In case of an Ethernet-based access/=20 >>>> aggregation network, this may, for example, be achieved by =20 >>>> means of IGMP snooping or IGMP proxy in the Access Node and =20 >>>> aggregation node(s). >>>> By introducing IGMP processing in the access/aggregation =20 >>>> nodes, the >>>> multicast replication process is now divided between the NAS, =20= >>>> the >>>> aggregation node(s) and Access Nodes. In order to ensure =20 >>>> backward >>>> compatibility with the ATM-based model, the NAS, aggregation =20= >>>> node and Access Node need to behave as a single logical =20 >>>> device. This logical device must have exactly the same =20 >>>> functionality as the NAS in the ATM access/aggregation =20 >>>> network. The Access Node Control Mechanism can be used to =20 >>>> make sure that this logical/functional equivalence is =20 >>>> achieved by exchanging the necessary information between the =20= >>>> Access Node and the NAS. >>>> Another option is for NAS to terminate IGMP signaling from =20 >>>> the subscriber. In this scenario, NAS can use ANCP to create =20= >>>> replication state in the AN for efficient multicast =20 >>>> replication. The NAS sends a single copy of the multicast =20 >>>> stream towards the AN. The NAS can perform conditional =20 >>>> access and multicast admission control on IGMP joins, and =20 >>>> create replication state in the AN if the flow is admitted =20 >>>> by the NAS. >>>> The following subsections describe the different use =20 >>>> cases related to multicast. >>>> 3.4.2. Multicast Admission Control >>>> The successful delivery of Triple Play Broadband services =20 >>>> is quickly >>>> becoming a big capacity planning challenge for most of the =20 >>>> Service >>>> Providers nowadays. Solely increasing available bandwidth is =20= >>>> not >>>> always practical, cost-economical and/or sufficient to =20 >>>> satisfy end >>>> user experience given not only the strict requirements of =20 >>>> unicast >>>> delay sensitive applications like VoIP and Video, but also =20 >>>> the fast >>>> growth of multicast interactive applications such as >>>> videoconferencing, digital TV, digital audio, online movies and >>>> networked gaming. These applications are typically =20 >>>> 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, =20= >>>> that >>>> cannot be dynamically adjusted to the currently available =20 >>>> bandwidth. >>>> Therefore a Connection Admission Control (CAC) mechanism =20 >>>> covering >>>> admission of multicast traffic over the DSL Broadband access is >>>> required, in order to avoid oversubscribing the available =20 >>>> bandwidth >>>> and negatively impacting the end user experience. >>>> Considering specifically admission control over the access =20 >>>> line, >>>> before honoring a user request to join a new multicast flow, the >>>> combination of AN and NAS MUST ensure admission control is =20 >>>> performed >>>> to validate that there is enough "video" bandwidth remaining =20 >>>> on the >>>> access line to carry the new flow (in addition to all other =20 >>>> existing >>>> multicast and unicast video traffic). The solution needs to =20 >>>> cope >>>> with multiple flows per access line and needs to allow access =20= >>>> line >>>> bandwidth to be dynamically shared across multicast and unicast >>>> traffic (irrespective of whether unicast CAC is performed by =20= >>>> 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 =20 >>>> (e.g. the NAS or the AN) and the entity performing unicast =20 >>>> CAC (e.g. the NAS or a Policy Server) and the entity =20 >>>> actually enforcing the multicast replication (i.e. the AN). =20 >>>> This synchronization can be achieved in a number of ways: >>>> o One approach is for the AN to query the NAS so that both =20= >>>> unicast >>>> and multicast CAC for the access line are performed by the =20= >>>> NAS. >>>> In this case, the AN can use ANCP to query the NAS, that =20 >>>> in turn >>>> performs multicast CAC and responds to the AN indicating =20 >>>> whether >>>> the join is to be honored (and hence replication =20 >>>> performed by the >>>> AN) or denied. In the process, the NAS may communicate =20 >>>> with a >>>> Policy Server. The NAS may locally maintain available =20 >>>> "video" bandwidth on the access-loop, and perform =20 >>>> "video" bandwidth accounting for the access-loop. On =20 >>>> receiving an admission request from the AN, the NAS can =20 >>>> check available "video" bandwidth before admitting or =20 >>>> denying the multicast flow. The policy server may query =20 >>>> the NAS to perform admission control on a VoD flow, and update >>>> the available =93video=94 bandwidth maintained by the NAS. >>>> Similarly to what has been discussed in the =20 >>>> Conditional Access use case, in response to a Admission =20 >>>> Request from the AN for admission control of a multicast =20 >>>> flow, the NAS may send back an Admission Response message =20= >>>> to the AN, including admission control information for =20 >>>> that multicast flow, as well as for other a set of =20 >>>> multicast flows sharing the same admission control =20 >>>> rules. The AN can then autonomously honor or deny >>>> requests for a given user/port for the set of Multicast =20 >>>> flows as >>>> indicated in the Admission Response message. The ANCP >>>> requirements to support this approach (where the AN =20 >>>> queries the >>>> NAS) are specified in this document; >>>> o Another approach is the reverse: it consists of the =20 >>>> Policy Server >>>> querying the AN (either directly, or indirectly via the =20 >>>> NAS) so >>>> that both unicast and multicast CAC for the access line are >>>> performed by the AN. In this case, a subscriber request =20 >>>> for a >>>> unicast flow (e.g. a Video on Demand session) will trigger a >>>> resource request message towards a Policy Server; the =20 >>>> latter will >>>> then query the AN, that in turn will perform unicast CAC =20 >>>> for the >>>> access line and respond, indicating whether the unicast =20 >>>> request is to be honored or denied. In case the Policy =20 >>>> Server queries the AN directly, the approach doesn't =20 >>>> require the use of ANCP. It is therefore =20 >>>> beyond the scope of this document. >>>> In case the NAS terminates IGMP signaling from the subscriber =20 >>>> and controls the replication state on the AN, the CAC function =20 >>>> can be completely contained within the NAS. NAS may locally =20 >>>> maintain available "video" bandwidth on the access-loop, =20 >>>> perform "video" bandwidth accounting, and perform CAC on the =20 >>>> received IGMP. Based on the available bandwidth, if the IGMP =20 >>>> join can be honored, the NAS can set the replication state on =20 >>>> the AN using ANCP. The policy server may query the NAS to =20 >>>> perform admission control on a VoD flow, and update the =20 >>>> available "video" bandwidth maintained by the NAS. >>>> -----Original Message----- >>>> >>>>> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>>>> Sent: maandag 26 november 2007 11:42 >>>>> To: OOGHE Sven >>>>> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); =20 >>>>> ancp@ietf.org; >>>>> Maglione Roberta >>>>> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] =20 >>>>> ANCP WG >>>>> follow-up) >>>>> >>>>> Hi Sven, >>>>> >>>>> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>>>> >>>>> > Woj, >>>>> > >>>>> > =46rom 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 =20 >>>>> September >>>>> > 2007): >>>>> > >>>>> > "The option I alluded to is IGMP from RG to BNG, and =20 >>>>> 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 =20 >>>>> impact on >>>> >>>> the >>>> >>>>> ANCP protocol anyways (since "spontaneous Admission Responses" >>>>> are already explicitly allowed anyways for multicast termination) >>>>> >>>>> > >>>> >>>> =20 >>>> -------------------------------------------------------------------=20= >>>> -- --- >>>> _______________________________________________ >>>> ANCP mailing list >>>> ANCP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ancp >>> >>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 09:30:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDxe-00011v-FH; Wed, 30 Jan 2008 09:30:46 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKDxd-00011q-81 for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 09:30:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKDxb-00011h-UK for ancp@ietf.org; Wed, 30 Jan 2008 09:30:44 -0500 Received: from exprod7og103.obsmtp.com ([64.18.2.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKDxZ-0007n2-U5 for ancp@ietf.org; Wed, 30 Jan 2008 09:30:43 -0500 Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jan 2008 06:30:26 PST Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 06:30:36 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jan 2008 09:30:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] ANCP Multicast Admission Control Date: Wed, 30 Jan 2008 09:21:13 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C03285045@emailwf1.jnpr.net> In-Reply-To: <47A086DA.8050204@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: AchjSt9IRWs1CaOZSD+Hb9t541AGGQAACvVQ References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net><48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com><47A05CDB.7010909@alcatel-lucent.be><48214755113BB04F84D958B4F0DE261C050CE5F2@xmb-sjc-222.amer.cisco.com> <47A086DA.8050204@alcatel-lucent.be> From: "Jerome Moisand" To: "Stefaan DE CNODDER" , "Philippe Champagne (pchamp)" X-OriginalArrivalTime: 30 Jan 2008 14:30:35.0047 (UTC) FILETIME=[ACF52370:01C8634C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 Cc: Sven.Ooghe@alcatel-lucent.be, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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.=20 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:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, January 30, 2008 9:17 AM To: Philippe Champagne (pchamp) Cc: Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control Phil, I understand that what triggers the sending of the spont adm request is=20 out of scope and can be anyting, but more is needed than just sending=20 such a message to make it working because also the ethernet switch has=20 to forward the multicast stream to the DSLAM, which it wont do if no=20 IGMP join was received. So in the HTTP case, the user will not receive=20 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: > Hi Stefaan >=20 > Francois described this in very good terms in another email. But here is > another way to describe it: >=20 > 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. >=20 > Regards > Phil >=20 >=20 >>-----Original Message----- >>From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Sent: Wednesday, January 30, 2008 6:18 AM >>To: Philippe Champagne (pchamp) >>Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch);=20 >>Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org >>Subject: Re: [ANCP] ANCP Multicast Admission Control >> >> >>Hi Phil, >> >>How is in the case of HTTP the multicast stream delivered to=20 >>the DSLAMs?=20 >> The ethernet switches do not receive an IGMP message, so=20 >>their IGMP proxy/snooping will not see the new join. The=20 >>model you describe is not really related to ANCP, so maybe=20 >>better to leave it out to avoid new problems? >> >>regards, >>Stefaan >> >> >>Philippe Champagne (pchamp) wrote: >> >> >>>Hi Sanjay >>> >>>Question on this first paragraph and suggestion on the 2nd: >>>=20 >>>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=20 >>>will >>> >>> then query the AN, that in turn will perform unicast=20 >> >>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=20 >> >>of ANCP. =20 >> >>> It is therefore beyond the scope of this document. >>> >>>=20 >>> >>>pchamp> So, this means ANCP will need to cover the case of=20 >> >>admitting or denying on the AN a unicast flow rather than=20 >>multicast flow... >> >>>ie: Policy Server quering the AN indirectly via the NAS. Or=20 >> >>you meant that only for the multicast part. >> >>>=20 >>> >>>=20 >>> >>>In case the NAS terminates IGMP signaling from the subscriber and=20 >>>controls the >>> >>>replication state on the AN, the CAC function can be completely=20 >>>contained within >>> >>>the NAS. NAS may locally maintain available "video" bandwidth on the=20 >>>access-loop, >>> >>>perform "video" bandwidth accounting, and perform CAC on the=20 >> >>received=20 >> >>>IGMP. Based >>> >>>on the available bandwidth, if the IGMP join can be honored, the NAS=20 >>>can set the >>> >>>replication state on the AN using ANCP. The policy server may query=20 >>>the NAS to >>> >>>perform admission control on a VoD flow, and update the available=20 >>>"video" bandwidth >>> >>>maintained by the NAS. >>> >>>=20 >>>pchamp> This paragraph should also add some phrasing to=20 >> >>cover the case >> >>>where IGMP is not involved but rather an out of band protocol (HTTP=20 >>>based). For example, the subscriber requesting a given=20 >> >>multicast on a=20 >> >>>web page linked to the policy server. In turn it would=20 >> >>direct the NAS=20 >> >>>to submit an admission control to the AN for that given=20 >> >>multicast flow. >> >>>This could be done by adding to the 2nd paragraph, the following=20 >>>statement (or close to it): >>>=20 >>>Another case would be where the subscriber makes the request using=20 >>>HTTP directly to a web server linked to the policy server, bypassing=20 >>>both AN and NAS. In such case, the admission request would originate=20 >>>from the policy server towards the NAS. >>>=20 >>>=20 >>>=20 >>> >>> =20 >> >>--------------------------------------------------------------- >>--------- >> >>> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>> *Sent:* Tuesday, January 29, 2008 3:06 AM >>> *To:* Francois Le Faucheur (flefauch);=20 >> >>Sven.Ooghe@alcatel-lucent.be; >> >>> ancp@ietf.org >>> *Subject:* [ANCP] ANCP Multicast Admission Control >>> >>> Sven, Francois, and All >>> >>> We agreed in the attached thread below that the framework draft >>> needs to cover the case where IGMP signaling from the subscriber >>> terminates on the NAS, and the AN does not snoop IGMP=20 >> >>joins. The NAS >> >>> performs conditional access and admission control on the received >>> IGMP joins, and controls the replication state on the AN=20 >> >>using ANCP. >> >>> However, this is not adequately reflected in the draft. The draft >>> also does not consider the scenario where the bandwidth=20 >> >>accounting >> >>> and CAC function is completely contained within the NAS=20 >> >>(and doesn't >> >>> require complex synchronization between NAS and AN). I=20 >> >>am proposing >> >>> the following additions (in blue) to sections 3.4 and 3.4.2. >>> >>> =20 >>> >>> Thanks >>> >>> -Sanjay >>> >>> =20 >>> >>> =20 >>> >>>3.4. Multicast >>> >>>=20 >>> >>> With the rise of supporting IPTV services in a resource efficient >>> >>> way, multicast services are getting increasingly important. >>> >>>=20 >>> >>> In case of an ATM access/aggregation network, such as the=20 >> >>reference >> >>> architecture specified in DSL Forum [TR-059], multicast traffic >>> >>> replication is performed in the NAS. In this model,=20 >> >>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=20 >> >>Network, the >> >>> NAS typically uses a multicast routing protocol such as PIM. The=20 >>>ATM >>> >>> Access Nodes and aggregation switches don't perform IGMP=20 >>>processing, >>> >>> nor do they perform multicast traffic replication. As a result, >>> >>> network resources are wasted within the=20 >> >>access/aggregation network. >> >>>=20 >>> >>> To overcome this resource inefficiency, the Access Node,=20 >>>aggregation >>> >>> node(s) and the NAS must all be involved in the multicast =20 >>> >>> replication process. This avoids that several copies of the same >>> >>> stream are sent within the access/aggregation network. In case of=20 >>>an >>> >>> Ethernet-based access/aggregation network, this may, for example,=20 >>>be >>> >>> achieved by means of IGMP snooping or IGMP proxy in the=20 >> >>Access Node >> >>> and aggregation node(s). >>> >>>=20 >>> >>> By introducing IGMP processing in the access/aggregation=20 >> >>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=20 >> >>device. This =20 >> >>> 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. >>> >>>=20 >>> >>> Another option is for NAS to terminate IGMP signaling from the >>> >>> subscriber. In this scenario, NAS can use ANCP to create=20 >>>replication >>> >>> state in the AN for efficient multicast replication. The=20 >> >>NAS sends=20 >> >>>a >>> >>> single copy of the multicast stream towards the AN. The NAS can=20 >>>perform >>> >>> conditional access and multicast admission control on IGMP joins,=20 >>>and create >>> >>> replication state in the AN if the flow is admitted by the NAS. >>> >>> =20 >>> >>> The following subsections describe the different use=20 >> >>cases related to multicast. >> >>> =20 >>> >>>3.4.2. Multicast Admission Control >>> >>>=20 >>> >>> The successful delivery of Triple Play Broadband services is=20 >>>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=20 >> >>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=20 >>>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=20 >> >>bandwidth. >> >>>=20 >>> >>> 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=20 >> >>bandwidth >> >>> and negatively impacting the end user experience. >>> >>>=20 >>> >>> 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=20 >>>performed >>> >>> to validate that there is enough "video" bandwidth=20 >> >>remaining on the >> >>> access line to carry the new flow (in addition to all other=20 >>>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=20 >> >>by NAS or >> >>> by some off-path Policy Server). >>> >>>=20 >>> >>> Thus, supporting CAC for the access line requires some form of >>> >>> synchronization between the entity performing multicast CAC (e.g.=20 >>> >>> 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: >>> >>>=20 >>> >>> o One approach is for the AN to query the NAS so that=20 >> >>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,=20 >> >>that in turn >> >>> performs multicast CAC and responds to the AN=20 >> >>indicating whether >> >>> the join is to be honored (and hence replication performed by=20 >>>the >>> >>> AN) or denied. In the process, the NAS may communicate with a >>> >>> Policy Server. The NAS may locally maintain available=20 >> >>"video" =20 >> >>> bandwidth on the access-loop, and perform "video" bandwidth >>> >>> accounting for the access-loop. On receiving an admission=20 >>>request >>> >>> from the AN, the NAS can check available "video" bandwidth=20 >>>before >>> >>> admitting or denying the multicast flow. The policy server may >>> >>> query the NAS to perform admission control on a VoD flow, and=20 >>>update >>> >>> the available "video" bandwidth maintained by the NAS. >>> >>> =20 >>> >>> 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=20 >>>control >>> >>> information for that multicast flow, as well as for other a set >>> >>> of multicast flows sharing the same admission control rules. =20 >>> >>> The AN can then autonomously honor or deny >>> >>> requests for a given user/port for the set of=20 >> >>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; >>> >>>=20 >>> >>> o Another approach is the reverse: it consists of the Policy=20 >>>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=20 >>>will >>> >>> then query the AN, that in turn will perform unicast=20 >> >>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=20 >> >>of ANCP. =20 >> >>> It is therefore beyond the scope of this document. >>> >>>=20 >>> >>>In case the NAS terminates IGMP signaling from the subscriber and=20 >>>controls the >>> >>>replication state on the AN, the CAC function can be completely=20 >>>contained within >>> >>>the NAS. NAS may locally maintain available "video" bandwidth on the=20 >>>access-loop, >>> >>>perform "video" bandwidth accounting, and perform CAC on the=20 >> >>received=20 >> >>>IGMP. Based >>> >>>on the available bandwidth, if the IGMP join can be honored, the NAS=20 >>>can set the >>> >>>replication state on the AN using ANCP. The policy server may query=20 >>>the NAS to >>> >>>perform admission control on a VoD flow, and update the available=20 >>>"video" bandwidth >>> >>>maintained by the NAS. >>> >>> =20 >>> >>> =20 >>> >>> -----Original Message----- >>> >>> >>>> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>> >>>> Sent: maandag 26 november 2007 11:42 >>> >>>> To: OOGHE Sven >>> >>>> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >>> >>>> Maglione Roberta >>> >>>> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >>> >>>> follow-up) >>> >>>> Hi Sven, >>> >>>> On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>> >>>> > Woj, >>> >>>> > >>> >>>> > From what I can find on the email list, the proposed change >>> >>>> to section >>> >>>> > 3.4.4 is related to the following remark from Sanjay (mid=20 >>>>September >>> >>>> > 2007): >>> >>>> > >>> >>>> > "The option I alluded to is IGMP from RG to BNG, and replication=20 >>>>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) >>> >>>> > >>> >>> =20 >>> >>> =20 >>> >>> =20 >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ancp >=20 >> _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 09:35:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKE2d-0004t4-VH; Wed, 30 Jan 2008 09:35:55 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKE2c-0004sx-Jw for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 09:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKE2c-0004sp-9g for ancp@ietf.org; Wed, 30 Jan 2008 09:35:54 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKE2Y-0003pM-K4 for ancp@ietf.org; Wed, 30 Jan 2008 09:35:53 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UER4fO024094; Wed, 30 Jan 2008 15:27:04 +0100 Received: from [159.23.133.226] ([159.23.133.226]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 15:35:44 +0100 Message-ID: <47A08B40.9000109@alcatel-lucent.be> Date: Wed, 30 Jan 2008 15:35:44 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jerome Moisand Subject: Re: [ANCP] ANCP Multicast Admission Control References: <9BD5D7887235424FA97DFC223CAE3C280C972D7F@proton.jnpr.net><48214755113BB04F84D958B4F0DE261C050CE231@xmb-sjc-222.amer.cisco.com><47A05CDB.7010909@alcatel-lucent.be><48214755113BB04F84D958B4F0DE261C050CE5F2@xmb-sjc-222.amer.cisco.com> <47A086DA.8050204@alcatel-lucent.be> <3525C9833C09ED418C6FD6CD9514668C03285045@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C03285045@emailwf1.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2008 14:35:44.0510 (UTC) FILETIME=[656971E0:01C8634D] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9404aa2ccc871248c2288463bebdd6b9 Cc: ancp@ietf.org, Sven.Ooghe@alcatel-lucent.be X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Jerome, Thanks for the clarrification. Now I understand it how it works. regards, Stefaan Jerome Moisand wrote: > 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:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Wednesday, January 30, 2008 9:17 AM > To: Philippe Champagne (pchamp) > Cc: Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org > Subject: Re: [ANCP] ANCP Multicast Admission Control > > > 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: > > >>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 >> >> >> >>>-----Original Message----- >>>From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >>>Sent: Wednesday, January 30, 2008 6:18 AM >>>To: Philippe Champagne (pchamp) >>>Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch); >>>Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org >>>Subject: Re: [ANCP] ANCP Multicast Admission Control >>> >>> >>>Hi Phil, >>> >>>How is in the case of HTTP the multicast stream delivered to >>>the DSLAMs? >>> The ethernet switches do not receive an IGMP message, so >>>their IGMP proxy/snooping will not see the new join. The >>>model you describe is not really related to ANCP, so maybe >>>better to leave it out to avoid new problems? >>> >>>regards, >>>Stefaan >>> >>> >>>Philippe Champagne (pchamp) wrote: >>> >>> >>> >>>>Hi Sanjay >>>> >>>>Question on this first paragraph and suggestion on the 2nd: >>>> >>>>o Another approach is the reverse: it consists of the Policy Server >>>> >>>> querying the AN (either directly, or indirectly via the NAS) so >>>> >>>> that both unicast and multicast CAC for the access line are >>>> >>>> performed by the AN. In this case, a subscriber request for a >>>> >>>> unicast flow (e.g. a Video on Demand session) will trigger a >>>> >>>> resource request message towards a Policy Server; the latter >>>>will >>>> >>>> then query the AN, that in turn will perform unicast >>> >>>CAC for the >>> >>> >>>> access line and respond, indicating whether the unicast request >>>> >>>> is to be honored or denied. In case the Policy Server queries >>>> >>>> the AN directly, the approach doesn't require the use >>> >>>of ANCP. >>> >>> >>>> It is therefore beyond the scope of this document. >>>> >>>> >>>> >>>>pchamp> So, this means ANCP will need to cover the case of >>> >>>admitting or denying on the AN a unicast flow rather than >>>multicast flow... >>> >>> >>>>ie: Policy Server quering the AN indirectly via the NAS. Or >>> >>>you meant that only for the multicast part. >>> >>> >>>> >>>> >>>> >>>>In case the NAS terminates IGMP signaling from the subscriber and >>>>controls the >>>> >>>>replication state on the AN, the CAC function can be completely >>>>contained within >>>> >>>>the NAS. NAS may locally maintain available "video" bandwidth on the >>>>access-loop, >>>> >>>>perform "video" bandwidth accounting, and perform CAC on the >>> >>>received >>> >>> >>>>IGMP. Based >>>> >>>>on the available bandwidth, if the IGMP join can be honored, the NAS >>>>can set the >>>> >>>>replication state on the AN using ANCP. The policy server may query >>>>the NAS to >>>> >>>>perform admission control on a VoD flow, and update the available >>>>"video" bandwidth >>>> >>>>maintained by the NAS. >>>> >>>> >>>>pchamp> This paragraph should also add some phrasing to >>> >>>cover the case >>> >>> >>>>where IGMP is not involved but rather an out of band protocol (HTTP >>>>based). For example, the subscriber requesting a given >>> >>>multicast on a >>> >>> >>>>web page linked to the policy server. In turn it would >>> >>>direct the NAS >>> >>> >>>>to submit an admission control to the AN for that given >>> >>>multicast flow. >>> >>> >>>>This could be done by adding to the 2nd paragraph, the following >>>>statement (or close to it): >>>> >>>>Another case would be where the subscriber makes the request using >>>>HTTP directly to a web server linked to the policy server, bypassing >>>>both AN and NAS. In such case, the admission request would originate >>> >>>>from the policy server towards the NAS. >>> >>>> >>>> >>>> >>>> >>> >>>--------------------------------------------------------------- >>>--------- >>> >>> >>>> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>>> *Sent:* Tuesday, January 29, 2008 3:06 AM >>>> *To:* Francois Le Faucheur (flefauch); >>> >>>Sven.Ooghe@alcatel-lucent.be; >>> >>> >>>> ancp@ietf.org >>>> *Subject:* [ANCP] ANCP Multicast Admission Control >>>> >>>> Sven, Francois, and All >>>> >>>> We agreed in the attached thread below that the framework draft >>>> needs to cover the case where IGMP signaling from the subscriber >>>> terminates on the NAS, and the AN does not snoop IGMP >>> >>>joins. The NAS >>> >>> >>>> performs conditional access and admission control on the received >>>> IGMP joins, and controls the replication state on the AN >>> >>>using ANCP. >>> >>> >>>> However, this is not adequately reflected in the draft. The draft >>>> also does not consider the scenario where the bandwidth >>> >>>accounting >>> >>> >>>> and CAC function is completely contained within the NAS >>> >>>(and doesn't >>> >>> >>>> require complex synchronization between NAS and AN). I >>> >>>am proposing >>> >>> >>>> the following additions (in blue) to sections 3.4 and 3.4.2. >>>> >>>> >>>> >>>> Thanks >>>> >>>> -Sanjay >>>> >>>> >>>> >>>> >>>> >>>>3.4. Multicast >>>> >>>> >>>> >>>> With the rise of supporting IPTV services in a resource efficient >>>> >>>> way, multicast services are getting increasingly important. >>>> >>>> >>>> >>>> In case of an ATM access/aggregation network, such as the >>> >>>reference >>> >>> >>>> architecture specified in DSL Forum [TR-059], multicast traffic >>>> >>>> replication is performed in the NAS. In this model, >>> >>>typically IGMP >>> >>> >>>> is used to control the multicast replication process towards the >>>> >>>> subscribers. The NAS terminates and processes IGMP signaling >>>> >>>> messages sent by the subscribers; towards the Regional >>> >>>Network, the >>> >>> >>>> NAS typically uses a multicast routing protocol such as PIM. The >>>>ATM >>>> >>>> Access Nodes and aggregation switches don't perform IGMP >>>>processing, >>>> >>>> nor do they perform multicast traffic replication. As a result, >>>> >>>> network resources are wasted within the >>> >>>access/aggregation network. >>> >>> >>>> >>>> To overcome this resource inefficiency, the Access Node, >>>>aggregation >>>> >>>> node(s) and the NAS must all be involved in the multicast >>>> >>>> replication process. This avoids that several copies of the same >>>> >>>> stream are sent within the access/aggregation network. In case of >>>>an >>>> >>>> Ethernet-based access/aggregation network, this may, for example, >>>>be >>>> >>>> achieved by means of IGMP snooping or IGMP proxy in the >>> >>>Access Node >>> >>> >>>> and aggregation node(s). >>>> >>>> >>>> >>>> By introducing IGMP processing in the access/aggregation >>> >>>nodes, the >>> >>> >>>> multicast replication process is now divided between the NAS, the >>>> >>>> aggregation node(s) and Access Nodes. In order to ensure backward >>>> >>>> compatibility with the ATM-based model, the NAS, aggregation node >>>> >>>> and Access Node need to behave as a single logical >>> >>>device. This >>> >>> >>>> logical device must have exactly the same functionality as the NAS >>>> >>>> in the ATM access/aggregation network. The Access Node Control >>>> >>>> Mechanism can be used to make sure that this logical/functional >>>> >>>> equivalence is achieved by exchanging the necessary information >>>> >>>> between the Access Node and the NAS. >>>> >>>> >>>> >>>> Another option is for NAS to terminate IGMP signaling from the >>>> >>>> subscriber. In this scenario, NAS can use ANCP to create >>>>replication >>>> >>>> state in the AN for efficient multicast replication. The >>> >>>NAS sends >>> >>> >>>>a >>>> >>>> single copy of the multicast stream towards the AN. The NAS can >>>>perform >>>> >>>> conditional access and multicast admission control on IGMP joins, >>>>and create >>>> >>>> replication state in the AN if the flow is admitted by the NAS. >>>> >>>> >>>> >>>> The following subsections describe the different use >>> >>>cases related to multicast. >>> >>> >>>> >>>> >>>>3.4.2. Multicast Admission Control >>>> >>>> >>>> >>>> The successful delivery of Triple Play Broadband services is >>>>quickly >>>> >>>> becoming a big capacity planning challenge for most of the Service >>>> >>>> Providers nowadays. Solely increasing available bandwidth is not >>>> >>>> always practical, cost-economical and/or sufficient to satisfy end >>>> >>>> user experience given not only the strict requirements of unicast >>>> >>>> delay sensitive applications like VoIP and Video, but >>> >>>also the fast >>> >>> >>>> growth of multicast interactive applications such as >>>> >>>> videoconferencing, digital TV, digital audio, online movies and >>>> >>>> networked gaming. These applications are typically characterized >>>>by >>>> >>>> a delay sensitive nature, an extremely loss sensitive nature and >>>> >>>> intensive bandwidth requirements. They are also typically "non- >>>> >>>> elastic", which means that they operate at a fixed bandwidth, that >>>> >>>> cannot be dynamically adjusted to the currently available >>> >>>bandwidth. >>> >>> >>>> >>>> Therefore a Connection Admission Control (CAC) mechanism covering >>>> >>>> admission of multicast traffic over the DSL Broadband access is >>>> >>>> required, in order to avoid oversubscribing the available >>> >>>bandwidth >>> >>> >>>> and negatively impacting the end user experience. >>>> >>>> >>>> >>>> Considering specifically admission control over the access line, >>>> >>>> before honoring a user request to join a new multicast flow, the >>>> >>>> combination of AN and NAS MUST ensure admission control is >>>>performed >>>> >>>> to validate that there is enough "video" bandwidth >>> >>>remaining on the >>> >>> >>>> access line to carry the new flow (in addition to all other >>>>existing >>>> >>>> multicast and unicast video traffic). The solution needs to cope >>>> >>>> with multiple flows per access line and needs to allow access line >>>> >>>> bandwidth to be dynamically shared across multicast and unicast >>>> >>>> traffic (irrespective of whether unicast CAC is performed >>> >>>by NAS or >>> >>> >>>> by some off-path Policy Server). >>>> >>>> >>>> >>>> Thus, supporting CAC for the access line requires some form of >>>> >>>> synchronization between the entity performing multicast CAC (e.g. >>>> >>>> the NAS or the AN) and the entity performing unicast CAC (e.g. the >>>> >>>> NAS or a Policy Server) and the entity actually enforcing the >>>> >>>> multicast replication (i.e. the AN). This synchronization can be >>>> >>>> achieved in a number of ways: >>>> >>>> >>>> >>>> o One approach is for the AN to query the NAS so that >>> >>>both unicast >>> >>> >>>> and multicast CAC for the access line are performed by the NAS. >>>> >>>> In this case, the AN can use ANCP to query the NAS, >>> >>>that in turn >>> >>> >>>> performs multicast CAC and responds to the AN >>> >>>indicating whether >>> >>> >>>> the join is to be honored (and hence replication performed by >>>>the >>>> >>>> AN) or denied. In the process, the NAS may communicate with a >>>> >>>> Policy Server. The NAS may locally maintain available >>> >>>"video" >>> >>> >>>> bandwidth on the access-loop, and perform "video" bandwidth >>>> >>>> accounting for the access-loop. On receiving an admission >>>>request >>>> >>>> from the AN, the NAS can check available "video" bandwidth >>>>before >>>> >>>> admitting or denying the multicast flow. The policy server may >>>> >>>> query the NAS to perform admission control on a VoD flow, and >>>>update >>>> >>>> the available "video" bandwidth maintained by the NAS. >>>> >>>> >>>> >>>> Similarly to what has been discussed in the Conditional Access >>>> >>>> use case, in response to a Admission Request from the AN for >>>> >>>> admission control of a multicast flow, the NAS may send back an >>>> >>>> Admission Response message to the AN, including admission >>>>control >>>> >>>> information for that multicast flow, as well as for other a set >>>> >>>> of multicast flows sharing the same admission control rules. >>>> >>>> The AN can then autonomously honor or deny >>>> >>>> requests for a given user/port for the set of >>> >>>Multicast flows as >>> >>> >>>> indicated in the Admission Response message. The ANCP >>>> >>>> requirements to support this approach (where the AN queries the >>>> >>>> NAS) are specified in this document; >>>> >>>> >>>> >>>> o Another approach is the reverse: it consists of the Policy >>>>Server >>>> >>>> querying the AN (either directly, or indirectly via the NAS) so >>>> >>>> that both unicast and multicast CAC for the access line are >>>> >>>> performed by the AN. In this case, a subscriber request for a >>>> >>>> unicast flow (e.g. a Video on Demand session) will trigger a >>>> >>>> resource request message towards a Policy Server; the latter >>>>will >>>> >>>> then query the AN, that in turn will perform unicast >>> >>>CAC for the >>> >>> >>>> access line and respond, indicating whether the unicast request >>>> >>>> is to be honored or denied. In case the Policy Server queries >>>> >>>> the AN directly, the approach doesn't require the use >>> >>>of ANCP. >>> >>> >>>> It is therefore beyond the scope of this document. >>>> >>>> >>>> >>>>In case the NAS terminates IGMP signaling from the subscriber and >>>>controls the >>>> >>>>replication state on the AN, the CAC function can be completely >>>>contained within >>>> >>>>the NAS. NAS may locally maintain available "video" bandwidth on the >>>>access-loop, >>>> >>>>perform "video" bandwidth accounting, and perform CAC on the >>> >>>received >>> >>> >>>>IGMP. Based >>>> >>>>on the available bandwidth, if the IGMP join can be honored, the NAS >>>>can set the >>>> >>>>replication state on the AN using ANCP. The policy server may query >>>>the NAS to >>>> >>>>perform admission control on a VoD flow, and update the available >>>>"video" bandwidth >>>> >>>>maintained by the NAS. >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> >>>> >>>>>From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >>>> >>>>>Sent: maandag 26 november 2007 11:42 >>>> >>>>>To: OOGHE Sven >>>> >>>>>Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >>>> >>>>>Maglione Roberta >>>> >>>>>Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >>>> >>>>>follow-up) >>>> >>>>>Hi Sven, >>>> >>>>>On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >>>> >>>>>>Woj, >>>> >>>>>>From what I can find on the email list, the proposed change >>>> >>>>>to section >>>> >>>>>>3.4.4 is related to the following remark from Sanjay (mid >>>>> >>>>>September >>>> >>>>>>2007): >>>> >>>>>>"The option I alluded to is IGMP from RG to BNG, and replication >>>>> >>>>>on >>>> >>>>>>the AN. The replication state on the AN created/controlled >>>> >>>>>via ANCP by BNG. >>>> >>>>>>An optimization could be optional transparent snooping of >>>> >>>>>IGMP on the >>>> >>>>>>AN to act on IGMP reports for leave only (to implement >>>> >>>>>"fast leave")." >>>> >>>>>Right. This is what initiated the thread. >>>> >>>>>I am also aware of other planned deployments where the Multicast >>>> >>>> joins >>>> >>>> >>>> >>>>>are processed by the device behaving as the ANCP-controller (as >>>> >>>>>opposed to the AN). >>>> >>>>>As these ANCP deployments will exist, the ANCP specs ought to >>>> >>>>>recognize and allow them. Note that this has very little impact on >>>> >>>> the >>>> >>>> >>>> >>>>>ANCP protocol anyways (since "spontaneous Admission Responses" >>>> >>>>>are already explicitly allowed anyways for multicast termination) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>---------------------------------------------------------------------- >>> >>> >>>>-- >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ancp >> > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jan 30 12:32:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKGnC-00089x-Rd; Wed, 30 Jan 2008 12:32:10 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKGnC-00089s-Is for ancp-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 12:32:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKGnC-00089k-8b for ancp@ietf.org; Wed, 30 Jan 2008 12:32:10 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKGn9-0003Mf-Nr for ancp@ietf.org; Wed, 30 Jan 2008 12:32:10 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UHNL7Q003248; Wed, 30 Jan 2008 18:23:21 +0100 Received: from [159.23.133.226] ([159.23.133.226]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 18:32:02 +0100 Message-ID: <47A0B490.2040605@alcatel-lucent.be> Date: Wed, 30 Jan 2008 18:32:00 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2008 17:32:02.0800 (UTC) FILETIME=[06906700:01C86366] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: OOGHE Sven , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Francois, > > In addition, it is not clear to me how useful these additional models > are. It also raises a number of questions. For example, if the Policy > Server wants to query the AN, should it do so via the NAS instead of > directly to AN? Both are possible, is there any preferred way according to you? Also, to be able to perform complete Video CAC, the AN > would have to maintain user policy information (eg what is the fraction > of line bandwidth that can be used for Video for that subscriber at > that point in time considering the current DSL train rate). Is this in > line with current ANCP model? how is user info made available to AN? > What impact does all this have on ANCP? > While we can start discussing those questions and the usefulness of > such a model, IMHO this should not delay progress of current ANCP > documents. > > So in short, I do _not_ support the additional text below relating to > the introduction of the new additional model (PS-->NAS-->AN) and > corresponding additional ANCP requirements. does this mean that you prefer PS-->AN? To be honest, for me both options are valid. Is there any specific reason why you would not like to have the request going to the NAS? regards, Stefaan > > Cheers > > Francois > > > > On 28 Jan 2008, at 14:18, OOGHE Sven wrote: > >> Hi, >> >> Based on the discussion on the list, I have prepared the following text >> proposal concerning multicast conditional access. I tried to cover the >> different scenarios that were identified on the list. This includes the >> proposal from Tina and Roberta, and feedback from Stefaan. >> >> If nobody objects, I will use the text below to update the text in >> section 3.4.2 in the ANCP Framework. I will also add the corresponding >> requirements in section 4.2 (ANCP), 4.7.6 (Access Node) and 4.8.6 (NAS). >> >> Regards, >> Sven >> >> --- >> >> << Section 3.4.2 >> >> >> 3.4.2. Multicast Admission Control >> >> << first part of the section remains unchanged. The text from the second >> bullet onward is updated with below text >> >> >> 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. >> >> The second scenario can be split in to cases: >> >> o 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. >> >> o In case the Policy Server queries the AN indirectly via the NAS, >> the interaction can be handled as an ANCP transaction. When the >> Policy Server queries the NAS, the NAS can use ANCP to query the >> AN, specifying the Access-Loop-Circuit-ID and the required >> bandwidth for the requested unicast flow. Upon receiving the >> query from the NAS, the AN then performs Admission Control and >> responds to the NAS, indicating if this unicast VoD request can be >> accepted or denied. >> >> 3.4.2.1. When not to perform Admission Control >> >> In general, the Access Node and NAS may not be aware of all possible >> multicast groups that will be streamed in the access network. For >> instance, it is likely that there will be multicast streams offered >> across the Internet. For these unknown streams, performing bandwidth >> admission control may be challenging. >> >> To solve this, these requests could be accepted without performing >> Admission Control. This solution works, provided that the network >> handles the streams as best effort, so that other streams are not >> impacted at times of congestion. >> >> Disabling Admission Control for unknown stream can be achieved by >> adding a "catch-all statement" in the Access Node white list or grey >> list. In case the Access Node queries the NAS, the NAS on his turn >> will have to accept the request. That way, the unknown streams are >> not blocked by default. >> >> Next, in order to ensure that the streams are handled as best effort, >> the flow must be marked as such when entering the service provider >> network. This way, whenever congestion occurs somewhere in the >> access/aggregation network, this stream will be kicked out before the >> access provider's own premium content. >> >> The above concept is applicable beyond the notion of "Internet >> streams" or other unknown streams; it can applied to known multicast >> streams as well. In this case, the Access Node or NAS will accept >> the stream even when bandwidth may not be sufficient to support the >> stream. This again requires that the stream is marked as best effort >> traffic before entering the access/aggregation network. >> >> 3.4.2.2. Multicast Admission Control and White Lists >> >> As mentioned in section Section 3.4.1, conditional access to popular >> IPTV channels can be achieved by means of a White and Black list >> configured on the Access Node. This method allows the Access Node to >> autonomously decide whether or not access can be granted to a >> multicast flow. >> >> IPTV is an example of a service that will not be offered as best >> effort, but requires some level of guaranteed Quality of Service. >> This requires the use of Multicast Admission Control. Hence, if the >> Access Node wants to autonomously perform the admission process, it >> must be aware of the bandwidth characteristics of multicast flows. >> Otherwise, the Access Node would have to query the NAS for Multicast >> Admission Control; this would defeat the purpose of using a White and >> Black list. >> >> Some network deployments may combine the use of White list, Black >> list >> and Grey list. In this case, the AN will be aware of the portion of >> the bandwidth used on the Access Port for flows matching an entry in >> the White list. In order to perform Multicast Admission Control for >> flows matching an entry in the Grey list, the NAS should add the >> bandwidth characteristics of the flow in the Admission Response >> message. In this model, the AN would query the NAS for conditional >> access, and would then locally perform Multicast Conditional Access, >> using the bandwidth information retrieved from the NAS. >> >> << Section 4.2: add following requirements >> >> >> o The ANCP MUST support providing an Access Node with bandwidth >> information associated with multicast flows that are part of a >> White list. >> >> o The ANCP SHOULD allow the NAS to indicate the bandwidth >> information, associated with the requested multicast flows, in the >> admission decision sent to the AN. >> >> o In case a unicast and multicast stream share resources on an >> Access Port, the ANCP MUST allow the NAS to query the AN to >> request an admission decision for a unicast flow to be sent >> over that Port. >> >> << Section 4.7.6: add following requirements >> >> >> o The AN must be able to perform Admission Control for multicast >> streams, using the bandwith information of the requested multicast >> flow. The information may be provisioned by a management system >> or by the NAS (using a Control Reqest message or an Admission >> Response message). >> >> o Upon receiving a query from the NAS to request an admission >> decision for a unicast flow to be sent over a particular Access >> Port, the AN must support using ANCP to reply to the NAS, >> indicating whether the request is to be honored or denied. >> >> >> << Section 4.8.6: add following requirements >> >> >> o The NAS should support using ANCP to configure multicast >> admission control information to Access Ports on an Access Node. >> >> o Upon receiving a query from the AN for a request to replicate a >> multicast flow to a particular Access Port, the NAS should support >> using ANCP to reply to the AN indicating the bandwidth >> information, >> associated with the requested multicast flow. >> >> o Upon receiving a request from a Policy Server for a unicast flow >> to be sent over a particular Access Port, the NAS must support >> using ANCP to query the AN to receive a response indicating >> whether the request is to be honored or denied. >> >> --- >> >> Sven Ooghe >> Alcatel-Lucent >> CTO Office, Access Division >> Copernicuslaan 50, 2018 Antwerp, Belgium >> tel.: +32 3 240 42 26 >> fax: +32 3 240 40 73 >> >> This message (including any attachments) contains confidential >> information intended for a specific individual and purpose, and is >> protected by law. If you are not the intended recipient, you should >> delete this message. Any disclosure, copying, or distribution of this >> message, or the taking of any action based on it, is strictly prohibited >> without the prior consent of its author. >> >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 31 06:37:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKXjN-0001Ub-9D; Thu, 31 Jan 2008 06:37:21 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKXjM-0001UW-0q for ancp-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 06:37:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKXjL-0001UO-6J for ancp@ietf.org; Thu, 31 Jan 2008 06:37:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKXjJ-0005Ej-Ls for ancp@ietf.org; Thu, 31 Jan 2008 06:37:19 -0500 X-IronPort-AV: E=Sophos;i="4.25,285,1199660400"; d="scan'208";a="4488549" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2008 12:37:11 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0VBb1vZ029801; Thu, 31 Jan 2008 12:37:01 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0VBakFB005695; Thu, 31 Jan 2008 11:37:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 12:36:56 +0100 Received: from [10.0.0.61] ([10.61.81.79]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 12:36:55 +0100 In-Reply-To: <47A0B490.2040605@alcatel-lucent.be> References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> <47A0B490.2040605@alcatel-lucent.be> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP Multicast Admission Control Date: Thu, 31 Jan 2008 12:36:49 +0100 To: Stefaan DE CNODDER X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 31 Jan 2008 11:36:55.0949 (UTC) FILETIME=[951AB3D0:01C863FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11552; t=1201779421; x=1202643421; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20Multicast=20Admission=2 0Control |Sender:=20; bh=JBFSQu2EdvRswI+nxZgf0++fLhRj/gMKdU5yVJCWke8=; b=MpFvOE3U0Ay8AOM+1+uiE9/P+tu8GNoUxs/rmdygQ/CggLSQ3gRl0zpeZc evSdMsmLNUDjahtJdRn4Fu0i6Ah6jZBmJoqlw4vL3dy589fhE0em3zKjJo9u o12QA64QfI; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: OOGHE Sven , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Stefaan, On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote: > > Francois, > >> In addition, it is not clear to me how useful these additional >> models are. It also raises a number of questions. For example, if >> the Policy Server wants to query the AN, should it do so via the >> NAS instead of directly to AN? > > Both are possible, is there any preferred way according to you? > > Also, to be able to perform complete Video CAC, the AN >> would have to maintain user policy information (eg what is the >> fraction of line bandwidth that can be used for Video for that >> subscriber at that point in time considering the current DSL >> train rate). Is this in line with current ANCP model? how is user >> info made available to AN? What impact does all this have on ANCP? >> While we can start discussing those questions and the usefulness >> of such a model, IMHO this should not delay progress of current >> ANCP documents. >> So in short, I do _not_ support the additional text below relating >> to the introduction of the new additional model (PS-->NAS-->AN) >> and corresponding additional ANCP requirements. > > does this mean that you prefer PS-->AN? No. I am not expressing any preference for PS-->AN over PS-->NAS-->AN There seemed to be a lot of additional text proposed below relating to PS-->NAS-->AN as this involves ANCP more heavily. And I am simply stating that I do not support adding such text. The current framework defines PS-->AN and PS-->NAS-->AN as out of scope for now ("It is therefore beyond the scope of this document.") and I recommend we do not change scope at this stage if we want to have a first version of the ANCP protocol in the targeted timeframe. Those can always be easily added to the scope/protocol once there is stronger consensus/understanding or their applicability in the group and when the WG has completed the first base protocol spec. Francois > To be honest, for me both options are valid. Is there any specific > reason why you would not like to have the request going to the NAS? > > regards, > Stefaan > > >> Cheers >> Francois >> On 28 Jan 2008, at 14:18, OOGHE Sven wrote: >>> Hi, >>> >>> Based on the discussion on the list, I have prepared the >>> following text >>> proposal concerning multicast conditional access. I tried to >>> cover the >>> different scenarios that were identified on the list. This >>> includes the >>> proposal from Tina and Roberta, and feedback from Stefaan. >>> >>> If nobody objects, I will use the text below to update the text in >>> section 3.4.2 in the ANCP Framework. I will also add the >>> corresponding >>> requirements in section 4.2 (ANCP), 4.7.6 (Access Node) and >>> 4.8.6 (NAS). >>> >>> Regards, >>> Sven >>> >>> --- >>> >>> << Section 3.4.2 >> >>> >>> 3.4.2. Multicast Admission Control >>> >>> << first part of the section remains unchanged. The text from >>> the second >>> bullet onward is updated with below text >> >>> >>> 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. >>> >>> The second scenario can be split in to cases: >>> >>> o 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. >>> >>> o In case the Policy Server queries the AN indirectly via the >>> NAS, >>> the interaction can be handled as an ANCP transaction. >>> When the >>> Policy Server queries the NAS, the NAS can use ANCP to >>> query the >>> AN, specifying the Access-Loop-Circuit-ID and the required >>> bandwidth for the requested unicast flow. Upon receiving the >>> query from the NAS, the AN then performs Admission Control and >>> responds to the NAS, indicating if this unicast VoD >>> request can be >>> accepted or denied. >>> >>> 3.4.2.1. When not to perform Admission Control >>> >>> In general, the Access Node and NAS may not be aware of all >>> possible >>> multicast groups that will be streamed in the access network. >>> For >>> instance, it is likely that there will be multicast streams >>> offered >>> across the Internet. For these unknown streams, performing >>> bandwidth >>> admission control may be challenging. >>> >>> To solve this, these requests could be accepted without >>> performing >>> Admission Control. This solution works, provided that the >>> network >>> handles the streams as best effort, so that other streams are not >>> impacted at times of congestion. >>> >>> Disabling Admission Control for unknown stream can be achieved by >>> adding a "catch-all statement" in the Access Node white list >>> or grey >>> list. In case the Access Node queries the NAS, the NAS on his >>> turn >>> will have to accept the request. That way, the unknown >>> streams are >>> not blocked by default. >>> >>> Next, in order to ensure that the streams are handled as best >>> effort, >>> the flow must be marked as such when entering the service >>> provider >>> network. This way, whenever congestion occurs somewhere in the >>> access/aggregation network, this stream will be kicked out >>> before the >>> access provider's own premium content. >>> >>> The above concept is applicable beyond the notion of "Internet >>> streams" or other unknown streams; it can applied to known >>> multicast >>> streams as well. In this case, the Access Node or NAS will >>> accept >>> the stream even when bandwidth may not be sufficient to >>> support the >>> stream. This again requires that the stream is marked as >>> best effort >>> traffic before entering the access/aggregation network. >>> >>> 3.4.2.2. Multicast Admission Control and White Lists >>> >>> As mentioned in section Section 3.4.1, conditional access to >>> popular >>> IPTV channels can be achieved by means of a White and Black list >>> configured on the Access Node. This method allows the Access >>> Node to >>> autonomously decide whether or not access can be granted to a >>> multicast flow. >>> >>> IPTV is an example of a service that will not be offered as best >>> effort, but requires some level of guaranteed Quality of Service. >>> This requires the use of Multicast Admission Control. Hence, >>> if the >>> Access Node wants to autonomously perform the admission >>> process, it >>> must be aware of the bandwidth characteristics of multicast >>> flows. >>> Otherwise, the Access Node would have to query the NAS for >>> Multicast >>> Admission Control; this would defeat the purpose of using a >>> White and >>> Black list. >>> >>> Some network deployments may combine the use of White list, Black >>> list >>> and Grey list. In this case, the AN will be aware of the >>> portion of >>> the bandwidth used on the Access Port for flows matching an >>> entry in >>> the White list. In order to perform Multicast Admission >>> Control for >>> flows matching an entry in the Grey list, the NAS should add the >>> bandwidth characteristics of the flow in the Admission Response >>> message. In this model, the AN would query the NAS for >>> conditional >>> access, and would then locally perform Multicast Conditional >>> Access, >>> using the bandwidth information retrieved from the NAS. >>> >>> << Section 4.2: add following requirements >> >>> >>> o The ANCP MUST support providing an Access Node with bandwidth >>> information associated with multicast flows that are part of a >>> White list. >>> >>> o The ANCP SHOULD allow the NAS to indicate the bandwidth >>> information, associated with the requested multicast >>> flows, in the >>> admission decision sent to the AN. >>> >>> o In case a unicast and multicast stream share resources on an >>> Access Port, the ANCP MUST allow the NAS to query the AN to >>> request an admission decision for a unicast flow to be sent >>> over that Port. >>> >>> << Section 4.7.6: add following requirements >> >>> >>> o The AN must be able to perform Admission Control for multicast >>> streams, using the bandwith information of the requested >>> multicast >>> flow. The information may be provisioned by a management >>> system >>> or by the NAS (using a Control Reqest message or an Admission >>> Response message). >>> >>> o Upon receiving a query from the NAS to request an admission >>> decision for a unicast flow to be sent over a particular >>> Access >>> Port, the AN must support using ANCP to reply to the NAS, >>> indicating whether the request is to be honored or denied. >>> >>> >>> << Section 4.8.6: add following requirements >> >>> >>> o The NAS should support using ANCP to configure multicast >>> admission control information to Access Ports on an Access >>> Node. >>> >>> o Upon receiving a query from the AN for a request to >>> replicate a >>> multicast flow to a particular Access Port, the NAS should >>> support >>> using ANCP to reply to the AN indicating the bandwidth >>> information, >>> associated with the requested multicast flow. >>> >>> o Upon receiving a request from a Policy Server for a unicast >>> flow >>> to be sent over a particular Access Port, the NAS must support >>> using ANCP to query the AN to receive a response indicating >>> whether the request is to be honored or denied. >>> >>> --- >>> >>> Sven Ooghe >>> Alcatel-Lucent >>> CTO Office, Access Division >>> Copernicuslaan 50, 2018 Antwerp, Belgium >>> tel.: +32 3 240 42 26 >>> fax: +32 3 240 40 73 >>> >>> This message (including any attachments) contains confidential >>> information intended for a specific individual and purpose, and is >>> protected by law. If you are not the intended recipient, you should >>> delete this message. Any disclosure, copying, or distribution of >>> this >>> message, or the taking of any action based on it, is strictly >>> prohibited >>> without the prior consent of its author. >>> >>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 31 07:20:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYOq-0005DX-Iv; Thu, 31 Jan 2008 07:20:12 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKYOp-00058y-MG for ancp-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 07:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYOp-00057Y-BL for ancp@ietf.org; Thu, 31 Jan 2008 07:20:11 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKYOn-0002Gb-Qb for ancp@ietf.org; Thu, 31 Jan 2008 07:20:11 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0VCJ2IG026068; Thu, 31 Jan 2008 13:19:07 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 13:19:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] ANCP Multicast Admission Control Date: Thu, 31 Jan 2008 13:19:21 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA233C10@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: Achj/aYhdiiX06jCQ2mTC3HrFqnp8QABNh2Q References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> <47A0B490.2040605@alcatel-lucent.be> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" , "Tina TSOU" , "Maglione Roberta" X-OriginalArrivalTime: 31 Jan 2008 12:19:22.0762 (UTC) FILETIME=[831F86A0:01C86403] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Francois, For clarification: The text concerning PS-->AN and PS-->NAS-->AN interactions is based on the proposal sent by Tina and Roberta in http://www1.ietf.org/mail-archive/web/ancp/current/msg00446.html. At that point in time, there was no feedback on the proposal yet. I see you have concerns with the approach. Tina or Roberta, can you share your point of view? Regards, Sven -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: donderdag 31 januari 2008 12:37 To: DE CNODDER Stefaan Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control Hi Stefaan, On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote: > > Francois, > >> In addition, it is not clear to me how useful these additional models >> are. It also raises a number of questions. For example, if the Policy >> Server wants to query the AN, should it do so via the NAS instead of >> directly to AN? > > Both are possible, is there any preferred way according to you? > > Also, to be able to perform complete Video CAC, the AN >> would have to maintain user policy information (eg what is the =20 >> fraction of line bandwidth that can be used for Video for that =20 >> subscriber at that point in time considering the current DSL train =20 >> rate). Is this in line with current ANCP model? how is user info made >> available to AN? What impact does all this have on ANCP? >> While we can start discussing those questions and the usefulness of =20 >> such a model, IMHO this should not delay progress of current ANCP =20 >> documents. >> So in short, I do _not_ support the additional text below relating to >> the introduction of the new additional model (PS-->NAS-->AN) and =20 >> corresponding additional ANCP requirements. > > does this mean that you prefer PS-->AN? No. I am not expressing any preference for PS-->AN over PS-->NAS-->AN There seemed to be a lot of additional text proposed below relating to PS-->NAS-->AN as this involves ANCP more heavily. And I am simply stating that I do not support adding such text. The current framework defines PS-->AN and PS-->NAS-->AN as out of scope for now ("It is therefore beyond the scope of this document.") and I recommend we do not change scope at this stage if we want to have a first version of the ANCP protocol in the targeted timeframe. =20 Those can always be easily added to the scope/protocol once there is stronger consensus/understanding or their applicability in the group and when the WG has completed the first base protocol spec. Francois > To be honest, for me both options are valid. Is there any specific=20 > reason why you would not like to have the request going to the NAS? > > regards, > Stefaan > > >> Cheers >> Francois >> On 28 Jan 2008, at 14:18, OOGHE Sven wrote: >>> Hi, >>> >>> Based on the discussion on the list, I have prepared the following =20 >>> text proposal concerning multicast conditional access. I tried to=20 >>> cover the different scenarios that were identified on the list. This >>> includes the proposal from Tina and Roberta, and feedback from=20 >>> Stefaan. >>> >>> If nobody objects, I will use the text below to update the text in=20 >>> section 3.4.2 in the ANCP Framework. I will also add the=20 >>> corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access=20 >>> Node) and >>> 4.8.6 (NAS). >>> >>> Regards, >>> Sven >>> >>> --- >>> >>> << Section 3.4.2 >> >>> >>> 3.4.2. Multicast Admission Control >>> >>> << first part of the section remains unchanged. The text from the =20 >>> second bullet onward is updated with below text >> >>> >>> o Another approach is the reverse: it consists of the Policy=20 >>> 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 =20 >>> will >>> then query the AN, that in turn will perform unicast CAC for=20 >>> the >>> access line and respond, indicating whether the unicast =20 >>> request is >>> to be honored or denied. >>> >>> The second scenario can be split in to cases: >>> >>> o In case the Policy Server queries the AN directly, the=20 >>> approach >>> doesn't require the use of ANCP. It is therefore beyond the =20 >>> scope >>> of this document. >>> >>> o In case the Policy Server queries the AN indirectly via the=20 >>> NAS, >>> the interaction can be handled as an ANCP transaction. =20 >>> When the >>> Policy Server queries the NAS, the NAS can use ANCP to query=20 >>> the >>> AN, specifying the Access-Loop-Circuit-ID and the required >>> bandwidth for the requested unicast flow. Upon receiving the >>> query from the NAS, the AN then performs Admission Control and >>> responds to the NAS, indicating if this unicast VoD request =20 >>> can be >>> accepted or denied. >>> >>> 3.4.2.1. When not to perform Admission Control >>> >>> In general, the Access Node and NAS may not be aware of all =20 >>> possible >>> multicast groups that will be streamed in the access network. =20 >>> For >>> instance, it is likely that there will be multicast streams=20 >>> offered >>> across the Internet. For these unknown streams, performing =20 >>> bandwidth >>> admission control may be challenging. >>> >>> To solve this, these requests could be accepted without=20 >>> performing >>> Admission Control. This solution works, provided that the=20 >>> network >>> handles the streams as best effort, so that other streams are not >>> impacted at times of congestion. >>> >>> Disabling Admission Control for unknown stream can be achieved by >>> adding a "catch-all statement" in the Access Node white list or =20 >>> grey >>> list. In case the Access Node queries the NAS, the NAS on his=20 >>> turn >>> will have to accept the request. That way, the unknown streams=20 >>> are >>> not blocked by default. >>> >>> Next, in order to ensure that the streams are handled as best =20 >>> effort, >>> the flow must be marked as such when entering the service=20 >>> provider >>> network. This way, whenever congestion occurs somewhere in the >>> access/aggregation network, this stream will be kicked out =20 >>> before the >>> access provider's own premium content. >>> >>> The above concept is applicable beyond the notion of "Internet >>> streams" or other unknown streams; it can applied to known =20 >>> multicast >>> streams as well. In this case, the Access Node or NAS will=20 >>> accept >>> the stream even when bandwidth may not be sufficient to support=20 >>> the >>> stream. This again requires that the stream is marked as best =20 >>> effort >>> traffic before entering the access/aggregation network. >>> >>> 3.4.2.2. Multicast Admission Control and White Lists >>> >>> As mentioned in section Section 3.4.1, conditional access to =20 >>> popular >>> IPTV channels can be achieved by means of a White and Black list >>> configured on the Access Node. This method allows the Access =20 >>> Node to >>> autonomously decide whether or not access can be granted to a >>> multicast flow. >>> >>> IPTV is an example of a service that will not be offered as best >>> effort, but requires some level of guaranteed Quality of Service. >>> This requires the use of Multicast Admission Control. Hence, if >>> the >>> Access Node wants to autonomously perform the admission process,=20 >>> it >>> must be aware of the bandwidth characteristics of multicast=20 >>> flows. >>> Otherwise, the Access Node would have to query the NAS for =20 >>> Multicast >>> Admission Control; this would defeat the purpose of using a =20 >>> White and >>> Black list. >>> >>> Some network deployments may combine the use of White list, Black >>> list >>> and Grey list. In this case, the AN will be aware of the =20 >>> portion of >>> the bandwidth used on the Access Port for flows matching an =20 >>> entry in >>> the White list. In order to perform Multicast Admission Control >>> for >>> flows matching an entry in the Grey list, the NAS should add the >>> bandwidth characteristics of the flow in the Admission Response >>> message. In this model, the AN would query the NAS for=20 >>> conditional >>> access, and would then locally perform Multicast Conditional =20 >>> Access, >>> using the bandwidth information retrieved from the NAS. >>> >>> << Section 4.2: add following requirements >> >>> >>> o The ANCP MUST support providing an Access Node with bandwidth >>> information associated with multicast flows that are part of a >>> White list. >>> >>> o The ANCP SHOULD allow the NAS to indicate the bandwidth >>> information, associated with the requested multicast flows, =20 >>> in the >>> admission decision sent to the AN. >>> >>> o In case a unicast and multicast stream share resources on an >>> Access Port, the ANCP MUST allow the NAS to query the AN to >>> request an admission decision for a unicast flow to be sent >>> over that Port. >>> >>> << Section 4.7.6: add following requirements >> >>> >>> o The AN must be able to perform Admission Control for multicast >>> streams, using the bandwith information of the requested =20 >>> multicast >>> flow. The information may be provisioned by a management=20 >>> system >>> or by the NAS (using a Control Reqest message or an Admission >>> Response message). >>> >>> o Upon receiving a query from the NAS to request an admission >>> decision for a unicast flow to be sent over a particular=20 >>> Access >>> Port, the AN must support using ANCP to reply to the NAS, >>> indicating whether the request is to be honored or denied. >>> >>> >>> << Section 4.8.6: add following requirements >> >>> >>> o The NAS should support using ANCP to configure multicast >>> admission control information to Access Ports on an Access=20 >>> Node. >>> >>> o Upon receiving a query from the AN for a request to replicate=20 >>> a >>> multicast flow to a particular Access Port, the NAS should =20 >>> support >>> using ANCP to reply to the AN indicating the bandwidth=20 >>> information, >>> associated with the requested multicast flow. >>> >>> o Upon receiving a request from a Policy Server for a unicast=20 >>> flow >>> to be sent over a particular Access Port, the NAS must support >>> using ANCP to query the AN to receive a response indicating >>> whether the request is to be honored or denied. >>> >>> --- >>> >>> Sven Ooghe >>> Alcatel-Lucent >>> CTO Office, Access Division >>> Copernicuslaan 50, 2018 Antwerp, Belgium >>> tel.: +32 3 240 42 26 >>> fax: +32 3 240 40 73 >>> >>> This message (including any attachments) contains confidential=20 >>> information intended for a specific individual and purpose, and is=20 >>> protected by law. If you are not the intended recipient, you should >>> delete this message. Any disclosure, copying, or distribution of=20 >>> this >>> message, or the taking of any action based on it, is strictly =20 >>> prohibited >>> without the prior consent of its author. >>> >>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jan 31 07:21:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYPi-0006Hr-PR; Thu, 31 Jan 2008 07:21:06 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1JKYPh-0006Hl-Cd for ancp-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 07:21:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYPh-0006Hd-11 for ancp@ietf.org; Thu, 31 Jan 2008 07:21:05 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKYPg-0007cm-DC for ancp@ietf.org; Thu, 31 Jan 2008 07:21:04 -0500 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0VCBbpH019670; Thu, 31 Jan 2008 13:11:47 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 13:20:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] ANCP Multicast Admission Control Date: Thu, 31 Jan 2008 13:20:35 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA233C12@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9BE48792-AB5D-40D4-98BA-50B073352DEE@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: AchjMAi2/ZTPqhzeTYmSKYqWKHbTPwA04TFw References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> <9BE48792-AB5D-40D4-98BA-50B073352DEE@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 31 Jan 2008 12:20:36.0595 (UTC) FILETIME=[AF218C30:01C86403] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Francois, I'm ok with both suggested changes. They better reflect what I intended to write. Regards, Sven=20 -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: woensdag 30 januari 2008 12:05 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control Hi again Sven, I support introduction of the text you propose below for section 3.4.2.1 (related to our earlier agreement on being able to do CAC on some flows and not on others). Minor suggestions: - could change title into something like "By-passing admission control for some flows" or "When not to perform admission control for a subset of flows". The idea being that the title makes it clear that we don't do CAC on some flows BUT still do CAC on others. - s/"so that other streams are not impacted"/"so that other streams (that are subject to admission control) are not impacted"/ Thanks Francois > > 3.4.2.1. When not to perform Admission Control > > In general, the Access Node and NAS may not be aware of all=20 > possible > multicast groups that will be streamed in the access network. For > instance, it is likely that there will be multicast streams offered > across the Internet. For these unknown streams, performing=20 > bandwidth > admission control may be challenging. > > To solve this, these requests could be accepted without performing > Admission Control. This solution works, provided that the network > handles the streams as best effort, so that other streams are not > impacted at times of congestion. > > Disabling Admission Control for unknown stream can be achieved by > adding a "catch-all statement" in the Access Node white list or=20 > grey > list. In case the Access Node queries the NAS, the NAS on his turn > will have to accept the request. That way, the unknown streams are > not blocked by default. > > Next, in order to ensure that the streams are handled as best=20 > effort, > the flow must be marked as such when entering the service provider > network. This way, whenever congestion occurs somewhere in the > access/aggregation network, this stream will be kicked out before=20 > the > access provider's own premium content. > > The above concept is applicable beyond the notion of "Internet > streams" or other unknown streams; it can applied to known=20 > multicast > streams as well. In this case, the Access Node or NAS will accept > the stream even when bandwidth may not be sufficient to support the > stream. This again requires that the stream is marked as best=20 > effort > traffic before entering the access/aggregation network. > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp