Re: [L2CP] Updated LC charter
stefaan.de_cnodder@alcatel.be Mon, 22 May 2006 17:27 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEBq-0006NK-Je; Mon, 22 May 2006 13:27:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEBp-0006Ma-GO for l2cp@ietf.org; Mon, 22 May 2006 13:27:33 -0400
Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEBi-0002VZ-Um for l2cp@ietf.org; Mon, 22 May 2006 13:27:33 -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/Debian-3sarge1) with ESMTP id k4MHRPEn014986 for <l2cp@ietf.org>; Mon, 22 May 2006 19:27:25 +0200
Received: from [138.203.192.189] ([138.203.192.189]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF868) with ESMTP id 2006052219272338:4952 ; Mon, 22 May 2006 19:27:23 +0200
Message-ID: <4471F47B.7020906@alcatel.be>
Date: Mon, 22 May 2006 19:27:23 +0200
From: stefaan.de_cnodder@alcatel.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: Matthew.Bocci@alcatel.co.uk
Subject: Re: [L2CP] Updated LC charter
References: <OF4A2DB3F0.97006032-ON80257176.0058F313-80257176.0059BB70@netfr.alcatel.fr>
In-Reply-To: <OF4A2DB3F0.97006032-ON80257176.0058F313-80257176.0059BB70@netfr.alcatel.fr>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/22/2006 19:27:23, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/22/2006 19:27:25, Serialize complete at 05/22/2006 19:27:25
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: 9a2be21919e71dc6faef12b370c4ecf5
Cc: l2cp@ietf.org
X-BeenThere: l2cp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Layer 2 Control Protocol Discussion List <l2cp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2cp>, <mailto:l2cp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l2cp>
List-Post: <mailto:l2cp@ietf.org>
List-Help: <mailto:l2cp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2cp>, <mailto:l2cp-request@ietf.org?subject=subscribe>
Errors-To: l2cp-bounces@ietf.org
Matthew, some comments inline.... Purpose: The purpose of the ANCP WG is to standardize an IP based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) access and aggregation networks. ANCP operates between a DSL Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office, that terminates DSL connections from Subscribers. Often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). [Stefaan] RFC2138 already define the term NAS. Is it the same definition? Is it needed to repeat it, if not the same then better to use another term. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Characterization Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop characteristics and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop characteristics from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via end-to-end ATM loopbacks. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. [Stefaan] I would remove "via end-to-end ATM loopbacks" because the text seems to suggest that ATM loopbacks have to be used consistently... 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads 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. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over a DSL access and aggregation network. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol should be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks. [Stefaan] A goal of the working group is to solve the requirements for DSL access in such a way that the solution can be re-used later for other technologies as well. Is is something that should be clearer in the "goals" section. regards, Stefaan _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp
- [L2CP] Updated LC charter Matthew.Bocci
- Re: [L2CP] Updated LC charter stefaan.de_cnodder
- Re: [L2CP] Updated LC charter Matthew.Bocci
- Re: [L2CP] Updated LC charter stefaan.de_cnodder
- Re: [L2CP] Updated LC charter Matthew.Bocci
- Re: [L2CP] Updated LC charter stefaan.de_cnodder
- Re: [L2CP] Updated LC charter Matthew.Bocci