Subject: RE: [L2CP] Revised WG Charter Draft

From: Knud Gjørup (AH/LMD) <[email-masked]>
Date: Mon, 3 Apr 2006 14:40:36 +0200

Hi Robert,
 
You are not wrong, but mostly right.
Our main task when extending GSMP for new-L2CP is to define new TLVs and new service related facilities!
 
Your suggestion about enabling sequence numbering and ack in the new-L2CP application protocol (when some conn-less service is used) may work, but some people will call it: "not very nice".
It's a possibility we need to discuss and decide about in the WG.
 
The reason why I would like to revisit 1)  "the general housekeeping facilities of GSMP" is the following long and perhaps not complete and perfect list of deviations between old-GSMP and L2CP:
1         The direction of TCP session set up is changed,
2         Port-session-number, L2CP uses always 0 (zero),
3         Only one BRAS per Partition
4         No Adjacency Update Message
5         Normal L2CP packets does not function as keep alive in the Adjacency Protocol
6         Version concept changed to version and sub-version (is in accordance with the GSMP-draft)
7         DSL ports belong to one and only one Partition, and can't be split among Partitions
8         Event sequence number always == 0 (zero)
9         Transaction Id always == 0 (zero)
10     No New Port or Dead Port message
11     No way for a BRAS to find the DSLAM port configuration
(there may be more)
 
Cheers,
Knud

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 30. marts 2006 14:31
	To: Knud Gjørup (AH/LMD)
	Cc: [email-masked]; Wojciech Dec (wdec)
	Subject: RE: [L2CP] Revised WG Charter Draft

	Hi all, 
	
	I may be wrong but I see GSMP protocol with 
	     1) general housekeeping facilities (adjacency negociation, capability negotiations, keep alive polling, 
	          sequence numbers, acks etc) 
	     2) "service" related facilities using dedicated TLVs (cf port, switch, connection, etc... management) 
	          (this is where GSMP does the usefull job from operator point of view) 
	
	It looks to me that extending GSMP for L2CP boils down to extending the "service" related facilities 
	with new L2CP_TLVs. 
	
	Maybe naive from me, but I still do not see clearly what is broken in part 1) of GSMP when it would 
	come to L2CP functionality, in such a way that we need to revisit 1) too ? 
	
	Can't the genuine GSMP run on UDP or L2 ? If this would mean enabling sequence number & acking 
	 etc, can't we then just enable sequence numbering and ack  for L2CP when UDP or L2 is used ? 
	
	I appreciate anyone highlighting/correcting me ! 
	Kind regards, 
	Robert 

	
	Knud Gjørup (AH/LMD) <[email-masked]> 

03/30/2006 01:38 PM 

        To:        "Wojciech Dec \(wdec\)" <[email-masked]>, <[email-masked]> 
        cc:         
        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

	> -----Original Message-----
	> From: Wojciech Dec (wdec) [mailto:[email-masked]] 
	> Sent: 30. marts 2006 11:47
	> To: Knud Gjørup (AH/LMD); [email-masked]
	> Subject: RE: [L2CP] Revised WG Charter Draft
	> 
	> 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 
	> > 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

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 4 Apr 2006 15:23:16 -0400

I have two comments on the revised charter.

1)	At the end of the BOF, Mark Townsley limited the scope of the working group. Unfortunately, this is not captured very clearly in the meeting minutes. The critical sentence in the meeting minutes is "DSL but good engineers ...". I.e. the focus of the WG is to solve a particular issue in DSL access networks, but as good engineers we should not preclude the use of the protocol for other applications.

I don't see the limited scope reflected in the new charter.

2)	Under "Line Configuration". the charter says:

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

I don't understand how L2CP leads to fewer Radius server back end data bases. I also don't understand how L2CP avoids cross-organizational interactions. There seems to be an assumption that it is ok for L2CP to cross organizational boundaries but not for other protocols. I don't think that is correct. At the BOF, Dave Allan pointed out  that this is one of the more difficult problems to solve. Therefore, I believe that this text should be removed from the charter.

Peter

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 4 Apr 2006 21:49:34 -0400

GSMP is generic and hence has a lot by way of general  house-keeping . The approach taken thus far is to leverage whatever is required for the currently defined use-cases (for DSL access). 
On the question of extending L2C to run over unreliable transport.. UDP or over IP directly, I believe we will need to define precise protocol operations (e.g. a periodic state refresh mechanism OR ack/nack/retransmission procedures). Some of the design choices here will also depend on the requirements imposed by the use-cases. However, I agree with Robert's point.. that in providing this support, it is useful to leverage (borrow from) anything relevant that GSMP protocol provides (e.g. ability to request acks for specific messages). 
 
In response to Knud's comment,  the list below is mostly GSMP capabilities that we haven't necessarily used in L2C. Some are not very relevant to current use-cases, and some of these might be used as we define more capabilities in L2C.. e.g. support for "controller redundancy" will probably need to visit #3 and #4....#9 is already used for "remote-connectivity" (OAM) use-case..since it is request/response... #5 is an optimization best left to an implementation. 
However, if we find that some of these GSMP capabilities make sense for currently defined use-cases, don't see why we can't consider updating the usage specified in the existing L2C draft. 
 
Cheers
-Sanjay

-----Original Message-----
From: Knud Gjørup (AH/LMD) [mailto:[email-masked]]
Sent: Monday, April 03, 2006 8:41 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [L2CP] Revised WG Charter Draft

Hi Robert,

 
 
Cheers,
Knud

  _____  

Hi all, 

03/30/2006 01:38 PM 

Hi Woj

