[secdir] [New-work] WG Review: Recharter of Access Node Control Protocol (ancp)

IESG Secretary <iesg-secretary@ietf.org> Tue, 29 September 2009 16:45 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBC428C170 for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 09:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.999
X-Spam-Level:
X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFEhTSK5hQtF for <secdir@core3.amsl.com>; Tue, 29 Sep 2009 09:45:30 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BDD3128C173 for <secdir@ietf.org>; Tue, 29 Sep 2009 09:45:28 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TGknHW009800 for <secdir@ietf.org>; Tue, 29 Sep 2009 12:46:49 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8TGkkoK009788 for <secdir@PCH.mit.edu>; Tue, 29 Sep 2009 12:46:48 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n8TGkZQ8020110 for <secdir@mit.edu>; Tue, 29 Sep 2009 12:46:36 -0400 (EDT)
Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id E9DE81F0F8F2 for <secdir@mit.edu>; Tue, 29 Sep 2009 12:46:34 -0400 (EDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id TyEb6bKdjxXyfuxw for <secdir@mit.edu>; Tue, 29 Sep 2009 12:46:34 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org;
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6DA28C19D; Tue, 29 Sep 2009 09:45:12 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id D9AE528C174; Tue, 29 Sep 2009 09:45:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20090929164501.D9AE528C174@core3.amsl.com>
Date: Tue, 29 Sep 2009 09:45:01 -0700
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 29 Sep 2009 09:49:10 -0700
Subject: [secdir] [New-work] WG Review: Recharter of Access Node Control Protocol (ancp)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2009 16:45:32 -0000

A modified charter has been submitted for the Access Node Control Protocol
(ancp) working group in the Internet Area of the IETF.  The IESG has not
made any determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, October 6, 2009.

Access Node Control Protocol (ancp)
-----------------------------------
Current Status: Active Working Group

 Chair(s):
   Wojciech Dec  <wdec@cisco.com>
   Matthew Bocci  <matthew.bocci@alcatel-lucent.com>

 Internet Area Director(s):
   Ralph Droms  <rdroms@cisco.com>
   Jari Arkko  <jari.arkko@piuha.net>

 Internet Area Advisor:
   Ralph Droms  <rdroms@cisco.com>

 Technical Advisor(s):
   Dan Romascanu  <dromasca@avaya.com>

 Mailing Lists:
   General Discussion: ancp@ietf.org
   To Subscribe:       ancp-request@ietf.org
      In Body:         In Body: subscribe your_email_address
   Archive:           
http://www.ietf.org/mail-archive/web/ancp/current/maillist.html


Description of Working Group: 
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) and Passive Optical Network (PON) access and aggregation
networks.  ANCP operates between an Access Node (AN) and Network
Access Server (NAS).

Necessary Terminology: 

Access Node (AN) - Network device, usually located at a service
provider central office or street cabinet, that terminates access loop
connections from Subscribers. In DSL, this is often referred to as a
Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is
usually comprised of an Optical Network Termination (ONT) / Optical
Network Unit (ONU) and an Optical Line Termination (OLT).

Network Access Server (NAS) - Network device which aggregates
multiplexed Subscriber traffic from a number of Access Nodes. The NAS
plays a central role in per-subscriber policy enforcement and QoS.
This is often referred to as a Broadband Network Gateway (BNG) or
Broadband Remote Access Server (BRAS). A detailed definition of the
NAS is given in RFC2881.

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 and PON 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 Attributes
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 status, attributes 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 attributes 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 ATM OAM tools. 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.

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. 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 must 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 service provider broadband
(such as xDSL, xPON) access and aggregation networks.


Security: 

The ANCP working group will provide a threat analysis and address the
associated security aspects of the control protocol.

Resiliency and Scalability: 

A graceful restart mechanism will be defined to enable the protocol to
be resilient to network failures between the AN and NAS.

Scalability at the NAS is of primary concern, as it may be aggregating
traffic from a large number of ANs, which in turn may be serving a
large number of Subscribers. ANCP traffic should not become a denial
of service attack on the NAS control plane. Format of messages,
pacing, transport over UDP or TCP, etc. will be considered with this
in mind.

For reasons of aggregation network scalability, some use cases require
that aspects of NAS or AN functionality may be distributed in nodes in
the aggregation network. In these cases, ANCP can run between these
nodes.

Deliverables: 

The working group will define a basic framework and requirements
document intended for Informational publication, focusing on the four
use-cases outlined in this charter. This document will include a
security threat analysis and associated requirements. The WG will then
investigate and define a solution for an IP based control protocol
meeting these requirements.

There are early interoperable implementations of an ANCP-like protocol
which are based on an extended subset of the GSMPv3 protocol. This
running code will be the the starting point for the working group
solution, and will be abandoned only if the WG determines it is not
adequate to meet requirements going forward.

Coordination with other Working Groups or Organizations: 

The working group will coordinate with the ADSL MIB working group so
the management framework and MIB modules are consistent for DSL access
environments. The working group will re-use, as far as possible,
standard MIB modules that have already been defined.

The remote connectivity test use case may require coordination with
ITU-T Ethernet OAM and PON work and with IEEE 802.1ag.

Goals and Milestones: 

Done            Accept WG I-D for ANCP Framework and Requirements 
Done            Accept WG I-D for Access Node Control Protocol (ANCP) 
Done            Accept WG ID for Security Threats analysis 
Done            Accept WG I-D for ANCP MIB 
Done            Security Threats Analysis last call 
Done            Framework and Requirements last call 
Done            Accept WG I-D for ANCP Multicast Extensions
Nov 2009        Accept WG I-D for ANCP applicability to PON 
Jan 2010        Access Node Control Protocol (ANCP) Last Call 
Jan 2010        ANCP Multicast Extensions last call
Jan 2010        ANCP MIB Last Call 
Apr 2010        ANCP applicability to PON last call
Jul 2010        Re-charter or conclude Working Group
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir