Thought of the day: was RE: Gen_server and Gen_fsm questions

[Vance Shipley]

Joe,

I've spent a lot of time in the last year and a half with the OSI 
protocols for telecom.  The RPC is TCAP which is based on ROSE.
It can be quite a but more complicated than you describe.  ROSE
supports things like:

	- selecting a specific application (beyond a 1:1 mapping with port)
	- dynamic negotiation of protocol encoding
	- an ongoing dialogue (e.g. request->,<-request,reply->,<-reply)
	- corelation between transactions
	- timers, aborts, rejects, etc.

My experience in protocol interworking tells me that to have full
interoperability you need to support the capabilities of the most
complex protocol in your interworking protocol.  So you would need
to make a list of all the RPCs which would be supported and work
back from there building a new Erlang term based protocol which 
would handle interworking.  Not that I expect this to happen.

I do have this related suggestion:

In OSI protocols like those within the SS7 protocol suite (MTP, SCCP,
TCAP, MAP, etc.) the specifications define the service access points
between layers using "service primitives".  These are conceptual
devices and do not specify a particular form (e.g. a C structure
argument to a function call, a socket based RPC, etc.).  What they do
define is the purpose of the message, the possible senders and receivers
and the mandatory and optional parameters.  The parameters have a 
defined encoding but how they are packaged to form a service primitive
is an implementation matter.

I have chosen the following form:

	SAP ! {Layer, GenericName, SpecificName, Parameters}

	Layer = 'MTP' | 'SCCP' | 'N' | 'TR' | 'TC' | 'MAP'
	GenericName = atom() specific to protocol
	SpecificName = request | indication | response | confirmation
	Parameters = term() specific to message

Service Access Points (SAP) should be implemented as erlang message
sink/source points using these forms.  This is a fairly obvious mapping
actually.  Examples from TCAP:

TC-User -> TC-SAP

	{'TC', 'UNI', request, Parms}
	{'TC', 'BEGIN', request, Parms}
	{'TC', 'CONTINUE', request, Parms}
	{'TC', 'END', request, Parms}
	{'TC', 'U-ABORT', request, Parm

TC-SAP -> TC-User

	{'TC', 'UNI', indication, Parms}
	{'TC', 'BEGIN', indication, Parms}
	{'TC', 'END', indication, Parms}
	{'TC', 'NOTICE', indication, Parms}
	{'TC', 'U-ABORT', indication, Parms}
	{'TC', 'P-ABORT', indication, Parms}

Now if whoever is working on another peice of this puzzle uses the
same form of service primitives we can have nicely interoperable
protocol applications.  :)

	-Vance