Best regards
Knud

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Wed, 5 Apr 2006 13:34:29 +0200

Hi Peter,

To address 1) we have put in the following statement in the charter
which you may have not noticed.

"The protocol design will not preclude other uses of L2CP." 

WRT 2) we do not lay any claims to how different operators structure
their data bases, and some are probably better at doing it than others.
However it does seem to be a fairly common problem that the info related
to a single subscriber's network service needs to be farmed out and fed
into numerous custom built manager systems besides also the Radius DB.
The idea is to allow a mechanism, through the use of L2CP, to have the
Access node be provided with such information as and when needed by the
NAS which in turn accesses a common repository like a Radius DB. 
Dave's statement was, I believe, in relation to different subject; that
of a wholesale-retail operation, where indeed the relationship is more
complex. However we do plan on addressing this as evidenced by the
statement in the charter:
"L2CP will address security aspects of the control protocol, including
the trust model between NAS nodes and access nodes."

Regards,
Woj.

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Sent: 04 April 2006 21:23
To: [email-masked]'
Subject: [L2CP] Re: Revised WG Charter Draft

1)	At the end of the BOF, Mark Townsley limited the scope of the
working group. Unfortunately, this is not captured very clearly in the
meeting minutes. The critical sentence in the meeting minutes is "DSL
but good engineers ...". I.e. the focus of the WG is to solve a
particular issue in DSL access networks, but as good engineers we should
not preclude the use of the protocol for other applications.

2)	Under "Line Configuration". the charter says:

> management, allowing subscriber-related service data to be maintained 

I don't understand how L2CP leads to fewer Radius server back end data
bases. I also don't understand how L2CP avoids cross-organizational
interactions. There seems to be an assumption that it is ok for L2CP to
cross organizational boundaries but not for other protocols. I don't
think that is correct. At the BOF, Dave Allan pointed out  that this is
one of the more difficult problems to solve. Therefore, I believe that
this text should be removed from the charter.

Peter

---

From: "Voigt, Norbert" <[email-masked]>
Date: Thu, 6 Apr 2006 14:21:42 +0200

Hi Wojciech,
I'm quite comfortable with the changes after the BOF session.
There is one highly desired goal and that's accordance with DSLF scope (in that context).
I guess it's hardly to achieve as well, but we should start using the same wording, e.g. the names of the use cases. Please check the revised version of WT-147 (dslf2006.147.01 from March 17th) that reflects the agreed scope and wording. Do you think this would be feasible?

Regards,
Norbert.

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Montag, 27. März 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)------------------------

Chair(s):
Matthew Bocci ([email-masked])
Wojciech Dec  ([email-masked])

Technical Advisor(s):
TBD <tbd>

Secretary(ies):
TBD <tbd>

Mailing Lists:

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.

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

deployment of Ethernet in the aggregation network, operators require
Ethernet and ATM access networks (including the local loop). L2CP will

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

Goals and Milestones:

Internet-Drafts:

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Thu, 6 Apr 2006 15:09:47 +0200

Hi Norbert,

I hear you, however it's quite clear that the protocol is not to be tied at the hip solely to the DSLF work, allowing it to be used in other scenarios. Also the terms used by the DSLF have other more established equivalents in the IETF (eg NAS). Hence, I'd rather go along with what we have in the charter, which addresses the DSLF needs and has been reviewed and understood, rather then re-wording the whole thing and going through more churn. 

Going forward, we see liaisons between the DSLF and IETF, besides joint participant attendance, as key to addressing changing needs for the protocol but it will be solely the IETF WG's task to do the protocol spec and extensions (within the boundaries of the current charter).

Regards,
Woj.

-----Original Message-----
From: Voigt, Norbert [mailto:[email-masked]] 
Sent: 06 April 2006 14:22
To: Wojciech Dec (wdec)
Cc: [email-masked]
Subject: RE: [L2CP] Revised WG Charter Draft

Hi Wojciech,

Regards,
Norbert.

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: Montag, 27. März 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)------------------------

Chair(s):
Matthew Bocci ([email-masked]) Wojciech Dec  ([email-masked])

Technical Advisor(s):
TBD <tbd>

Secretary(ies):
TBD <tbd>

Mailing Lists:

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.

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

Internet-Drafts:

---

From: "Voigt, Norbert" <[email-masked]>
Date: Thu, 6 Apr 2006 15:29:21 +0200

Hi Wojciech,
It's quite clear to me as well. I didn't want you to re-word the whole charter, just wanted to make our life easier when talking about the same thing, e.g. use case. But you're right, DSLF needs are addressed. Staying consistent is a matter of liaisons and will mainly be achieved by joint participant attendance.
Cheers,
Norbert.

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Donnerstag, 6. April 2006 15:10
To: Voigt, Norbert
Cc: [email-masked]
Subject: RE: [L2CP] Revised WG Charter Draft

Hi Norbert,

Regards,
Woj.

-----Original Message-----
From: Voigt, Norbert [mailto:[email-masked]] 
Sent: 06 April 2006 14:22
To: Wojciech Dec (wdec)
Cc: [email-masked]
Subject: RE: [L2CP] Revised WG Charter Draft

Hi Wojciech,

Regards,
Norbert.

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: Montag, 27. März 2006 16:15
To: [email-masked]
Subject: [L2CP] Revised WG Charter Draft

Hello All,

Regards,
Woj.

-------------------WG CHARTER (DRAFT)------------------------

Chair(s):

Technical Advisor(s):
TBD <tbd>

Secretary(ies):
TBD <tbd>

Mailing Lists:

- Access Link Discovery

- Line Configuration

- Multicast

Goals and Milestones:

Internet-Drafts: