From ancp-bounces@ietf.org Sun Mar 04 05:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNoRA-0004UA-Tj; Sun, 04 Mar 2007 05:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNoRA-0004T5-7v for ancp@ietf.org; Sun, 04 Mar 2007 05:59:32 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNoR8-0003t1-Pm for ancp@ietf.org; Sun, 04 Mar 2007 05:59:32 -0500 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l24AxQ8F020137; Sun, 4 Mar 2007 11:59:26 +0100 In-Reply-To: Subject: [ANCP] Reminder: Prague meeting slots To: Matthew.Bocci@alcatel-lucent.co.uk X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Sun, 4 Mar 2007 10:59:09 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/04/2007 10:59:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Folks, Don't forget to get your slot requests to me by Tuesday 6th. Regards, Matthew Matthew.Bocci@alc atel-lucent.co.uk To 23/02/2007 08:35 ancp@ietf.org cc Subject [ANCP] Prague meeting slots Folks, We have a 2 hour session for ANCP, tentatively scheduled for 13:00 on Tuesday 20th March. Please can you let me know if you would like a slot to present during the meeting, by 6th March. As usual, please include a brief summary of what you want to talk about, a pointer to the draft (if any), and the time. Best regards, Matthew _______________________________________________ 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 Mar 06 07:44:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZ2B-0002vx-H9; Tue, 06 Mar 2007 07:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZ29-0002vs-KW for ancp@ietf.org; Tue, 06 Mar 2007 07:44:49 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOZ27-0008SR-5M for ancp@ietf.org; Tue, 06 Mar 2007 07:44:49 -0500 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l26Cif1Z005377 for ; Tue, 6 Mar 2007 13:44:41 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Tue, 6 Mar 2007 12:36:18 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/06/2007 12:44:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [ANCP] ANCP agenda for Prague 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 Here is the first version of the agenda. Please let me know if you have any comments/Corrections. Regards, Matthew TUESDAY, March 20th, 2007: 13:00 - 15:00 ------------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci 15 mins - Administrivia, WG Status and WG Docs Update - Chairs 10 mins - ANCP Framework / Requirements - Sven Ooghe (sven.ooghe@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-01.txt 15 mins - ANCP Acess Node MIBs - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an-01.txt 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-00.txt 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-03.txt 15 mins - Access Topology Discovery - Wojciech Dec (wdec@cisco.com) 15 mins - ANCP Multicast Discussion - Chairs _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Mar 06 08:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOa2h-00006D-3P; Tue, 06 Mar 2007 08:49:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOa2f-000065-Qv for ancp@ietf.org; Tue, 06 Mar 2007 08:49:25 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOa2e-0005tm-Cg for ancp@ietf.org; Tue, 06 Mar 2007 08:49:25 -0500 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l26DnINf024994 for ; Tue, 6 Mar 2007 14:49:18 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Tue, 6 Mar 2007 13:49:02 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/06/2007 13:49:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [ANCP] Multicast in ANCP 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 would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Mar 06 09:41:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOaqw-0000zQ-Gr; Tue, 06 Mar 2007 09:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOaqv-0000yd-4i for ancp@ietf.org; Tue, 06 Mar 2007 09:41:21 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOanZ-0007Eh-Eo for ancp@ietf.org; Tue, 06 Mar 2007 09:38:04 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Mar 2007 06:37:53 -0800 X-IronPort-AV: i="4.14,254,1170662400"; d="scan'208"; a="666546011:sNHT44459792" 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 agenda for Prague Date: Tue, 6 Mar 2007 09:37:52 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280794EEA7@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP agenda for Prague Thread-Index: Acdf7Wriiob++UAVTKqsqi6xNL6mkwADGtBQ From: "Sanjay Wadhwa" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Matthew The latest version of the protocol draft (renamed as draft-ietf-ancp-protocol-00.txt) was submitted before the submission deadline. Please update the pointer below.=20 Thanks -Sanjay -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: Tuesday, March 06, 2007 7:36 AM To: ancp@ietf.org Subject: [ANCP] ANCP agenda for Prague Here is the first version of the agenda. Please let me know if you have any comments/Corrections. Regards, Matthew TUESDAY, March 20th, 2007: 13:00 - 15:00 ------------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci 15 mins - Administrivia, WG Status and WG Docs Update - Chairs 10 mins - ANCP Framework / Requirements - Sven Ooghe (sven.ooghe@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-01.txt 15 mins - ANCP Acess Node MIBs - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an-01.txt 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-00. txt 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configur ation-03.txt 15 mins - Access Topology Discovery - Wojciech Dec (wdec@cisco.com) 15 mins - ANCP Multicast Discussion - Chairs _______________________________________________ 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 Mar 07 04:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsBU-0002Tz-HD; Wed, 07 Mar 2007 04:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOpmv-0006bC-05 for ancp@ietf.org; Wed, 07 Mar 2007 01:38:13 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOpmr-000827-Qm for ancp@ietf.org; Wed, 07 Mar 2007 01:38:12 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 03F742074A for ; Wed, 7 Mar 2007 11:30:40 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id E457820723 for ; Wed, 7 Mar 2007 11:30:39 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 12:08:01 +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 Subject: RE: [ANCP] Multicast in ANCP Date: Wed, 7 Mar 2007 12:07:43 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9nDcpcntxRH+TB+TgLWSnyu1swAfQJ6w References: From: To: , X-OriginalArrivalTime: 07 Mar 2007 06:38:01.0618 (UTC) FILETIME=[27177720:01C76083] X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 My view on use of ANCP for multicast is as follows: As defined the ANCP framework draft, the Access Node could get the subscribers configuration for Multicast from the NAS. This would typically include the list of channels authorized to view by the subscribers connected to user ports. Having said that, whether the Access Node gets the subscribers configuration list from the NAS using PUSH or PULL mechanism and whether Access Node gets the list statically or dynamically (or every few time intervals) should be left to implementation specific. I think we don't need to mention about this in any of ANCP drafts. The objective is to get the configuration information from the NAS. Now, what Access Node can possibly do with the subscriber configuration (specically channel entitlement list)? The main usage of this list I see is, the Access Node (which is performing IGMP snoop or IGMP proxy) can start replicating the channel to a suscriber based on the channel entitlement list.=20 Consider a case, if user post '5' is already subscribed to channel 'x', if user port '10' issue a join message to receive channel 'x', the Access Node could decide to replicate the channel 'x' to user port '10' based on the authorization list. This way the channel zap time would be faster. Again an optimization could be that Access Node after exchancing channel authorization list could subscribe to all/all the premium channels which user ports are entitiled to join, and start replicating to user ports (based on authorization list)as when the join requests come. This is debatable and asolutely an implementation issue. We don't need to cover this in any of ANCP drafts. On the downside of ANCP use case for multicast, I see ANCP serves no purpose, when two subscribers (two Set-Top-Boxes) are attached to a single user port, where application based authorization (based on encryption/decryption) would be a better choice. My answer to Mtthew's point in below mail below would be, 1. I don't see a need to specify any use case in the framework draft, since this draft already talks about exchanging the subscriber related information between Access Node and NAS for multicast purposes at high level. It should be left to implementation how this information is used in Access Node or how this information is exchanced with NAS. 2. Never the less, the protocol draft could include message type, format and associated TLVs for exchanging the multicast related subscriber information between the Access Node and NAS. Comments are welcome. Rgds, Sathiya -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: Tuesday, March 06, 2007 7:19 PM To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Mar 07 04:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsDQ-00075n-9M; Wed, 07 Mar 2007 04:13:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOrq7-00057u-T3 for ancp@ietf.org; Wed, 07 Mar 2007 03:49:39 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOrq7-0003aa-0n for ancp@ietf.org; Wed, 07 Mar 2007 03:49:39 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id BD88920741 for ; Wed, 7 Mar 2007 13:42:08 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9B58120782 for ; Wed, 7 Mar 2007 13:42:08 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 14:19:30 +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 Subject: RE: [ANCP] Multicast in ANCP Date: Wed, 7 Mar 2007 14:19:26 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [ANCP] Multicast in ANCP Thread-Index: Acdf9nDcpcntxRH+TB+TgLWSnyu1swAfQJ6wAAh8XnA= From: To: X-OriginalArrivalTime: 07 Mar 2007 08:49:30.0334 (UTC) FILETIME=[8521FFE0:01C76095] X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 My view on use of ANCP for multicast is as follows: As defined the ANCP framework draft, the Access Node could get the subscribers configuration for Multicast from the NAS. This would typically include the list of channels authorized to view by the subscribers connected to user ports. Having said that, whether the Access Node gets the subscribers configuration list from the NAS using PUSH or PULL mechanism and whether Access Node gets the list statically or dynamically (or every few time intervals) should be left to implementation specific. I think we don't need to mention about this in any of ANCP drafts. The objective is to get the configuration information from the NAS. Now, what Access Node can possibly do with the subscriber configuration (specically channel entitlement list)? The main usage of this list I see is, the Access Node (which is performing IGMP snoop or IGMP proxy) can start replicating the channel to a suscriber based on the channel entitlement list.=20 Consider a case, if user post '5' is already subscribed to channel 'x', if user port '10' issue a join message to receive channel 'x', the Access Node could decide to replicate the channel 'x' to user port '10' based on the authorization list. This way the channel zap time would be faster. Again an optimization could be that Access Node after exchancing channel authorization list could subscribe to all/all the premium channels which user ports are entitiled to join, and start replicating to user ports (based on authorization list)as when the join requests come. This is debatable and asolutely an implementation issue. We don't need to cover this in any of ANCP drafts. On the downside of ANCP use case for multicast, I see ANCP serves no purpose, when two subscribers (two Set-Top-Boxes) are attached to a single user port, where application based authorization (based on encryption/decryption) would be a better choice. My answer to Mtthew's point in below mail below would be, 1. I don't see a need to specify any use case in the framework draft, since this draft already talks about exchanging the subscriber related information between Access Node and NAS for multicast purposes at high level. It should be left to implementation how this information is used in Access Node or how this information is exchanced with NAS. 2. Never the less, the protocol draft could include message type, format and associated TLVs for exchanging the multicast related subscriber information between the Access Node and NAS. Comments are welcome. Rgds, Sathiya -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk] Sent: Tuesday, March 06, 2007 7:19 PM To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Mar 07 11:41:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzCM-0003JX-1k; Wed, 07 Mar 2007 11:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzCK-0003JS-Ng for ancp@ietf.org; Wed, 07 Mar 2007 11:41:04 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOzCD-0006NQ-Kl for ancp@ietf.org; Wed, 07 Mar 2007 11:41:04 -0500 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:40:53 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.227]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:40:53 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Importance: normal Priority: normal Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast in ANCP Date: Wed, 7 Mar 2007 17:40:52 +0100 Message-ID: <9E577E61D0108D4F8CD482029B613F5C0181B9D2@PTPEVS108BA020.idc.cww.telecomitalia.it> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP thread-index: Acdf9khgTFd1uNzcTc+dN/jHyJuQzgA4H46Q References: From: "Maglione Roberta" To: , X-OriginalArrivalTime: 07 Mar 2007 16:40:53.0383 (UTC) FILETIME=[5F24C970:01C760D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Hello, I have a different opinion on using ANCP for multicast traffic, in particular I have in mind a couple of scenarios where ANCP could be very useful to deal with multicast replication on Access Node. 1. What I think is currently missing is a standard authentication mechanism that could be used by the Access Node to control the delivery of the multicast traffic to the end user; in particular the capability to associate a subscriber's multicast replication service profile with a user session and a mechanism to provide conditional authorization for multicast traffic. I don't think the mechanism used to exchange authentication info related to channels white/black lists between Access Node and NAS are implementation issues, IMHO this should be part of ANCP job.=20 2. An additional scenario where ANCP could be useful for multicast traffic is for accounting purposes both time-based accounting and prepaid accounting; what I'm thinking is a mechanism to trigger generation of accounting start and stop records based on multicast replication. 3. A scenario where Dynamic Multicast replication stop is required; for example if a user is currently watching a movie and the SP would like to send him a sort of advertisement; a capability to stop the current multicast replication on the Access Node is required. 4. Additional application could be a scenario where a network operator would like to control bandwidth admission requests for a contended shared unicast and multicast bandwidth pool on the access link . These are just starting points but IMHO I think ANCP is valuable protocol to be used to address these type of scenarios that's why I think we should not remove Multicast section from ANCP charter, instead we should try to start working more on this topic. Best regards, Roberta =20 -------------------------------------------------------------------- Roberta Maglione Telecom Italia - T.IE.AFT.BI Broadband Network Service Innovation Via G. Reiss Romoli 274 10148 Torino - Italy Phone: +39 011 228 5007 e-mail: roberta.maglione@telecomitalia.it ------------------------------------------------------------------- -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: Tuesday, March 06, 2007 2:49 PM To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = 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 Wed Mar 07 23:27:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPADu-0003k3-2a; Wed, 07 Mar 2007 23:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPADt-0003im-C7 for ancp@ietf.org; Wed, 07 Mar 2007 23:27:25 -0500 Received: from kecgate06.infosys.com ([61.95.162.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPADs-0008Gc-Ek for ancp@ietf.org; Wed, 07 Mar 2007 23:27:25 -0500 Received: from indhubbhs03.ad.infosys.com ([192.168.200.83]) by Kecgate06.infosys.com with InterScan Messaging Security Suite; Wed, 07 Mar 2007 22:18:51 +0530 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by indhubbhs03.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 22:18:50 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 22:18:49 +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 Subject: RE: [ANCP] Multicast in ANCP Date: Wed, 7 Mar 2007 22:18:47 +0530 Message-ID: <6031539A3C7B964581EFCE2E205D6EEF01F8AED0@BLRKECMSG01.ad.infosys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9i8ZnPSUMzWTQ62YJb9K0lstqwAx7mLg References: From: "bharat_joshi" To: X-OriginalArrivalTime: 07 Mar 2007 16:48:49.0919 (UTC) FILETIME=[7B2E68F0:01C760D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Matthew, I have some suggestions. Please see in line. Thanks & Regards, Bharat > I would like to start a discussion on what the working group would like to > do with Multicast in ANCP. >=0D > Currently the ANCP charter includes multicast as one of the use cases, as > follows: >=0D > "When multicast replication for subscriber-bound traffic is performed at > the AN, it off-loads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow the > AN > to perform subscriber bound multicast group replication in line with the > subscriber's policy and configuration, and also allow the NAS to follow > each subscriber's multicast group membership." >=0D > The framework draft (draft-ietf-ancp-framework-01.txt) says that the > access > loop configuration mechanisms may be useful for setting the per-Subscriber > multicast channel entitlement information, used for IPTV applications > where > the Access Node is performing IGMP snooping or IGMP proxy function. It > goes > on to say that a Subscriber's policy and configuration for multicast > traffic might only be known at the NAS. The Access Node Control Mechanism > could be used to exchange the necessary information between the Access > Node > and the NAS so as to allow the Access Node to perform multicast > replication > in line with the Subscriber's policy and configuration, and also allow > the > NAS to follow each Subscriber's multicast group membership. >=0D >=0D > None of these multicast mechanisms are defined in the ANCP protocol draft, > and I think there is insufficient detail in the framework draft to fully > specify this use case. > Yes. I think we need to enhance the existing details to be more specific on what kind of information we would want an NAS to be sending to AN. I think there are two cases which we should consider: * IGMP Snooping is not enabled in AN: In this case, Access Node does not snoop IGMP packets and so it is NAS which verify the authorization of a user if he can join a group and if it passes, NAS sends an ANCP message to the AN and ask it to create a forwarding state for this group. Once NAS receives a leave message, NAS sends another message to AN to remove the forwarding state. * IGMP Snooping is enabled in AN: In this case, Access node snoops IGMP packet but does not have the subscriber related information to authorize the user if it can join the group. So what we can do in this case is that as soon as a line comes up, NAS can forward the subscriber related information to AN using ANCP messages. AN can make use of this information to create the forwarding state. AN removes the forwarding state when it snoops a leave message. I think we should consider both the cases above and defined ANCP messages accordingly. In both the above cases, we would also need to send following things defined: * Till what time these entries are valid? Will there be a periodic update? > There has been very little work on this since the charter discussions, but > the ANCP working group needs to clarify what it wants to do (if anything) > with multicast for the framework can move forward. I think there are two > choices: Either we should clarify the use case and specify the ANCP > protocol to support it, or we should remove the multicast use case from > the=0D > framework for now. >=0D I think we should keep it in the framework document and at least add the possible scenarios where ANCP shall be used. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Mar 12 12:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnAB-0001YT-I2; Mon, 12 Mar 2007 12:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnA9-0001We-MR for ancp@ietf.org; Mon, 12 Mar 2007 12:14:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnA8-0004hS-1g for ancp@ietf.org; Mon, 12 Mar 2007 12:14:17 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2007 17:14:16 +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 l2CGE6R1009527 for ; Mon, 12 Mar 2007 17:14:06 +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 l2CGE2Ap012281 for ; Mon, 12 Mar 2007 16:14:06 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, 12 Mar 2007 17:13:59 +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 in ANCP Date: Mon, 12 Mar 2007 17:13:44 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWg From: "Wojciech Dec \(wdec\)" To: , X-OriginalArrivalTime: 12 Mar 2007 16:13:59.0515 (UTC) FILETIME=[7144D2B0:01C764C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5973; t=1173716055; x=1174580055; 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=20in=20ANCP |Sender:=20; bh=xdZfjR/ee91MAM0vIVL4ZJTE/7mYgw0hjOPYuvqi+xc=; b=D0SY9GsKrnCcXIU5ZghWR9OmdRpvuJNHKQ7inIPFsL/kxvCFoWOzPYZkGTM4lAYQtAJ0nps9 sd3oxq9cCbwHTu69ZV7aOfA8vOLuMq2/dVEYMHIXEcMVQRwM6Bfykp8n; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 2.3 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 All, (chair hat off) I propose that the ANCP multicast requirements should cover the following 3 areas: 1. Dynamic configuration There appears to be a need to be able to control the multicast replication at the access-node in accordance with per user or per circuit-id policies known at the controller, and do so in a dynamic vs a one time provisioned manner. Currently operators do so by statically configuring an ingress IGMP filtering ACL on a given circuit-id, which is not amenable to dynamic changes. By dynamic changes it's meant that they are ones that are quickly executed in response to other system events, eg a subscriber session coming up/down, the expiration of a quota or timer, or a policy trigger, or even operator command.=20 ANCP would need to be able to install such ACLs through an efficient transaction mechanism. Two forms of installation appear to be worthwhile of consideration:=20 i) overwrite - a complete ACL is applied in a transaction on a target circuit-id ii) add/remove - one or more entries are added/removed in a transaction on a target circuit-id. 2. Reporting Several service providers currently run operational procedures that rely on an operator being able to issue/troubleshoot a subscriber's problems from a BNG. Classic examples of these are ATM OAM, and ip ping tests, with the ANCP OAM "use-case" being an extension there of. It appears to be quite laborious, and often problematic due to the crossing of organizational boundaries, to have the procedure performed at the access-node. Troubleshooting of multicast delivery is as yet a bit of a black art to many providers that are only begging to deploy access-nodes capable of L2 multicast replication. It would thus appear to be desirable, in order to aid operations in such deployments, to introduce into ANCP a set of multicast reporting commands, that would allow a BNG operator to gain knowledge of the per circuit-id multicast replication state on the access-node. This would be a simple query/response mechanism, communicating from the access-node to the BNG the currently active multicast groups on a given target (circuit-id) along with applicable counters (eg time/byte count). =20 3. Change of L2 forwarding The current notions of multicast replication on a L2 element are limited to the following two options: flood all multicast with IGMP snooping disabled, or snoop IGMP and immediately replicate/stop-replicating multicast. It appears sensible to consider introducing a third notion that involves ANCP, and provides a more granular per multicast group control approach instead of the all or nothing options above. This would consist having a list of specific groups for which the access node would not flood the multicast traffic to a port, but neither would it do IGMP snooping, rather it would pass IGMP transparently and commence or stop replication when instructed via ANCP.=20 Various optimizations can be introduced to this scheme, but the principle remains the same; the L2 multicast replication mechanism, for a given group or range, would be driven by ANCP signalling. Depending on the deployment scenario, this would appear to be a good tool to utilize when multicast authorization, accounting, or asynchronous operator requests affecting multicast forwarding are desired. Regards, Woj. -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: 06 March 2007 14:49 To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Mar 12 15:41:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQqOQ-0006jy-V9; Mon, 12 Mar 2007 15:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQqOO-0006jq-Ns for ancp@ietf.org; Mon, 12 Mar 2007 15:41:12 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQqOM-0007E8-4E for ancp@ietf.org; Mon, 12 Mar 2007 15:41:12 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 12 Mar 2007 12:41:09 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="689442288:sNHT41427564" 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 in ANCP Date: Mon, 12 Mar 2007 15:41:04 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B75FF2@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgABZ9bNA= From: "Sanjay Wadhwa" To: "Wojciech Dec \(wdec\)" , , X-Spam-Score: 2.3 (++) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 I would like to extend my support for all the three use cases. #1 and #3 have also been discussed and debated in DSL forum. One comment on #3 is that we shouldn't define this case to preclude snooping on the access-node, even when creation of replication state is being controlled by NAS via ANCP. There could be varying degress of control exercised by the NAS in manipulating the replication state on the access-node.=20 -Sanjay =20 >-----Original Message----- >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >Sent: Monday, March 12, 2007 11:14 AM >To: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org >Subject: RE: [ANCP] Multicast in ANCP > > >Hi All, > >(chair hat off) > >I propose that the ANCP multicast requirements should cover the >following 3 areas: > >1. Dynamic configuration >There appears to be a need to be able to control the multicast >replication at the access-node in accordance with per user or per >circuit-id policies known at the controller, and do so in a=20 >dynamic vs a >one time provisioned manner. Currently operators do so by statically >configuring an ingress IGMP filtering ACL on a given circuit-id, which >is not amenable to dynamic changes. By dynamic changes it's meant that >they are ones that are quickly executed in response to other system >events, eg a subscriber session coming up/down, the expiration of a >quota or timer, or a policy trigger, or even operator command.=20 >ANCP would need to be able to install such ACLs through an efficient >transaction mechanism. Two forms of installation appear to be=20 >worthwhile >of consideration:=20 >i) overwrite - a complete ACL is applied in a transaction on a target >circuit-id >ii) add/remove - one or more entries are added/removed in a transaction >on a target circuit-id. > >2. Reporting >Several service providers currently run operational procedures=20 >that rely >on an operator being able to issue/troubleshoot a subscriber's problems >from a BNG. Classic examples of these are ATM OAM, and ip ping tests, >with the ANCP OAM "use-case" being an extension there of. It appears to >be quite laborious, and often problematic due to the crossing of >organizational boundaries, to have the procedure performed at the >access-node. Troubleshooting of multicast delivery is as yet a bit of a >black art to many providers that are only begging to deploy=20 >access-nodes >capable of L2 multicast replication. >It would thus appear to be desirable, in order to aid=20 >operations in such >deployments, to introduce into ANCP a set of multicast reporting >commands, that would allow a BNG operator to gain knowledge of the per >circuit-id multicast replication state on the access-node.=20 >This would be >a simple query/response mechanism, communicating from the=20 >access-node to >the BNG the currently active multicast groups on a given target >(circuit-id) along with applicable counters (eg time/byte count). >=20 >3. Change of L2 forwarding >The current notions of multicast replication on a L2 element=20 >are limited >to the following two options: flood all multicast with IGMP snooping >disabled, or snoop IGMP and immediately replicate/stop-replicating >multicast. >It appears sensible to consider introducing a third notion=20 >that involves >ANCP, and provides a more granular per multicast group control approach >instead of the all or nothing options above. This would=20 >consist having a >list of specific groups for which the access node would not flood the >multicast traffic to a port, but neither would it do IGMP snooping, >rather it would pass IGMP transparently and commence or stop=20 >replication >when instructed via ANCP.=20 >Various optimizations can be introduced to this scheme, but the >principle remains the same; the L2 multicast replication mechanism, for >a given group or range, would be driven by ANCP signalling. >Depending on the deployment scenario, this would appear to be a good >tool to utilize when multicast authorization, accounting, or >asynchronous operator requests affecting multicast forwarding are >desired. > >Regards, >Woj. > > >-----Original Message----- >From: Matthew.Bocci@alcatel-lucent.co.uk >[mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 >Sent: 06 March 2007 14:49 >To: ancp@ietf.org >Subject: [ANCP] Multicast in ANCP > >I would like to start a discussion on what the working group would like >to do with Multicast in ANCP. > >Currently the ANCP charter includes multicast as one of the use cases, >as >follows: > >"When multicast replication for subscriber-bound traffic is=20 >performed at >the AN, it off-loads the network between the AN and NAS. However, a >subscriber's policy and configuration for multicast traffic may only be >known at the NAS. ANCP will provide a mechanism to communicate the >necessary information exchange between the AN and NAS so as to=20 >allow the >AN to perform subscriber bound multicast group replication in line with >the subscriber's policy and configuration, and also allow the NAS to >follow each subscriber's multicast group membership." > >The framework draft (draft-ietf-ancp-framework-01.txt) says that the >access loop configuration mechanisms may be useful for setting the >per-Subscriber multicast channel entitlement information, used for IPTV >applications where the Access Node is performing IGMP snooping or IGMP >proxy function. It goes on to say that a Subscriber's policy and >configuration for multicast traffic might only be known at the NAS. The >Access Node Control Mechanism could be used to exchange the necessary >information between the Access Node and the NAS so as to allow the >Access Node to perform multicast replication in line with the >Subscriber's policy and configuration, and also allow the NAS to follow >each Subscriber's multicast group membership. > > >None of these multicast mechanisms are defined in the ANCP protocol >draft, and I think there is insufficient detail in the framework draft >to fully specify this use case. > >There has been very little work on this since the charter discussions, >but the ANCP working group needs to clarify what it wants to do (if >anything) with multicast for the framework can move forward. I think >there are two >choices: Either we should clarify the use case and specify the ANCP >protocol to support it, or we should remove the multicast use case from >the framework for now. > >Please post your opinions to the list. We plan to have a discussion on >this in Prague, and to try to reach a consensus at around that time. > >Best regards, > >Matthew > > > > > > > > > > >_______________________________________________ >ANCP mailing list >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 Tue Mar 13 05:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR3Dd-00049s-VU; Tue, 13 Mar 2007 05:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR3Dd-00049k-4F for ancp@ietf.org; Tue, 13 Mar 2007 05:22:57 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR3Da-0005cz-HI for ancp@ietf.org; Tue, 13 Mar 2007 05:22:57 -0400 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2D9N08Z016672 for ; Tue, 13 Mar 2007 10:23:00 +0100 Received: from [172.17.240.23] ([172.17.240.23]) by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031310225258:4586 ; Tue, 13 Mar 2007 10:22:52 +0100 Message-ID: <45F66D6F.80103@alcatel-lucent.be> Date: Tue, 13 Mar 2007 10:22:55 +0100 From: Sven.Ooghe@alcatel-lucent.be Organization: Alcatel-Lucent User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Multicast in ANCP References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/13/2007 10:22:52, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/13/2007 10:22:53, Serialize complete at 03/13/2007 10:22:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Currently the use of IGMP filtering mechanisms based on Access Control Lists are quite common. They allow control over the multicast replication process; the ACLs are provisioned via network management. It could be desirable to extend this concept to allow for ACL installation/removal upon establishing or terminating a PPP/DHCP session. That would require a mechanism to bring down the ACLs from a RADIUS or DHCP server to the points of IGMP processing and multicast replication. When a NAS receives the ACLs via RADIUS or DHCP, ANCP could then be used for bringing the ACLs from the NAS to the Access Node. I propose to scope the ANCP framework multicast requirements to cover the following: - supporting on the Access Node an ACL indicating for a particular access port which multicast groups/streams are allowed resp. not allowed to be sent to that port; - using ANCP for configuring these ACLs on the Access Node at PPP/DHCP session start/stop. The ACLs could be sent in RADIUS / DHCP / ANCP explicitly via new ACL attributes/options or implicitly using a pointer to a preprovisioned ACL profile on the Access Node (details to be discussed further on the list). This lines up with the first area mentioned in Woj's email, i.e. "dynamic configuration". I am supportive of this. In terms of using ANCP for multicast reporting, I would rather make use of the IGMP Query mechanism to determine replication state throughout the network. I am not in favor of using ANCP for configuration of the layer 2 replication state (be it for some or for all channels) in the access/aggregation network and disabling IGMP processing throughout the network for these channels. Regards, Sven Matthew.Bocci@alcatel-lucent.co.uk wrote: > I would like to start a discussion on what the working group would like to > do with Multicast in ANCP. > > Currently the ANCP charter includes multicast as one of the use cases, as > follows: > > "When multicast replication for subscriber-bound traffic is performed at > the AN, it off-loads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow the AN > to perform subscriber bound multicast group replication in line with the > subscriber's policy and configuration, and also allow the NAS to follow > each subscriber's multicast group membership." > > The framework draft (draft-ietf-ancp-framework-01.txt) says that the access > loop configuration mechanisms may be useful for setting the per-Subscriber > multicast channel entitlement information, used for IPTV applications where > the Access Node is performing IGMP snooping or IGMP proxy function. It goes > on to say that a Subscriber's policy and configuration for multicast > traffic might only be known at the NAS. The Access Node Control Mechanism > could be used to exchange the necessary information between the Access Node > and the NAS so as to allow the Access Node to perform multicast replication > in line with the Subscriber's policy and configuration, and also allow the > NAS to follow each Subscriber's multicast group membership. > > > None of these multicast mechanisms are defined in the ANCP protocol draft, > and I think there is insufficient detail in the framework draft to fully > specify this use case. > > There has been very little work on this since the charter discussions, but > the ANCP working group needs to clarify what it wants to do (if anything) > with multicast for the framework can move forward. I think there are two > choices: Either we should clarify the use case and specify the ANCP > protocol to support it, or we should remove the multicast use case from the > framework for now. > > Please post your opinions to the list. We plan to have a discussion on this > in Prague, and to try to reach a consensus at around that time. > > Best regards, > > Matthew > > > > > > > > > > > _______________________________________________ > ANCP mailing list > 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 Mar 13 06:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR3wN-0001lq-8E; Tue, 13 Mar 2007 06:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR3wL-0001h4-Ru for ancp@ietf.org; Tue, 13 Mar 2007 06:09:09 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR3wK-0001ku-Bh for ancp@ietf.org; Tue, 13 Mar 2007 06:09:09 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 13 Mar 2007 03:09:04 -0700 X-IronPort-AV: i="4.14,279,1170662400"; d="scan'208"; a="669750110:sNHT8971351074" Received: from emailbng1.jnpr.net ([10.209.194.15]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 03:09:04 -0700 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 in ANCP Date: Tue, 13 Mar 2007 15:38:56 +0530 Message-ID: <65F7C33180AA234285CE48530D32901803143FBA@emailbng1.jnpr.net> In-Reply-To: <45F66D6F.80103@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: AcdlUUR6058d1QPlQROT67WHgjlAegABAJNg From: "Ashwin Shimoga" To: , X-OriginalArrivalTime: 13 Mar 2007 10:09:04.0398 (UTC) FILETIME=[A12CDAE0:01C76557] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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, I have some general questions regarding ANCP framework for multicast requirements. 1. Will the draft specify to what extent ACL will be supported in Access Node? Or is it implementation dependent?=20 2. Bringing ACLs downto Access Node involves keeping the whole path of RADIUS->PPP/DHCP->ANCP on NAS->AN in sync. Will this increase the number of message exchanges between different network elements or is there an easier way to do this? 3. When a new user comes up can the Access node query NAS and pull ACL related information?=20 For Reporting purposes a simple request/reply mechanism from NAS to AN based on circuit-id should do the job. A set of reporting commands is not needed. The message format can be extended to contain TLV's for all the reporting parameters. The changes proposed by Wojciech for changes in L2 forwarding are more suitable for IPTV requirements. They provide more granularity at AN level to control multicast replication. Thanks Ashwin -----Original Message----- From: Sven.Ooghe@alcatel-lucent.be [mailto:Sven.Ooghe@alcatel-lucent.be] Sent: Tuesday, March 13, 2007 2:53 PM To: ancp@ietf.org Subject: Re: [ANCP] Multicast in ANCP Currently the use of IGMP filtering mechanisms based on Access Control=20 Lists are quite common. They allow control over the multicast=20 replication process; the ACLs are provisioned via network management. It could be desirable to extend this concept to allow for ACL=20 installation/removal upon establishing or terminating a PPP/DHCP=20 session. That would require a mechanism to bring down the ACLs from a=20 RADIUS or DHCP server to the points of IGMP processing and multicast=20 replication. When a NAS receives the ACLs via RADIUS or DHCP, ANCP could then be used for bringing the ACLs from the NAS to the Access Node. I propose to scope the ANCP framework multicast requirements to cover=20 the following: - supporting on the Access Node an ACL indicating for a particular access port which multicast groups/streams are allowed resp. not allowed to be sent to that port; - using ANCP for configuring these ACLs on the Access Node at PPP/DHCP=20 session start/stop. The ACLs could be sent in RADIUS / DHCP / ANCP=20 explicitly via new ACL attributes/options or implicitly using a pointer=20 to a preprovisioned ACL profile on the Access Node (details to be=20 discussed further on the list). This lines up with the first area mentioned in Woj's email, i.e.=20 "dynamic configuration". I am supportive of this. In terms of using ANCP for multicast reporting, I would rather make use=20 of the IGMP Query mechanism to determine replication state throughout=20 the network. I am not in favor of using ANCP for configuration of the layer 2=20 replication state (be it for some or for all channels) in the=20 access/aggregation network and disabling IGMP processing throughout the=20 network for these channels. Regards, Sven Matthew.Bocci@alcatel-lucent.co.uk wrote: > I would like to start a discussion on what the working group would like to > do with Multicast in ANCP. >=20 > Currently the ANCP charter includes multicast as one of the use cases, as > follows: >=20 > "When multicast replication for subscriber-bound traffic is performed at > the AN, it off-loads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow the AN > to perform subscriber bound multicast group replication in line with the > subscriber's policy and configuration, and also allow the NAS to follow > each subscriber's multicast group membership." >=20 > The framework draft (draft-ietf-ancp-framework-01.txt) says that the access > loop configuration mechanisms may be useful for setting the per-Subscriber > multicast channel entitlement information, used for IPTV applications where > the Access Node is performing IGMP snooping or IGMP proxy function. It goes > on to say that a Subscriber's policy and configuration for multicast > traffic might only be known at the NAS. The Access Node Control Mechanism > could be used to exchange the necessary information between the Access Node > and the NAS so as to allow the Access Node to perform multicast replication > in line with the Subscriber's policy and configuration, and also allow the > NAS to follow each Subscriber's multicast group membership. >=20 >=20 > None of these multicast mechanisms are defined in the ANCP protocol draft, > and I think there is insufficient detail in the framework draft to fully > specify this use case. >=20 > There has been very little work on this since the charter discussions, but > the ANCP working group needs to clarify what it wants to do (if anything) > with multicast for the framework can move forward. I think there are two > choices: Either we should clarify the use case and specify the ANCP > protocol to support it, or we should remove the multicast use case from the > framework for now. >=20 > Please post your opinions to the list. We plan to have a discussion on this > in Prague, and to try to reach a consensus at around that time. >=20 > Best regards, >=20 > Matthew >=20 >=20 >=20 >=20 >=20 >=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Mar 13 10:45:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8G2-0008UT-Lm; Tue, 13 Mar 2007 10:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8G1-0008UO-WF for ancp@ietf.org; Tue, 13 Mar 2007 10:45:46 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Fz-00036n-Gf for ancp@ietf.org; Tue, 13 Mar 2007 10:45:45 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id E363F205E3 for ; Tue, 13 Mar 2007 19:38:19 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id CD0C0205D9 for ; Tue, 13 Mar 2007 19:38:19 +0530 (IST) Received: from BLR-EC-MBX03.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 20:15:42 +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 Subject: RE: [ANCP] Multicast in ANCP Date: Tue, 13 Mar 2007 20:15:41 +0530 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B75FF2@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgABZ9bNAAIOi2QA== From: To: , , , X-OriginalArrivalTime: 13 Mar 2007 14:45:42.0126 (UTC) FILETIME=[463128E0:01C7657E] X-Spam-Score: 2.4 (++) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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 Hello all, The proposed use cases look fine, some comments: Use case 1 - dynamic configuration can include not only ACL installation, but also pushing QoS policy configuration for a channel and channel admission control bandwidth configuration to the access node. Use case 2 - Reporting can be extended to include the following: i. With IGMP proxy on the access node, subscriber information can be communicated to BNG. Along with the time/counter information this can be used for accounting per subscriber that is not visible to BNG otherwise ii. It can be used to synchronize multicast parameters between the access node and BNG. Any change in access node multicast parameter configuration through a local management system can be reported to BNG. Use case 3 - L2 forwarding changes It looks like this is within the scope of use case 1. Perhaps, a dynamic policy update and configuration is what is required. A general comment: It needs to be seen if there is a need to control the point of content injection for subscribers dynamically through ANCP, either to force or to fallback on. Thanks, Kirubaharan -----Original Message----- From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: Tuesday, March 13, 2007 1:11 AM To: Wojciech Dec (wdec); Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org Subject: RE: [ANCP] Multicast in ANCP I would like to extend my support for all the three use cases. #1 and #3 have also been discussed and debated in DSL forum. One comment on #3 is that we shouldn't define this case to preclude snooping on the access-node, even when creation of replication state is being controlled by NAS via ANCP. There could be varying degress of control exercised by the NAS in manipulating the replication state on the access-node.=20 -Sanjay =20 >-----Original Message----- >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >Sent: Monday, March 12, 2007 11:14 AM >To: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org >Subject: RE: [ANCP] Multicast in ANCP > > >Hi All, > >(chair hat off) > >I propose that the ANCP multicast requirements should cover the >following 3 areas: > >1. Dynamic configuration >There appears to be a need to be able to control the multicast >replication at the access-node in accordance with per user or per >circuit-id policies known at the controller, and do so in a=20 >dynamic vs a >one time provisioned manner. Currently operators do so by statically >configuring an ingress IGMP filtering ACL on a given circuit-id, which >is not amenable to dynamic changes. By dynamic changes it's meant that >they are ones that are quickly executed in response to other system >events, eg a subscriber session coming up/down, the expiration of a >quota or timer, or a policy trigger, or even operator command.=20 >ANCP would need to be able to install such ACLs through an efficient >transaction mechanism. Two forms of installation appear to be=20 >worthwhile >of consideration:=20 >i) overwrite - a complete ACL is applied in a transaction on a target >circuit-id >ii) add/remove - one or more entries are added/removed in a transaction >on a target circuit-id. > >2. Reporting >Several service providers currently run operational procedures=20 >that rely >on an operator being able to issue/troubleshoot a subscriber's problems >from a BNG. Classic examples of these are ATM OAM, and ip ping tests, >with the ANCP OAM "use-case" being an extension there of. It appears to >be quite laborious, and often problematic due to the crossing of >organizational boundaries, to have the procedure performed at the >access-node. Troubleshooting of multicast delivery is as yet a bit of a >black art to many providers that are only begging to deploy=20 >access-nodes >capable of L2 multicast replication. >It would thus appear to be desirable, in order to aid=20 >operations in such >deployments, to introduce into ANCP a set of multicast reporting >commands, that would allow a BNG operator to gain knowledge of the per >circuit-id multicast replication state on the access-node.=20 >This would be >a simple query/response mechanism, communicating from the=20 >access-node to >the BNG the currently active multicast groups on a given target >(circuit-id) along with applicable counters (eg time/byte count). >=20 >3. Change of L2 forwarding >The current notions of multicast replication on a L2 element=20 >are limited >to the following two options: flood all multicast with IGMP snooping >disabled, or snoop IGMP and immediately replicate/stop-replicating >multicast. >It appears sensible to consider introducing a third notion=20 >that involves >ANCP, and provides a more granular per multicast group control approach >instead of the all or nothing options above. This would=20 >consist having a >list of specific groups for which the access node would not flood the >multicast traffic to a port, but neither would it do IGMP snooping, >rather it would pass IGMP transparently and commence or stop=20 >replication >when instructed via ANCP.=20 >Various optimizations can be introduced to this scheme, but the >principle remains the same; the L2 multicast replication mechanism, for >a given group or range, would be driven by ANCP signalling. >Depending on the deployment scenario, this would appear to be a good >tool to utilize when multicast authorization, accounting, or >asynchronous operator requests affecting multicast forwarding are >desired. > >Regards, >Woj. > > >-----Original Message----- >From: Matthew.Bocci@alcatel-lucent.co.uk >[mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 >Sent: 06 March 2007 14:49 >To: ancp@ietf.org >Subject: [ANCP] Multicast in ANCP > >I would like to start a discussion on what the working group would like >to do with Multicast in ANCP. > >Currently the ANCP charter includes multicast as one of the use cases, >as >follows: > >"When multicast replication for subscriber-bound traffic is=20 >performed at >the AN, it off-loads the network between the AN and NAS. However, a >subscriber's policy and configuration for multicast traffic may only be >known at the NAS. ANCP will provide a mechanism to communicate the >necessary information exchange between the AN and NAS so as to=20 >allow the >AN to perform subscriber bound multicast group replication in line with >the subscriber's policy and configuration, and also allow the NAS to >follow each subscriber's multicast group membership." > >The framework draft (draft-ietf-ancp-framework-01.txt) says that the >access loop configuration mechanisms may be useful for setting the >per-Subscriber multicast channel entitlement information, used for IPTV >applications where the Access Node is performing IGMP snooping or IGMP >proxy function. It goes on to say that a Subscriber's policy and >configuration for multicast traffic might only be known at the NAS. The >Access Node Control Mechanism could be used to exchange the necessary >information between the Access Node and the NAS so as to allow the >Access Node to perform multicast replication in line with the >Subscriber's policy and configuration, and also allow the NAS to follow >each Subscriber's multicast group membership. > > >None of these multicast mechanisms are defined in the ANCP protocol >draft, and I think there is insufficient detail in the framework draft >to fully specify this use case. > >There has been very little work on this since the charter discussions, >but the ANCP working group needs to clarify what it wants to do (if >anything) with multicast for the framework can move forward. I think >there are two >choices: Either we should clarify the use case and specify the ANCP >protocol to support it, or we should remove the multicast use case from >the framework for now. > >Please post your opinions to the list. We plan to have a discussion on >this in Prague, and to try to reach a consensus at around that time. > >Best regards, > >Matthew > > > > > > > > > > >_______________________________________________ >ANCP mailing list >ANCP@ietf.org >https://www1.ietf.org/mailman/listinfo/ancp > >_______________________________________________ >ANCP mailing list >ANCP@ietf.org >https://www1.ietf.org/mailman/listinfo/ancp > [Ignore any disclaimer auto inserted] _______________________________________________ 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 Mar 13 11:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9GI-0005IA-2g; Tue, 13 Mar 2007 11:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9GG-0005Ga-9N for ancp@ietf.org; Tue, 13 Mar 2007 11:50:04 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9GD-0000x8-5O for ancp@ietf.org; Tue, 13 Mar 2007 11:50:04 -0400 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 16:50:00 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.227]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 16:49:59 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Multicast in ANCP Date: Tue, 13 Mar 2007 16:49:59 +0100 Message-ID: <9E577E61D0108D4F8CD482029B613F5C0181BA08@PTPEVS108BA020.idc.cww.telecomitalia.it> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP thread-index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgABZ9bNAAIOi2QAAHiF7A References: <9BD5D7887235424FA97DFC223CAE3C2803B75FF2@proton.jnpr.net> From: "Maglione Roberta" To: , , , , X-OriginalArrivalTime: 13 Mar 2007 15:49:59.0700 (UTC) FILETIME=[417C3D40:01C76587] X-Spam-Score: 2.3 (++) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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 All, I would like to support all three use cases proposed, because they cover the=20 main topics we are interesting in: - the flexibility given by the capability to dynamically modify configuration parameters based on external events such as session coming up/down, the expiration of a quota or timer, or a policy trigger, or even operator command; - the service granularity related to the possibility to allow or deny per user multicast replication; - the possibility to perform multicast authorization and time/volume based accounting. Thanks, Roberta =20 -------------------------------------------------------------------- Roberta Maglione Telecom Italia - T.IE.AFT.BI Broadband Network Services Innovation Via G. Reiss Romoli 274 10148 Torino - Italy Phone: +39 011 228 5007 e-mail: roberta.maglione@telecomitalia.it ------------------------------------------------------------------- -----Original Message----- From: kirubaharan.dorairaj@wipro.com [mailto:kirubaharan.dorairaj@wipro.com]=20 Sent: Tuesday, March 13, 2007 3:46 PM To: swadhwa@juniper.net; wdec@cisco.com; Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org Subject: RE: [ANCP] Multicast in ANCP Hello all, The proposed use cases look fine, some comments: Use case 1 - dynamic configuration can include not only ACL installation, but also pushing QoS policy configuration for a channel and channel admission control bandwidth configuration to the access node. Use case 2 - Reporting can be extended to include the following: i. With IGMP proxy on the access node, subscriber information can be communicated to BNG. Along with the time/counter information this can be used for accounting per subscriber that is not visible to BNG otherwise ii. It can be used to synchronize multicast parameters between the access node and BNG. Any change in access node multicast parameter configuration through a local management system can be reported to BNG. Use case 3 - L2 forwarding changes It looks like this is within the scope of use case 1. Perhaps, a dynamic policy update and configuration is what is required. A general comment: It needs to be seen if there is a need to control the point of content injection for subscribers dynamically through ANCP, either to force or to fallback on. Thanks, Kirubaharan -----Original Message----- From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: Tuesday, March 13, 2007 1:11 AM To: Wojciech Dec (wdec); Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org Subject: RE: [ANCP] Multicast in ANCP I would like to extend my support for all the three use cases. #1 and #3 have also been discussed and debated in DSL forum. One comment on #3 is that we shouldn't define this case to preclude snooping on the access-node, even when creation of replication state is being controlled by NAS via ANCP. There could be varying degress of control exercised by the NAS in manipulating the replication state on the access-node.=20 -Sanjay =20 >-----Original Message----- >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >Sent: Monday, March 12, 2007 11:14 AM >To: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org >Subject: RE: [ANCP] Multicast in ANCP > > >Hi All, > >(chair hat off) > >I propose that the ANCP multicast requirements should cover the >following 3 areas: > >1. Dynamic configuration >There appears to be a need to be able to control the multicast >replication at the access-node in accordance with per user or per >circuit-id policies known at the controller, and do so in a=20 >dynamic vs a >one time provisioned manner. Currently operators do so by statically >configuring an ingress IGMP filtering ACL on a given circuit-id, which >is not amenable to dynamic changes. By dynamic changes it's meant that >they are ones that are quickly executed in response to other system >events, eg a subscriber session coming up/down, the expiration of a >quota or timer, or a policy trigger, or even operator command.=20 >ANCP would need to be able to install such ACLs through an efficient >transaction mechanism. Two forms of installation appear to be=20 >worthwhile >of consideration:=20 >i) overwrite - a complete ACL is applied in a transaction on a target >circuit-id >ii) add/remove - one or more entries are added/removed in a transaction >on a target circuit-id. > >2. Reporting >Several service providers currently run operational procedures=20 >that rely >on an operator being able to issue/troubleshoot a subscriber's problems >from a BNG. Classic examples of these are ATM OAM, and ip ping tests, >with the ANCP OAM "use-case" being an extension there of. It appears to >be quite laborious, and often problematic due to the crossing of >organizational boundaries, to have the procedure performed at the >access-node. Troubleshooting of multicast delivery is as yet a bit of a >black art to many providers that are only begging to deploy=20 >access-nodes >capable of L2 multicast replication. >It would thus appear to be desirable, in order to aid=20 >operations in such >deployments, to introduce into ANCP a set of multicast reporting >commands, that would allow a BNG operator to gain knowledge of the per >circuit-id multicast replication state on the access-node.=20 >This would be >a simple query/response mechanism, communicating from the=20 >access-node to >the BNG the currently active multicast groups on a given target >(circuit-id) along with applicable counters (eg time/byte count). >=20 >3. Change of L2 forwarding >The current notions of multicast replication on a L2 element=20 >are limited >to the following two options: flood all multicast with IGMP snooping >disabled, or snoop IGMP and immediately replicate/stop-replicating >multicast. >It appears sensible to consider introducing a third notion=20 >that involves >ANCP, and provides a more granular per multicast group control approach >instead of the all or nothing options above. This would=20 >consist having a >list of specific groups for which the access node would not flood the >multicast traffic to a port, but neither would it do IGMP snooping, >rather it would pass IGMP transparently and commence or stop=20 >replication >when instructed via ANCP.=20 >Various optimizations can be introduced to this scheme, but the >principle remains the same; the L2 multicast replication mechanism, for >a given group or range, would be driven by ANCP signalling. >Depending on the deployment scenario, this would appear to be a good >tool to utilize when multicast authorization, accounting, or >asynchronous operator requests affecting multicast forwarding are >desired. > >Regards, >Woj. > > >-----Original Message----- >From: Matthew.Bocci@alcatel-lucent.co.uk >[mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 >Sent: 06 March 2007 14:49 >To: ancp@ietf.org >Subject: [ANCP] Multicast in ANCP > >I would like to start a discussion on what the working group would like >to do with Multicast in ANCP. > >Currently the ANCP charter includes multicast as one of the use cases, >as >follows: > >"When multicast replication for subscriber-bound traffic is=20 >performed at >the AN, it off-loads the network between the AN and NAS. However, a >subscriber's policy and configuration for multicast traffic may only be >known at the NAS. ANCP will provide a mechanism to communicate the >necessary information exchange between the AN and NAS so as to=20 >allow the >AN to perform subscriber bound multicast group replication in line with >the subscriber's policy and configuration, and also allow the NAS to >follow each subscriber's multicast group membership." > >The framework draft (draft-ietf-ancp-framework-01.txt) says that the >access loop configuration mechanisms may be useful for setting the >per-Subscriber multicast channel entitlement information, used for IPTV >applications where the Access Node is performing IGMP snooping or IGMP >proxy function. It goes on to say that a Subscriber's policy and >configuration for multicast traffic might only be known at the NAS. The >Access Node Control Mechanism could be used to exchange the necessary >information between the Access Node and the NAS so as to allow the >Access Node to perform multicast replication in line with the >Subscriber's policy and configuration, and also allow the NAS to follow >each Subscriber's multicast group membership. > > >None of these multicast mechanisms are defined in the ANCP protocol >draft, and I think there is insufficient detail in the framework draft >to fully specify this use case. > >There has been very little work on this since the charter discussions, >but the ANCP working group needs to clarify what it wants to do (if >anything) with multicast for the framework can move forward. I think >there are two >choices: Either we should clarify the use case and specify the ANCP >protocol to support it, or we should remove the multicast use case from >the framework for now. > >Please post your opinions to the list. We plan to have a discussion on >this in Prague, and to try to reach a consensus at around that time. > >Best regards, > >Matthew > > > > > > > > > > >_______________________________________________ >ANCP mailing list >ANCP@ietf.org >https://www1.ietf.org/mailman/listinfo/ancp > >_______________________________________________ >ANCP mailing list >ANCP@ietf.org >https://www1.ietf.org/mailman/listinfo/ancp > [Ignore any disclaimer auto inserted] _______________________________________________ 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 -------------------------------------------------------------------- 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 Wed Mar 14 04:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HROxO-0000X2-Ui; Wed, 14 Mar 2007 04:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HROxN-0000Wt-Bc for ancp@ietf.org; Wed, 14 Mar 2007 04:35:37 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HROxL-0002Cc-8Y for ancp@ietf.org; Wed, 14 Mar 2007 04:35:37 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2E8ZfL2021871 for ; Wed, 14 Mar 2007 09:35:41 +0100 Received: from [172.31.131.185] ([172.31.131.185]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031409353319:1602 ; Wed, 14 Mar 2007 09:35:33 +0100 Message-ID: <45F7B3CD.5070806@alcatel-lucent.be> Date: Wed, 14 Mar 2007 09:35:25 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ancp@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/14/2007 09:35:33, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/14/2007 09:35:33, Serialize complete at 03/14/2007 09:35:33 Content-Type: multipart/mixed; boundary="------------030300080903030703080801" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9d62a9227719824a4e99fed679d6685e Subject: [ANCP] ANCP MIB 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 This is a multi-part message in MIME format. --------------030300080903030703080801 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Hi, The updated ANCP MIB was submitted to the IETF in time but for some reason it never appeared on i-d-annound. Therefore I sent the updated draft as attachement to this mailing list. Comments are very welcome. regards, Stefaan --------------030300080903030703080801 Content-Transfer-Encoding: 7bit Content-Type: text/plain; name="draft-decnodder-ancp-mib-an-01.txt" Content-Disposition: inline; filename="draft-decnodder-ancp-mib-an-01.txt" Network Working Group S. De Cnodder Internet-Draft Alcatel-Lucent Intended status: Standards Track M. Morgenstern Expires: August 30, 2007 ECI Telecom Ltd. February 26, 2007 Access Node Control Protocol (ANCP) MIB module for Access Nodes draft-decnodder-ancp-mib-an-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes as described in [ANCPFW] that are using the Access Node Control Protocol (ANCP) defined in [ANCPPR]. De Cnodder & Morgenstern Expires August 30, 2007 [Page 1] Internet-Draft ANCP MIB February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 3 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 4 5.2. The ANCP Subtree for the Access Node . . . . . . . . . . . 5 5.3. The Notifications Subtree . . . . . . . . . . . . . . . . 5 5.4. Relationship to Other MIB Modules . . . . . . . . . . . . 5 6. ANCP MIB Definitions for the Access Node . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 De Cnodder & Morgenstern Expires August 30, 2007 [Page 2] Internet-Draft ANCP MIB February 2007 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes as described in [ANCPFW] that are using the Access Node Control Protocol defined in [ANCPPR]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Overview In [ANCPFW], the framework for the Access Node Control Protocol (ANCP) is described. It defines 2 network entities, the Access Node (AN) and the Network Access Server (NAS), between which ANCP sessions are established. The detailed protocol specification of ANCP is described in [ANCPPR]. This document specifies a MIB module for an AN that supports ANCP. Note: the current MIB definition is specific for [ANCPPR]. If [ANCPPR] gets updated later, then the MIB definition in this document will also follow these changes. 5. Structure of the MIB Module The ANCP MIB module for the AN has 3 parts. A first table, De Cnodder & Morgenstern Expires August 30, 2007 [Page 3] Internet-Draft ANCP MIB February 2007 ancpAnSessionConfigTable, is used to configure ANCP sessions at the AN towards a specific NAS. The NAS is identified by a number of attributes in this table (ancpAnSessionConfigNasIpAddressType and ancpAnSessionConfigNasIpAddress). The other attributes in this table can be used to configure properties that are specific for that particular ANCP session. A second table, ancpAnCurrentSessionTable, shows the operational state of a particular ANCP session. Each session configured in ancpAnSessionConfigTable has a corresponding row in ancpAnCurrentSessionTable. When a session is configured or deleted in the ancpAnSessionConfigTable, then the corresponding row of that session in the ancpAnCurrentSessionTable is, respectively, automatically created or deleted. A third table is used to assign interfaces to particular partitions. A row in this table is created automatically when an interface is created in the ifTable of the IF- MIB [RFC2863] for which the system supports ANCP. Four groups are defined: o ancpAnConfigGroup This group contains all objects of the ancpAnSessionConfigTable in which the ANCP sessions are configured in the access node. o ancpAnCurrentGroup This group contains all objects of the ancpAnCurrentSessionTable where the operational state and other information of the ANCP sessions are shown. o ancpAnInterfaceGroup This group contains all objects to configure interfaces to be used by ANCP. Assigning interfaces to particular partitions is part of this group. o ancpAnNotificationsGroup This group contains the notifications that indicate state changes of ANCP sessions. 5.1. Textual Conventions Two new textual convention, GsmpSubVersion and AncpAnSessionCapabilities, are defined in this MIB module. The ANCP specification in [ANCPPR] is re-using the GSMP specification in [RFC3292] where the GSMP subversion is introduced. These textual convention complement the textual conventions defined in [RFC3295], De Cnodder & Morgenstern Expires August 30, 2007 [Page 4] Internet-Draft ANCP MIB February 2007 GsmpVersion, GsmpNameType, and GsmpPartitionIdType, which are also used in this MIB module. These textual conventions are used for the convenience of humans reading the MIB. 5.2. The ANCP Subtree for the Access Node TBD 5.3. The Notifications Subtree Notifications are defined to inform the management station about state changes of ANCP sessions, whenever an ANCP session changes state. Two notifications are defined for this purpose. The notification ancpSessionUp is to inform the management station when the session comes up, and the notification ancpSessionDown is to inform when the ANCP session is down again after it was up before. No special measures for congestion avoidance for the notifications are needed because the number of ANCP sessions in an access node is typically small. In addition, establishing an ANCP session and tearing down it again, takes some time such that for a particular ANCP session, not many notifications in a short time period can be generated. 5.4. Relationship to Other MIB Modules There is a dependency with the Interfaces Group MIB (IF-MIB) defined in [RFC2863]. The ifIndex defined in the ifTable of IF-MIB is used as the index of the ancpAnInterfaceConfigTable defined in the ANCP MIB module for access nodes. Each time that an entry is created in the ifTable for which the system supports ANCP (e.g., in a DSLAM this is typically for each DSL line), a row is created automatically in the ancpAnInterfaceConfigTable. 6. ANCP MIB Definitions for the Access Node ANCP-AN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2, TimeTicks, NOTIFICATION-TYPE FROM SNMPv2-SMI -- [RFC2578] ZeroBasedCounter32 FROM RMON2-MIB -- [RFC4502] ifIndex FROM IF-MIB -- [RFC2863] InetAddressType, InetAddress, InetPortNumber De Cnodder & Morgenstern Expires August 30, 2007 [Page 5] Internet-Draft ANCP MIB February 2007 FROM INET-ADDRESS-MIB -- [RFC4001] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] GsmpVersion, GsmpNameType, GsmpPartitionIdType FROM GSMP-MIB -- [RFC3295] RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ancpAnMIB MODULE-IDENTITY LAST-UPDATED "200702260000Z" -- 26 February 2007 ORGANIZATION "IETF ANCP Working Group" CONTACT-INFO " Editors: Stefaan De Cnodder Alcatel-Lucent Postal: Copernicuslaan 50 B-2018 Antwerp Belgium EMail: stefaan.de_cnodder@alcatel-lucent.be Phone: +32 3 240 85 15 Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 " DESCRIPTION "The MIB module for entities implementing the access node side of the Access Node Control Protocol (ANCP). Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC yyyy; for full legal notices see the RFC itself." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "200702260000Z" -- 26 February 2007 DESCRIPTION "Initial version as published in RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { mib-2 xxx } -- The value xxx to be assigned by IANA. ancpNotifications OBJECT IDENTIFIER ::= { ancpAnMIB 0 } ancpAnObjects OBJECT IDENTIFIER ::= { ancpAnMIB 1 } ancpAnConformance OBJECT IDENTIFIER ::= { ancpAnMIB 2 } De Cnodder & Morgenstern Expires August 30, 2007 [Page 6] Internet-Draft ANCP MIB February 2007 GsmpSubVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The subversion numbers defined for the GSMP protocol." SYNTAX Unsigned32 AncpAnSessionCapabilities ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ANCP capabilities supported by the AN. The following capabilities are available: topologyDiscovery (0)- Access Topology Discovery lineConfig (1) - Line Configuration multicast (2) - Multicast l2Oam (3) - Layer 2 OAM A bit set means the associated capability is supported." SYNTAX BITS { topologyDiscovery (0), lineConfig (1), multicast (2), l2Oam (3) } ancpAnNextSessionId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The object reports the next index (potential value of ancpAnSessionConfigSessionId) which is available for creating a new row in ancpAnSessionConfigTable. If no such value is available (e.g., the table is full or any other reason) the object reports '0' (zero). An available value V becomes unavailable when a row is actually created with ancpAnSessionConfigSessionId=V and until then consecutive GET commands with this object may return the same value V. Note that eventually only one row creation with the value V can succeed. An unavailable value V becomes available again when a row with ancpAnSessionConfigSessionId=V in ancpAnSessionConfigTable is deleted." ::= { ancpAnObjects 1 } ancpAnSessionConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF AncpAnSessionConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION De Cnodder & Morgenstern Expires August 30, 2007 [Page 7] Internet-Draft ANCP MIB February 2007 "This table represents the ANCP sessions in the access node. An entry in this table needs to be configured (created) before an ANCP session might be started." ::= { ancpAnObjects 2 } ancpAnSessionConfigEntry OBJECT-TYPE SYNTAX AncpAnSessionConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the data for a specific actual or yet to be established session. If partitions are used, one session corresponds to one specific access node partition." INDEX { ancpAnSessionConfigSessionId } ::= { ancpAnSessionConfigTable 1 } AncpAnSessionConfigEntry ::= SEQUENCE { ancpAnSessionConfigSessionId Unsigned32, ancpAnSessionConfigRowStatus RowStatus, ancpAnSessionConfigGsmpVersion GsmpVersion, ancpAnSessionConfigGsmpSubVersion GsmpSubVersion, ancpAnSessionConfigEncapsulationType INTEGER, ancpAnSessionConfigCapabilities AncpAnSessionCapabilities, ancpAnSessionConfigAliveTimer Unsigned32, ancpAnSessionConfigPortReportShaper Unsigned32, ancpAnSessionConfigAggregateReportShaper Unsigned32, ancpAnSessionConfigTransportRetryTimer Unsigned32, ancpAnSessionConfigGsmpRetryTimer Unsigned32, ancpAnSessionConfigAnName GsmpNameType, ancpAnSessionConfigPartitionId GsmpPartitionIdType, ancpAnSessionConfigWindowSize Unsigned32, ancpAnSessionConfigNasIpAddressType InetAddressType, ancpAnSessionConfigNasIpAddress InetAddress, ancpAnSessionConfigEncapPortNumber InetPortNumber } ancpAnSessionConfigSessionId OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A system generated index to distinguish between different sessions. Session may be actually established or just potential." ::= { ancpAnSessionConfigEntry 1 } ancpAnSessionConfigRowStatus OBJECT-TYPE De Cnodder & Morgenstern Expires August 30, 2007 [Page 8] Internet-Draft ANCP MIB February 2007 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { ancpAnSessionConfigEntry 2 } ancpAnSessionConfigGsmpVersion OBJECT-TYPE SYNTAX GsmpVersion MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum version number of the GSMP protocol that may be used in this session. The value of this object is persistent." DEFVAL { 3 } ::= { ancpAnSessionConfigEntry 3 } ancpAnSessionConfigGsmpSubVersion OBJECT-TYPE SYNTAX GsmpSubVersion MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum subversion number of the GSMP protocol that may be used in this session. The value of this object is persistent." DEFVAL { 1 } ::= { ancpAnSessionConfigEntry 4 } ancpAnSessionConfigEncapsulationType OBJECT-TYPE SYNTAX INTEGER { tcp(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Required encapsulation for this session. The value of this object is persistent." DEFVAL { tcp } ::= { ancpAnSessionConfigEntry 5 } ancpAnSessionConfigCapabilities OBJECT-TYPE SYNTAX AncpAnSessionCapabilities MAX-ACCESS read-create STATUS current DESCRIPTION "ANCP capabilities supported by the AN in this session. De Cnodder & Morgenstern Expires August 30, 2007 [Page 9] Internet-Draft ANCP MIB February 2007 When all bits are set to zero then this means that no capabilities are supported. The value of this object is persistent." DEFVAL { { topologyDiscovery, l2Oam } } ::= { ancpAnSessionConfigEntry 6 } ancpAnSessionConfigAliveTimer OBJECT-TYPE SYNTAX Unsigned32(1..255) UNITS "deciseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between periodic adjacency protocol messages generated by the access node. It is a constant for the duration of a GSMP session. The timer is specified in units of 100ms. The value of this object is persistent." DEFVAL { 100 } ::= { ancpAnSessionConfigEntry 7 } ancpAnSessionConfigPortReportShaper OBJECT-TYPE SYNTAX Unsigned32(1..255) UNITS "deciseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between 2 EventReport messages related to the same port. It is a constant for the duration of a GSMP session. The timer is specified in units of 100ms. The value of this object is persistent." DEFVAL { 10 } ::= { ancpAnSessionConfigEntry 8 } ancpAnSessionConfigAggregateReportShaper OBJECT-TYPE SYNTAX Unsigned32(1..2550) UNITS "centiseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between 2 EventReport messages related to any port. It is a constant for the duration of a GSMP session. The timer is specified in units of 10ms. The value of this object is persistent." DEFVAL { 10 } ::= { ancpAnSessionConfigEntry 9 } De Cnodder & Morgenstern Expires August 30, 2007 [Page 10] Internet-Draft ANCP MIB February 2007 ancpAnSessionConfigTransportRetryTimer OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "deciseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between 2 transport connection setup attempts done by the access node. The transport protocol is specified in ancpAnSessionConfigEncapsulationType. The timer is specified in units of 100ms. A value 0 means that the access node will NOT initiate nor setup the transport connection. The value of this object is persistent." DEFVAL { 10 } ::= { ancpAnSessionConfigEntry 10 } ancpAnSessionConfigGsmpRetryTimer OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "deciseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between 2 ANCP connection setup attempts. The timer is specified in units of 100ms. A value 0 means that the access node will NOT spontaneously trigger an ANCP session. Whatever the setting of this timer, the access node shall always listen for ANCP session setup. The value of this object is persistent." DEFVAL { 10 } ::= { ancpAnSessionConfigEntry 11 } ancpAnSessionConfigAnName OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the access node. The first three octets must be an Organizationally Unique Identifier (OUI) that identifies the manufacturer of the access node. This can be (one of) the MAC address(es) of the access node on the network side. It may not change during the ANCP session. When set to zero, the access node shall autonomously decide on using the most appropriate MAC address of the access node. Then the actually used access node name can De Cnodder & Morgenstern Expires August 30, 2007 [Page 11] Internet-Draft ANCP MIB February 2007 be read from ancpAnCurrentSessionAnName. The value of this object is persistent." DEFVAL { '000000000000'H } ::= { ancpAnSessionConfigEntry 12 } ancpAnSessionConfigPartitionId OBJECT-TYPE SYNTAX GsmpPartitionIdType MAX-ACCESS read-create STATUS current DESCRIPTION "The Id for this session's specific access node partition. The value of this object is persistent." DEFVAL { '00'H } ::= { ancpAnSessionConfigEntry 13 } ancpAnSessionConfigWindowSize OBJECT-TYPE SYNTAX Unsigned32(1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of unacknowledged request messages that may be transmitted by the controller without the possibility of loss. This field is used to prevent request messages from being lost in the access node because of overflow in the receive buffer. The field is a hint to the controller. The value of this object is persistent." DEFVAL { 10 } ::= { ancpAnSessionConfigEntry 14 } ancpAnSessionConfigNasIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of address in ancpAnSessionConfigNasIpAddress. The value of this object is persistent." ::= { ancpAnSessionConfigEntry 15 } ancpAnSessionConfigNasIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address used for the ANCP session peer (NAS). The value of this object is persistent." ::= { ancpAnSessionConfigEntry 16 } De Cnodder & Morgenstern Expires August 30, 2007 [Page 12] Internet-Draft ANCP MIB February 2007 ancpAnSessionConfigEncapPortNumber OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The port number used for the transport protocol establishment to the ANCP peer. The value of this object is persistent." DEFVAL { 6068 } ::= { ancpAnSessionConfigEntry 17 } ancpAnCurrentSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AncpAnCurrentSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table gives actual information of the sessions in the access node. A row in this table is created when the corresponding row in the ancpAnSessionConfigTable is activated. A row in this table is deleted when the corresponding row in the ancpAnSessionConfigTable is deleted." ::= { ancpAnObjects 3 } ancpAnCurrentSessionEntry OBJECT-TYPE SYNTAX AncpAnCurrentSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the data for a specific actual session." INDEX { ancpAnSessionConfigSessionId } ::= { ancpAnCurrentSessionTable 1 } AncpAnCurrentSessionEntry ::= SEQUENCE { ancpAnCurrentSessionState INTEGER, ancpAnCurrentSessionGsmpVersion GsmpVersion, ancpAnCurrentSessionGsmpSubVersion GsmpSubVersion, ancpAnCurrentSessionAnName GsmpNameType, ancpAnCurrentSessionNasName GsmpNameType, ancpAnCurrentSessionAnIpAddressType InetAddressType, ancpAnCurrentSessionAnIpAddress InetAddress, ancpAnCurrentSessionAnInstance Unsigned32, ancpAnCurrentSessionNasInstance Unsigned32, ancpAnCurrentSessionCapabilities AncpAnSessionCapabilities, ancpAnCurrentSessionStartUptime TimeTicks, ancpAnCurrentSessionDiscontinuityTime TimeTicks, ancpAnCurrentSessionStatSentMessages ZeroBasedCounter32, De Cnodder & Morgenstern Expires August 30, 2007 [Page 13] Internet-Draft ANCP MIB February 2007 ancpAnCurrentSessionStatReceivedValidMessages ZeroBasedCounter32, ancpAnCurrentSessionStatDiscardedMessages ZeroBasedCounter32 } ancpAnCurrentSessionState OBJECT-TYPE SYNTAX INTEGER { null(1), synsent(2), synrcvd(3), estab(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of this session. The null (1) state is returned if the proper encapsulation data is not yet configured, if the row is not in active status or if the session is in NULL state as defined in the GSMP specification." ::= { ancpAnCurrentSessionEntry 1 } ancpAnCurrentSessionGsmpVersion OBJECT-TYPE SYNTAX GsmpVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The actual version number of the GSMP protocol that is used in this session. This object has value 0 if ancpAnCurrentSessionState is not estab(4)." ::= { ancpAnCurrentSessionEntry 2 } ancpAnCurrentSessionGsmpSubVersion OBJECT-TYPE SYNTAX GsmpSubVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The actual subversion number of the GSMP protocol that may be used in this session. This object has value 0 if ancpAnCurrentSessionState is not estab(4)." ::= { ancpAnCurrentSessionEntry 3 } ancpAnCurrentSessionAnName OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS read-only STATUS current DESCRIPTION De Cnodder & Morgenstern Expires August 30, 2007 [Page 14] Internet-Draft ANCP MIB February 2007 "The name of the access node used in this session. It should be the same as ancpAnSessionConfigAnName. The value of this object is used as value for the 'Sender Name' field in the header of the ANCP messages generated for this session by the AN." ::= { ancpAnCurrentSessionEntry 4 } ancpAnCurrentSessionNasName OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the NAS as advertised in the adjacency message. The value of this object is set to the value of the 'Sender Name' field in the header of the ANCP messages received on this session. This object has value 0 if ancpAnCurrentSessionState is not estab(4)." ::= { ancpAnCurrentSessionEntry 5 } ancpAnCurrentSessionAnIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address in ancpAnCurrentSessionAnIpAddress." ::= { ancpAnCurrentSessionEntry 6 } ancpAnCurrentSessionAnIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address used for the access node." ::= { ancpAnCurrentSessionEntry 7 } ancpAnCurrentSessionAnInstance OBJECT-TYPE SYNTAX Unsigned32(0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The instance number used by the access node during this session. The Instance number is a 24-bit number that should be guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number. This object has value 0 if ancpAnCurrentSessionState is De Cnodder & Morgenstern Expires August 30, 2007 [Page 15] Internet-Draft ANCP MIB February 2007 not estab(4)." ::= { ancpAnCurrentSessionEntry 8 } ancpAnCurrentSessionNasInstance OBJECT-TYPE SYNTAX Unsigned32(0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The instance number used by the NAS during this session. The Instance number is a 24-bit number that should be guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. This object has value 0 if ancpAnCurrentSessionState is not estab(4)." ::= { ancpAnCurrentSessionEntry 9 } ancpAnCurrentSessionCapabilities OBJECT-TYPE SYNTAX AncpAnSessionCapabilities MAX-ACCESS read-only STATUS current DESCRIPTION "The common ANCP capabilities supported by the AN and NAS in this session. The object has the value 0 if no capabilities are supported or if ancpAnCurrentSessionState is not estab(4)." ::= { ancpAnCurrentSessionEntry 10 } ancpAnCurrentSessionStartUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the session came to established state. This object has value 0 if ancpAnCurrentSessionState is not estab(4)." ::= { ancpAnCurrentSessionEntry 11 } ancpAnCurrentSessionDiscontinuityTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which session's counters suffered a discontinuity. If no such discontinuities have occurred since then, De Cnodder & Morgenstern Expires August 30, 2007 [Page 16] Internet-Draft ANCP MIB February 2007 this object contains the same value as ancpAnCurrentSessionStartUptime." ::= { ancpAnCurrentSessionEntry 12 } ancpAnCurrentSessionStatSentMessages OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been sent in this session by the access node. All ANCP messages pertaining to this session after the session came to established state shall be counted, also including adjacency protocol messages and failure response messages. Discontinuities of this counter are indicated by ancpAnCurrentSessionDiscontinuityTime." ::= { ancpAnCurrentSessionEntry 13 } ancpAnCurrentSessionStatReceivedValidMessages OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been received and processed in this session by the access node. All ANCP messages pertaining to this session after the session came to established state shall be counted, also including adjacency protocol messages and failure response messages. Discontinuities of this counter are indicated by ancpAnCurrentSessionDiscontinuityTime." ::= { ancpAnCurrentSessionEntry 14 } ancpAnCurrentSessionStatDiscardedMessages OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that in this session have been received and discarded for whatever reason by the access node. All ANCP messages pertaining to this session after the session came to established state shall be counted, also including adjacency protocol messages and failure response messages. Discontinuities of this counter are indicated by ancpAnCurrentSessionDiscontinuityTime." De Cnodder & Morgenstern Expires August 30, 2007 [Page 17] Internet-Draft ANCP MIB February 2007 ::= { ancpAnCurrentSessionEntry 15 } -- -- Partitions -- ancpAnInterfaceDefaultPartitionId OBJECT-TYPE SYNTAX GsmpPartitionIdType MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the manager control the default value for the ancpAnInterfaceConfigPartitionId object in ancpAnInterfaceConfigTable. The value of this object is persistent." DEFVAL { "0" } ::= { ancpAnObjects 4 } ancpAnInterfaceConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF AncpAnInterfaceConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table configures the association of user facing interfaces to ANCP partitions in the access node. An entry in this table needs to be added by the agent for each relevant user facing interface with the value of ancpAnInterfaceConfigPartitionId set to the value of ancpAnInterfaceDefaultPartitionId at the time of the creation of the row. A relevant user facing interface is created whenever a row is created in the ifTable of the IF-MIB that can be controlled by ANCP. When such an interface is deleted from the ifTable, the corresponding row in this table has to be removed by the agent. A manager is allowed to change the value of ancpAnInterfaceConfigPartitionId after the row has been created." ::= { ancpAnObjects 5 } ancpAnInterfaceConfigEntry OBJECT-TYPE SYNTAX AncpAnInterfaceConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the partition id for a specific user facing interface" INDEX { ifIndex } De Cnodder & Morgenstern Expires August 30, 2007 [Page 18] Internet-Draft ANCP MIB February 2007 ::= { ancpAnInterfaceConfigTable 1 } AncpAnInterfaceConfigEntry ::= SEQUENCE { ancpAnInterfaceConfigPartitionId GsmpPartitionIdType } ancpAnInterfaceConfigPartitionId OBJECT-TYPE SYNTAX GsmpPartitionIdType MAX-ACCESS read-write STATUS current DESCRIPTION "A partition Id associated with the related ifIndex. Upon creation of the row, the value is set to ancpAnInterfaceDefaultPartitionId. The value of this object is persistent." ::= { ancpAnInterfaceConfigEntry 1 } -- -- Notifications -- ancpSessionDown NOTIFICATION-TYPE OBJECTS { ancpAnCurrentSessionAnIpAddressType, ancpAnCurrentSessionAnIpAddress, ancpAnSessionConfigNasIpAddressType, ancpAnSessionConfigNasIpAddress, ancpAnCurrentSessionAnInstance, ancpAnCurrentSessionNasInstance, ancpAnCurrentSessionStartUptime, ancpAnCurrentSessionStatSentMessages, ancpAnCurrentSessionStatReceivedValidMessages, ancpAnCurrentSessionStatDiscardedMessages } STATUS current DESCRIPTION "This notification is generated whenever an ANCP session goes down. A session can go down for several reasons: 1) The ANCP session can be deleted by a manager from the ancpAnSessionConfigTable, and hence it will also be removed from the ancpAnCurrentSessionTable. 2) The session can go operational down due to some malfunction in the network, the AN, or the NAS. In this case, the ANCP session will be still in the ancpAnSessionConfigTable and ancpAnCurrentSessionTable, but the ancpAnCurrentSessionState moves from the estab state to another state." De Cnodder & Morgenstern Expires August 30, 2007 [Page 19] Internet-Draft ANCP MIB February 2007 ::= { ancpNotifications 1 } ancpSessionUp NOTIFICATION-TYPE OBJECTS { ancpAnCurrentSessionAnInstance } STATUS current DESCRIPTION "This notification is generated when an ANCP session enters the estab state as given by ancpAnCurrentSessionState. Since ancpAnCurrentSessionAnInstance identifies the ANCP session uniquely the other attributes can be derived from this attribute." ::= { ancpNotifications 2 } -- -- ANCP AN Compliance -- ancpAnGroups OBJECT IDENTIFIER ::= { ancpAnConformance 1 } ancpAnCompliances OBJECT IDENTIFIER ::= { ancpAnConformance 2 } ancpAnModuleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the ANCP MIB module for access nodes." MODULE -- this module MANDATORY-GROUPS { ancpAnConfigGroup, ancpAnCurrentGroup, ancpAnInterfaceGroup, ancpAnNotificationsGroup } ::= { ancpAnCompliances 1 } -- units of conformance ancpAnConfigGroup OBJECT-GROUP OBJECTS { ancpAnNextSessionId, ancpAnSessionConfigRowStatus, ancpAnSessionConfigGsmpVersion, ancpAnSessionConfigGsmpSubVersion, ancpAnSessionConfigEncapsulationType, ancpAnSessionConfigCapabilities, De Cnodder & Morgenstern Expires August 30, 2007 [Page 20] Internet-Draft ANCP MIB February 2007 ancpAnSessionConfigAliveTimer, ancpAnSessionConfigPortReportShaper, ancpAnSessionConfigAggregateReportShaper, ancpAnSessionConfigTransportRetryTimer, ancpAnSessionConfigGsmpRetryTimer, ancpAnSessionConfigAnName, ancpAnSessionConfigPartitionId, ancpAnSessionConfigWindowSize, ancpAnSessionConfigNasIpAddressType, ancpAnSessionConfigNasIpAddress, ancpAnSessionConfigEncapPortNumber } STATUS current DESCRIPTION "These objects apply to the configuration of ANCP sessions in access nodes." ::= { ancpAnGroups 1 } ancpAnCurrentGroup OBJECT-GROUP OBJECTS { ancpAnCurrentSessionState, ancpAnCurrentSessionGsmpVersion, ancpAnCurrentSessionGsmpSubVersion, ancpAnCurrentSessionAnName, ancpAnCurrentSessionNasName, ancpAnCurrentSessionAnIpAddressType, ancpAnCurrentSessionAnIpAddress, ancpAnCurrentSessionAnInstance, ancpAnCurrentSessionNasInstance, ancpAnCurrentSessionCapabilities, ancpAnCurrentSessionStartUptime, ancpAnCurrentSessionDiscontinuityTime, ancpAnCurrentSessionStatSentMessages, ancpAnCurrentSessionStatReceivedValidMessages, ancpAnCurrentSessionStatDiscardedMessages } STATUS current DESCRIPTION "These objects show the operational state of all ANCP sessions configured in the access node." ::= { ancpAnGroups 2 } ancpAnInterfaceGroup OBJECT-GROUP OBJECTS { ancpAnInterfaceDefaultPartitionId, ancpAnInterfaceConfigPartitionId } STATUS current De Cnodder & Morgenstern Expires August 30, 2007 [Page 21] Internet-Draft ANCP MIB February 2007 DESCRIPTION "These objects are used to assign user facing interface to partitions." ::= { ancpAnGroups 3 } ancpAnNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ancpSessionDown, ancpSessionUp } STATUS current DESCRIPTION "These notifications inform management stations about changes in the state of ANCP sessions." ::= { ancpAnGroups 4 } END 7. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. This is the table and these are the objects and their sensitivity/vulnerability: o ancpAnSessionConfigTable The table consists of the following objects that support SET operations: * ancpAnSessionConfigRowStatus * ancpAnSessionConfigGsmpVersion * ancpAnSessionConfigGsmpSubVersion * ancpAnSessionConfigEncapsulationType * ancpAnSessionConfigCapabilities * ancpAnSessionConfigAliveTimer * ancpAnSessionConfigPortReportShaper * ancpAnSessionConfigAggregateReportShaper * ancpAnSessionConfigTransportRetryTimer * ancpAnSessionConfigGsmpRetryTimer * ancpAnSessionConfigAnName * ancpAnSessionConfigPartitionId De Cnodder & Morgenstern Expires August 30, 2007 [Page 22] Internet-Draft ANCP MIB February 2007 * ancpAnSessionConfigWindowSize * ancpAnSessionConfigNasIpAddressType * ancpAnSessionConfigNasIpAddress * ancpAnSessionConfigEncapPortNumber Unauthorized changes to ancpAnSessionConfigRowStatus could result in session being created or brought into service prematurely; or could result in session being inadvertently deleted or taken out of service. Unauthorized changes to ancpAnSessionConfigGsmpVersion or ancpAnSessionConfigGsmpSubVersion could have an adverse operational effect by limiting the GSMP version to be used in the context of this session or enabling a GSMP version number that is actually unsupported by the access node. Unauthorized changes to ancpAnSessionConfigEncapsulationType could have an adverse operational effect by configuring the session to use an undesired or even unsupported protocol. Unauthorized changes to ancpAnSessionConfigCapabilities could have an adverse operational effect by disabling certain ANCP capabilities that the operator assumed that are enabled, or enable a capability that the operator would not like to activate. Unauthorized changes to ancpAnSessionConfigAliveTimer could have an adverse operational effect by increasing the frequency of adjacency protocol messages generated by the access node and leading to an overload of such messages. Decreasing the frequency of such messages may harm the synchronization between the access node and the NAS. Unauthorized changes to ancpAnSessionConfigPortReportShaper or ancpAnSessionConfigAggregateReportShaper could have an adverse operational effect by increasing the frequency of Event Report messages generated by the access node and leading to an overload of such messages. Decreasing the frequency of such messages may delay the responsivness of the system to events associated with one or more ports. Unauthorized changes to ancpAnSessionConfigTransportRetryTimer could have an adverse operational effect by increasing the frequency of transport connection setup attempts initiated by the access node or even unexpectedly enabling the access node to initiate the transport connection setup when that supposed to be disabled. Alternatively, when the operator basically planned transport connection setup attempts by the access node unauthorized changes to the attribute may cause unexpected low De Cnodder & Morgenstern Expires August 30, 2007 [Page 23] Internet-Draft ANCP MIB February 2007 frequency of such attepts or unexpectedly disable those attempts. Unauthorized changes to ancpAnSessionConfigGsmpRetryTimer could have an adverse operational effect by increasing the frequency of ANCP onnection setup attempts initiated by the access node or even unexpectedly enabling the access node to initiate the ANCP connection setup when that supposed to be disabled. Alternatively, when the operator basically planned ANCP connection setup attempts by the access node unauthorized changes to the attribute may cause unexpected low frequency of such attepts or unexpectedly disable those attempts. Unauthorized changes to ancpAnSessionConfigAnName could confuse the NAS, e.g., by detecting the same name from multiple access nodes. This may also override the operator's will to allow/avoid the access node to autonomously determine its name. Unauthorized changes to ancpAnSessionConfigPartitionId could mean that partitions are used when actually they are not, or vice versa. It could also al least specify a different partition ID than the one actually associated with the session. Unauthorized changes to ancpAnSessionConfigWindowSize are not directly harmfull. However, if the controller adopts the suggested wrong window size it may either cause the controller to send too many messages in a window or unnecessarily limit itself and that could reduce the system performance. Unauthorized changes to ancpAnSessionConfigNasIpAddressType and/or ancpAnSessionConfigNasIpAddress and/or ancpAnSessionConfigEncapPortNumber could produce a wrong address type (interpretation) and/or IP address for the NAS and/or specify a wrong transport protocol port number for the session, respectively. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. This is the table and these are the objects and their sensitivity/vulnerability: o ancpAnCurrentSessionTable Access to these objects would allow an intruder to obtain information about which vendor's equipment is in use on the De Cnodder & Morgenstern Expires August 30, 2007 [Page 24] Internet-Draft ANCP MIB February 2007 network. Further, such information is considered sensitive in many environments for competitive reasons. * ancpAnCurrentSessionState * ancpAnCurrentSessionGsmpVersion * ancpAnCurrentSessionGsmpSubVersion * ancpAnCurrentSessionAnName * ancpAnCurrentSessionNasName * ancpAnCurrentSessionAnIpAddressType * ancpAnCurrentSessionAnIpAddress * ancpAnCurrentSessionAnInstance * ancpAnCurrentSessionNasInstance * ancpAnCurrentSessionCapabilities * ancpAnCurrentSessionStartUptime * ancpAnCurrentSessionDiscontinuityTime * ancpAnCurrentSessionStatSentMessages * ancpAnCurrentSessionStatReceivedValidMessages * ancpAnCurrentSessionStatDiscardedMessages SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA considerations IANA is requested to assign an OID xxx under mib-2. 9. Acknowledgements The authors would like to thank Paul Reynders and Bert Wijnen for their feedback. De Cnodder & Morgenstern Expires August 30, 2007 [Page 25] Internet-Draft ANCP MIB February 2007 10. References 10.1. Normative References [ANCPFW] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", draft-ietf-ancp-framework-01.txt, work in progress, February 2007. [ANCPPR] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., and N. Voigt, "GSMP extensions for layer2 control (L2C) Topology Discovery and Line Configuration", draft-wadhwa-gsmp-l2control- configuration-01.txt, work in progress, March 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002. [RFC3295] Sjostrand, H., Buerkle, J., and B. Srinivasan, "Definitions of Managed Objects for the General Switch Management Protocol (GSMP)", RFC 3295, June 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. De Cnodder & Morgenstern Expires August 30, 2007 [Page 26] Internet-Draft ANCP MIB February 2007 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Authors' Addresses Stefaan De Cnodder Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 Email: stefaan.de_cnodder@alcatel- lucent.be Moti Morgenstern ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517 Israel Phone: +972 3 926 6258 Fax: +972 3 928 7342 Email: moti.Morgenstern@ecitele.com De Cnodder & Morgenstern Expires August 30, 2007 [Page 27] Internet-Draft ANCP MIB February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). De Cnodder & Morgenstern Expires August 30, 2007 [Page 28] --------------030300080903030703080801 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 --------------030300080903030703080801-- From ancp-bounces@ietf.org Wed Mar 14 07:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRS81-0001rf-Pl; Wed, 14 Mar 2007 07:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRS81-0001ra-0i for ancp@ietf.org; Wed, 14 Mar 2007 07:58:49 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRS7y-0001NE-4k for ancp@ietf.org; Wed, 14 Mar 2007 07:58:49 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 14 Mar 2007 04:58:44 -0700 X-IronPort-AV: i="4.14,283,1170662400"; d="txt'?scan'208"; a="670259371:sNHT190304726" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C76630.1D00B567" Subject: RE: [ANCP] ANCP MIB Date: Wed, 14 Mar 2007 07:58:41 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2807AE51F1@proton.jnpr.net> In-Reply-To: <45F7B3CD.5070806@alcatel-lucent.be> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP MIB Thread-Index: AcdmE+iizikhH4RYQS6AaoZxPFgz6QAGSWJg From: "Sanjay Wadhwa" To: , X-Spam-Score: 0.4 (/) X-Scan-Signature: 3c2f308c73d3221c0e72748732ce4acb 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C76630.1D00B567 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ditto with the updated protocol draft attached here, that was submitted to the IETF before the cutoff. The name, title and version have been changed to reflect it as a WG draft. Thanks -Sanjay -----Original Message----- From: stefaan.de_cnodder@alcatel-lucent.be [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, March 14, 2007 4:35 AM To: ancp@ietf.org Subject: [ANCP] ANCP MIB Hi, The updated ANCP MIB was submitted to the IETF in time but for some=20 reason it never appeared on i-d-annound. Therefore I sent the updated=20 draft as attachement to this mailing list. Comments are very welcome. regards, Stefaan ------_=_NextPart_001_01C76630.1D00B567 Content-Type: text/plain; name="draft-ietf-ancp-protocol-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ancp-protocol-00.txt Content-Disposition: attachment; filename="draft-ietf-ancp-protocol-00.txt" DQoNCg0KDQoNCg0KICAgICBXb3JraW5nIEdyb3VwIE5hbWUgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU2FuamF5IFdhZGh3YSANCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0d29ya3MgDQogICAg IEV4cGlyZXM6IEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSmVyb21lIE1vaXNhbmQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtzIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFN3YW1pIFN1YnJhbWFuaWFuIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBlciBOZXR3b3JrcyAN CiAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGhvbWFzIEhhYWcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULVN5c3RlbXMgICAgICANCiAgICAgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Tm9yYmVydCBWb2lndCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNpZW1lbnMgDQogICAgICANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDI1LCAyMDA3 ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICBQcm90b2NvbCBmb3IgQWNjZXNzIE5vZGUgQ29udHJvbCBNZWNoYW5pc20gaW4gQnJvYWRiYW5k IE5ldHdvcmtzIA0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0w MC50eHQgDQoNCg0KICAgICAgICAgDQoNCiAgICAgU3RhdHVzIG9mIHRoaXMgTWVtbyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCiAgICAgICAgIA0KDQog ICAgICAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVw cmVzZW50cyB0aGF0IGFueSANCiAgICAgICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBS IGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUgDQogICAgICAgIGhhdmUgYmVlbiBv ciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyAN CiAgICAgICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBzZWN0 aW9uIDYgb2YgQkNQIDc5LiANCg0KICAgICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyANCiAgICAgICAgVGFzayBGb3Jj ZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCAN CiAgICAgICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtDQogICAgICAgIERyYWZ0cy4gSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiANCiAgICAgICAgc2l4IG1vbnRocyBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgDQogICAg ICAgIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LURyYWZ0cyBhcyANCiAgICAgICAgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQoNCiAgICAgICAgVGhlIGxp c3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0ICAgICANCiAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0IA0KDQogICAg ICAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQgICAgIA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s IA0KDQogICAgICAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXVndXN0IDIy LCAyMDA3LiANCiAgICAgIA0KICAgICAgDQogICAgICANCgwgICAgIFdhZGh3YSBldC5hbCAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0K ICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9j b2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgQ29weXJpZ2h0IE5v dGljZSANCg0KICAgICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA3 KS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0KDQogICAgIEFic3RyYWN0IA0KDQogICAgICAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHByb3Bvc2VkIGV4dGVuc2lvbnMgdG8gdGhlIEdTTVB2MyBw cm90b2NvbCB0byANCiAgICAgICAgYWxsb3cgaXRzIHVzZSBpbiBhIGJyb2FkYmFuZCBlbnZpcm9u bWVudCwgYXMgYSBjb250cm9sIHBsYW5lIGJldHdlZW4gICANCiAgICAgICAgQWNjZXNzIE5vZGVz IChlLmcuIERTTEFNKSBhbmQgQnJvYWRiYW5kIE5ldHdvcmsgR2F0ZXdheXMgKGUuZy4gTkFTKS4g DQogICAgICAgIFRoZXNlIHByb3Bvc2VkIGV4dGVuc2lvbnMgYXJlIHJlcXVpcmVkIHRvIHJlYWxp emUgYSBwcm90b2NvbCBmb3IgDQogICAgICAgIJNBY2Nlc3MgTm9kZSBDb250cm9slCBtZWNoYW5p c20gYXMgZGVzY3JpYmVkIGluIFs5XS4gVGhlIHJlc3VsdGluZyANCiAgICAgICAgcHJvdG9jb2wg d2l0aCB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyB0byBHU01QdjMgWzRdIGlzIHJlZmVycmVkIHRv IGFzIA0KICAgICAgICCTQWNjZXNzIE5vZGUgQ29udHJvbCBQcm90b2NvbJQgKEFOQ1ApLiAgVGhp cyBkb2N1bWVudCBmb2N1c2VzIG9uIA0KICAgICAgICBzcGVjaWZpYyB1c2UgY2FzZXMgb2YgYWNj ZXNzIG5vZGUgY29udHJvbCBtZWNoYW5pc20gZm9yIHRvcG9sb2d5IA0KICAgICAgICBkaXNjb3Zl cnksIGxpbmUgY29uZmlndXJhdGlvbiwgYW5kIE9BTS4gSXQgaXMgaW50ZW5kZWQgdG8gYmUgDQog ICAgICAgIGF1Z21lbnRlZCBieSBhZGRpdGlvbmFsIHByb3RvY29sIHNwZWNpZmljYXRpb24gZm9y IGZ1dHVyZSB1c2UgY2FzZXMgDQogICAgICAgIGNvbnNpZGVyZWQgaW4gc2NvcGUgYnkgdGhlIEFO Q1AgY2hhcnRlci4gDQoNCiAgICAgICAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50 IA0KDQogICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQi LCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs ICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgICAgICBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5IFsx XS4gDQoNCiAgICAgICAgVGFibGUgb2YgQ29udGVudHMgDQoNCiAgICAgICAgMSAgU3BlY2lmaWNh dGlvbiBSZXF1aXJlbWVudHMgNCANCg0KICAgICAgICAyICBJbnRyb2R1Y3Rpb240IA0KDQogICAg ICAgIDMgIEJyb2FkYmFuZCBBY2Nlc3MgQWdncmVnYXRpb24gIDQgDQoNCiAgICAgICAgICAgMy4x ICAgQVRNLWJhc2VkIGJyb2FkYmFuZCBhZ2dyZWdhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNCANCiAgICAgICAgICAgMy4yICAgRXRoZXJuZXQtYmFzZWQgYnJvYWRiYW5kIGFnZ3JlZ2F0 aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNiANCiAgICAgICAgIA0KDQogICAgICAgIDQgIEFjY2Vz cyBOb2RlIENvbnRyb2wgUHJvdG9jb2wgIDcgDQoNCiAgICAgICAgICAgNC4xICAgT3ZlcnZpZXcu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgICAg ICAgICAgNC4yICAgQU5DUCBiYXNlZCBBY2Nlc3MgVG9wb2xvZ3kgRGlzY292ZXJ5Li4uLi4uLi4u Li4uLi4uLi4uLi4uOCANCiAgICAgICAgICAgICAgNC4yLjEgICAgR29hbHMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgICAgICAgICAgICAgNC4yLjIg ICAgTWVzc2FnZSBGbG93Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCAN CiAgICAgICAgICAgNC4zICAgQU5DUCBiYXNlZCBMaW5lIENvbmZpZ3VyYXRpb24uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uOSANCiAgICAgICAgICAgICAgNC4zLjEgICAgR29hbHMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgICAgICAgICAgICAg NC4zLjIgICAgTWVzc2FnZSBGbG93Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xMCANCiAgICAgICAgICAgNC40ICAgQU5DUCBiYXNlZCBUcmFuc2FjdGlvbmFsIE11bHRpY2Fz dC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMiANCiAgICAgICAgICAgNC41ICAgQU5DUCBiYXNlZCBP QU0uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANCiAgICAgIA0K ICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIw MDcgICAgICAgICAgICAgICAgIFtQYWdlIDJdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1E cmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3 IA0KICAgICAgICAgDQoNCiAgICAgICAgICAgICAgNC41LjEgICAgTWVzc2FnZSBGbG93Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANCiAgICAgICAgIA0KDQogICAgICAg IDUgIEFjY2VzcyBOb2RlIENvbnRyb2wgUHJvdG9jb2wgKEFOQ1ApIDE0IA0KDQogICAgICAgICAg IDUuMSAgIEFOQ1AvVENQIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTQgDQogICAgICAgICAgIDUuMiAgIEFOQ1AgQ29ubmVjdGlvbiBrZWVwLWFsaXZlLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUgDQogICAgICAgICAgIDUuMyAgIENhcGFiaWxp dHkgbmVnb3RpYXRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYgDQogICAg ICAgICAgIDUuNCAgIEdTTVAgTWVzc2FnZSBFeHRlbnNpb25zIGZvciBBY2Nlc3MgTm9kZSBDb250 cm9sLi4uLi4uLi4uMTggDQogICAgICAgICAgICAgIDUuNC4xICAgIEdlbmVyYWwgRXh0ZW5zaW9u cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTggDQogICAgICAgICAgICAgIDUuNC4y ICAgIFRvcG9sb2d5IERpc2NvdmVyeSBFeHRlbnNpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjEg DQogICAgICAgICAgICAgIDUuNC4zICAgIExpbmUgQ29uZmlndXJhdGlvbiBFeHRlbnNpb25zLi4u Li4uLi4uLi4uLi4uLi4uLi4uMzAgDQogICAgICAgICAgICAgIDUuNC40ICAgIE9BTSBFeHRlbnNp b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzIgDQogICAgICAgICAgIDUu NSAgIEFUTS1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMzUgDQogICAgICAgICAgIDUuNiAgIEV0aGVybmV0LXNwZWNpZmljIGNvbnNpZGVyYXRpb25z Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzYgDQogICAgICAgIDYgIElBTkEgQ29uc2lkZXJhdGlv bnMgIDM2IA0KDQogICAgICAgIDcgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIDM2IA0KDQogICAg ICAgIDggIFJlZmVyZW5jZXMgIDM3IA0KDQogICAgICAgIEF1dGhvcidzIEFkZHJlc3NlczM4IA0K DQogICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQgIDM4IA0KDQogICAgICAg IERpc2NsYWltZXIgb2YgVmFsaWRpdHkgIDM5IA0KDQogICAgICAgIENvcHlyaWdodCBTdGF0ZW1l bnQgIDM5IA0KDQogICAgICAgIEFja25vd2xlZGdtZW50IDM5IA0KDQogICAgICAgICANCg0KICAg ICAgICAgDQoNCiAgICAgICAgIA0KDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAg IA0KDQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3 YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAg IFtQYWdlIDNdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1p ZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAg ICAgMSAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlbWVudHMgDQoNCiAgICAgICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAg IA0KICAgICAgICCTU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcyAgIA0KICAgICAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5LiANCg0KICAgICAgICAgDQoNCiAgICAg MiAgSW50cm9kdWN0aW9uIA0KDQogICAgICAgIERTTCBpcyBhIHdpZGVseSBkZXBsb3llZCBhY2Nl c3MgdGVjaG5vbG9neSBmb3IgQnJvYWRiYW5kIEFjY2VzcyBmb3IgDQogICAgICAgIE5leHQgR2Vu ZXJhdGlvbiBOZXR3b3Jrcy4gU2V2ZXJhbCBzcGVjaWZpY2F0aW9ucyBsaWtlIFsxLTNdIGRlc2Ny aWJlIA0KICAgICAgICBwb3NzaWJsZSBhcmNoaXRlY3R1cmVzIGZvciB0aGVzZSBhY2Nlc3MgbmV0 d29ya3MuIEluIHRoZSBzY29wZSBvZiANCiAgICAgICAgdGhlc2Ugc3BlY2lmaWNhdGlvbnMgYXJl IHRoZSBkZWxpdmVyeSBvZiB2b2ljZSwgdmlkZW8gYW5kIGRhdGEgDQogICAgICAgIHNlcnZpY2Vz LiANCg0KICAgICAgICBXaGVuIGRlcGxveWluZyB2YWx1ZS1hZGRlZCBzZXJ2aWNlcyBhY3Jvc3Mg RFNMIGFjY2VzcyBuZXR3b3JrcywgDQogICAgICAgIHNwZWNpYWwgYXR0ZW50aW9uIHJlZ2FyZGlu ZyBxdWFsaXR5IG9mIHNlcnZpY2UgYW5kIHNlcnZpY2UgY29udHJvbCBpcyANCiAgICAgICAgcmVx dWlyZWQsIHdoaWNoIGltcGxpZXMgYSB0aWdodGVyIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIG5ldHdv cmsgDQogICAgICAgIGVsZW1lbnRzIGluIHRoZSBicm9hZGJhbmQgYWNjZXNzIG5ldHdvcmsgd2l0 aG91dCBidXJkZW5pbmcgdGhlIE9TUyANCiAgICAgICAgbGF5ZXIuICANCg0KICAgICAgICBUaGlz IGRyYWZ0IGRlZmluZXMgZXh0ZW5zaW9ucyBhbmQgbW9kaWZpY2F0aW9ucyB0byBHU01QdjMgKHNw ZWNpZmllZCANCiAgICAgICAgaW4gWzRdKSBhbmQgY2VydGFpbiBuZXcgbWVjaGFuaXNtcyB0byBy ZWFsaXplIGEgY29udHJvbCBwbGFuZSBiZXR3ZWVuIA0KICAgICAgICBhIHNlcnZpY2Utb3JpZW50 ZWQgbGF5ZXIgMyBlZGdlIGRldmljZSAodGhlIE5BUykgYW5kIGEgbGF5ZXIyIEFjY2VzcyANCiAg ICAgICAgTm9kZSAoZS5nLiBEU0xBTSkgaW4gb3JkZXIgdG8gcGVyZm9ybSBRb1MtcmVsYXRlZCwg c2VydmljZS1yZWxhdGVkIA0KICAgICAgICBhbmQgc3Vic2NyaWJlci1yZWxhdGVkIG9wZXJhdGlv bnMuIFRoZSBjb250cm9sIHByb3RvY29sIGFzIGEgcmVzdWx0IA0KICAgICAgICBvZiB0aGVzZSBl eHRlbnNpb25zIGFuZCBtZWNoYW5pc21zIGlzIHJlZmVycmVkIHRvIGFzIJNBY2Nlc3MgTm9kZSAN CiAgICAgICAgQ29udHJvbCBQcm90b2NvbJQgKEFOQ1ApLiAgDQoNCiAgICAgICAgSW4gYWRkaXRp b24gdG8gc3BlY2lmeWluZyBleHRlbnNpb25zIGFuZCBtb2RpZmljYXRpb25zIHRvIHJlbGV2YW50 IA0KICAgICAgICBHU01QIG1lc3NhZ2VzIGFwcGxpY2FibGUgdG8gYWNjZXNzIG5vZGUgY29udHJv bCBtZWNoYW5pc20sIHRoaXMgZHJhZnQgDQogICAgICAgIGFsc28gZGVmaW5lcyB2YWx1ZXMgdGhh dCBBTkNQIHNob3VsZCBzZXQgZm9yIHJlbGV2YW50IGZpZWxkcyBpbiB0aGVzZSANCiAgICAgICAg R1NNUCBtZXNzYWdlcy4gSG93ZXZlciwgdG8gdW5kZXJzdGFuZCB0aGUgYmFzaWMgc2VtYW50aWNz IG9mIHZhcmlvdXMgDQogICAgICAgIGZpZWxkcyBpbiBHU01QIG1lc3NhZ2VzLCB0aGUgcmVhZGVy IGlzIHJlZmVycmVkIHRvIFs0XS4gDQoNCiAgICAgICAgIA0KICAgICAzICBCcm9hZGJhbmQgQWNj ZXNzIEFnZ3JlZ2F0aW9uICANCg0KICAgICAgICAgDQogICAgIDMuMSBBVE0tYmFzZWQgYnJvYWRi YW5kIGFnZ3JlZ2F0aW9uICANCg0KICAgICAgICBFbmQgdG8gZW5kIERTTCBuZXR3b3JrIGNvbnNp c3RzIG9mIG5ldHdvcmsgYW5kIGFwcGxpY2F0aW9uIHNlcnZpY2UgDQogICAgICAgIHByb3ZpZGVy IG5ldHdvcmtzIChOU1AgYW5kIEFTUCBuZXR3b3JrcyksIHJlZ2lvbmFsL2FjY2VzcyBuZXR3b3Jr LCANCiAgICAgICAgYW5kIGN1c3RvbWVyIHByZW1pc2VzIG5ldHdvcmsuIEZpZzEuIHNob3dzIEFU TSBicm9hZGJhbmQgYWNjZXNzIA0KICAgICAgICBuZXR3b3JrIGNvbXBvbmVudHMuIA0KDQogICAg ICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI1 LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA0XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJu ZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAwICAgICAgICBBdWd1c3Qg MjAwNyANCiAgICAgICAgIA0KDQogICAgICAgIFRoZSBSZWdpb25hbC9BY2Nlc3MgTmV0d29yayBj b25zaXN0cyBvZiB0aGUgUmVnaW9uYWwgTmV0d29yaywgTmV0d29yayANCiAgICAgICAgQWNjZXNz IFNlcnZlciwgYW5kIHRoZSBBY2Nlc3MgTmV0d29yayBhcyBzaG93IGluIEZpZyAxLiBJdHMgcHJp bWFyeSANCiAgICAgICAgZnVuY3Rpb24gaXMgdG8gcHJvdmlkZSBlbmQtdG8tZW5kIHRyYW5zcG9y dCBiZXR3ZWVuIHRoZSBjdXN0b21lciANCiAgICAgICAgcHJlbWlzZXMgYW5kIHRoZSBOU1Agb3Ig QVNQLiBUaGUgQWNjZXNzIE5vZGUgdGVybWluYXRlcyB0aGUgRFNMIA0KICAgICAgICBzaWduYWwu IEl0IGNvdWxkIGNvbnNpc3Qgb2YgRFNMQU0gaW4gdGhlIGNlbnRyYWwgb2ZmaWNlLCBvciByZW1v dGUgDQogICAgICAgIERTTEFNLCBvciBhIFJlbW90ZSBBY2Nlc3MgTXVsdGlwbGV4ZXIgKFJBTSku IEFjY2VzcyBub2RlIGlzIHRoZSBmaXJzdCANCiAgICAgICAgcG9pbnQgaW4gdGhlIG5ldHdvcmsg d2hlcmUgdHJhZmZpYyBvbiBtdWx0aXBsZSBEU0wgbGluZXMgd2lsbCBiZSANCiAgICAgICAgYWdn cmVnYXRlZCBvbnRvIGEgc2luZ2xlIG5ldHdvcmsuICANCg0KICAgICAgICBUaGUgTkFTIHBlcmZv cm1zIG11bHRpcGxlIGZ1bmN0aW9ucyBpbiB0aGUgbmV0d29yay4gVGhlIE5BUyBpcyB0aGUgDQog ICAgICAgIGFnZ3JlZ2F0aW9uIHBvaW50IGZvciB0aGUgc3Vic2NyaWJlciB0cmFmZmljLiBJdCBw cm92aWRlcyBhZ2dyZWdhdGlvbiANCiAgICAgICAgY2FwYWJpbGl0aWVzIChlLmcuIElQLCBQUFAs IEFUTSkgYmV0d2VlbiB0aGUgUmVnaW9uYWwvQWNjZXNzIE5ldHdvcmsgDQogICAgICAgIGFuZCB0 aGUgTlNQIG9yIEFTUC4gVGhlc2UgaW5jbHVkZSB0cmFkaXRpb25hbCBBVE0tYmFzZWQgb2ZmZXJp bmdzIGFuZCANCiAgICAgICAgbmV3ZXIsIG1vcmUgbmF0aXZlIElQLWJhc2VkIHNlcnZpY2VzLiBU aGlzIGluY2x1ZGVzIHN1cHBvcnQgZm9yIA0KICAgICAgICBQb2ludC10by1Qb2ludCBQcm90b2Nv bCBvdmVyIEFUTSAoUFBQb0EpIGFuZCBQUFAgb3ZlciBFdGhlcm5ldCANCiAgICAgICAgKFBQUG9F KSwgYXMgd2VsbCBhcyBkaXJlY3QgSVAgc2VydmljZXMgZW5jYXBzdWxhdGVkIG92ZXIgYW4gDQog ICAgICAgIGFwcHJvcHJpYXRlIGxheWVyIDIgdHJhbnNwb3J0LiAgDQoNCiAgICAgICAgQmV5b25k IGFnZ3JlZ2F0aW9uLCBOQVMgaXMgYWxzbyB0aGUgaW5qZWN0aW9uIHBvaW50IGZvciBwb2xpY3kg DQogICAgICAgIG1hbmFnZW1lbnQgYW5kIElQIFFvUyBpbiB0aGUgUmVnaW9uYWwvQWNjZXNzIE5l dHdvcmtzLiBJbiBvcmRlciB0byANCiAgICAgICAgYWxsb3cgSVAgUW9TIHN1cHBvcnQgb3ZlciBh biBleGlzdGluZyBub24tSVAtYXdhcmUgbGF5ZXIgMiBhY2Nlc3MgDQogICAgICAgIG5ldHdvcmsg d2l0aG91dCB1c2luZyBtdWx0aXBsZSBsYXllciAyIFFvUyBjbGFzc2VzLCBhIG1lY2hhbmlzbSBi YXNlZCANCiAgICAgICAgb24gaGllcmFyY2hpY2FsIHNjaGVkdWxpbmcgaXMgdXNlZC4gVGhpcyBt ZWNoYW5pc20gZGVmaW5lZCBpbiBbMV0sIA0KICAgICAgICBwcmVzZXJ2ZXMgSVAgUW9TIG92ZXIg dGhlIEFUTSBuZXR3b3JrIGJldHdlZW4gdGhlIE5BUyBhbmQgdGhlIFJHcyBieSAgICANCiAgICAg ICAgY2FyZWZ1bGx5IGNvbnRyb2xsaW5nIGRvd25zdHJlYW0gdHJhZmZpYyBpbiB0aGUgTkFTLCBz byB0aGF0ICAgDQogICAgICAgIHNpZ25pZmljYW50IHF1ZXVpbmcgYW5kIGNvbmdlc3Rpb24gZG9l cyBub3Qgb2NjdXIgZnVydGhlciBkb3duIHRoZSAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA1XSANCiAg ICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXByb3Rv Y29sLTAwICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAgICAgIA0KDQogICAgICAgIEFUTSBuZXR3 b3JrLiBUaGlzIGlzIGFjaGlldmVkIGJ5IHVzaW5nIGEgZGlmZnNlcnYtYXdhcmUgaGllcmFyY2hp Y2FsIA0KICAgICAgICBzY2hlZHVsZXIgaW4gdGhlIE5BUyB0aGF0IHdpbGwgYWNjb3VudCBmb3Ig ZG93bnN0cmVhbSB0cnVuayANCiAgICAgICAgYmFuZHdpZHRocyBhbmQgRFNMIHN5bmNoIHJhdGVz LiANCiAgICAgICAgWzldIHByb3ZpZGVzIGRldGFpbGVkIGRlZmluaXRpb24gYW5kIGZ1bmN0aW9u cyBvZiBlYWNoIG5ldHdvcmsgDQogICAgICAgIGVsZW1lbnQgaW4gdGhlIGJyb2FkYmFuZCByZWZl cmVuY2UgYXJjaGl0ZWN0dXJlLiANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFjY2VzcyAgICAgICAgICAgICAgICAgICAg IEN1c3RvbWVyICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLSBB Z2dyZWdhdGlvbiAtLS0+ICAgPC0tLS0tLS0gUHJlbWlzZXMgLS0tLS0tLT4gIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXR3b3JrICAgICAgICAgICAgICAg ICAgICAgTmV0d29yayANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgKy0t LS0tKyAgIHwgKy0tLS0tKyAgKy0tLS0tLSsgfC0tfCstLS0tLSsgKy0tKyArLS0tLS0tLS0tLSsg fCANCiAgICAgICAgICAgICAgfCAgICAgICAgICB8ICstfE5BUyAgfC0tLXwgfEFUTSAgfC0tfEFj Y2Vzc3wgfCAgfHxEU0wgIHwtfFJHfC18U3Vic2NyaWJlcnwgfCANCiAgICAgICAgTlNQLS0tK1Jl Z2lvbmFsICB8IHwgKy0tLS0tKyAgIHwgKy0tLS0tKyAgfCBOb2RlIHwgfCAgfHxNb2RlbXwgKy0t KyB8RGV2aWNlcyAgIHwgfCANCiAgICAgICAgICAgICAgfEJyb2FkYmFuZCB8IHwgKy0tLS0tKyAg IHwgICAgICAgICAgKy0tLS0tLSsgfCAgfCstLS0tLSsgICAgICArLS0tLS0tLS0tLSsgfCANCiAg ICAgICAgICAgICAgfE5ldHdvcmsgICB8LSstfE5BUyAgfCAgICstLS0tLS0tLS0tLS0tLS18LS0t KyAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgQVNQLS0tKyAgICAgICAg ICB8IHwgKy0tLS0tKyAgICAgICAgICAgICAgICAgICB8ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgfCAgICAgICAgICB8IHwgKy0tLS0tKyAgICAgICAg ICAgICAgICAgICB8ICAgICAgfCArLS0tLS0rICstLSsgKy0tLS0tLS0tLS0rfCANCiAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0rICstfE5BUyAgfCAgICAgICAgICAgICAgICAgICArLS0tLS0tfCB8 IERTTCB8LXxSR3wtfFN1YnNjcmliZXJ8fCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8TW9kZW18ICstLSsgfERldmljZXMg ICB8fCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCArLS0tLS0rICAgICAgKy0tLS0tLS0tLS0rfCANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgIFJHICAgOiBSb3V0aW5nIEdhdGV3YXkgDQog ICAgICAgICBOQVMgIDogTmV0d29yayBBY2Nlc3MgU2VydmVyIA0KICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgIEZpZy4xICBBVE0gQnJvYWRiYW5kIEFnZ3JlZ2F0 aW9uIFRvcG9sb2d5IA0KICAgICAgICAgDQogICAgICAgICANCg0KICAgICAzLjIgRXRoZXJuZXQt YmFzZWQgYnJvYWRiYW5kIGFnZ3JlZ2F0aW9uICANCg0KICAgICBUaGUgRXRoZXJuZXQgYWdncmVn YXRpb24gbmV0d29yayBhcmNoaXRlY3R1cmUgYnVpbGRzIG9uIHRoZSBFdGhlcm5ldCANCiAgICAg YnJpZGdpbmcvc3dpdGNoaW5nIGNvbmNlcHRzIGRlZmluZWQgaW4gSUVFRSA4MDIuIFRoZSBFdGhl cm5ldCANCiAgICAgYWdncmVnYXRpb24gbmV0d29yayBwcm92aWRlcyB0cmFmZmljIGFnZ3JlZ2F0 aW9uLCBjbGFzcyBvZiBzZXJ2aWNlIA0KICAgICBkaXN0aW5jdGlvbiwgYW5kIGN1c3RvbWVyIHNl cGFyYXRpb24gYW5kIHRyYWNlYWJpbGl0eS4gVkxBTiB0YWdnaW5nIA0KICAgICBkZWZpbmVkIGlu IElFRUUgODAyLjFRIGFuZCBiZWluZyBlbmhhbmNlZCBieSBJRUVFIDgwMi4xYWQgaXMgdXNlZCBh cyANCiAgICAgc3RhbmRhcmQgdmlydHVhbGl6YXRpb24gbWVjaGFuaXNtIGluIHRoZSBFdGhlcm5l dCBhZ2dyZWdhdGlvbiBuZXR3b3JrLiANCiAgICAgVGhlIGFnZ3JlZ2F0aW9uIGRldmljZXMgYXJl IJNwcm92aWRlciBlZGdlIGJyaWRnZXOUIGRlZmluZWQgaW4gSUVFRSANCiAgICAgODAyLmFkLiAg DQogICAgIFN0YWNrZWQgVkxBTiB0YWdzIHByb3ZpZGUgb25lIHBvc3NpYmxlIHdheSB0byBjcmVh dGUgZXF1aXZhbGVudCBvZiANCiAgICAgk3ZpcnR1YWwgcGF0aHOUIGFuZCCTdmlydHVhbCBjaXJj dWl0c5QgaW4gdGhlIGFnZ3JlZ2F0aW9uIG5ldHdvcmsuIFRoZSANCiAgICAgk291dGVylCB2bGFu IGNvdWxkIGJlIHVzZWQgdG8gY3JlYXRlIGEgZm9ybSBvZiCTdmlydHVhbCBwYXRolCBiZXR3ZWVu IGEgDQogICAgIGdpdmVuIERTTEFNIGFuZCBhIGdpdmVuIE5BUy4gQW5kIJNpbm5lcpQgVkxBTiB0 YWdzIHRvIGNyZWF0ZSBhIGZvcm0gb2YgDQogICAgIJN2aXJ0dWFsIGNpcmN1aXSUIG9uIGEgcGVy IERTTCBsaW5lIGJhc2lzLiBUaGlzIGlzIDE6MSBWTEFOIGFsbG9jYXRpb24gDQogICAgIG1vZGVs LiBBbiBhbHRlcm5hdGl2ZSBtb2RlbCBpcyB0byBicmlkZ2Ugc2Vzc2lvbnMgZnJvbSBtdWx0aXBs ZSANCiAgICAgc3Vic2NyaWJlcnMgYmVoaW5kIGEgRFNMQU0gaW50byBhIHNpbmdsZSBWTEFOIGlu IHRoZSBhZ2dyZWdhdGlvbiANCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0K ICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJv dG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgbmV0d29yay4g VGhpcyBpcyBOOjEgVkxBTiBhbGxvY2F0aW9uIG1vZGVsLiBBcmNoaXRlY3R1cmFsIGFuZCANCiAg ICAgdG9wb2xvZ2ljYWwgbW9kZWxzIG9mIGFuIEV0aGVybmV0IGFnZ3JlZ2F0aW9uIG5ldHdvcmsg aW4gY29udGV4dCBvZiBEU0wgDQogICAgIGFnZ3JlZ2F0aW9uIGFyZSBkZWZpbmVkIGluIFs4XS4g IA0KICAgICAgICAgDQoNCiAgICAgNCAgQWNjZXNzIE5vZGUgQ29udHJvbCBQcm90b2NvbCANCg0K ICAgICA0LjEgT3ZlcnZpZXcgDQoNCiAgICAgICAgQSBkZWRpY2F0ZWQgY29udHJvbCBwcm90b2Nv bCBiZXR3ZWVuIE5BUyBhbmQgYWNjZXNzIG5vZGVzIGNhbiANCiAgICAgICAgZmFjaWxpdGF0ZSAi TkFTIG1hbmFnZWQiIHRpZ2h0IFFPUyBjb250cm9sIGluIHRoZSBhY2Nlc3MgbmV0d29yaywgDQog ICAgICAgIHNpbXBsaWZpZWQgT1NTIGluZnJhc3RydWN0dXJlIGZvciBzZXJ2aWNlIG1hbmFnZW1l bnQsIG9wdGltaXplZCANCiAgICAgICAgbXVsdGljYXN0IHJlcGxpY2F0aW9uIHRvIGVuYWJsZSB2 aWRlbyBzZXJ2aWNlcyBvdmVyIERTTCwgc3Vic2NyaWJlciANCiAgICAgICAgc3RhdGlzdGljcyBy ZXRyaWV2YWwgb24gdGhlIE5BUyBmb3IgYWNjb3VudGluZyBwdXJwb3NlcywgYW5kIGZhdWx0IA0K ICAgICAgICBpc29sYXRpb24gY2FwYWJpbGl0eSBvbiB0aGUgTkFTIGZvciB0aGUgdW5kZXJseWlu ZyBhY2Nlc3MgdGVjaG5vbG9neS4gDQogICAgICAgIFRoaXMgZGVkaWNhdGVkIGNvbnRyb2wgcGxh bmUgaXMgcmVmZXJyZWQgdG8gYXMgk0FjY2VzcyBOb2RlIENvbnRyb2wgDQogICAgICAgIFByb3Rv Y29slCAoQU5DUCkuIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlbGV2YW50IGV4dGVuc2lvbnMg dG8gDQogICAgICAgIEdTTVB2MyBhcyBkZWZpbmVkIFs0XSB0byByZWFsaXplIEFOQ1AuIA0KDQog ICAgICAgIEZvbGxvd2luZyBzZWN0aW9ucyBkaXNjdXNzIHRoZSB1c2Ugb2YgQU5DUCBmb3IgaW1w bGVtZW50aW5nOiANCg0KICAgICAgICAgIC4gRHluYW1pYyBkaXNjb3Zlcnkgb2YgYWNjZXNzIHRv cG9sb2d5IGJ5IHRoZSBOQVMgdG8gcHJvdmlkZSB0aWdodCANCiAgICAgICAgICAgICBRT1MgY29u dHJvbCBpbiB0aGUgYWNjZXNzIG5ldHdvcmsuIA0KDQogICAgICAgICAgLiBQdXNoaW5nIHRvIHRo ZSBhY2Nlc3Mtbm9kZXMsIHN1YnNjcmliZXIgYW5kIHNlcnZpY2UgZGF0YSANCiAgICAgICAgICAg ICByZXRyaWV2ZWQgYnkgdGhlIE5BUyBmcm9tIGFuIE9TUyBzeXN0ZW0gKGUuZy4gcmFkaXVzIHNl cnZlciksIHRvIA0KICAgICAgICAgICAgIHNpbXBsaWZ5IE9TUyBpbmZyYXN0cnVjdHVyZSBmb3Ig c2VydmljZSBtYW5hZ2VtZW50LiANCg0KICAgICAgICAgIC4gT3B0aW1pemVkLCAiTkFTIGNvbnRy b2xsZWQgYW5kIG1hbmFnZWQiIG11bHRpY2FzdCByZXBsaWNhdGlvbiBieSANCiAgICAgICAgICAg ICBhY2Nlc3Mtbm9kZXMgYXQgTDIgbGF5ZXIuICANCg0KICAgICAgICAgIC4gTkFTIGNvbnRyb2xs ZWQsIG9uLWRlbWFuZCBhY2Nlc3MtbGluZSB0ZXN0IGNhcGFiaWxpdHkgDQogICAgICAgICAgICAg KHJ1ZGltZW50YXJ5IGVuZC10by1lbmQgT0FNKS4gICAgDQoNCiAgICAgICAgSW4gYWRkaXRpb24g dG8gRFNMLCBhbHRlcm5hdGUgYnJvYWRiYW5kIGFjY2VzcyB0ZWNobm9sb2dpZXMgKGUuZy4gDQog ICAgICAgIE1ldHJvLUV0aGVybmV0LCBQYXNzaXZlIE9wdGljYWwgTmV0d29ya2luZywgV2lNYXgp IHdpbGwgaGF2ZSBzaW1pbGFyIA0KICAgICAgICBjaGFsbGVuZ2VzIHRvIGFkZHJlc3MsIGFuZCBj b3VsZCBiZW5lZml0IGZyb20gdGhlIHNhbWUgYXBwcm9hY2ggb2YgYSANCiAgICAgICAgY29udHJv bCBwbGFuZSBiZXR3ZWVuIGEgTkFTIGFuZCBhbiBBY2Nlc3MgTm9kZSAoZS5nLiBPTFQpLCBwcm92 aWRpbmcgDQogICAgICAgIGEgdW5pZmllZCBjb250cm9sIGFuZCBtYW5hZ2VtZW50IGFyY2hpdGVj dHVyZSBmb3IgbXVsdGlwbGUgYWNjZXNzIA0KICAgICAgICB0ZWNobm9sb2dpZXMsIGhlbmNlIGZh Y2lsaXRhdGluZyBtaWdyYXRpb24gZnJvbSBvbmUgdG8gdGhlIG90aGVyIA0KICAgICAgICBhbmQv b3IgcGFyYWxsZWwgZGVwbG95bWVudHMuICANCg0KICAgICAgICBHU01QdjMgaXMgYW4gaWRlYWwg Zml0IGZvciBpbXBsZW1lbnRpbmcgQU5DUC4gSXQgaXMgZXh0ZW5zaWJsZSBhbmQgDQogICAgICAg IGNhbiBiZSBydW4gb3ZlciBUQ1AvSVAsIHdoaWNoIG1ha2VzIGl0IHBvc3NpYmxlIHRvIHJ1biBv dmVyIGRpZmZlcmVudCANCiAgICAgICAgYWNjZXNzIHRlY2hub2xvZ2llcy4gDQoNCiAgICAgICAg IA0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQogICAgICAgICANCgwgICAg IEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAg QXVndXN0IDIwMDcgDQogICAgICAgICANCg0KICAgICA0LjIgQU5DUCBiYXNlZCBBY2Nlc3MgVG9w b2xvZ3kgRGlzY292ZXJ5IA0KDQogICAgIDQuMi4xIEdvYWxzIA0KDQogICAgICAgIFsxXSBkaXNj dXNzZXMgdmFyaW91cyBxdWV1aW5nL3NjaGVkdWxpbmcgbWVjaGFuaXNtcyB0byBhdm9pZCANCiAg ICAgICAgY29uZ2VzdGlvbiBpbiB0aGUgYWNjZXNzIG5ldHdvcmsgd2hpbGUgZGVhbGluZyB3aXRo IG11bHRpcGxlIGZsb3dzIA0KICAgICAgICB3aXRoIGRpc3RpbmN0IFFvUyByZXF1aXJlbWVudHMu IFN1Y2ggbWVjaGFuaXNtcyByZXF1aXJlIHRoYXQgdGhlIE5BUyANCiAgICAgICAgZ2FpbnMga25v d2xlZGdlIGFib3V0IHRoZSB0b3BvbG9neSBvZiB0aGUgYWNjZXNzIG5ldHdvcmssIHRoZSB2YXJp b3VzIA0KICAgICAgICBsaW5rcyBiZWluZyB1c2VkIGFuZCB0aGVpciByZXNwZWN0aXZlIHJhdGVz LiBTb21lIG9mIHRoZSBpbmZvcm1hdGlvbiANCiAgICAgICAgcmVxdWlyZWQgaXMgc29tZXdoYXQg ZHluYW1pYyBpbiBuYXR1cmUgKGUuZy4gRFNMIHN5bmMgcmF0ZSksIGhlbmNlIA0KICAgICAgICBj YW5ub3QgY29tZSBmcm9tIGEgcHJvdmlzaW9uaW5nIGFuZC9vciBpbnZlbnRvcnkgbWFuYWdlbWVu dCBPU1MgDQogICAgICAgIHN5c3RlbS4gU29tZSBvZiB0aGUgaW5mb3JtYXRpb24gdmFyaWVzIGxl c3MgZnJlcXVlbnRseSAoZS5nLiBjYXBhY2l0eSANCiAgICAgICAgb2YgYSBEU0xBTSB1cGxpbmsp LCBidXQgbmV2ZXJ0aGVsZXNzIG5lZWRzIHRvIGJlIGtlcHQgc3RyaWN0bHkgaW4gDQogICAgICAg IHN5bmMgYmV0d2VlbiB0aGUgYWN0dWFsIGNhcGFjaXR5IG9mIHRoZSB1cGxpbmsgYW5kIHRoZSBp bWFnZSB0aGUgTkFTIA0KICAgICAgICBoYXMgb2YgaXQuICANCg0KICAgICAgICBGb2xsb3dpbmcg c2VjdGlvbiBkZXNjcmliZXMgQU5DUCBtZXNzYWdlcyB0aGF0IGFsbG93IHRoZSBBY2Nlc3MgTm9k ZSANCiAgICAgICAgKGUuZy4gRFNMQU0pIHRvIGNvbW11bmljYXRlIHRvIHRoZSBOQVMsIGFjY2Vz cyBuZXR3b3JrIHRvcG9sb2d5IA0KICAgICAgICBpbmZvcm1hdGlvbiBhbmQgYW55IGNvcnJlc3Bv bmRpbmcgdXBkYXRlcy4gIA0KDQogICAgICAgIFNvbWUgb2YgdGhlIHBhcmFtZXRlcnMgdGhhdCBj YW4gYmUgY29tbXVuaWNhdGVkIGZyb20gdGhlIERTTEFNIHRvIHRoZSANCiAgICAgICAgTkFTIGlu Y2x1ZGUgRFNMIGxpbmUgc3RhdGUsIGFjdHVhbCB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBkYXRh IHJhdGVzIA0KICAgICAgICBvZiBhIHN5bmNocm9uaXplZCBEU0wgbGluaywgbWF4aW11bSBhdHRh aW5hYmxlIHVwc3RyZWFtIGFuZCANCiAgICAgICAgZG93bnN0cmVhbSBkYXRhIHJhdGVzLCBpbnRl cmxlYXZpbmcgZGVsYXkgZXRjLiBUb3BvbG9neSBkaXNjb3ZlcnkgaXMgDQogICAgICAgIHNwZWNp ZmljYWxseSBpbXBvcnRhbnQgaW4gY2FzZSB0aGUgbmV0IGRhdGEgcmF0ZSBvZiB0aGUgRFNMIGxp bmUgDQogICAgICAgIGNoYW5nZXMgb3ZlciB0aW1lLiBUaGUgRFNMIG5ldCBkYXRhIHJhdGUgbWF5 IGJlIGRpZmZlcmVudCBldmVyeSB0aW1lIA0KICAgICAgICB0aGUgRFNMIG1vZGVtIGlzIHR1cm5l ZCBvbi4gQWRkaXRpb25hbGx5LCBkdXJpbmcgdGhlIHRpbWUgdGhlIERTTCANCiAgICAgICAgbW9k ZW0gaXMgYWN0aXZlLCBkYXRhIHJhdGUgY2hhbmdlcyBjYW4gb2NjdXIgZHVlIHRvIGVudmlyb25t ZW50YWwgDQogICAgICAgIGNvbmRpdGlvbnMgKHRoZSBEU0wgbGluZSBjYW4gZ2V0ICJvdXQgb2Yg c3luYyIgYW5kIGNhbiByZXRyYWluIHRvIGEgDQogICAgICAgIGxvd2VyIHZhbHVlLiAgDQoNCiAg ICAgNC4yLjIgTWVzc2FnZSBGbG93ICANCg0KICAgICBXaGVuIGEgRFNMIGxpbmUgaW5pdGlhbGx5 IGNvbWVzIHVwIG9yIHJlc3luY2hyb25pemVzIHRvIGEgZGlmZmVyZW50IA0KICAgICByYXRlLCB0 aGUgRFNMQU0gZ2VuZXJhdGVzIGFuZCB0cmFuc21pdHMgYSBHU01QIFBPUlQgVVAgRVZFTlQgbWVz c2FnZSB0byAgICAgDQogICAgIHRoZSBOQVMuIFRoZSBleHRlbnNpb24gZmllbGQgaW4gdGhlIG1l c3NhZ2UgY2FycmllcyB0aGUgVExWcyBjb250YWluaW5nIA0KICAgICBEU0wgbGluZSBzcGVjaWZp YyBwYXJhbWV0ZXJzLiBPbiBhIGxvc3Mgb2Ygc2lnbmFsIG9uIHRoZSBEU0wgbGluZSwgYSAgICAN CiAgICAgR1NNUCBQT1JUIERPV04gbWVzc2FnZSBpcyBnZW5lcmF0ZWQgYnkgdGhlIERTTEFNIHRv IHRoZSBOQVMuIEluIG9yZGVyIHRvIA0KICAgICBwcm92aWRlIGV4cGVjdGVkIHNlcnZpY2UgbGV2 ZWwsIE5BUyBuZWVkcyB0byBsZWFybiB0aGUgaW5pdGlhbCAgICAgDQogICAgIGF0dHJpYnV0ZXMg b2YgdGhlIERTTCBsaW5lIGJlZm9yZSB0aGUgc3Vic2NyaWJlciBjYW4gbG9nIGluIGFuZCBhY2Nl c3MgDQogICAgIHRoZSBwcm92aXNpb25lZCBzZXJ2aWNlcyBmb3IgdGhlIHN1YnNjcmliZXIuICAg DQoNCiAgICAgICAgIA0KDQoNCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA4 XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNw LXByb3RvY29sLTAwICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAgICAgIA0KDQogICAgICAgICAg ICAgICAgIDwtLS0tLSBQb3J0IFVQKEVWRU5UIE1lc3NhZ2UpICA8LS0tLS0gRFNMICANCiAgICAg ICAgICAgICAgICAgICAgICAoZGVmYXVsdCBsaW5lIHBhcmFtZXRlcnMpICAgICAgIFNpZ25hbCAN CiAgICAgICAgIA0KICAgICAgICAxLiAgTkFTIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIERTTEFN IC0tLS0tLS0tLS0tIFJvdXRpbmcgLS0tLS0gU3Vic2NyaWJlciANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdhdGV3YXkgICAgICAg ICAgICANCiAgICAgICAgIA0KICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIDwtLS0tLSBQ b3J0IFVQIChFVkVOVCBNZXNzYWdlKSAgPC0tLS0tIERTTCAgDQogICAgICAgICAgICAgICAgICAg ICAgICh1cGRhdGVkIGxpbmUgcGFyYW1ldGVycykgICAgICAgUmVzeW5jaCANCiAgICAgICAgIDIu ICBOQVMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gRFNMQU0gLS0tLS0tLS0tLS0gUm91dGluZyAt LS0tLS0gU3Vic2NyaWJlciANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEdhdGV3YXkgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCiAgICAgICAgICAgICAgICA8LS0tIFBv cnQgRE9XTiAoRVZFTlQgTWVzc2FnZSkgPC0tLS0gRFNMICANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExvc3Mgb2YgU2lnbmFsICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgIDMu ICBOQVMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBEU0xBTSAtLS0tLS0tLS0tLS0tIFJvdXRpbmcg LS0tLS0gU3Vic2NyaWJlciAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdhdGV3YXkgDQoNCiAgICAgICAg ICAgICAgICBGaWcgMi4gTWVzc2FnZSBmbG93IChBTkNQIG1hcHBpbmcpIGZvciB0b3BvbG9neSBk aXNjb3ZlcnkgICAgICANCiAgICAgICAgIA0KDQogICAgICAgICANCg0KICAgICAgICBUaGUgRXZl bnQgbWVzc2FnZSB3aXRoIFBPUlQgVVAgbWVzc2FnZSB0eXBlICg4MCkgaXMgdXNlZCBmb3IgDQog ICAgICAgIGNvbnZleWluZyBEU0wgbGluZSBhdHRyaWJ1dGVzIHRvIHRoZSBOQVMuIFRoaXMgbWVz c2FnZSB3aXRoIHJlbGV2YW50IA0KICAgICAgICBleHRlbnNpb25zIGlzIGRlZmluZWQgaW4gc2Vj dGlvbiA1LjQuMi4gICAgDQoNCiAgICAgICAgICAgICANCg0KICAgICA0LjMgQU5DUCBiYXNlZCBM aW5lIENvbmZpZ3VyYXRpb24gDQoNCiAgICAgNC4zLjEgR29hbHMgDQoNCiAgICAgICAgRm9sbG93 aW5nIGR5bmFtaWMgZGlzY292ZXJ5IG9mIGFjY2VzcyB0b3BvbG9neSAoaWRlbnRpZmljYXRpb24g b2YgRFNMIA0KICAgICAgICBsaW5lIGFuZCBpdHMgYXR0cmlidXRlcykgYXMgYXNzaXN0ZWQgYnkg dGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgICAgaW4gDQogICAgICAgIHRoZSBwcmV2aW91cyBzZWN0 aW9uICh0b3BvbG9neSBkaXNjb3ZlcnkpLCB0aGUgTkFTIGNvdWxkIHRoZW4gcXVlcnkgYSANCiAg ICAgICAgc3Vic2NyaWJlciBtYW5hZ2VtZW50IE9TUyBzeXN0ZW0gKGUuZy4gUkFESVVTIHNlcnZl cikgdG8gICAgIHJldHJpZXZlIA0KICAgICAgICBzdWJzY3JpYmVyIGF1dGhvcml6YXRpb24gZGF0 YSAoc2VydmljZSBwcm9maWxlcywgYWthIHVzZXIgDQogICAgICAgIGVudGl0bGVtZW50KS4gTW9z dCBvZiBzdWNoIHNlcnZpY2UgbWVjaGFuaXNtcyBhcmUgdHlwaWNhbGx5IGVuZm9yY2VkICAgICAN CiAgICAgICAgYnkgdGhlIE5BUyBpdHNlbGYsIGJ1dCB0aGVyZSBhcmUgYSBmZXcgY2FzZXMgd2hl cmUgaXQgbWlnaHQgYmUgdXNlZnVsIA0KICAgICAgICB0byBwdXNoIHN1Y2ggc2VydmljZSBwYXJh bWV0ZXIgdG8gdGhlIERTTEFNIGZvciBsb2NhbCBlbmZvcmNlbWVudCBvZiANCiAgICAgICAgYSBt ZWNoYW5pc20gKGUuZy4gRFNMLXJlbGF0ZWQpIG9uIHRoZSBjb3JyZXNwb25kaW5nIHN1YnNjcmli ZXIgbGluZS4gDQogICAgICAgIE9uZSBzdWNoIGV4YW1wbGUgb2YgYSBzZXJ2aWNlIHBhcmFtZXRl ciB0aGF0IGNhbiBiZSBwdXNoZWQgdG8gdGhlIA0KICAgICAgICBEU0xBTSBmb3IgbG9jYWwgZW5m b3JjZW1lbnQgaXMgRFNMICJpbnRlcmxlYXZpbmcgZGVsYXkiLiBMb25nZXIgDQogICAgICAgIGlu dGVybGVhdmluZyBkZWxheSAoYW5kIGhlbmNlIHN0cmluZ2VudCBlcnJvciBjb3JyZWN0aW9uKSBp cyByZXF1aXJlZCANCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KICAgICAg ICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wt MDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgICAgZm9yIGEgdmlkZW8g c2VydmljZSB0byBlbnN1cmUgYmV0dGVyIHZpZGVvICJxdWFsaXR5IG9mIGV4cGVyaWVuY2UiLCAN CiAgICAgICAgd2hlcmVhcyBmb3IgYSBWb0lQIHNlcnZpY2Ugb3IgZm9yICJzaG9vdCBmaXJzdCIg Z2FtaW5nIHNlcnZpY2UsIGEgDQogICAgICAgIHZlcnkgc2hvcnQgaW50ZXJsZWF2aW5nIGRlbGF5 IGlzIG1vcmUgYXBwcm9wcmlhdGUuIEFub3RoZXIgcmVsZXZhbnQgDQogICAgICAgIGFwcGxpY2F0 aW9uIGlzIGRvd25sb2FkaW5nIHBlciBzdWJzY3JpYmVyIG11bHRpY2FzdCBjaGFubmVsIA0KICAg ICAgICBlbnRpdGxlbWVudCBpbmZvcm1hdGlvbiBpbiBJUFRWIGFwcGxpY2F0aW9ucyB3aGVyZSB0 aGUgRFNMQU0gaXMgDQogICAgICAgIHBlcmZvcm1pbmcgSUdNUCBzbm9vcGluZyBvciBJR01QIHBy b3h5IGZ1bmN0aW9uLiBVc2luZyBBTkNQLCB0aGUgTkFTIA0KICAgICAgICBjb3VsZCBhY2hpZXZl IHRoZSBnb2FsIG9mIHB1c2hpbmcgbGluZSBjb25maWd1cmF0aW9uIHRvIHRoZSBEU0xBTSBieSAN CiAgICAgICAgYW4gaW50ZXJvcGVyYWJsZSBhbmQgc3RhbmRhcmRpemVkIHByb3RvY29sLiAgDQoN CiAgICAgICAgSWYgYSBzdWJzY3JpYmVyIHdhbnRzIHRvIGNob29zZSBhIGRpZmZlcmVudCBzZXJ2 aWNlLCBpdCBjYW4gcmVxdWlyZSANCiAgICAgICAgYW4gT1BFWCBpbnRlbnNpdmUgcmVjb25maWd1 cmF0aW9uIG9mIHRoZSBsaW5lIHZpYSBhIG5ldHdvcmsgb3BlcmF0b3IsIA0KICAgICAgICBwb3Nz aWJseSBpbXBseWluZyBhIGJ1c2luZXNzLXRvLWJ1c2luZXNzIHRyYW5zYWN0aW9uIGJldHdlZW4g YW4gSVNQIA0KICAgICAgICBhbmQgYW4gYWNjZXNzIHByb3ZpZGVyLiBVc2luZyBBTkNQIGZvciBs aW5lIGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgDQogICAgICAgIE5BUyBkcmFtYXRpY2FsbHkgc2lt cGxpZmllcyB0aGUgT1NTIGluZnJhc3RydWN0dXJlIGZvciBzZXJ2aWNlIA0KICAgICAgICBtYW5h Z2VtZW50LCBhbGxvd2luZyBmdWxseSBjZW50cmFsaXplZCBzdWJzY3JpYmVyLXJlbGF0ZWQgc2Vy dmljZSANCiAgICAgICAgZGF0YSAoZS5nLiBSQURJVVMgc2VydmVyIGJhY2stZW5kKSBhbmQgYXZv aWRpbmcgY29tcGxleCBjcm9zcy0NCiAgICAgICAgb3JnYW5pemF0aW9uIEIyQiBpbnRlcmFjdGlv bnMuICANCg0KICAgICAgICBUaGUgYmVzdCB3YXkgdG8gY2hhbmdlIGxpbmUgcGFyYW1ldGVycyB3 b3VsZCBiZSBieSB1c2luZyBwcm9maWxlcy4gDQogICAgICAgIFRoZXNlIHByb2ZpbGVzIChEU0wg cHJvZmlsZXMgZm9yIGRpZmZlcmVudCBzZXJ2aWNlcykgYXJlIHByZS0NCiAgICAgICAgY29uZmln dXJlZCBvbiB0aGUgRFNMQU1zLiBUaGUgTkFTIGNhbiB0aGVuIGluZGljYXRlIGEgcmVmZXJlbmNl IHRvIA0KICAgICAgICB0aGUgcmlnaHQgRFNMIHByb2ZpbGUgdmlhIEFOQ1AuIEFsdGVybmF0aXZl bHksIGRpc2NyZXRlIERTTCANCiAgICAgICAgcGFyYW1ldGVycyBjYW4gYWxzbyBiZSBjb252ZXll ZCBieSB0aGUgTkFTIGluIEFOQ1AuIA0KDQogICAgICAgICANCg0KICAgICA0LjMuMiBNZXNzYWdl IEZsb3cgIA0KDQogICAgIFRyaWdnZXJlZCBieSB0b3BvbG9neSBpbmZvcm1hdGlvbiByZXBvcnRp bmcgYSBuZXcgRFNMIGxpbmUgb3IgdHJpZ2dlcmVkIA0KICAgICBieSBhIHN1YnNlcXVlbnQgdXNl ciBzZXNzaW9uIGVzdGFibGlzaG1lbnQgKFBQUCBvciBESENQKSwgdGhlIE5BUyBtYXkgDQogICAg IHNlbmQgbGluZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIChlLmcuIHJlZmVyZW5jZSB0byBh IERTTCBwcm9maWxlKSB0byANCiAgICAgdGhlIERTTEFNIHVzaW5nIEdTTVAgUG9ydCBNYW5hZ2Vt ZW50IG1lc3NhZ2VzLiBUaGUgTkFTIG1heSBnZXQgc3VjaCBsaW5lIA0KICAgICBjb25maWd1cmF0 aW9uIGRhdGEgZnJvbSBhIHBvbGljeSBzZXJ2ZXIgKGUuZy4gUkFESVVTKS4gRmlndXJlIDMgDQog ICAgIHN1bW1hcml6ZXMgdGhlIGludGVyYWN0aW9uLiAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxMF0gDQogICAgICAgICANCgwg ICAgIEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAg ICAgQXVndXN0IDIwMDcgDQogICAgICAgICANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDEuRFNMIFNpZ25hbCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8LS0tLS0tLS0tLS0gDQogICAgICAgICAgICAgICAgICAgICAgMi4gUG9ydCBVUCAoRVZF TlQgTWVzc2FnZSkgDQogICAgICAgICAgICAgICAgICAgICAgICAgKEFjY2VzcyBUb3BvbG9neSBE aXNjb3ZlcnkpIA0KICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDMuIFBQUC9ESENQIFNlc3Npb24gDQogICAgICAgICAgICAgICAgICAg ICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIA0KICAgICAgIDQuIEF1dGhvcml6YXRpb24gDQogICAgICAgICAmIEF1dGhlbnRpY2F0aW9u IA0KICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICAgICAgICAgICAg IFBvcnQgTWFuYWdlbWVudCBNZXNzYWdlICANCiAgICAgICAgICAgICAgICAgICAgICAgICAoTGlu ZSBDb25maWd1cmF0aW9uKSANCiAgICAgICAgICAgICAgICAgICAgICAgNS4gLS0tLS0tLS0tLS0t LS0tLT4gDQogICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLSsgICAgICAgICArLS0tLS0t LSsgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICANCiAg ICAgfFJhZGl1cy9BQUEgICAgfC0tLS0tLXxOQVMgIHwtLS0tLS0tLS18IERTTEFNIHwtLS0tLS0g fCBSb3V0aW5nICB8LS0tLS0tIHxTdWJzY3JpYmVyIHwgICAgDQogICAgIHxQb2xpY3kgU2VydmVy fCAgICAgICstLS0tLSsgICAgICAgICArLS0tLS0tLSsgICAgICAgfCBHYXRld2F5ICB8ICAgICAg ICstLS0tLS0tLS0tLSsgICAgICAgICAgICANCiAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgIA0KICAgICAg IA0KICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgIEZpZyAzLiBNZXNzYWdlIGZsb3cgLSBB TkNQIG1hcHBpbmcgZm9yIEluaXRpYWwgTGluZSBDb25maWd1cmF0aW9uIA0KICAgICAgICAgDQoN CiAgICAgVGhlIE5BUyBtYXkgdXBkYXRlIHRoZSBsaW5lIGNvbmZpZ3VyYXRpb24gZHVlIHRvIGEg c3Vic2NyaWJlciBzZXJ2aWNlIA0KICAgICBjaGFuZ2UgKGUuZy4gdHJpZ2dlcmVkIGJ5IHRoZSBw b2xpY3kgc2VydmVyKS4gRmlndXJlIDQgc3VtbWFyaXplcyB0aGUgDQogICAgIGludGVyYWN0aW9u IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgICANCiAgICAgIA0K ICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAg ICAgICAgICAgIFtQYWdlIDExXSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAg ICAgZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAwICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAg ICAgIA0KDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEuIFBQUC9ESENQIFNlc3Npb24gDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAyLiBTZXJ2aWNlIE9uIERlbWFuZCANCiAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICAgICAgICAgICB8IFdlYiBw b3J0YWwgIHwgDQogICAgICAgICAgICAgICAgICAgICB8ICBPU1MgZXRjICAgIHwgMy5DaGFuZ2Ug b2YgICA0LlBvcnQgTWFuYWdlbWVudCANCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgfCBBdXRob3JpemF0aW9uICAgTWVzc2FnZSAgDQogICAgICAgICAgICAgICAgICAgICB8IFJh ZGl1cyBBQUEgIHwgLS0tLS0tLS0+ICAgICAoVXBkYXRlZCBMaW5lICANCiAgICAgICAgICAgICAg ICAgICAgIHwgIFBvbGljeSAgICAgfCAgICAgICAgICAgICAgICBDb25maWcgLSBOZXcgUHJvZmls ZSkgDQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgLS0tLS0t LS0tLS0tLS4gIA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICstLS0t LS0rICAgICArLS0tLS0tLSsgICArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0rICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfC0tLS18IE5BUyAgfC0tLS0tfCBE U0xBTSB8LS0tfCBSb3V0aW5nIHwtLXxTdWJzY3JpYmVyfCANCiAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgfCAgICArLS0tLS0tKyAgICAgKy0tLS0tLS0rICAgfCBHYXRld2F5IHwg ICstLS0tLS0tLS0tKyAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgDQogICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgIEZpZyA0LiBNZXNzYWdlIGZsb3cgLSBBTkNQIG1hcHBp bmcgZm9yIFVwZGF0ZWQgTGluZSBDb25maWd1cmF0aW9uIA0KICAgICAgICAgDQogICAgICANCg0K ICAgICAgICBUaGUgZm9ybWF0IG9mIHJlbGV2YW50IGV4dGVuc2lvbnMgdG8gcG9ydCBtYW5hZ2Vt ZW50IG1lc3NhZ2UgaXMgDQogICAgICAgIGRlZmluZWQgaW4gc2VjdGlvbiA1LjQuMy4gVGhlIGxp bmUgY29uZmlndXJhdGlvbiBtb2RlbHMgY291bGQgYmUgDQogICAgICAgIHZpZXdlZCBhcyBhIGZv cm0gb2YgZGVsZWdhdGlvbiBvZiBhdXRob3JpemF0aW9uIGZyb20gdGhlIE5BUyB0byB0aGUgDQog ICAgICAgIERTTEFNLiANCg0KICAgDQoNCiAgICAgNC40IEFOQ1AgYmFzZWQgVHJhbnNhY3Rpb25h bCBNdWx0aWNhc3QgDQoNCiAgICAgICAgVHlwaWNhbCBJUCBtdWx0aWNhc3QgaW4gYWNjZXNzIG5l dHdvcmtzIGludm9sdmVzIHRoZSBOQVMgdGVybWluYXRpbmcgDQogICAgICAgIHVzZXIgcmVxdWVz dHMgZm9yIHJlY2VpdmluZyBtdWx0aWNhc3QgY2hhbm5lbHMgdmlhIElHTVAuIFRoZSBOQVMgDQog ICAgICAgIGF1dGhvcml6ZXMgdGhlIHN1YnNjcmliZXIsIGFuZCBkeW5hbWljYWxseSBkZXRlcm1p bmVzIHRoZSBtdWx0aWNhc3QgDQogICAgICAgIHN1YnNjcmlwdGlvbiByaWdodHMgZm9yIHRoZSBz dWJzY3JpYmVyLiBCYXNlZCBvbiB0aGUgdXNlcidzIA0KICAgICAgICBzdWJzY3JpcHRpb24sIHRo ZSBOQVMgY2FuIHJlcGxpY2F0ZSB0aGUgc2FtZSBtdWx0aWNhc3Qgc3RyZWFtIHRvIA0KICAgICAg ICBtdWx0aXBsZSBzdWJzY3JpYmVycy4gVGhpcyBsZWFkcyB0byBhIHdhc3RlIG9mIGFjY2VzcyBi YW5kd2lkdGggaWYgDQogICAgICAgIG11bHRpcGxlIHN1YnNjcmliZXJzIGFjY2VzcyBuZXR3b3Jr IHNlcnZpY2VzIHZpYSB0aGUgc2FtZSBhY2Nlc3Mtbm9kZSANCiAgICAgICAgKGUuZy4gRFNMQU0p LiBUaGUgYW1vdW50IG9mIG11bHRpY2FzdCByZXBsaWNhdGlvbiBpcyBvZiB0aGUgb3JkZXIgb2Yg DQogICAgICAgIG51bWJlciBvZiBzdWJzY3JpYmVycyByYXRoZXIgdGhhbiB0aGUgbnVtYmVyIG9m IGFjY2Vzcy1ub2Rlcy4gDQoNCiAgICAgICAgSXQgaXMgaWRlYWwgZm9yIE5BUyB0byBzZW5kIGEg c2luZ2xlIGNvcHkgb2YgdGhlIG11bHRpY2FzdCBzdHJlYW0gdG8gDQogICAgICAgIGEgZ2l2ZW4g YWNjZXNzLW5vZGUsIGFuZCBsZXQgdGhlIGFjY2Vzcy1ub2RlIHBlcmZvcm0gbXVsdGljYXN0IA0K ICAgICAgICByZXBsaWNhdGlvbiAgIGJ5IGxheWVyMiBtZWFucyAoZS5nLiBBVE0gcG9pbnQtdG8t bXVsdGlwb2ludCBjZWxsIA0KICAgICAgICByZXBsaWNhdGlvbiBvciBldGhlcm5ldCBkYXRhLWxp bmsgYnJpZGdpbmcpIGZvciBzdWJzY3JpYmVycyBiZWhpbmQgDQogICAgICAgIHRoZSBhY2Nlc3Mt bm9kZS4gSG93ZXZlciwgb3BlcmF0aW9uYWxseSwgTkFTIGlzIHRoZSBpZGVhbCBjaG9pY2UgdG8g DQogICAgICAgIGhhbmRsZSBzdWJzY3JpYmVyIG1hbmFnZW1lbnQgZnVuY3Rpb25zIChhdXRoZW50 aWNhdGlvbiwgDQogICAgICAgIGF1dGhvcml6YXRpb24sIGFjY291bnRpbmcgYW5kIGFkZHJlc3Mg bWFuYWdlbWVudCksIG11bHRpY2FzdCBwb2xpY2llcyANCiAgICAgIA0KICAgICAgDQogICAgIFdh ZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAg ICAgW1BhZ2UgMTJdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFm dC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoN CiAgICAgICAgc3VjaCBhcyBwZXItY2hhbm5lbCBhdXRob3JpemF0aW9uLCBhbmQgY29tcGxleCBt dWx0aWNhc3Qgcm91dGluZyANCiAgICAgICAgcHJvdG9jb2xzLiBUaGVyZWZvcmUsIHNvbWUgbWVh bnMgaXMgbmVlZGVkIGZvciB0aGUgTkFTIHRvIHNldHVwIA0KICAgICAgICBtdWx0aWNhc3QgcmVw bGljYXRpb24gc3RhdGUgaW4gdGhlIGFjY2Vzcy1ub2Rlcy4gSW4gQVRNIGFjY2VzcyANCiAgICAg ICAgbmV0d29ya3MsIEFOQ1AgY2FuIGJlIHVzZWQgYnkgdGhlIE5BUyB0byBzZXR1cCBQMk1QIGNy b3NzLWNvbm5lY3RzIGluIA0KICAgICAgICB0aGUgRFNMQU1zLiBQcm90b2NvbCBzdXBwb3J0IGZv ciB0aGlzIHVzZS1jYXNlIHdpbGwgYmUgcHJvdmlkZWQgaW4gDQogICAgICAgIGZ1dHVyZS4gDQoN CiAgICAgIA0KDQogICAgIDQuNSBBTkNQIGJhc2VkIE9BTSANCg0KICAgICAgICBJbiBhIG1peGVk IEV0aGVybmV0IGFuZCBBVE0gYWNjZXNzIG5ldHdvcmsgKGluY2x1ZGluZyB0aGUgbG9jYWwgDQog ICAgICAgIGxvb3ApLCBpdCBpcyBkZXNpcmFibGUgdG8gcHJvdmlkZSBzaW1pbGFyIG1lY2hhbmlz bXMgZm9yIGNvbm5lY3Rpdml0eSANCiAgICAgICAgY2hlY2tzIGFuZCBmYXVsdCBpc29sYXRpb24s IGFzIHRob3NlIHVzZWQgaW4gYW4gQVRNIGJhc2VkIA0KICAgICAgICBhcmNoaXRlY3R1cmUuIFRo aXMgY2FuIGJlIGFjaGlldmVkIHVzaW5nIGFuIEFOQ1AgYmFzZWQgbWVjaGFuaXNtIA0KICAgICAg ICB1bnRpbCBlbmQtdG8tZW5kIEV0aGVybmV0IE9BTSBtZWNoYW5pc21zIGFyZSBtb3JlIHdpZGVs eSBpbXBsZW1lbnRlZCANCiAgICAgICAgaW4gdmFyaW91cyBuZXR3b3JrIGVsZW1lbnRzLiANCg0K ICAgICAgICBBIHNpbXBsZSBzb2x1dGlvbiBiYXNlZCBvbiBBTkNQIGNhbiBwcm92aWRlIE5BUyB3 aXRoIGFuIGFjY2Vzcy1saW5lIA0KICAgICAgICB0ZXN0IGNhcGFiaWxpdHkgYW5kIHRvIHNvbWUg ZXh0ZW50IGZhdWx0IGlzb2xhdGlvbi4gQ29udHJvbGxlZCBieSBhIA0KICAgICAgICBsb2NhbCBt YW5hZ2VtZW50IGludGVyZmFjZSB0aGUgTkFTIGNhbiB1c2UgYW4gQU5DUCBvcGVyYXRpb24gdG8g DQogICAgICAgIHRyaWdnZXIgdGhlIGFjY2Vzcy1ub2RlIHRvIHBlcmZvcm0gYSBsb29wYmFjayB0 ZXN0IG9uIHRoZSBsb2NhbC1sb29wIA0KICAgICAgICAoYmV0d2VlbiB0aGUgYWNjZXNzLW5vZGUg YW5kIHRoZSBDUEUpLiBUaGUgYWNjZXNzLW5vZGUgY2FuIHJlc3BvbmQgDQogICAgICAgIHZpYSBh bm90aGVyIEFOQ1Agb3BlcmF0aW9uIHRoZSByZXN1bHQgb2YgdGhlIHRyaWdnZXJlZCBsb29wYmFj ayB0ZXN0LiANCiAgICAgICAgSW4gY2FzZSBvZiBBVE0gYmFzZWQgbG9jYWwtbG9vcCB0aGUgQU5D UCBvcGVyYXRpb24gY2FuIHRyaWdnZXIgdGhlIA0KICAgICAgICBhY2Nlc3Mtbm9kZSB0byBnZW5l cmF0ZSBBVE0gKEY0L0Y1KSBsb29wYmFjayBjZWxscyBvbiB0aGUgbG9jYWwgbG9vcC4gDQogICAg ICAgIEluIGNhc2Ugb2YgRXRoZXJuZXQsIHRoZSBhY2Nlc3Mtbm9kZSBjYW4gdHJpZ2dlciBhbiBl dGhlcm5ldCBsb29wYmFjayANCiAgICAgICAgbWVzc2FnZShwZXIgRUZNIE9BTSkgb24gdGhlIGxv Y2FsLWxvb3AuIA0KDQogICAgIDQuNS4xIE1lc3NhZ2UgRmxvdyAgDQoNCiAgICAgICAgk1BvcnQg TWFuYWdlbWVudJQgbWVzc2FnZSBjYW4gYmUgdXNlZCBieSB0aGUgTkFTIHRvIHJlcXVlc3QgYWNj ZXNzIA0KICAgICAgICBub2RlIHRvIHRyaWdnZXIgYSCTcmVtb3RlIGxvb3BiYWNrlCB0ZXN0IG9u IHRoZSBsb2NhbCBsb29wLiBUaGUgDQogICAgICAgIHJlc3VsdCBvZiB0aGUgbG9vcGJhY2sgdGVz dCBjYW4gYmUgYXN5bmNocm9ub3VzbHkgY29udmV5ZWQgYnkgdGhlIA0KICAgICAgICBhY2Nlc3Mg bm9kZSB0byB0aGUgTkFTIGluIGEgk1BvcnQgTWFuYWdlbWVudJQgcmVzcG9uc2UgbWVzc2FnZS4g VGhlIA0KICAgICAgICBmb3JtYXQgb2YgcmVsZXZhbnQgZXh0ZW5zaW9ucyB0byBwb3J0IG1hbmFn ZW1lbnQgbWVzc2FnZSBpcyBkZWZpbmVkIA0KICAgICAgICBpbiBzZWN0aW9uIDUuNC40LiANCg0K DQoNCg0KDQoNCg0KDQoNCg0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxM10gDQog ICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90 b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcgDQogICAgICAgICANCg0KICAgICAgDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICBQb3J0IE1hbmFnZW1lbnQgTWVzc2FnZSAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgKFJlbW90ZSBMb29wYmFjayAgICAgICAgICBBVE0gbG9vcGJhY2sgIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICBUcmlnZ2VyIFJlcXVlc3QpICAgICAgICAgT1IgRUZN IExvb3BiYWNrIA0KICAgICAgICAgICAgICAgICAgICAgICAxLiAgLS0tLS0tLS0tLS0tLS0tLT4g ICAgIDIuIC0tLS0tLS0tLS0+IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0rIA0KICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAr LS0tLS0rICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsg ICAgICAgICAgICAgICAgICAgDQogICAgIHxSYWRpdXMvQUFBICAgIHwtLS0tLS18TkFTICB8LS0t LS0tLS0tfCBEU0xBTSB8LS0tLS0tLS0tLS0tLXwgICAgIENQRSAgICAgICAgIHwgICAgICAgDQog ICAgIHxQb2xpY3kgU2VydmVyfCAgICAgICstLS0tLSsgICAgICAgICArLS0tLS0tLSsgICAgICAg ICAgICAgfCAgKERTTCBNb2RlbSArICAgfCAgICAgICAgICAgICAgICAgICANCiAgICAgKy0tLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJv dXRpbmcgR2F0ZXdheSl8ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLSsgDQogICAgICAgICAgICAgICAgICAgICAgICAgMy4gPC0tLS0tLS0tLS0tLS0tLSAgICAg ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIFBvcnQgTWFuYWdlbWVu dCBNZXNzYWdlIA0KICAgICAgICAgICAgICAgICAgICAgICAoUmVtb3RlIExvb3BiYWNrIFRlc3Qg UmVzcG9uc2UpIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICANCiAg ICAgICAgIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICA1ICBBY2Nlc3Mg Tm9kZSBDb250cm9sIFByb3RvY29sIChBTkNQKSANCg0KICAgICA1LjEgQU5DUC9UQ1AgY29ubmVj dGlvbiBlc3RhYmxpc2htZW50IA0KDQogICAgICAgIEFOQ1Agd2lsbCB1c2UgVENQIGZvciBleGNo YW5naW5nIHByb3RvY29sIG1lc3NhZ2VzLiBbNV0gZGVmaW5lcyB0aGUgDQogICAgICAgIEdTTVAg bWVzc2FnZSBlbmNhcHN1bGF0aW9uIGZvciBUQ1AuIFRoZSBUQ1AgICBzZXNzaW9uIGlzIGluaXRp YXRlZCANCiAgICAgICAgZnJvbSB0aGUgRFNMQU0gKGFjY2VzcyBub2RlKSB0byB0aGUgTkFTIChj b250cm9sbGVyKS4gVGhpcyBpcyANCiAgICAgICAgbmVjZXNzYXJ5IHRvIGF2b2lkIHN0YXRpYyBw cm92aXNpb25pbmcgb24gdGhlIE5BUyBmb3IgYWxsIHRoZSBEU0xBTXMgDQogICAgICAgIHRoYXQg YXJlIGJlaW5nIHNlcnZlZCBieSB0aGUgTkFTLiBJdCBpcyBlYXNpZXIgdG8gY29uZmlndXJlIGEg Z2l2ZW4gDQogICAgICAgIERTTEFNIHdpdGggdGhlIHNpbmdsZSBJUCBhZGRyZXNzIG9mIHRoZSBO QVMgdGhhdCBzZXJ2ZXMgdGhlIERTTEFNLiANCiAgICAgICAgVGhpcyBpcyBhIGRldmlhdGlvbiBm cm9tIFs1XSB3aGljaCBpbmRpY2F0ZXMgdGhhdCB0aGUgY29udHJvbGxlciANCiAgICAgICAgaW5p dGlhdGVzIHRoZSBUQ1AgY29ubmVjdGlvbiB0byB0aGUgc3dpdGNoLiANCg0KICAgICAgICBOQVMg bGlzdGVucyBmb3IgaW5jb21pbmcgY29ubmVjdGlvbnMgZnJvbSB0aGUgYWNjZXNzIG5vZGVzLiBQ b3J0IDYwNjggDQogICAgICAgIGlzIHVzZWQgZm9yIFRDUCBjb25uZWN0aW9uLiBBZGphY2VuY3kg cHJvdG9jb2wgbWVzc2FnZXMsIHdoaWNoIGFyZSANCiAgICAgICAgdXNlZCB0byBzeW5jaHJvbml6 ZSB0aGUgTkFTIGFuZCBhY2Nlc3Mtbm9kZXMgYW5kIG1haW50YWluIGhhbmRzaGFrZXMsIA0KICAg ICAgICBhcmUgc2VudCBhZnRlciB0aGUgVENQIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQuIEFO Q1AgbWVzc2FnZXMgb3RoZXIgDQogICAgICAgIHRoYW4gYWRqYWNlbmN5IHByb3RvY29sIG1lc3Nh Z2VzIG1heSBiZSBzZW50IG9ubHkgYWZ0ZXIgdGhlIGFkamFjZW5jeSANCiAgICAgICAgcHJvdG9j b2wgaGFzIGFjaGlldmVkIHN5bmNocm9uaXphdGlvbi4gDQoNCiAgICAgICAgSW4gdGhlIGNhc2Ug b2YgQVRNIGFjY2VzcywgYSBzZXBhcmF0ZSBQVkMgKGNvbnRyb2wgY2hhbm5lbCkgY2FwYWJsZSAN CiAgICAgICAgb2YgdHJhbnNwb3J0aW5nIElQIHdvdWxkIGJlIGNvbmZpZ3VyZWQgYmV0d2VlbiBO QVMgYW5kIHRoZSBEU0xBTSBmb3IgICAgIA0KICAgICAgICBBTkNQIG1lc3NhZ2VzLiAgDQoNCg0K DQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDE0XSANCiAgICAgICAgIA0KDCAgICAg SW50ZXJuZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAwICAgICAgICBB dWd1c3QgMjAwNyANCiAgICAgICAgIA0KDQogICAgIDUuMiBBTkNQIENvbm5lY3Rpb24ga2VlcC1h bGl2ZSANCg0KICAgICAgICBHU01QdjMgZGVmaW5lcyBhbiBhZGphY2VuY3kgcHJvdG9jb2wuICBU aGUgYWRqYWNlbmN5IHByb3RvY29sIGlzIHVzZWQgDQogICAgICAgIHRvIHN5bmNocm9uaXplIHN0 YXRlcyBhY3Jvc3MgdGhlIGxpbmssIHRvIG5lZ290aWF0ZSB3aGljaCB2ZXJzaW9uIG9mIA0KICAg ICAgICB0aGUgR1NNUCBwcm90b2NvbCB0byB1c2UsIHRvIGRpc2NvdmVyIHRoZSBpZGVudGl0eSBv ZiB0aGUgZW50aXR5IGF0IA0KICAgICAgICB0aGUgb3RoZXIgZW5kIG9mIGEgbGluaywgYW5kIHRv IGRldGVjdCB3aGVuIGl0IGNoYW5nZXMuIEdTTVAgaXMgYSANCiAgICAgICAgaGFyZCAgICAgc3Rh dGUgcHJvdG9jb2wuICBJdCBpcyB0aGVyZWZvcmUgaW1wb3J0YW50IHRvIGRldGVjdCBsb3NzIG9m IA0KICAgICAgICBjb250YWN0IGJldHdlZW4gc3dpdGNoIGFuZCBjb250cm9sbGVyLCBhbmQgdG8g ZGV0ZWN0IGFueSBjaGFuZ2Ugb2YgDQogICAgICAgIGlkZW50aXR5ICAgIG9mIHN3aXRjaCBvciBj b250cm9sbGVyLiBObyBwcm90b2NvbCBtZXNzYWdlcyBvdGhlciB0aGFuIA0KICAgICAgICB0aG9z ZSBvZiB0aGUgYWRqYWNlbmN5IHByb3RvY29sIG1heSBiZSBzZW50IGFjcm9zcyB0aGUgbGluayB1 bnRpbCB0aGUgDQogICAgICAgIGFkamFjZW5jeSBwcm90b2NvbCBoYXMgYWNoaWV2ZWQgc3luY2hy b25pemF0aW9uLiBUaGVyZSBhcmUgbm8gY2hhbmdlcyANCiAgICAgICAgdG8gdGhlIGJhc2UgR1NN UCBhZGphY2VuY3kgcHJvdG9jb2wgZm9yIGltcGxlbWVudGluZyBBTkNQLiANCg0KICAgICAgICBU aGUgTkFTIHdpbGwgc2V0IHRoZSBNLWZsYWcgaW4gdGhlIFNZTiBtZXNzYWdlIChzaWduaWZ5aW5n IGl0IGlzIHRoZSANCiAgICAgICAgbWFzdGVyKS4gT25jZSB0aGUgYWRqYWNlbmN5IGlzIGVzdGFi bGlzaGVkLCBwZXJpb2RpYyBhZGphY2VuY3kgDQogICAgICAgIG1lc3NhZ2VzICAgICAodHlwZSBB Q0spIGFyZSBleGNoYW5nZWQuIFRoZSBkZWZhdWx0IEFDSyBpbnRlcnZhbCBhcyANCiAgICAgICAg YWR2ZXJ0aXNlZCBpbiB0aGUgYWRqYWNlbmN5IG1lc3NhZ2VzIGlzIDEwIHNlYyBmb3IgQU5DUC4g SXQgU0hPVUxEIGJlIA0KICAgICAgICBjb25maWd1cmFibGUgYW5kIGlzIGFuIGltcGxlbWVudGF0 aW9uIGNob2ljZS4gSXQgaXMgcmVjb21tZW5kZWQgdGhhdCANCiAgICAgICAgYm90aCBlbmRzIHNw ZWNpZnkgdGhlIHNhbWUgdGltZXIgdmFsdWUuIEhvd2V2ZXIsIGl0IGlzIG5vdCBuZWNlc3Nhcnkg DQogICAgICAgIGZvciB0aGUgdGltZXIgdmFsdWVzIHRvIG1hdGNoLiANCg0KICAgICAgICBUaGUg R1NNUCBhZGphY2VuY3kgbWVzc2FnZSBkZWZpbmVkIGluIFs0XSBpcyBleHRlbmRlZCBmb3IgQU5D UCBhbmQgaXMgDQogICAgICAgIHNob3duIGluIHNlY3Rpb24gNS4zIGltbWVkaWF0ZWx5IGZvbGxv d2luZyB0aGlzIHNlY3Rpb24uIFRoZSA4LWJpdCANCiAgICAgICAgk3ZlcnNpb26UIGZpZWxkIGlu IHRoZSBhZGphY2VuY3kgcHJvdG9jb2wgbWVzc2FnZXMgaXMgbW9kaWZpZWQgdG8gDQogICAgICAg IGNhcnJ5IHRoZSB2ZXJzaW9uIGFuZCBzdWItdmVyc2lvbiBvZiB0aGUgR1NNUCBwcm90b2NvbCBm b3IgdmVyc2lvbiANCiAgICAgICAgbmVnb3RpYXRpb24uIEFOQ1AgdXNlcyB2ZXJzaW9uIDMgYW5k IHN1Yi12ZXJzaW9uIDEgb2YgR1NNUCBwcm90b2NvbC4gDQogICAgICAgIFRoZSBzZW1hbnRpY3Mg YW5kIHN1Z2dlc3RlZCB2YWx1ZXMgZm9yIENvZGUsIJNTZW5kZXIgTmFtZZQsIJNSZWNlaXZlciAN CiAgICAgICAgTmFtZZQsIJNTZW5kZXIgSW5zdGFuY2WULCBhbmQgk1JlY2VpdmVyIEluc3RhbmNl lCBmaWVsZHMgYXJlIGFzIA0KICAgICAgICBkZWZpbmVkIGluIFs0XS4gVGhlIJNTZW5kZXIgUG9y dJQsIGFuZCCTUmVjZWl2ZXIgUG9ydJQgc2hvdWxkIGJlIHNldCANCiAgICAgICAgdG8gMCBieSBi b3RoIGVuZHMuIFRoZSBwVHlwZSBmaWVsZCBzaG91bGQgYmUgc2V0IHRvIDAuIFRoZSBwRmxhZyAN CiAgICAgICAgc2hvdWxkIGJlIHNldCB0byAxLiANCg0KICAgICAgICBJZiB0aGUgYWRqYWNlbmN5 IHRpbWVzIG91dCBvbiBlaXRoZXIgZW5kLCBkdWUgdG8gbm90IHJlY2VpdmluZyBhbiANCiAgICAg ICAgYWRqYWNlbmN5IG1lc3NhZ2UgZm9yIGEgZHVyYXRpb24gb2YgKDMgKiBUaW1lciB2YWx1ZSks IHdoZXJlIHRoZSANCiAgICAgICAgdGltZXIgdmFsdWUgaXMgc3BlY2lmaWVkIGluIHRoZSBhZGph Y2VuY3kgbWVzc2FnZSwgYWxsIHRoZSBzdGF0ZSANCiAgICAgICAgcmVjZWl2ZWQgZnJvbSB0aGUg QU5DUCBuZWlnaGJvciBzaG91bGQgYmUgY2xlYW5lZCB1cCwgYW5kIHRoZSBUQ1AgDQogICAgICAg IGNvbm5lY3Rpb24gc2hvdWxkIGJlIGNsb3NlZC4gVGhlIE5BUyB3b3VsZCBjb250aW51ZSB0byBs aXN0ZW4gZm9yIG5ldyANCiAgICAgICAgY29ubmVjdGlvbiByZXF1ZXN0cy4gVGhlIERTTEFNIHdp bGwgdHJ5IHRvIHJlLWVzdGFibGlzaCB0aGUgVENQIA0KICAgICAgICBjb25uZWN0aW9uIGFuZCBi b3RoIHNpZGVzIHdpbGwgYXR0ZW1wdCB0byByZS1lc3RhYmxpc2ggdGhlIGFkamFjZW5jeS4gDQoN CiAgICAgICAgVGhlIGhhbmRsaW5nIGRlZmluZWQgYWJvdmUgd2lsbCBuZWVkIHNvbWUgbW9kaWZp Y2F0aW9ucyB3aGVuIEFOQ1AgDQogICAgICAgIGdyYWNlZnVsIHJlc3RhcnQgcHJvY2VkdXJlcyBh cmUgZGVmaW5lZC4gVGhlc2UgcHJvY2VkdXJlcyB3aWxsIGJlIA0KICAgICAgICBkZWZpbmVkIGlu IGEgc2VwYXJhdGUgZHJhZnQuIA0KDQogICAgICAgICAgDQoNCg0KICAgICAgDQogICAgICANCiAg ICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSAxNV0gDQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAg IGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcgDQogICAgICAg ICANCg0KICAgICA1LjMgQ2FwYWJpbGl0eSBuZWdvdGlhdGlvbiANCg0KICAgICAgICBUaGUgYWRq YWNlbmN5IG1lc3NhZ2UgYXMgZGVmaW5lZCBpbiBbNF0gaXMgZXh0ZW5kZWQgdG8gY2FycnkgDQog ICAgICAgIHRlY2hub2xvZ3kgc3BlY2lmaWMgIkNhcGFiaWxpdHkgVExWcyIuIEJvdGggdGhlIE5B UyBhbmQgdGhlIGFjY2VzcyANCiAgICAgICAgbm9kZSB3aWxsIGFkdmVydGlzZSBzdXBwb3J0ZWQg Y2FwYWJpbGl0aWVzIGluIHRoZSBvcmlnaW5hdGVkIA0KICAgICAgICBhZGphY2VuY3kgbWVzc2Fn ZXMuIElmIGEgcmVjZWl2ZWQgYWRqYWNlbmN5IG1lc3NhZ2UgaW5kaWNhdGVzIGFic2VuY2UgDQog ICAgICAgIG9mIHN1cHBvcnQgZm9yIGEgY2FwYWJpbGl0eSB0aGF0IGlzIHN1cHBvcnRlZCBieSB0 aGUgcmVjZWl2aW5nIA0KICAgICAgICBkZXZpY2UsIGl0IHdpbGwgdHVybiBvZmYgdGhlIGNhcGFi aWxpdHkgbG9jYWxseSBhbmQgd2lsbCBzZW5kIGFuIA0KICAgICAgICB1cGRhdGVkIGFkamFjZW5j eSBtZXNzYWdlIHdpdGggdGhlIGNhcGFiaWxpdHkgdHVybmVkIG9mZiB0byBtYXRjaCB0aGUgDQog ICAgICAgIHJlY2VpdmVkIGNhcGFiaWxpdHkgc2V0LiBUaGlzIHByb2Nlc3Mgd2lsbCBldmVudHVh bGx5IHJlc3VsdCBpbiBib3RoIA0KICAgICAgICBzaWRlcyBhZ3JlZWluZyBvbiB0aGUgbWluaW1h bCBzZXQgb2Ygc3VwcG9ydGVkIGNhcGFiaWxpdGllcy4gVGhlIA0KICAgICAgICBhZGphY2VuY3kg d2lsbCBub3QgY29tZSB1cCB1bmxlc3MgdGhlIGNhcGFiaWxpdGllcyBhZHZlcnRpc2VkIGJ5IHRo ZSANCiAgICAgICAgY29udHJvbGxlciBhbmQgdGhlIGNvbnRyb2xsZWQgZGV2aWNlIG1hdGNoLiAN Cg0KICAgICAgICBBZnRlciBpbml0aWFsIHN5bmNocm9uaXphdGlvbiwgaWYgYXQgYW55dGltZSBh IGNhcGFiaWxpdHkgbWlzbWF0Y2ggaXMgDQogICAgICAgIGRldGVjdGVkLCB0aGUgYWRqYWNlbmN5 IHdpbGwgYmUgYnJvdWdodCBkb3duIChSU1RBQ0sgd2lsbCBiZSANCiAgICAgICAgZ2VuZXJhdGVk IGJ5IHRoZSBkZXZpY2UgZGV0ZWN0aW5nIHRoZSBtaXNtYXRjaCksIGFuZCBzeW5jaHJvbml6YXRp b24gDQogICAgICAgIHdpbGwgYmUgcmUtYXR0ZW1wdGVkLiANCg0KICAgICAgICAgDQoNCiAgICAg ICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMgDQogICAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDQogICAgICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICAgICB8ICAgVmVyIHwgIFN1YiAgfCBNZXNzYWdlIFR5cGUgIHwgICAgIFRpbWVyICAg ICB8TXwgICAgIENvZGUgICAgfCANCiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBOYW1lICAgICAgICAgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAg ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICArIA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIFJl Y2VpdmVyIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBQb3J0ICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBSZWNlaXZlciBQb3J0ICAgICAgICAgICAgICAg ICAgICAgICAgIHwgDQogICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICAgICB8IFBUeXBlIHwg UEZsYWcgfCAgICAgICAgICAgICAgIFNlbmRlciBJbnN0YW5jZSAgICAgICAgICAgICAgICAgfCAN CiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwgUGFydGl0aW9uIElEICB8ICAgICAg ICAgICAgICBSZWNlaXZlciBJbnN0YW5jZSAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyANCiAgICAgICAgICAgfCBUZWNoIFR5cGUgICAgIHwgIyBvZiBUTFZzICAgICB8IFRv dGFsIExlbmd0aCAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgfiAgICAgICAgICAgICAgICAgICBDYXBhYmls aXR5IFRMVnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4gDQogICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAgIA0KICAgICAgDQogICAgICAN CiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAwNyAgICAg ICAgICAgICAgICBbUGFnZSAxNl0gDQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAg ICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcgDQogICAg ICAgICANCg0KICAgICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAgIFRoZSBmb3JtYXQg b2YgY2FwYWJpbGl0eSBUTFYgaXM6IA0KDQogICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICAg ICB8ICAgICBDYXBhYmlsaXR5IFR5cGUgICAgICAgICB8ICAgQ2FwYWJpbGl0eSBMZW5ndGggICAg ICAgICAgICAgfCANCiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0K ICAgICAgICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfiANCiAgICAgICAgICAgfiAgICAgICAgICAgICAgICAgICBDYXBh YmlsaXR5IERhdGEgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4gIA0KICAgICAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyANCiAgICAgICAgIA0KDQogICAgICAgIFRoZSBUZWNoIFR5cGUgZmllbGQgdHlwZSBp bmRpY2F0ZXMgdGhlIHRlY2hub2xvZ3kgdG8gd2hpY2ggdGhlIA0KICAgICAgICBjYXBhYmlsaXR5 IGV4dGVuc2lvbiBhcHBsaWVzLiBGb3IgYWNjZXNzIG5vZGUgY29udHJvbCBpbiBjYXNlIG9mIERT TCANCiAgICAgICAgbmV0d29ya3MsIG5ldyB0eXBlICJEU0wiIGlzIHByb3Bvc2VkLiBUaGUgdmFs dWUgZm9yIHRoaXMgZmllbGQgaXMgDQogICAgICAgIDB4MDUuIFRoaXMgaXMgdGhlIGZpcnN0IGF2 YWlsYWJsZSB2YWx1ZSBpbiB0aGUgcmFuZ2UgdGhhdCBpcyBub3QgDQogICAgICAgIGN1cnJlbnRs eSBhbGxvY2F0ZWQuIEl0IHdpbGwgbmVlZCB0byBiZSByZXNlcnZlZCB3aXRoIElBTkEuIA0KDQog ICAgICAgIENhcGFiaWxpdHkgbGVuZ3RoIGlzIHRoZSBudW1iZXIgb2YgYWN0dWFsIGJ5dGVzIGNv bnRhaW5lZCBpbiB0aGUgDQogICAgICAgIHZhbHVlIHBvcnRpb24gb2YgdGhlIFRMVi4gVGhlIFRM ViBpcyBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4gDQogICAgICAgIFRoZXJlZm9yZSwg YSBUTFYgd2l0aCBubyBkYXRhIHdpbGwgY29udGFpbiBhIHplcm8gaW4gdGhlIGxlbmd0aCBmaWVs ZCANCiAgICAgICAgKGlmIGNhcGFiaWxpdHkgZGF0YSBpcyB0aHJlZSBvY3RldHMsIHRoZSBsZW5n dGggZmllbGQgd2lsbCBjb250YWluIGEgDQogICAgICAgIHRocmVlLCBidXQgdGhlIHNpemUgb2Yg dGhlIGFjdHVhbCBUTFYgaXMgZWlnaHQgb2N0ZXRzKS4gDQoNCiAgICAgICAgQ2FwYWJpbGl0eSBk YXRhIGZpZWxkIGNhbiBiZSBlbXB0eSBpZiB0aGUgY2FwYWJpbGl0eSBpcyBqdXN0IGEgDQogICAg ICAgIGJvb2xlYW4uIEluIGNhc2UgdGhlIGNhcGFiaWxpdHkgaXMgYSBib29sZWFuLCBpdCBpcyBp bmZlcnJlZCBmcm9tIHRoZSANCiAgICAgICAgcHJlc2VuY2Ugb2YgdGhlIFRMViAod2l0aCBubyBk YXRhKS4gQ2FwYWJpbGl0eSBkYXRhIHByb3ZpZGVzIHRoZSANCiAgICAgICAgZmxleGliaWxpdHkg dG8gYWR2ZXJ0aXNlIG1vcmUgdGhhbiBtZXJlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgYSANCiAg ICAgICAgY2FwYWJpbGl0eS4gQ2FwYWJpbGl0eSB0eXBlcyBjYW4gYmUgcmVnaXN0ZXJlZCB3aXRo IElBTkEuIEZvbGxvd2luZyANCiAgICAgICAgY2FwYWJpbGl0aWVzIGFyZSBkZWZpbmVkIGZvciBB TkNQIGFzIGFwcGxpZWQgdG8gRFNMIGFjY2VzczogDQoNCiAgICAgICAgICAxLiBDYXBhYmlsaXR5 IFR5cGUgOiBEeW5hbWljLVRvcG9sb2d5LURpc2NvdmVyeSA9IDB4MDEgDQoNCiAgICAgICAgICAg ICBMZW5ndGggKGluIGJ5dGVzKSA6IDAgDQoNCiAgICAgICAgICAgICBDYXBhYmlsaXR5IERhdGEg OiBOVUxMIA0KDQogICAgICAgICANCg0KICAgICAgICAgIDIuIENhcGFiaWxpdHkgVHlwZSA6IExp bmUtQ29uZmlndXJhdGlvbiA9IDB4MDIgDQoNCiAgICAgICAgICAgICBMZW5ndGggKGluIGJ5dGVz KSA6IDAgDQoNCiAgICAgICAgICAgICBDYXBhYmlsaXR5IERhdGEgOiBOVUxMIA0KICAgICAgDQog ICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSAxN10gDQogICAgICAgICANCgwgICAgIEludGVybmV0LURy YWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcg DQogICAgICAgICANCg0KICAgICAgICAgDQoNCiAgICAgICAgICAzLiBDYXBhYmlsaXR5IFR5cGUg OiBUcmFuc2FjdGlvbmFsLU11bHRpY2FzdCA9IDB4MDMgKGNvbnRyb2xsZXIgDQogICAgICAgICAg ICAgaS5lLiBOQVMgdGVybWluYXRlcyBJR01QIG1lc3NhZ2VzIGZyb20gc3Vic2NyaWJlcnMsIGFu ZCB2aWEgbDIgDQogICAgICAgICAgICAgY29udHJvbCBwcm90b2NvbCwgc2lnbmFscyBzdGF0ZSB0 byB0aGUgYWNjZXNzLW5vZGVzIChlLmcuIA0KICAgICAgICAgICAgIERTTEFNcykgdG8gZW5hYmxl IGxheWVyMiByZXBsaWNhdGlvbiBvZiBtdWx0aWNhc3Qgc3RyZWFtcy4gSW4gDQogICAgICAgICAg ICAgQVRNIGFjY2VzcyBuZXR3b3JrIHRoaXMgaW1wbGllcyB0aGF0IE5BUyBpbnN0cnVjdHMgdGhl IGFjY2Vzcy0NCiAgICAgICAgICAgICBub2RlIHRvIHNldHVwIGEgUDJNUCBjcm9zcy1jb25uZWN0 LiBUaGUgZGV0YWlscyBvZiB0aGlzIHdpbGwgYmUgDQogICAgICAgICAgICAgY292ZXJlZCBpbiBh IHNlcGFyYXRlIElEIFs2XS4gIA0KDQogICAgICAgICAgICAgTGVuZ3RoIChpbiBieXRlcykgOiAw IA0KDQogICAgICAgICAgICAgQ2FwYWJpbGl0eSBEYXRhIDogTlVMTCANCg0KICAgICAgICAgDQoN CiAgICAgICAgICA0LiBDYXBhYmlsaXR5IFR5cGUgOiBPQU0gPSAweDA0ICANCg0KICAgICAgICAg ICAgIExlbmd0aCAoaW4gYnl0ZXMpIDogMCANCg0KICAgICAgICAgICAgIENhcGFiaWxpdHkgRGF0 YSA6IE5VTEwgDQoNCiAgICAgICAgICA1LiBDYXBhYmlsaXR5IFR5cGUgOiBCdWxrIFRyYW5zYWN0 aW9uID0gMHgwNSAoZGVmaW5lZCBpbiBzZWN0aW9uIA0KICAgICAgICAgICAgIDUuNC4xLjIpLiAg DQoNCiAgICAgICAgICAgICBMZW5ndGggKGluIGJ5dGVzKSA6IDAgDQoNCiAgICAgICAgICAgICBD YXBhYmlsaXR5IERhdGEgOiBOVUxMIA0KDQogICAgICAgICANCg0KICAgICA1LjQgR1NNUCBNZXNz YWdlIEV4dGVuc2lvbnMgZm9yIEFjY2VzcyBOb2RlIENvbnRyb2wgDQoNCiAgICAgNS40LjEgR2Vu ZXJhbCBFeHRlbnNpb25zIA0KDQogICAgICAgIEV4dGVuc2lvbnMgdG8gR1NNUCBtZXNzYWdlcyBm b3IgdmFyaW91cyB1c2UtY2FzZXMgb2Ygk0FjZXNzIE5vZGUgDQogICAgICAgIENvbnRyb2yUIG1l Y2hhbmlzbSBhcmUgZGVmaW5lZCBpbiBzZWN0aW9ucyA1LjQuMiB0byA1LjQuNC4gSG93ZXZlciwg DQogICAgICAgIHN1Yi1zZWN0aW9ucyA1LjQuMS4xIGFuZCA1LjQuMS4yIGJlbG93IGRlZmluZSBl eHRlbnNpb25zIHRvIEdTTVAgdGhhdCANCiAgICAgICAgaGF2ZSBnZW5lcmFsIGFwcGxpY2FiaWxp dHkuICAgICANCg0KICAgICA1LjQuMS4xICBFeHRlbnNpb24gVExWIA0KDQogICAgICAgIEluIG9y ZGVyIHRvIHByb3ZpZGUgZmxleGliaWxpdHkgYW5kIGV4dGVuc2liaWxpdHkgY2VydGFpbiBHU01Q IA0KICAgICAgICBtZXNzYWdlcyBzdWNoIGFzIJNQT1JUIE1BTkFHRU1FTlSUIGFuZCCTRVZFTlSU IG1lc3NhZ2VzIGRlZmluZWQgaW4gDQogICAgICAgIFs0XSBoYXZlIGJlZW4gbW9kaWZpZWQgdG8g aW5jbHVkZSBhbiBleHRlbnNpb24gYmxvY2sgdGhhdCBmb2xsb3dzIGEgDQogICAgICAgIFRMViBz dHJ1Y3R1cmUuIEluZGl2aWR1YWwgbWVzc2FnZXMgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBk ZXNjcmliZSANCiAgICAgICAgdGhlIHVzYWdlIGFuZCBmb3JtYXQgb2YgdGhlIGV4dGVuc2lvbiBi bG9jay4gDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDE4XSANCiAgICAgICAgIA0K DCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAwICAg ICAgICBBdWd1c3QgMjAwNyANCiAgICAgICAgIA0KDQogICAgICANCiAgICAgICAgIA0KICAgICAg DQogICAgICANCiAgICAgIA0KICAgICAgDQogICAgICAgICAgIEFsbCBFeHRlbnNpb24gVExWJ3Mg d2lsbCBiZSBkZXNpZ25hdGVkIGFzIGZvbGxvdzogDQoNCiAgICAgICAgIA0KICAgICAgICAgICAg MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMyANCiAgICAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANCiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAg ICAgIHx4fHh8eHx4fHh8eHx4fHh8IE1lc3NhZ2UgVHlwZSAgfCAgIFRlY2ggVHlwZSAgIHwgQmxv Y2sgTGVuZ3RoICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg DQogICAgICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgRXh0ZW5zaW9uIFZhbHVlICAg ICAgICAgICAgICAgICAgICAgICB+IA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgDQogICAgICAgICANCiAgICAgICAgIA0KDQogICAgICAgICAgIHg6IFJlc2VydmVk IEZsYWdzIA0KDQogICAgICAgICAgICAgIFRoZXNlIGFyZSBnZW5lcmFsbHkgdXNlZCBieSBzcGVj aWZpYyBtZXNzYWdlcyBhbmQgd2lsbCBiZSANCiAgICAgICAgICAgICAgZGVmaW5lZCBpbiB0aG9z ZSBtZXNzYWdlcy4gDQoNCiAgICAgICAgICAgTWVzc2FnZSBUeXBlIA0KDQogICAgICAgICAgICAg IEFuIDgtYml0IGZpZWxkIGNvcnJlc3BvbmRpbmcgdG8gdGhlIG1lc3NhZ2UgdHlwZSB3aGVyZSB0 aGUgICANCiAgICAgICAgICAgICAgZXh0ZW5zaW9uIGJsb2NrIGlzIHVzZWQuIA0KDQogICAgICAg ICAgIFRlY2ggVHlwZSANCg0KICAgICAgICAgICAgICBBbiA4LWJpdCBmaWVsZCBpbmRpY2F0aW5n IHRoZSBhcHBsaWNhYmxlIHRlY2hub2xvZ3kgdHlwZSB2YWx1ZS4gICAgICANCiAgICAgICAgICAg ICAgVGhlIE1lc3NhZ2UgVHlwZSBwbHVzIHRoZSBUZWNoIFZhbHVlIHVuaXF1ZWx5IGRlZmluZSBh IHNpbmdsZSAgICANCiAgICAgICAgICAgICAgRXh0ZW5zaW9uIFR5cGUgYW5kIGNhbiBiZSB0cmVh dGVkIGFzIGEgc2luZ2xlIDE2IGJpdCBleHRlbnNpb24gDQogICAgICAgICAgICAgIHR5cGUuIJNU ZWNoIFR5cGWUIHZhbHVlIG9mIDB4MDUgU0hPVUxEIGJlIHVzZWQgYnkgQU5DUCBmb3IgRFNMIA0K ICAgICAgICAgICAgICB0ZWNobm9sb2d5LiANCg0KICAgICAgICAgICAgICAweDAwICAgICAgICAg IEV4dGVuc2lvbiBibG9jayBub3QgaXQgdXNlLiANCg0KICAgICAgICAgICAgICAweDAxIJYgMHgw NCAgIEFscmVhZHkgaW4gdXNlIGJ5IHZhcmlvdXMgdGVjaG5vbG9naWVzIA0KDQogICAgICAgICAg ICAgIDB4MDUgICAgICAgICAgRFNMIA0KDQogICAgICAgICAgICAgIDB4MDYgLSAweEZFICAgUmVz ZXJ2ZWQgDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTldIA0KICAgICAgICAg DQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAg ICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgICAgICAgICAgMHhGRiAgICAg ICAgICBCYXNlIFNwZWNpZmljYXRpb24gVXNlIA0KDQogICAgICAgICAgIEJsb2NrIExlbmd0aCAN Cg0KICAgICAgICAgICAgICBBIDgtYml0IGZpZWxkIGluZGljYXRpbmcgdGhlIGxlbmd0aCBvZiB0 aGUgRXh0ZW5zaW9uIFZhbHVlIA0KICAgICAgICAgICAgICBmaWVsZCBpbiBieXRlcy4gIFdoZW4g dGhlIFRlY2ggVHlwZSA9IDB4MDAsIHRoZSBsZW5ndGggdmFsdWUgDQogICAgICAgICAgICAgIE1V U1QgYmUgc2V0IHRvIDAuIA0KDQogICAgICAgICAgIEV4dGVuc2lvbiBWYWx1ZSANCg0KICAgICAg ICAgICAgICBBIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCB0aGF0IGlzIGFuIGludGVnZXIgbnVtYmVy IG9mIDMyIGJpdCANCiAgICAgICAgICAgICAgd29yZHMgbG9uZy4gIFRoZSBFeHRlbnNpb24gVmFs dWUgZmllbGQgaXMgaW50ZXJwcmV0ZWQgYWNjb3JkaW5nIA0KICAgICAgICAgICAgICB0byB0aGUg c3BlY2lmaWMgZGVmaW5pdGlvbnMgcHJvdmlkZWQgYnkgdGhlIG1lc3NhZ2VzIGluIHRoZSANCiAg ICAgICAgICAgICAgZm9sbG93aW5nIHNlY3Rpb25zLiANCg0KICAgICA1LjQuMS4yICBCdWxrIFRy YW5zYWN0aW9uIE1lc3NhZ2UgDQoNCiAgICAgICAgQU5DUCBlbGVtZW50cyBNQVkgc3VwcG9ydCBh IGJ1bGsgdHJhbnNhY3Rpb24gY2FwYWJpbGl0eS4gIFRoaXMgDQogICAgICAgIGNhcGFiaWxpdHkg aXMgbmVnb3RpYXRlZCBkdXJpbmcgYWRqYWNlbmN5IHN5bmNocm9uaXphdGlvbiBhbmQgZm9sbG93 cyANCiAgICAgICAgZ2VuZXJhbCBBTkNQIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gcnVsZXMuICAN Cg0KICAgICAgICBJbiBhIGJ1bGsgdHJhbnNhY3Rpb24sIHNldmVyYWwgbWVzc2FnZXMgY2FuIGJl IGJ1bmRsZWQgdG9nZXRoZXIgaW4gYSANCiAgICAgICAgc2luZ2xlIHRyYW5zYWN0aW9uLiBCdWxr IHRyYW5zYWN0aW9uIHVzZXMgbWVzc2FnZSB0eXBlIDEzLiBSZWNlcHRpb24gDQogICAgICAgIG9m IJNCdWxrIFRyYW5zYWN0aW9uIE1lc3NhZ2WUIGJ5IGEgbm9kZSB0aGF0IGhhcyBub3QgYWR2ZXJ0 aXNlZCBidWxrIA0KICAgICAgICB0cmFuc2FjdGlvbiBjYXBhYmlsaXR5IE1VU1Qgc2lsZW50bHkg ZGlzY2FyZCB0aGUgcmVjZWl2ZWQgbWVzc2FnZS4gDQoNCiAgICAgICAgVGhlIEJ1bGsgVHJhbnNh Y3Rpb24gbWVzc2FnZSBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6IA0KDQogICAgICANCiAgICAg ICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMgDQogICAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDQogICAgICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICAgICB8IFZlcnMgIHwgIFN1YiAgfCBNZXNzYWdlIFR5cGUgIHwgUmVzdWx0fCAgICAg ICAgQ29kZSAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgIHwg UGFydGl0aW9uIElEICB8ICAgICAgICAgICAgVHJhbnNhY3Rpb24gSWRlbnRpZmllciAgICAgICAg ICAgICB8IA0KICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgICAgfEl8ICAgICAgU3ViTWVz c2FnZSBOdW1iZXIgICAgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwgDQogICAg ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgICAgICB8ICAgICAgICAgICAgICBSZXNlcnZlZCAgICAg ICAgIHwgICAgICAgICAgIENvdW50ICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICB+ICAgICAgICAgICAgICAgICAg ICAgICAgICBNZXNzYWdlIFBheWxvYWQgICAgICAgICAgICAgICAgICAgICAgfiANCiAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgDQogICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICAgDQogICAgICANCg0K ICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAyMF0gDQogICAgICAgICANCgwgICAgIElu dGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAgQXVn dXN0IDIwMDcgDQogICAgICAgICANCg0KICAgICAgICBJbiBhIEJ1bGsgVHJhbnNhY3Rpb24gTWVz c2FnZSwgZWFjaCBvZiB0aGUgbWVzc2FnZSBpbiB0aGUgcGF5bG9hZCBpcyAgIA0KICAgICAgICBm cmFtZWQgd2l0aCBhIGNvbXBsZXRlIGhlYWRlciBhbmQgaXMgYWN0ZWQgb24gaW5kaXZpZHVhbGx5 LiAgVGhlICAgDQogICAgICAgIHJlc3BvbnNlIHRvIHRoZSBCdWxrIFRyYW5zYWN0aW9uIG1lc3Nh Z2UgY29udGFpbnMgdGhlIHJlc3BvbnNlICAgDQogICAgICAgIG1lc3NhZ2UgdGhhdCB3b3VsZCBo YXZlIGJlZW4gZ2VuZXJhdGVkIGJ5IGVhY2ggb2YgdGhlIG1lc3NhZ2VzIGhhZCBpdCANCiAgICAg ICAgYmVlbiBzZW50IGluZGl2aWR1YWxseS4gRWFjaCByZXNwb25zZSBtZXNzYWdlIHdpbGwgaGF2 ZSB0aGUgDQogICAgICAgIGFwcHJvcHJpYXRlIHJlc3VsdCBhbmQgY29kZSBmaWVsZCBmaWxsZWQu IEFueSBtZXNzYWdlIGNhbiBiZSBpbmNsdWRlZCANCiAgICAgICAgaW4gdGhlIGJ1bGsgVHJhbnNh Y3Rpb24gbWVzc2FnZSBleGNlcHQgZm9yIGFkamFjZW5jeSBtZXNzYWdlIGFuZCANCiAgICAgICAg YW5vdGhlciBidWxrIHRyYW5zYWN0aW9uIG1lc3NhZ2UuIElmIGEgcHJvaGliaXRlZCBtZXNzYWdl IGlzIGluY2x1ZGVkIA0KICAgICAgICBpbiBhIGJ1bGsgVHJhbnNhY3Rpb24gbWVzc2FnZSwgaXQg TVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgQnVsayANCiAgICAgICAgcmVzcG9uc2Ugd2l0aCBhIGZh aWx1cmUgcmVzcG9uc2UuIFRoZSByZXNwb25zZSBjb2RlIGZvciB0aGF0IGZhaWx1cmUgDQogICAg ICAgIGlzIDB4ODEgKJNNZXNzYWdlIHR5cGUgcHJvaGliaXRlZCBpbiBidWxrIFRyYW5zYWN0aW9u lCkuIFdoaWxlIHRoZSANCiAgICAgICAgaW5kaXZpZHVhbCBtZXNzYWdlIHdvdWxkIGZhaWwsIHRo aXMgd291bGQgbm90ICAgY29uc3RpdHV0ZSBhIGZhaWx1cmUgDQogICAgICAgIGZvciB0aGUgQnVs ayBUcmFuc2FjdGlvbiBtZXNzYWdlIA0KDQogICAgIDUuNC4yIFRvcG9sb2d5IERpc2NvdmVyeSBF eHRlbnNpb25zIA0KDQogICAgIFRoZSBHU01QIEV2ZW50IG1lc3NhZ2Ugd2l0aCBQT1JUIFVQIG1l c3NhZ2UgdHlwZSAoODApIGlzIHVzZWQgZm9yIA0KICAgICBjb252ZXlpbmcgRFNMIGxpbmUgYXR0 cmlidXRlcyB0byB0aGUgTkFTLiBUaGUgdmVyc2lvbiBmaWVsZCBzaG91bGQgYmUgDQogICAgIHNl dCB0byAzLCBhbmQgdGhlIHN1YiBmaWVsZCBzaG91bGQgYmUgc2V0IHRvIDEuIFRoZSBJIGFuZCBz dWJNZXNzYWdlIA0KICAgICBmaWVsZHMgU0hPVUxEIGJlIHNldCB0byAxIHRvIHNpZ25pZnkgbm8g ZnJhZ21lbnRhdGlvbi4gVGhlIFBvcnQgYW5kIA0KICAgICBMYWJlbCBmaWVsZHMgc2hvdWxkIGJl IHNldCB0byAwLiBUaGUgk1BvcnQgU2Vzc2lvbiBOdW1iZXKUIHNob3VsZCBiZSBzZXQgDQogICAg IHRvIDAsIGFuZCB0aGUgk0V2ZW50IFNlcXVlbmNlIE51bWJlcpQgc2hvdWxkIGJlIDAuIFRoZSBU ZWNoIFR5cGUgZmllbGQgDQogICAgIGlzIGV4dGVuZGVkIHdpdGggbmV3IHR5cGUgIkRTTCIuIFRo ZSB2YWx1ZSBmb3IgdGhpcyBmaWVsZCBpcyAweDA1LiBUaGUgDQogICAgIG1lc3NhZ2UgU0hPVUxE IGJlIGdlbmVyYXRlZCB3aGVuIGEgbGluZSBmaXJzdCBjb21lcyBVUCwgb3IgYW55IG9mIHRoZSAN CiAgICAgYXR0cmlidXRlcyBvZiB0aGUgbGluZSBjaGFuZ2UgZS5nLiB0aGUgbGluZSByZS10cmFp bnMgdG8gYSBkaWZmZXJlbnQgDQogICAgIHJhdGUgb3Igb25lIG9yIG1vcmUgb2YgdGhlIGNvbmZp Z3VyZWQgbGluZSBhdHRyaWJ1dGVzIGFyZSANCiAgICAgYWRtaW5pc3RyYXRpdmVseSBtb2RpZmll ZC4gQWxzbywgd2hlbiB0aGUgQU5DUCBzZXNzaW9uIGZpcnN0IGNvbWVzIHVwLCANCiAgICAgdGhl IERTTFNNIFNIT1VMRCB0cmFuc21pdCBhIFBPUlQgVVAgbWVzc2FnZSB0byB0aGUgTkFTIGZvciBl YWNoIGxpbmUgDQogICAgIHRoYXQgaXMgdXAuIEEgRFNMQU0gTUFZIHVzZSBhIEJ1bGsgVHJhbnNh Y3Rpb24gbWVzc2FnZSBhcyBkZWZpbmVkIGluIA0KICAgICA1LjQuMS4yIHRvIGFnZ3JlZ2F0ZSB0 aGUgdHJhbnNtaXNzaW9uIG9mIFBPUlQgVVAgbWVzc2FnZXMuIA0KDQogICAgIFdoZW4gYSBEU0wg bGluZSBnb2VzIGRvd24gKGlkbGUgb3Igc2lsZW50KSwgdGhlIERTTEFNIFNIT1VMRCB0cmFuc21p dCBhbiANCiAgICAgRXZlbnQgbWVzc2FnZSB3aXRoIFBPUlQgRE9XTiBtZXNzYWdlIHR5cGUgKDgx KSB0byB0aGUgTkFTLiBJdCBpcyANCiAgICAgcmVjb21tZW5kZWQgdGhhdCB0aGUgRFNMQU1zIHVz ZSBhIGRhbXBlbmluZyBtZWNoYW5pc20gcGVyIERTTCBsaW5lIHRvIA0KICAgICBjb250cm9sIHRo ZSByYXRlIG9mIHN0YXRlIGNoYW5nZXMgcGVyIERTTCBsaW5lLCBjb21tdW5pY2F0ZWQgdG8gdGhl IE5BUy4gIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICAgDQogICAgICANCiAgICAgV2Fk aHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAg ICBbUGFnZSAyMV0gDQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0 LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcgDQogICAgICAgICANCg0K ICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMyANCiAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANCiAgICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAg ICAgIHwgVmVycyAgfCAgU3ViICB8IE1lc3NhZ2UgVHlwZSAgfCBSZXN1bHR8ICAgICAgICBDb2Rl ICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCBQYXJ0aXRpb24gSUQg IHwgICAgICAgICAgICBUcmFuc2FjdGlvbiBJZGVudGlmaWVyICAgICAgICAgICAgIHwgICAgIA0K ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfEl8ICAgICAgU3ViTWVzc2FnZSBOdW1iZXIgICAg ICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQb3J0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgUG9ydCBTZXNzaW9uIE51bWJlciAgICAgICAgICAgICAgICAgICAgICB8IA0K ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIEV2ZW50IFNl cXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICB8eHxTfHh8eHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAg TGFiZWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgIH4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+IA0K ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfHh8eHx4fHh8eHx4fHh8eHwgTWVzc2FnZSBUeXBl ICB8ICAgVGVjaCBUeXBlICAgfCBCbG9jayBMZW5ndGggIHwgDQogICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICBFeHRl bnNpb24gVmFsdWUgICAgICAgICAgICAgICAgICAgICAgIH4gDQogICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0K ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgIFRoZSBmb3Jt YXQgb2YgdGhlICJFeHRlbnNpb24gVmFsdWUiIGZpZWxkIGZvciBUZWNoIFR5cGUgk0RTTJQgaXMg IA0KICAgICAgICBhcyBmb2xsb3dzIDogDQogICAgICAgICANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAg ICAgIA0KICAgICAgICB8ICAgICAgICAgICAgICMgb2YgVExWcyAgICAgICAgIHwgRXh0ZW5zaW9u IGJsb2NrIGxlbmd0aCAoYnl0ZXMpfCANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgDQog ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfiANCiAgICAgICAgfiAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRMVnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4gIA0K ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICANCg0KICAgICBUaGUg k0V4dGVuc2lvbiBWYWx1ZZQgY29udGFpbnMgb25lIG9yIG1vcmUgVExWcyB0byBpZGVudGlmeSBh IERTTCBsaW5lIA0KICAgICBhbmQgZGVmaW5lIGl0knMgY2hhcmFjdGVyaXN0aWNzLiBBIFRMViBj YW4gY29uc2lzdCBvZiBtdWx0aXBsZSBzdWItVExWcy4gDQogICAgIEZpcnN0IDIgYnl0ZSBvZiB0 aGUgk0V4dGVuc2lvbiBWYWx1ZZQgY29udGFpbnMgdGhlIG51bWJlciBvZiBUTFZzIHRoYXQgDQog ICAgIGZvbGxvdy4gVGhlIG5leHQgMiBieXRlcyBjb250YWluIHRoZSB0b3RhbCBsZW5ndGggb2Yg dGhlIFRMVnMgY2FycmllZCBpbiANCiAgICAgdGhlIGV4dGVuc2lvbiBibG9jayBpbiBieXRlcyAo ZXhpc3Rpbmcgk0Jsb2NrIExlbmd0aJQgZmllbGQgaW4gdGhlIEdTTVAgDQogICAgIG1lc3NhZ2Ug aXMgbGltaXRlZCB0byAyNTUgYnl0ZXMgYW5kIGlzIG5vdCBzdWZmaWNpZW50KS4gDQoNCiAgICAg IA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjJdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5l dC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAy MDA3IA0KICAgICAgICAgDQoNCiAgICAgIA0KDQogICAgICAgIEdlbmVyYWwgZm9ybWF0IG9mIGEg VExWIGlzIDogIA0KDQogICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDQogICAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAN CiAgICAgICAgfCAgICAgICAgICAgIFR5cGUgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIExl bmd0aCAgICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgIA0KICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCANCiAgICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4gDQogICAgICAgIH4gICAgICAgICAgICAgICAg ICAgICAgICAgICBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+ICANCiAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgDQogICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgICAgDQoNCiAgICAgVGhlIHZh bHVlIGZpZWxkIGluIGVhY2ggVExWIGlzIHBhZGRlZCB0byBhIDQtb2N0ZXQgYWxpZ25tZW50LiBU aGUgTGVuZ3RoIA0KICAgICBmaWVsZCBpbiBlYWNoIFRMViBjb250YWlucyB0aGUgYWN0dWFsIG51 bWJlciBvZiBieXRlcyBpbiB0aGUgVExWIChub3QgDQogICAgIGluY2x1ZGluZyB0aGUgcGFkZGlu ZyBpZiBwcmVzZW50KS4gSWYgYSBUTFYgaXMgbm90IHVuZGVyc3Rvb2QgYnkgdGhlIA0KICAgICBO QVMsIGl0IGlzIHNpbGVudGx5IGlnbm9yZWQuIEN1cnJlbnRseSBkZWZpbmVkIHR5cGVzIHN0YXJ0 IGZyb20gMHgwMS4gDQoNCiAgICAgRm9sbG93aW5nIFRMVnMgYXJlIGN1cnJlbnRseSBkZWZpbmVk OiANCg0KICAgICAgIDEuIFR5cGUgKEFjY2Vzcy1Mb29wLUNpcmN1aXQtSUQgPSAweDAxKTogVGhp cyBpcyBhIG1hbmRhdG9yeSBUTFYgYW5kIA0KICAgICAgICAgIGNvbnRhaW5zIGFuIGlkZW50aWZp ZXIgb2YgdGhlIHN1YnNjcmliZXKScyBjb25uZWN0aW9uIHRvIHRoZSBhY2Nlc3MgDQogICAgICAg ICAgbm9kZSAoaS5lLiAgk2xvY2FsIGxvb3CUKS4gVGhlIJNsb2NhbCBsb29wlCBjYW4gYmUgQVRN IGJhc2VkIG9yIA0KICAgICAgICAgIEV0aGVybmV0IGJhc2VkLiBUaGUgk0FjY2VzcyBMb29wIENp cmN1aXQgSUSUIGhhcyBsb2NhbCBzaWduaWZpY2FuY2UgDQogICAgICAgICAgYXQgdGhlIGFjY2Vz cyBub2RlLiBUaGUgZXhhY3QgdXNhZ2Ugb24gdGhlIE5BUyBpcyBiZXlvbmQgdGhlIHNjb3BlIA0K ICAgICAgICAgIG9mIHRoaXMgZG9jdW1lbnQuIFRoZSBmb3JtYXQgdXNlZCBmb3Igk2xvY2FsIGxv b3CUIGlkZW50aWZpY2F0aW9uIA0KICAgICAgICAgIGluIEFOQ1AgbWVzc2FnZXMgTVVTVCBiZSBp ZGVudGljYWwgdG8gd2hhdCBpcyB1c2VkIGJ5IHRoZSBhY2Nlc3MgDQogICAgICAgICAgbm9kZXMg aW4gc3Vic2NyaWJlciBzaWduYWxpbmcgbWVzc2FnZXMgd2hlbiB0aGUgYWNjZXNzIG5vZGVzIGFj dCBhcyANCiAgICAgICAgICCTc2lnbmFsaW5nIHJlbGF5IGFnZW50c5QgYXMgb3V0bGluZWQgaW4g WzddIGFuZCBbOF0uIA0KDQogICAgICAgICAgTGVuZ3RoIDogKHVwdG8gNjMgYnl0ZXMpICANCg0K ICAgICAgICAgIFZhbHVlIDogQVNDSUkgc3RyaW5nLiAgICAgICAgICAgICAgICAgICAgICAgDQoN CiAgICAgICAgICBGb3IgYW4gQVRNIGJhc2VkIGxvY2FsIGxvb3AgdGhlIHN0cmluZyBjb25zaXN0 cyBvZiBzbG90L3BvcnQgYW5kICAgDQogICAgICAgICAgVlBJL1ZDSSBpbmZvcm1hdGlvbiBjb3Jy ZXNwb25kaW5nIHRvIHRoZSBzdWJzY3JpYmVyknMgRFNMIA0KICAgICAgICAgIGNvbm5lY3Rpb24u IERlZmF1bHQgc3ludGF4IGZvciB0aGUgc3RyaW5nIGluc2VydGVkIGJ5IHRoZSBhY2Nlc3MgDQog ICAgICAgICAgbm9kZSBhcyBwZXIgWzhdIGlzOiANCg0KICAgICAgICAgICCTQWNjZXNzLU5vZGUt SWRlbnRpZmllciBhdG0gc2xvdC9wb3J0OnZwaS52Y2mUICANCg0KICAgICAgICAgIFRoZSBBY2Nl c3MtTm9kZS1JZGVudGlmaWVyIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIGFjY2VzcyBub2RlIGlu IA0KICAgICAgICAgIHRoZSBhY2Nlc3MgbmV0d29yay4gVGhlIHNsb3QvcG9ydCBhbmQgVlBJL1ZD SSB1bmlxdWVseSBpZGVudGlmaWVzIA0KICAgICAgICAgIHRoZSBEU0wgbGluZSBvbiB0aGUgYWNj ZXNzIG5vZGUuIEFsc28sIHRoZXJlIGlzIG9uZSB0byBvbmUgDQoNCiAgICAgIA0KICAgICAgDQog ICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAg ICAgICAgICAgW1BhZ2UgMjNdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAg ICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAg ICAgDQoNCiAgICAgICAgICBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIERTTCBsaW5lIGFuZCB0aGUg VkMgYmV0d2VlbiB0aGUgYWNjZXNzIG5vZGUgDQogICAgICAgICAgYW5kIHRoZSBOQVMuICANCg0K ICAgICAgICAgICBGb3IgbG9jYWwgbG9vcCB3aGljaCBpcyBFdGhlcm5ldCBiYXNlZCAoYW5kIHRh Z2dlZCksIHRoZSBzdHJpbmcgDQogICAgICAgICAgIGNvbnNpc3RzIG9mIHNsb3QvcG9ydCBhbmQg VkxBTiB0YWcgY29ycmVzcG9uZGluZyB0byB0aGUgDQogICAgICAgICAgIHN1YnNjcmliZXIuIERl ZmF1bHQgc3ludGF4IGZvciB0aGUgc3RyaW5nIGluc2VydGVkIGJ5IHRoZSBhY2Nlc3MgDQogICAg ICAgICAgIG5vZGUgYXMgcGVyIFs4XSBpczogDQoNCiAgICAgICAgICAgICJBY2Nlc3MtTm9kZS1J ZGVudGlmaWVyIGV0aCBzbG90L3BvcnRbOnZsYW4taWRdIiAgDQogICAgICANCiAgICAgICAgICAg DQogICAgICAgMi4gVHlwZSAoQWNjZXNzLUxvb3AtUmVtb3RlLUlkID0gMHgwMik6IFRoaXMgaXMg YW4gb3B0aW9uYWwgVExWIGFuZCANCiAgICAgICAgICBjb250YWlucyBhbiBpZGVudGlmaWVyIHRv IHVuaXF1ZWx5IGlkZW50aWZ5IGEgdXNlciBvbiBhIGxvY2FsIGxvb3AgDQogICAgICAgICAgb24g dGhlIGFjY2VzcyBub2RlLiBUaGUgZXhhY3QgdXNhZ2Ugb24gdGhlIE5BUyBpcyBvdXQgb2Ygc2Nv cGUgb2YgDQogICAgICAgICAgdGhpcyBkb2N1bWVudC4gSXQgaXMgZGVzaXJhYmxlIHRoYXQgdGhl IGZvcm1hdCB1c2VkIGZvciB0aGUgZmllbGQgDQogICAgICAgICAgaXMgc2ltaWxhciB0byB3aGF0 IGlzIHVzZWQgYnkgdGhlIGFjY2VzcyBub2RlcyBpbiBzdWJzY3JpYmVyIA0KICAgICAgICAgIHNp Z25hbGluZyBtZXNzYWdlcyB3aGVuIHRoZSBhY2Nlc3Mgbm9kZXMgYWN0IGFzIJNzaWduYWxpbmcg cmVsYXkgDQogICAgICAgICAgYWdlbnRzlCBhcyBvdXRsaW5lZCBpbiBbN10gYW5kIFs4XS4gDQoN CiAgICAgICAgICBMZW5ndGggOiAodXB0byA2MyBieXRlcykgDQoNCiAgICAgICAgICBWYWx1ZSAg OiAgQVNDSUkgc3RyaW5nIA0KDQogICAgICAgICAgICAgICANCg0KICAgICAgIDMuIFR5cGUgKEFj Y2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUJpbmFyeSA9IDB4MDYpIA0KDQogICAgICAgICAg TGVuZ3RoIDogKDggYnl0ZXMpICANCg0KICAgICAgICAgIFZhbHVlIDogdHdvIDMyIGJpdCBpbnRl Z2Vycy4gDQoNCiAgICAgICAgICBGb3IgZXRoZXJuZXQgYWNjZXNzIGFnZ3JlZ2F0aW9uLCB3aGVy ZSBhIHBlci1zdWJzY3JpYmVyIChzdGFja2VkKSANCiAgICAgICAgICBWTEFOIGNhbiBiZSBhcHBs aWVkICgxOjEgbW9kZWwgZGVmaW5lZCBpbiBbOF0pLCB0aGUgVkxBTiBzdGFjayANCiAgICAgICAg ICBwcm92aWRlcyBhIGNvbnZlbmllbnQgd2F5IHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBEU0wg bGluZS4gVGhlIA0KICAgICAgICAgIG91dGVyIFZMQU4gaXMgZXF1aXZhbGVudCB0byB2aXJ0dWFs IHBhdGggYmV0d2VlbiBhIERTTEFNIGFuZCB0aGUgDQogICAgICAgICAgTkFTIGFuZCBpbm5lciBW TEFOIGlzIGVxdWl2YWxlbnQgdG8gYSB2aXJ0dWFsIGNpcmN1aXQgb24gYSBwZXIgRFNMIA0KICAg ICAgICAgIGxpbmUgYmFzaXMuIEluIHRoaXMgc2NlbmFyaW8sIGFueSBzdWJzY3JpYmVyIGRhdGEg cmVjZWl2ZWQgYnkgdGhlIA0KICAgICAgICAgIGFjY2VzcyBub2RlIGFuZCB0cmFuc21pdHRlZCBv dXQgdGhlIHVwbGluayB0byB0aGUgYWdncmVnYXRpb24gDQogICAgICAgICAgbmV0d29yayB3aWxs IGJlIHRhZ2dlZCB3aXRoIHRoZSBWTEFOIHN0YWNrIGFzc2lnbmVkIGJ5IHRoZSBhY2Nlc3MgDQog ICAgICAgICAgbm9kZSANCg0KICAgICAgICAgIFRoaXMgVExWIGNhbiBjYXJyeSB0aGUgVkxBTiB0 YWdzIGFzc2lnbmVkIGJ5IHRoZSBhY2Nlc3Mgbm9kZSBpbiB0aGUgDQogICAgICAgICAgQU5DUCBt ZXNzYWdlcy4gVGhlIFZMQU4gdGFncyBjYW4gdW5pcXVlbHkgaWRlbnRpZnkgdGhlIERTTCBsaW5l IA0KICAgICAgICAgIGJlaW5nIHJlZmVycmVkIHRvIGluIHRoZSBBTkNQIG1lc3NhZ2VzLCBhc3N1 bWluZyB0aGUgVkxBTiB0YWdzIGFyZSANCiAgICAgICAgICBub3QgaW4gYW55IHdheSB0cmFuc2xh dGVkIGluIHRoZSBhZ2dyZWdhdGlvbiBuZXR3b3JrIGFuZCBhcmUgdW5pcXVlIA0KICAgICAgICAg IGFjcm9zcyBwaHlzaWNhbCBwb3J0cy4gRWFjaCAzMiBiaXQgaW50ZWdlciAobGVhc3Qgc2lnbmlm aWNhbnQgYml0cykgDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjRdIA0KICAg ICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9j b2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgICAgICBjb250YWlu cyBhIDEyIGJpdCBWTEFOIGlkZW50aWZpZXIgKHdoaWNoIGlzIHBhcnQgb2YgdGhlIFZMQU4gdGFn IA0KICAgICAgICAgIGRlZmluZWQgYnkgSUVFRSA4MDIuMVEpLiANCg0KICAgICAgICAgIEFsc28s IGluIGNhc2Ugb2YgYW4gQVRNIGFnZ3JlZ2F0aW9uIG5ldHdvcmssIHdoZXJlIHRoZSBEU0xBTSBp cyANCiAgICAgICAgICBkaXJlY3RseSBjb25uZWN0ZWQgdG8gdGhlIE5BUyAod2l0aG91dCBhbiBp bnRlcm1lZGlhdGUgQVRNIHN3aXRjaCksIA0KICAgICAgICAgIHRoZSB0d28gdmFsdWVzIGNhbiBj b250YWluIFZQSSBhbmQgVkNJIG9uIHRoZSBEU0xBTSB1cGxpbmsgKGFuZCBjYW4gDQogICAgICAg ICAgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIERTTCBsaW5lIG9uIHRoZSBEU0xBTSkuIA0KDQogICAg ICAgICAgVGhpcyBUTFYgaXMgb3B0aW9uYWwuIA0KDQogICAgICANCg0KICAgICAgIDQuIFR5cGUg KEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlELUFTQ0lJID0gMHgwMykgDQoNCiAgICAgICAg ICBMZW5ndGggOiAodXB0byA2MyBieXRlcykgIA0KDQogICAgICAgICAgVmFsdWUgOiBBU0NJSSBz dHJpbmcuIA0KDQogICAgICAgICAgVGhpcyBmaWVsZCBjb250YWlucyBpbmZvcm1hdGlvbiBwZXJ0 YWluaW5nIHRvIGFuIHVwbGluayBvbiB0aGUgDQogICAgICAgICAgYWNjZXNzIG5vZGUuIEZvciBF dGhlcm5ldCBhY2Nlc3MgYWdncmVnYXRpb24sIGFzc3VtaW5nIHRoZSBhY2Nlc3MgDQogICAgICAg ICAgbm9kZSBhc3NpZ25zIFZMQU4gdGFncyAoMToxIG1vZGVsKSwgdHlwaWNhbCBmb3JtYXQgZm9y IHRoZSBzdHJpbmcgDQogICAgICAgICAgaXM6IA0KDQogICAgICAgICAgk0FjY2Vzcy1Ob2RlLUlk ZW50aWZpZXIgZXRoIHNsb3QvcG9ydCBbOmlubmVyLXZsYW4taWRdWzpvdXRlci12bGFuLWlkXZQg ICANCg0KICAgICAgICAgIFRoZSBzbG90L3BvcnQgY29ycmVzcG9uZHMgdG8gdGhlIGV0aGVybmV0 IHVwbGluayBvbiB0aGUgYWNjZXNzIG5vZGUgDQogICAgICAgICAgdG93YXJkcyB0aGUgTkFTLiAN Cg0KICAgICAgICAgIEZvciBhbiBBVE0gYWdncmVnYXRpb24gbmV0d29yaywgdHlwaWNhbCBmb3Jt YXQgZm9yIHRoZSBzdHJpbmcgaXM6IA0KDQogICAgICAgICAgk0FjY2Vzcy1Ob2RlLUlkZW50aWZp ZXIgYXRtIHNsb3QvcG9ydDp2cGkudmNplCANCg0KICAgICAgICAgIFRoaXMgVExWIGFsbG93cyB0 aGUgTkFTIHRvIGFzc29jaWF0ZSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIA0KICAgICAg ICAgIHRoZSBBTkNQIG1lc3NhZ2VzIHRvIHRoZSBEU0wgbGluZSBvbiB0aGUgYWNjZXNzIG5vZGUu IA0KDQogICAgICAgICAgSWYgdGhlIGFjY2VzcyBub2RlIGluc2VydHMgdGhpcyBzdHJpbmcgaW4g dGhlIEFOQ1AgbWVzc2FnZXMsIHdoZW4gDQogICAgICAgICAgcmVmZXJyaW5nIHRvIGxvY2FsIGxv b3AgY2hhcmFjdGVyaXN0aWNzIChlLmcuIERTTCBsaW5lIGluIGNhc2Ugb2YgYSANCiAgICAgICAg ICBEU0xBTSksIHRoZW4gaXQgc2hvdWxkIGJlIGFibGUgdG8gbWFwIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gDQogICAgICAgICAgdGhlIHN0cmluZyB1bmlxdWVseSB0byB0aGUgbG9jYWwg bG9vcCAoZS5nLiBEU0wgbGluZSkuIA0KDQogICAgICAgICAgT24gdGhlIE5BUywgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHN0cmluZyBjYW4gYmUgdXNlZCB0byANCiAgICAgICAg ICBkZXJpdmUgYW4gk2FnZ3JlZ2F0aW9uIG5ldHdvcmuUIGZhY2luZyBjb25zdHJ1Y3QgKGUuZy4g YW4gSVAgDQogICAgICAgICAgaW50ZXJmYWNlKSBjb3JyZXNwb25kaW5nIHRvIHRoZSBsb2NhbCBs b29wIChlLmcuIERTTCBsaW5lKS4gVGhlIA0KICAgICAgICAgIGFzc29jaWF0aW9uIGNvdWxkIGJl IGJhc2VkIG9uIJNsb2NhbCBjb25maWd1cmF0aW9ulCBvbiB0aGUgTkFTLiANCg0KICAgICAgICAg IFRoZSBhY2Nlc3Mgbm9kZSBjYW4gYWxzbyBjb252ZXkgdG8gdGhlIE5BUywgdGhlIGNoYXJhY3Rl cmlzdGljcyANCiAgICAgICAgICAoZS5nLiBiYW5kd2lkdGgpIG9mIHRoZSB1cGxpbmsgb24gdGhl IGFjY2VzcyBub2RlLiBUaGlzIFRMViB0aGVuIA0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdh IGV0LmFsICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICBb UGFnZSAyNV0gDQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWll dGYtYW5jcC1wcm90b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcgDQogICAgICAgICANCg0KICAg ICAgICAgIHNlcnZlcyB0aGUgcHVycG9zZSBvZiB1bmlxdWVseSBpZGVudGlmeWluZyB0aGUgdXBs aW5rIHdob3NlIA0KICAgICAgICAgIGNoYXJhY3RlcmlzdGljcyBhcmUgYmVpbmcgZGVmaW5lZC4g QSBzZXBhcmF0ZSBzZXQgb2Ygc3ViLVRMVnMgd2lsbCANCiAgICAgICAgICBiZSBkZWZpbmVkIGZv ciB0aGUgdXBsaW5rIGNoYXJhY3RlcmlzdGljcyAoVEJEKS4gDQoNCiAgICAgICAgICBUaGlzIFRM ViBpcyBvcHRpb25hbC4gDQoNCiAgICAgICAgICANCg0KICAgICAgIDUuIFR5cGUgKERTTCBMaW5l IEF0dHJpYnV0ZXMgPSAweDA0KTogDQoNCiAgICAgICAgICBMZW5ndGggOiB2YXJpYWJsZSAodXAg dG8gMTAyNCBieXRlcykgDQoNCiAgICAgICAgICBWYWx1ZSA6IFRoaXMgY29uc2lzdHMgb2Ygb25l IG9yIG1vcmUgU3ViLVRMVnMgY29ycmVzcG9uZGluZyB0byBEU0wgICAgIA0KICAgICAgICAgIGxp bmUgYXR0cmlidXRlcy4gTm8gc3ViLVRMVnMgb3RoZXIgdGhhbiB0aGUgk0RTTCB0eXBllCBhbmQg k0RTTCANCiAgICAgICAgICBsaW5lIHN0YXRllCBTSE9VTEQgYmUgaW5jbHVkZWQgaW4gYSBQT1JU IERPV04gbWVzc2FnZS4gDQoNCiAgICAgICAgICBUaGUgZ2VuZXJhbCBmb3JtYXQgb2YgdGhlIHN1 Yi1UTFZzIGlzIGlkZW50aWNhbCB0byB0aGUgZ2VuZXJhbCBUTFYgICANCiAgICAgICAgICBmb3Jt YXQuIFRoZSB2YWx1ZSBmaWVsZCBpbiBlYWNoIHN1Yi1UTFYgaXMgcGFkZGVkIHRvIGEgNC1vY3Rl dCANCiAgICAgICAgICBhbGlnbm1lbnQuIFRoZSBMZW5ndGggZmllbGQgaW4gZWFjaCBzdWItVExW IGNvbnRhaW5zIHRoZSBhY3R1YWwgDQogICAgICAgICAgbnVtYmVyIG9mIGJ5dGVzIGluIHRoZSBU TFYgKG5vdCBpbmNsdWRpbmcgdGhlIHBhZGRpbmcgaWYgcHJlc2VudCkuIA0KICAgICAgICAgIEN1 cnJlbnQgZGVmaW5lZCBzdWItVExWIHR5cGVzIGFyZSBzdGFydCBmcm9tIDB4ODEuIA0KDQogICAg ICAgICAgRm9sbG93aW5nIHN1Yi1UTFZzIGFyZSBjdXJyZW50bHkgZGVmaW5lZCA6IA0KDQogICAg ICAgICAgLiBUeXBlIChEU0wtVHlwZSA9IDB4OTEpIDogRGVmaW5lcyB0aGUgdHlwZSBvZiB0cmFu c21pc3Npb24gc3lzdGVtIA0KICAgICAgICAgICAgIGluIHVzZS4gVGhpcyBpcyBhIG1hbmRhdG9y eSBUTFYuIA0KDQogICAgICAgICAgICAgTGVuZ3RoIDogICg0IGJ5dGVzKSAgIA0KDQogICAgICAg ICAgICAgVmFsdWUgIDogKFRyYW5zbWlzc2lvbiBzeXN0ZW0gOiBBRFNMMSA9IDB4MDEsIEFEU0wy ID0gMHgwMiwgICAgIA0KICAgICAgICAgICAgIEFEU0wyKyA9IDB4MDMsIFZEU0wxID0gMHgwNCwg VkRTTDIgPSAweDA1LCBTRFNMID0gMHgwNiwgVU5LTk9XTiANCiAgICAgICAgICAgICA9IDB4MDcp LiANCg0KICAgICAgICAgIC4gVHlwZSAoQWN0dWFsLURhdGEtUmF0ZS1VcHN0cmVhbSA9IDB4ODEp IDogQWN0dWFsIGRhdGEgcmF0ZSANCiAgICAgICAgICAgICB1cHN0cmVhbSBvZiBhIHN5bmNocm9u aXplZCBEU0wgbGluZS4gVGhpcyBpcyBhIG1hbmRhdG9yeSBUTFYuIA0KICAgICAgICAgICAgIFRo aXMgcmF0ZSB2YWx1ZSBhbmQgYWxsIHRoZSBzdWJzZXF1ZW50IG9uZXMgYWNjb3VudCBmb3IgdGhl IERTTCANCiAgICAgICAgICAgICBvdmVyaGVhZCAoaS5lLiBzaWduaWZ5IHRoZSBuZXQgcmF0ZSku ICAgDQoNCiAgICAgICAgICAgIExlbmd0aCAgOiAgKDQgYnl0ZXMpIA0KDQogICAgICAgICAgICBW YWx1ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSANCg0KICAgICAgICAgIC4gVHlwZSAoQWN0dWFsLURh dGEtUmF0ZS1Eb3duc3RyZWFtID0gMHg4MikgOiBBY3R1YWwgZGF0YSByYXRlIA0KICAgICAgICAg ICAgIGRvd25zdHJlYW0gb2YgYSBzeW5jaHJvbml6ZWQgRFNMIGxpbmUuIFRoaXMgaXMgYSBtYW5k YXRvcnkgVExWLiANCg0KICAgICAgICAgICAgIExlbmd0aCA6ICAoNCBieXRlcykgDQoNCiAgICAg IA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjZdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5l dC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAy MDA3IA0KICAgICAgICAgDQoNCiAgICAgICAgICAgICBWYWx1ZSAgOiAgKFJhdGUgaW4gS2Ivc2Vj KSANCg0KICAgICAgICAgIC4gVHlwZSAoTWluaW11bS1EYXRhLVJhdGUtVXBzdHJlYW0gPSAweDgz KSA6IE1pbmltdW0gZGF0YSByYXRlIA0KICAgICAgICAgICAgIGRlc2lyZWQgYnkgdGhlIG9wZXJh dG9yLiBUaGlzIGlzIG9wdGlvbmFsLiAgDQoNCiAgICAgICAgICAgIExlbmd0aCAgOiAgKDQgYnl0 ZXMpIA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSANCg0KICAgICAg ICAgIC4gVHlwZSAoTWluaW11bS1EYXRhLVJhdGUtRG93bnN0cmVhbSA9IDB4ODQpIDogTWluaW11 bSBkYXRhIHJhdGUgDQogICAgICAgICAgICAgZGVzaXJlZCBieSB0aGUgb3BlcmF0b3IuIFRoaXMg aXMgb3B0aW9uYWwuICANCg0KICAgICAgICAgICAgTGVuZ3RoICA6ICAoNCBieXRlcykgDQoNCiAg ICAgICAgICAgIFZhbHVlICAgOiAoUmF0ZSBpbiBLYi9zZWMpIA0KDQogICAgICAgICAgLiBUeXBl IChBdHRhaW5hYmxlLURhdGEtUmF0ZS1VcHN0cmVhbSA9IDB4ODUpIDogTWF4aW11bSB1cHN0cmVh bSANCiAgICAgICAgICAgICByYXRlIHRoYXQgY2FuIGJlIGF0dGFpbmVkIG9uIHRoZSBEU0wgbGlu ZS4gVGhpcyBpcyBhbiBvcHRpb25hbCANCiAgICAgICAgICAgICBUTFYuIA0KDQogICAgICAgICAg ICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAgICAgICAgICAgIFZhbHVlICAgOiAoUmF0ZSBp biBLYi9zZWMpIA0KDQogICAgICAgICAgLiBUeXBlIChBdHRhaW5hYmxlLURhdGEtUmF0ZS1Eb3du c3RyZWFtID0gMHg4NikgOiBNYXhpbXVtIA0KICAgICAgICAgICAgIGRvd25zdHJlYW0gcmF0ZSB0 aGF0IGNhbiBiZSBhdHRhaW5lZCBvbiB0aGUgRFNMIGxpbmUuIFRoaXMgaXMgIA0KICAgICAgICAg ICAgIGFuIG9wdGlvbmFsIFRMVi4gDQoNCiAgICAgICAgICAgIExlbmd0aCAgOiAgKDQgYnl0ZXMp IA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSANCg0KICAgICAgICAg IC4gVHlwZSAoTWF4aW11bS1EYXRhLVJhdGUtVXBzdHJlYW0gPSAweDg3KSA6IE1heGltdW0gZGF0 YSByYXRlIA0KICAgICAgICAgICAgIGRlc2lyZWQgYnkgdGhlICBvcGVyYXRvci4gVGhpcyBpcyBv cHRpb25hbC4gIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSAgDQoNCiAgICAg ICAgICAgIFZhbHVlICAgOiAoUmF0ZSBpbiBLYi9zZWMpIA0KDQogICAgICAgICAgIA0KDQogICAg ICAgICAgLiBUeXBlIChNYXhpbXVtLURhdGEtUmF0ZS1Eb3duc3RyZWFtID0gMHg4OCkgOiBNYXhp bXVtIGRhdGEgcmF0ZSANCiAgICAgICAgICAgICBkZXNpcmVkIGJ5IHRoZSBvcGVyYXRvci4gVGhp cyBpcyBvcHRpb25hbC4gIA0KDQogICAgICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0K ICAgICAgICAgICAgVmFsdWUgICA6IChSYXRlIGluIEtiL3NlYykgDQogICAgICANCiAgICAgIA0K ICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAg ICAgICAgICAgIFtQYWdlIDI3XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAg ICAgZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAwICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAg ICAgIA0KDQogICAgICAgICAgLiBUeXBlIChNaW5pbXVtLUxvdy1Qb3dlci1EYXRhLVJhdGUtVXBz dHJlYW0gPSAweDg5KSA6IE1pbmltdW0gDQogICAgICAgICAgICAgZGF0YSByYXRlIGRlc2lyZWQg YnkgdGhlIG9wZXJhdG9yIGluIGxvdyBwb3dlciBzdGF0ZS4gVGhpcyBpcyANCiAgICAgICAgICAg ICBvcHRpb25hbC4gDQoNCiAgICAgICAgICAgIExlbmd0aCAgOiAgKDQgYnl0ZXMpIA0KDQogICAg ICAgICAgICBWYWx1ZSAgIDogKFJhdGUgaW4gS2Ivc2VjKSANCg0KICAgICAgICAgIC4gVHlwZSAo TWluaW11bS1Mb3ctUG93ZXItRGF0YS1SYXRlLURvd25zdHJlYW0gPSAweDhBKSA6IE1pbmltdW0g DQogICAgICAgICAgICAgZGF0YSByYXRlIGRlc2lyZWQgYnkgdGhlIG9wZXJhdG9yIGluIGxvdyBw b3dlciBzdGF0ZS4gVGhpcyBpcyANCiAgICAgICAgICAgICBvcHRpb25hbC4gDQoNCiAgICAgICAg ICAgIExlbmd0aCAgOiAgKDQgYnl0ZXMpIA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFJhdGUg aW4gS2Ivc2VjKSANCg0KICAgICAgICAgIC4gVHlwZSAoTWF4aW11bS1JbnRlcmxlYXZpbmctRGVs YXktVXBzdHJlYW0gPSAweDhCKSA6IG1heGltdW0gb25lIA0KICAgICAgICAgICAgIHdheSBpbnRl cmxlYXZpbmcgZGVsYXkuIFRoaXMgaXMgb3B0aW9uYWwuIA0KDQogICAgICAgICAgICBMZW5ndGgg IDogICg0IGJ5dGVzKSANCg0KICAgICAgICAgICAgVmFsdWUgICA6IChUaW1lIGluIG1zZWMpIA0K DQogICAgICAgICAgLiBUeXBlIChBY3R1YWwtSW50ZXJsZWF2aW5nLURlbGF5LVVwc3RyZWFtID0g MHg4QykgOiBWYWx1ZSANCiAgICAgICAgICAgICBjb3JyZXNwb25kaW5nIHRvIHRoZSBpbnRlcmxl YXZlciBzZXR0aW5nLiBUaGlzIGlzIG9wdGlvbmFsLiANCg0KICAgICAgICAgICAgTGVuZ3RoICA6 ICAoNCBieXRlcykgDQoNCiAgICAgICAgICAgIFZhbHVlICAgOiAoVGltZSBpbiBtc2VjKSANCg0K ICAgICAgICAgIC4gVHlwZSAoTWF4aW11bS1JbnRlcmxlYXZpbmctRGVsYXktRG93bnN0cmVhbSA9 IDB4OEQpIDogbWF4aW11bSANCiAgICAgICAgICAgICBvbmUgd2F5IGludGVybGVhdmluZyBkZWxh eS4gVGhpcyBpcyBvcHRpb25hbC4gDQoNCiAgICAgICAgICAgIExlbmd0aCAgOiAgKDQgYnl0ZXMp IA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFRpbWUgaW4gbXNlYykgDQoNCiAgICAgICAgICAg DQoNCiAgICAgICAgICAuIFR5cGUgKEFjdHVhbC1JbnRlcmxlYXZpbmctRGVsYXktRG93bnN0cmVh bSA9IDB4OEUpIDogVmFsdWUgDQogICAgICAgICAgICAgY29ycmVzcG9uZGluZyB0byB0aGUgaW50 ZXJsZWF2ZXIgc2V0dGluZy4gVGhpcyBpcyBvcHRpb25hbC4gDQoNCiAgICAgICAgICAgIExlbmd0 aCAgOiAgKDQgYnl0ZXMpIA0KDQogICAgICAgICAgICBWYWx1ZSAgIDogKFRpbWUgaW4gbXNlYykg DQoNCg0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAyOF0gDQogICAgICAgICANCgwg ICAgIEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0wMCAgICAg ICAgQXVndXN0IDIwMDcgDQogICAgICAgICANCg0KICAgICAgICAgIC4gVHlwZSAoRFNMIGxpbmUg c3RhdGUgPSAweDhGKSA6IFRoZSBzdGF0ZSBvZiB0aGUgRFNMIGxpbmUuIEZvciANCiAgICAgICAg ICAgICBQT1JUIFVQIG1lc3NhZ2UsIGF0IHRoaXMgdGltZSwgdGhlIFRMViBpcyBvcHRpb25hbCAo c2luY2UgdGhlIA0KICAgICAgICAgICAgIG1lc3NhZ2UgdHlwZSBpbXBsaWNpdGx5IGNvbnZleXMg dGhlIHN0YXRlIG9mIHRoZSBsaW5lKS4gRm9yIFBPUlQgDQogICAgICAgICAgICAgRE9XTiwgdGhl IFRMViBpcyBtYW5kYXRvcnksIHNpbmNlIGl0IGZ1cnRoZXIgY29tbXVuaWNhdGVzIHRoZSANCiAg ICAgICAgICAgICBzdGF0ZSBvZiB0aGUgbGluZSBhcyBJRExFIG9yIFNJTEVOVC4gIA0KDQogICAg ICAgICAgICBMZW5ndGggIDogICg0IGJ5dGVzKSANCg0KICAgICAgICAgICAgIFZhbHVlICAgOiAg eyBTSE9XVElNRSA9IDB4MDEsIElETEUgPSAweDAyLCBTSUxFTlQgPSAweDAzIH0gDQoNCiAgICAg ICAgICAuIFR5cGUgKEFjY2VzcyBMb29wIEVuY2Fwc3VsYXRpb24gPSAweDkwKSA6IFRoZSBkYXRh IGxpbmsgcHJvdG9jb2wgDQogICAgICAgICAgICAgYW5kLCBvcHRpb25hbGx5IHRoZSBlbmNhcHN1 bGF0aW9uIG92ZXJoZWFkIG9uIHRoZSBhY2Nlc3MgbG9vcC4gDQogICAgICAgICAgICAgVGhpcyBp cyBhbiBvcHRpb25hbCBUTFYuIEhvd2V2ZXIsIHdoZW4gdGhpcyBUTFYgaXMgcHJlc2VudCwgdGhl IA0KICAgICAgICAgICAgIGRhdGEgbGluayBwcm90b2NvbCBNVVNUIG1pbmltYWxseSBiZSBpbmRp Y2F0ZWQuIFRoZSANCiAgICAgICAgICAgICBlbmNhcHN1bGF0aW9uIG92ZXJoZWFkIGNhbiBiZSBv cHRpb25hbGx5IGluZGljYXRlZC4gDQoNCiAgICAgICAgICAgICAgTGVuZ3RoICA6ICAoMyBieXRl cykgDQoNCiAgICAgICAgICAgICAgVmFsdWUgOiBUaGUgdGhyZWUgYnl0ZXMgKG1vc3QgdG8gbGVh c3Qgc2lnbmlmaWNhbnQpIGFuZCB2YWxpZCAgIA0KICAgICAgICAgICAgICBzZXQgb2YgdmFsdWVz IGZvciBlYWNoIGJ5dGUgYXJlIGRlZmluZWQgYmVsb3cuIA0KDQogICAgICAgICAgICAgICAgICAg RGF0YSBMaW5rICgxIGJ5dGUpOiB7QVRNIEFBTDUgPSAwLCAgDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRVRIRVJORVQgPSAxfSANCg0KICAgICAgICAgICAgICAg ICAgICBFbmNhcHMgMSAoMSBieXRlKToge05BID0gMCwgIA0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVW50YWdnZWQgRXRoZXJuZXQgPSAxLCANCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNpbmdsZS10YWdnZWQgRXRoZXJuZXQgPSAy fSAgICAgIA0KDQogICAgICAgICAgICAgICAgICAgIEVuY2FwcyAyICgxIGJ5dGUpOnsgTkEgPSAw LCAgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQUFBvQSBMTEMgPSAx LCAgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQUFBvQSBOVUxMID0g MiwgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUG9BIExMQyA9IDMs ICANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElQb0EgTnVMTCA9IDQs ICANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92ZXIg QUFMNSBMTEMgd2l0aCBGQ1MgPSA1LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEV0aGVybmV0IG92ZXIgQUFMNSBMTEMgd2l0aG91dCBGQ1MgPSA2LCANCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV0aGVybmV0IG92ZXIgQUFMNSBOVUxMIHdp dGggRkNTID0gNywgDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjldIA0KICAg ICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9j b2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBFdGhlcm5ldCBvdmVyIEFBTDUgTlVMTCB3aXRob3V0IEZDUyA9 IDh9IA0KDQogICAgIElmIHRoaXMgVExWIGlzIHByZXNlbnQsIHRoZSBEYXRhIExpbmsgcHJvdG9j b2wgTVVTVCBiZSBpbmRpY2F0ZWQgYXMgDQogICAgIGRlZmluZWQgYWJvdmUuIEhvd2V2ZXIsIHRo ZSBBY2Nlc3MgTm9kZSBjYW4gY2hvb3NlIHRvIG5vdCBjb252ZXkgdGhlIA0KICAgICBlbmNhcHN1 bGF0aW9uIG9uIHRoZSBhY2Nlc3MgbG9vcCBieSBzcGVjaWZ5aW5nIGEgdmFsdWUgb2YgMCAoTkEp IGZvciB0aGUgDQogICAgIHR3byBlbmNhcHN1bGF0aW9uIGZpZWxkcy4gICAgDQoNCiAgICAgNS40 LjMgTGluZSBDb25maWd1cmF0aW9uIEV4dGVuc2lvbnMgDQoNCiAgICAgVGhlIE5BUyB1c2VzIGV4 dGVuc2lvbiBibG9jayBpbiB0aGUgUG9ydCBNYW5hZ2VtZW50IG1lc3NhZ2VzIHRvIGNvbnZleSAN CiAgICAgc2VydmljZSBhdHRyaWJ1dGVzIG9mIHRoZSBEU0wgbGluZXMgdG8gdGhlIERTTEFNLiBU TFZzIGFyZSBkZWZpbmVkIGZvciAgICAgIA0KICAgICBEU0wgbGluZSBpZGVudGlmaWNhdGlvbiBh bmQgc2VydmljZSBkYXRhIGZvciB0aGUgRFNMIGxpbmVzLiBQb3J0IG51bWJlciANCiAgICAgaXMg c2V0IHRvIDAgaW4gdGhlIG1lc3NhZ2UuIEEgbmV3IGFjdGlvbiB0eXBlICJDb25maWd1cmUgQ29u bmVjdGlvbiANCiAgICAgU2VydmljZSBEYXRhIiAodmFsdWUgMHg4KSBpcyBkZWZpbmVkLiBUaGUg IkZ1bmN0aW9uIiBmaWVsZCBpcyBzZXQgdG8gdGhlIA0KICAgICBhY3Rpb24gdHlwZS4gVGhpcyBh Y3Rpb24gdHlwZSBpbmRpY2F0ZXMgdG8gdGhlIGRldmljZSBiZWluZyBjb250cm9sbGVkIA0KICAg ICAoYWNjZXNzLW5vZGUgaS5lLiBEU0xBTSkgdG8gYXBwbHkgc2VydmljZSBjb25maWd1cmF0aW9u IGRhdGEgY29udGFpbmVkIA0KICAgICBpbiB0aGUgZXh0ZW5zaW9uIHZhbHVlIChUTFZzKSwgdG8g dGhlIERTTCBsaW5lIChpZGVudGlmaWVkIGJ5IG9uZSBvZiB0aGUgDQogICAgIFRMVnMgaW4gdGhl IGV4dGVuc2lvbiB2YWx1ZSkuIFRoZSBUZWNoIFR5cGUgZmllbGQgaXMgZXh0ZW5kZWQgd2l0aCBu ZXcgDQogICAgIHR5cGUgIkRTTCIuIFRoZSB2YWx1ZSBmb3IgdGhpcyBmaWVsZCBpcyAweDA1LiAN Cg0KICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMyANCiAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHwgVmVycyAgfCAgU3ViICB8IE1lc3NhZ2UgVHlwZSAgfCBSZXN1bHR8ICAgICAgICBD b2RlICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCBQYXJ0aXRpb24g SUQgIHwgICAgICAgICAgICBUcmFuc2FjdGlvbiBJZGVudGlmaWVyICAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgICB8SXwgICAgICBTdWJNZXNzYWdlIE51bWJlciAgICAg IHwgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBvcnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICBQb3J0IFNlc3Npb24gTnVtYmVyICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgRXZlbnQgU2Vx dWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHxSfHh8eHx4fHh8eHx4fHh8ICAgRHVyYXRpb24gICAgfCAgICBGdW5jdGlvbiAgIHwg WC1GdW5jdGlvbiAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgfCAgICAgICAgICAg RXZlbnQgRmxhZ3MgICAgICAgICB8ICAgICAgICBGbG93IENvbnRyb2wgRmxhZ3MgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgICB8eHx4fHh8eHx4fHh8eHx4fCBNZXNzYWdlIFR5cGUg IHwgICBUZWNoIFR5cGUgICB8IEJsb2NrIExlbmd0aCAgfCANCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgIEV4dGVu c2lvbiBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgfiANCiAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KICAgICAgDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBl dC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgMzBdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRm LWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAg IA0KDQogICAgICAgICAgIA0KDQogICAgICAgIFRoZSBmb3JtYXQgb2YgdGhlICJFeHRlbnNpb24g VmFsdWUiIGZpZWxkIGlzIGFzIGZvbGxvd3M6IA0KICAgICAgICAgDQogICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0KICAgICAgICB8ICAgICAgICAgICAgICMgb2YgVExWcyAgICAgICAgIHwgRXh0ZW5zaW9uIEJs b2NrIGxlbmd0aCAoYnl0ZXMpfCANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 IA0KICAgICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfiANCiAgICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUTFZzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4gIA0KICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgICANCg0KICAgICAgICBUaGUgk0V4dGVuc2lvbiBW YWx1ZZQgZmllbGQgY29udGFpbnMgb25lIG9yIG1vcmUgVExWcyBjb250YWluaW5nIERTTCANCiAg ICAgICAgbGluZSBpZGVudGlmaWVyIGFuZCBkZXNpcmVkIHNlcnZpY2UgYXR0cmlidXRlcyBvZiB0 aGUgdGhlIERTTCBsaW5lLiANCiAgICAgICAgRmlyc3QgMiBieXRlIG9mIHRoZSCTRXh0ZW5zaW9u IFZhbHVllCBjb250YWlucyB0aGUgbnVtYmVyIG9mIFRMVnMgDQogICAgICAgIHRoYXQgZm9sbG93 LiBUaGUgbmV4dCAyIGJ5dGVzIGNvbnRhaW4gdGhlIHRvdGFsIGxlbmd0aCBvZiB0aGUgDQogICAg ICAgIGV4dGVuc2lvbiBibG9jayBpbiBieXRlcyAoZXhpc3Rpbmcgk0Jsb2NrIExlbmd0aJQgZmll bGQgaW4gdGhlIEdTTVAgDQogICAgICAgIG1lc3NhZ2UgaXMgbGltaXRlZCB0byAyNTUgYnl0ZXMg YW5kIGlzIG5vdCBzdWZmaWNpZW50KS4gDQoNCiAgICAgICAgR2VuZXJhbCBmb3JtYXQgb2YgYSBU TFYgaXM6ICANCg0KICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgDQog ICAgICAgIHwgICAgICAgICAgICBUeXBlICAgICAgICAgICAgICAgfCAgICAgICAgICAgICBMZW5n dGggICAgICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICANCiAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgDQogICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB+IA0KICAgICAgICB+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgVmFsdWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfiAgDQogICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICAgIA0KDQogICAgICAgIFRoZSB2 YWx1ZSBmaWVsZCBpcyBwYWRkZWQgdG8gYSA0LW9jdGV0IGFsaWdubWVudC4gVGhlIExlbmd0aCBm aWVsZCBpbiANCiAgICAgICAgZWFjaCBUTFYgY29udGFpbnMgdGhlIGFjdHVhbCBudW1iZXIgb2Yg Ynl0ZXMgaW4gdGhlIFRMViAobm90IA0KICAgICAgICBpbmNsdWRpbmcgdGhlIHBhZGRpbmcgaWYg cHJlc2VudCkuIElmIGEgVExWIGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZSANCiAgICAgICAgYWNj ZXNzLW5vZGUsIGl0IGlzIHNpbGVudGx5IGlnbm9yZWQuIERlcGVuZGluZyB1cG9uIHRoZSBkZXBs b3ltZW50IA0KICAgICAgICBzY2VuYXJpbywgdGhlIE5BUyBtYXkgc3BlY2lmeSCTQWNjZXNzIExv b3AgQ2lyY3VpdC1JRJQgb3IgdGhlIJNBY2Nlc3MgDQogICAgICAgIEFnZ3JlZ2F0aW9uIENpcmN1 aXQtSUQpIGFzIGRlZmluZWQgaW4gc2VjdGlvbiA1LjQuMS4gRm9sbG93aW5nIFRMVnMgDQogICAg ICAgIGNhbiBhcHBlYXIgaW4gdGhpcyBtZXNzYWdlOiANCg0KICAgICAgICBvICBUeXBlIChBY2Nl c3MtTG9vcC1DaXJjdWl0LUlEID0gMHgwMSkgOiBkZWZpbmVkIGluIHNlY3Rpb24gNS40LjEgIA0K DQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBB dWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzFdIA0KICAgICAgICAgDQoMICAg ICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAg IEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgICAgbyAgVHlwZSAoQWNjZXNzLUFnZ3Jl Z2F0aW9uLUNpcmN1aXQtSUQtQmluYXJ5ID0gMHgwNik6IGRlZmluZWQgaW4gDQogICAgICAgICAg IHNlY3Rpb24gNS40LjEuIA0KDQogICAgICAgIG8gIFR5cGUgKEFjY2Vzcy1BZ2dyZWdhdGlvbi1D aXJjdWl0LUlELUFTQ0lJID0gMHgwMyk6IGRlZmluZWQgaW4gDQogICAgICAgICAgIHNlY3Rpb24g NS40LjEuICAgICAgDQoNCiAgICAgICAgbyAgVHlwZSAoU2VydmljZS1Qcm9maWxlLU5hbWUgPSAw eDA1KTogUmVmZXJlbmNlIHRvIGEgcHJlLWNvbmZpZ3VyZWQgDQogICAgICAgICAgIHByb2ZpbGUg b24gdGhlIERTTEFNIHRoYXQgY29udGFpbnMgc2VydmljZSBzcGVjaWZpYyBkYXRhIGZvciB0aGUg DQogICAgICAgICAgIHN1YnNjcmliZXIuICAgIA0KDQogICAgICAgICAgIExlbmd0aCA6ICh1cHRv IDY0IGJ5dGVzKSANCg0KICAgICAgICAgICBWYWx1ZSAgOiBBU0NJSSBzdHJpbmcgY29udGFpbmlu ZyB0aGUgcHJvZmlsZSBuYW1lIChOQVMgbGVhcm5zICANCiAgICAgICAgICAgZnJvbSBhIHBvbGlj eSBzZXJ2ZXIgYWZ0ZXIgYSBzdWJzY3JpYmVyIGlzIGF1dGhvcml6ZWQpLiANCg0KICAgICAgICBJ biBmdXR1cmUsIG1vcmUgVExWcyBNQVkgYmUgZGVmaW5lZCBmb3IgaW5kaXZpZHVhbCBzZXJ2aWNl IGF0dHJpYnV0ZXMgDQogICAgICAgIG9mIGEgRFNMIGxpbmUgKGUuZy4gcmF0ZXMsIGludGVybGVh dmluZyBkZWxheSwgIG11bHRpY2FzdCBjaGFubmVsIA0KICAgICAgICBlbnRpdGxlbWVudCBhY2Nl c3MtbGlzdCBldGMpLiANCg0KICAgICAgICAgDQoNCiAgICAgNS40LjQgT0FNIEV4dGVuc2lvbnMg DQoNCiAgICAgICAgR1NNUCCTUG9ydCBNYW5hZ2VtZW50lCBtZXNzYWdlICh0eXBlIDMyKSBTSE9V TEQgYmUgdXNlZCBieSB0aGUgTkFTIHRvIA0KICAgICAgICB0cmlnZ2VyIGFjY2VzcyBub2RlIHRv IHJ1biBhIGxvb3BiYWNrIHRlc3Qgb24gdGhlIGxvY2FsIGxvb3AuIFRoZSANCiAgICAgICAgbWVz c2FnZSBmb3JtYXQgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDUuNC4yLiBUaGUgdmVyc2lvbiBmaWVs ZCBTSE9VTEQgDQogICAgICAgIGJlIHNldCB0byAzIGFuZCBzdWItdmVyc2lvbiBmaWVsZCBTSE9V TEQgYmUgc2V0IHRvIDEuIFRoZSByZW1haW5pbmcgDQogICAgICAgIGZpZWxkcyBpbiB0aGUgR1NN UCBoZWFkZXIgaGF2ZSBzdGFuZGFyZCBzZW1hbnRpY3MuIFRoZSBmdW5jdGlvbiB0eXBlIA0KICAg ICAgICB1c2VkIGluIHRoZSByZXF1ZXN0IG1lc3NhZ2UgU0hPVUxEIGJlIHNldCB0byCTcmVtb3Rl IGxvb3BiYWNrlCAodHlwZSANCiAgICAgICAgPSAweDA5KS4gVGhlIHBvcnQsIJNwb3J0IHNlc3Np b24gbnVtYmVylCwgk2V2ZW50IHNlcXVlbmNlIG51bWJlcpQsIA0KICAgICAgICBkdXJhdGlvbiwg k2V2ZW50IGZsYWdzlCwgk2Zsb3cgY29udHJvbCBmbGFnc5QgYW5kIGNvZGUgZmllbGRzIFNIT1VM RCANCiAgICAgICAgYWxsIGJlIHNldCB0byAwLiBUaGUgcmVzdWx0IGZpZWxkIFNIT1VMRCBiZSBz ZXQgdG8gk0Fja0FsbJQgdG8gDQogICAgICAgIGluZGljYXRlIHJlcXVpcmVtZW50IGZvciB0aGUg YWNjZXNzIG5vZGUgdG8gc2VuZCBhIHN1Y2Nlc3MgZm9yIA0KICAgICAgICBmYWlsdXJlIHJlc3Bv bnNlLiBUaGUgdHJhbnNhY3Rpb24gSUQgU0hPVUxEIGNvbnRhaW4gYSBzZXF1ZW5jZSBudW1iZXIg DQogICAgICAgIGluc2VydGVkIGJ5IHRoZSBOQVMgaW4gZWFjaCByZXF1ZXN0IHRoYXQgaXQgZ2Vu ZXJhdGVzLiBUaGUgZXh0ZW5zaW9uIA0KICAgICAgICBmaWVsZCBmb3JtYXQgaXMgYWxzbyBkZWZp bmVkIGFib3ZlIGluIHNlY3Rpb24gNS40LjIuIFRoZSBleHRlbnNpb24gDQogICAgICAgIHZhbHVl IGZpZWxkIGNhbiBjb250YWluIG9uZSBvciBtb3JlIFRMVnMgaW5jbHVkaW5nIHRoZSBhY2Nlc3Mt bGluZSANCiAgICAgICAgaWRlbnRpZmllciBvbiB0aGUgRFNMQU0gYW5kIE9BTSB0ZXN0IGNoYXJh Y3RlcmlzdGljcyBkZXNpcmVkIGJ5IHRoZSANCiAgICAgICAgTkFTLiAgDQoNCiAgICAgICAgVGhl IFRMViBmb3JtYXQgaXMgZGVmaW5lZCBhYm92ZSBpbiBzZWN0aW9uIDUuNC4yLiBUaGUgdmFsdWUg ZmllbGQgaXMgDQogICAgICAgIHBhZGRlZCB0byBhIDQtb2N0ZXQgYWxpZ25tZW50LiBUaGUgTGVu Z3RoIGZpZWxkIGluIGVhY2ggVExWIGNvbnRhaW5zIA0KICAgICAgICB0aGUgYWN0dWFsIG51bWJl ciBvZiBieXRlcyBpbiB0aGUgVExWIChub3QgaW5jbHVkaW5nIHRoZSBwYWRkaW5nIGlmIA0KICAg ICAgICBwcmVzZW50KS4gSWYgYSBUTFYgaXMgbm90IHVuZGVyc3Rvb2QgYnkgdGhlIE5BUywgaXQg aXMgc2lsZW50bHkgDQogICAgICAgIGlnbm9yZWQuIERlcGVuZGluZyB1cG9uIHRoZSBkZXBsb3lt ZW50IHNjZW5hcmlvLCB0aGUgTkFTIG1heSBzcGVjaWZ5IA0KICAgICAgICCTQWNjZXNzIExvb3Ag Q2lyY3VpdC1JRJQgb3IgdGhlIJNBY2Nlc3MgQWdncmVnYXRpb24gQ2lyY3VpdC1JRCkgYXMgDQog ICAgICAgIGRlZmluZWQgaW4gc2VjdGlvbiA1LjQuMS4gRm9sbG93aW5nIFRMVnMgY2FuIGFwcGVh ciBpbiB0aGlzIG1lc3NhZ2U6IA0KICAgICAgDQogICAgICANCiAgICAgV2FkaHdhIGV0LmFsICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzMl0g DQogICAgICAgICANCgwgICAgIEludGVybmV0LURyYWZ0ICAgICAgIGRyYWZ0LWlldGYtYW5jcC1w cm90b2NvbC0wMCAgICAgICAgQXVndXN0IDIwMDcgDQogICAgICAgICANCg0KICAgICAgICBvICBU eXBlIChBY2Nlc3MtTG9vcC1DaXJjdWl0LUlEID0gMHgwMSkgOiBkZWZpbmVkIGluIHNlY3Rpb24g NS40LjEgIA0KDQogICAgICAgIG8gIFR5cGUgKEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlE LUJpbmFyeSA9IDB4MDYpOiBkZWZpbmVkIGluIA0KICAgICAgICAgICBzZWN0aW9uIDUuNC4xLiAN Cg0KICAgICAgICBvICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3VpdC1JRC1BU0NJSSA9 IDB4MDMpOiBkZWZpbmVkIGluIA0KICAgICAgICAgICBzZWN0aW9uIDUuNC4xLiAgDQoNCiAgICAg ICAgbyAgVHlwZSAoT0FNLUxvb3BiYWNrLVRlc3QtUGFyYW1ldGVycyA9IDB4MDcpOiBQYXJhbWV0 ZXJzIHJlbGF0ZWQgdG8gIA0KICAgICAgICAgICBsb29wYmFjayB0ZXN0LiBUaGlzIGlzIGFuIG9w dGlvbmFsIFRMVi4gSWYgdGhpcyBUTFYgaXMgbm90IHByZXNlbnQgDQogICAgICAgICAgIGluIHRo ZSByZXF1ZXN0IG1lc3NhZ2UsIHRoZSBEU0xBTSBTSE9VTEQgdXNlIGxvY2FsbHkgZGV0ZXJtaW5l ZCANCiAgICAgICAgICAgZGVmYXVsdCB2YWx1ZXMgZm9yIHRoZSB0ZXN0IHBhcmFtZXRlcnMuICAN Cg0KICAgICAgICAgICBMZW5ndGg6IDQgYnl0ZXMgDQoNCiAgICAgICAgICAgVmFsdWUgIDogdHdv IDEgYnl0ZSBudW1iZXJzIGRlc2NyaWJlZCBiZWxvdyAobGlzdGVkIGluIG9yZGVyIG9mIA0KICAg ICAgICAgICBtb3N0IHRvIGxlYXN0ICBzaWduaWZpY2FudCkuIFRodXMsIHRoZSA0IGJ5dGVzIGNv bnNpc3Qgb2YgMSBieXRlIA0KICAgICAgICAgICBvZiBDb3VudCwgZm9sbG93ZWQgYnkgMSBieXRl IG9mIFRpbWVvdXQsIGZvbGxvd2VkIGJ5IHR3byBwYWQgYnl0ZXMgDQogICAgICAgICAgIG9mIHpl cm8uIA0KDQogICAgICAgICAgICBvICBDb3VudCAoMSBieXRlKSA6IE51bWJlciBvZiBsb29wYmFj ayBjZWxscy9tZXNzYWdlcyB0aGF0IHNob3VsZCANCiAgICAgICAgICAgICAgIGJlIGdlbmVyYXRl ZCBvbiB0aGUgbG9jYWwgbG9vcCBhcyBwYXJ0IG9mIHRoZSBsb29wYmFjayB0ZXN0LiANCiAgICAg ICAgICAgICAgIFRoZSBOQVMgU0hPVUxEIHJlc3RyaWN0IHRoZSCTY291bnSUIHRvIGJlIGdyZWF0 ZXIgdGhhbiAwIGFuZCANCiAgICAgICAgICAgICAgIGxlc3MgdGhhbiBvciBlcXVhbCB0byAzMi4g VGhlIERTTEFNIFNIT1VMRCBkaXNjYXJkIHRoZSByZXF1ZXN0IA0KICAgICAgICAgICAgICAgZm9y IGEgbG9vcGJhY2sgdGVzdCwgaWYgdGhlIHJlY2VpdmVkIHRlc3QgcGFyYW1ldGVycyBjb250YWlu IA0KICAgICAgICAgICAgICAgYW4gb3V0IG9mIHJhbmdlIHZhbHVlIGZvciB0aGUgk2NvdW50lCBm aWVsZC4gVGhlIERTTEFNIE1BWSANCiAgICAgICAgICAgICAgIG9wdGlvbmFsbHkgc2VuZCBhIGZh aWx1cmUgcmVzcG9uc2UgdG8gdGhlIE5BUyB3aXRoIHRoZSBjb2RlIA0KICAgICAgICAgICAgICAg k2ludmFsaWQgdGVzdCBwYXJhbWV0ZXKULiAgICAgICAgIA0KDQogICAgICAgICAgICBvICBUaW1l b3V0ICgxIGJ5dGUpIDogVXBwZXIgYm91bmQgb24gdGhlIHRpbWUgaW4gc2Vjb25kcyB0aGF0IHRo ZSANCiAgICAgICAgICAgICAgIE5BUyB3b3VsZCB3YWl0IGZvciBhIHJlc3BvbnNlIGZyb20gdGhl IERTTEFNLiBJZiB0aGUgdG90YWwgDQogICAgICAgICAgICAgICB0aW1lIHRha2VuIGJ5IHRoZSBE U0xBTSB0byBjb21wbGV0ZSBhIHRlc3Qgd2l0aCByZXF1ZXN0ZWQgDQogICAgICAgICAgICAgICBw YXJhbWV0ZXJzLCBleGNlZWRzIHRoZSBzcGVjaWZpZWQgk3RpbWVvdXSUIHZhbHVlLCBpdCBjYW4g DQogICAgICAgICAgICAgICBjaG9vc2UgdG8gb21pdCB0aGUgZ2VuZXJhdGlvbiBvZiBhIHJlc3Bv bnNlIHRvIHRoZSBOQVMuIERTTEFNIA0KICAgICAgICAgICAgICAgU0hPVUxEIHVzZSBhIGxvY2Fs bHkgZGV0ZXJtaW5lZCB2YWx1ZSBmb3IgdGhlIJN0aW1lb3V0lCwgaWYgDQogICAgICAgICAgICAg ICB0aGUgcmVjZWl2ZWQgdmFsdWUgb2YgdGhlIJN0aW1lb3V0lCBwYXJhbWV0ZXIgaXMgMC4gDQoN CiAgICAgICAgICAgICAgDQoNCiAgICAgICAgbyAgVHlwZSAoT3BhcXVlLURhdGEgPSAweDA4KSA6 IFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWLiBJZiBwcmVzZW50IGluIA0KICAgICAgICAgICB0aGUg cmVxdWVzdCBtZXNzYWdlLCB0aGUgRFNMQU0gU0hPVUxEIHJlZmxlY3QgaXQgYmFjayBpbiB0aGUg DQogICAgICAgICAgIHJlc3BvbnNlIHVubW9kaWZpZWQuIA0KDQogICAgICAgICAgIExlbmd0aCA6 IDggYnl0ZXMgDQoNCg0KDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDMzXSANCiAg ICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXByb3Rv Y29sLTAwICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAgICAgIA0KDQogICAgICAgICAgIFZhbHVl IDogVHdvIDMyIGJpdCBpbnRlZ2VycyBpbnNlcnRlZCBieSB0aGUgTkFTIChub3QgdG8gYmUgDQog ICAgICAgICAgIGludGVycHJldGVkIGJ5IHRoZSBEU0xBTSwgYnV0IGp1c3QgcmVmbGVjdGVkIGJh Y2sgaW4gdGhlIA0KICAgICAgICAgICByZXNwb25zZSkuIA0KDQogICAgICAgIFRoZSBhY2Nlc3Mg bm9kZSBnZW5lcmF0ZXMgYSBzdWNjZXNzIG9yIGZhaWx1cmUgcmVzcG9uc2Ugd2hlbiBpdCBkZWVt cyANCiAgICAgICAgdGhlIGxvb3BiYWNrIHRlc3QgdG8gYmUgY29tcGxldGUuIJNQb3J0IE1hbmFn ZW1lbnSUIG1lc3NhZ2UgKHR5cGUgMzIpIA0KICAgICAgICBpcyB1c2VkLiBUaGUgcmVzdWx0IGZp ZWxkIFNIT1VMRCBiZSBzZXQgdG8gc3VjY2VzcyBvciBmYWlsdXJlLiBUaGUgDQogICAgICAgIGZ1 bmN0aW9uIHR5cGUgU0hPVUxEIGJlIHNldCB0byAweDA5LiBUaGUgdHJhbnNhY3Rpb24gSUQgU0hP VUxEIGJlIA0KICAgICAgICBjb3BpZWQgZnJvbSB0aGUgc2VxdWVuY2UgbnVtYmVyIGNvbnRhaW5l ZCBpbiB0aGUgY29ycmVzcG9uZGluZyANCiAgICAgICAgcmVxdWVzdC4gVGhlIG90aGVyIHBhcmFt ZXRlcnMgbm90IGV4cGxpY2l0bHkgZGVmaW5lZCBoZXJlIFNIT1VMRCBiZSANCiAgICAgICAgc2V0 IGFzIHNwZWNpZmllZCBpbiB0aGUgcmVxdWVzdCBtZXNzYWdlIGFib3ZlLiBUaGUgY29kZSBmaWVs ZCBTSE9VTEQgDQogICAgICAgIGJlIHNldCB0byBhIHZhbHVlIGluIHRoZSByYW5nZSAweDUwMCB0 byAweDVmZiAodG8gYmUgcmVzZXJ2ZWQgd2l0aCANCiAgICAgICAgSUFOQSkgdG8gaW5kaWNhdGUg dGhlIHN0YXR1cyBvZiB0aGUgZXhlY3V0ZWQgdGVzdC4gVGhlIHZhbGlkIHZhbHVlcyANCiAgICAg ICAgZGVmaW5lZCBhcmUgKGNhbiBiZSBleHRlbmRlZCBpbiBmdXR1cmUpOiANCg0KICAgICAgICAg ICAgICAweDUwMCA6IFNwZWNpZmllZCBhY2Nlc3MgbGluZSBkb2VzIG5vdCBleGlzdC4gDQoNCiAg ICAgICAgICAgICAgMHg1MDEgOiBMb29wYmFjayB0ZXN0IHRpbWVkIG91dC4gDQoNCiAgICAgICAg ICAgICAgMHg1MDIgOiBSZXNlcnZlZCANCg0KICAgICAgICAgICAgICAweDUwMyA6IERTTCBsaW5l IHN0YXR1cyBzaG93dGltZS4gDQoNCiAgICAgICAgICAgICAgMHg1MDQgOiBEU0wgbGluZSBzdGF0 dXMgaWRsZS4gDQoNCiAgICAgICAgICAgICAgMHg1MDUgOiBEU0wgbGluZSBzdGF0dXMgc2lsZW50 LiANCg0KICAgICAgICAgICAgICAweDUwNiA6IERTTCBsaW5lIHN0YXR1cyB0cmFpbmluZy4gDQoN CiAgICAgICAgICAgICAgMHg1MDcgOiBEU0wgbGluZSBpbnRlZ3JpdHkgZXJyb3IuIA0KDQogICAg ICAgICAgICAgIDB4NTA4IDogRFNMQU0gcmVzb3VyY2Ugbm90IGF2YWlsYWJsZS4gDQoNCiAgICAg ICAgICAgICAgMHg1MDkgOiBJbnZhbGlkIHRlc3QgcGFyYW1ldGVyLiANCg0KICAgICBUaGUgRXh0 ZW5zaW9uIHZhbHVlIGNhbiBjb250YWluIG9uZSBvciBtb3JlIFRMVnMgaW5jbHVkaW5nIHRoZSBU TFYgdG8gDQogICAgIGlkZW50aWZ5IHRoZSBhY2Nlc3MgbGluZSBvbiB3aGljaCB0aGUgdGVzdCB3 YXMgcGVyZm9ybWVkLCBhbmQgZGV0YWlscyANCiAgICAgZnJvbSBleGVjdXRpbmcgdGhlIHRlc3Qu IFRoZSBhY2Nlc3MgbGluZSBpZGVudGlmaWVyIFNIT1VMRCBiZSBpZGVudGljYWwgDQogICAgIHRv IHdoYXQgd2FzIGNvbnRhaW5lZCBpbiB0aGUgcmVxdWVzdC4gVGhlIHJlbGV2YW50IFRMVnMgYXJl OiANCg0KICAgICAgICBvICBUeXBlIChBY2Nlc3MtTG9vcC1DaXJjdWl0LUlEID0gMHgwMSkgOiBk ZWZpbmVkIGluIHNlY3Rpb24gNS40LjEgIA0KDQogICAgICAgIG8gIFR5cGUgKEFjY2Vzcy1BZ2dy ZWdhdGlvbi1DaXJjdWl0LUlELUJpbmFyeSA9IDB4MDYpOiBkZWZpbmVkIGluIA0KICAgICAgICAg ICBzZWN0aW9uIDUuNC4xLiANCg0KICAgICAgICBvICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24t Q2lyY3VpdC1JRC1BU0NJSSA9IDB4MDMpOiBkZWZpbmVkIGluIA0KICAgICAgICAgICBzZWN0aW9u IDUuNC4xLiAgDQogICAgICANCiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDM0XSANCiAgICAgICAg IA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICAgZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAw ICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAgICAgIA0KDQogICAgICAgIG8gIFR5cGUgKE9wYXF1 ZS1EYXRhID0gMHgwOCkgOiBEYXRhIGluc2VydGVkIGJ5IHRoZSBOQVMgaW4gdGhlIA0KICAgICAg ICAgICByZXF1ZXN0IHJlZmxlY3RlZCBiYWNrIGJ5IHRoZSBEU0xBTS4gDQoNCiAgICAgICAgICAg TGVuZ3RoIDogOCBieXRlcyANCg0KICAgICAgICAgICBWYWx1ZSA6IFR3byAzMiBiaXQgaW50ZWdl cnMgYXMgcmVjZWl2ZWQgaW4gdGhlIHJlcXVlc3QgKG9wYXF1ZSB0byANCiAgICAgICAgICAgdGhl IERTTEFNKS4gDQoNCiAgICAgICAgbyAgVHlwZSAoT0FNLUxvb3BiYWNrLVRlc3QtUmVzcG9uc2Ut U3RyaW5nID0gMHgwOSkgDQoNCiAgICAgICAgICAgTGVuZ3RoICh1cHRvIDEyOCBieXRlcykgDQoN CiAgICAgICAgICAgVmFsdWUgOiBTdWl0YWJseSBmb3JtYXR0ZWQgQVNDSUkgc3RyaW5nIGNvbnRh aW5pbmcgdXNlZnVsIGRldGFpbHMgDQogICAgICAgICAgIGFib3V0IHRoZSB0ZXN0IHRoYXQgdGhl IE5BUyB3aWxsIGRpc3BsYXkgZm9yIHRoZSBvcGVyYXRvciwgZXhhY3RseSANCiAgICAgICAgICAg YXMgcmVjZWl2ZWQgZnJvbSB0aGUgRFNMQU0gKG5vIG1hbmlwdWxhdGlvbi9pbnRlcnByZXRhdGlv biBieSB0aGUgDQogICAgICAgICAgIE5BUykuIFRoaXMgaXMgYW4gb3B0aW9uYWwgVExWLCBidXQg aXQgaXMgc3Ryb25nbHkgcmVjb21tZW5kZWQsIA0KICAgICAgICAgICB0aGF0IGluIGNhc2Ugb2Yg QVRNIGJhc2VkIGxvY2FsIGxvb3AsIHRoZSBEU0xBTSBhdCB0aGUgdmVyeSBsZWFzdCANCiAgICAg ICAgICAgaW5kaWNhdGVzIHZpYSB0aGlzIFRMViwgdGhlIHRvdGFsIGxvb3BiYWNrIGNlbGxzIGdl bmVyYXRlZCBhbmQgdGhlIA0KICAgICAgICAgICB0b3RhbCBsb29wYmFjayBjZWxscyBzdWNjZXNz ZnVsbHkgcmVjZWl2ZWQgYXMgcGFydCBvZiBleGVjdXRpbmcgDQogICAgICAgICAgIHRoZSByZXF1 ZXN0ZWQgbG9vcGJhY2sgdGVzdC4gICAgICANCg0KICAgICAgICAgICAgIA0KDQogICAgIDUuNSBB VE0tc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgDQoNCiAgICAgICAgVGhlIHRvcG9sb2d5IGRpc2Nv dmVyeSBhbmQgbGluZSBjb25maWd1cmF0aW9uIGludm9sdmUgdGhlIERTTCBsaW5lIA0KICAgICAg ICBhdHRyaWJ1dGVzLiBGb3IgQVRNIGJhc2VkIGFjY2VzcyBuZXR3b3JrcywgdGhlIERTTCBsaW5l IG9uIHRoZSBEU0xBTSANCiAgICAgICAgaXMgaWRlbnRpZmllZCBieSB0aGUgcG9ydCBhbmQgUFZQ L1BWQyBjb3JyZXNwb25kaW5nIHRvIHRoZSANCiAgICAgICAgc3Vic2NyaWJlci4gVGhlIERTTEFN cyBhcmUgY29ubmVjdGVkIHRvIHRoZSBOQVMgdmlhIGFuIEFUTSBhY2Nlc3MgDQogICAgICAgIGFn Z3JlZ2F0aW9uIG5ldHdvcmsuIFNpbmNlLCB0aGUgICBEU0xBTSAoYWNjZXNzLW5vZGUpIGlzIG5v dCBkaXJlY3RseSANCiAgICAgICAgY29ubmVjdGVkIHRvIHRoZSBOQVMsIHRoZSBOQVMgbmVlZHMg YSBtZWNoYW5pc20gdG8gbGVhcm4gdGhlIERTTCBsaW5lIA0KICAgICAgICBpZGVudGlmaWVyICht b3JlIGdlbmVyYWxseSByZWZlcnJlZCB0byBhcyAiQWNjZXNzIExvb3AgQ2lyY3VpdC1JRCIpIA0K ICAgICAgICBjb3JyZXNwb25kaW5nIHRvIGEgc3Vic2NyaWJlci4gVGhlICJBY2Nlc3MgbG9vcCBj aXJjdWl0LUlEIiBoYXMgbm8gDQogICAgICAgIGxvY2FsIHNpZ25pZmljYW5jZSBvbiB0aGUgTkFT LiBUaGUgQU5DUCBtZXNzYWdlcyBmb3IgdG9wb2xvZ3kgDQogICAgICAgIGRpc2NvdmVyeSBhbmQg bGluZSBjb25maWd1cmF0aW9uIGNhcnJ5IG9wYXF1ZSAiQWNjZXNzIGxvb3AgQ2lyY3VpdC0NCiAg ICAgICAgSUQiIHdoaWNoIGhhcyBvbmx5IGxvY2FsIHNpZ25pZmljYW5jZSBvbiB0aGUgRFNMQU1z LiAgDQoNCiAgICAgICAgVGhlIGFjY2VzcyBsb29wIGNpcmN1aXQgaWRlbnRpZmllciBjYW4gYmUg Y2FycmllZCBhcyBhbiBBU0NJSSBzdHJpbmcgDQogICAgICAgIGluIHRoZSBBTkNQIG1lc3NhZ2Vz LiBUaGlzIGFsbG93cyBBTkNQIHRvIGJlIGRlY291cGxlZCBmcm9tIHRoZSANCiAgICAgICAgc3Bl Y2lmaWNzIG9mIHRoZSB1bmRlcmx5aW5nIGFjY2VzcyB0ZWNobm9sb2d5IGJlaW5nIGNvbnRyb2xs ZWQuIE9uIA0KICAgICAgICB0aGUgb3RoZXIgaGFuZCwgdGhpcyByZXF1aXJlcyBhIE5BUyBtZWNo YW5pc20gYnkgd2hpY2ggc3VjaCANCiAgICAgICAgaWRlbnRpZmllciBjYW4gYmUgY29ycmVsYXRl ZCB0byB0aGUgY29udGV4dCBvZiBhbiCTYWdncmVnYXRpb24gDQogICAgICAgIG5ldHdvcmuUIGZh Y2luZyBJUCBpbnRlcmZhY2UgKGNvcnJlc3BvbmRpbmcgdG8gdGhlIHN1YnNjcmliZXIpIG9uIHRo ZSANCiAgICAgICAgTkFTLiBUaGlzIHdvdWxkIHR5cGljYWxseSByZXF1aXJlIGxvY2FsIGNvbmZp Z3VyYXRpb24gb2Ygc3VjaCBJUCANCiAgICAgICAgaW50ZXJmYWNlcywgb3Igb2YgdGhlIHVuZGVy bHlpbmcgQVRNIGludGVyZmFjZXMuICANCg0KICAgICAgICAgDQogICAgICANCiAgICAgIA0KICAg ICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDM1XSANCiAgICAgICAgIA0KDCAgICAgSW50ZXJuZXQtRHJhZnQgICAgICAg ZHJhZnQtaWV0Zi1hbmNwLXByb3RvY29sLTAwICAgICAgICBBdWd1c3QgMjAwNyANCiAgICAgICAg IA0KDQogICAgIDUuNiBFdGhlcm5ldC1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucyANCg0KICAgICBP bmUgcG9zc2libGUgd2F5IG9mIGFwcHJvYWNoaW5nIHRoZSB1c2Ugb2YgRXRoZXJuZXQgdGVjaG5v bG9neSBpbiB0aGUgDQogICAgIGFjY2VzcyBhZ2dyZWdhdGlvbiBuZXR3b3JrIGlzIHRvIHJlY3Jl YXRlIHRoZSBlcXVpdmFsZW50IG9mIFZpcnR1YWwgDQogICAgIFBhdGhzIChWUHMpIGFuZCBWaXJ0 dWFsIENpcmN1aXRzIChWQ3MpIGJ5IHVzaW5nIHN0YWNrZWQgVmlydHVhbCBMQU4gDQogICAgIHRh Z3MuIEFzIGFuIGV4YW1wbGUsIG9uZSBjb3VsZCB1c2UgYW4gk291dGVylCBWTEFOIHRvIGNyZWF0 ZSBhIGZvcm0gb2YgDQogICAgIJN2aXJ0dWFsIHBhdGiUIGJldHdlZW4gYSBnaXZlbiBEU0xBTSBh bmQgYSBnaXZlbiBOQVMuIEFuZCB0aGVuIHVzZSANCiAgICAgk2lubmVylCBWTEFOIHRhZ3MgdG8g Y3JlYXRlIGEgZm9ybSBvZiCTdmlydHVhbCBjaXJjdWl0lCBvbiBhIHBlciBEU0wgDQogICAgIGxp bmUgYmFzaXMuIEluIHRoaXMgY2FzZSwgVkxBTiB0YWdzIGNvbnZleWVkIGluIHRvcG9sb2d5IGRp c2NvdmVyeSBhbmQgDQogICAgIGxpbmUgY29uZmlndXJhdGlvbiBtZXNzYWdlcyB3aWxsIGFsbG93 IHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBEU0wgbGluZSANCiAgICAgaW4gYSBzdHJhaWdodGZv cndhcmQgbWFubmVyLCBhc3N1bWluZyB0aGUgVkxBTiB0YWdzIGFyZSBub3QgdHJhbnNsYXRlZCAN CiAgICAgaW4gc29tZSB3YXkgYnkgdGhlIGFnZ3JlZ2F0aW9uIG5ldHdvcmssIGFuZCBhcmUgdW5p cXVlIGFjcm9zcyBwaHlzaWNhbCANCiAgICAgcG9ydHMuIA0KICAgICAgDQogICAgIEhvd2V2ZXIs IHNvbWUgY2FycmllcnMgZG8gbm90IHdpc2ggdG8gdXNlIHRoaXMgk2Nvbm5lY3Rpb24gb3JpZW50 ZWSUIA0KICAgICBhcHByb2FjaC4gVGhlcmVmb3JlLCBhbiBhbHRlcm5hdGl2ZSBtb2RlbCBpcyB0 byBicmlkZ2Ugc2Vzc2lvbnMgZnJvbSANCiAgICAgbXVsdGlwbGUgc3Vic2NyaWJlcnMgYmVoaW5k IGEgRFNMQU0gdG8gYSBzaW5nbGUgVkxBTiBpbiB0aGUgYWdncmVnYXRpb24gDQogICAgIG5ldHdv cmsuIFRoaXMgaXMgdGhlIE46MSBtb2RlbC4gSW4gdGhpcyBtb2RlbCwgb3IgaW4gdGhlIGNhc2Ug d2hlcmUgdXNlciANCiAgICAgdHJhZmZpYyBpcyBzZW50IHVudGFnZ2VkLCB0aGUgYWNjZXNzIG5v ZGUgbmVlZHMgdG8gaW5zZXJ0IHRoZSBleGFjdCANCiAgICAgaWRlbnRpdHkgb2YgdGhlIERTTCBs aW5lIGluIHRoZSB0b3BvbG9neSBkaXNjb3ZlcnkgYW5kIGxpbmUgDQogICAgIGNvbmZpZ3VyYXRp b24gbWVzc2FnZXMsIGFuZCB0aGVuIGhhdmUgYSBtZWNoYW5pc20gYnkgd2hpY2ggdGhpcyBjYW4g YmUgDQogICAgIGNvcnJlbGF0ZWQgdG8gdGhlIGNvbnRleHQgb2YgYW4gk2FnZ3JlZ2F0aW9uIG5l dHdvcmuUIGZhY2luZyBJUCANCiAgICAgaW50ZXJmYWNlIChmb3IgdGhlIHN1YnNjcmliZXIpIG9u IHRoZSBOQVMuIFRoaXMgY2FuIGVpdGhlciBiZSBiYXNlZCBvbiANCiAgICAgbG9jYWwgY29uZmln dXJhdGlvbiBvbiB0aGUgTkFTLCBvciBvbiB0aGUgZmFjdCB0aGF0IHN1Y2ggRFNMQU0gKGFjY2Vz cyANCiAgICAgbm9kZSkgdHlwaWNhbGx5IGluc2VydHMgdGhlIJNBY2Nlc3MgTG9vcCBDaXJjdWl0 IElElCBpbiBzdWJzY3JpYmVyIA0KICAgICBzaWduYWxpbmcgbWVzc2FnZXMgcmVsYXllZCB0byB0 aGUgTkFTIChpLmUuIERIQ1Agb3IgUFBQb0UgZGlzY292ZXJ5IA0KICAgICBtZXNzYWdlcykuIA0K ICAgICAgIA0KICAgICBTZWN0aW9uIDUuNC4xIGRlZmluZXMgk0FjY2VzcyBMb29wIENpcmN1aXQg SUSULiAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KICAgICA2ICBJQU5BIENvbnNpZGVyYXRpb25zIA0KDQog ICAgICAgIE5ldyBUZWNoLVR5cGUsIGNhcGFiaWxpdHkgdHlwZXMsIHN1Yi1UTFYgdHlwZXMgcmVs YXRlZCB0byB0b3BvbG9neSANCiAgICAgICAgZGlzY292ZXJ5IGFuZCBsaW5lIGNvbmZpZ3VyYXRp b24gd2lsbCBuZWVkIHRvIGJlIHJlc2VydmVkLiANCg0KICAgICA3ICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyANCg0KICAgICAgICBUaGUgTkFTIGFuZCBEU0xBTXMgYXJlIGltcGxpY2l0bHkgaW4g YSB0cnVzdGVkIGRvbWFpbiwgc28gc2VjdXJpdHkgICAgICAgIA0KICAgICAgICBmb3IgQU5DUCBp cyBub3QgYSBzdHJvbmcgcmVxdWlyZW1lbnQuIEhvd2V2ZXIsIGlmIG5lZWRlZCBzZWN1cml0eSBj YW4gDQogICAgICAgIGJlIHByb3ZpZGVkIHVzaW5nIElQIHNlY3VyaXR5IGFzIGluZGljYXRlZCBp biBbUkZDMzI5M10uICANCg0KICAgICAgICAgDQoNCg0KDQoNCiAgICAgIA0KICAgICAgDQogICAg IFdhZGh3YSBldC5hbCAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAg ICAgICAgW1BhZ2UgMzZdIA0KICAgICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBk cmFmdC1pZXRmLWFuY3AtcHJvdG9jb2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAg DQoNCiAgICAgOCAgUmVmZXJlbmNlcyANCg0KICAgICAgICBbMV0gICBEU0xGb3J1bSBUUi0wNTks IERTTCBFdm9sdXRpb24gLSBBcmNoaXRlY3R1cmUgUmVxdWlyZW1lbnRzIGZvciANCiAgICAgICAg ICAgICAgdGhlIFN1cHBvcnQgb2YgUW9TLUVuYWJsZWQgSVAgU2VydmljZXMsIFRvbSBBbnNjaHV0 eiAoQmVsbFNvdXRoIA0KICAgICAgICAgICAgICBUZWxlY29tbXVuaWNhdGlvbnMpLCAwOS8yMDAz LiANCg0KICAgICAgICBbMl0gICBEU0xGb3J1bSBUUi0wNTgsIE11bHRpLVNlcnZpY2UgQXJjaGl0 ZWN0dXJlICYgRnJhbWV3b3JrIA0KICAgICAgICAgICAgICBSZXF1aXJlbWVudHMsIE1hcmsgRWxp YXMgKFNCQykgYW5kIFN2ZW4gT29naGUgKEFsY2F0ZWwpLCANCiAgICAgICAgICAgICAgMDkvMjAw My4gDQoNCiAgICAgICAgWzNdICAgRFNMRm9ydW0gVFItMDkyLCBCcm9hZGJhbmQgUmVtb3RlIGFj Y2VzcyBzZXJ2ZXIgcmVxdWlyZW1lbnRzIA0KICAgICAgICAgICAgICBkb2N1bWVudC4gDQoNCiAg ICAgICAgWzRdICAgRG9yaWEsIEEuIGV0IGFsLCAiR2VuZXJhbCBTd2l0Y2ggTWFuYWdlbWVudCBQ cm90b2NvbC0gVjMiIChHU01QIA0KICAgICAgICAgICAgICB2MyksIFJGQyAzMjkyLCBKdW5lIDIw MDIuIA0KDQogICAgICAgIFs1XSAgIFdvcnN0ZXIsIFQuLCBEb3JpYSwgQS4gYW5kIEouIEJ1ZXJr bGUsICJHZW5lcmFsIFN3aXRjaCANCiAgICAgICAgICAgICAgTWFuYWdlbWVudCBQcm90b2NvbCAo R1NNUCkgUGFja2V0IEVuY2Fwc3VsYXRpb25zIGZvciANCiAgICAgICAgICAgICAgQXN5bmNocm9u b3VzIFRyYW5zZmVyIE1vZGUgKEFUTSksIEV0aGVybmV0IGFuZCBUcmFuc21pc3Npb24gDQogICAg ICAgICAgICAgIENvbnRyb2wgUHJvdG9jb2wgKFRDUCkiLCBSRkMgMzI5MywgSnVuZSAyMDAyLiAN Cg0KICAgICAgICBbNl0gICBHU01QIGV4dGVuc2lvbnMgZm9yIEFOQ1AgLSBUcmFuc2FjdGlvbmFs IE11bHRpY2FzdCwgZHJhZnQtDQogICAgICAgICAgICAgIG1vaXNhbmQtZ3NtcC1hbmNwLW11bHRp Y2FzdC0wMCAod29yayBpbiBwcm9ncmVzcykuIA0KDQogICAgICAgIFs3XSAgIJNESENQIFJlbGF5 IEFnZW50IEluZm9ybWF0aW9uIE9wdGlvbpQsIFJGQyAzMDQ2LCBKYW51YXJ5IDIwMDEuIA0KDQog ICAgICAgIFs4XSAgIEFyY2hpdGVjdHVyZSAmIFRyYW5zcG9ydDogTWlncmF0aW9uIHRvIEV0aGVy bmV0IEJhc2VkIERTTCANCiAgICAgICAgICAgICAgQWdncmVnYXRpb24sIERTTCBGb3J1bSBXVC0x MDEsIENvaGVuIGV0IGFsLiAgDQoNCiAgICAgICAgWzldICAgRnJhbWV3b3JrIGZvciBBY2Nlc3Mg Tm9kZSBDb250cm9sIE1lY2hhbmlzbSBpbiBCcm9hZGJhbmQgDQogICAgICAgICAgICAgIE5ldHdv cmtzLCBkcmFmdC1pZXRmLWFuY3AtZnJhbWV3b3JrLTAwLnR4dC4gDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCiAgICAgIA0KICAgICAgDQogICAgIFdhZGh3YSBldC5hbCAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzddIA0KICAg ICAgICAgDQoMICAgICBJbnRlcm5ldC1EcmFmdCAgICAgICBkcmFmdC1pZXRmLWFuY3AtcHJvdG9j b2wtMDAgICAgICAgIEF1Z3VzdCAyMDA3IA0KICAgICAgICAgDQoNCiAgICAgQXV0aG9yJ3MgQWRk cmVzc2VzIA0KDQogICAgICAgIFNhbmpheSBXYWRod2EgIA0KICAgICAgICBKdW5pcGVyIE5ldHdv cmtzIA0KICAgICAgICAxMCBUZWNobm9sb2d5IFBhcmsgRHJpdmUgDQogICAgICAgIFdlc3Rmb3Jk LCBNQSAwMTg4NiANCiAgICAgICAgIA0KICAgICAgICBFbWFpbDogc3dhZGh3YUBqdW5pcGVyLm5l dCANCiAgICAgICAgICAgIA0KICAgICAgICBKZXJvbWUgTW9pc2FuZCANCiAgICAgICAgSnVuaXBl ciBOZXR3b3JrcyANCiAgICAgICAgMTAgVGVjaG5vbG9neSBQYXJrIERyaXZlIA0KICAgICAgICBX ZXN0Zm9yZCwgTUEgMDE4ODYgDQogICAgICAgICANCiAgICAgICAgICAgIA0KICAgICAgICBFbWFp bDogam1vaXNhbmRAanVuaXBlci5uZXQgDQogICAgICAgICANCiAgICAgICAgU3dhbWkgU3VicmFt YW5pYW4gDQogICAgICAgIEp1bmlwZXIgTmV0d29ya3MgDQogICAgICAgIDEwIFRlY2hub2xvZ3kg UGFyayBEcml2ZSANCiAgICAgICAgV2VzdGZvcmQsIE1BIDAxODg2IA0KICAgICAgICAgDQogICAg ICAgICAgICANCiAgICAgICAgRW1haWw6IHNzdWJyYW1hbmlhbkBqdW5pcGVyLm5ldCANCiAgICAg ICAgIA0KICAgICAgICBUaG9tYXMgSGFhZyANCiAgICAgICAgVC1zeXN0ZW1zIA0KICAgICAgICAg DQogICAgICAgIEVtYWlsOiB0aG9tYXMuaGFhZ0B0LXN5c3RlbXMuY29tIA0KICAgICAgICAgDQog ICAgICAgIE5vcmJlciBWb2lndCANCiAgICAgICAgU2llbWVucyANCiAgICAgICAgIA0KICAgICAg ICBFbWFpbDogbm9yYmVydC52b2lndEBzaWVtZW5zLmNvbSANCiAgICAgICAgIA0KICAgICANCiAg RnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1 c3QgKDIwMDcpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywg bGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4 Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAgIHJldGFpbiBhbGwgdGhl aXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBD T05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMg U1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYgVFJV U1QgQU5EDQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBB TEwgV0FSUkFOVElFUywgRVhQUkVTUw0KICAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1Qg TElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GDQogICBUSEUgSU5GT1JNQVRJ T04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAg IFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFLg0KDQoNCiAgSW50ZWxsZWN0dWFsIFByb3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQog ICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0 IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3Ig bWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz DQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmln aHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byBy aWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQ IDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2Vj cmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2 YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBh IGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHBy b3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3Bl Y2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBv c2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52 aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0K ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkg YmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4N CiANCg0KICBBY2tub3dsZWRnbWVudCAgICAgDQoNCiAgICBUaGFua3MgdG8gUGV0ZXIgQXJiZXJn LCBKb3NlZiBGcm9laGxlciwgRGVyZWsgSGFya25lc3MsIEtpbSANCiAgICBIeWxkZ2FhcmQsIFNh bmR5IE5nLCBSb2JlcnQgUGVzY2hpLCBhbmQgTWljaGVsIFBsYXRuaWMgZm9yIHRoZWlyIA0KICAg IGlucHV0IHRvIHRoaXMgZG9jdW1lbnQuICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgICAN CiAgICAgIA0KICAgICBXYWRod2EgZXQuYWwgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI1LCAy MDA3ICAgICAgICAgICAgICAgIFtQYWdlIDM5XSANCiAgICAgICAgIA0KDA== ------_=_NextPart_001_01C76630.1D00B567 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 ------_=_NextPart_001_01C76630.1D00B567-- From ancp-bounces@ietf.org Wed Mar 14 09:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTtQ-0004oO-EW; Wed, 14 Mar 2007 09:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTtP-0004o3-C1 for ancp@ietf.org; Wed, 14 Mar 2007 09:51:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTtE-00017z-Af for ancp@ietf.org; Wed, 14 Mar 2007 09:51:51 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2007 14:51:39 +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 l2EDpd30016578; Wed, 14 Mar 2007 14:51:39 +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 l2EDpdlZ018055; Wed, 14 Mar 2007 13:51:39 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); Wed, 14 Mar 2007 14:51:39 +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 MIB Date: Wed, 14 Mar 2007 14:51:32 +0100 Message-ID: In-Reply-To: <45F7B3CD.5070806@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP MIB Thread-Index: AcdmE+uOsE9/GP7EQjm7QrcRPmm20wAK6mdA From: "Wojciech Dec \(wdec\)" To: , X-OriginalArrivalTime: 14 Mar 2007 13:51:39.0500 (UTC) FILETIME=[E3D972C0:01C7663F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=595; t=1173880299; x=1174744299; 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]=20ANCP=20MIB |Sender:=20; bh=mXM0FpEvbR31TAZzwDWITKLf2GYPdfh/LA9dAsPMMKI=; b=DsV3TM59vtATa43ldgUodlkjPXgkMCzYMCdAc9RjaetXc7GHhXmjzSzSoMTzyYlUXaz7AFti ztmG8QbcXOow1VpxCnA1K6h4kRmYEzJ3/uRwsRPEYJPLXlVXBLHhZd4R; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Strange, the boiler plate you used appears to be the correct one. Did you get notice from the editor as to why the draft wasn't accepted? -Woj.=20 -----Original Message----- From: stefaan.de_cnodder@alcatel-lucent.be [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: 14 March 2007 09:35 To: ancp@ietf.org Subject: [ANCP] ANCP MIB Hi, The updated ANCP MIB was submitted to the IETF in time but for some reason it never appeared on i-d-annound. Therefore I sent the updated draft as attachement to this mailing list. Comments are very welcome. regards, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Mar 14 10:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRU63-0006cl-M5; Wed, 14 Mar 2007 10:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRU62-0006cg-Jp for ancp@ietf.org; Wed, 14 Mar 2007 10:04:54 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRU61-0004v4-CM for ancp@ietf.org; Wed, 14 Mar 2007 10:04:54 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E513179FF8B; Wed, 14 Mar 2007 07:04:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06811-04; Wed, 14 Mar 2007 07:04:52 -0700 (PDT) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 5B6C279FF87; Wed, 14 Mar 2007 07:04:49 -0700 (PDT) Message-ID: <45F80101.9090707@redback.com> Date: Wed, 14 Mar 2007 07:04:49 -0700 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sanjay Wadhwa References: <9BD5D7887235424FA97DFC223CAE3C2807AE51F1@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2807AE51F1@proton.jnpr.net> 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.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ancp@ietf.org Subject: [ANCP] Re: draft-ietf-ancp-protocol-00.txt 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 diff ? Sanjay Wadhwa wrote: > Ditto with the updated protocol draft attached here, that was submitted > to the IETF before the cutoff. The name, title and version have been > changed to reflect it as a WG draft. > > Thanks > -Sanjay -- Jakob Heitz. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Mar 14 10:05:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRU6X-0006fq-81; Wed, 14 Mar 2007 10:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRU6W-0006fd-BZ for ancp@ietf.org; Wed, 14 Mar 2007 10:05:24 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRU6U-000549-QL for ancp@ietf.org; Wed, 14 Mar 2007 10:05:24 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l2EE5MWT023245 for ; Wed, 14 Mar 2007 15:05:22 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l2EE5LxI019203 for ; Wed, 14 Mar 2007 15:05:21 +0100 Received: from MCHP7RCA.ww002.siemens.net ([139.25.131.170]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:05:21 +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 in ANCP Date: Wed, 14 Mar 2007 15:05:23 +0100 Message-ID: In-Reply-To: <45F66D6F.80103@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: AcdlUUB6RSQjBdd3QBuVBqLg99h4VwA6IU0A References: <45F66D6F.80103@alcatel-lucent.be> From: "Voigt, Norbert" To: X-OriginalArrivalTime: 14 Mar 2007 14:05:21.0612 (UTC) FILETIME=[CDDDC8C0:01C76641] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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, I fully support Sven's view saying there seems to be a need for controling multicast content at the Access Node, i.e.: 1)For enabling multicast at AN ports, ACLs shall be provided per AN port. The ACL shall contain multicast entitlement data in order to provide dedicated IP multicast groups to the user. I also support the idea to configure these ACLs by means of ANCP at DHCP/PPPoE session start/stop. 2)Regarding the reporting function Wojciech proposed, I have difficulties seeing the need for it. I would prefer the IGMP query mechanism to gain knowledge of the per port multicast replication state on the Access Node. 3)Regarding the use of ANCP for configuration of the L2 replication state without IGMP procesing for some dedicated ports, I'm not very supportive. I would like to see whether the intended use case could be covered by the already mentioned ACLs to allow/disallow mc content to be sent to that port. Regards, Norbert. Matthew.Bocci@alcatel-lucent.co.uk wrote: > I would like to start a discussion on what the working group would like to > do with Multicast in ANCP. >=20 > Currently the ANCP charter includes multicast as one of the use cases, as > follows: >=20 > "When multicast replication for subscriber-bound traffic is performed at > the AN, it off-loads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow the AN > to perform subscriber bound multicast group replication in line with the > subscriber's policy and configuration, and also allow the NAS to follow > each subscriber's multicast group membership." >=20 > The framework draft (draft-ietf-ancp-framework-01.txt) says that the access > loop configuration mechanisms may be useful for setting the per-Subscriber > multicast channel entitlement information, used for IPTV applications where > the Access Node is performing IGMP snooping or IGMP proxy function. It goes > on to say that a Subscriber's policy and configuration for multicast > traffic might only be known at the NAS. The Access Node Control Mechanism > could be used to exchange the necessary information between the Access Node > and the NAS so as to allow the Access Node to perform multicast replication > in line with the Subscriber's policy and configuration, and also allow the > NAS to follow each Subscriber's multicast group membership. >=20 >=20 > None of these multicast mechanisms are defined in the ANCP protocol draft, > and I think there is insufficient detail in the framework draft to fully > specify this use case. >=20 > There has been very little work on this since the charter discussions, but > the ANCP working group needs to clarify what it wants to do (if anything) > with multicast for the framework can move forward. I think there are two > choices: Either we should clarify the use case and specify the ANCP > protocol to support it, or we should remove the multicast use case from the > framework for now. >=20 > Please post your opinions to the list. We plan to have a discussion on this > in Prague, and to try to reach a consensus at around that time. >=20 > Best regards, >=20 > Matthew >=20 >=20 >=20 >=20 >=20 >=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 Wed Mar 14 10:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUp1-0001ZF-NB; Wed, 14 Mar 2007 10:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUp0-0001ZA-SV for ancp@ietf.org; Wed, 14 Mar 2007 10:51:22 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRUox-0006GH-JK for ancp@ietf.org; Wed, 14 Mar 2007 10:51:22 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Mar 2007 07:51:19 -0700 X-IronPort-AV: i="4.14,284,1170662400"; d="scan'208"; a="690360830:sNHT41642252" 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: Wed, 14 Mar 2007 10:51:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2807AE52CA@proton.jnpr.net> In-Reply-To: <45F80101.9090707@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ancp-protocol-00.txt Thread-Index: AcdmQcYQuOozFdGzTw6CfOJRoHYnmgABPvoA From: "Sanjay Wadhwa" To: "Jakob Heitz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ancp@ietf.org Subject: [ANCP] RE: draft-ietf-ancp-protocol-00.txt 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 Nothing significant. The update mainly includes the following: 1. Title and Name change. Note, that it is version 00 now due to the name change.=20 2. Changed references to BRAS with NAS (in accordance with standard ANCP terminology). 3. Removed some text in several sections that appeared in the framework draft. The framework draft came into existence much after the protocol draft resulting in some overlap. I have provided references to the framework draft as necessary. However, in order to provide minimal context, I had to leave some text for each use case.=20 4. Clarified text in section 5.4.4 for "OAM-Loopback-Test-Parameters'" TLV's value field as discussed on the mailing list. -Sanjay -----Original Message----- From: Jakob Heitz [mailto:jheitz+020707@redback.com]=20 Sent: Wednesday, March 14, 2007 10:05 AM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: Re: draft-ietf-ancp-protocol-00.txt diff ? Sanjay Wadhwa wrote: > Ditto with the updated protocol draft attached here, that was submitted > to the IETF before the cutoff. The name, title and version have been > changed to reflect it as a WG draft. > > Thanks > -Sanjay --=20 Jakob Heitz. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Mar 14 11:41:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVbK-0002EX-Tn; Wed, 14 Mar 2007 11:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVbJ-0002E7-GP for ancp@ietf.org; Wed, 14 Mar 2007 11:41:17 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRVbH-0000Ig-Pb for ancp@ietf.org; Wed, 14 Mar 2007 11:41:17 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Wed, 14 Mar 2007 16:41:12 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 16:40:50 +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] Multicast in ANCP Date: Wed, 14 Mar 2007 16:45:13 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED201E66CB7@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgAHFGe0A= References: From: "Haag, T" To: X-OriginalArrivalTime: 14 Mar 2007 15:40:50.0699 (UTC) FILETIME=[24AB15B0:01C7664F] X-Spam-Score: 2.3 (++) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: "Busser, M" 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, Thanks for pointing out several options dealing with ANCP and Multicast. Some points are interesting raising new requirements, some points = bringing up new concerns regarding interoperability AN/NAS, extending = the existing charter by introducing new requirements which may have = impact to already existing requirements and use cases. ANCP can do many = things but the operational impact as well as impact on interaction = between NAS and AN which is out of scope of a protocol specification but = needs to be taken into account too. Below I tried to summarize it step by step: 1. I support option 1 enabling MC per AN port by configuring entitlement = data of an AN in order control ACL in conjunction with session = start/stop. I also support the idea to consider PPPoE as well as DHCP. 2. I support also using the OAM feature as it is described now by using = ANCP as trigger an report function between AN and NAS to enable OAM = fault management between AN and CPE at DSL line such as e.g. ATM F5 LB = Port Status message or equivalent Ethernet feature. These functions are = still used in a point to point manner checking a connection. I have some concerns and don't support the idea to mix the sense of = these OAM features with Multicast OAM which is total different.=20 The difference is here to poll a state of a Multicast Point which is = not any more an OAM feature enabling line testing towards the DSL CPE. = This is a function which needs state awareness which is a new field = which is not considered so far and has some drawbacks to already = existing use cases.=20 So from my point of view it needs to be considered but goes beyond the = charter and the use case Multicast itself. 3. Using ANCP in a way to control Multicast per multicast group seems = from a flexible service delivery standpoint as an option. But considering the impact which the dynamic interaction between AN = and NAS will bring I have strong concerns regarding performance and = timing issues with respect to channel change time if customer is = zapping. Also in case of failure this scenario maintenance can not = performed successfully.=20 Taking this into account I don't support option 3 which describes = configuration of the L2 replication state without IGMP processing for = some dedicated ports. Regards =20 Thomas Haag =20 -----Urspr=FCngliche Nachricht----- Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Montag, 12. M=E4rz 2007 17:14 An: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org Betreff: RE: [ANCP] Multicast in ANCP Hi All, (chair hat off) I propose that the ANCP multicast requirements should cover the following 3 areas: 1. Dynamic configuration There appears to be a need to be able to control the multicast replication at the access-node in accordance with per user or per circuit-id policies known at the controller, and do so in a dynamic vs a one time provisioned manner. Currently operators do so by statically configuring an ingress IGMP filtering ACL on a given circuit-id, which is not amenable to dynamic changes. By dynamic changes it's meant that they are ones that are quickly executed in response to other system events, eg a subscriber session coming up/down, the expiration of a quota or timer, or a policy trigger, or even operator command.=20 ANCP would need to be able to install such ACLs through an efficient transaction mechanism. Two forms of installation appear to be worthwhile of consideration:=20 i) overwrite - a complete ACL is applied in a transaction on a target circuit-id ii) add/remove - one or more entries are added/removed in a transaction on a target circuit-id. 2. Reporting Several service providers currently run operational procedures that rely on an operator being able to issue/troubleshoot a subscriber's problems from a BNG. Classic examples of these are ATM OAM, and ip ping tests, with the ANCP OAM "use-case" being an extension there of. It appears to be quite laborious, and often problematic due to the crossing of organizational boundaries, to have the procedure performed at the access-node. Troubleshooting of multicast delivery is as yet a bit of a black art to many providers that are only begging to deploy access-nodes capable of L2 multicast replication. It would thus appear to be desirable, in order to aid operations in such deployments, to introduce into ANCP a set of multicast reporting commands, that would allow a BNG operator to gain knowledge of the per circuit-id multicast replication state on the access-node. This would be a simple query/response mechanism, communicating from the access-node to the BNG the currently active multicast groups on a given target (circuit-id) along with applicable counters (eg time/byte count). =20 3. Change of L2 forwarding The current notions of multicast replication on a L2 element are limited to the following two options: flood all multicast with IGMP snooping disabled, or snoop IGMP and immediately replicate/stop-replicating multicast. It appears sensible to consider introducing a third notion that involves ANCP, and provides a more granular per multicast group control approach instead of the all or nothing options above. This would consist having a list of specific groups for which the access node would not flood the multicast traffic to a port, but neither would it do IGMP snooping, rather it would pass IGMP transparently and commence or stop replication when instructed via ANCP.=20 Various optimizations can be introduced to this scheme, but the principle remains the same; the L2 multicast replication mechanism, for a given group or range, would be driven by ANCP signalling. Depending on the deployment scenario, this would appear to be a good tool to utilize when multicast authorization, accounting, or asynchronous operator requests affecting multicast forwarding are desired. Regards, Woj. -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: 06 March 2007 14:49 To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Mar 14 11:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVma-0001u8-SE; Wed, 14 Mar 2007 11:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVmZ-0001tw-Cj for ancp@ietf.org; Wed, 14 Mar 2007 11:52:55 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRVmX-0002X2-Vp for ancp@ietf.org; Wed, 14 Mar 2007 11:52:55 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2EFqsi9023951; Wed, 14 Mar 2007 16:52:54 +0100 Received: from [172.31.131.185] ([172.31.131.185]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031416524518:5147 ; Wed, 14 Mar 2007 16:52:45 +0100 Message-ID: <45F81A4D.2060607@alcatel-lucent.be> Date: Wed, 14 Mar 2007 16:52:45 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] ANCP MIB References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/14/2007 16:52:45, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/14/2007 16:52:46, Serialize complete at 03/14/2007 16:52:46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 draft was submitted 1 week before the deadline and I only got the standard response immediately after submission. After that, I have not seen anything anymore. Although the draft is not available at the IETF, I hope it is not a problem to present it in Prague. I will resubmit immediately after the IETF again. regards, Stefaan Wojciech Dec (wdec) wrote: > Strange, the boiler plate you used appears to be the correct one. Did > you get notice from the editor as to why the draft wasn't accepted? > > -Woj. > > -----Original Message----- > From: stefaan.de_cnodder@alcatel-lucent.be > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: 14 March 2007 09:35 > To: ancp@ietf.org > Subject: [ANCP] ANCP MIB > > > Hi, > > The updated ANCP MIB was submitted to the IETF in time but for some > reason it never appeared on i-d-annound. Therefore I sent the updated > draft as attachement to this mailing list. > > Comments are very welcome. > > regards, > Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Mar 14 13:09:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWyZ-0007ir-E4; Wed, 14 Mar 2007 13:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWyY-0007im-NU for ancp@ietf.org; Wed, 14 Mar 2007 13:09:22 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRWyX-0001Kv-5o for ancp@ietf.org; Wed, 14 Mar 2007 13:09:22 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B646B325F68; Wed, 14 Mar 2007 10:09:20 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19867-01; Wed, 14 Mar 2007 10:09:20 -0700 (PDT) Received: from PARBETM2XP2 (unknown [172.31.253.79]) by prattle.redback.com (Postfix) with ESMTP id D97DE325F69; Wed, 14 Mar 2007 10:09:18 -0700 (PDT) From: "Peter Arberg" To: "'Wojciech Dec (wdec)'" , , Subject: RE: [ANCP] Multicast in ANCP Date: Wed, 14 Mar 2007 18:09:56 +0100 Organization: Redback Networks Inc. Message-ID: <006401c7665b$98c198f0$ba3dfea9@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgAHRHOZA= In-Reply-To: X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 2.3 (++) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com 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, I would also like to extend my support for all the three use cases, as I can see they will be very useful and I think they are well covered with the existing charter. I think #2 is very useful, and can not rely on IGMP Query as proposed earlier, as in a access node with IGMP proxy, I can't see how the IGMP Query will give you a "subscriber" or DSL home view of the replication. And I agree with Sanjays comment that #3 that we shouldn't define this case to preclude snooping on the access-node, even when creation of replication state is being controlled by NAS via ANCP. cheers, Peter > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: 12. marts 2007 17:14 > To: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org > Subject: RE: [ANCP] Multicast in ANCP > > Hi All, > > (chair hat off) > > I propose that the ANCP multicast requirements should cover the > following 3 areas: > > 1. Dynamic configuration > There appears to be a need to be able to control the multicast > replication at the access-node in accordance with per user or per > circuit-id policies known at the controller, and do so in a > dynamic vs a > one time provisioned manner. Currently operators do so by statically > configuring an ingress IGMP filtering ACL on a given circuit-id, which > is not amenable to dynamic changes. By dynamic changes it's meant that > they are ones that are quickly executed in response to other system > events, eg a subscriber session coming up/down, the expiration of a > quota or timer, or a policy trigger, or even operator command. > ANCP would need to be able to install such ACLs through an efficient > transaction mechanism. Two forms of installation appear to be > worthwhile > of consideration: > i) overwrite - a complete ACL is applied in a transaction on a target > circuit-id > ii) add/remove - one or more entries are added/removed in a > transaction > on a target circuit-id. > > 2. Reporting > Several service providers currently run operational > procedures that rely > on an operator being able to issue/troubleshoot a > subscriber's problems > from a BNG. Classic examples of these are ATM OAM, and ip ping tests, > with the ANCP OAM "use-case" being an extension there of. It > appears to > be quite laborious, and often problematic due to the crossing of > organizational boundaries, to have the procedure performed at the > access-node. Troubleshooting of multicast delivery is as yet > a bit of a > black art to many providers that are only begging to deploy > access-nodes > capable of L2 multicast replication. > It would thus appear to be desirable, in order to aid > operations in such > deployments, to introduce into ANCP a set of multicast reporting > commands, that would allow a BNG operator to gain knowledge of the per > circuit-id multicast replication state on the access-node. > This would be > a simple query/response mechanism, communicating from the > access-node to > the BNG the currently active multicast groups on a given target > (circuit-id) along with applicable counters (eg time/byte count). > > 3. Change of L2 forwarding > The current notions of multicast replication on a L2 element > are limited > to the following two options: flood all multicast with IGMP snooping > disabled, or snoop IGMP and immediately replicate/stop-replicating > multicast. > It appears sensible to consider introducing a third notion > that involves > ANCP, and provides a more granular per multicast group > control approach > instead of the all or nothing options above. This would > consist having a > list of specific groups for which the access node would not flood the > multicast traffic to a port, but neither would it do IGMP snooping, > rather it would pass IGMP transparently and commence or stop > replication > when instructed via ANCP. > Various optimizations can be introduced to this scheme, but the > principle remains the same; the L2 multicast replication > mechanism, for > a given group or range, would be driven by ANCP signalling. > Depending on the deployment scenario, this would appear to be a good > tool to utilize when multicast authorization, accounting, or > asynchronous operator requests affecting multicast forwarding are > desired. > > Regards, > Woj. > > > -----Original Message----- > From: Matthew.Bocci@alcatel-lucent.co.uk > [mailto:Matthew.Bocci@alcatel-lucent.co.uk] > Sent: 06 March 2007 14:49 > To: ancp@ietf.org > Subject: [ANCP] Multicast in ANCP > > I would like to start a discussion on what the working group > would like > to do with Multicast in ANCP. > > Currently the ANCP charter includes multicast as one of the use cases, > as > follows: > > "When multicast replication for subscriber-bound traffic is > performed at > the AN, it off-loads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic > may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as > to allow the > AN to perform subscriber bound multicast group replication in > line with > the subscriber's policy and configuration, and also allow the NAS to > follow each subscriber's multicast group membership." > > The framework draft (draft-ietf-ancp-framework-01.txt) says that the > access loop configuration mechanisms may be useful for setting the > per-Subscriber multicast channel entitlement information, > used for IPTV > applications where the Access Node is performing IGMP snooping or IGMP > proxy function. It goes on to say that a Subscriber's policy and > configuration for multicast traffic might only be known at > the NAS. The > Access Node Control Mechanism could be used to exchange the necessary > information between the Access Node and the NAS so as to allow the > Access Node to perform multicast replication in line with the > Subscriber's policy and configuration, and also allow the NAS > to follow > each Subscriber's multicast group membership. > > > None of these multicast mechanisms are defined in the ANCP protocol > draft, and I think there is insufficient detail in the framework draft > to fully specify this use case. > > There has been very little work on this since the charter discussions, > but the ANCP working group needs to clarify what it wants to do (if > anything) with multicast for the framework can move forward. I think > there are two > choices: Either we should clarify the use case and specify the ANCP > protocol to support it, or we should remove the multicast use > case from > the framework for now. > > Please post your opinions to the list. We plan to have a discussion on > this in Prague, and to try to reach a consensus at around that time. > > Best regards, > > Matthew > > > > > > > > > > > _______________________________________________ > 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 Mar 14 13:11:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRX0D-0008Tg-Dw; Wed, 14 Mar 2007 13:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRX0C-0008Tb-7c for ancp@ietf.org; Wed, 14 Mar 2007 13:11:04 -0400 Received: from [216.23.136.226] (helo=mailhost.van.redback.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRX0A-0001aj-NE for ancp@ietf.org; Wed, 14 Mar 2007 13:11:04 -0400 Received: from CSHERBOTM5XP (dhcp-36-36.van.redback.com [172.19.36.36]) by mailhost.van.redback.com (Postfix) with ESMTP id 18BA52AF6D for ; Wed, 14 Mar 2007 10:11:02 -0700 (PDT) From: "Curtis Sherbo" To: Subject: RE: [ANCP] Multicast in ANCP Date: Wed, 14 Mar 2007 10:10:59 -0700 Message-ID: <001201c7665b$bca1dcd0$242413ac@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acdf9k4VP+PmpMWmRpWoFSXC2t1a5wGV4IGg X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 Greetings, With respect to the multicast use case currently in the ANCP charter, I support keeping it in scope, with clarifications, and specifying the ANCP protocol to support it. Here are my thoughts around several multicast problems that could be nicely solved with a mechanism such as ANCP. Multicast Replication Today there are varying implementations of multicast replication in Access Nodes, making it difficult for Service Providers to implement a uniform model across the network. Add to this the ability to uniformly enact policy and/or accounting, and you have a very large problem that today would require a complex OSS solution. As already brought forward, it would be simpler to utilize existing functions on the NAS for both policy and accounting with enchantments that include the use of ANCP to signal L2 replication state on the AN. Sheer volume of ANs to NASs deployed, make it logical from a policy control perspective to centralize this function on the NAS. Enacting Policy on a large scale to varying AN types and vendors is a daunting task. I agree with an earlier statement that the potential function of ANCP to signal L2 replication state should not preclude the use of IGMP snooping. I just think it would be a valuable option in moving the functionality of the network beyond supporting basic broadcast television support. Fast Channel Change Although not yet commonly discussed in current working groups, perhaps this is an opportunity to discuss potential solutions. Some known Middleware implementations utilize a unicast stream at time of channel change, and switch to the multicast stream at a secondary point in time. This two part channel change makes simple access lists and straight IGMP snooping a little less useful. Perhaps some opportunities for optimization would present themselves if the decision making process was left up to the NAS. Access Control (Simple Policy) I think it is easily agreed that a basic form of Multicast (IGMP) Filtering on an Access Node is a good idea. The debatable point is whether these lists are dynamic or not. In the simplest case, dynamic means installed at the start of a subscriber session. In the more advanced case, dynamic would mean some sort of real time function where the AN could query the real time Authorization of a particular Multicast group. Accounting Use cases are starting to be discussed that would require accounting for multicast traffic. Since Accounting is typically performed on the NAS, with existing systems setup to collect this info from the NAS, it only makes sense to aggregate the records that account for the multicast traffic on the NAS and utilize existing systems to collect this data. Bandwidth Control The NAS has the best view of available network resources in both an upstream and downstream perspective. A hot topic for discussion today is a bandwidth admission function, that should account for both Multicast and Unicast traffic. Utilizing the NASs position in the network, and knowledge of subscriber state, make this a logical point for providing feedback on resources, as well as querying/signaling of downstream elements for the purpose of optimizing available bandwidth. I look forward to further discussion. Regards, Curtis Sherbo -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk] Sent: Tuesday, March 06, 2007 5:49 AM To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Mar 14 13:35:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXOC-0006Km-Ui; Wed, 14 Mar 2007 13:35:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXOA-0006Kd-T0 for ancp@ietf.org; Wed, 14 Mar 2007 13:35:50 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRXO9-0006hX-6H for ancp@ietf.org; Wed, 14 Mar 2007 13:35:50 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2007 18:35:49 +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 l2EHZm9X000393; Wed, 14 Mar 2007 18:35:48 +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 l2EHZhlb010470; Wed, 14 Mar 2007 17:35:48 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); Wed, 14 Mar 2007 18:35:46 +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 in ANCP Date: Wed, 14 Mar 2007 18:35:09 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: AcdlUUB6RSQjBdd3QBuVBqLg99h4VwA6IU0AAAiplnA= From: "Wojciech Dec \(wdec\)" To: "Voigt, Norbert" , X-OriginalArrivalTime: 14 Mar 2007 17:35:46.0871 (UTC) FILETIME=[331B6C70:01C7665F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4064; t=1173893748; x=1174757748; 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=20in=20ANCP |Sender:=20; bh=N4V/gzS3dJxBDDPU8uSFkFmh70BT+1wPwwEk60f8jc8=; b=FmSkRdpOR22VnIz5z9kFLT69wL0Tt1a/75Cuktm1DcgRdm3/BD0TJAzCLY+f79KBdaX/hSpJ pRQYjZckbAHlRArD8Y1Itd7QaQKFUllUOK+Rnm/EFYLIUiULpmSHmQzP; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Norbert, Sven Could you elaborate how you see the IGMP query mechanism working instead of the reporting feature proposed? Regards, Woj.=20 -----Original Message----- From: Voigt, Norbert [mailto:norbert.voigt@siemens.com]=20 Sent: 14 March 2007 15:05 To: ancp@ietf.org Subject: RE: [ANCP] Multicast in ANCP Hi all, I fully support Sven's view saying there seems to be a need for controling multicast content at the Access Node, i.e.: 1)For enabling multicast at AN ports, ACLs shall be provided per AN port. The ACL shall contain multicast entitlement data in order to provide dedicated IP multicast groups to the user. I also support the idea to configure these ACLs by means of ANCP at DHCP/PPPoE session start/stop. 2)Regarding the reporting function Wojciech proposed, I have difficulties seeing the need for it. I would prefer the IGMP query mechanism to gain knowledge of the per port multicast replication state on the Access Node. 3)Regarding the use of ANCP for configuration of the L2 replication state without IGMP procesing for some dedicated ports, I'm not very supportive. I would like to see whether the intended use case could be covered by the already mentioned ACLs to allow/disallow mc content to be sent to that port. Regards, Norbert. Matthew.Bocci@alcatel-lucent.co.uk wrote: > I would like to start a discussion on what the working group would like to > do with Multicast in ANCP. >=20 > Currently the ANCP charter includes multicast as one of the use cases, as > follows: >=20 > "When multicast replication for subscriber-bound traffic is performed at > the AN, it off-loads the network between the AN and NAS. However, a=20 > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the=20 > necessary information exchange between the AN and NAS so as to allow the AN > to perform subscriber bound multicast group replication in line with the > subscriber's policy and configuration, and also allow the NAS to follow > each subscriber's multicast group membership." >=20 > The framework draft (draft-ietf-ancp-framework-01.txt) says that the access > loop configuration mechanisms may be useful for setting the per-Subscriber > multicast channel entitlement information, used for IPTV applications where > the Access Node is performing IGMP snooping or IGMP proxy function. It goes > on to say that a Subscriber's policy and configuration for multicast=20 > traffic might only be known at the NAS. The Access Node Control Mechanism > could be used to exchange the necessary information between the Access Node > and the NAS so as to allow the Access Node to perform multicast replication > in line with the Subscriber's policy and configuration, and also allow the > NAS to follow each Subscriber's multicast group membership. >=20 >=20 > None of these multicast mechanisms are defined in the ANCP protocol draft, > and I think there is insufficient detail in the framework draft to fully > specify this use case. >=20 > There has been very little work on this since the charter discussions, but > the ANCP working group needs to clarify what it wants to do (if anything) > with multicast for the framework can move forward. I think there are two > choices: Either we should clarify the use case and specify the ANCP=20 > protocol to support it, or we should remove the multicast use case from the > framework for now. >=20 > Please post your opinions to the list. We plan to have a discussion on this > in Prague, and to try to reach a consensus at around that time. >=20 > Best regards, >=20 > Matthew >=20 >=20 >=20 >=20 >=20 >=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Mar 15 05:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlwD-0001gS-Ck; Thu, 15 Mar 2007 05:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlwC-0001gN-CP for ancp@ietf.org; Thu, 15 Mar 2007 05:07:56 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRlwA-0000sw-NS for ancp@ietf.org; Thu, 15 Mar 2007 05:07:56 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2F97xv3012929; Thu, 15 Mar 2007 10:07:59 +0100 Received: from [172.31.131.185] ([172.31.131.185]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031510075073:2022 ; Thu, 15 Mar 2007 10:07:50 +0100 Message-ID: <45F90CE5.5040507@alcatel-lucent.be> Date: Thu, 15 Mar 2007 10:07:49 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Multicast in ANCP References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/15/2007 10:07:50, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/15/2007 10:07:51, Serialize complete at 03/15/2007 10:07:51 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 2.4 (++) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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, My comments on your 3 cases below: 1) dynamic configuration of ACLs: looks interesting 2) OAM: I have some doubts about it, although not a strong position. The question is on how far you want to go with the troubleshooting of the AN from the NAS. There are so many things that can be done but where will it stop. 3) it looks like that this causes a lot of load on both the AN and the NAS. Should we really consider this? When looking to all the emails on this subject, I come to the conclusion that on the first case, there is a very good consensus. For the other 2 cases more discussion is needed. So it looks that this discussion is a good start for the multicast usecase and it looks that we can already make it more concrete in framework and protocol with on which there is already consensus and continue the discussion on the rest. regards, Stefaan Wojciech Dec (wdec) wrote: > Hi All, > > (chair hat off) > > I propose that the ANCP multicast requirements should cover the > following 3 areas: > > 1. Dynamic configuration > There appears to be a need to be able to control the multicast > replication at the access-node in accordance with per user or per > circuit-id policies known at the controller, and do so in a dynamic vs a > one time provisioned manner. Currently operators do so by statically > configuring an ingress IGMP filtering ACL on a given circuit-id, which > is not amenable to dynamic changes. By dynamic changes it's meant that > they are ones that are quickly executed in response to other system > events, eg a subscriber session coming up/down, the expiration of a > quota or timer, or a policy trigger, or even operator command. > ANCP would need to be able to install such ACLs through an efficient > transaction mechanism. Two forms of installation appear to be worthwhile > of consideration: > i) overwrite - a complete ACL is applied in a transaction on a target > circuit-id > ii) add/remove - one or more entries are added/removed in a transaction > on a target circuit-id. > > 2. Reporting > Several service providers currently run operational procedures that rely > on an operator being able to issue/troubleshoot a subscriber's problems > from a BNG. Classic examples of these are ATM OAM, and ip ping tests, > with the ANCP OAM "use-case" being an extension there of. It appears to > be quite laborious, and often problematic due to the crossing of > organizational boundaries, to have the procedure performed at the > access-node. Troubleshooting of multicast delivery is as yet a bit of a > black art to many providers that are only begging to deploy access-nodes > capable of L2 multicast replication. > It would thus appear to be desirable, in order to aid operations in such > deployments, to introduce into ANCP a set of multicast reporting > commands, that would allow a BNG operator to gain knowledge of the per > circuit-id multicast replication state on the access-node. This would be > a simple query/response mechanism, communicating from the access-node to > the BNG the currently active multicast groups on a given target > (circuit-id) along with applicable counters (eg time/byte count). > > 3. Change of L2 forwarding > The current notions of multicast replication on a L2 element are limited > to the following two options: flood all multicast with IGMP snooping > disabled, or snoop IGMP and immediately replicate/stop-replicating > multicast. > It appears sensible to consider introducing a third notion that involves > ANCP, and provides a more granular per multicast group control approach > instead of the all or nothing options above. This would consist having a > list of specific groups for which the access node would not flood the > multicast traffic to a port, but neither would it do IGMP snooping, > rather it would pass IGMP transparently and commence or stop replication > when instructed via ANCP. > Various optimizations can be introduced to this scheme, but the > principle remains the same; the L2 multicast replication mechanism, for > a given group or range, would be driven by ANCP signalling. > Depending on the deployment scenario, this would appear to be a good > tool to utilize when multicast authorization, accounting, or > asynchronous operator requests affecting multicast forwarding are > desired. > > Regards, > Woj. > > > -----Original Message----- > From: Matthew.Bocci@alcatel-lucent.co.uk > [mailto:Matthew.Bocci@alcatel-lucent.co.uk] > Sent: 06 March 2007 14:49 > To: ancp@ietf.org > Subject: [ANCP] Multicast in ANCP > > I would like to start a discussion on what the working group would like > to do with Multicast in ANCP. > > Currently the ANCP charter includes multicast as one of the use cases, > as > follows: > > "When multicast replication for subscriber-bound traffic is performed at > the AN, it off-loads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow the > AN to perform subscriber bound multicast group replication in line with > the subscriber's policy and configuration, and also allow the NAS to > follow each subscriber's multicast group membership." > > The framework draft (draft-ietf-ancp-framework-01.txt) says that the > access loop configuration mechanisms may be useful for setting the > per-Subscriber multicast channel entitlement information, used for IPTV > applications where the Access Node is performing IGMP snooping or IGMP > proxy function. It goes on to say that a Subscriber's policy and > configuration for multicast traffic might only be known at the NAS. The > Access Node Control Mechanism could be used to exchange the necessary > information between the Access Node and the NAS so as to allow the > Access Node to perform multicast replication in line with the > Subscriber's policy and configuration, and also allow the NAS to follow > each Subscriber's multicast group membership. > > > None of these multicast mechanisms are defined in the ANCP protocol > draft, and I think there is insufficient detail in the framework draft > to fully specify this use case. > > There has been very little work on this since the charter discussions, > but the ANCP working group needs to clarify what it wants to do (if > anything) with multicast for the framework can move forward. I think > there are two > choices: Either we should clarify the use case and specify the ANCP > protocol to support it, or we should remove the multicast use case from > the framework for now. > > Please post your opinions to the list. We plan to have a discussion on > this in Prague, and to try to reach a consensus at around that time. > > Best regards, > > Matthew > > > > > > > > > > > _______________________________________________ > 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 Mar 15 09:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpt4-0004rT-RN; Thu, 15 Mar 2007 09:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpt3-0004pD-Tk for ancp@ietf.org; Thu, 15 Mar 2007 09:20:57 -0400 Received: from smail2.alcatel.fr ([64.208.49.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRpt0-0006Ne-Ts for ancp@ietf.org; Thu, 15 Mar 2007 09:20:57 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id l2FDKVRj006047; Thu, 15 Mar 2007 14:20:35 +0100 Received: from [172.31.131.185] ([172.31.131.185]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031514203390:4141 ; Thu, 15 Mar 2007 14:20:33 +0100 Message-ID: <45F94821.3070001@alcatel-lucent.be> Date: Thu, 15 Mar 2007 14:20:33 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" Subject: Re: [ANCP] Multicast in ANCP References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/15/2007 14:20:33, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/15/2007 14:20:35, Serialize complete at 03/15/2007 14:20:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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, I guess it is be sending a query to the host? See section 4.1.12 of RFC3376. regards, Stefaan Wojciech Dec (wdec) wrote: > Hi Norbert, Sven > > Could you elaborate how you see the IGMP query mechanism working instead > of the reporting feature proposed? > > Regards, > Woj. > > -----Original Message----- > From: Voigt, Norbert [mailto:norbert.voigt@siemens.com] > Sent: 14 March 2007 15:05 > To: ancp@ietf.org > Subject: RE: [ANCP] Multicast in ANCP > > Hi all, > > I fully support Sven's view saying there seems to be a need for > controling multicast content at the Access Node, i.e.: > 1)For enabling multicast at AN ports, ACLs shall be provided per AN > port. The ACL shall contain multicast entitlement data in order to > provide dedicated IP multicast groups to the user. > I also support the idea to configure these ACLs by means of ANCP at > DHCP/PPPoE session start/stop. > > 2)Regarding the reporting function Wojciech proposed, I have > difficulties seeing the need for it. I would prefer the IGMP query > mechanism to gain knowledge of the per port multicast replication state > on the Access Node. > > 3)Regarding the use of ANCP for configuration of the L2 replication > state without IGMP procesing for some dedicated ports, I'm not very > supportive. I would like to see whether the intended use case could be > covered by the already mentioned ACLs to allow/disallow mc content to be > sent to that port. > > Regards, > Norbert. > > > > Matthew.Bocci@alcatel-lucent.co.uk wrote: > >>I would like to start a discussion on what the working group would > > like to > >>do with Multicast in ANCP. >> >>Currently the ANCP charter includes multicast as one of the use cases, > > as > >>follows: >> >>"When multicast replication for subscriber-bound traffic is performed > > at > >>the AN, it off-loads the network between the AN and NAS. However, a >>subscriber's policy and configuration for multicast traffic may only > > be > >>known at the NAS. ANCP will provide a mechanism to communicate the >>necessary information exchange between the AN and NAS so as to allow > > the AN > >>to perform subscriber bound multicast group replication in line with > > the > >>subscriber's policy and configuration, and also allow the NAS to > > follow > >>each subscriber's multicast group membership." >> >>The framework draft (draft-ietf-ancp-framework-01.txt) says that the > > access > >>loop configuration mechanisms may be useful for setting the > > per-Subscriber > >>multicast channel entitlement information, used for IPTV applications > > where > >>the Access Node is performing IGMP snooping or IGMP proxy function. It > > goes > >>on to say that a Subscriber's policy and configuration for multicast >>traffic might only be known at the NAS. The Access Node Control > > Mechanism > >>could be used to exchange the necessary information between the Access > > Node > >>and the NAS so as to allow the Access Node to perform multicast > > replication > >>in line with the Subscriber's policy and configuration, and also > > allow the > >>NAS to follow each Subscriber's multicast group membership. >> >> >>None of these multicast mechanisms are defined in the ANCP protocol > > draft, > >>and I think there is insufficient detail in the framework draft to > > fully > >>specify this use case. >> >>There has been very little work on this since the charter discussions, > > but > >>the ANCP working group needs to clarify what it wants to do (if > > anything) > >>with multicast for the framework can move forward. I think there are > > two > >>choices: Either we should clarify the use case and specify the ANCP >>protocol to support it, or we should remove the multicast use case > > from the > >>framework for now. >> >>Please post your opinions to the list. We plan to have a discussion on > > this > >>in Prague, and to try to reach a consensus at around that time. >> >>Best regards, >> >>Matthew >> >> >> >> >> >> >> >> >> >> >>_______________________________________________ >>ANCP mailing list >>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 Mar 15 10:09:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqdr-0004lD-Dy; Thu, 15 Mar 2007 10:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqdq-0004kl-6Y for ancp@ietf.org; Thu, 15 Mar 2007 10:09:18 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqdo-0005UJ-Ld for ancp@ietf.org; Thu, 15 Mar 2007 10:09:18 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 136753EA6CB; Thu, 15 Mar 2007 07:09:16 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01409-02; Thu, 15 Mar 2007 07:09:15 -0700 (PDT) Received: from PARBETM2XP2 (unknown [172.31.253.81]) by prattle.redback.com (Postfix) with ESMTP id A65E33EA6C3; Thu, 15 Mar 2007 07:09:13 -0700 (PDT) From: "Peter Arberg" To: , "'Wojciech Dec (wdec)'" Subject: RE: [ANCP] Multicast in ANCP Date: Thu, 15 Mar 2007 15:09:51 +0100 Organization: Redback Networks Inc. Message-ID: <001201c7670b$9a955e90$ba3dfea9@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45F94821.3070001@alcatel-lucent.be> Thread-Index: AcdnBN93gKHMbOAqSla8UAL0qIowpAABQsbg X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com 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 So if you can be a little more specific, and explain how a query send to a host if the Access Node is running in a IGMP proxy model (or snooping with proxy reporting as it also is called) will be able to inform what DSL line is receiving the multicast group ? In TR-101 the "snooping with proxy reporting" describe the IGMP query as: --- Report suppression: intercepts, absorbs and summarizes IGMP reports coming from IGMP hosts. IGMP reports are relayed upstream only when necessary, i.e. when the first user joins a multicast group, and once only per multicast group in response to an IGMP query. --- So with IGMP Query if I understand the functionality will only tell the NAS if the AN has joined the multicast group, it will not be able to identify if a particular DSL line has joined the group. thanks, Peter > -----Original Message----- > From: stefaan.de_cnodder@alcatel-lucent.be > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: 15. marts 2007 14:21 > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Multicast in ANCP > > > Woj, > > I guess it is be sending a query to the host? See section 4.1.12 of > RFC3376. > > regards, > Stefaan > > > Wojciech Dec (wdec) wrote: > > Hi Norbert, Sven > > > > Could you elaborate how you see the IGMP query mechanism > working instead > > of the reporting feature proposed? > > > > Regards, > > Woj. > > > > -----Original Message----- > > From: Voigt, Norbert [mailto:norbert.voigt@siemens.com] > > Sent: 14 March 2007 15:05 > > To: ancp@ietf.org > > Subject: RE: [ANCP] Multicast in ANCP > > > > Hi all, > > > > I fully support Sven's view saying there seems to be a need for > > controling multicast content at the Access Node, i.e.: > > 1)For enabling multicast at AN ports, ACLs shall be provided per AN > > port. The ACL shall contain multicast entitlement data in order to > > provide dedicated IP multicast groups to the user. > > I also support the idea to configure these ACLs by means of ANCP at > > DHCP/PPPoE session start/stop. > > > > 2)Regarding the reporting function Wojciech proposed, I have > > difficulties seeing the need for it. I would prefer the IGMP query > > mechanism to gain knowledge of the per port multicast > replication state > > on the Access Node. > > > > 3)Regarding the use of ANCP for configuration of the L2 replication > > state without IGMP procesing for some dedicated ports, I'm not very > > supportive. I would like to see whether the intended use > case could be > > covered by the already mentioned ACLs to allow/disallow mc > content to be > > sent to that port. > > > > Regards, > > Norbert. > > > > > > > > Matthew.Bocci@alcatel-lucent.co.uk wrote: > > > >>I would like to start a discussion on what the working group would > > > > like to > > > >>do with Multicast in ANCP. > >> > >>Currently the ANCP charter includes multicast as one of the > use cases, > > > > as > > > >>follows: > >> > >>"When multicast replication for subscriber-bound traffic is > performed > > > > at > > > >>the AN, it off-loads the network between the AN and NAS. However, a > >>subscriber's policy and configuration for multicast traffic may only > > > > be > > > >>known at the NAS. ANCP will provide a mechanism to communicate the > >>necessary information exchange between the AN and NAS so as to allow > > > > the AN > > > >>to perform subscriber bound multicast group replication in line with > > > > the > > > >>subscriber's policy and configuration, and also allow the NAS to > > > > follow > > > >>each subscriber's multicast group membership." > >> > >>The framework draft (draft-ietf-ancp-framework-01.txt) says that the > > > > access > > > >>loop configuration mechanisms may be useful for setting the > > > > per-Subscriber > > > >>multicast channel entitlement information, used for IPTV > applications > > > > where > > > >>the Access Node is performing IGMP snooping or IGMP proxy > function. It > > > > goes > > > >>on to say that a Subscriber's policy and configuration for > multicast > >>traffic might only be known at the NAS. The Access Node Control > > > > Mechanism > > > >>could be used to exchange the necessary information between > the Access > > > > Node > > > >>and the NAS so as to allow the Access Node to perform multicast > > > > replication > > > >>in line with the Subscriber's policy and configuration, and also > > > > allow the > > > >>NAS to follow each Subscriber's multicast group membership. > >> > >> > >>None of these multicast mechanisms are defined in the ANCP protocol > > > > draft, > > > >>and I think there is insufficient detail in the framework draft to > > > > fully > > > >>specify this use case. > >> > >>There has been very little work on this since the charter > discussions, > > > > but > > > >>the ANCP working group needs to clarify what it wants to do (if > > > > anything) > > > >>with multicast for the framework can move forward. I think there are > > > > two > > > >>choices: Either we should clarify the use case and specify the ANCP > >>protocol to support it, or we should remove the multicast use case > > > > from the > > > >>framework for now. > >> > >>Please post your opinions to the list. We plan to have a > discussion on > > > > this > > > >>in Prague, and to try to reach a consensus at around that time. > >> > >>Best regards, > >> > >>Matthew > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>ANCP mailing list > >>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 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Mar 15 13:16:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtZ8-0000Gj-OJ; Thu, 15 Mar 2007 13:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtZ7-0000Ge-O1 for ancp@ietf.org; Thu, 15 Mar 2007 13:16:37 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRtZ3-000664-PV for ancp@ietf.org; Thu, 15 Mar 2007 13:16:37 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com) ([172.31.244.40]) by iron.ecitele.com with ESMTP; 15 Mar 2007 19:17:11 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 19:16:28 +0200 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] Multicast in ANCP Date: Thu, 15 Mar 2007 19:16:29 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F67E777D5@ilptex01.ecitele.com> In-Reply-To: <6439282641581441A36F7F6F83ED2ED201E66CB7@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgAHFGe0AANERrgA== References: <6439282641581441A36F7F6F83ED2ED201E66CB7@S4DE8PSAAFQ.mitte.t-com.de> From: "Moti Morgenstern" To: X-OriginalArrivalTime: 15 Mar 2007 17:16:28.0389 (UTC) FILETIME=[AB02D950:01C76725] X-Spam-Score: 2.3 (++) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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, Having experience in managing multicast services in the AN I have the = following thoughts regarding the 3 topics in Wojciech's mail: 1) Configuration - NAS will (dynamically) configure the ACLs at the AN per each = circuit-ID, based on any criteria it implements.=20 - The ANCP could also be used to (dynamically) configure the maximum = number of multicast channels and aggregate bandwidth allowed for each = circuit-ID for multicast channels. 2) Reporting - If IGMP snooping is being used at the AN then all accounting data = (volume/time) may be known at the NAS. - IGMP proxy is being used normally for flat-rate service. - Hence, ANCP is not needed for reporting as IGMP itself has the right = modes to help support multicast records at the NAS, if required.=20 3) L2 Forwarding - As already stated, the fastest response to zapping requests is by = utilizing a set of dynamically updated ACLs residing at the AN, closer = to the customer.=20 - I share the concerns of Thomas Haag regarding performance and timing = issues. It is obvious that the NAS-AN interface adds a delay to zapping = time not to mention the fact that NAS will need to handle many more = concurrent IGMP requests to be treated in real-time. If performed at the = AN the IGMP join/leave requests load is distributed between all ANs. - Finally, from a service reliability point-of-view, when the ANCP is = not available for any reason the AN can still use the most updated ACLs = it has and the service is unaffected. Regards, Moti Morgenstern -----Original Message----- From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 Sent: Wednesday, March 14, 2007 5:45 PM To: ancp@ietf.org Cc: Busser, M Subject: AW: [ANCP] Multicast in ANCP Hi all, Thanks for pointing out several options dealing with ANCP and Multicast. Some points are interesting raising new requirements, some points = bringing up new concerns regarding interoperability AN/NAS, extending = the existing charter by introducing new requirements which may have = impact to already existing requirements and use cases. ANCP can do many = things but the operational impact as well as impact on interaction = between NAS and AN which is out of scope of a protocol specification but = needs to be taken into account too. Below I tried to summarize it step by step: 1. I support option 1 enabling MC per AN port by configuring entitlement = data of an AN in order control ACL in conjunction with session = start/stop. I also support the idea to consider PPPoE as well as DHCP. 2. I support also using the OAM feature as it is described now by using = ANCP as trigger an report function between AN and NAS to enable OAM = fault management between AN and CPE at DSL line such as e.g. ATM F5 LB = Port Status message or equivalent Ethernet feature. These functions are = still used in a point to point manner checking a connection. I have some concerns and don't support the idea to mix the sense of = these OAM features with Multicast OAM which is total different.=20 The difference is here to poll a state of a Multicast Point which is = not any more an OAM feature enabling line testing towards the DSL CPE. = This is a function which needs state awareness which is a new field = which is not considered so far and has some drawbacks to already = existing use cases.=20 So from my point of view it needs to be considered but goes beyond the = charter and the use case Multicast itself. 3. Using ANCP in a way to control Multicast per multicast group seems = from a flexible service delivery standpoint as an option. But considering the impact which the dynamic interaction between AN = and NAS will bring I have strong concerns regarding performance and = timing issues with respect to channel change time if customer is = zapping. Also in case of failure this scenario maintenance can not = performed successfully.=20 Taking this into account I don't support option 3 which describes = configuration of the L2 replication state without IGMP processing for = some dedicated ports. Regards =20 Thomas Haag =20 -----Urspr=FCngliche Nachricht----- Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Montag, 12. M=E4rz 2007 17:14 An: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org Betreff: RE: [ANCP] Multicast in ANCP Hi All, (chair hat off) I propose that the ANCP multicast requirements should cover the following 3 areas: 1. Dynamic configuration There appears to be a need to be able to control the multicast replication at the access-node in accordance with per user or per circuit-id policies known at the controller, and do so in a dynamic vs a one time provisioned manner. Currently operators do so by statically configuring an ingress IGMP filtering ACL on a given circuit-id, which is not amenable to dynamic changes. By dynamic changes it's meant that they are ones that are quickly executed in response to other system events, eg a subscriber session coming up/down, the expiration of a quota or timer, or a policy trigger, or even operator command.=20 ANCP would need to be able to install such ACLs through an efficient transaction mechanism. Two forms of installation appear to be worthwhile of consideration:=20 i) overwrite - a complete ACL is applied in a transaction on a target circuit-id ii) add/remove - one or more entries are added/removed in a transaction on a target circuit-id. 2. Reporting Several service providers currently run operational procedures that rely on an operator being able to issue/troubleshoot a subscriber's problems from a BNG. Classic examples of these are ATM OAM, and ip ping tests, with the ANCP OAM "use-case" being an extension there of. It appears to be quite laborious, and often problematic due to the crossing of organizational boundaries, to have the procedure performed at the access-node. Troubleshooting of multicast delivery is as yet a bit of a black art to many providers that are only begging to deploy access-nodes capable of L2 multicast replication. It would thus appear to be desirable, in order to aid operations in such deployments, to introduce into ANCP a set of multicast reporting commands, that would allow a BNG operator to gain knowledge of the per circuit-id multicast replication state on the access-node. This would be a simple query/response mechanism, communicating from the access-node to the BNG the currently active multicast groups on a given target (circuit-id) along with applicable counters (eg time/byte count). =20 3. Change of L2 forwarding The current notions of multicast replication on a L2 element are limited to the following two options: flood all multicast with IGMP snooping disabled, or snoop IGMP and immediately replicate/stop-replicating multicast. It appears sensible to consider introducing a third notion that involves ANCP, and provides a more granular per multicast group control approach instead of the all or nothing options above. This would consist having a list of specific groups for which the access node would not flood the multicast traffic to a port, but neither would it do IGMP snooping, rather it would pass IGMP transparently and commence or stop replication when instructed via ANCP.=20 Various optimizations can be introduced to this scheme, but the principle remains the same; the L2 multicast replication mechanism, for a given group or range, would be driven by ANCP signalling. Depending on the deployment scenario, this would appear to be a good tool to utilize when multicast authorization, accounting, or asynchronous operator requests affecting multicast forwarding are desired. Regards, Woj. -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: 06 March 2007 14:49 To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Mar 15 14:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRuly-0001dv-Sx; Thu, 15 Mar 2007 14:33:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRulx-0001do-SF for ancp@ietf.org; Thu, 15 Mar 2007 14:33:57 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRulw-00079U-2A for ancp@ietf.org; Thu, 15 Mar 2007 14:33:57 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 15 Mar 2007 11:33:53 -0700 X-IronPort-AV: i="4.14,289,1170662400"; d="scan'208"; a="670837180:sNHT45925402" 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] Multicast in ANCP Date: Thu, 15 Mar 2007 14:33:51 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B76018@proton.jnpr.net> In-Reply-To: <83153A1EB675AF4F82E134FA27F95F67E777D5@ilptex01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9k/CpbTm4BVnQb+TxWsD2lls9gEksXWgAHFGe0AANERrgAADADwg From: "Sanjay Wadhwa" To: "Moti Morgenstern" , X-Spam-Score: 2.3 (++) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b 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 Moti One of the motivation for NAS to control replication state on the AN = is to subject it to admission control (based on multiple services being = delivered to the same local-loop). The NAS needs per-subscriber IGMP = visibility to do this. Once it gets this visibilty, per-subscriber = accounting and dynamic management of QoS for the local-loop comes as a = bonus. In this case IGMP state machine is running between RG and NAS. = So, IGMP query is good enough to figure out the state on RG.=20 However, the last point of replication in the network is the AN. I take = use-case #2 as a means to help with troubleshooting when say an RG is = not recieving a multicast stream. In this case the operator from the NAS = can use ANCP to trigger AN to provide stats such as "dropped and = forwarded multicast packets or bytes" per local-loop (ACI) or can = trigger it to report the MAC based multicast filter entries for an = access-loop. If we implement use-case #3, then I think #2 is a = pre-requisite. I also think if we do use-case #3, then high-availability = based on "ANCP graceful restart" is a pre-requisite for both AN and NAS. = Without these two, we don't have a carrier-grade solution. Regards -Sanjay =20 >2) Reporting >- If IGMP snooping is being used at the AN then all accounting=20 >data (volume/time) may be known at the NAS. >- IGMP proxy is being used normally for flat-rate service. >- Hence, ANCP is not needed for reporting as IGMP itself has=20 >the right modes to help support multicast records at the NAS,=20 >if required.=20 >-----Original Message----- >From: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] >Sent: Thursday, March 15, 2007 1:16 PM >To: ancp@ietf.org >Subject: RE: [ANCP] Multicast in ANCP > > >Hi all, > >Having experience in managing multicast services in the AN I=20 >have the following thoughts regarding the 3 topics in Wojciech's mail: > >1) Configuration >- NAS will (dynamically) configure the ACLs at the AN per each=20 >circuit-ID, based on any criteria it implements.=20 >- The ANCP could also be used to (dynamically) configure the=20 >maximum number of multicast channels and aggregate bandwidth=20 >allowed for each circuit-ID for multicast channels. > >2) Reporting >- If IGMP snooping is being used at the AN then all accounting=20 >data (volume/time) may be known at the NAS. >- IGMP proxy is being used normally for flat-rate service. >- Hence, ANCP is not needed for reporting as IGMP itself has=20 >the right modes to help support multicast records at the NAS,=20 >if required.=20 > >3) L2 Forwarding >- As already stated, the fastest response to zapping requests=20 >is by utilizing a set of dynamically updated ACLs residing at=20 >the AN, closer to the customer.=20 >- I share the concerns of Thomas Haag regarding performance=20 >and timing issues. It is obvious that the NAS-AN interface=20 >adds a delay to zapping time not to mention the fact that NAS=20 >will need to handle many more concurrent IGMP requests to be=20 >treated in real-time. If performed at the AN the IGMP=20 >join/leave requests load is distributed between all ANs. >- Finally, from a service reliability point-of-view, when the=20 >ANCP is not available for any reason the AN can still use the=20 >most updated ACLs it has and the service is unaffected. > >Regards, >Moti Morgenstern > >-----Original Message----- >From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 >Sent: Wednesday, March 14, 2007 5:45 PM >To: ancp@ietf.org >Cc: Busser, M >Subject: AW: [ANCP] Multicast in ANCP > >Hi all, > >Thanks for pointing out several options dealing with ANCP and=20 >Multicast. > >Some points are interesting raising new requirements, some=20 >points bringing up new concerns regarding interoperability=20 >AN/NAS, extending the existing charter by introducing new=20 >requirements which may have impact to already existing=20 >requirements and use cases. ANCP can do many things but the=20 >operational impact as well as impact on interaction between=20 >NAS and AN which is out of scope of a protocol specification=20 >but needs to be taken into account too. > >Below I tried to summarize it step by step: > >1. I support option 1 enabling MC per AN port by=20 >configuring entitlement data of an AN in order control=20 >ACL in conjunction with session start/stop. I also=20 >support the idea to consider PPPoE as well as DHCP. > >2. I support also using the OAM feature as it is described=20 >now by using ANCP as trigger an report function between AN=20 >and NAS to enable OAM fault management between AN and=20 >CPE at DSL line such as e.g. ATM F5 LB Port Status=20 >message or equivalent Ethernet feature. These functions are=20 >still used in a point to point manner checking a connection. > > I have some concerns and don't support the idea to mix=20 >the sense of these OAM features with Multicast OAM which is=20 >total different.=20 > The difference is here to poll a state of a Multicast=20 >Point which is not any more an OAM feature enabling=20 >line testing towards the DSL CPE. This is a function=20 >which needs state awareness which is a new field which=20 >is not considered so far and has some drawbacks to already =09 >existing use cases.=20 > > So from my point of view it needs to be considered but=20 >goes beyond the charter and the use case Multicast itself. > >3. Using ANCP in a way to control Multicast per multicast=20 >group seems from a flexible service delivery standpoint as=20 >an option. > But considering the impact which the dynamic=20 >interaction between AN and NAS will bring I have=20 >strong concerns regarding performance and timing issues=20 >with respect to channel change time if customer is =09 >zapping. Also in case of failure this scenario maintenance can=20 >not performed successfully.=20 > > Taking this into account I don't support option 3 which=20 >describes configuration of the L2 replication state=20 >without IGMP processing for some dedicated ports. > >Regards >=20 >Thomas Haag >=20 > >-----Urspr=FCngliche Nachricht----- >Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 >Gesendet: Montag, 12. M=E4rz 2007 17:14 >An: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org >Betreff: RE: [ANCP] Multicast in ANCP > >Hi All, > >(chair hat off) > >I propose that the ANCP multicast requirements should cover the >following 3 areas: > >1. Dynamic configuration >There appears to be a need to be able to control the multicast >replication at the access-node in accordance with per user or per >circuit-id policies known at the controller, and do so in a=20 >dynamic vs a >one time provisioned manner. Currently operators do so by statically >configuring an ingress IGMP filtering ACL on a given circuit-id, which >is not amenable to dynamic changes. By dynamic changes it's meant that >they are ones that are quickly executed in response to other system >events, eg a subscriber session coming up/down, the expiration of a >quota or timer, or a policy trigger, or even operator command.=20 >ANCP would need to be able to install such ACLs through an efficient >transaction mechanism. Two forms of installation appear to be=20 >worthwhile >of consideration:=20 >i) overwrite - a complete ACL is applied in a transaction on a target >circuit-id >ii) add/remove - one or more entries are added/removed in a transaction >on a target circuit-id. > >2. Reporting >Several service providers currently run operational procedures=20 >that rely >on an operator being able to issue/troubleshoot a subscriber's problems >from a BNG. Classic examples of these are ATM OAM, and ip ping tests, >with the ANCP OAM "use-case" being an extension there of. It appears to >be quite laborious, and often problematic due to the crossing of >organizational boundaries, to have the procedure performed at the >access-node. Troubleshooting of multicast delivery is as yet a bit of a >black art to many providers that are only begging to deploy=20 >access-nodes >capable of L2 multicast replication. >It would thus appear to be desirable, in order to aid=20 >operations in such >deployments, to introduce into ANCP a set of multicast reporting >commands, that would allow a BNG operator to gain knowledge of the per >circuit-id multicast replication state on the access-node.=20 >This would be >a simple query/response mechanism, communicating from the=20 >access-node to >the BNG the currently active multicast groups on a given target >(circuit-id) along with applicable counters (eg time/byte count). >=20 >3. Change of L2 forwarding >The current notions of multicast replication on a L2 element=20 >are limited >to the following two options: flood all multicast with IGMP snooping >disabled, or snoop IGMP and immediately replicate/stop-replicating >multicast. >It appears sensible to consider introducing a third notion=20 >that involves >ANCP, and provides a more granular per multicast group control approach >instead of the all or nothing options above. This would=20 >consist having a >list of specific groups for which the access node would not flood the >multicast traffic to a port, but neither would it do IGMP snooping, >rather it would pass IGMP transparently and commence or stop=20 >replication >when instructed via ANCP.=20 >Various optimizations can be introduced to this scheme, but the >principle remains the same; the L2 multicast replication mechanism, for >a given group or range, would be driven by ANCP signalling. >Depending on the deployment scenario, this would appear to be a good >tool to utilize when multicast authorization, accounting, or >asynchronous operator requests affecting multicast forwarding are >desired. > >Regards, >Woj. > > >-----Original Message----- >From: Matthew.Bocci@alcatel-lucent.co.uk >[mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 >Sent: 06 March 2007 14:49 >To: ancp@ietf.org >Subject: [ANCP] Multicast in ANCP > >I would like to start a discussion on what the working group would like >to do with Multicast in ANCP. > >Currently the ANCP charter includes multicast as one of the use cases, >as >follows: > >"When multicast replication for subscriber-bound traffic is=20 >performed at >the AN, it off-loads the network between the AN and NAS. However, a >subscriber's policy and configuration for multicast traffic may only be >known at the NAS. ANCP will provide a mechanism to communicate the >necessary information exchange between the AN and NAS so as to=20 >allow the >AN to perform subscriber bound multicast group replication in line with >the subscriber's policy and configuration, and also allow the NAS to >follow each subscriber's multicast group membership." > >The framework draft (draft-ietf-ancp-framework-01.txt) says that the >access loop configuration mechanisms may be useful for setting the >per-Subscriber multicast channel entitlement information, used for IPTV >applications where the Access Node is performing IGMP snooping or IGMP >proxy function. It goes on to say that a Subscriber's policy and >configuration for multicast traffic might only be known at the NAS. The >Access Node Control Mechanism could be used to exchange the necessary >information between the Access Node and the NAS so as to allow the >Access Node to perform multicast replication in line with the >Subscriber's policy and configuration, and also allow the NAS to follow >each Subscriber's multicast group membership. > > >None of these multicast mechanisms are defined in the ANCP protocol >draft, and I think there is insufficient detail in the framework draft >to fully specify this use case. > >There has been very little work on this since the charter discussions, >but the ANCP working group needs to clarify what it wants to do (if >anything) with multicast for the framework can move forward. I think >there are two >choices: Either we should clarify the use case and specify the ANCP >protocol to support it, or we should remove the multicast use case from >the framework for now. > >Please post your opinions to the list. We plan to have a discussion on >this in Prague, and to try to reach a consensus at around that time. > >Best regards, > >Matthew > > > > > > > > > > >_______________________________________________ >ANCP mailing list >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 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Mar 16 02:17:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS5ki-0005rI-1Q; Fri, 16 Mar 2007 02:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS5kg-0005rA-6A for ancp@ietf.org; Fri, 16 Mar 2007 02:17:22 -0400 Received: from kecgate03.infosysconsulting.com ([220.227.179.21] helo=Kecgate03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS5kd-0005sj-8q for ancp@ietf.org; Fri, 16 Mar 2007 02:17:22 -0400 Received: from indhubbhs03.ad.infosys.com ([192.168.200.83]) by Kecgate03.infosys.com with InterScan Messaging Security Suite; Fri, 16 Mar 2007 10:34:48 +0530 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by indhubbhs03.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 10:35:17 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 10:35:15 +0530 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] Multicast in ANCP Date: Fri, 16 Mar 2007 10:35:15 +0530 Message-ID: <0CA51D55A5DC42479FEBFBCEB7D5F183D44DE4@BLRKECMSG01.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: AcdnBN93gKHMbOAqSla8UAL0qIowpAABQsbgAB9Ud50= References: <001201c7670b$9a955e90$ba3dfea9@ad.redback.com> From: "pavan_kurapati" To: , , "Wojciech Dec \(wdec\)" X-OriginalArrivalTime: 16 Mar 2007 05:05:15.0999 (UTC) FILETIME=[AF7126F0:01C76788] X-Spam-Score: 0.1 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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 support all the 3 cases raised by Woj. If Access node is using proxy= mechanism then query would not help. It works only in the case of= transparent IGMP snooping mechanism. Even if Access node is not aggregating the reports (as is the case with= transparent snooping), some clients send reports with source IP address of= 0.0.0.0. Though it is a rare scenario, it does occur and in such cases NAS= cannot identify the subscriber properly through queries. The only way to= get the information reliably is by using a separate mechanism through= ANCP.=0D Another use case that I can think of is pushing multicast CAC information= to the AN. This is the list of priority and non-priority channels with= bandwidth information. This will help the Access node to maintain a list= of system wide priority & non-priority channels with their corresponding= bandwidths. If the allocated bandwidth for multicast is exhausted then= access node can reject the subsequent Joins generated by subscribers. = Unlike other cases, this has to be pushed by NAS as soon as it detects the= AN (i.e it is not done at subscriber level). If a particular channel's= attribute is changed (i.e either priority or bandwidth is changed) then= that change can be pushed by the NAS through ANCP message to the AN. Thanks, Pavan -----Original Message----- From: Peter Arberg [mailto:parberg@redback.com] Sent: Thu 3/15/2007 7:39 PM To: stefaan.de_cnodder@alcatel-lucent.be; 'Wojciech Dec (wdec)' Cc: ancp@ietf.org Subject: RE: [ANCP] Multicast in ANCP =0D So if you can be a little more specific, and explain how a=0D query send to a host if the Access Node is running in a=0D IGMP proxy model (or snooping with proxy reporting as it also is called) will be able to inform what DSL line is receiving the multicast group ? In TR-101 the "snooping with proxy reporting" describe the IGMP query as: --- Report suppression: intercepts, absorbs and summarizes IGMP reports coming from IGMP hosts. IGMP reports are relayed upstream only when necessary, i.e. when the first user joins a multicast group, and once only per multicast group in response to an IGMP query. --- So with IGMP Query if I understand the functionality will only tell the NAS if the AN has joined the multicast group, it will not be able to identify if a particular DSL line has joined the group. thanks, Peter =0D > -----Original Message----- > From: stefaan.de_cnodder@alcatel-lucent.be=0D > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=0D > Sent: 15. marts 2007 14:21 > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Multicast in ANCP >=0D >=0D > Woj, >=0D > I guess it is be sending a query to the host? See section 4.1.12 of=0D > RFC3376. >=0D > regards, > Stefaan >=0D >=0D > Wojciech Dec (wdec) wrote: > > Hi Norbert, Sven > >=0D > > Could you elaborate how you see the IGMP query mechanism=0D > working instead > > of the reporting feature proposed? > >=0D > > Regards, > > Woj.=0D > >=0D > > -----Original Message----- > > From: Voigt, Norbert [mailto:norbert.voigt@siemens.com]=0D > > Sent: 14 March 2007 15:05 > > To: ancp@ietf.org > > Subject: RE: [ANCP] Multicast in ANCP > >=0D > > Hi all, > >=0D > > I fully support Sven's view saying there seems to be a need for > > controling multicast content at the Access Node, i.e.: > > 1)For enabling multicast at AN ports, ACLs shall be provided per AN > > port. The ACL shall contain multicast entitlement data in order to > > provide dedicated IP multicast groups to the user. > > I also support the idea to configure these ACLs by means of ANCP at > > DHCP/PPPoE session start/stop. > >=0D > > 2)Regarding the reporting function Wojciech proposed, I have > > difficulties seeing the need for it. I would prefer the IGMP query > > mechanism to gain knowledge of the per port multicast=0D > replication state > > on the Access Node. > >=0D > > 3)Regarding the use of ANCP for configuration of the L2 replication > > state without IGMP procesing for some dedicated ports, I'm not very > > supportive. I would like to see whether the intended use=0D > case could be > > covered by the already mentioned ACLs to allow/disallow mc=0D > content to be > > sent to that port. > >=0D > > Regards, > > Norbert. > >=0D > >=0D > >=0D > > Matthew.Bocci@alcatel-lucent.co.uk wrote: > >=0D > >>I would like to start a discussion on what the working group would > >=0D > > like to > >=0D > >>do with Multicast in ANCP. > >> > >>Currently the ANCP charter includes multicast as one of the=0D > use cases, > >=0D > > as > >=0D > >>follows: > >> > >>"When multicast replication for subscriber-bound traffic is=0D > performed > >=0D > > at > >=0D > >>the AN, it off-loads the network between the AN and NAS. However, a=0D > >>subscriber's policy and configuration for multicast traffic may only > >=0D > > be > >=0D > >>known at the NAS. ANCP will provide a mechanism to communicate the=0D > >>necessary information exchange between the AN and NAS so as to allow > >=0D > > the AN > >=0D > >>to perform subscriber bound multicast group replication in line with > >=0D > > the > >=0D > >>subscriber's policy and configuration, and also allow the NAS to > >=0D > > follow > >=0D > >>each subscriber's multicast group membership." > >> > >>The framework draft (draft-ietf-ancp-framework-01.txt) says that the > >=0D > > access > >=0D > >>loop configuration mechanisms may be useful for setting the > >=0D > > per-Subscriber > >=0D > >>multicast channel entitlement information, used for IPTV=0D > applications > >=0D > > where > >=0D > >>the Access Node is performing IGMP snooping or IGMP proxy=0D > function. It > >=0D > > goes > >=0D > >>on to say that a Subscriber's policy and configuration for=0D > multicast=0D > >>traffic might only be known at the NAS. The Access Node Control > >=0D > > Mechanism > >=0D > >>could be used to exchange the necessary information between=0D > the Access > >=0D > > Node > >=0D > >>and the NAS so as to allow the Access Node to perform multicast > >=0D > > replication > >=0D > >>in line with the Subscriber's policy and configuration, and also > >=0D > > allow the > >=0D > >>NAS to follow each Subscriber's multicast group membership. > >> > >> > >>None of these multicast mechanisms are defined in the ANCP protocol > >=0D > > draft, > >=0D > >>and I think there is insufficient detail in the framework draft to > >=0D > > fully > >=0D > >>specify this use case. > >> > >>There has been very little work on this since the charter=0D > discussions, > >=0D > > but > >=0D > >>the ANCP working group needs to clarify what it wants to do (if > >=0D > > anything) > >=0D > >>with multicast for the framework can move forward. I think there are > >=0D > > two > >=0D > >>choices: Either we should clarify the use case and specify the ANCP=0D > >>protocol to support it, or we should remove the multicast use case > >=0D > > from the > >=0D > >>framework for now. > >> > >>Please post your opinions to the list. We plan to have a=0D > discussion on > >=0D > > this > >=0D > >>in Prague, and to try to reach a consensus at around that time. > >> > >>Best regards, > >> > >>Matthew > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>ANCP mailing list > >>ANCP@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ancp > >> > >=0D > >=0D > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=0D > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp >=0D > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=0D _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Mar 16 04:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS8Fn-0006Ql-0G; Fri, 16 Mar 2007 04:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS8Fl-0006Qc-I0 for ancp@ietf.org; Fri, 16 Mar 2007 04:57:37 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS8Fk-0000jm-3E for ancp@ietf.org; Fri, 16 Mar 2007 04:57:37 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2G8vfWQ025587 for ; Fri, 16 Mar 2007 09:57:41 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Fri, 16 Mar 2007 08:57:19 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/16/2007 08:57:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [ANCP] Prague agenda and slides 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 Folks, Please find below the latest agenda for Prague. If you are presenting, please send me your slides by Monday 19th at the latest, or you risk loosing your slot. Regards, Matthew TUESDAY, March 20th, 2007: 13:00 - 15:00 ------------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci 15 mins - Administrivia, WG Status and WG Docs Update - Chairs 10 mins - ANCP Framework / Requirements - Sven Ooghe (sven.ooghe@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-01.txt 15 mins - ANCP Acess Node MIBs - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an-01.txt 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-00.txt 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-00.txt 15 mins - Access Topology Discovery - Wojciech Dec (wdec@cisco.com) 15 mins - ANCP Multicast Discussion - Chairs _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Mar 16 07:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAWW-0004xi-7E; Fri, 16 Mar 2007 07:23:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAWU-0004wf-OR for ancp@ietf.org; Fri, 16 Mar 2007 07:23:02 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSAWK-0002ef-Qn for ancp@ietf.org; Fri, 16 Mar 2007 07:23:02 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2GBMue9005455; Fri, 16 Mar 2007 12:22:56 +0100 Received: from [172.31.131.185] ([172.31.131.185]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031612224729:3083 ; Fri, 16 Mar 2007 12:22:47 +0100 Message-ID: <45FA7E07.1080600@alcatel-lucent.be> Date: Fri, 16 Mar 2007 12:22:47 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sanjay Wadhwa Subject: Re: [ANCP] Multicast in ANCP References: <9BD5D7887235424FA97DFC223CAE3C2803B76018@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B76018@proton.jnpr.net> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/16/2007 12:22:47, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/16/2007 12:22:48 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 2.5 (++) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 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="===============0885012280==" Errors-To: ancp-bounces@ietf.org --===============0885012280== Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 DQpTYW5qYXksDQoNCkl0IGxvb2tzIHlvdSBhcmUgcHJvcG9zaW5nIG5ldyBmdW5jdGlvbmFsaXR5 IGluIEFOQ1AgZm9yIG1vcmUgZGV0YWlsZWQgDQp0cm91Ymxlc2hvb3RpbmcgaW4gdGhlIEFOIGZy b20gdGhlIE5BUywgYnV0IHRoZW4gdGhlIHF1ZXN0aW9uIGlzIHdoZXJlIA0KaXQgc3RvcHMsIGFu ZCBpdCBsb29rcyB0byBtZSB0aGF0IHN1Y2ggYSBkZXRhaWxlZCB0cm91Ymxlc2hvb3Rpbmcgc2hv dWxkIA0KYmUgYmV0dGVyIGRvbmUgYXQgdGhlIEFOIGl0c2VsZi4gIExvb2sgdG8gdGhlIGN1cnJl bnQgT0FNOiB0aGVyZSBpcyBqdXN0IA0Kc29tZSBpbmRpY2F0aW9uIG9mIHRoZSBzdGF0ZSBvZiB0 aGUgRFNMIGxpbmUgYW5kIG5vdGhpbmcgbW9yZSBhbmQgdGhlIA0KZGV0YWlsZWQgdHJvdWJsZXNo b290aW5nIChzcGVjdHJ1bSBhbmFseWlzLCAuLi4pIGlzIHRvIGJlIGRvbmUgb24gdGhlIEFOIA0K aXRzZWxmLiAgSW4gZmFjdCwgZm9yIG11bHRpY2FzdCwgSSBoYXZlIGRvbmUgbG90cyBvZiB0cm91 Ymxlc2hvb3RpbmcgaW4gDQpsaXZlIG5ldHdvcmtzIGFuZCB3aGF0ZXZlciB5b3UgZG8gaW4gQU5D UCwgdGhlIG1vc3QgaW1wb3J0YW50IA0KZnVuY3Rpb25hbGl0eSBzdWNoIGFzIHByb3RvY29sIHRy YWNpbmcsIGRldGFpbGVkIGVycm9yIGNvdW50ZXJzLCAuLi4gDQp3aWxsIGJlIHZlcnkgaGFyZCB0 byBzdXBwb3J0IGluIEFOQ1AuICBUaGUgcHJvcG9zZWQgZXh0ZW5zaW9uIGJ5IFdvaiBvbiANCmdl dHRpbmcgdmlzaWJpbGl0eSBvbiB0aGUgbXVsdGljYXN0IGZvcndhcmRpbmcgdGFibGUgaW4gdGhl IEFOLCB3aWxsIG5vdCANCmhlbHAgYSBsb3QgaW4gZnV0aGVyIGlzb2xhdGluZyB0aGUgcHJvYmxl bS4gIElmIHRoZSBlbnRyeSBpcyB0aGVyZSBvciANCm5vdCwgdGhlbiB0aGUgcHJvYmxlbSBjYW4g YmUgc3RpbGwgYW55d2hlcmUgaW4gdGhlIG5ldHdvcmsgYW5kIHVwIHRvIHRoZSANCmFwcGxpY2F0 aW9uIGxheWVyLiAgQW5kIGlmIHRoZSBwcm9ibGVtIGlzIGluIHRoZSBBTiAoYSBidWcsIG9yIHdo YXRldmVyKSANCnRoZSBpbmZvcm1hdGlvbiBnaXZlbiBpbiBBTkNQIGNvdWxkIGJlIGZhdWx0eSBp bmZvcm1hdGlvbi4NCg0KcmVnYXJkcywNClN0ZWZhYW4NCg0KU2FuamF5IFdhZGh3YSB3cm90ZToN Cg0KPiBNb3RpDQo+ICAgT25lIG9mIHRoZSBtb3RpdmF0aW9uIGZvciBOQVMgdG8gY29udHJvbCBy ZXBsaWNhdGlvbiBzdGF0ZSBvbiB0aGUgQU4gaXMgdG8gc3ViamVjdCBpdCB0byBhZG1pc3Npb24g Y29udHJvbCAoYmFzZWQgb24gbXVsdGlwbGUgc2VydmljZXMgYmVpbmcgZGVsaXZlcmVkIHRvIHRo ZSBzYW1lIGxvY2FsLWxvb3ApLiBUaGUgTkFTIG5lZWRzIHBlci1zdWJzY3JpYmVyIElHTVAgdmlz aWJpbGl0eSB0byBkbyB0aGlzLiBPbmNlIGl0IGdldHMgdGhpcyB2aXNpYmlsdHksIHBlci1zdWJz Y3JpYmVyIGFjY291bnRpbmcgYW5kIGR5bmFtaWMgbWFuYWdlbWVudCBvZiBRb1MgZm9yIHRoZSBs b2NhbC1sb29wIGNvbWVzIGFzIGEgYm9udXMuIEluIHRoaXMgY2FzZSBJR01QIHN0YXRlIG1hY2hp bmUgaXMgcnVubmluZyBiZXR3ZWVuIFJHIGFuZCBOQVMuIFNvLCBJR01QIHF1ZXJ5IGlzIGdvb2Qg ZW5vdWdoIHRvIGZpZ3VyZSBvdXQgdGhlIHN0YXRlIG9uIFJHLiANCj4gSG93ZXZlciwgdGhlIGxh c3QgcG9pbnQgb2YgcmVwbGljYXRpb24gaW4gdGhlIG5ldHdvcmsgaXMgdGhlIEFOLiBJIHRha2Ug dXNlLWNhc2UgIzIgYXMgYSBtZWFucyB0byBoZWxwIHdpdGggdHJvdWJsZXNob290aW5nIHdoZW4g c2F5IGFuIFJHIGlzIG5vdCByZWNpZXZpbmcgYSBtdWx0aWNhc3Qgc3RyZWFtLiBJbiB0aGlzIGNh c2UgdGhlIG9wZXJhdG9yIGZyb20gdGhlIE5BUyBjYW4gdXNlIEFOQ1AgdG8gdHJpZ2dlciBBTiB0 byBwcm92aWRlIHN0YXRzIHN1Y2ggYXMgImRyb3BwZWQgYW5kIGZvcndhcmRlZCBtdWx0aWNhc3Qg cGFja2V0cyBvciBieXRlcyIgcGVyIGxvY2FsLWxvb3AgKEFDSSkgb3IgY2FuIHRyaWdnZXIgaXQg dG8gcmVwb3J0IHRoZSBNQUMgYmFzZWQgbXVsdGljYXN0IGZpbHRlciBlbnRyaWVzIGZvciBhbiBh Y2Nlc3MtbG9vcC4gSWYgd2UgaW1wbGVtZW50IHVzZS1jYXNlICMzLCB0aGVuIEkgdGhpbmsgIzIg aXMgYSBwcmUtcmVxdWlzaXRlLiBJIGFsc28gdGhpbmsgaWYgd2UgZG8gdXNlLWNhc2UgIzMsIHRo ZW4gaGlnaC1hdmFpbGFiaWxpdHkgYmFzZWQgb24gIkFOQ1AgZ3JhY2VmdWwgcmVzdGFydCIgaXMg YSBwcmUtcmVxdWlzaXRlIGZvciBib3RoIEFOIGFuZCBOQVMuIFdpdGhvdXQgdGhlc2UgdHdvLCB3 ZSBkb24ndCBoYXZlIGEgY2Fycmllci1ncmFkZSBzb2x1dGlvbi4NCj4gDQo+IFJlZ2FyZHMNCj4g LVNhbmpheQ0KPiANCj4gIA0KPiANCj4gDQo+IA0KPj4yKSBSZXBvcnRpbmcNCj4+LSBJZiBJR01Q IHNub29waW5nIGlzIGJlaW5nIHVzZWQgYXQgdGhlIEFOIHRoZW4gYWxsIGFjY291bnRpbmcgDQo+ PmRhdGEgKHZvbHVtZS90aW1lKSBtYXkgYmUga25vd24gYXQgdGhlIE5BUy4NCj4+LSBJR01QIHBy b3h5IGlzIGJlaW5nIHVzZWQgbm9ybWFsbHkgZm9yIGZsYXQtcmF0ZSBzZXJ2aWNlLg0KPj4tIEhl bmNlLCBBTkNQIGlzIG5vdCBuZWVkZWQgZm9yIHJlcG9ydGluZyBhcyBJR01QIGl0c2VsZiBoYXMg DQo+PnRoZSByaWdodCBtb2RlcyB0byBoZWxwIHN1cHBvcnQgbXVsdGljYXN0IHJlY29yZHMgYXQg dGhlIE5BUywgDQo+PmlmIHJlcXVpcmVkLiANCj4gDQo+IA0KPj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj5Gcm9tOiBNb3RpIE1vcmdlbnN0ZXJuIFttYWlsdG86TW90aS5Nb3JnZW5zdGVy bkBlY2l0ZWxlLmNvbV0NCj4+U2VudDogVGh1cnNkYXksIE1hcmNoIDE1LCAyMDA3IDE6MTYgUE0N Cj4+VG86IGFuY3BAaWV0Zi5vcmcNCj4+U3ViamVjdDogUkU6IFtBTkNQXSBNdWx0aWNhc3QgaW4g QU5DUA0KPj4NCj4+DQo+PkhpIGFsbCwNCj4+DQo+PkhhdmluZyBleHBlcmllbmNlIGluIG1hbmFn aW5nIG11bHRpY2FzdCBzZXJ2aWNlcyBpbiB0aGUgQU4gSSANCj4+aGF2ZSB0aGUgZm9sbG93aW5n IHRob3VnaHRzIHJlZ2FyZGluZyB0aGUgMyB0b3BpY3MgaW4gV29qY2llY2gncyBtYWlsOg0KPj4N Cj4+MSkgQ29uZmlndXJhdGlvbg0KPj4tIE5BUyB3aWxsIChkeW5hbWljYWxseSkgY29uZmlndXJl IHRoZSBBQ0xzIGF0IHRoZSBBTiBwZXIgZWFjaCANCj4+Y2lyY3VpdC1JRCwgYmFzZWQgb24gYW55 IGNyaXRlcmlhIGl0IGltcGxlbWVudHMuIA0KPj4tIFRoZSBBTkNQIGNvdWxkIGFsc28gYmUgdXNl ZCB0byAoZHluYW1pY2FsbHkpIGNvbmZpZ3VyZSB0aGUgDQo+Pm1heGltdW0gbnVtYmVyIG9mIG11 bHRpY2FzdCBjaGFubmVscyBhbmQgYWdncmVnYXRlIGJhbmR3aWR0aCANCj4+YWxsb3dlZCBmb3Ig ZWFjaCBjaXJjdWl0LUlEIGZvciBtdWx0aWNhc3QgY2hhbm5lbHMuDQo+Pg0KPj4yKSBSZXBvcnRp bmcNCj4+LSBJZiBJR01QIHNub29waW5nIGlzIGJlaW5nIHVzZWQgYXQgdGhlIEFOIHRoZW4gYWxs IGFjY291bnRpbmcgDQo+PmRhdGEgKHZvbHVtZS90aW1lKSBtYXkgYmUga25vd24gYXQgdGhlIE5B Uy4NCj4+LSBJR01QIHByb3h5IGlzIGJlaW5nIHVzZWQgbm9ybWFsbHkgZm9yIGZsYXQtcmF0ZSBz ZXJ2aWNlLg0KPj4tIEhlbmNlLCBBTkNQIGlzIG5vdCBuZWVkZWQgZm9yIHJlcG9ydGluZyBhcyBJ R01QIGl0c2VsZiBoYXMgDQo+PnRoZSByaWdodCBtb2RlcyB0byBoZWxwIHN1cHBvcnQgbXVsdGlj YXN0IHJlY29yZHMgYXQgdGhlIE5BUywgDQo+PmlmIHJlcXVpcmVkLiANCj4+DQo+PjMpIEwyIEZv cndhcmRpbmcNCj4+LSBBcyBhbHJlYWR5IHN0YXRlZCwgdGhlIGZhc3Rlc3QgcmVzcG9uc2UgdG8g emFwcGluZyByZXF1ZXN0cyANCj4+aXMgYnkgdXRpbGl6aW5nIGEgc2V0IG9mIGR5bmFtaWNhbGx5 IHVwZGF0ZWQgQUNMcyByZXNpZGluZyBhdCANCj4+dGhlIEFOLCBjbG9zZXIgdG8gdGhlIGN1c3Rv bWVyLiANCj4+LSBJIHNoYXJlIHRoZSBjb25jZXJucyBvZiBUaG9tYXMgSGFhZyByZWdhcmRpbmcg cGVyZm9ybWFuY2UgDQo+PmFuZCB0aW1pbmcgaXNzdWVzLiBJdCBpcyBvYnZpb3VzIHRoYXQgdGhl IE5BUy1BTiBpbnRlcmZhY2UgDQo+PmFkZHMgYSBkZWxheSB0byB6YXBwaW5nIHRpbWUgbm90IHRv IG1lbnRpb24gdGhlIGZhY3QgdGhhdCBOQVMgDQo+PndpbGwgbmVlZCB0byBoYW5kbGUgbWFueSBt b3JlIGNvbmN1cnJlbnQgSUdNUCByZXF1ZXN0cyB0byBiZSANCj4+dHJlYXRlZCBpbiByZWFsLXRp bWUuIElmIHBlcmZvcm1lZCBhdCB0aGUgQU4gdGhlIElHTVAgDQo+PmpvaW4vbGVhdmUgcmVxdWVz dHMgbG9hZCBpcyBkaXN0cmlidXRlZCBiZXR3ZWVuIGFsbCBBTnMuDQo+Pi0gRmluYWxseSwgZnJv bSBhIHNlcnZpY2UgcmVsaWFiaWxpdHkgcG9pbnQtb2Ytdmlldywgd2hlbiB0aGUgDQo+PkFOQ1Ag aXMgbm90IGF2YWlsYWJsZSBmb3IgYW55IHJlYXNvbiB0aGUgQU4gY2FuIHN0aWxsIHVzZSB0aGUg DQo+Pm1vc3QgdXBkYXRlZCBBQ0xzIGl0IGhhcyBhbmQgdGhlIHNlcnZpY2UgaXMgdW5hZmZlY3Rl ZC4NCj4+DQo+PlJlZ2FyZHMsDQo+Pk1vdGkgTW9yZ2Vuc3Rlcm4NCj4+DQo+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IEhhYWcsIFQgW21haWx0bzpUaG9tYXMuSGFhZ0B0LXN5 c3RlbXMuY29tXSANCj4+U2VudDogV2VkbmVzZGF5LCBNYXJjaCAxNCwgMjAwNyA1OjQ1IFBNDQo+ PlRvOiBhbmNwQGlldGYub3JnDQo+PkNjOiBCdXNzZXIsIE0NCj4+U3ViamVjdDogQVc6IFtBTkNQ XSBNdWx0aWNhc3QgaW4gQU5DUA0KPj4NCj4+SGkgYWxsLA0KPj4NCj4+VGhhbmtzIGZvciBwb2lu dGluZyBvdXQgc2V2ZXJhbCBvcHRpb25zIGRlYWxpbmcgd2l0aCBBTkNQIGFuZCANCj4+TXVsdGlj YXN0Lg0KPj4NCj4+U29tZSBwb2ludHMgYXJlIGludGVyZXN0aW5nIHJhaXNpbmcgbmV3IHJlcXVp cmVtZW50cywgc29tZSANCj4+cG9pbnRzIGJyaW5naW5nIHVwIG5ldyBjb25jZXJucyByZWdhcmRp bmcgaW50ZXJvcGVyYWJpbGl0eSANCj4+QU4vTkFTLCBleHRlbmRpbmcgdGhlIGV4aXN0aW5nIGNo YXJ0ZXIgYnkgaW50cm9kdWNpbmcgbmV3IA0KPj5yZXF1aXJlbWVudHMgd2hpY2ggbWF5IGhhdmUg aW1wYWN0IHRvIGFscmVhZHkgZXhpc3RpbmcgDQo+PnJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2Vz LiBBTkNQIGNhbiBkbyBtYW55IHRoaW5ncyBidXQgdGhlIA0KPj5vcGVyYXRpb25hbCBpbXBhY3Qg YXMgd2VsbCBhcyBpbXBhY3Qgb24gaW50ZXJhY3Rpb24gYmV0d2VlbiANCj4+TkFTIGFuZCBBTiB3 aGljaCBpcyBvdXQgb2Ygc2NvcGUgb2YgYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIA0KPj5idXQg bmVlZHMgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IHRvby4NCj4+DQo+PkJlbG93IEkgdHJpZWQg dG8gc3VtbWFyaXplIGl0IHN0ZXAgYnkgc3RlcDoNCj4+DQo+PjEuCUkgc3VwcG9ydCBvcHRpb24g MSBlbmFibGluZyBNQyBwZXIgQU4gcG9ydCBieSANCj4+Y29uZmlndXJpbmcgZW50aXRsZW1lbnQg CWRhdGEgb2YgYW4gQU4gaW4gb3JkZXIgY29udHJvbCANCj4+QUNMIGluIGNvbmp1bmN0aW9uIHdp dGggc2Vzc2lvbiAJc3RhcnQvc3RvcC4gSSBhbHNvIA0KPj5zdXBwb3J0IHRoZSBpZGVhIHRvIGNv bnNpZGVyIFBQUG9FIGFzIHdlbGwgYXMgCURIQ1AuDQo+Pg0KPj4yLglJIHN1cHBvcnQgYWxzbyB1 c2luZyB0aGUgT0FNIGZlYXR1cmUgYXMgaXQgaXMgZGVzY3JpYmVkIA0KPj5ub3cgYnkgdXNpbmcg CUFOQ1AgYXMgdHJpZ2dlciBhbiByZXBvcnQgZnVuY3Rpb24gYmV0d2VlbiBBTiANCj4+YW5kIE5B UyB0byBlbmFibGUgCU9BTSAJZmF1bHQgbWFuYWdlbWVudCBiZXR3ZWVuIEFOIGFuZCANCj4+Q1BF IGF0ICBEU0wgbGluZSBzdWNoIGFzIGUuZy4gQVRNIAlGNSBMQiBQb3J0IFN0YXR1cyANCj4+bWVz c2FnZSBvciBlcXVpdmFsZW50IEV0aGVybmV0IGZlYXR1cmUuIFRoZXNlIAlmdW5jdGlvbnMgYXJl IA0KPj5zdGlsbCB1c2VkIGluIGEgcG9pbnQgdG8gcG9pbnQgbWFubmVyIGNoZWNraW5nIGEgCWNv bm5lY3Rpb24uDQo+Pg0KPj4JSSBoYXZlIHNvbWUgY29uY2VybnMgYW5kIGRvbid0IHN1cHBvcnQg dGhlIGlkZWEgdG8gbWl4IA0KPj50aGUgc2Vuc2Ugb2YgCXRoZXNlIE9BTSBmZWF0dXJlcyB3aXRo IE11bHRpY2FzdCBPQU0gd2hpY2ggaXMgDQo+PnRvdGFsIGRpZmZlcmVudC4gDQo+PglUaGUgZGlm ZmVyZW5jZSBpcyBoZXJlIHRvIHBvbGwgYSBzdGF0ZSBvZiBhIE11bHRpY2FzdCANCj4+UG9pbnQg d2hpY2ggaXMgCW5vdCBhbnkgbW9yZSBhbiBPQU0gZmVhdHVyZSBlbmFibGluZyANCj4+bGluZSB0 ZXN0aW5nIHRvd2FyZHMgdGhlIERTTCBDUEUuIAlUaGlzIGlzIGEgZnVuY3Rpb24gDQo+PndoaWNo IG5lZWRzIHN0YXRlIGF3YXJlbmVzcyB3aGljaCBpcyBhIG5ldyBmaWVsZCAJd2hpY2ggDQo+Pmlz IG5vdCBjb25zaWRlcmVkIHNvIGZhciBhbmQgaGFzIHNvbWUgZHJhd2JhY2tzIHRvIGFscmVhZHkg CQ0KPj5leGlzdGluZyB1c2UgY2FzZXMuIA0KPj4NCj4+CVNvIGZyb20gbXkgcG9pbnQgb2Ygdmll dyBpdCBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGJ1dCANCj4+Z29lcyBiZXlvbmQgdGhlIAljaGFy dGVyIGFuZCB0aGUgdXNlIGNhc2UgTXVsdGljYXN0IGl0c2VsZi4NCj4+DQo+PjMuCVVzaW5nIEFO Q1AgaW4gYSB3YXkgdG8gY29udHJvbCBNdWx0aWNhc3QgcGVyIG11bHRpY2FzdCANCj4+Z3JvdXAg c2VlbXMgCWZyb20gYSBmbGV4aWJsZSBzZXJ2aWNlIGRlbGl2ZXJ5IHN0YW5kcG9pbnQgYXMgDQo+ PmFuIG9wdGlvbi4NCj4+CUJ1dCBjb25zaWRlcmluZyB0aGUgaW1wYWN0IHdoaWNoIHRoZSBkeW5h bWljIA0KPj5pbnRlcmFjdGlvbiBiZXR3ZWVuIEFOIAlhbmQgTkFTIHdpbGwgYnJpbmcgSSBoYXZl IA0KPj5zdHJvbmcgY29uY2VybnMgcmVnYXJkaW5nIHBlcmZvcm1hbmNlIGFuZCAJdGltaW5nIGlz c3VlcyANCj4+d2l0aCByZXNwZWN0IHRvIGNoYW5uZWwgY2hhbmdlIHRpbWUgaWYgY3VzdG9tZXIg aXMgCQ0KPj56YXBwaW5nLiBBbHNvIGluIGNhc2Ugb2YgZmFpbHVyZSB0aGlzIHNjZW5hcmlvIG1h aW50ZW5hbmNlIGNhbiANCj4+bm90IAlwZXJmb3JtZWQgc3VjY2Vzc2Z1bGx5LiANCj4+DQo+PglU YWtpbmcgdGhpcyBpbnRvIGFjY291bnQgSSBkb24ndCBzdXBwb3J0IG9wdGlvbiAzIHdoaWNoIA0K Pj5kZXNjcmliZXMgCWNvbmZpZ3VyYXRpb24gb2YgdGhlIEwyIHJlcGxpY2F0aW9uIHN0YXRlIA0K Pj53aXRob3V0IElHTVAgcHJvY2Vzc2luZyBmb3IgCXNvbWUgZGVkaWNhdGVkIHBvcnRzLg0KPj4N Cj4+UmVnYXJkcw0KPj4NCj4+VGhvbWFzIEhhYWcNCj4+DQo+Pg0KPj4tLS0tLVVyc3By/G5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NCj4+Vm9uOiBXb2pjaWVjaCBEZWMgKHdkZWMpIFttYWlsdG86d2Rl Y0BjaXNjby5jb21dIA0KPj5HZXNlbmRldDogTW9udGFnLCAxMi4gTeRyeiAyMDA3IDE3OjE0DQo+ PkFuOiBNYXR0aGV3LkJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvLnVrOyBhbmNwQGlldGYub3JnDQo+ PkJldHJlZmY6IFJFOiBbQU5DUF0gTXVsdGljYXN0IGluIEFOQ1ANCj4+DQo+PkhpIEFsbCwNCj4+ DQo+PihjaGFpciBoYXQgb2ZmKQ0KPj4NCj4+SSBwcm9wb3NlIHRoYXQgdGhlIEFOQ1AgbXVsdGlj YXN0IHJlcXVpcmVtZW50cyBzaG91bGQgY292ZXIgdGhlDQo+PmZvbGxvd2luZyAzIGFyZWFzOg0K Pj4NCj4+MS4gRHluYW1pYyBjb25maWd1cmF0aW9uDQo+PlRoZXJlIGFwcGVhcnMgdG8gYmUgYSBu ZWVkIHRvIGJlIGFibGUgdG8gY29udHJvbCB0aGUgbXVsdGljYXN0DQo+PnJlcGxpY2F0aW9uIGF0 IHRoZSBhY2Nlc3Mtbm9kZSBpbiBhY2NvcmRhbmNlIHdpdGggcGVyIHVzZXIgb3IgcGVyDQo+PmNp cmN1aXQtaWQgcG9saWNpZXMga25vd24gYXQgdGhlIGNvbnRyb2xsZXIsIGFuZCBkbyBzbyBpbiBh IA0KPj5keW5hbWljIHZzIGENCj4+b25lIHRpbWUgcHJvdmlzaW9uZWQgbWFubmVyLiBDdXJyZW50 bHkgb3BlcmF0b3JzIGRvIHNvIGJ5IHN0YXRpY2FsbHkNCj4+Y29uZmlndXJpbmcgYW4gaW5ncmVz cyBJR01QIGZpbHRlcmluZyBBQ0wgb24gYSBnaXZlbiBjaXJjdWl0LWlkLCB3aGljaA0KPj5pcyBu b3QgYW1lbmFibGUgdG8gZHluYW1pYyBjaGFuZ2VzLiBCeSBkeW5hbWljIGNoYW5nZXMgaXQncyBt ZWFudCB0aGF0DQo+PnRoZXkgYXJlIG9uZXMgdGhhdCBhcmUgcXVpY2tseSBleGVjdXRlZCBpbiBy ZXNwb25zZSB0byBvdGhlciBzeXN0ZW0NCj4+ZXZlbnRzLCBlZyBhIHN1YnNjcmliZXIgc2Vzc2lv biBjb21pbmcgdXAvZG93biwgdGhlIGV4cGlyYXRpb24gb2YgYQ0KPj5xdW90YSBvciB0aW1lciwg b3IgYSBwb2xpY3kgdHJpZ2dlciwgb3IgZXZlbiBvcGVyYXRvciBjb21tYW5kLiANCj4+QU5DUCB3 b3VsZCBuZWVkIHRvIGJlIGFibGUgdG8gaW5zdGFsbCBzdWNoIEFDTHMgdGhyb3VnaCBhbiBlZmZp Y2llbnQNCj4+dHJhbnNhY3Rpb24gbWVjaGFuaXNtLiBUd28gZm9ybXMgb2YgaW5zdGFsbGF0aW9u IGFwcGVhciB0byBiZSANCj4+d29ydGh3aGlsZQ0KPj5vZiBjb25zaWRlcmF0aW9uOiANCj4+aSkg b3ZlcndyaXRlIC0gYSBjb21wbGV0ZSBBQ0wgaXMgYXBwbGllZCBpbiBhIHRyYW5zYWN0aW9uIG9u IGEgdGFyZ2V0DQo+PmNpcmN1aXQtaWQNCj4+aWkpIGFkZC9yZW1vdmUgLSBvbmUgb3IgbW9yZSBl bnRyaWVzIGFyZSBhZGRlZC9yZW1vdmVkIGluIGEgdHJhbnNhY3Rpb24NCj4+b24gYSB0YXJnZXQg Y2lyY3VpdC1pZC4NCj4+DQo+PjIuIFJlcG9ydGluZw0KPj5TZXZlcmFsIHNlcnZpY2UgcHJvdmlk ZXJzIGN1cnJlbnRseSBydW4gb3BlcmF0aW9uYWwgcHJvY2VkdXJlcyANCj4+dGhhdCByZWx5DQo+ Pm9uIGFuIG9wZXJhdG9yIGJlaW5nIGFibGUgdG8gaXNzdWUvdHJvdWJsZXNob290IGEgc3Vic2Ny aWJlcidzIHByb2JsZW1zDQo+IA0KPj5mcm9tIGEgQk5HLiBDbGFzc2ljIGV4YW1wbGVzIG9mIHRo ZXNlIGFyZSBBVE0gT0FNLCBhbmQgaXAgcGluZyB0ZXN0cywNCj4gDQo+PndpdGggdGhlIEFOQ1Ag T0FNICJ1c2UtY2FzZSIgYmVpbmcgYW4gZXh0ZW5zaW9uIHRoZXJlIG9mLiBJdCBhcHBlYXJzIHRv DQo+PmJlIHF1aXRlIGxhYm9yaW91cywgYW5kIG9mdGVuIHByb2JsZW1hdGljIGR1ZSB0byB0aGUg Y3Jvc3Npbmcgb2YNCj4+b3JnYW5pemF0aW9uYWwgYm91bmRhcmllcywgdG8gaGF2ZSB0aGUgcHJv Y2VkdXJlIHBlcmZvcm1lZCBhdCB0aGUNCj4+YWNjZXNzLW5vZGUuIFRyb3VibGVzaG9vdGluZyBv ZiBtdWx0aWNhc3QgZGVsaXZlcnkgaXMgYXMgeWV0IGEgYml0IG9mIGENCj4+YmxhY2sgYXJ0IHRv IG1hbnkgcHJvdmlkZXJzIHRoYXQgYXJlIG9ubHkgYmVnZ2luZyB0byBkZXBsb3kgDQo+PmFjY2Vz cy1ub2Rlcw0KPj5jYXBhYmxlIG9mIEwyIG11bHRpY2FzdCByZXBsaWNhdGlvbi4NCj4+SXQgd291 bGQgdGh1cyBhcHBlYXIgdG8gYmUgZGVzaXJhYmxlLCBpbiBvcmRlciB0byBhaWQgDQo+Pm9wZXJh dGlvbnMgaW4gc3VjaA0KPj5kZXBsb3ltZW50cywgdG8gaW50cm9kdWNlIGludG8gQU5DUCBhIHNl dCBvZiBtdWx0aWNhc3QgcmVwb3J0aW5nDQo+PmNvbW1hbmRzLCB0aGF0IHdvdWxkIGFsbG93IGEg Qk5HIG9wZXJhdG9yIHRvIGdhaW4ga25vd2xlZGdlIG9mIHRoZSBwZXINCj4+Y2lyY3VpdC1pZCBt dWx0aWNhc3QgcmVwbGljYXRpb24gc3RhdGUgb24gdGhlIGFjY2Vzcy1ub2RlLiANCj4+VGhpcyB3 b3VsZCBiZQ0KPj5hIHNpbXBsZSBxdWVyeS9yZXNwb25zZSBtZWNoYW5pc20sIGNvbW11bmljYXRp bmcgZnJvbSB0aGUgDQo+PmFjY2Vzcy1ub2RlIHRvDQo+PnRoZSBCTkcgdGhlIGN1cnJlbnRseSBh Y3RpdmUgbXVsdGljYXN0IGdyb3VwcyBvbiBhIGdpdmVuIHRhcmdldA0KPj4oY2lyY3VpdC1pZCkg YWxvbmcgd2l0aCBhcHBsaWNhYmxlIGNvdW50ZXJzIChlZyB0aW1lL2J5dGUgY291bnQpLg0KPj4N Cj4+My4gQ2hhbmdlIG9mIEwyIGZvcndhcmRpbmcNCj4+VGhlIGN1cnJlbnQgbm90aW9ucyBvZiBt dWx0aWNhc3QgcmVwbGljYXRpb24gb24gYSBMMiBlbGVtZW50IA0KPj5hcmUgbGltaXRlZA0KPj50 byB0aGUgZm9sbG93aW5nIHR3byBvcHRpb25zOiBmbG9vZCBhbGwgbXVsdGljYXN0IHdpdGggSUdN UCBzbm9vcGluZw0KPj5kaXNhYmxlZCwgb3Igc25vb3AgSUdNUCBhbmQgaW1tZWRpYXRlbHkgcmVw bGljYXRlL3N0b3AtcmVwbGljYXRpbmcNCj4+bXVsdGljYXN0Lg0KPj5JdCBhcHBlYXJzIHNlbnNp YmxlIHRvIGNvbnNpZGVyIGludHJvZHVjaW5nIGEgdGhpcmQgbm90aW9uIA0KPj50aGF0IGludm9s dmVzDQo+PkFOQ1AsIGFuZCBwcm92aWRlcyBhIG1vcmUgZ3JhbnVsYXIgcGVyIG11bHRpY2FzdCBn cm91cCBjb250cm9sIGFwcHJvYWNoDQo+Pmluc3RlYWQgb2YgdGhlIGFsbCBvciBub3RoaW5nIG9w dGlvbnMgYWJvdmUuIFRoaXMgd291bGQgDQo+PmNvbnNpc3QgaGF2aW5nIGENCj4+bGlzdCBvZiBz cGVjaWZpYyBncm91cHMgZm9yIHdoaWNoIHRoZSBhY2Nlc3Mgbm9kZSB3b3VsZCBub3QgZmxvb2Qg dGhlDQo+Pm11bHRpY2FzdCB0cmFmZmljIHRvIGEgcG9ydCwgYnV0IG5laXRoZXIgd291bGQgaXQg ZG8gSUdNUCBzbm9vcGluZywNCj4+cmF0aGVyIGl0IHdvdWxkIHBhc3MgSUdNUCB0cmFuc3BhcmVu dGx5IGFuZCBjb21tZW5jZSBvciBzdG9wIA0KPj5yZXBsaWNhdGlvbg0KPj53aGVuIGluc3RydWN0 ZWQgdmlhIEFOQ1AuIA0KPj5WYXJpb3VzIG9wdGltaXphdGlvbnMgY2FuIGJlIGludHJvZHVjZWQg dG8gdGhpcyBzY2hlbWUsIGJ1dCB0aGUNCj4+cHJpbmNpcGxlIHJlbWFpbnMgdGhlIHNhbWU7IHRo ZSBMMiBtdWx0aWNhc3QgcmVwbGljYXRpb24gbWVjaGFuaXNtLCBmb3INCj4+YSBnaXZlbiBncm91 cCBvciByYW5nZSwgd291bGQgYmUgZHJpdmVuIGJ5IEFOQ1Agc2lnbmFsbGluZy4NCj4+RGVwZW5k aW5nIG9uIHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvLCB0aGlzIHdvdWxkIGFwcGVhciB0byBiZSBh IGdvb2QNCj4+dG9vbCB0byB1dGlsaXplIHdoZW4gbXVsdGljYXN0IGF1dGhvcml6YXRpb24sIGFj Y291bnRpbmcsIG9yDQo+PmFzeW5jaHJvbm91cyBvcGVyYXRvciByZXF1ZXN0cyBhZmZlY3Rpbmcg bXVsdGljYXN0IGZvcndhcmRpbmcgYXJlDQo+PmRlc2lyZWQuDQo+Pg0KPj5SZWdhcmRzLA0KPj5X b2ouDQo+Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogTWF0dGhl dy5Cb2NjaUBhbGNhdGVsLWx1Y2VudC5jby51aw0KPj5bbWFpbHRvOk1hdHRoZXcuQm9jY2lAYWxj YXRlbC1sdWNlbnQuY28udWtdIA0KPj5TZW50OiAwNiBNYXJjaCAyMDA3IDE0OjQ5DQo+PlRvOiBh bmNwQGlldGYub3JnDQo+PlN1YmplY3Q6IFtBTkNQXSBNdWx0aWNhc3QgaW4gQU5DUA0KPj4NCj4+ SSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgZGlzY3Vzc2lvbiBvbiB3aGF0IHRoZSB3b3JraW5nIGdy b3VwIHdvdWxkIGxpa2UNCj4+dG8gZG8gd2l0aCBNdWx0aWNhc3QgaW4gQU5DUC4NCj4+DQo+PkN1 cnJlbnRseSB0aGUgQU5DUCBjaGFydGVyIGluY2x1ZGVzIG11bHRpY2FzdCBhcyBvbmUgb2YgdGhl IHVzZSBjYXNlcywNCj4+YXMNCj4+Zm9sbG93czoNCj4+DQo+PiJXaGVuIG11bHRpY2FzdCByZXBs aWNhdGlvbiBmb3Igc3Vic2NyaWJlci1ib3VuZCB0cmFmZmljIGlzIA0KPj5wZXJmb3JtZWQgYXQN Cj4+dGhlIEFOLCBpdCBvZmYtbG9hZHMgdGhlIG5ldHdvcmsgYmV0d2VlbiB0aGUgQU4gYW5kIE5B Uy4gSG93ZXZlciwgYQ0KPj5zdWJzY3JpYmVyJ3MgcG9saWN5IGFuZCBjb25maWd1cmF0aW9uIGZv ciBtdWx0aWNhc3QgdHJhZmZpYyBtYXkgb25seSBiZQ0KPj5rbm93biBhdCB0aGUgTkFTLiBBTkNQ IHdpbGwgcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBjb21tdW5pY2F0ZSB0aGUNCj4+bmVjZXNzYXJ5 IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJldHdlZW4gdGhlIEFOIGFuZCBOQVMgc28gYXMgdG8gDQo+ PmFsbG93IHRoZQ0KPj5BTiB0byBwZXJmb3JtIHN1YnNjcmliZXIgYm91bmQgbXVsdGljYXN0IGdy b3VwIHJlcGxpY2F0aW9uIGluIGxpbmUgd2l0aA0KPj50aGUgc3Vic2NyaWJlcidzIHBvbGljeSBh bmQgY29uZmlndXJhdGlvbiwgYW5kIGFsc28gYWxsb3cgdGhlIE5BUyB0bw0KPj5mb2xsb3cgZWFj aCBzdWJzY3JpYmVyJ3MgbXVsdGljYXN0IGdyb3VwIG1lbWJlcnNoaXAuIg0KPj4NCj4+VGhlIGZy YW1ld29yayBkcmFmdCAoZHJhZnQtaWV0Zi1hbmNwLWZyYW1ld29yay0wMS50eHQpIHNheXMgdGhh dCB0aGUNCj4+YWNjZXNzIGxvb3AgY29uZmlndXJhdGlvbiBtZWNoYW5pc21zIG1heSBiZSB1c2Vm dWwgZm9yIHNldHRpbmcgdGhlDQo+PnBlci1TdWJzY3JpYmVyIG11bHRpY2FzdCBjaGFubmVsIGVu dGl0bGVtZW50IGluZm9ybWF0aW9uLCB1c2VkIGZvciBJUFRWDQo+PmFwcGxpY2F0aW9ucyB3aGVy ZSB0aGUgQWNjZXNzIE5vZGUgaXMgcGVyZm9ybWluZyBJR01QIHNub29waW5nIG9yIElHTVANCj4+ cHJveHkgZnVuY3Rpb24uIEl0IGdvZXMgb24gdG8gc2F5IHRoYXQgYSBTdWJzY3JpYmVyJ3MgcG9s aWN5IGFuZA0KPj5jb25maWd1cmF0aW9uIGZvciBtdWx0aWNhc3QgdHJhZmZpYyBtaWdodCBvbmx5 IGJlIGtub3duIGF0IHRoZSBOQVMuIFRoZQ0KPj5BY2Nlc3MgTm9kZSBDb250cm9sIE1lY2hhbmlz bSBjb3VsZCBiZSB1c2VkIHRvIGV4Y2hhbmdlIHRoZSBuZWNlc3NhcnkNCj4+aW5mb3JtYXRpb24g YmV0d2VlbiB0aGUgQWNjZXNzIE5vZGUgYW5kIHRoZSBOQVMgc28gYXMgdG8gYWxsb3cgdGhlDQo+ PkFjY2VzcyBOb2RlIHRvIHBlcmZvcm0gbXVsdGljYXN0IHJlcGxpY2F0aW9uIGluIGxpbmUgd2l0 aCAgdGhlDQo+PlN1YnNjcmliZXIncyBwb2xpY3kgYW5kIGNvbmZpZ3VyYXRpb24sIGFuZCBhbHNv IGFsbG93IHRoZSBOQVMgdG8gZm9sbG93DQo+PmVhY2ggU3Vic2NyaWJlcidzIG11bHRpY2FzdCBn cm91cCBtZW1iZXJzaGlwLg0KPj4NCj4+DQo+Pk5vbmUgb2YgdGhlc2UgbXVsdGljYXN0IG1lY2hh bmlzbXMgYXJlIGRlZmluZWQgaW4gdGhlIEFOQ1AgcHJvdG9jb2wNCj4+ZHJhZnQsIGFuZCBJIHRo aW5rIHRoZXJlIGlzIGluc3VmZmljaWVudCBkZXRhaWwgaW4gdGhlIGZyYW1ld29yayBkcmFmdA0K Pj50byBmdWxseSBzcGVjaWZ5IHRoaXMgdXNlIGNhc2UuDQo+Pg0KPj5UaGVyZSBoYXMgYmVlbiB2 ZXJ5IGxpdHRsZSB3b3JrIG9uIHRoaXMgc2luY2UgdGhlIGNoYXJ0ZXIgZGlzY3Vzc2lvbnMsDQo+ PmJ1dCB0aGUgQU5DUCB3b3JraW5nIGdyb3VwIG5lZWRzIHRvIGNsYXJpZnkgd2hhdCBpdCB3YW50 cyB0byBkbyAoaWYNCj4+YW55dGhpbmcpIHdpdGggbXVsdGljYXN0IGZvciB0aGUgZnJhbWV3b3Jr IGNhbiBtb3ZlIGZvcndhcmQuIEkgdGhpbmsNCj4+dGhlcmUgYXJlIHR3bw0KPj5jaG9pY2VzOiBF aXRoZXIgd2Ugc2hvdWxkIGNsYXJpZnkgdGhlIHVzZSBjYXNlIGFuZCBzcGVjaWZ5IHRoZSBBTkNQ DQo+PnByb3RvY29sIHRvIHN1cHBvcnQgaXQsIG9yIHdlIHNob3VsZCByZW1vdmUgdGhlIG11bHRp Y2FzdCB1c2UgY2FzZSBmcm9tDQo+PnRoZSBmcmFtZXdvcmsgZm9yIG5vdy4NCj4+DQo+PlBsZWFz ZSBwb3N0IHlvdXIgb3BpbmlvbnMgdG8gdGhlIGxpc3QuIFdlIHBsYW4gdG8gaGF2ZSBhIGRpc2N1 c3Npb24gb24NCj4+dGhpcyBpbiBQcmFndWUsIGFuZCB0byB0cnkgdG8gcmVhY2ggYSBjb25zZW5z dXMgYXQgYXJvdW5kIHRoYXQgdGltZS4NCj4+DQo+PkJlc3QgcmVnYXJkcywNCj4+DQo+Pk1hdHRo ZXcNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkFOQ1AgbWFpbGluZyBsaXN0 DQo+PkFOQ1BAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5jcA0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+QU5DUCBtYWlsaW5nIGxpc3QNCj4+QU5DUEBpZXRmLm9yZw0KPj5odHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmNwDQo+Pg0KPj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5BTkNQIG1haWxpbmcgbGlzdA0KPj5B TkNQQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fu Y3ANCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PkFOQ1AgbWFpbGluZyBsaXN0DQo+PkFOQ1BAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcA0KPj4NCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBTkNQIG1haWxpbmcgbGlzdA0K PiBBTkNQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FuY3ANCg== --===============0885012280== 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 --===============0885012280==-- From ancp-bounces@ietf.org Fri Mar 16 09:04:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSC6V-00084D-9d; Fri, 16 Mar 2007 09:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSC6U-000848-37 for ancp@ietf.org; Fri, 16 Mar 2007 09:04:18 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSC6T-0001kO-7m for ancp@ietf.org; Fri, 16 Mar 2007 09:04:18 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 16 Mar 2007 06:04:14 -0700 X-IronPort-AV: i="4.14,292,1170662400"; d="scan'208"; a="671225489:sNHT67126948" 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] Multicast in ANCP Date: Fri, 16 Mar 2007 09:04:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2807C6A1A6@proton.jnpr.net> In-Reply-To: <45FA7E07.1080600@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: AcdnvYDy4WTM9et3SSmzDxmc3K1OfQACUnGg From: "Sanjay Wadhwa" To: X-Spam-Score: 2.3 (++) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 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 Remote troubleshooting from NAS for basic fault isolation seems useful = to me in case of multicast too. I am not sure why it is very hard (as = you say) to get visibility via ANCP into some basic multicast data = counters for a port, which an AN would normally maintain. And same with = MAC level multicast entries. As currently defined ANCP OAM allows = returning more than just state.=20 Regards -Sanjay -----Original Message----- From: stefaan.de_cnodder@alcatel-lucent.be = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Friday, March 16, 2007 7:23 AM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: Re: [ANCP] Multicast in ANCP Sanjay, It looks you are proposing new functionality in ANCP for more detailed=20 troubleshooting in the AN from the NAS, but then the question is where=20 it stops, and it looks to me that such a detailed troubleshooting should = be better done at the AN itself. Look to the current OAM: there is just = some indication of the state of the DSL line and nothing more and the=20 detailed troubleshooting (spectrum analyis, ...) is to be done on the AN = itself. In fact, for multicast, I have done lots of troubleshooting in=20 live networks and whatever you do in ANCP, the most important=20 functionality such as protocol tracing, detailed error counters, ...=20 will be very hard to support in ANCP. The proposed extension by Woj on=20 getting visibility on the multicast forwarding table in the AN, will not = help a lot in futher isolating the problem. If the entry is there or=20 not, then the problem can be still anywhere in the network and up to the = application layer. And if the problem is in the AN (a bug, or whatever) = the information given in ANCP could be faulty information. regards, Stefaan Sanjay Wadhwa wrote: > Moti > One of the motivation for NAS to control replication state on the AN = is to subject it to admission control (based on multiple services being = delivered to the same local-loop). The NAS needs per-subscriber IGMP = visibility to do this. Once it gets this visibilty, per-subscriber = accounting and dynamic management of QoS for the local-loop comes as a = bonus. In this case IGMP state machine is running between RG and NAS. = So, IGMP query is good enough to figure out the state on RG.=20 > However, the last point of replication in the network is the AN. I = take use-case #2 as a means to help with troubleshooting when say an RG = is not recieving a multicast stream. In this case the operator from the = NAS can use ANCP to trigger AN to provide stats such as "dropped and = forwarded multicast packets or bytes" per local-loop (ACI) or can = trigger it to report the MAC based multicast filter entries for an = access-loop. If we implement use-case #3, then I think #2 is a = pre-requisite. I also think if we do use-case #3, then high-availability = based on "ANCP graceful restart" is a pre-requisite for both AN and NAS. = Without these two, we don't have a carrier-grade solution. >=20 > Regards > -Sanjay >=20 > =20 >=20 >=20 >=20 >>2) Reporting >>- If IGMP snooping is being used at the AN then all accounting=20 >>data (volume/time) may be known at the NAS. >>- IGMP proxy is being used normally for flat-rate service. >>- Hence, ANCP is not needed for reporting as IGMP itself has=20 >>the right modes to help support multicast records at the NAS,=20 >>if required.=20 >=20 >=20 >>-----Original Message----- >>From: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] >>Sent: Thursday, March 15, 2007 1:16 PM >>To: ancp@ietf.org >>Subject: RE: [ANCP] Multicast in ANCP >> >> >>Hi all, >> >>Having experience in managing multicast services in the AN I=20 >>have the following thoughts regarding the 3 topics in Wojciech's mail: >> >>1) Configuration >>- NAS will (dynamically) configure the ACLs at the AN per each=20 >>circuit-ID, based on any criteria it implements.=20 >>- The ANCP could also be used to (dynamically) configure the=20 >>maximum number of multicast channels and aggregate bandwidth=20 >>allowed for each circuit-ID for multicast channels. >> >>2) Reporting >>- If IGMP snooping is being used at the AN then all accounting=20 >>data (volume/time) may be known at the NAS. >>- IGMP proxy is being used normally for flat-rate service. >>- Hence, ANCP is not needed for reporting as IGMP itself has=20 >>the right modes to help support multicast records at the NAS,=20 >>if required.=20 >> >>3) L2 Forwarding >>- As already stated, the fastest response to zapping requests=20 >>is by utilizing a set of dynamically updated ACLs residing at=20 >>the AN, closer to the customer.=20 >>- I share the concerns of Thomas Haag regarding performance=20 >>and timing issues. It is obvious that the NAS-AN interface=20 >>adds a delay to zapping time not to mention the fact that NAS=20 >>will need to handle many more concurrent IGMP requests to be=20 >>treated in real-time. If performed at the AN the IGMP=20 >>join/leave requests load is distributed between all ANs. >>- Finally, from a service reliability point-of-view, when the=20 >>ANCP is not available for any reason the AN can still use the=20 >>most updated ACLs it has and the service is unaffected. >> >>Regards, >>Moti Morgenstern >> >>-----Original Message----- >>From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 >>Sent: Wednesday, March 14, 2007 5:45 PM >>To: ancp@ietf.org >>Cc: Busser, M >>Subject: AW: [ANCP] Multicast in ANCP >> >>Hi all, >> >>Thanks for pointing out several options dealing with ANCP and=20 >>Multicast. >> >>Some points are interesting raising new requirements, some=20 >>points bringing up new concerns regarding interoperability=20 >>AN/NAS, extending the existing charter by introducing new=20 >>requirements which may have impact to already existing=20 >>requirements and use cases. ANCP can do many things but the=20 >>operational impact as well as impact on interaction between=20 >>NAS and AN which is out of scope of a protocol specification=20 >>but needs to be taken into account too. >> >>Below I tried to summarize it step by step: >> >>1. I support option 1 enabling MC per AN port by=20 >>configuring entitlement data of an AN in order control=20 >>ACL in conjunction with session start/stop. I also=20 >>support the idea to consider PPPoE as well as DHCP. >> >>2. I support also using the OAM feature as it is described=20 >>now by using ANCP as trigger an report function between AN=20 >>and NAS to enable OAM fault management between AN and=20 >>CPE at DSL line such as e.g. ATM F5 LB Port Status=20 >>message or equivalent Ethernet feature. These functions are=20 >>still used in a point to point manner checking a connection. >> >> I have some concerns and don't support the idea to mix=20 >>the sense of these OAM features with Multicast OAM which is=20 >>total different.=20 >> The difference is here to poll a state of a Multicast=20 >>Point which is not any more an OAM feature enabling=20 >>line testing towards the DSL CPE. This is a function=20 >>which needs state awareness which is a new field which=20 >>is not considered so far and has some drawbacks to already =09 >>existing use cases.=20 >> >> So from my point of view it needs to be considered but=20 >>goes beyond the charter and the use case Multicast itself. >> >>3. Using ANCP in a way to control Multicast per multicast=20 >>group seems from a flexible service delivery standpoint as=20 >>an option. >> But considering the impact which the dynamic=20 >>interaction between AN and NAS will bring I have=20 >>strong concerns regarding performance and timing issues=20 >>with respect to channel change time if customer is =09 >>zapping. Also in case of failure this scenario maintenance can=20 >>not performed successfully.=20 >> >> Taking this into account I don't support option 3 which=20 >>describes configuration of the L2 replication state=20 >>without IGMP processing for some dedicated ports. >> >>Regards >> >>Thomas Haag >> >> >>-----Urspr=FCngliche Nachricht----- >>Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 >>Gesendet: Montag, 12. M=E4rz 2007 17:14 >>An: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org >>Betreff: RE: [ANCP] Multicast in ANCP >> >>Hi All, >> >>(chair hat off) >> >>I propose that the ANCP multicast requirements should cover the >>following 3 areas: >> >>1. Dynamic configuration >>There appears to be a need to be able to control the multicast >>replication at the access-node in accordance with per user or per >>circuit-id policies known at the controller, and do so in a=20 >>dynamic vs a >>one time provisioned manner. Currently operators do so by statically >>configuring an ingress IGMP filtering ACL on a given circuit-id, which >>is not amenable to dynamic changes. By dynamic changes it's meant that >>they are ones that are quickly executed in response to other system >>events, eg a subscriber session coming up/down, the expiration of a >>quota or timer, or a policy trigger, or even operator command.=20 >>ANCP would need to be able to install such ACLs through an efficient >>transaction mechanism. Two forms of installation appear to be=20 >>worthwhile >>of consideration:=20 >>i) overwrite - a complete ACL is applied in a transaction on a target >>circuit-id >>ii) add/remove - one or more entries are added/removed in a = transaction >>on a target circuit-id. >> >>2. Reporting >>Several service providers currently run operational procedures=20 >>that rely >>on an operator being able to issue/troubleshoot a subscriber's = problems >=20 >>from a BNG. Classic examples of these are ATM OAM, and ip ping tests, >=20 >>with the ANCP OAM "use-case" being an extension there of. It appears = to >>be quite laborious, and often problematic due to the crossing of >>organizational boundaries, to have the procedure performed at the >>access-node. Troubleshooting of multicast delivery is as yet a bit of = a >>black art to many providers that are only begging to deploy=20 >>access-nodes >>capable of L2 multicast replication. >>It would thus appear to be desirable, in order to aid=20 >>operations in such >>deployments, to introduce into ANCP a set of multicast reporting >>commands, that would allow a BNG operator to gain knowledge of the per >>circuit-id multicast replication state on the access-node.=20 >>This would be >>a simple query/response mechanism, communicating from the=20 >>access-node to >>the BNG the currently active multicast groups on a given target >>(circuit-id) along with applicable counters (eg time/byte count). >> >>3. Change of L2 forwarding >>The current notions of multicast replication on a L2 element=20 >>are limited >>to the following two options: flood all multicast with IGMP snooping >>disabled, or snoop IGMP and immediately replicate/stop-replicating >>multicast. >>It appears sensible to consider introducing a third notion=20 >>that involves >>ANCP, and provides a more granular per multicast group control = approach >>instead of the all or nothing options above. This would=20 >>consist having a >>list of specific groups for which the access node would not flood the >>multicast traffic to a port, but neither would it do IGMP snooping, >>rather it would pass IGMP transparently and commence or stop=20 >>replication >>when instructed via ANCP.=20 >>Various optimizations can be introduced to this scheme, but the >>principle remains the same; the L2 multicast replication mechanism, = for >>a given group or range, would be driven by ANCP signalling. >>Depending on the deployment scenario, this would appear to be a good >>tool to utilize when multicast authorization, accounting, or >>asynchronous operator requests affecting multicast forwarding are >>desired. >> >>Regards, >>Woj. >> >> >>-----Original Message----- >>From: Matthew.Bocci@alcatel-lucent.co.uk >>[mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 >>Sent: 06 March 2007 14:49 >>To: ancp@ietf.org >>Subject: [ANCP] Multicast in ANCP >> >>I would like to start a discussion on what the working group would = like >>to do with Multicast in ANCP. >> >>Currently the ANCP charter includes multicast as one of the use cases, >>as >>follows: >> >>"When multicast replication for subscriber-bound traffic is=20 >>performed at >>the AN, it off-loads the network between the AN and NAS. However, a >>subscriber's policy and configuration for multicast traffic may only = be >>known at the NAS. ANCP will provide a mechanism to communicate the >>necessary information exchange between the AN and NAS so as to=20 >>allow the >>AN to perform subscriber bound multicast group replication in line = with >>the subscriber's policy and configuration, and also allow the NAS to >>follow each subscriber's multicast group membership." >> >>The framework draft (draft-ietf-ancp-framework-01.txt) says that the >>access loop configuration mechanisms may be useful for setting the >>per-Subscriber multicast channel entitlement information, used for = IPTV >>applications where the Access Node is performing IGMP snooping or IGMP >>proxy function. It goes on to say that a Subscriber's policy and >>configuration for multicast traffic might only be known at the NAS. = The >>Access Node Control Mechanism could be used to exchange the necessary >>information between the Access Node and the NAS so as to allow the >>Access Node to perform multicast replication in line with the >>Subscriber's policy and configuration, and also allow the NAS to = follow >>each Subscriber's multicast group membership. >> >> >>None of these multicast mechanisms are defined in the ANCP protocol >>draft, and I think there is insufficient detail in the framework draft >>to fully specify this use case. >> >>There has been very little work on this since the charter discussions, >>but the ANCP working group needs to clarify what it wants to do (if >>anything) with multicast for the framework can move forward. I think >>there are two >>choices: Either we should clarify the use case and specify the ANCP >>protocol to support it, or we should remove the multicast use case = from >>the framework for now. >> >>Please post your opinions to the list. We plan to have a discussion on >>this in Prague, and to try to reach a consensus at around that time. >> >>Best regards, >> >>Matthew >> >> >> >> >> >> >> >> >> >> >>_______________________________________________ >>ANCP mailing list >>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 >> >=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 Fri Mar 16 09:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSCu1-0000EJ-St; Fri, 16 Mar 2007 09:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSCu0-0000EB-5Q for ancp@ietf.org; Fri, 16 Mar 2007 09:55:28 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSCtx-0002Fo-P3 for ancp@ietf.org; Fri, 16 Mar 2007 09:55:28 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2GDtUH3027365; Fri, 16 Mar 2007 14:55:31 +0100 Received: from [172.31.131.185] ([172.31.131.185]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031614552242:4293 ; Fri, 16 Mar 2007 14:55:22 +0100 Message-ID: <45FAA1C7.5080509@alcatel-lucent.be> Date: Fri, 16 Mar 2007 14:55:19 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sanjay Wadhwa Subject: Re: [ANCP] Multicast in ANCP References: <9BD5D7887235424FA97DFC223CAE3C2807C6A1A6@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2807C6A1A6@proton.jnpr.net> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/16/2007 14:55:22, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/16/2007 14:55:24 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 2.5 (++) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 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="===============1468347141==" Errors-To: ancp-bounces@ietf.org --===============1468347141== Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 DQpTYW5qYXksDQoNCnNlZSBpbmxpbmUuLi4NCg0KU2FuamF5IFdhZGh3YSB3cm90ZToNCg0KPiBT dGVmYWFuDQo+ICAgUmVtb3RlIHRyb3VibGVzaG9vdGluZyBmcm9tIE5BUyBmb3IgYmFzaWMgZmF1 bHQgaXNvbGF0aW9uIHNlZW1zIHVzZWZ1bCB0byBtZSBpbiBjYXNlIG9mIG11bHRpY2FzdCB0b28u DQoNCmRlZmluaXRlbHkgdHJvdWJsZXNob290aW5nIGlzIGltcG9ydGFudCwgYnV0IHRoZSBxdWVz dGlvbiBpcyB3aGV0aGVyIA0KdHJvdWJsZXNob290aW5nIGZyb20gdGhlIE5BUyB2aWEgQU5DUCBp cyB0aGUgcmlnaHQgd2F5IG9mIGRvaW5nIHRoaXMuDQoNCkkgbGlrZSB0aGUgY3VycmVudCBPQU0g aW4gdGhlIGRyYWZ0IGJlY2F1c2UgaXQgY2FuIGluZGljYXRlIHdoZXRoZXIgdGhlIA0KcHJvYmxl bSBoYXMgdG8gYmUgZnVydGhlciBpbnZlc3RpZ2F0ZWQgb24gdGhlIEFOL0RTTEFNIG9yIG5vdCwg YnV0IGNhbiANCnRoZSBzYW1lIGJlIGFjaGlldmVkIGZvciBtdWx0aWNhc3QgaW4gYSBzaW1wbHkg d2F5IHN1Y2ggdGhhdCB0aGUgDQpwcm90b2NvbCBkb2VzIGdldCAib3ZlcnNwZWNpZmllZCIgd2l0 aCBhbGwga2luZHMgb2YgY291bnRlcnMgYW5kIG90aGVyIA0KaW5mb3JtYXRpb24/ICBJZiB5ZXMs IHZlcnkgZ29vZCBmb3IgbWUgaW4gdGhhdCBjYXNlIGJ1dCB3aXRoIGV4cG9ydGluZyANCm9ubHkg c29tZSBiYXNpYyBpbmZvcm1hdGlvbiwgSSBhbSBub3Qgc3VyZSB0aGF0IGEgYmlnIHByb2JsZW0g aXMgc29sdmVkIA0Kd2hpY2ggaXMgd29ydGggaGF2aW5nIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0 eSBpbiBBTkNQLg0KDQpJIGFtIG5vdCBzdXJlIHdoeSBpdCBpcyB2ZXJ5IGhhcmQgKGFzIHlvdSBz YXkpIHRvIGdldCB2aXNpYmlsaXR5IHZpYSANCkFOQ1AgaW50byBzb21lIGJhc2ljIG11bHRpY2Fz dCBkYXRhIGNvdW50ZXJzDQoNCmJhc2ljIGNvdW50ZXJzIGFyZSBub3QgZGlmZmljdWx0LCBzZWUg bXkgZW1haWwgYmVsb3cuICBXaGljaCBpbmZvcm1hdGlvbiANCmxvb2tzIHN1ZmZpY2llbnQgdG8g eW91IHRoYXQgY2FuIGJlIHJldHJpZXZlZCBpbiBzdWNoIGEgcmVxdWVzdC9yZXNwb25zZSANCm1l Y2hhbmlzbT8gIEFyZSB0aGUgbXVsdGljYXN0IGVudHJpZXMgb24gYSBwYXJ0aWN1bGFyIGxpbmUg YmUgc3VmZmljaWVudD8NCg0KcmVnYXJkcywNClN0ZWZhYW4NCg0KDQoNCiAgZm9yIGEgcG9ydCwg d2hpY2ggYW4gQU4gd291bGQgbm9ybWFsbHkgbWFpbnRhaW4uIEFuZCBzYW1lIHdpdGggTUFDIA0K bGV2ZWwgbXVsdGljYXN0IGVudHJpZXMuIEFzIGN1cnJlbnRseSBkZWZpbmVkIEFOQ1AgT0FNIGFs bG93cyByZXR1cm5pbmcgDQptb3JlIHRoYW4ganVzdCBzdGF0ZS4NCj4gDQo+IFJlZ2FyZHMNCj4g LVNhbmpheQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc3RlZmFh bi5kZV9jbm9kZGVyQGFsY2F0ZWwtbHVjZW50LmJlIFttYWlsdG86c3RlZmFhbi5kZV9jbm9kZGVy QGFsY2F0ZWwtbHVjZW50LmJlXSANCj4gU2VudDogRnJpZGF5LCBNYXJjaCAxNiwgMjAwNyA3OjIz IEFNDQo+IFRvOiBTYW5qYXkgV2FkaHdhDQo+IENjOiBhbmNwQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbQU5DUF0gTXVsdGljYXN0IGluIEFOQ1ANCj4gDQo+IA0KPiBTYW5qYXksDQo+IA0KPiBJ dCBsb29rcyB5b3UgYXJlIHByb3Bvc2luZyBuZXcgZnVuY3Rpb25hbGl0eSBpbiBBTkNQIGZvciBt b3JlIGRldGFpbGVkIA0KPiB0cm91Ymxlc2hvb3RpbmcgaW4gdGhlIEFOIGZyb20gdGhlIE5BUywg YnV0IHRoZW4gdGhlIHF1ZXN0aW9uIGlzIHdoZXJlIA0KPiBpdCBzdG9wcywgYW5kIGl0IGxvb2tz IHRvIG1lIHRoYXQgc3VjaCBhIGRldGFpbGVkIHRyb3VibGVzaG9vdGluZyBzaG91bGQgDQo+IGJl IGJldHRlciBkb25lIGF0IHRoZSBBTiBpdHNlbGYuICBMb29rIHRvIHRoZSBjdXJyZW50IE9BTTog dGhlcmUgaXMganVzdCANCj4gc29tZSBpbmRpY2F0aW9uIG9mIHRoZSBzdGF0ZSBvZiB0aGUgRFNM IGxpbmUgYW5kIG5vdGhpbmcgbW9yZSBhbmQgdGhlIA0KPiBkZXRhaWxlZCB0cm91Ymxlc2hvb3Rp bmcgKHNwZWN0cnVtIGFuYWx5aXMsIC4uLikgaXMgdG8gYmUgZG9uZSBvbiB0aGUgQU4gDQo+IGl0 c2VsZi4gIEluIGZhY3QsIGZvciBtdWx0aWNhc3QsIEkgaGF2ZSBkb25lIGxvdHMgb2YgdHJvdWJs ZXNob290aW5nIGluIA0KPiBsaXZlIG5ldHdvcmtzIGFuZCB3aGF0ZXZlciB5b3UgZG8gaW4gQU5D UCwgdGhlIG1vc3QgaW1wb3J0YW50IA0KPiBmdW5jdGlvbmFsaXR5IHN1Y2ggYXMgcHJvdG9jb2wg dHJhY2luZywgZGV0YWlsZWQgZXJyb3IgY291bnRlcnMsIC4uLiANCj4gd2lsbCBiZSB2ZXJ5IGhh cmQgdG8gc3VwcG9ydCBpbiBBTkNQLiAgVGhlIHByb3Bvc2VkIGV4dGVuc2lvbiBieSBXb2ogb24g DQo+IGdldHRpbmcgdmlzaWJpbGl0eSBvbiB0aGUgbXVsdGljYXN0IGZvcndhcmRpbmcgdGFibGUg aW4gdGhlIEFOLCB3aWxsIG5vdCANCj4gaGVscCBhIGxvdCBpbiBmdXRoZXIgaXNvbGF0aW5nIHRo ZSBwcm9ibGVtLiAgSWYgdGhlIGVudHJ5IGlzIHRoZXJlIG9yIA0KPiBub3QsIHRoZW4gdGhlIHBy b2JsZW0gY2FuIGJlIHN0aWxsIGFueXdoZXJlIGluIHRoZSBuZXR3b3JrIGFuZCB1cCB0byB0aGUg DQo+IGFwcGxpY2F0aW9uIGxheWVyLiAgQW5kIGlmIHRoZSBwcm9ibGVtIGlzIGluIHRoZSBBTiAo YSBidWcsIG9yIHdoYXRldmVyKSANCj4gdGhlIGluZm9ybWF0aW9uIGdpdmVuIGluIEFOQ1AgY291 bGQgYmUgZmF1bHR5IGluZm9ybWF0aW9uLg0KPiANCj4gcmVnYXJkcywNCj4gU3RlZmFhbg0KPiAN Cj4gU2FuamF5IFdhZGh3YSB3cm90ZToNCj4gDQo+IA0KPj5Nb3RpDQo+PiAgT25lIG9mIHRoZSBt b3RpdmF0aW9uIGZvciBOQVMgdG8gY29udHJvbCByZXBsaWNhdGlvbiBzdGF0ZSBvbiB0aGUgQU4g aXMgdG8gc3ViamVjdCBpdCB0byBhZG1pc3Npb24gY29udHJvbCAoYmFzZWQgb24gbXVsdGlwbGUg c2VydmljZXMgYmVpbmcgZGVsaXZlcmVkIHRvIHRoZSBzYW1lIGxvY2FsLWxvb3ApLiBUaGUgTkFT IG5lZWRzIHBlci1zdWJzY3JpYmVyIElHTVAgdmlzaWJpbGl0eSB0byBkbyB0aGlzLiBPbmNlIGl0 IGdldHMgdGhpcyB2aXNpYmlsdHksIHBlci1zdWJzY3JpYmVyIGFjY291bnRpbmcgYW5kIGR5bmFt aWMgbWFuYWdlbWVudCBvZiBRb1MgZm9yIHRoZSBsb2NhbC1sb29wIGNvbWVzIGFzIGEgYm9udXMu IEluIHRoaXMgY2FzZSBJR01QIHN0YXRlIG1hY2hpbmUgaXMgcnVubmluZyBiZXR3ZWVuIFJHIGFu ZCBOQVMuIFNvLCBJR01QIHF1ZXJ5IGlzIGdvb2QgZW5vdWdoIHRvIGZpZ3VyZSBvdXQgdGhlIHN0 YXRlIG9uIFJHLiANCj4+SG93ZXZlciwgdGhlIGxhc3QgcG9pbnQgb2YgcmVwbGljYXRpb24gaW4g dGhlIG5ldHdvcmsgaXMgdGhlIEFOLiBJIHRha2UgdXNlLWNhc2UgIzIgYXMgYSBtZWFucyB0byBo ZWxwIHdpdGggdHJvdWJsZXNob290aW5nIHdoZW4gc2F5IGFuIFJHIGlzIG5vdCByZWNpZXZpbmcg YSBtdWx0aWNhc3Qgc3RyZWFtLiBJbiB0aGlzIGNhc2UgdGhlIG9wZXJhdG9yIGZyb20gdGhlIE5B UyBjYW4gdXNlIEFOQ1AgdG8gdHJpZ2dlciBBTiB0byBwcm92aWRlIHN0YXRzIHN1Y2ggYXMgImRy b3BwZWQgYW5kIGZvcndhcmRlZCBtdWx0aWNhc3QgcGFja2V0cyBvciBieXRlcyIgcGVyIGxvY2Fs LWxvb3AgKEFDSSkgb3IgY2FuIHRyaWdnZXIgaXQgdG8gcmVwb3J0IHRoZSBNQUMgYmFzZWQgbXVs dGljYXN0IGZpbHRlciBlbnRyaWVzIGZvciBhbiBhY2Nlc3MtbG9vcC4gSWYgd2UgaW1wbGVtZW50 IHVzZS1jYXNlICMzLCB0aGVuIEkgdGhpbmsgIzIgaXMgYSBwcmUtcmVxdWlzaXRlLiBJIGFsc28g dGhpbmsgaWYgd2UgZG8gdXNlLWNhc2UgIzMsIHRoZW4gaGlnaC1hdmFpbGFiaWxpdHkgYmFzZWQg b24gIkFOQ1AgZ3JhY2VmdWwgcmVzdGFydCIgaXMgYSBwcmUtcmVxdWlzaXRlIGZvciBib3RoIEFO IGFuZCBOQVMuIFdpdGhvdXQgdGhlc2UgdHdvLCB3ZSBkb24ndCBoYXZlIGEgY2Fycmllci1ncmFk ZSBzb2x1dGlvbi4NCj4+DQo+PlJlZ2FyZHMNCj4+LVNhbmpheQ0KPj4NCj4+IA0KPj4NCj4+DQo+ Pg0KPj4NCj4+PjIpIFJlcG9ydGluZw0KPj4+LSBJZiBJR01QIHNub29waW5nIGlzIGJlaW5nIHVz ZWQgYXQgdGhlIEFOIHRoZW4gYWxsIGFjY291bnRpbmcgDQo+Pj5kYXRhICh2b2x1bWUvdGltZSkg bWF5IGJlIGtub3duIGF0IHRoZSBOQVMuDQo+Pj4tIElHTVAgcHJveHkgaXMgYmVpbmcgdXNlZCBu b3JtYWxseSBmb3IgZmxhdC1yYXRlIHNlcnZpY2UuDQo+Pj4tIEhlbmNlLCBBTkNQIGlzIG5vdCBu ZWVkZWQgZm9yIHJlcG9ydGluZyBhcyBJR01QIGl0c2VsZiBoYXMgDQo+Pj50aGUgcmlnaHQgbW9k ZXMgdG8gaGVscCBzdXBwb3J0IG11bHRpY2FzdCByZWNvcmRzIGF0IHRoZSBOQVMsIA0KPj4+aWYg cmVxdWlyZWQuIA0KPj4NCj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJv bTogTW90aSBNb3JnZW5zdGVybiBbbWFpbHRvOk1vdGkuTW9yZ2Vuc3Rlcm5AZWNpdGVsZS5jb21d DQo+Pj5TZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMDcgMToxNiBQTQ0KPj4+VG86IGFuY3BA aWV0Zi5vcmcNCj4+PlN1YmplY3Q6IFJFOiBbQU5DUF0gTXVsdGljYXN0IGluIEFOQ1ANCj4+Pg0K Pj4+DQo+Pj5IaSBhbGwsDQo+Pj4NCj4+PkhhdmluZyBleHBlcmllbmNlIGluIG1hbmFnaW5nIG11 bHRpY2FzdCBzZXJ2aWNlcyBpbiB0aGUgQU4gSSANCj4+PmhhdmUgdGhlIGZvbGxvd2luZyB0aG91 Z2h0cyByZWdhcmRpbmcgdGhlIDMgdG9waWNzIGluIFdvamNpZWNoJ3MgbWFpbDoNCj4+Pg0KPj4+ MSkgQ29uZmlndXJhdGlvbg0KPj4+LSBOQVMgd2lsbCAoZHluYW1pY2FsbHkpIGNvbmZpZ3VyZSB0 aGUgQUNMcyBhdCB0aGUgQU4gcGVyIGVhY2ggDQo+Pj5jaXJjdWl0LUlELCBiYXNlZCBvbiBhbnkg Y3JpdGVyaWEgaXQgaW1wbGVtZW50cy4gDQo+Pj4tIFRoZSBBTkNQIGNvdWxkIGFsc28gYmUgdXNl ZCB0byAoZHluYW1pY2FsbHkpIGNvbmZpZ3VyZSB0aGUgDQo+Pj5tYXhpbXVtIG51bWJlciBvZiBt dWx0aWNhc3QgY2hhbm5lbHMgYW5kIGFnZ3JlZ2F0ZSBiYW5kd2lkdGggDQo+Pj5hbGxvd2VkIGZv ciBlYWNoIGNpcmN1aXQtSUQgZm9yIG11bHRpY2FzdCBjaGFubmVscy4NCj4+Pg0KPj4+MikgUmVw b3J0aW5nDQo+Pj4tIElmIElHTVAgc25vb3BpbmcgaXMgYmVpbmcgdXNlZCBhdCB0aGUgQU4gdGhl biBhbGwgYWNjb3VudGluZyANCj4+PmRhdGEgKHZvbHVtZS90aW1lKSBtYXkgYmUga25vd24gYXQg dGhlIE5BUy4NCj4+Pi0gSUdNUCBwcm94eSBpcyBiZWluZyB1c2VkIG5vcm1hbGx5IGZvciBmbGF0 LXJhdGUgc2VydmljZS4NCj4+Pi0gSGVuY2UsIEFOQ1AgaXMgbm90IG5lZWRlZCBmb3IgcmVwb3J0 aW5nIGFzIElHTVAgaXRzZWxmIGhhcyANCj4+PnRoZSByaWdodCBtb2RlcyB0byBoZWxwIHN1cHBv cnQgbXVsdGljYXN0IHJlY29yZHMgYXQgdGhlIE5BUywgDQo+Pj5pZiByZXF1aXJlZC4gDQo+Pj4N Cj4+PjMpIEwyIEZvcndhcmRpbmcNCj4+Pi0gQXMgYWxyZWFkeSBzdGF0ZWQsIHRoZSBmYXN0ZXN0 IHJlc3BvbnNlIHRvIHphcHBpbmcgcmVxdWVzdHMgDQo+Pj5pcyBieSB1dGlsaXppbmcgYSBzZXQg b2YgZHluYW1pY2FsbHkgdXBkYXRlZCBBQ0xzIHJlc2lkaW5nIGF0IA0KPj4+dGhlIEFOLCBjbG9z ZXIgdG8gdGhlIGN1c3RvbWVyLiANCj4+Pi0gSSBzaGFyZSB0aGUgY29uY2VybnMgb2YgVGhvbWFz IEhhYWcgcmVnYXJkaW5nIHBlcmZvcm1hbmNlIA0KPj4+YW5kIHRpbWluZyBpc3N1ZXMuIEl0IGlz IG9idmlvdXMgdGhhdCB0aGUgTkFTLUFOIGludGVyZmFjZSANCj4+PmFkZHMgYSBkZWxheSB0byB6 YXBwaW5nIHRpbWUgbm90IHRvIG1lbnRpb24gdGhlIGZhY3QgdGhhdCBOQVMgDQo+Pj53aWxsIG5l ZWQgdG8gaGFuZGxlIG1hbnkgbW9yZSBjb25jdXJyZW50IElHTVAgcmVxdWVzdHMgdG8gYmUgDQo+ Pj50cmVhdGVkIGluIHJlYWwtdGltZS4gSWYgcGVyZm9ybWVkIGF0IHRoZSBBTiB0aGUgSUdNUCAN Cj4+PmpvaW4vbGVhdmUgcmVxdWVzdHMgbG9hZCBpcyBkaXN0cmlidXRlZCBiZXR3ZWVuIGFsbCBB TnMuDQo+Pj4tIEZpbmFsbHksIGZyb20gYSBzZXJ2aWNlIHJlbGlhYmlsaXR5IHBvaW50LW9mLXZp ZXcsIHdoZW4gdGhlIA0KPj4+QU5DUCBpcyBub3QgYXZhaWxhYmxlIGZvciBhbnkgcmVhc29uIHRo ZSBBTiBjYW4gc3RpbGwgdXNlIHRoZSANCj4+Pm1vc3QgdXBkYXRlZCBBQ0xzIGl0IGhhcyBhbmQg dGhlIHNlcnZpY2UgaXMgdW5hZmZlY3RlZC4NCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pk1vdGkgTW9y Z2Vuc3Rlcm4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEhh YWcsIFQgW21haWx0bzpUaG9tYXMuSGFhZ0B0LXN5c3RlbXMuY29tXSANCj4+PlNlbnQ6IFdlZG5l c2RheSwgTWFyY2ggMTQsIDIwMDcgNTo0NSBQTQ0KPj4+VG86IGFuY3BAaWV0Zi5vcmcNCj4+PkNj OiBCdXNzZXIsIE0NCj4+PlN1YmplY3Q6IEFXOiBbQU5DUF0gTXVsdGljYXN0IGluIEFOQ1ANCj4+ Pg0KPj4+SGkgYWxsLA0KPj4+DQo+Pj5UaGFua3MgZm9yIHBvaW50aW5nIG91dCBzZXZlcmFsIG9w dGlvbnMgZGVhbGluZyB3aXRoIEFOQ1AgYW5kIA0KPj4+TXVsdGljYXN0Lg0KPj4+DQo+Pj5Tb21l IHBvaW50cyBhcmUgaW50ZXJlc3RpbmcgcmFpc2luZyBuZXcgcmVxdWlyZW1lbnRzLCBzb21lIA0K Pj4+cG9pbnRzIGJyaW5naW5nIHVwIG5ldyBjb25jZXJucyByZWdhcmRpbmcgaW50ZXJvcGVyYWJp bGl0eSANCj4+PkFOL05BUywgZXh0ZW5kaW5nIHRoZSBleGlzdGluZyBjaGFydGVyIGJ5IGludHJv ZHVjaW5nIG5ldyANCj4+PnJlcXVpcmVtZW50cyB3aGljaCBtYXkgaGF2ZSBpbXBhY3QgdG8gYWxy ZWFkeSBleGlzdGluZyANCj4+PnJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2VzLiBBTkNQIGNhbiBk byBtYW55IHRoaW5ncyBidXQgdGhlIA0KPj4+b3BlcmF0aW9uYWwgaW1wYWN0IGFzIHdlbGwgYXMg aW1wYWN0IG9uIGludGVyYWN0aW9uIGJldHdlZW4gDQo+Pj5OQVMgYW5kIEFOIHdoaWNoIGlzIG91 dCBvZiBzY29wZSBvZiBhIHByb3RvY29sIHNwZWNpZmljYXRpb24gDQo+Pj5idXQgbmVlZHMgdG8g YmUgdGFrZW4gaW50byBhY2NvdW50IHRvby4NCj4+Pg0KPj4+QmVsb3cgSSB0cmllZCB0byBzdW1t YXJpemUgaXQgc3RlcCBieSBzdGVwOg0KPj4+DQo+Pj4xLglJIHN1cHBvcnQgb3B0aW9uIDEgZW5h YmxpbmcgTUMgcGVyIEFOIHBvcnQgYnkgDQo+Pj5jb25maWd1cmluZyBlbnRpdGxlbWVudCAJZGF0 YSBvZiBhbiBBTiBpbiBvcmRlciBjb250cm9sIA0KPj4+QUNMIGluIGNvbmp1bmN0aW9uIHdpdGgg c2Vzc2lvbiAJc3RhcnQvc3RvcC4gSSBhbHNvIA0KPj4+c3VwcG9ydCB0aGUgaWRlYSB0byBjb25z aWRlciBQUFBvRSBhcyB3ZWxsIGFzIAlESENQLg0KPj4+DQo+Pj4yLglJIHN1cHBvcnQgYWxzbyB1 c2luZyB0aGUgT0FNIGZlYXR1cmUgYXMgaXQgaXMgZGVzY3JpYmVkIA0KPj4+bm93IGJ5IHVzaW5n IAlBTkNQIGFzIHRyaWdnZXIgYW4gcmVwb3J0IGZ1bmN0aW9uIGJldHdlZW4gQU4gDQo+Pj5hbmQg TkFTIHRvIGVuYWJsZSAJT0FNIAlmYXVsdCBtYW5hZ2VtZW50IGJldHdlZW4gQU4gYW5kIA0KPj4+ Q1BFIGF0ICBEU0wgbGluZSBzdWNoIGFzIGUuZy4gQVRNIAlGNSBMQiBQb3J0IFN0YXR1cyANCj4+ Pm1lc3NhZ2Ugb3IgZXF1aXZhbGVudCBFdGhlcm5ldCBmZWF0dXJlLiBUaGVzZSAJZnVuY3Rpb25z IGFyZSANCj4+PnN0aWxsIHVzZWQgaW4gYSBwb2ludCB0byBwb2ludCBtYW5uZXIgY2hlY2tpbmcg YSAJY29ubmVjdGlvbi4NCj4+Pg0KPj4+CUkgaGF2ZSBzb21lIGNvbmNlcm5zIGFuZCBkb24ndCBz dXBwb3J0IHRoZSBpZGVhIHRvIG1peCANCj4+PnRoZSBzZW5zZSBvZiAJdGhlc2UgT0FNIGZlYXR1 cmVzIHdpdGggTXVsdGljYXN0IE9BTSB3aGljaCBpcyANCj4+PnRvdGFsIGRpZmZlcmVudC4gDQo+ Pj4JVGhlIGRpZmZlcmVuY2UgaXMgaGVyZSB0byBwb2xsIGEgc3RhdGUgb2YgYSBNdWx0aWNhc3Qg DQo+Pj5Qb2ludCB3aGljaCBpcyAJbm90IGFueSBtb3JlIGFuIE9BTSBmZWF0dXJlIGVuYWJsaW5n IA0KPj4+bGluZSB0ZXN0aW5nIHRvd2FyZHMgdGhlIERTTCBDUEUuIAlUaGlzIGlzIGEgZnVuY3Rp b24gDQo+Pj53aGljaCBuZWVkcyBzdGF0ZSBhd2FyZW5lc3Mgd2hpY2ggaXMgYSBuZXcgZmllbGQg CXdoaWNoIA0KPj4+aXMgbm90IGNvbnNpZGVyZWQgc28gZmFyIGFuZCBoYXMgc29tZSBkcmF3YmFj a3MgdG8gYWxyZWFkeSAJDQo+Pj5leGlzdGluZyB1c2UgY2FzZXMuIA0KPj4+DQo+Pj4JU28gZnJv bSBteSBwb2ludCBvZiB2aWV3IGl0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgYnV0IA0KPj4+Z29l cyBiZXlvbmQgdGhlIAljaGFydGVyIGFuZCB0aGUgdXNlIGNhc2UgTXVsdGljYXN0IGl0c2VsZi4N Cj4+Pg0KPj4+My4JVXNpbmcgQU5DUCBpbiBhIHdheSB0byBjb250cm9sIE11bHRpY2FzdCBwZXIg bXVsdGljYXN0IA0KPj4+Z3JvdXAgc2VlbXMgCWZyb20gYSBmbGV4aWJsZSBzZXJ2aWNlIGRlbGl2 ZXJ5IHN0YW5kcG9pbnQgYXMgDQo+Pj5hbiBvcHRpb24uDQo+Pj4JQnV0IGNvbnNpZGVyaW5nIHRo ZSBpbXBhY3Qgd2hpY2ggdGhlIGR5bmFtaWMgDQo+Pj5pbnRlcmFjdGlvbiBiZXR3ZWVuIEFOIAlh bmQgTkFTIHdpbGwgYnJpbmcgSSBoYXZlIA0KPj4+c3Ryb25nIGNvbmNlcm5zIHJlZ2FyZGluZyBw ZXJmb3JtYW5jZSBhbmQgCXRpbWluZyBpc3N1ZXMgDQo+Pj53aXRoIHJlc3BlY3QgdG8gY2hhbm5l bCBjaGFuZ2UgdGltZSBpZiBjdXN0b21lciBpcyAJDQo+Pj56YXBwaW5nLiBBbHNvIGluIGNhc2Ug b2YgZmFpbHVyZSB0aGlzIHNjZW5hcmlvIG1haW50ZW5hbmNlIGNhbiANCj4+Pm5vdCAJcGVyZm9y bWVkIHN1Y2Nlc3NmdWxseS4gDQo+Pj4NCj4+PglUYWtpbmcgdGhpcyBpbnRvIGFjY291bnQgSSBk b24ndCBzdXBwb3J0IG9wdGlvbiAzIHdoaWNoIA0KPj4+ZGVzY3JpYmVzIAljb25maWd1cmF0aW9u IG9mIHRoZSBMMiByZXBsaWNhdGlvbiBzdGF0ZSANCj4+PndpdGhvdXQgSUdNUCBwcm9jZXNzaW5n IGZvciAJc29tZSBkZWRpY2F0ZWQgcG9ydHMuDQo+Pj4NCj4+PlJlZ2FyZHMNCj4+Pg0KPj4+VGhv bWFzIEhhYWcNCj4+Pg0KPj4+DQo+Pj4tLS0tLVVyc3By/G5nbGljaGUgTmFjaHJpY2h0LS0tLS0N Cj4+PlZvbjogV29qY2llY2ggRGVjICh3ZGVjKSBbbWFpbHRvOndkZWNAY2lzY28uY29tXSANCj4+ Pkdlc2VuZGV0OiBNb250YWcsIDEyLiBN5HJ6IDIwMDcgMTc6MTQNCj4+PkFuOiBNYXR0aGV3LkJv Y2NpQGFsY2F0ZWwtbHVjZW50LmNvLnVrOyBhbmNwQGlldGYub3JnDQo+Pj5CZXRyZWZmOiBSRTog W0FOQ1BdIE11bHRpY2FzdCBpbiBBTkNQDQo+Pj4NCj4+PkhpIEFsbCwNCj4+Pg0KPj4+KGNoYWly IGhhdCBvZmYpDQo+Pj4NCj4+PkkgcHJvcG9zZSB0aGF0IHRoZSBBTkNQIG11bHRpY2FzdCByZXF1 aXJlbWVudHMgc2hvdWxkIGNvdmVyIHRoZQ0KPj4+Zm9sbG93aW5nIDMgYXJlYXM6DQo+Pj4NCj4+ PjEuIER5bmFtaWMgY29uZmlndXJhdGlvbg0KPj4+VGhlcmUgYXBwZWFycyB0byBiZSBhIG5lZWQg dG8gYmUgYWJsZSB0byBjb250cm9sIHRoZSBtdWx0aWNhc3QNCj4+PnJlcGxpY2F0aW9uIGF0IHRo ZSBhY2Nlc3Mtbm9kZSBpbiBhY2NvcmRhbmNlIHdpdGggcGVyIHVzZXIgb3IgcGVyDQo+Pj5jaXJj dWl0LWlkIHBvbGljaWVzIGtub3duIGF0IHRoZSBjb250cm9sbGVyLCBhbmQgZG8gc28gaW4gYSAN Cj4+PmR5bmFtaWMgdnMgYQ0KPj4+b25lIHRpbWUgcHJvdmlzaW9uZWQgbWFubmVyLiBDdXJyZW50 bHkgb3BlcmF0b3JzIGRvIHNvIGJ5IHN0YXRpY2FsbHkNCj4+PmNvbmZpZ3VyaW5nIGFuIGluZ3Jl c3MgSUdNUCBmaWx0ZXJpbmcgQUNMIG9uIGEgZ2l2ZW4gY2lyY3VpdC1pZCwgd2hpY2gNCj4+Pmlz IG5vdCBhbWVuYWJsZSB0byBkeW5hbWljIGNoYW5nZXMuIEJ5IGR5bmFtaWMgY2hhbmdlcyBpdCdz IG1lYW50IHRoYXQNCj4+PnRoZXkgYXJlIG9uZXMgdGhhdCBhcmUgcXVpY2tseSBleGVjdXRlZCBp biByZXNwb25zZSB0byBvdGhlciBzeXN0ZW0NCj4+PmV2ZW50cywgZWcgYSBzdWJzY3JpYmVyIHNl c3Npb24gY29taW5nIHVwL2Rvd24sIHRoZSBleHBpcmF0aW9uIG9mIGENCj4+PnF1b3RhIG9yIHRp bWVyLCBvciBhIHBvbGljeSB0cmlnZ2VyLCBvciBldmVuIG9wZXJhdG9yIGNvbW1hbmQuIA0KPj4+ QU5DUCB3b3VsZCBuZWVkIHRvIGJlIGFibGUgdG8gaW5zdGFsbCBzdWNoIEFDTHMgdGhyb3VnaCBh biBlZmZpY2llbnQNCj4+PnRyYW5zYWN0aW9uIG1lY2hhbmlzbS4gVHdvIGZvcm1zIG9mIGluc3Rh bGxhdGlvbiBhcHBlYXIgdG8gYmUgDQo+Pj53b3J0aHdoaWxlDQo+Pj5vZiBjb25zaWRlcmF0aW9u OiANCj4+PmkpIG92ZXJ3cml0ZSAtIGEgY29tcGxldGUgQUNMIGlzIGFwcGxpZWQgaW4gYSB0cmFu c2FjdGlvbiBvbiBhIHRhcmdldA0KPj4+Y2lyY3VpdC1pZA0KPj4+aWkpIGFkZC9yZW1vdmUgLSBv bmUgb3IgbW9yZSBlbnRyaWVzIGFyZSBhZGRlZC9yZW1vdmVkIGluIGEgdHJhbnNhY3Rpb24NCj4+ Pm9uIGEgdGFyZ2V0IGNpcmN1aXQtaWQuDQo+Pj4NCj4+PjIuIFJlcG9ydGluZw0KPj4+U2V2ZXJh bCBzZXJ2aWNlIHByb3ZpZGVycyBjdXJyZW50bHkgcnVuIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMg DQo+Pj50aGF0IHJlbHkNCj4+Pm9uIGFuIG9wZXJhdG9yIGJlaW5nIGFibGUgdG8gaXNzdWUvdHJv dWJsZXNob290IGEgc3Vic2NyaWJlcidzIHByb2JsZW1zDQo+Pg0KPj4+ZnJvbSBhIEJORy4gQ2xh c3NpYyBleGFtcGxlcyBvZiB0aGVzZSBhcmUgQVRNIE9BTSwgYW5kIGlwIHBpbmcgdGVzdHMsDQo+ Pg0KPj4NCj4+PndpdGggdGhlIEFOQ1AgT0FNICJ1c2UtY2FzZSIgYmVpbmcgYW4gZXh0ZW5zaW9u IHRoZXJlIG9mLiBJdCBhcHBlYXJzIHRvDQo+Pj5iZSBxdWl0ZSBsYWJvcmlvdXMsIGFuZCBvZnRl biBwcm9ibGVtYXRpYyBkdWUgdG8gdGhlIGNyb3NzaW5nIG9mDQo+Pj5vcmdhbml6YXRpb25hbCBi b3VuZGFyaWVzLCB0byBoYXZlIHRoZSBwcm9jZWR1cmUgcGVyZm9ybWVkIGF0IHRoZQ0KPj4+YWNj ZXNzLW5vZGUuIFRyb3VibGVzaG9vdGluZyBvZiBtdWx0aWNhc3QgZGVsaXZlcnkgaXMgYXMgeWV0 IGEgYml0IG9mIGENCj4+PmJsYWNrIGFydCB0byBtYW55IHByb3ZpZGVycyB0aGF0IGFyZSBvbmx5 IGJlZ2dpbmcgdG8gZGVwbG95IA0KPj4+YWNjZXNzLW5vZGVzDQo+Pj5jYXBhYmxlIG9mIEwyIG11 bHRpY2FzdCByZXBsaWNhdGlvbi4NCj4+Pkl0IHdvdWxkIHRodXMgYXBwZWFyIHRvIGJlIGRlc2ly YWJsZSwgaW4gb3JkZXIgdG8gYWlkIA0KPj4+b3BlcmF0aW9ucyBpbiBzdWNoDQo+Pj5kZXBsb3lt ZW50cywgdG8gaW50cm9kdWNlIGludG8gQU5DUCBhIHNldCBvZiBtdWx0aWNhc3QgcmVwb3J0aW5n DQo+Pj5jb21tYW5kcywgdGhhdCB3b3VsZCBhbGxvdyBhIEJORyBvcGVyYXRvciB0byBnYWluIGtu b3dsZWRnZSBvZiB0aGUgcGVyDQo+Pj5jaXJjdWl0LWlkIG11bHRpY2FzdCByZXBsaWNhdGlvbiBz dGF0ZSBvbiB0aGUgYWNjZXNzLW5vZGUuIA0KPj4+VGhpcyB3b3VsZCBiZQ0KPj4+YSBzaW1wbGUg cXVlcnkvcmVzcG9uc2UgbWVjaGFuaXNtLCBjb21tdW5pY2F0aW5nIGZyb20gdGhlIA0KPj4+YWNj ZXNzLW5vZGUgdG8NCj4+PnRoZSBCTkcgdGhlIGN1cnJlbnRseSBhY3RpdmUgbXVsdGljYXN0IGdy b3VwcyBvbiBhIGdpdmVuIHRhcmdldA0KPj4+KGNpcmN1aXQtaWQpIGFsb25nIHdpdGggYXBwbGlj YWJsZSBjb3VudGVycyAoZWcgdGltZS9ieXRlIGNvdW50KS4NCj4+Pg0KPj4+My4gQ2hhbmdlIG9m IEwyIGZvcndhcmRpbmcNCj4+PlRoZSBjdXJyZW50IG5vdGlvbnMgb2YgbXVsdGljYXN0IHJlcGxp Y2F0aW9uIG9uIGEgTDIgZWxlbWVudCANCj4+PmFyZSBsaW1pdGVkDQo+Pj50byB0aGUgZm9sbG93 aW5nIHR3byBvcHRpb25zOiBmbG9vZCBhbGwgbXVsdGljYXN0IHdpdGggSUdNUCBzbm9vcGluZw0K Pj4+ZGlzYWJsZWQsIG9yIHNub29wIElHTVAgYW5kIGltbWVkaWF0ZWx5IHJlcGxpY2F0ZS9zdG9w LXJlcGxpY2F0aW5nDQo+Pj5tdWx0aWNhc3QuDQo+Pj5JdCBhcHBlYXJzIHNlbnNpYmxlIHRvIGNv bnNpZGVyIGludHJvZHVjaW5nIGEgdGhpcmQgbm90aW9uIA0KPj4+dGhhdCBpbnZvbHZlcw0KPj4+ QU5DUCwgYW5kIHByb3ZpZGVzIGEgbW9yZSBncmFudWxhciBwZXIgbXVsdGljYXN0IGdyb3VwIGNv bnRyb2wgYXBwcm9hY2gNCj4+Pmluc3RlYWQgb2YgdGhlIGFsbCBvciBub3RoaW5nIG9wdGlvbnMg YWJvdmUuIFRoaXMgd291bGQgDQo+Pj5jb25zaXN0IGhhdmluZyBhDQo+Pj5saXN0IG9mIHNwZWNp ZmljIGdyb3VwcyBmb3Igd2hpY2ggdGhlIGFjY2VzcyBub2RlIHdvdWxkIG5vdCBmbG9vZCB0aGUN Cj4+Pm11bHRpY2FzdCB0cmFmZmljIHRvIGEgcG9ydCwgYnV0IG5laXRoZXIgd291bGQgaXQgZG8g SUdNUCBzbm9vcGluZywNCj4+PnJhdGhlciBpdCB3b3VsZCBwYXNzIElHTVAgdHJhbnNwYXJlbnRs eSBhbmQgY29tbWVuY2Ugb3Igc3RvcCANCj4+PnJlcGxpY2F0aW9uDQo+Pj53aGVuIGluc3RydWN0 ZWQgdmlhIEFOQ1AuIA0KPj4+VmFyaW91cyBvcHRpbWl6YXRpb25zIGNhbiBiZSBpbnRyb2R1Y2Vk IHRvIHRoaXMgc2NoZW1lLCBidXQgdGhlDQo+Pj5wcmluY2lwbGUgcmVtYWlucyB0aGUgc2FtZTsg dGhlIEwyIG11bHRpY2FzdCByZXBsaWNhdGlvbiBtZWNoYW5pc20sIGZvcg0KPj4+YSBnaXZlbiBn cm91cCBvciByYW5nZSwgd291bGQgYmUgZHJpdmVuIGJ5IEFOQ1Agc2lnbmFsbGluZy4NCj4+PkRl cGVuZGluZyBvbiB0aGUgZGVwbG95bWVudCBzY2VuYXJpbywgdGhpcyB3b3VsZCBhcHBlYXIgdG8g YmUgYSBnb29kDQo+Pj50b29sIHRvIHV0aWxpemUgd2hlbiBtdWx0aWNhc3QgYXV0aG9yaXphdGlv biwgYWNjb3VudGluZywgb3INCj4+PmFzeW5jaHJvbm91cyBvcGVyYXRvciByZXF1ZXN0cyBhZmZl Y3RpbmcgbXVsdGljYXN0IGZvcndhcmRpbmcgYXJlDQo+Pj5kZXNpcmVkLg0KPj4+DQo+Pj5SZWdh cmRzLA0KPj4+V29qLg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj5Gcm9tOiBNYXR0aGV3LkJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvLnVrDQo+Pj5bbWFpbHRvOk1h dHRoZXcuQm9jY2lAYWxjYXRlbC1sdWNlbnQuY28udWtdIA0KPj4+U2VudDogMDYgTWFyY2ggMjAw NyAxNDo0OQ0KPj4+VG86IGFuY3BAaWV0Zi5vcmcNCj4+PlN1YmplY3Q6IFtBTkNQXSBNdWx0aWNh c3QgaW4gQU5DUA0KPj4+DQo+Pj5JIHdvdWxkIGxpa2UgdG8gc3RhcnQgYSBkaXNjdXNzaW9uIG9u IHdoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd291bGQgbGlrZQ0KPj4+dG8gZG8gd2l0aCBNdWx0aWNh c3QgaW4gQU5DUC4NCj4+Pg0KPj4+Q3VycmVudGx5IHRoZSBBTkNQIGNoYXJ0ZXIgaW5jbHVkZXMg bXVsdGljYXN0IGFzIG9uZSBvZiB0aGUgdXNlIGNhc2VzLA0KPj4+YXMNCj4+PmZvbGxvd3M6DQo+ Pj4NCj4+PiJXaGVuIG11bHRpY2FzdCByZXBsaWNhdGlvbiBmb3Igc3Vic2NyaWJlci1ib3VuZCB0 cmFmZmljIGlzIA0KPj4+cGVyZm9ybWVkIGF0DQo+Pj50aGUgQU4sIGl0IG9mZi1sb2FkcyB0aGUg bmV0d29yayBiZXR3ZWVuIHRoZSBBTiBhbmQgTkFTLiBIb3dldmVyLCBhDQo+Pj5zdWJzY3JpYmVy J3MgcG9saWN5IGFuZCBjb25maWd1cmF0aW9uIGZvciBtdWx0aWNhc3QgdHJhZmZpYyBtYXkgb25s eSBiZQ0KPj4+a25vd24gYXQgdGhlIE5BUy4gQU5DUCB3aWxsIHByb3ZpZGUgYSBtZWNoYW5pc20g dG8gY29tbXVuaWNhdGUgdGhlDQo+Pj5uZWNlc3NhcnkgaW5mb3JtYXRpb24gZXhjaGFuZ2UgYmV0 d2VlbiB0aGUgQU4gYW5kIE5BUyBzbyBhcyB0byANCj4+PmFsbG93IHRoZQ0KPj4+QU4gdG8gcGVy Zm9ybSBzdWJzY3JpYmVyIGJvdW5kIG11bHRpY2FzdCBncm91cCByZXBsaWNhdGlvbiBpbiBsaW5l IHdpdGgNCj4+PnRoZSBzdWJzY3JpYmVyJ3MgcG9saWN5IGFuZCBjb25maWd1cmF0aW9uLCBhbmQg YWxzbyBhbGxvdyB0aGUgTkFTIHRvDQo+Pj5mb2xsb3cgZWFjaCBzdWJzY3JpYmVyJ3MgbXVsdGlj YXN0IGdyb3VwIG1lbWJlcnNoaXAuIg0KPj4+DQo+Pj5UaGUgZnJhbWV3b3JrIGRyYWZ0IChkcmFm dC1pZXRmLWFuY3AtZnJhbWV3b3JrLTAxLnR4dCkgc2F5cyB0aGF0IHRoZQ0KPj4+YWNjZXNzIGxv b3AgY29uZmlndXJhdGlvbiBtZWNoYW5pc21zIG1heSBiZSB1c2VmdWwgZm9yIHNldHRpbmcgdGhl DQo+Pj5wZXItU3Vic2NyaWJlciBtdWx0aWNhc3QgY2hhbm5lbCBlbnRpdGxlbWVudCBpbmZvcm1h dGlvbiwgdXNlZCBmb3IgSVBUVg0KPj4+YXBwbGljYXRpb25zIHdoZXJlIHRoZSBBY2Nlc3MgTm9k ZSBpcyBwZXJmb3JtaW5nIElHTVAgc25vb3Bpbmcgb3IgSUdNUA0KPj4+cHJveHkgZnVuY3Rpb24u IEl0IGdvZXMgb24gdG8gc2F5IHRoYXQgYSBTdWJzY3JpYmVyJ3MgcG9saWN5IGFuZA0KPj4+Y29u ZmlndXJhdGlvbiBmb3IgbXVsdGljYXN0IHRyYWZmaWMgbWlnaHQgb25seSBiZSBrbm93biBhdCB0 aGUgTkFTLiBUaGUNCj4+PkFjY2VzcyBOb2RlIENvbnRyb2wgTWVjaGFuaXNtIGNvdWxkIGJlIHVz ZWQgdG8gZXhjaGFuZ2UgdGhlIG5lY2Vzc2FyeQ0KPj4+aW5mb3JtYXRpb24gYmV0d2VlbiB0aGUg QWNjZXNzIE5vZGUgYW5kIHRoZSBOQVMgc28gYXMgdG8gYWxsb3cgdGhlDQo+Pj5BY2Nlc3MgTm9k ZSB0byBwZXJmb3JtIG11bHRpY2FzdCByZXBsaWNhdGlvbiBpbiBsaW5lIHdpdGggIHRoZQ0KPj4+ U3Vic2NyaWJlcidzIHBvbGljeSBhbmQgY29uZmlndXJhdGlvbiwgYW5kIGFsc28gYWxsb3cgdGhl IE5BUyB0byBmb2xsb3cNCj4+PmVhY2ggU3Vic2NyaWJlcidzIG11bHRpY2FzdCBncm91cCBtZW1i ZXJzaGlwLg0KPj4+DQo+Pj4NCj4+Pk5vbmUgb2YgdGhlc2UgbXVsdGljYXN0IG1lY2hhbmlzbXMg YXJlIGRlZmluZWQgaW4gdGhlIEFOQ1AgcHJvdG9jb2wNCj4+PmRyYWZ0LCBhbmQgSSB0aGluayB0 aGVyZSBpcyBpbnN1ZmZpY2llbnQgZGV0YWlsIGluIHRoZSBmcmFtZXdvcmsgZHJhZnQNCj4+PnRv IGZ1bGx5IHNwZWNpZnkgdGhpcyB1c2UgY2FzZS4NCj4+Pg0KPj4+VGhlcmUgaGFzIGJlZW4gdmVy eSBsaXR0bGUgd29yayBvbiB0aGlzIHNpbmNlIHRoZSBjaGFydGVyIGRpc2N1c3Npb25zLA0KPj4+ YnV0IHRoZSBBTkNQIHdvcmtpbmcgZ3JvdXAgbmVlZHMgdG8gY2xhcmlmeSB3aGF0IGl0IHdhbnRz IHRvIGRvIChpZg0KPj4+YW55dGhpbmcpIHdpdGggbXVsdGljYXN0IGZvciB0aGUgZnJhbWV3b3Jr IGNhbiBtb3ZlIGZvcndhcmQuIEkgdGhpbmsNCj4+PnRoZXJlIGFyZSB0d28NCj4+PmNob2ljZXM6 IEVpdGhlciB3ZSBzaG91bGQgY2xhcmlmeSB0aGUgdXNlIGNhc2UgYW5kIHNwZWNpZnkgdGhlIEFO Q1ANCj4+PnByb3RvY29sIHRvIHN1cHBvcnQgaXQsIG9yIHdlIHNob3VsZCByZW1vdmUgdGhlIG11 bHRpY2FzdCB1c2UgY2FzZSBmcm9tDQo+Pj50aGUgZnJhbWV3b3JrIGZvciBub3cuDQo+Pj4NCj4+ PlBsZWFzZSBwb3N0IHlvdXIgb3BpbmlvbnMgdG8gdGhlIGxpc3QuIFdlIHBsYW4gdG8gaGF2ZSBh IGRpc2N1c3Npb24gb24NCj4+PnRoaXMgaW4gUHJhZ3VlLCBhbmQgdG8gdHJ5IHRvIHJlYWNoIGEg Y29uc2Vuc3VzIGF0IGFyb3VuZCB0aGF0IHRpbWUuDQo+Pj4NCj4+PkJlc3QgcmVnYXJkcywNCj4+ Pg0KPj4+TWF0dGhldw0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+ Pg0KPj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+QU5DUCBtYWlsaW5nIGxpc3QNCj4+PkFOQ1BAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuY3ANCj4+Pg0KPj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PkFOQ1AgbWFpbGluZyBsaXN0DQo+ Pj5BTkNQQGlldGYub3JnDQo+Pj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hbmNwDQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj5BTkNQIG1haWxpbmcgbGlzdA0KPj4+QU5DUEBpZXRmLm9yZw0KPj4+aHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcA0KPj4+DQo+Pj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+QU5DUCBtYWlsaW5nIGxp c3QNCj4+PkFOQ1BAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuY3ANCj4+Pg0KPj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PkFOQ1AgbWFpbGluZyBsaXN0DQo+PkFOQ1BAaWV0Zi5vcmcN Cj4+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcA0KPiANCj4gDQo= --===============1468347141== 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 --===============1468347141==-- From ancp-bounces@ietf.org Fri Mar 16 21:49:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSO2G-0005yW-RB; Fri, 16 Mar 2007 21:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSO2F-0005wp-GV for ancp@ietf.org; Fri, 16 Mar 2007 21:48:43 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSO2C-0000iN-JY for ancp@ietf.org; Fri, 16 Mar 2007 21:48:43 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 16 Mar 2007 18:48:40 -0700 X-IronPort-AV: i="4.14,293,1170662400"; d="scan'208"; a="691649027:sNHT64401692" 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] Multicast in ANCP Date: Fri, 16 Mar 2007 21:48:37 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2807C6A4BA@proton.jnpr.net> In-Reply-To: <45FAA1C7.5080509@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdn0s4KNWtgZDSoTg60mwqNEjXKMQAXHBKQ From: "Sanjay Wadhwa" To: X-Spam-Score: 2.3 (++) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd 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 like the current OAM in the draft because it can indicate whether the = >problem has to be further investigated on the AN/DSLAM or not, but can=20 >the same be achieved for multicast in a simply way such that the=20 >protocol does get "overspecified" with all kinds of counters and other=20 >information? =20 Stefaan, I believe in case of multicast too, we can do enough to isolate = a problem to AN, which then possibly serves as a trigger for further = investigation on the AN (just like current OAM use-case in the draft). AN can have smarts to look at it's raw stats or any local conditions and = condense these into relevant notification back to the NAS when triggered = OR where it makes sense, it can report raw stats (e.g. incoming/outgoing = multicast packets/bytes, ). We can figure this = out better if don't summarily dismiss this use-case. Regards -Sanjay -----Original Message----- From: stefaan.de_cnodder@alcatel-lucent.be = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Friday, March 16, 2007 9:55 AM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: Re: [ANCP] Multicast in ANCP Sanjay, see inline... Sanjay Wadhwa wrote: > Stefaan > Remote troubleshooting from NAS for basic fault isolation seems = useful to me in case of multicast too. definitely troubleshooting is important, but the question is whether=20 troubleshooting from the NAS via ANCP is the right way of doing this. I like the current OAM in the draft because it can indicate whether the=20 problem has to be further investigated on the AN/DSLAM or not, but can=20 the same be achieved for multicast in a simply way such that the=20 protocol does get "overspecified" with all kinds of counters and other=20 information? If yes, very good for me in that case but with exporting=20 only some basic information, I am not sure that a big problem is solved=20 which is worth having additional functionality in ANCP. I am not sure why it is very hard (as you say) to get visibility via=20 ANCP into some basic multicast data counters basic counters are not difficult, see my email below. Which information = looks sufficient to you that can be retrieved in such a request/response = mechanism? Are the multicast entries on a particular line be = sufficient? regards, Stefaan for a port, which an AN would normally maintain. And same with MAC=20 level multicast entries. As currently defined ANCP OAM allows returning=20 more than just state. >=20 > Regards > -Sanjay >=20 > -----Original Message----- > From: stefaan.de_cnodder@alcatel-lucent.be = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: Friday, March 16, 2007 7:23 AM > To: Sanjay Wadhwa > Cc: ancp@ietf.org > Subject: Re: [ANCP] Multicast in ANCP >=20 >=20 > Sanjay, >=20 > It looks you are proposing new functionality in ANCP for more detailed = > troubleshooting in the AN from the NAS, but then the question is where = > it stops, and it looks to me that such a detailed troubleshooting = should=20 > be better done at the AN itself. Look to the current OAM: there is = just=20 > some indication of the state of the DSL line and nothing more and the=20 > detailed troubleshooting (spectrum analyis, ...) is to be done on the = AN=20 > itself. In fact, for multicast, I have done lots of troubleshooting = in=20 > live networks and whatever you do in ANCP, the most important=20 > functionality such as protocol tracing, detailed error counters, ...=20 > will be very hard to support in ANCP. The proposed extension by Woj = on=20 > getting visibility on the multicast forwarding table in the AN, will = not=20 > help a lot in futher isolating the problem. If the entry is there or=20 > not, then the problem can be still anywhere in the network and up to = the=20 > application layer. And if the problem is in the AN (a bug, or = whatever)=20 > the information given in ANCP could be faulty information. >=20 > regards, > Stefaan >=20 > Sanjay Wadhwa wrote: >=20 >=20 >>Moti >> One of the motivation for NAS to control replication state on the AN = is to subject it to admission control (based on multiple services being = delivered to the same local-loop). The NAS needs per-subscriber IGMP = visibility to do this. Once it gets this visibilty, per-subscriber = accounting and dynamic management of QoS for the local-loop comes as a = bonus. In this case IGMP state machine is running between RG and NAS. = So, IGMP query is good enough to figure out the state on RG.=20 >>However, the last point of replication in the network is the AN. I = take use-case #2 as a means to help with troubleshooting when say an RG = is not recieving a multicast stream. In this case the operator from the = NAS can use ANCP to trigger AN to provide stats such as "dropped and = forwarded multicast packets or bytes" per local-loop (ACI) or can = trigger it to report the MAC based multicast filter entries for an = access-loop. If we implement use-case #3, then I think #2 is a = pre-requisite. I also think if we do use-case #3, then high-availability = based on "ANCP graceful restart" is a pre-requisite for both AN and NAS. = Without these two, we don't have a carrier-grade solution. >> >>Regards >>-Sanjay >> >>=20 >> >> >> >> >>>2) Reporting >>>- If IGMP snooping is being used at the AN then all accounting=20 >>>data (volume/time) may be known at the NAS. >>>- IGMP proxy is being used normally for flat-rate service. >>>- Hence, ANCP is not needed for reporting as IGMP itself has=20 >>>the right modes to help support multicast records at the NAS,=20 >>>if required.=20 >> >> >>>-----Original Message----- >>>From: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] >>>Sent: Thursday, March 15, 2007 1:16 PM >>>To: ancp@ietf.org >>>Subject: RE: [ANCP] Multicast in ANCP >>> >>> >>>Hi all, >>> >>>Having experience in managing multicast services in the AN I=20 >>>have the following thoughts regarding the 3 topics in Wojciech's = mail: >>> >>>1) Configuration >>>- NAS will (dynamically) configure the ACLs at the AN per each=20 >>>circuit-ID, based on any criteria it implements.=20 >>>- The ANCP could also be used to (dynamically) configure the=20 >>>maximum number of multicast channels and aggregate bandwidth=20 >>>allowed for each circuit-ID for multicast channels. >>> >>>2) Reporting >>>- If IGMP snooping is being used at the AN then all accounting=20 >>>data (volume/time) may be known at the NAS. >>>- IGMP proxy is being used normally for flat-rate service. >>>- Hence, ANCP is not needed for reporting as IGMP itself has=20 >>>the right modes to help support multicast records at the NAS,=20 >>>if required.=20 >>> >>>3) L2 Forwarding >>>- As already stated, the fastest response to zapping requests=20 >>>is by utilizing a set of dynamically updated ACLs residing at=20 >>>the AN, closer to the customer.=20 >>>- I share the concerns of Thomas Haag regarding performance=20 >>>and timing issues. It is obvious that the NAS-AN interface=20 >>>adds a delay to zapping time not to mention the fact that NAS=20 >>>will need to handle many more concurrent IGMP requests to be=20 >>>treated in real-time. If performed at the AN the IGMP=20 >>>join/leave requests load is distributed between all ANs. >>>- Finally, from a service reliability point-of-view, when the=20 >>>ANCP is not available for any reason the AN can still use the=20 >>>most updated ACLs it has and the service is unaffected. >>> >>>Regards, >>>Moti Morgenstern >>> >>>-----Original Message----- >>>From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 >>>Sent: Wednesday, March 14, 2007 5:45 PM >>>To: ancp@ietf.org >>>Cc: Busser, M >>>Subject: AW: [ANCP] Multicast in ANCP >>> >>>Hi all, >>> >>>Thanks for pointing out several options dealing with ANCP and=20 >>>Multicast. >>> >>>Some points are interesting raising new requirements, some=20 >>>points bringing up new concerns regarding interoperability=20 >>>AN/NAS, extending the existing charter by introducing new=20 >>>requirements which may have impact to already existing=20 >>>requirements and use cases. ANCP can do many things but the=20 >>>operational impact as well as impact on interaction between=20 >>>NAS and AN which is out of scope of a protocol specification=20 >>>but needs to be taken into account too. >>> >>>Below I tried to summarize it step by step: >>> >>>1. I support option 1 enabling MC per AN port by=20 >>>configuring entitlement data of an AN in order control=20 >>>ACL in conjunction with session start/stop. I also=20 >>>support the idea to consider PPPoE as well as DHCP. >>> >>>2. I support also using the OAM feature as it is described=20 >>>now by using ANCP as trigger an report function between AN=20 >>>and NAS to enable OAM fault management between AN and=20 >>>CPE at DSL line such as e.g. ATM F5 LB Port Status=20 >>>message or equivalent Ethernet feature. These functions are=20 >>>still used in a point to point manner checking a connection. >>> >>> I have some concerns and don't support the idea to mix=20 >>>the sense of these OAM features with Multicast OAM which is=20 >>>total different.=20 >>> The difference is here to poll a state of a Multicast=20 >>>Point which is not any more an OAM feature enabling=20 >>>line testing towards the DSL CPE. This is a function=20 >>>which needs state awareness which is a new field which=20 >>>is not considered so far and has some drawbacks to already =09 >>>existing use cases.=20 >>> >>> So from my point of view it needs to be considered but=20 >>>goes beyond the charter and the use case Multicast itself. >>> >>>3. Using ANCP in a way to control Multicast per multicast=20 >>>group seems from a flexible service delivery standpoint as=20 >>>an option. >>> But considering the impact which the dynamic=20 >>>interaction between AN and NAS will bring I have=20 >>>strong concerns regarding performance and timing issues=20 >>>with respect to channel change time if customer is =09 >>>zapping. Also in case of failure this scenario maintenance can=20 >>>not performed successfully.=20 >>> >>> Taking this into account I don't support option 3 which=20 >>>describes configuration of the L2 replication state=20 >>>without IGMP processing for some dedicated ports. >>> >>>Regards >>> >>>Thomas Haag >>> >>> >>>-----Urspr=FCngliche Nachricht----- >>>Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 >>>Gesendet: Montag, 12. M=E4rz 2007 17:14 >>>An: Matthew.Bocci@alcatel-lucent.co.uk; ancp@ietf.org >>>Betreff: RE: [ANCP] Multicast in ANCP >>> >>>Hi All, >>> >>>(chair hat off) >>> >>>I propose that the ANCP multicast requirements should cover the >>>following 3 areas: >>> >>>1. Dynamic configuration >>>There appears to be a need to be able to control the multicast >>>replication at the access-node in accordance with per user or per >>>circuit-id policies known at the controller, and do so in a=20 >>>dynamic vs a >>>one time provisioned manner. Currently operators do so by statically >>>configuring an ingress IGMP filtering ACL on a given circuit-id, = which >>>is not amenable to dynamic changes. By dynamic changes it's meant = that >>>they are ones that are quickly executed in response to other system >>>events, eg a subscriber session coming up/down, the expiration of a >>>quota or timer, or a policy trigger, or even operator command.=20 >>>ANCP would need to be able to install such ACLs through an efficient >>>transaction mechanism. Two forms of installation appear to be=20 >>>worthwhile >>>of consideration:=20 >>>i) overwrite - a complete ACL is applied in a transaction on a target >>>circuit-id >>>ii) add/remove - one or more entries are added/removed in a = transaction >>>on a target circuit-id. >>> >>>2. Reporting >>>Several service providers currently run operational procedures=20 >>>that rely >>>on an operator being able to issue/troubleshoot a subscriber's = problems >> >>>from a BNG. Classic examples of these are ATM OAM, and ip ping tests, >> >> >>>with the ANCP OAM "use-case" being an extension there of. It appears = to >>>be quite laborious, and often problematic due to the crossing of >>>organizational boundaries, to have the procedure performed at the >>>access-node. Troubleshooting of multicast delivery is as yet a bit of = a >>>black art to many providers that are only begging to deploy=20 >>>access-nodes >>>capable of L2 multicast replication. >>>It would thus appear to be desirable, in order to aid=20 >>>operations in such >>>deployments, to introduce into ANCP a set of multicast reporting >>>commands, that would allow a BNG operator to gain knowledge of the = per >>>circuit-id multicast replication state on the access-node.=20 >>>This would be >>>a simple query/response mechanism, communicating from the=20 >>>access-node to >>>the BNG the currently active multicast groups on a given target >>>(circuit-id) along with applicable counters (eg time/byte count). >>> >>>3. Change of L2 forwarding >>>The current notions of multicast replication on a L2 element=20 >>>are limited >>>to the following two options: flood all multicast with IGMP snooping >>>disabled, or snoop IGMP and immediately replicate/stop-replicating >>>multicast. >>>It appears sensible to consider introducing a third notion=20 >>>that involves >>>ANCP, and provides a more granular per multicast group control = approach >>>instead of the all or nothing options above. This would=20 >>>consist having a >>>list of specific groups for which the access node would not flood the >>>multicast traffic to a port, but neither would it do IGMP snooping, >>>rather it would pass IGMP transparently and commence or stop=20 >>>replication >>>when instructed via ANCP.=20 >>>Various optimizations can be introduced to this scheme, but the >>>principle remains the same; the L2 multicast replication mechanism, = for >>>a given group or range, would be driven by ANCP signalling. >>>Depending on the deployment scenario, this would appear to be a good >>>tool to utilize when multicast authorization, accounting, or >>>asynchronous operator requests affecting multicast forwarding are >>>desired. >>> >>>Regards, >>>Woj. >>> >>> >>>-----Original Message----- >>>From: Matthew.Bocci@alcatel-lucent.co.uk >>>[mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 >>>Sent: 06 March 2007 14:49 >>>To: ancp@ietf.org >>>Subject: [ANCP] Multicast in ANCP >>> >>>I would like to start a discussion on what the working group would = like >>>to do with Multicast in ANCP. >>> >>>Currently the ANCP charter includes multicast as one of the use = cases, >>>as >>>follows: >>> >>>"When multicast replication for subscriber-bound traffic is=20 >>>performed at >>>the AN, it off-loads the network between the AN and NAS. However, a >>>subscriber's policy and configuration for multicast traffic may only = be >>>known at the NAS. ANCP will provide a mechanism to communicate the >>>necessary information exchange between the AN and NAS so as to=20 >>>allow the >>>AN to perform subscriber bound multicast group replication in line = with >>>the subscriber's policy and configuration, and also allow the NAS to >>>follow each subscriber's multicast group membership." >>> >>>The framework draft (draft-ietf-ancp-framework-01.txt) says that the >>>access loop configuration mechanisms may be useful for setting the >>>per-Subscriber multicast channel entitlement information, used for = IPTV >>>applications where the Access Node is performing IGMP snooping or = IGMP >>>proxy function. It goes on to say that a Subscriber's policy and >>>configuration for multicast traffic might only be known at the NAS. = The >>>Access Node Control Mechanism could be used to exchange the necessary >>>information between the Access Node and the NAS so as to allow the >>>Access Node to perform multicast replication in line with the >>>Subscriber's policy and configuration, and also allow the NAS to = follow >>>each Subscriber's multicast group membership. >>> >>> >>>None of these multicast mechanisms are defined in the ANCP protocol >>>draft, and I think there is insufficient detail in the framework = draft >>>to fully specify this use case. >>> >>>There has been very little work on this since the charter = discussions, >>>but the ANCP working group needs to clarify what it wants to do (if >>>anything) with multicast for the framework can move forward. I think >>>there are two >>>choices: Either we should clarify the use case and specify the ANCP >>>protocol to support it, or we should remove the multicast use case = from >>>the framework for now. >>> >>>Please post your opinions to the list. We plan to have a discussion = on >>>this in Prague, and to try to reach a consensus at around that time. >>> >>>Best regards, >>> >>>Matthew >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>ANCP mailing list >>>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 >>> >> >> >>_______________________________________________ >>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 Mon Mar 19 12:22:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKcd-000856-4e; Mon, 19 Mar 2007 12:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKcb-00081h-RI for ancp@ietf.org; Mon, 19 Mar 2007 12:22:09 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKcX-0004Am-BN for ancp@ietf.org; Mon, 19 Mar 2007 12:22:09 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by iron.ecitele.com with ESMTP; 19 Mar 2007 18:23:39 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 19 Mar 2007 18:22:00 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Mar 2007 18:22:02 +0200 Message-ID: In-Reply-To: <45FAA1C7.5080509@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP MIB - Connection between Partition IDs and Session IDs Thread-index: Acdn0uRBZmCA6ky6T7uYYVJ6EbOXvACVyIgA From: "Michel Platnic" To: X-OriginalArrivalTime: 19 Mar 2007 16:22:00.0110 (UTC) FILETIME=[B89E0CE0:01C76A42] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [ANCP] ANCP MIB - Connection between Partition IDs and Session IDs 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="===============0547050916==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0547050916== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76A42.B870C5DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76A42.B870C5DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 The ANCP MIB Draft 'draft-decnodder-ancp-mib-an-01' defines that a Partition ID can be associated to several session IDs. This allows an AN to receive commands from several NAS.=20 =20 Question 1: How does the reporting from the AN to the NAS works? Shall it send the results only to the requester (NAS which sent the command) or to all NAS connected to the partition ID (depending on the session negotiated capabilities with the NAS)? =20 =20 In case several Partitions are used per AN a high number of Sessions can potentially be terminated at the NAS. Allowing to associate one Session ID to several Partitions may help reduce the number of Sessions.=20 =20 Question 2: The MIB defines that a Partition ID can be associated to several Sessions IDs, should we, in addition to this, allow one Session ID to be connected to several Partition IDs? =20 Regards, Michel. =20 ------_=_NextPart_001_01C76A42.B870C5DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
 The ANCP MIB=20 Draft 'draft-decnodder-ancp-mib-an-01' defines that a Partition ID can = be=20 associated to several session IDs. This allows an AN to receive commands = from=20 several NAS.
 
Question 1:=20 How does the reporting from the AN to the NAS works? Shall it = send the=20 results only to the requester (NAS which sent the command) or = to all=20 NAS connected to the partition ID (depending on the session negotiated=20 capabilities with the NAS)?
 
 
In = case several=20 Partitions are used per AN a high number of Sessions can = potentially=20 be terminated at the NAS. Allowing to associate one Session ID to several Partitions = may help=20 reduce the number of Sessions.
 
Question 2: The MIB defines that a = Partition=20 ID can be associated to several Sessions IDs, should we, in = addition to=20 this, allow one Session ID to be connected to several Partition=20 IDs?
 
Regards,
Michel.

 

------_=_NextPart_001_01C76A42.B870C5DB-- --===============0547050916== 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 --===============0547050916==-- From ancp-bounces@ietf.org Mon Mar 19 13:50:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM0A-0001ll-0E; Mon, 19 Mar 2007 13:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM08-0001ld-Vw for ancp@ietf.org; Mon, 19 Mar 2007 13:50:32 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTM03-00012f-1m for ancp@ietf.org; Mon, 19 Mar 2007 13:50:32 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2JHoUZM022579; Mon, 19 Mar 2007 18:50:30 +0100 Received: from [172.17.244.159] ([172.17.244.159]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007031918502191:5882 ; Mon, 19 Mar 2007 18:50:21 +0100 Message-ID: <45FECD5D.80202@alcatel-lucent.be> Date: Mon, 19 Mar 2007 18:50:21 +0100 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Platnic Subject: Re: [ANCP] ANCP MIB - Connection between Partition IDs and Session IDs References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/19/2007 18:50:22, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/19/2007 18:50:23, Serialize complete at 03/19/2007 18:50:23 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Michel, see inline... > Hi All, > > The ANCP MIB Draft 'draft-decnodder-ancp-mib-an-01' defines that a > Partition ID can be associated to several session IDs. This allows an AN > to receive commands from several NAS. > > _Question 1:_ How does the reporting from the AN to the NAS works? Shall > it send the results only to the requester (NAS which sent the command) > or to all NAS connected to the partition ID (depending on the session > negotiated capabilities with the NAS)? > That's how I understand it. The framework document says: "The Access Node SHOULD be able to work with redundant controllers." How this works is not further specified but it looks to me that in this case, one partition can have multiple ANCP sessions. When there are 2 sessions, then I would expect that they are treated independently from each other, i.e., what is send over one session is the same as if the other session was not there. Previously, "functional partitioning" was also discussed on this mailing list a while ago, and in that case, you might have a NAS per capability, and hence a session per capability. > > In case several Partitions are used per AN a high number of Sessions can > potentially be terminated at the NAS. Allowing to associate one Session > ID to several Partitions may help reduce the number of Sessions. > > _Question 2:_ The MIB defines that a Partition ID can be associated to > several Sessions IDs, should we, in addition to this, allow one Session > ID to be connected to several Partition IDs? > I am all open for it but I am not sure if there is a good case where 1 session need to control multiple partitions. In fact, partioning is a quite hard separation of the access node and I am not sure if it is good that 2 partitions are sharing the same session. Why would you make 2 partitions in this case? Would it not be better to make one partition of it? As MIB impact, I see that in the configuration instead of 1 partition ID per session we need multiple partition IDs per session, meaning another table. If there are good cases for it, it is ok for me. Note that ANCP is based on GSMP, and also the ANCP MIB is (more or less) based on the GSMP MIB, and the current ANCP MIB has taken this from the GSMP MIB. Thanks, Stefaan > Regards, > Michel. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mar 19 14:50:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMwB-0003SI-Kd; Mon, 19 Mar 2007 14:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMwA-0003Os-7j for ancp@ietf.org; Mon, 19 Mar 2007 14:50:30 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMvb-0003ZA-DY for ancp@ietf.org; Mon, 19 Mar 2007 14:50:30 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 19:49:55 +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 l2JInsGW030736; Mon, 19 Mar 2007 19:49:54 +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 l2JInilZ011412; Mon, 19 Mar 2007 18:49:54 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, 19 Mar 2007 19:49:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Mar 2007 19:49:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda change Thread-Index: AcdqV1cg5QElezF0SRygTZPCDzZ2Ww== From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 19 Mar 2007 18:49:44.0606 (UTC) FILETIME=[5C44CBE0:01C76A57] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5597; t=1174330194; x=1175194194; 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:=20Agenda=20change |Sender:=20; bh=ayoGrxxS0bSKvQTQJS7ZwwMu7kjVqxsgFQTLn2D2oss=; b=P1yDB30gbGwTBplsOrXsDvMtn2lDKN8CNXCCxpPYD+lefFp6dwpwd2NHAJ/O37d0S0IlcLnr IfA8VguWZMw3t9B/OKUaI24mB/FDDtXLZnhD++CS2ra3G8Z0YuuIYsLt; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [ANCP] Agenda change 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="===============2088371008==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2088371008== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76A57.5C08806C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76A57.5C08806C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, It appears that tomorrow's meeting will overlap with the BMWG meeting where multicast also features on the agenda. In order to accommodate those participants who would like to follow the multicast discussion in both WGs we've modified the order of our agenda to be as shown below. We've also added the TLV and protocol versioning item related to the protocol draft: TUESDAY, March 20th, 2007: 13:00 - 15:00 ------------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci 5 mins - Administrivia, WG Status and WG Docs Update - Chairs 10 mins - ANCP Framework / Requirements - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework- 01.txt 15 mins - ANCP Multicast Discussion - Chairs 15 mins - ANCP Acess Node MIBs - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an- 01.txt 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-security- threats-00.txt 15 mins - ANCP Protocol Draft - Derek Harkness (dharkness@juniper.net) http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol- 00.txt 10 mins - Protocol Draft: Versioning and TLV numbering - Chairs Regards, Woj & Matthew. =20 ------_=_NextPart_001_01C76A57.5C08806C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda change

Hello All,

It appears that tomorrow's meeting will = overlap with the BMWG meeting where multicast also features on the = agenda. In order to accommodate those participants who would like to = follow the multicast discussion in both WGs we've modified the order of = our agenda to be as shown below. We've also added the TLV and protocol = versioning item related to the protocol draft:

TUESDAY, March = 20th, 2007: 13:00 - 15:00
-------------------------------------------
CHAIRS: = Wojciech Dec & Matthew Bocci

5 mins - = Administrivia, WG Status and WG Docs Update - Chairs

10 mins - ANCP = Framework / Requirements - Stefaan de Cnodder
(stefaan.de_cnodder@alcatel-lucent.be)
http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework= -
01.txt

15 mins - ANCP Multicast = Discussion - Chairs

15 mins - ANCP Acess Node MIBs - = Stefaan de Cnodder
(stefaan.de_cnodder@alcatel-lucent.be)
= http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an-
01.txt

15 mins - ANCP Security Threats = and Requirements - Hassnaa
Moustafa = (hassnaa.moustafa@orange-ftgroup.com)
= http://www.ietf.org/internet-drafts/draft-ietf-ancp-security<= /U>-
threats-00.txt

15 mins - ANCP Protocol Draft - = Derek Harkness
(dharkness@juniper.net)
= http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol<= /U>-
00.txt

10 mins - Protocol Draft: = Versioning and TLV numbering - Chairs

Regards,
Woj & Matthew.
 

------_=_NextPart_001_01C76A57.5C08806C-- --===============2088371008== 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 --===============2088371008==-- From ancp-bounces@ietf.org Tue Mar 20 09:36:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeVS-0005YL-1A; Tue, 20 Mar 2007 09:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeVR-0005YF-45 for ancp@ietf.org; Tue, 20 Mar 2007 09:36:05 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTeV0-00034X-Ii for ancp@ietf.org; Tue, 20 Mar 2007 09:36:05 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by iron.ecitele.com with ESMTP; 20 Mar 2007 15:37:28 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Mar 2007 15:35:36 +0200 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 MIB - Connection between Partition IDs and Session IDs Date: Tue, 20 Mar 2007 15:31:50 +0200 Message-ID: In-Reply-To: <45FECD5D.80202@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP MIB - Connection between Partition IDs and Session IDs Thread-index: AcdqTxN2NhyPn58OT9mh/7pVa34gIwAnh5eA From: "Michel Platnic" To: X-OriginalArrivalTime: 20 Mar 2007 13:35:36.0971 (UTC) FILETIME=[A49DADB0:01C76AF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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, About Question 1: I also support your views regarding the overall mechanism. Tough, if we agree that each session is autonomous, I am not sure that 'functional partitioning' is a must anymore. If one NAS requests access attributes, the AN sends results only to this NAS, if later on an other NAS connected to the same partition via an other session sends the same request, it may receive, in its turn, the requested attributes. There might be some operational limitations for the configuration use-case, but details for this use-case are not defined yet so its too early to say. About Question 2: The main idea to have several partitions sharing the same session is on one hand to reduce the number of sessions and on the other hand to allow a separation between the different ISPs. Indeed, several ISPs might be connected to one NAS but could use only one single session to address the relevant partitions. Limitation: all ISPs using a single session should support a common set of capabilities. This proposal is only one of several other possible solutions to reduce the number of sessions. It adds some level of complexity to the model but seems a good comprise compared to other solutions such as an aggregation switch ANCP proxy to implement same feature for example. Regards, Michel. -----Original Message----- From: stefaan.de_cnodder@alcatel-lucent.be [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Monday, March 19, 2007 7:50 PM To: Michel Platnic Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP MIB - Connection between Partition IDs and Session IDs Hi Michel, see inline... > Hi All, > =20 > The ANCP MIB Draft 'draft-decnodder-ancp-mib-an-01' defines that a=20 > Partition ID can be associated to several session IDs. This allows an AN=20 > to receive commands from several NAS. > =20 > _Question 1:_ How does the reporting from the AN to the NAS works? Shall=20 > it send the results only to the requester (NAS which sent the command) > or to all NAS connected to the partition ID (depending on the session=20 > negotiated capabilities with the NAS)? > That's how I understand it. The framework document says: "The Access=20 Node SHOULD be able to work with redundant controllers." How this works is not further specified but it looks to me that in this case, one=20 partition can have multiple ANCP sessions. When there are 2 sessions,=20 then I would expect that they are treated independently from each other, i.e., what is send over one session is the same as if the other session=20 was not there. Previously, "functional partitioning" was also discussed on this mailing list a while ago, and in that case, you might have a NAS per capability, and hence a session per capability. > =20 > In case several Partitions are used per AN a high number of Sessions can=20 > potentially be terminated at the NAS. Allowing to associate one Session=20 > ID to several Partitions may help reduce the number of Sessions. > =20 > _Question 2:_ The MIB defines that a Partition ID can be associated to > several Sessions IDs, should we, in addition to this, allow one Session=20 > ID to be connected to several Partition IDs? > =20 I am all open for it but I am not sure if there is a good case where 1=20 session need to control multiple partitions. In fact, partioning is a=20 quite hard separation of the access node and I am not sure if it is good that 2 partitions are sharing the same session. Why would you make 2=20 partitions in this case? Would it not be better to make one partition=20 of it? As MIB impact, I see that in the configuration instead of 1 partition ID per session we need multiple partition IDs per session, meaning another=20 table. If there are good cases for it, it is ok for me. Note that ANCP is based on GSMP, and also the ANCP MIB is (more or less) based on the=20 GSMP MIB, and the current ANCP MIB has taken this from the GSMP MIB. Thanks, Stefaan > Regards, > Michel. >=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 Tue Mar 20 09:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTedy-0001EN-5Z; Tue, 20 Mar 2007 09:44:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTedw-0001Dw-EQ for ancp@ietf.org; Tue, 20 Mar 2007 09:44:52 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTedO-0007eF-LA for ancp@ietf.org; Tue, 20 Mar 2007 09:44:52 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2KDiGMS004889 for ; Tue, 20 Mar 2007 08:44:18 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:44:06 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:44: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Mar 2007 14:43:58 +0100 Message-ID: In-Reply-To: <45F7B3CD.5070806@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP MIB and Partition-ID Thread-Index: AcdmE/T2YouUQo/YQNOxQssnPj/0ZQE4S0xA References: <45F7B3CD.5070806@alcatel-lucent.be> From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 20 Mar 2007 13:44:04.0530 (UTC) FILETIME=[D3250920:01C76AF5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [ANCP] ANCP MIB and Partition-ID 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 During the ANCP session today I listened to the discussion about PartionID and the question if it is more than just a number. There was talk about that possibly they could be multiple partitions in the same device, maybe even=20 virtual partitions? That triggered me to wonder=20 - will multiple partitions on the same device be supported (repersented) by a single SNMP agent or by multiple SNMP agents? - If so, do we need to consider that the particionID becomes part of the indexing scheme, so that you implicitly support multiple instances of this MIB module The WG better thinks this through BEFORE the MIB module gets finalized, because if we find out later (afte rthe MIB document has been approved), then it can only be changed with incompatible changes (i.e. re-indexing), and so that means obsoleting most=20 (if not all) of what we define today. Bert _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Mar 21 07:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzGM-0006mw-UM; Wed, 21 Mar 2007 07:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzGL-0006kB-7B for ancp@ietf.org; Wed, 21 Mar 2007 07:45:53 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzG7-0004Z2-9v for ancp@ietf.org; Wed, 21 Mar 2007 07:45:53 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2LBjiGM009801 for ; Wed, 21 Mar 2007 12:45:44 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Wed, 21 Mar 2007 11:43:17 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/21/2007 11:45:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [ANCP] ANCP AN MIB to WG draft? 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 During the meeting in Prague, there was a request to make draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Mar 21 07:49:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJP-00014e-Tb; Wed, 21 Mar 2007 07:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJP-00014Z-9L for ancp@ietf.org; Wed, 21 Mar 2007 07:49:03 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzJ8-0005fb-6l for ancp@ietf.org; Wed, 21 Mar 2007 07:49:03 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com) ([172.31.244.40]) by iron.ecitele.com with ESMTP; 21 Mar 2007 13:50:44 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Mar 2007 13:48:40 +0200 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 AN MIB to WG draft? Date: Wed, 21 Mar 2007 13:48:40 +0200 Message-ID: <2F7C502D2CC5EF4CBA93F7F47896E197F86746@ilptex01.ecitele.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP AN MIB to WG draft? Thread-index: Acdrrp8PC5BKgvw1QsqLzr97xySpAQAACZXw References: From: "Menachem Dodge" To: , X-OriginalArrivalTime: 21 Mar 2007 11:48:40.0853 (UTC) FILETIME=[DEB98450:01C76BAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Hello Mathew, I am in support of making this draft a working group document. Best Regards, Menachem Dodge.=20 -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: Wednesday, March 21, 2007 1:43 PM To: ancp@ietf.org Subject: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ 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 Mar 21 07:57:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzR2-0001wS-R2; Wed, 21 Mar 2007 07:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzR1-0001lP-1W for ancp@ietf.org; Wed, 21 Mar 2007 07:56:55 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzQr-0007pR-5b for ancp@ietf.org; Wed, 21 Mar 2007 07:56:55 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 21 Mar 2007 12:56:41 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 12:56:16 +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] ANCP AN MIB to WG draft? Date: Wed, 21 Mar 2007 12:56:15 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2BCE62E@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP AN MIB to WG draft? Thread-Index: AcdrrpJlI5y3WzaFTg+tauN8vaG8EAAALUKg References: From: "Freudenberger, Markus" To: , X-OriginalArrivalTime: 21 Mar 2007 11:56:16.0124 (UTC) FILETIME=[EE165BC0:01C76BAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Haag, T" 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 Matthew, I support the request making this draft a working group document. Regards Markus Freudenberger=20 T-Systems Enterprise Services GmbH Systems Integration Telco Project & Design Line of Business Networks & Processes Technology Consultant Deutsche-Telekom-Allee 7, D-64295 Darmstadt +49 6151 937-3679 (Phone)=20 +49 6151 937-19875 (Fax)=20 +49 521 5224 5816 (PC-Fax)=20 E-Mail: mailto:markus.freudenberger@t-systems.com=20 Internet: http://t-systems.com T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you. T-Systems - Business flexibility =20 -----Urspr=FCngliche Nachricht----- Von: Matthew.Bocci@alcatel-lucent.co.uk = [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Gesendet: Mittwoch, 21. M=E4rz 2007 12:43 An: ancp@ietf.org Betreff: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make = draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ 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 Mar 21 08:02:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzVt-0005pY-5b; Wed, 21 Mar 2007 08:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzVs-0005l9-1s for ancp@ietf.org; Wed, 21 Mar 2007 08:01:56 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzVp-0000Jt-Tq for ancp@ietf.org; Wed, 21 Mar 2007 08:01:56 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 21 Mar 2007 13:01:51 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 13:01:26 +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] ANCP AN MIB to WG draft? Date: Wed, 21 Mar 2007 13:05:58 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED201EDF08F@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP AN MIB to WG draft? Thread-Index: AcdrrpJlI5y3WzaFTg+tauN8vaG8EAAAomcw References: From: "Haag, T" To: X-OriginalArrivalTime: 21 Mar 2007 12:01:26.0530 (UTC) FILETIME=[A71A8E20:01C76BB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ancp@ietf.org, "Freudenberger, Markus" 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 Matthew, I support the request making this draft a working group document. Regards =20 Thomas Haag =20 T-Systems Enterprise Services GmbH Systems Integration Telco Project & Design Line of Business Networks & Processes Project Manager and Consultant =20 Address: Deutsche Telekom Allee 7, 64295 Darmstadt Phone: +49 6151/937- 53 47 Fax: +49 6151/937- 30 47 E-Mail: thomas.haag@t-systems.com Internet: http://www.t-systems.com =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 -----Urspr=FCngliche Nachricht----- Von: Matthew.Bocci@alcatel-lucent.co.uk = [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Gesendet: Mittwoch, 21. M=E4rz 2007 12:43 An: ancp@ietf.org Betreff: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ 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 Mar 21 08:08:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzcP-0007jl-9r; Wed, 21 Mar 2007 08:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzcO-0007jc-0R for ancp@ietf.org; Wed, 21 Mar 2007 08:08:40 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzcM-0001sx-Ip for ancp@ietf.org; Wed, 21 Mar 2007 08:08:39 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 21 Mar 2007 13:08:37 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 13:08:12 +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] ANCP AN MIB to WG draft? Date: Wed, 21 Mar 2007 13:08:12 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2C45926@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP AN MIB to WG draft? Thread-Index: AcdrrpJlI5y3WzaFTg+tauN8vaG8EAAAv/9A From: "Busser, M" To: , X-OriginalArrivalTime: 21 Mar 2007 12:08:12.0541 (UTC) FILETIME=[991AEAD0:01C76BB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Hello Matthew, I support the request making this draft a working group document. Michael Busser T-Systems Enterprise Services GmbH Production Line Network Centric Systems ICT-Systems Integration Network Integration Services Postal address:=20 Postfach 91 00,=20 55541 Bad Kreuznach Phone +49 671 8333 8911 Fax +49 671 8333 8983 PC Fax +49 521 92103859 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you -----Urspr=FCngliche Nachricht----- Von: Matthew.Bocci@alcatel-lucent.co.uk = [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Gesendet: Mittwoch, 21. M=E4rz 2007 12:43 An: ancp@ietf.org Betreff: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make = draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ 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 Mar 21 08:33:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU00J-0005rs-69; Wed, 21 Mar 2007 08:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU00I-0005rX-37 for ancp@ietf.org; Wed, 21 Mar 2007 08:33:22 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU00A-0008VX-LX for ancp@ietf.org; Wed, 21 Mar 2007 08:33:22 -0400 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2LCXKLX001485 for ; Wed, 21 Mar 2007 13:33:20 +0100 Received: from [172.31.148.63] ([172.31.148.63]) by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007032113331265:7366 ; Wed, 21 Mar 2007 13:33:12 +0100 Message-ID: <46012610.8080700@alcatel-lucent.be> Date: Wed, 21 Mar 2007 13:33:20 +0100 From: Sven.Ooghe@alcatel-lucent.be Organization: Alcatel-Lucent User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] ANCP AN MIB to WG draft? References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/21/2007 13:33:12, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/21/2007 13:33:13, Serialize complete at 03/21/2007 13:33:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 support this document becoming a WG draft. Regards, Sven Matthew.Bocci@alcatel-lucent.co.uk wrote: > During the meeting in Prague, there was a request to make > draft-decnodder-ancp-mib-an-01.txt a working group draft. > > Please indicate to the list if you support this. > > Regards, > > Matthew > > > > > _______________________________________________ > 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 Fri Mar 23 08:55:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUjJ6-0007ws-9C; Fri, 23 Mar 2007 08:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRav3-0001XB-Q4 for ancp@ietf.org; Wed, 14 Mar 2007 17:22:01 -0400 Received: from ext-sendmail2.labs.att.com ([205.173.58.20] helo=sendmail2.labs.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRav0-0006wL-8d for ancp@ietf.org; Wed, 14 Mar 2007 17:22:01 -0400 Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com [144.60.9.139]) by sendmail2.labs.att.com (8.14.0/8.13.1) with ESMTP id l2ELLrtP016267 for ; Wed, 14 Mar 2007 16:21:53 -0500 Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228]) by labs.att.com (8.14.0/8.13.1) with ESMTP id l2ELGoDq023800 for ; Wed, 14 Mar 2007 16:16:50 -0500 Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 16:21:53 -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] Multicast in ANCP Date: Wed, 14 Mar 2007 16:21:52 -0500 Message-ID: <0CED449E95A92A42991EB71B778C17BF04C9DB4D@TSMAIL2.ad.tri.sbc.com> In-Reply-To: <001201c7665b$bca1dcd0$242413ac@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Multicast in ANCP Thread-Index: Acdf9k4VP+PmpMWmRpWoFSXC2t1a5wGV4IGgAAwvd9A= References: <001201c7665b$bca1dcd0$242413ac@ad.redback.com> From: "Serbest, Yetik" To: X-OriginalArrivalTime: 14 Mar 2007 21:21:53.0477 (UTC) FILETIME=[C96F3750:01C7667E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-Mailman-Approved-At: Fri, 23 Mar 2007 08:55:47 -0400 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 agree: We need all three cases. The following is also a good set of problem definitions, which can be solved by ANCP multicast extensions. -----Original Message----- From: Curtis Sherbo [mailto:csherbo@redback.com]=20 Sent: Wednesday, March 14, 2007 12:11 PM To: ancp@ietf.org Subject: RE: [ANCP] Multicast in ANCP Greetings, With respect to the multicast use case currently in the ANCP charter, I support keeping it in scope, with clarifications, and specifying the ANCP protocol to support it. Here are my thoughts around several multicast problems that could be nicely solved with a mechanism such as ANCP. Multicast Replication Today there are varying implementations of multicast replication in Access Nodes, making it difficult for Service Providers to implement a uniform model across the network. Add to this the ability to uniformly enact policy and/or accounting, and you have a very large problem that today would require a complex OSS solution. As already brought forward, it would be simpler to utilize existing functions on the NAS for both policy and accounting with enchantments that include the use of ANCP to signal L2 replication state on the AN. Sheer volume of ANs to NASs deployed, make it logical from a policy control perspective to centralize this function on the NAS. Enacting Policy on a large scale to varying AN types and vendors is a daunting task. I agree with an earlier statement that the potential function of ANCP to signal L2 replication state should not preclude the use of IGMP snooping. I just think it would be a valuable option in moving the functionality of the network beyond supporting basic broadcast television support. Fast Channel Change Although not yet commonly discussed in current working groups, perhaps this is an opportunity to discuss potential solutions. Some known Middleware implementations utilize a unicast stream at time of channel change, and switch to the multicast stream at a secondary point in time. This two part channel change makes simple access lists and straight IGMP snooping a little less useful. Perhaps some opportunities for optimization would present themselves if the decision making process was left up to the NAS. Access Control (Simple Policy) I think it is easily agreed that a basic form of Multicast (IGMP) Filtering on an Access Node is a good idea. The debatable point is whether these lists are dynamic or not. In the simplest case, dynamic means installed at the start of a subscriber session. In the more advanced case, dynamic would mean some sort of real time function where the AN could query the real time Authorization of a particular Multicast group. Accounting Use cases are starting to be discussed that would require accounting for multicast traffic. Since Accounting is typically performed on the NAS, with existing systems setup to collect this info from the NAS, it only makes sense to aggregate the records that account for the multicast traffic on the NAS and utilize existing systems to collect this data. Bandwidth Control The NAS has the best view of available network resources in both an upstream and downstream perspective. A hot topic for discussion today is a bandwidth admission function, that should account for both Multicast and Unicast traffic. Utilizing the NASs position in the network, and knowledge of subscriber state, make this a logical point for providing feedback on resources, as well as querying/signaling of downstream elements for the purpose of optimizing available bandwidth. I look forward to further discussion. Regards, Curtis Sherbo -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: Tuesday, March 06, 2007 5:49 AM To: ancp@ietf.org Subject: [ANCP] Multicast in ANCP I would like to start a discussion on what the working group would like to do with Multicast in ANCP. Currently the ANCP charter includes multicast as one of the use cases, as follows: "When multicast replication for subscriber-bound traffic is performed at the AN, it off-loads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership." The framework draft (draft-ietf-ancp-framework-01.txt) says that the access loop configuration mechanisms may be useful for setting the per-Subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function. It goes on to say that a Subscriber's policy and configuration for multicast traffic might only be known at the NAS. The Access Node Control Mechanism could be used to exchange the necessary information between the Access Node and the NAS so as to allow the Access Node to perform multicast replication in line with the Subscriber's policy and configuration, and also allow the NAS to follow each Subscriber's multicast group membership. None of these multicast mechanisms are defined in the ANCP protocol draft, and I think there is insufficient detail in the framework draft to fully specify this use case. There has been very little work on this since the charter discussions, but the ANCP working group needs to clarify what it wants to do (if anything) with multicast for the framework can move forward. I think there are two choices: Either we should clarify the use case and specify the ANCP protocol to support it, or we should remove the multicast use case from the framework for now. Please post your opinions to the list. We plan to have a discussion on this in Prague, and to try to reach a consensus at around that time. Best regards, Matthew _______________________________________________ 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 Fri Mar 23 11:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUlQt-0005n3-AB; Fri, 23 Mar 2007 11:11:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUlQs-0005mx-8R for ancp@ietf.org; Fri, 23 Mar 2007 11:11:58 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUlQp-0006zU-Od for ancp@ietf.org; Fri, 23 Mar 2007 11:11:58 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com) ([172.31.244.40]) by iron.ecitele.com with ESMTP; 23 Mar 2007 17:14:28 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 23 Mar 2007 17:11:53 +0200 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 AN MIB to WG draft? Date: Fri, 23 Mar 2007 17:11:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP AN MIB to WG draft? Thread-index: Acdrrp8wBvncO3QSTsuaTwYEr+iGqgBrt3Zw From: "Michel Platnic" To: , X-OriginalArrivalTime: 23 Mar 2007 15:11:54.0032 (UTC) FILETIME=[97407B00:01C76D5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 I support this draft becoming a WG document, Regards, Michel Platnic.=20 -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Sent: Wednesday, March 21, 2007 1:43 PM To: ancp@ietf.org Subject: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ 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 Mar 26 08:38:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVoSw-0002tq-0E; Mon, 26 Mar 2007 08:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVoSu-0002tk-GQ for ancp@ietf.org; Mon, 26 Mar 2007 08:38:24 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVoSs-0007KN-Ur for ancp@ietf.org; Mon, 26 Mar 2007 08:38:24 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l2QCcOMe005371; Mon, 26 Mar 2007 14:38:25 +0200 Received: from [172.31.131.58] ([172.31.131.58]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007032614381677:3755 ; Mon, 26 Mar 2007 14:38:16 +0200 Message-ID: <4607BEB8.2050204@alcatel-lucent.be> Date: Mon, 26 Mar 2007 14:38:16 +0200 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Platnic Subject: Re: [ANCP] ANCP MIB - Connection between Partition IDs and Session IDs References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/26/2007 14:38:16, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/26/2007 14:38:17, Serialize complete at 03/26/2007 14:38:17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 Michel, see inline... Michel Platnic wrote: > Hi Stefaan, > > About Question 1: > I also support your views regarding the overall mechanism. Tough, if we > agree that each session is autonomous, I am not sure that 'functional > partitioning' is a must anymore. If one NAS requests access attributes, > the AN sends results only to this NAS, if later on an other NAS > connected to the same partition via an other session sends the same > request, it may receive, in its turn, the requested attributes. There > might be some operational limitations for the configuration use-case, > but details for this use-case are not defined yet so its too early to > say. > > About Question 2: > The main idea to have several partitions sharing the same session is on > one hand to reduce the number of sessions and on the other hand to allow > a separation between the different ISPs. Indeed, several ISPs might be > connected to one NAS but could use only one single session to address > the relevant partitions. Limitation: all ISPs using a single session > should support a common set of capabilities. In this case I would suggest to group all DSL lines that belongs to the same NAS (though belonging to multiple ISPs) in one partition. A partition more belongs to a session and not necessarily to an ISP. A partition is meant to define the lines subject to a particular partition, so that's why I would think that an ANCP session should not handle multiple partitions. regards, Stefaan > This proposal is only one of several other possible solutions to reduce > the number of sessions. It adds some level of complexity to the model > but seems a good comprise compared to other solutions such as an > aggregation switch ANCP proxy to implement same feature for example. > > Regards, > Michel. > > -----Original Message----- > From: stefaan.de_cnodder@alcatel-lucent.be > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Monday, March 19, 2007 7:50 PM > To: Michel Platnic > Cc: ancp@ietf.org > Subject: Re: [ANCP] ANCP MIB - Connection between Partition IDs and > Session IDs > > > Hi Michel, > > see inline... > > >>Hi All, >> >> The ANCP MIB Draft 'draft-decnodder-ancp-mib-an-01' defines that a >>Partition ID can be associated to several session IDs. This allows an > > AN > >>to receive commands from several NAS. >> >>_Question 1:_ How does the reporting from the AN to the NAS works? > > Shall > >>it send the results only to the requester (NAS which sent the command) > > >>or to all NAS connected to the partition ID (depending on the session >>negotiated capabilities with the NAS)? >> > > > That's how I understand it. The framework document says: "The Access > Node SHOULD be able to work with redundant controllers." How this works > > is not further specified but it looks to me that in this case, one > partition can have multiple ANCP sessions. When there are 2 sessions, > then I would expect that they are treated independently from each other, > > i.e., what is send over one session is the same as if the other session > was not there. Previously, "functional partitioning" was also discussed > > on this mailing list a while ago, and in that case, you might have a NAS > > per capability, and hence a session per capability. > > >> >>In case several Partitions are used per AN a high number of Sessions > > can > >>potentially be terminated at the NAS. Allowing to associate one > > Session > >>ID to several Partitions may help reduce the number of Sessions. >> >>_Question 2:_ The MIB defines that a Partition ID can be associated to > > >>several Sessions IDs, should we, in addition to this, allow one > > Session > >>ID to be connected to several Partition IDs? >> > > > I am all open for it but I am not sure if there is a good case where 1 > session need to control multiple partitions. In fact, partioning is a > quite hard separation of the access node and I am not sure if it is good > > that 2 partitions are sharing the same session. Why would you make 2 > partitions in this case? Would it not be better to make one partition > of it? > > As MIB impact, I see that in the configuration instead of 1 partition ID > > per session we need multiple partition IDs per session, meaning another > table. If there are good cases for it, it is ok for me. Note that ANCP > > is based on GSMP, and also the ANCP MIB is (more or less) based on the > GSMP MIB, and the current ANCP MIB has taken this from the GSMP MIB. > > Thanks, > > Stefaan > > > >>Regards, >>Michel. >> >> >> >> >> > > ------------------------------------------------------------------------ > >>_______________________________________________ >>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 Mar 26 15:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVuf9-00057B-8B; Mon, 26 Mar 2007 15:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVuf7-0004yI-M6 for ancp@ietf.org; Mon, 26 Mar 2007 15:15:25 -0400 Received: from [216.23.136.226] (helo=mailhost.van.redback.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVuf4-00064D-Cv for ancp@ietf.org; Mon, 26 Mar 2007 15:15:25 -0400 Received: from CSHERBOTM5XP (unknown [172.31.253.16]) by mailhost.van.redback.com (Postfix) with ESMTP id 2259F6BA02 for ; Mon, 26 Mar 2007 12:15:18 -0700 (PDT) From: "Curtis Sherbo" To: Subject: RE: [ANCP] ANCP AN MIB to WG draft? Date: Mon, 26 Mar 2007 12:16:24 -0700 Message-ID: <005601c76fdb$3f45d2d0$4201a8c0@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrrp8JRGPwr/5BSjuEKy5xBzNHzAELH/zA X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 support this becoming a WG Draft. Thanks, Curtis -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk] Sent: Wednesday, March 21, 2007 4:43 AM To: ancp@ietf.org Subject: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ 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 Mar 28 17:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfPX-0000Pz-Fj; Wed, 28 Mar 2007 17:10:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWfPW-0000OT-1X for ancp@ietf.org; Wed, 28 Mar 2007 17:10:26 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWfPU-0002lP-OR for ancp@ietf.org; Wed, 28 Mar 2007 17:10:26 -0400 Received: by wr-out-0506.google.com with SMTP id 71so2338459wri for ; Wed, 28 Mar 2007 14:10:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=a3Y0Fa+I6wNXgw1T30tENGm63LtT0BE5xnTp2LhS0obebXq501Nbwhd0QLtLQ6amfde/jqwFF4baU4eHoHZ8smjcsbsxDaY2dVuMlQr4tRp88gaJSiDDeqXwV15nEeVLCdg17K0SV1lnmIoMDIAMsmX8zoefpovxjI876GS47BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GlTwJ9MdNFza7XPZt3440HKSIzeOTl7kqZ+LRhPZOlt8KvFQZDGkhzGoDxpoiCjEE9YK8116e38bygZa7nvod5fP8ng0CV8oG6ny4VcexzxrzjK+1Z6LDGXQg+VqrV7BXSuT6S9UJkPmUdzmXbXZuC9UhWsGLUCafRXEKToXKPM= Received: by 10.114.12.9 with SMTP id 9mr3937448wal.1175116223664; Wed, 28 Mar 2007 14:10:23 -0700 (PDT) Received: by 10.115.109.17 with HTTP; Wed, 28 Mar 2007 14:10:23 -0700 (PDT) Message-ID: Date: Wed, 28 Mar 2007 22:10:23 +0100 From: "Hasnaa Moustafa" To: ancp@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [ANCP] Re: ANCP Digest, Vol 10, Issue 14 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="===============0666064682==" Errors-To: ancp-bounces@ietf.org --===============0666064682== Content-Type: multipart/alternative; boundary="----=_Part_40324_27755715.1175116223510" ------=_Part_40324_27755715.1175116223510 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I support this draft as a WG document. Hassnaa Moustafa -----Original Message----- > From: Matthew.Bocci@alcatel-lucent.co.uk > [mailto:Matthew.Bocci@alcatel-lucent.co.uk] > Sent: Wednesday, March 21, 2007 4:43 AM > To: ancp@ietf.org > Subject: [ANCP] ANCP AN MIB to WG draft? > > During the meeting in Prague, there was a request to make > draft-decnodder-ancp-mib-an-01.txt a working group draft. > > Please indicate to the list if you support this. > > Regards, > > Matthew > > > > > _______________________________________________ > 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 > > > End of ANCP Digest, Vol 10, Issue 14 > ************************************ > ------=_Part_40324_27755715.1175116223510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
 

I support this draft as a WG document.
 
Hassnaa Moustafa

 
 

-----Original Message-----
From: Matthew.Bocci@alcatel-lucent.co.uk
[mailto:Matthew.Bocci@alcatel-lucent.co.uk]
Sent: Wednesday, March 21, 2007 4:43 AM
To: ancp@ietf.org
Subject: [ANCP] ANCP AN MIB to WG draft?

During the meeting in Prague, there was a request to make
draft-decnodder-ancp-mib-an-01.txt a working group draft.

Please indicate to the list if you support this.

Regards,

Matthew




_______________________________________________
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


End of ANCP Digest, Vol 10, Issue 14
************************************

------=_Part_40324_27755715.1175116223510-- --===============0666064682== 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 --===============0666064682==--