Subject: Re: [GSMP] GSMPv3 and L2C

From: [email-masked]
Date: Tue, 1 Feb 2005 15:16:40 -0800

Hi,

Answers in line.

> A URL for this Internet-Draft is:
> 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 
> access-nodes(e.g DSLAMs) and BRAS devices (controllers in gsmp-speak) 
> in an atm or ethernet based access networks.
> Avri had posted on the list the DSL forum draft on this work (L2CP - 
> L2 control protocol). The idea is to extend GSMPv3 to implement 
> requirements of the L2 control protocol.
> In going through the current GSMP RFCs, and the DSL forum document a 
> couple of observations :
>
> 1. GSMP RFCs suggests that switch is the passive entity with respect 
> to tcp connectivity. The controller initiates the TCP connection. In 
> certain cases (e.g in L2C it makes sense to let the controller be 
> passive w.r.t TCP connection, and let the access-node(s) initiate TCP 
> connection).  Does it make sense for the GSMP spec to not require that 
> controller initiate the tcp connection  but keep it be open such that 
> this behaviour can be config driven on the devices involved. The 
> applicability document can capture specifics of different 
> applications.

Unless I misremember, there is nothing in the adjacency protocol that 
determines that the first SYN need to be sent out by the controller as 
opposed to the switch.  the may be part of TCP framing method, but I 
don't think it is integral to the protocol  so I guess my answer is, 
yes, I think this could be worked out.

>
> 2. The adjacency protocol in GSMP has version number negotiation 
> support. Was there any discussion when GSMP was being designed to take 
> a more general approach to capability negotiation between the swtich 
> and controller (e.g  by including capability TLVs in adjacency 
> protocol messages) ? This helps extensibility in general.

Yes, there was.  For reasons of complexity we decided to make it simply 
version number  negotiation (and i need to get rid of the subversion 
number - i have been convinced this is a bad idea ).  My operating 
assumption is that options are limited to a technology specific 
extension and we can certainly talk about it in that context.

>
> Will appreciate feedback (including general discussion on extending 
> GSMPv3 to implement L2C as specified in the DSL forum doc)...

I recommend you look at draft-ietf-v3-gsmp-base-spec which contains the 
base modifications which i think should be the start for any changes to 
we make to support DSL.

I have looked at the DSL doc and think the work is definitely 
reasonable.  I am waiting, with infinite patience, to see if there are 
others on this list who think so.  I currently have limited bandwidth 
(code words for no employer interested in paying for this work) for 
making changes to the protocol, though i am ready to edit the base 
document in my own time once people figure out what changes they need 
to the base.

As far as I can tell, we need someone to take on the task of writing 
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 
with issues where the base doesn't support what is needed.  At that 
point I will negotiate the changes with whoever wishes to negotiate.

cheers,

a.

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Wed, 2 Feb 2005 09:00:31 -0500

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

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 01, 2005 6:17 PM
>To: Sanjay Wadhwa
>Cc: [email-masked]
>Subject: Re: [GSMP] GSMPv3 and L2C 
>
>
>Hi,
>
>Answers in line.
>
>

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

>point I will negotiate the changes with whoever wishes to negotiate.

Thanks. That does sound like a plan.

-Sanjay