Subject: [L2CP] Revised WG Charter Draft

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Mon, 27 Mar 2006 16:15:20 +0200

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

---

From: Knud Gjørup (AH/LMD) <[email-masked]>
Date: Thu, 30 Mar 2006 11:06:48 +0200

Andy,

We don't need to mention "communication between redundant CSMSes" in the charter as this problem is "solved" in GSMP (and GAMP is an extended subset of GSMPv3++)

The GSMP approach is to introduce an "Adjacency Update message" (Message Type = 85). It informs the controller/CSMS when adjacencies, i.e., other controllers/CSMSes controlling a specific partition/AN, are joining or leaving.
And the overall concept is (quoted): "Multiple switch controllers/CSMSes may jointly control a single switch partition/AN.  The controllers/CSMSes may control a switch partition/AN either in a primary/standby fashion or as part of multiple controllers/CSMSes providing load-sharing for the same partition/AN. It is the responsibility of the controllers/CSMSes to co-ordinate their interactions with the switch partition/AN". (I especially like the last sentence)

This concept fits us (as manufacturer of big ANs) very well. Our equipment (DSLAMs) are e.g. bought and deployed by an Access Provider. The ports on a DSLAM are split up into several partitions=ANs, one for each Network Access Provider (NAP). The NAP handles one or several CSMSes used for General Access Management on there part of a DSLAM, i.e. on there partition. This implies that multiple CSMSes handling the same AN/partition belongs to one and only one organization (capable of doing the necessary co-ordination between the CSMSes).
A NAP handling access ports on a DSLAM is not aware of the other NAPs handling access ports on the same physical DSLAM.

I general (I think) we tend to invent everything by ourselves from scratch, in stead of looking for inspiration in GSMPv3++ (or in WT-101).

Cheers,
Knud

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]] 
> Sent: 29. marts 2006 16:31
> To: Knud Gjørup (AH/LMD)
> Cc: Wojciech Dec (wdec); [email-masked]
> Subject: RE: [L2CP] Revised WG Charter Draft
> 
> 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 think 
> >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.
> > >
> > > Matthew Bocci ([email-masked]) Wojciech Dec
> > > ([email-masked])
> > >
> > > 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).
> > >
> > > 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.
> > >
> > > 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.
> > > 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.
> > >
> > > 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 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.
> > >

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Thu, 30 Mar 2006 11:47:11 +0200

Hi Knud,

A couple of observations on my part:
1. L2CP is indeed intended to be independent of the actual access and aggregation technologies, however in this day and age do we really need to define any non IP based encapsulation? Across all possible segments that I look at I see IP stacks available on devices so what would be the driver for having a L2CPoL2 encap? (Practically speaking this does not appear to be useful)
2. Deriving an alternative transport, possibly UDP based, is something that is within the charter. Also, I don't quite see why you view GSMP as connectionless - an adjacency is formed/negotiated before any info transfer is possible, and keepalives are there to maintain this connection state. Are you suggesting that such adjacency formation and resulting state are not desirable or are you referring to GSMPoTCP? Can you elaborate?
3. Agreed.

Regards,
Woj.

-----Original Message-----
From: Knud Gjørup (AH/LMD) [mailto:[email-masked]] 
Sent: 29 March 2006 13:50
To: Wojciech Dec (wdec); [email-masked]
Subject: RE: [L2CP] Revised WG Charter Draft

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 

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

> 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.
> 
> 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.
> 
> 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 
> 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.
> 
> 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
> 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. 
> subscriber service nodes and will be resilient to network failures.
> 
> 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:
>

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Fri, 31 Mar 2006 09:20:04 +0200

Hi Kund,

All clear about point 2 I think. You are saying that we must address non TCP based transport and any changes this will have on the L2CP protocol.
Would you be happy with us stating in the charter the following?

"The working group will also evaluate L2CP transport on connection and connection-less protocols, and define any necessary extensions for the chosen method."

As for point 1, it does appear reasonable to have the WG focus on tasks that have objectives which are practical and in line with the protocols' deployment expectations. Today and in the foreseeable future in effect this means IP, with the pros and cons and cons that this carries. That said, we are open to a discussion on some *really convincing* practical or deployment reasons for why the WG should look into L2CP over native L2 encaps, but until then let's leave it as IP only (which hardly puts a dependency on the application layer).

Regards,
Woj.

-----Original Message-----
From: Knud Gjørup (AH/LMD) [mailto:[email-masked]] 
Sent: 30 March 2006 13:39
To: Wojciech Dec (wdec); [email-masked]
Subject: RE: [L2CP] Revised WG Charter Draft

Hi Woj

1. (about transport independence) You are of course right, L2CP will run over some IP based communication technology! But as a matter of principle I don't like when defining an application protocol to have stated: "IP based". (My handicap is that I'm grown up with the concept of independent layers). I think a tiny rephrasing of the charter about this independence would satisfy me (and perhaps some other fundamentalists).

