RE: [L2CP] Revised WG Charter Draft

[Knud Gjørup (AH/LMD) <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
	Sent: 30. marts 2006 14:31
	To: Knud Gjørup (AH/LMD)
	Cc: [e-mail]; 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) <[e-mail]> 

03/30/2006 01:38 PM 

        
        To:        "Wojciech Dec \(wdec\)" <[e-mail]>, <[e-mail]> 
        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:[e-mail]] 
	> Sent: 30. marts 2006 11:47
	> To: Knud Gjørup (AH/LMD); [e-mail]
	> 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:[e-mail]]
	> Sent: 29 March 2006 13:50
	> To: Wojciech Dec (wdec); [e-mail]
	> 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:[e-mail]]
	> > Sent: 27. marts 2006 16:15
	> > To: [e-mail]
	> > 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 ([e-mail]) Wojciech Dec
	> > ([e-mail])
	> > 
	> > Internet Area Director(s):
	> > Mark Townsley <[e-mail]>
	> > Jari Arkko <[e-mail]>
	> > 
	> > Technical Advisor(s):
	> > TBD <tbd>
	> > 
	> > Secretary(ies):
	> > TBD <tbd>
	> > 
	> > Area Specific Mailing List:
	> > [e-mail]
	> > 
	> > Mailing Lists:
	> > General Discussion: [e-mail]
	> > To Subscribe: [e-mail]
	> > 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
	> > [e-mail]
	> > https://www1.ietf.org/mailman/listinfo/l2cp
	> > 
	> 
	
	_______________________________________________
	L2cp mailing list
	[e-mail]
	https://www1.ietf.org/mailman/listinfo/l2cp
	
	

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