From fan.liang2@zte.com.cn Sun Jul 3 20:07:57 2011 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D01F0C41 for ; Sun, 3 Jul 2011 20:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.954 X-Spam-Level: X-Spam-Status: No, score=-100.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYfqDdMIYxXF for ; Sun, 3 Jul 2011 20:07:56 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DA37A1F0C39 for ; Sun, 3 Jul 2011 20:07:55 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322038417834; Mon, 4 Jul 2011 11:03:40 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 86255.4912735981; Mon, 4 Jul 2011 11:07:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6437Zn7078090; Mon, 4 Jul 2011 11:07:35 +0800 (GMT-8) (envelope-from fan.liang2@zte.com.cn) To: flefauch@cisco.com, roberta.maglione@telecomitalia.it, tom111.taylor@bell.net MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fan.liang2@zte.com.cn Date: Mon, 4 Jul 2011 11:07:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-04 11:07:36, Serialize complete at 2011-07-04 11:07:36 Content-Type: multipart/alternative; boundary="=_alternative 00112DB0482578C3_=" X-MAIL: mse02.zte.com.cn p6437Zn7078090 Cc: ancp@ietf.org Subject: [ANCP] About draft-ietf-ancp-mc-extensions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 03:07:57 -0000 This is a multipart message in MIME format. --=_alternative 00112DB0482578C3_= Content-Type: text/plain; charset="US-ASCII" Hi Authors, I have got some suggestion about ANCP multicast accounting feature. Hope that I could get your response. According to RFC 5851(Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks), 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 starts and stops. My suggestions of implementing multicast accounting feature by using ANCP protocol: 1. Currently, there's already an accounting field in multicast replication control message in draft-ietf-ancp-mc-extensions (http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-04#section-4.3). Meaningful only when the Command Code is "Add" (0x01). In that case, 0x00 indicates no flow accounting, 0x01 indicates that octet accounting for the flow is to commence. I think we need a 0x02 to indicates the time accounting for the flow. 2. Do we need also some corresponding TLV in the Generic Response message to indicates that if the Access Node could support octet accounting/time accounting (depends on the multicast replication control message) or not? It could be an extension to Generic Response Message in NAS Initiated Multicast Replication Control Use Case (http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-04#section-3.1.2 ), or a dedicated Generic Response Message in Conditional Access and Admission Control Use Case ( http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-04#section-3.2.2 ). 3. Based on this multicast accounting feature, we need also some extension to multicast flow reporting, for both use case and messages/TLVs. 1) Use case extension: The access node should be able to automatically (or we could say "triggered" by multicast replication control message of ) send reports to the NAS, including Multicast Replication Starts/Ends time, or Multicast Replication Volume (could be periodically or just twice (when the multicast replication starting/terminating)), or both of them. And now the Access Node will just send multicast flow reports message (Multicast Flow Query Response) to the NAS when receiving the Multicast Flow Request. 2)Messages/TLVs extension: Meesages: There could be a new Multicast Accounting Reports Message or some TLV extension to current Multicast Flow Query Response Message for reporting accounting results of specific multicast flows. Which one do you think is better? For my part, the latter is better, since it could be a kind of "generic reponse" for both Multicast Replication control Message and on demand Multicast Flow Query Request Message. TLVs: There could be Replication Start Time TLV, Replication Ends Time TLV and Replication Volume TLV to indicates the the replicating starts/ends time and the replicating volume. Waiting for your feedback. Best regards Fan Liang -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00112DB0482578C3_= Content-Type: text/html; charset="US-ASCII"
Hi Authors,

I have got some suggestion about ANCP multicast accounting feature. Hope that I could get your response.
According to RFC 5851(Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks),   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 starts and stops.  

My suggestions of implementing multicast accounting feature by using ANCP protocol:

