Subject: RE: [L2CP] Revised WG Charter Draft

From: Knud Gjørup (AH/LMD) <[email-masked]>
Date: Wed, 29 Mar 2006 13:50:06 +0200

Hi All,

Let me first apologise for being "a bull in a china shop", but I thing our charter is much too specific and is perhaps disguising our actual task.

The must important sentence in the charter is:
> The goal of a L2CP message exchange is to 
> convey status and control information between access devices 
> and one or more other NAS devices without going through 
> intermediate element managers.

In general I consider L2CP an application protocol between a Customer Service Management System (CSMS) and an Access Node (AN).
The CSMS may be situated in a BRAS, NAS, BNG or even together with a Radius server, but the important task for the CSMS is to  communicate the content of the Customer Service DB (like agreed QoS) to the AN and to communicate the actual QoS back to the accounting system and the Customer Service DB. This communication is done by L2CP.
The AN implements (or understands) some standardised L2CP primitives e.g.: Access-Line-Status, Access-Line-Configuration (profiles), and Access-Line-Test. These primitives should be as independent of the actual access technology as possible! The primitives are invoked (or communicated) by the L2CP application protocol as described in the use cases in the below charter.

If you agree in this overall reference architecture for L2CP, I also think you must agree in the following points:
1) L2CP is independent of the actual communication technology (as application protocols in general) between the CSMS and the AN, implying: L2CP is not IP based! But the WG will analyse and define the different comm. technologies including IP, UDP, TCP, Ethernet etc and specify the necessary encapsulation methods.
2) In spite L2CP is comm. techn. independent it is decided to be connection less based (like GSMP). If it is not defined as connection less it will be impossible/difficult to use UDP or Ethernet as communication technology.
3) The standardised L2CP primitives (in the AN) are independent of the actual access technology, and when not, this should be explicitly specified. The WG will emphasise on DSL Ether based and DSL ATM based access, but will not preclude the use of other access technologies. (This is why I personally don't like to use Layer-2 or Broadband in the WG name e.g. BAMP -  but prefer GAMP as I consider L2CP to be a sort of umbrella for different Access Management Protocols)

But as always when you specify something, you try to make your specification and definitions very general and comprehensive, and when you end up with your specification you will realise that you have found a reasonable compromise and a result much more specific and limited than originally planned.

What I want to emphasize by this note is that we have to TRY to make L2CP a GENERAL application protocol to ensure it's future applicability!

Regards 
Knud

> -----Original Message-----
> From: Wojciech Dec (wdec) [mailto:[email-masked]] 
> Sent: 27. marts 2006 16:15
> To: [email-masked]
> Subject: [L2CP] Revised WG Charter Draft
> 
> Hello All,
> 
> Following last week's BoF and the collected feedback we have 
> gone and revised the charter which is now re-proposed below. 
> The name of the WG is in the process of being discussed and 
> it's clear that it will NOT be L2CP, so please substitute 
> L2CP with whatever is your preferred acronym while reading the draft.
> 
> In order to put together the charter into shape in a 
> reasonably timely manner I would encourage all interested 
> parties to provide a prompt review, feedback and discussion. 
> Once we have a proposal that's acceptable we will be putting 
> the draft to a group "final call", tentatively aiming for 
> approximately 2 weeks from now.
> 
> Regards,
> Woj.
> 
> -------------------WG CHARTER (DRAFT)------------------------
> 
> Layer 2 Control Protocol (L2CP)
> 
> 
> Current Status: Non-existing Working Group
> 
> Chair(s):
> Matthew Bocci ([email-masked]) Wojciech Dec  
> ([email-masked])
> 
> Internet Area Director(s):
> Mark Townsley <[email-masked]>
> Jari Arkko <[email-masked]>
> 
> Technical Advisor(s):
> TBD <tbd>
> 
> Secretary(ies):
> TBD <tbd>
> 
> Area Specific Mailing List:
> [email-masked]
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> In Body: subscribe your_email_address
> Archive: http://www.ietf.org/mail-archive/web/l2cp/index.html
> 
> Description of the charter for this WG:
> 
> The purpose of the L2CP WG is to standardize an IP based 
> Layer 2 control protocol (L2CP) for use in service provider 
> access and aggregation type networks. The protocol is to be 
> inter-operable among a wide set of multi-vendor devices, 
> including but not limited to Access Nodes and Network Access 
> Server (NAS) nodes e.g. Broadband Network Gateways (BNGs). 
> 
> L2CP is intended to addresses the requirement for a 
> bidirectional, IP-based protocol that operates across a 
> number of access and aggregation network technologies e.g. 
> Ethernet, ATM. The goal of a L2CP message exchange is to 
> convey status and control information between access devices 
> and one or more other NAS devices without going through 
> intermediate element managers. An example of this is the 
> transmission of an access loop rate information from the edge 
> access node to a NAS device tasked with shaping traffic to 
> that rate. A further example is to trigger a local action on 
> an access device, such as the initiation of a local port 
> testing mechanism.
> 
> L2CP will address the following use-cases:
> 
> - Access Link Discovery
> Various queuing and scheduling mechanisms are used in access 
> networks to avoid congestion while dealing with multiple 
> flows with distinct QoS requirements. Such mechanisms require 
> that a NAS node gains knowledge of particular access-loop 
> characteristics e.g. DSL sync Rate. The layer 2 control 
> protocol is intended to convey this information between the 
> access node and a NAS node. 
> 
> - Line Configuration
> Following dynamic line identification (subscriber local 
> loop), assisted by the mechanism described in the access link 
> discovery use case, a NAS node could then query a subscriber 
> OSS system (e.g. RADIUS server) to retrieve subscriber 
> service profiles relating to the subscriber line.
> L2CP is intended to simplify the OSS infrastructure for 
> service management, allowing subscriber-related service data 
> to be maintained in fewer repositories (e.g. RADIUS server 
> back-end database) while avoiding complex cross-organization 
> interactions.
> 
> - Remote Connectivity Test
> Traditional DSL broadband access networks employ 
> point-to-point ATM circuits between a DSL modem and a NAS. In 
> such an environment, troubleshooting of the local loop and 
> aggregation network can be achieved by means of end-to-end 
> ATM loopbacks. With the increasing deployment of Ethernet in 
> the aggregation network, operators require consistent methods 
> to test and troubleshoot connectivity for mixed Ethernet and 
> ATM access networks (including the local loop). L2CP will 
> allow a remote procedure for the local loop connectivity test 
> to be triggered from the NAS and the results communicated 
> back to the NAS.
> 
> - Multicast
> Various mechanisms have been defined to create multicast 
> replication in the access nodes. There is a need to control 
> multicast replication in the access node, and to communicate 
> multicast state between the access node and the NAS node in 
> order to allow, for example, centralized policy control. 
> L2CP will address security aspects of the control protocol, 
> including the trust model between NAS nodes and access nodes. 
> The protocol will work with typical redundancy schemes for 
> subscriber service nodes and will be resilient to network failures.
> 
> The protocol design will not preclude other uses of L2CP.
> 
> The working group will define a framework and set of 
> requirements, and will investigate and define a solution for 
> an IP based Layer 2 control protocol that is robust, reliable 
> and scalable. L2CP will be based on extensions to existing 
> protocols, although the working group must justify its 
> choice. The initial proposal for L2CP is based on a subset of GSMPv3.
> 
> L2CP will not address the signaling of any type of VCs used 
> in the underlying aggregation network. 
> 
> 
> Goals and Milestones:
> 
> July 2006	      Accept WG I-D for L2CP Framework / Requirements
> July 2006	      Accept WG I-D for L2C Protocol extensions
> September 2006  Framework and requirements last call
> November 2006   Accept WG I-D for L2C MIBs
> December 2006   Protocol extensions last call
> January 2007    MIBs last call
> March 2007	 Re-charter or conclude Working Group
> 
> Internet-Drafts:
> 
> _______________________________________________
> L2cp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/l2cp
> 

_______________________________________________
L2cp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2cp

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 29 Mar 2006 09:30:30 -0500

Knud,

Assuming you take this approach to the architecture, should the 
L2CP/BAMP/BANCo protocol also be required to handle communication 
between redundant CSMSes, so that the CSMS doesn't become a potential 
single point of failure?  This would be necessary if the CSMS retains 
knowledge of the state of the AN.  Should this become part of the charter?

Cheers,
Andy

-------------

At 3/29/2006 13:50 +0200, AH/LMD wrote:
>Hi All,
>
>Let me first apologise for being "a bull in a china shop", but I 
>thing our charter is much too specific and is perhaps disguising our 
>actual task.
>
>In general I consider L2CP an application protocol between a 
>Customer Service Management System (CSMS) and an Access Node (AN).
>The CSMS may be situated in a BRAS, NAS, BNG or even together with a 
>Radius server, but the important task for the CSMS is 
>to  communicate the content of the Customer Service DB (like agreed 
>QoS) to the AN and to communicate the actual QoS back to the 
>accounting system and the Customer Service DB. This communication is 
>done by L2CP.
>The AN implements (or understands) some standardised L2CP primitives 
>e.g.: Access-Line-Status, Access-Line-Configuration (profiles), and 
>Access-Line-Test. These primitives should be as independent of the 
>actual access technology as possible! The primitives are invoked (or 
>communicated) by the L2CP application protocol as described in the 
>use cases in the below charter.
>
>If you agree in this overall reference architecture for L2CP, I also 
>think you must agree in the following points:
>1) L2CP is independent of the actual communication technology (as 
>application protocols in general) between the CSMS and the AN, 
>implying: L2CP is not IP based! But the WG will analyse and define 
>the different comm. technologies including IP, UDP, TCP, Ethernet 
>etc and specify the necessary encapsulation methods.
>2) In spite L2CP is comm. techn. independent it is decided to be 
>connection less based (like GSMP). If it is not defined as 
>connection less it will be impossible/difficult to use UDP or 
>Ethernet as communication technology.
>3) The standardised L2CP primitives (in the AN) are independent of 
>the actual access technology, and when not, this should be 
>explicitly specified. The WG will emphasise on DSL Ether based and 
>DSL ATM based access, but will not preclude the use of other access 
>technologies. (This is why I personally don't like to use Layer-2 or 
>Broadband in the WG name e.g. BAMP -  but prefer GAMP as I consider 
>L2CP to be a sort of umbrella for different Access Management Protocols)
>
>But as always when you specify something, you try to make your 
>specification and definitions very general and comprehensive, and 
>when you end up with your specification you will realise that you 
>have found a reasonable compromise and a result much more specific 
>and limited than originally planned.
>
>What I want to emphasize by this note is that we have to TRY to make 
>L2CP a GENERAL application protocol to ensure it's future applicability!
>
>Regards
>Knud
>
>