2. (about connection less) Even when you define an application protocol independent of the transport protocols beneath you have to decide about the expected service. The important choice here is: connection-less or connection-oriented service? (I assume a conn-lees protocol to be able to use a conn-oriented service without any changes, but not the opposite). When I stated that GSMP is connection-less based, I mean GSMP is capable of running on a conn-less service (like UDP). But GSMP uses this conn-less service to establish a GSMP connection (called a Control Channel) with keep alive monitoring and means to prevent packet loss (almost like having a connection for each port?).
But L2CP as defined to day is not able to run at a conn-less service (like UDP) without changes! We have no protection against packet loss (as far as I remember). Quoted from the draft: "the "Event Sequence Number" should be 0". This indicates that we may loss Event Messages in L2CP over UDP (loss is also possible in GSMP but you have some tools to recover, like Port Management Message). In L2CP you have to stop and start the Control Channel to recover, when not running over TCP.
I hope this more elaborated answer explains the problem we have to decide about?

Best regards
Knud

> Sent: 30. marts 2006 11:47
> To: Knud Gjørup (AH/LMD); [email-masked]
> 1. L2CP is indeed intended to be independent of the actual access and 
> aggregation technologies, however in this day and age do we really 
> need to define any non IP based encapsulation? Across all possible 
> segments that I look at I see IP stacks available on devices so what 
> would be the driver for having a L2CPoL2 encap? (Practically speaking 
> this does not appear to be useful) 2. Deriving an alternative 
> transport, possibly UDP based, is something that is within the 
> charter. Also, I don't quite see why you view GSMP as connectionless - 
> an adjacency is formed/negotiated before any info transfer is 
> possible, and keepalives are there to maintain this connection state. 
> Are you suggesting that such adjacency formation and resulting state 
> are not desirable or are you referring to GSMPoTCP? Can you elaborate?
> 3. Agreed.
> 
> Regards,
> Woj.
> 
> 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 
> 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.
> 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 
> implying: L2CP is not IP based! But the WG will analyse and define the 
> different comm. technologies including IP, UDP, TCP, Ethernet etc and 
> connection less based (like GSMP). If it is not defined as connection 
> 3) The standardised L2CP primitives (in the AN) are independent of the 
> specified. The WG will emphasise on DSL Ether based and DSL ATM based 
> (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)
> 
> 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.
> 
> it's clear
> reasonably timely
> > 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.
> > 
> > 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).
> > 
> 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.
> > 
> > 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 
> > 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.
> maintained
> > in fewer repositories (e.g. RADIUS server back-end database) while 
> > avoiding complex cross-organization interactions.
> > 
> > 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.
> including
> > the trust model between NAS nodes and access nodes.
> subscriber
> > service nodes and will be resilient to network failures.
> > 
> requirements, and

---

From: Knud Gjørup (AH/LMD) <[email-masked]>
Date: Fri, 31 Mar 2006 14:35:51 +0200

Hi Woj.

I'll be "happy" with your proposed statement somewhere in the revised WG charter.

And as for point 1, I'm happy with the agreement we have reached: 1) we are defining an application protocol, 2) it will run at some IP based transport technology now and forever!
And I'm sure we will be able - in the future work - to balance between our idealistic independent-layer-demands and our expectations about the future IP based deployment!

Cheers
Knud

> Sent: 31. marts 2006 09:20
> All clear about point 2 I think. You are saying that we must 
> address non TCP based transport and any changes this will 
> have on the L2CP protocol.
> "The working group will also evaluate L2CP transport on 
> connection and connection-less protocols, and define any 
> necessary extensions for the chosen method."
> 
> As for point 1, it does appear reasonable to have the WG 
> focus on tasks that have objectives which are practical and 
> in line with the protocols' deployment expectations. Today 
> and in the foreseeable future in effect this means IP, with 
> the pros and cons and cons that this carries. That said, we 
> are open to a discussion on some *really convincing* 
> practical or deployment reasons for why the WG should look 
> into L2CP over native L2 encaps, but until then let's leave 
> it as IP only (which hardly puts a dependency on the 
> application layer).
> 
> Regards,
> Woj.
> 
> 
> 1. (about transport independence) You are of course right, 
> L2CP will run over some IP based communication technology! 
> But as a matter of principle I don't like when defining an 
> application protocol to have stated: "IP based". (My handicap 
> is that I'm grown up with the concept of independent layers). 
> I think a tiny rephrasing of the charter about this 
> independence would satisfy me (and perhaps some other 
> fundamentalists).
> 
> 2. (about connection less) Even when you define an 
> application protocol independent of the transport protocols 
> beneath you have to decide about the expected service. The 
> important choice here is: connection-less or 
> connection-oriented service? (I assume a conn-lees protocol 
> to be able to use a conn-oriented service without any 
> changes, but not the opposite). When I stated that GSMP is 
> connection-less based, I mean GSMP is capable of running on a 
> conn-less service (like UDP). But GSMP uses this conn-less 
> service to establish a GSMP connection (called a Control 
> Channel) with keep alive monitoring and means to prevent 
> packet loss (almost like having a connection for each port?).
> But L2CP as defined to day is not able to run at a conn-less 
> service (like UDP) without changes! We have no protection 
> against packet loss (as far as I remember). Quoted from the 
> draft: "the "Event Sequence Number" should be 0". This 
> indicates that we may loss Event Messages in L2CP over UDP 
> (loss is also possible in GSMP but you have some tools to 
> recover, like Port Management Message). In L2CP you have to 
> stop and start the Control Channel to recover, when not 
> running over TCP.
> but I thing 
> bidirectional, 
> point-to-point ATM