1. Currently, there's already an accounting field in multicast replication control message in draft-ietf-ancp-mc-extensions
(http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-04#section-4.3).  Meaningful only when the Command Code is "Add" (0x01).  In that case, 0x00 indicates no flow accounting, 0x01 indicates that octet accounting for the flow is to commence. I think we need a 0x02 to indicates the time accounting for the flow.

2. Do we need also some corresponding TLV in the Generic Response message to indicates that if the Access Node could support octet accounting/time accounting (depends on the multicast replication control message) or not? It could be an extension to Generic Response Message  in NAS Initiated Multicast Replication Control Use Case
(http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-04#section-3.1.2), or a dedicated Generic Response Message in Conditional Access and Admission Control Use Case (http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-04#section-3.2.2 ).

3. Based on this multicast accounting feature, we need also some extension to multicast flow reporting, for both use case and messages/TLVs.
1) Use case extension: The access node should be able to automatically (or we could say "triggered" by multicast replication control message of ) send reports to the NAS, including Multicast Replication Starts/Ends time, or Multicast Replication Volume (could be periodically or  just twice (when the multicast replication starting/terminating)), or both of them. And now the Access Node will just send multicast flow reports message (Multicast Flow Query Response) to the NAS when receiving the Multicast Flow Request.

2)Messages/TLVs extension:
Meesages: There could be a new Multicast Accounting Reports Message or some TLV extension to current Multicast Flow Query Response Message for reporting accounting results of specific multicast flows. Which one do you think is better? For my part,  the latter is better, since it could be a kind of "generic reponse" for both Multicast Replication control Message and on demand Multicast Flow Query Request Message.

TLVs: There could be Replication Start Time TLV, Replication Ends Time TLV and Replication Volume TLV to indicates the the replicating starts/ends time and the replicating volume.

Waiting for your feedback.

Best regards
Fan Liang 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00112DB0482578C3_=-- From matthew.bocci@alcatel-lucent.com Thu Jul 7 09:24:55 2011 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F8D1F0C3D for ; Thu, 7 Jul 2011 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rByxDXRJja8x for ; Thu, 7 Jul 2011 09:24:54 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6002B1F0C3C for ; Thu, 7 Jul 2011 09:24:54 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p67GORXf031184 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 7 Jul 2011 18:24:52 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 7 Jul 2011 18:24:47 +0200 From: "Bocci, Matthew (Matthew)" To: "ancp@ietf.org" Date: Thu, 7 Jul 2011 18:24:45 +0200 Thread-Topic: ANCP Quebec meeting cancelled Thread-Index: Acw8wmMGppAZsCzkRUuUGBsuNddmZw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA3B9C5D13299matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [ANCP] ANCP Quebec meeting cancelled X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:24:55 -0000 --_000_CA3B9C5D13299matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We've had no slot requests for ANCP in Quebec, and unfortunately some of ou= r key contributors will not be able to attend, so we believe we should canc= el the ANCP meeting. We plan to hold a Webex session shortly after the Queb= ec IETF, if there is interest. Please let me know if you have any concerns. Best regards, Matthew --_000_CA3B9C5D13299matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,

We've had no slot requests for ANCP in Quebec, and unfortunately so= me of our key contributors will not be able to attend, so we believe we sho= uld cancel the ANCP meeting. We plan to hold a Webex session shortly after = the Quebec IETF, if there is interest.

Please let = me know if you have any concerns.

Best regards,

Matthew
--_000_CA3B9C5D13299matthewboccialcatellucentcom_-- From Internet-Drafts@ietf.org Mon Jul 11 16:15:02 2011 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A963E11E835F; Mon, 11 Jul 2011 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrdfKqKmmFIF; Mon, 11 Jul 2011 16:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C589C11E8354; Mon, 11 Jul 2011 16:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711231501.15132.41232.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 16:15:01 -0700 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-pon-01.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 23:15:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Applicability of Access Node Control Mechanism to PON based Broadband Networks Author(s) : N. Bitar, et al Filename : draft-ietf-ancp-pon-01.txt Pages : 35 Date : 2011-07-11 The purpose of this document is to provide applicability of the Access Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS- related, service-related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to- device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-pon-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-pon-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-11160041.I-D@ietf.org> --NextPart--