RE: GSMPv3 and L2C

Hi Avri
 Thanks much for the response.. Please see inline..


>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>Sent: Tuesday, February 01, 2005 6:17 PM
>To: Sanjay Wadhwa
>Cc: [email protected]
>Subject: Re: [GSMP] GSMPv3 and L2C=20
>
>
>Hi,
>
>Answers in line.
>
>
>> A URL for this Internet-Draft is:
>>=20
>http://www.ietf.org/internet-drafts/draft-ietf-gsmp-v3-base-spec-06.txt
>On 30 jan 2005, at 01.50, Sanjay Wadhwa wrote:
>
>> DSL Forum is working on a protocol for interaction between=20
>> access-nodes(e.g DSLAMs) and BRAS devices (controllers in=20
>gsmp-speak)=20
>> in an atm or ethernet based access networks.
>> Avri had posted on the list the DSL forum draft on this work (L2CP -=20
>> L2 control protocol). The idea is to extend GSMPv3 to implement=20
>> requirements of the L2 control protocol.
>> In going through the current GSMP RFCs, and the DSL forum document a=20
>> couple of observations :
>>
>> 1. GSMP RFCs suggests that switch is the passive entity with respect=20
>> to tcp connectivity. The controller initiates the TCP connection. In=20
>> certain cases (e.g in L2C it makes sense to let the controller be=20
>> passive w.r.t TCP connection, and let the access-node(s)=20
>initiate TCP=20
>> connection).  Does it make sense for the GSMP spec to not=20
>require that=20
>> controller initiate the tcp connection  but keep it be open=20
>such that=20
>> this behaviour can be config driven on the devices involved. The=20
>> applicability document can capture specifics of different=20
>> applications.
>
>Unless I misremember, there is nothing in the adjacency protocol that=20
>determines that the first SYN need to be sent out by the controller as=20
>opposed to the switch.  the may be part of TCP framing method, but I=20
>don't think it is integral to the protocol  so I guess my answer is,=20
>yes, I think this could be worked out.

That is true (nothing inherent in adj. protocol).. The observation is =
based on text in rfc3293 (GSMP packet encaps for TCP)
>From RFC 3293..
4. TCP/IP Encapsulation=20
For TCP encapsulations of GSMP messages, the controller runs the client =
code and the switch runs the server code. Upon initialisation, the =
server is listening on GSMP's TCP port number: 6068. The controller =
establishes a TCP connection with each switch it manages. The switch =
under control MUST be a multi-connection server (PORT 6068) to allow =
creation of multiple control sessions from N GSMP controller instances. =
Adjacency protocol messages, which are used to synchronise the =
controller and switch and maintain handshakes, are sent by the =
controller to the switch after the TCP connection is established. GSMP =
messages other than adjacency protocol messages MUST NOT be sent until =
after the adjacency protocol has achieved synchronisation. The actual =
GSMP message flow will occur on other ports.=20


>>
>> 2. The adjacency protocol in GSMP has version number negotiation=20
>> support. Was there any discussion when GSMP was being=20
>designed to take=20
>> a more general approach to capability negotiation between the swtich=20
>> and controller (e.g  by including capability TLVs in adjacency=20
>> protocol messages) ? This helps extensibility in general.
>
>Yes, there was.  For reasons of complexity we decided to make=20
>it simply=20
>version number  negotiation (and i need to get rid of the subversion=20
>number - i have been convinced this is a bad idea ).  My operating=20
>assumption is that options are limited to a technology specific=20
>extension and we can certainly talk about it in that context.

>>
>> Will appreciate feedback (including general discussion on extending=20
>> GSMPv3 to implement L2C as specified in the DSL forum doc)...
>
>I recommend you look at draft-ietf-v3-gsmp-base-spec which=20
>contains the=20
>base modifications which i think should be the start for any=20
>changes to=20
>we make to support DSL.
>
>I have looked at the DSL doc and think the work is definitely=20
>reasonable.  I am waiting, with infinite patience, to see if there are=20
>others on this list who think so.  I currently have limited bandwidth=20
>(code words for no employer interested in paying for this work) for=20
>making changes to the protocol, though i am ready to edit the base=20
>document in my own time once people figure out what changes they need=20
>to the base.
 >As far as I can tell, we need someone to take on the task of writing=20
>the DSl specific section of the doc to go with the base protocol spec.  =

>In the writing of the DSL technology specific section we will come up=20
>with issues where the base doesn't support what is needed.  At that=20
>point I will negotiate the changes with whoever wishes to negotiate.

Thanks. That does sound like a plan.

-Sanjay


>