Re: [L2CP] Updated LC charter

Matthew.Bocci@alcatel.co.uk Mon, 22 May 2006 18:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiF9O-000352-QK; Mon, 22 May 2006 14:29:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiF9O-00034x-DW for l2CP@ietf.org; Mon, 22 May 2006 14:29:06 -0400
Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiF9M-0005dM-S7 for l2CP@ietf.org; Mon, 22 May 2006 14:29:06 -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/Debian-3sarge1) with ESMTP id k4MIT3Zw031259 for <l2CP@ietf.org>; Mon, 22 May 2006 20:29:03 +0200
Subject: Re: [L2CP] Updated LC charter
To: stefaan.de_cnodder@alcatel.be
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF5D6E27DC.A9A2E902-ON80257176.00657E7F-80257176.00658A53@netfr.alcatel.fr>
From: Matthew.Bocci@alcatel.co.uk
Date: Mon, 22 May 2006 19:29:05 +0100
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 05/22/2006 19:29:03
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: 21bf7a2f1643ae0bf20c1e010766eb78
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



Stefaan,

Thanks for your comments.

Please see below.

Matthew




                                                                           
             Stefaan DE                                                    
             CNODDER/BE/ALCATE                                             
             L@ALCATEL                                                  To 
                                       Matthew BOCCI/GB/ALCATEL@ALCATEL    
             22/05/2006 18:27                                           cc 
                                       l2cp@ietf.org                       
                                                                   Subject 
                                       Re: [L2CP] Updated LC charter       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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.

MB> Unfortunately they do not seem to be exactly the same, since the RFC
assumes a RADIUS client in the NAS. Do you have any other suggestions?
Could we just go with BNG, as per the DSL Forum?

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...

MB> This sin't a requirement, but rather an explanation of how things are
today. How about "...via ATM OAM tools."?


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