Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Translation ports vs dual-faced ports part1(SNMP over UDP with translation port)
Translation ports vs dual-faced ports part1 [message #1761456] Thu, 11 May 2017 09:47 Go to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Dear all,


We have discussed at length the reasons to use dual-faced ports, for example here:

Dual-faced test ports: architectural considerations
https://www.eclipse.org/forums/index.php/t/1078877/


Dual faced ports are an early implementation of translation ports as described in

The Testing and Test Control Notation version 3;
TTCN-3 Language Extensions:
Configuration and Deployment Support
5.2 Ports with translation capability



Translation ports (or "ports with translation capability" but I will simply call them translation ports as both your and my time is valuable)
have the same use cases, and the standard describes a sleeker, easier to understand, more feature-rich concept than what has been implemented for dual-faced ports.
So we have decided to implement the standard translation ports, at least partially.
Mind you, the dual-faced ports will continue to be supported and can be used in parallel or as an alternative with translation ports.
Support is present starting from Titan 6.2.0.


First let's see the limitations of the implementation:

type port PortTypeIdmessage
[map to{OuterPortType[","]}+ ]
[connect to {OuterPortType[","]}+]"{"
{
(in{InnerInType [from {OuterInType with InFunction"("")"[","]}+][","]}+|
out{InnerOutType[to {OuterOutType with OutFunction"("")"[","]}+ ][","]}+ |
inout{InOutType[","]}+ |
address AddrType [to {OuterAddrTypewith AddrOutFunction"("")"[","]}+ ]
[from { OuterAddrTypewith AddrInFunction"("")"[","]}+ ] |
map param "("{FormalValuePar [","] }+ ")"|
unmap param "("{ FormalValuePar [","] }+ ")" |

VarInstance) ";"
}+
"}"

The underlined parts are not implemented.

For a detailed description of limitations see ref.guide 4.35 Ports with translation capability.

A new element is the presence of port variables/constants in the port declaration. These variables can be used in and their scope is limited to functions having a port clause that connects them to the port where variables have been declared. Some examples of uses of port variables:
module PortVariables {

	type record of integer RoI;

	type port VP1 message {
		out integer, charstring, RoI;
		in integer, charstring, RoI;
	} with {
		extension "provider"
	}

	type port NVP1 message map to VP1 {
		out charstring to integer with char_to_default_int_template() : charstring with char_to_default_char() : charstring with char_to_default_const_char() : RoI with char_to_default_roi() : integer with char_to_int();
		in integer, charstring, RoI;
//port declaration contains port variable declarations:
		const charstring c_cs := "DefaultConst"
		var charstring cs := "Default";
		var template integer i := 3;
		var template RoI roi := {1,2,3};
		var integer num;
	}

	function char_to_default_int_template(in charstring input, out integer output) port NVP1 {
		if (input == "int template") {
			output := valueof(i);
			port.setstate(0);
			i := 666;
		} else {
			port.setstate(1);
		}
	} with {
		extension "prototype(fast)";
	}
:
:
	
}


As a complete usage example I will re-use some dual-face port examples published earlier that have been adapted to a translation port.

Let's start with:

Example of SNMP over UDP(Example of SNMP over UDP with ASN.1 and dual-faced test port)
https://www.eclipse.org/forums/index.php/t/1068184/

The main component sends an SNMP message to the translation(earlier dual-faced ) port
which translates it to a UDP message and sends it to the single parallel component which does nothing else but echoes it back.
The translation port receives the echo, decodes it and decides whether it is the expected structure or not.

Here's the declaration of the translation port:

type port SNMP_UDP_PT message map to UDPasp_PT //Translation port
{
 out 
     SNMPv1_Message to ASP_UDP_message with f_enc_SNMPv1_TranslationPort(),
     SNMPv2_Message to ASP_UDP_message with f_enc_SNMPv2_TranslationPort(),
     SNMPv3_Message to ASP_UDP_message with f_enc_SNMPv3_TranslationPort(),
     ASP_UDP_open,
     ASP_UDP_close      
 in      
     SNMPv1_Message from ASP_UDP_message with f_dec_SNMPv1_TranslationPort(),
     SNMPv2_Message from ASP_UDP_message with f_dec_SNMPv2_TranslationPort(),
     SNMPv3_Message from ASP_UDP_message with f_dec_SNMPv3_TranslationPort(),
     ASP_UDP_open_result 
  inout ASP_UDP         
}  



and here's the earlier declaration of the dual-faced port with the same functionality:

type port SNMP_UDP_PT message  //DualFace port
{
 out 
     SNMPv1_Message,
     SNMPv2_Message,
     SNMPv3_Message,
     ASP_UDP_open,
     ASP_UDP_close      
 in      
     SNMPv1_Message,
     SNMPv2_Message,
     SNMPv3_Message,
     ASP_UDP_open_result          
}with 
{ extension 
   "user UDPasp_PT
      out(
        SNMPv1_Message -> ASP_UDP_message: function(f_enc_SNMPv1_DualFace);
        SNMPv2_Message -> ASP_UDP_message: function(f_enc_SNMPv2_DualFace);
        SNMPv3_Message -> ASP_UDP_message: function(f_enc_SNMPv3_DualFace);
        ASP_UDP_open   -> ASP_UDP_open  : simple;        
        ASP_UDP_close  -> ASP_UDP_close  : simple       	
    )    
      in(
        ASP_UDP_message ->  SNMPv1_Message : function(f_dec_SNMPv1_DualFace),
	                        SNMPv2_Message : function(f_dec_SNMPv2_DualFace),
	                        SNMPv3_Message : function(f_dec_SNMPv3_DualFace);
	    ASP_UDP    ->       -              : discard;           
        ASP_UDP_open_result -> ASP_UDP_open_result : simple
    )
   " 
   
}



and here you have one of the port functions after and before:
function f_enc_SNMPv1_TranslationPort
( in SNMPv1_Message pl_in,
  out ASP_UDP_message pl_out)
{
  pl_out.id := 0;
  pl_out.data := enc_SNMPv1_Message(pl_in);         
  pl_out.remote_addr := tsp_connectionParams.remHost; 
  pl_out.remote_port := tsp_connectionParams.remPort;
  port.setstate(0);
   
}with {extension "prototype(fast)" } 




function f_enc_SNMPv1_DualFace
( in SNMPv1_Message pl_in,
  out ASP_UDP_message pl_out) return integer
{
  pl_out.id := 0;
  pl_out.data := enc_SNMPv1_Message(pl_in);         
  pl_out.remote_addr := tsp_connectionParams.remHost; 
  pl_out.remote_port := tsp_connectionParams.remPort;
    
  return 0;
}with {extension "prototype(backtrack)" }


The code and logs are attached for your perusing pleasure.


To use the attached code, please extract it to a directory named e.g SNMP, followed by :

cd SNMP/bin
../install.script 
make

ttcn3_start ./SNMP  SNMP.cfg 



A difference compared with the dual faced test ports is that the ports with translation capability can work in two modes, in normal mode and in translation mode. In normal mode, the port behaves as a standard messaging port, while in translation mode it works as it is defined in the ES 202 781 standard clause 5.2 ([21]).
A test port skeleton must be generated for the port type with the translation capability, to ensure that the port can work in both modes.
When used in standard mode, the skeleton has to be replaced by a real test port.


This is the part of the standard that exemplifies dual usage:

typeport TransportPort {
 ...
 }
type portDataPort map to TransportPort {
 ...
 }
typecomponent SystemComponent{
 portDataPort dataPort;
 portTransportPort transportPort;
 }
type component TestComponent{
 port DataPort dataPort;
 }
testcase TC runson TestComponent system SystemComponent
 {
 if (PX_TRANSPORT_USED){
 // activate translation mode (TransportPort is implicitly referenced via transportPort
 // in the map operation)
 map(mtc:dataPort, system:transportPort);
 }
 else{
 // activate normal mode (TransportPort is not referenced in the map operation)
 map(mtc:dataPort, system:dataPort);
 }
 } 



The port skeleton files are:

 SNMP_UDP_PT.cc
 SNMP_UDP_PT.hh


They are contained in the package and have been generated with

compiler -t *.ttcn *.asn


issued in bin, after creating symlinks with install.script
and they have to be made part of the compilation.
( added to install.script, Makefile etc.)


Best regards

Elemer

Re: Translation ports vs dual-faced ports part1 [message #1769811 is a reply to message #1761456] Thu, 03 August 2017 14:59 Go to previous messageGo to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 48
Registered: July 2017
Location: Berlin, Germany
Member

I'm trying to do something similar but not based on the (older? deprecated?) UDPasp_PT, but using the IPL4asp_PT and stacking a Translation Port on top.

However, I seem to be unable to make the related functions (f_IPL4_listen, f_IPL4_connect, ...) work. I cannot pass the translated port type (in my case GTPC_PT) to the functions, as this results in a type mismatch:
     GTP_CodecPort.ttcn:81.24-30: error: Type mismatch: Reference to a port or port parameter of type `@IPL4asp_PortType.IPL4asp_PT' was expected instead of `@GTP_CodecPort.GTPC_PT'


And if I want to write wrapper control functions in C++ (like the IPL4asp_demo does in IPL4_SIP_CtrlFunctDef.cc), then it doesn't work either. This time not the TTCN3-compiler is complaining, but the C++ compiler:

GTP_CodecPort_CtrlFunctDef.cc: In function 'IPL4asp__Types::Result GTP__CodecPort__CtrlFunct::f__IPL4__listen(GTP__CodecPort::GTPC__PT&, const HostName&, const PortNumber&, const ProtoTuple&, const IPL4asp__Types::OptionList&)':
GTP_CodecPort_CtrlFunctDef.cc:17:79: error: 'f__IPL4__PROVIDER__listen' was not declared in this scope
     return f__IPL4__PROVIDER__listen(portRef, locName, locPort, proto, options);


Using the same translation functions with a Dual-Faced port works. But how can I get this to work with a TranslationPort?
Re: Translation ports vs dual-faced ports part1 [message #1769814 is a reply to message #1769811] Thu, 03 August 2017 15:20 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Harald,

have you checked this?

https://www.eclipse.org/forums/index.php/t/1086422/

I'm working on better examples but this is a translation port with IPL4 as southern interface.

One piece of info that is important and may not be apparent:
assuming you have your components as below:

type component GTPCodecComp
{
  port GTP_CodecPortType  GTP_CodecPort 
:

}


type component SystemComp
{
   port IPL4asp_PT IPL4_PCO;
} 



where translation is from GTP_CodecPort to IPL4_PCO and viceversa

In the config file , the parameters should refer to system.IPL4_PCO:

as in:
[TESTPORT_PARAMETERS]

system.IPL4_PCO.debug := "Yes" 


(and not *.GTP_CodecPort or anything else)

else they will not be considered.

So you need to:

-write the translation port definitions/functions
-edit IPL4asp_User_CtrlFunct.ttcn, IPL4asp_User_CtrlFunctDef.cc as detailed
-generate the translation port skeleton (I'll try to get rid of this step eventually...)
-take care of config

If it still resists, I'll prepare a tailored example.

Best regards
Elemer
Re: Translation ports vs dual-faced ports part1 [message #1769862 is a reply to message #1769814] Fri, 04 August 2017 09:31 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Harald,

OK, I have downloaded your code and made the following changes:

-I have rewritten the dual-faced definitions to translation ports as below:


/* dual-faced port sitting on top of IPL4_asp UDP to encode/decode GTP */
/* (C) 2017 by Harald Welte <laforge@gnumonks.org */
module GTP_CodecPort {
	import from IPL4asp_PortType all;
	import from IPL4asp_Types all;
	import from GTPC_Types all;
	import from GTPU_Types all;

	/* identifies a remote peer (sender or receiver) */
	type record GtpPeer {
		ConnectionId	connId,
		HostName	remName,
		PortNumber	remPort
	}

	/* Decoded GTP1C (Control Plane), used in send and receive direction */
	type record Gtp1cUnitdata {
		GtpPeer		peer,
		PDU_GTPC	gtpc
	}

	/* Decoded GTP1U (User Plane), used in send and receive direction */
	type record Gtp1uUnitdata {
		GtpPeer		peer,
		PDU_GTPU	gtpu
	}

 	/* Translation port on top of IPL4asp; ASP_Event passed through transparently */
/*	type port GTPC_PT message {
		out	Gtp1cUnitdata;
		in	Gtp1cUnitdata,
			ASP_Event;
	} with { extension "user IPL4asp_PT
		out(Gtp1cUnitdata -> ASP_SendTo: function(f_enc_Gtp1cUD))
		in(ASP_RecvFrom -> Gtp1cUnitdata: function(f_dec_Gtp1cUD);
		   ASP_Event -> ASP_Event: simple)" }

*/
 
type port GTPC_PT message  map to IPL4asp_PT //Translation port
{
 out 
    Gtp1cUnitdata  to ASP_SendTo   with f_enc_Gtp1cUD()
 in
    Gtp1cUnitdata      from ASP_RecvFrom with f_dec_Gtp1cUD(),
      ASP_Event   
     
}




	 private function f_enc_Gtp1cUD(in Gtp1cUnitdata in_ud, out ASP_SendTo out_ud) port GTPC_PT {
		out_ud.connId := in_ud.peer.connId;
		out_ud.remName := in_ud.peer.remName;
		out_ud.remPort := in_ud.peer.remPort;
		out_ud.proto := { udp := {} };
		out_ud.msg := enc_PDU_GTPC(in_ud.gtpc);
                 port.setstate(0);
	} with { extension "prototype(fast)" };

	private function f_dec_Gtp1cUD(in ASP_RecvFrom in_ud, out Gtp1cUnitdata out_ud) port GTPC_PT {
		out_ud.peer.connId := in_ud.connId;
		out_ud.peer.remName := in_ud.remName;
		out_ud.peer.remPort := in_ud.remPort;
		out_ud.gtpc := dec_PDU_GTPC(in_ud.msg);
             port.setstate(0);    
	} with { extension "prototype(fast)" };


	/* dual-faced port on top of IPL4asp; ASP_Event passed through transparently */
/*	type port GTPU_PT message {
		out	Gtp1uUnitdata;
		in	Gtp1uUnitdata,
			ASP_Event;
	} with { extension "user IPL4asp_PT
		out(Gtp1uUnitdata -> ASP_SendTo: function(f_enc_Gtp1uUD))
		in(ASP_RecvFrom -> Gtp1uUnitdata: function(f_dec_Gtp1uUD);
		   ASP_Event -> ASP_Event: simple)" }
*/

type port GTPU_PT message  map to IPL4asp_PT //Translation port
{
 out 
    Gtp1uUnitdata  to ASP_SendTo   with f_enc_Gtp1uUD()
 in
    Gtp1uUnitdata      from ASP_RecvFrom with f_dec_Gtp1uUD(),
      ASP_Event   
       
}





	function f_enc_Gtp1uUD(in Gtp1uUnitdata in_ud, out ASP_SendTo out_ud) port GTPU_PT{
		out_ud.connId := in_ud.peer.connId;
		out_ud.remName := in_ud.peer.remName;
		out_ud.remPort := in_ud.peer.remPort;
		out_ud.proto := { udp := {} };
		out_ud.msg := enc_PDU_GTPU(in_ud.gtpu);
   		port.setstate(0);   
	} with { extension "prototype(fast)" };

	function f_dec_Gtp1uUD(in ASP_RecvFrom in_ud, out Gtp1uUnitdata out_ud) port GTPU_PT {
		out_ud.peer.connId := in_ud.connId;
		out_ud.peer.remName := in_ud.remName;
		out_ud.peer.remPort := in_ud.remPort;
		out_ud.gtpu := dec_PDU_GTPU(in_ud.msg);
 	  	port.setstate(0);   
	} with { extension "prototype(fast)" };

}


- I could now generate the skeletons for GTPC_PT, GTPU_PT with
compiler -t *.ttcn



see archive attached

-I have renamed GTP_CodecPort_CtrlFunct.ttcn and GTP_CodecPort_CtrlFunctDef.cc to
IPL4asp_User_CtrlFunct.ttcn and IPL4asp_User_CtrlFunctDef.cc
(I'm a bit uncertain here but I believe these names ought to be kept: I'll have to ask someone smarter than me)

-I have also changed their content based on the SNMP_IPL4 example quoted above (please mind that IPL4asp_User_CtrlFunctDef.cc in this example differs from the one published in the test port)


I'm sorry , I'm aware this part is even more poorly documented then the average of our stuff; this is a new feature; we are trying to catch up with the documentation.


-I have also added the system component in GGSN_Tests.ttcn for the reasons above(config file):


 type component SystemComp
{
   port IPL4asp_PT IPL4_PCO;
} 



and also made some small changes to follow the changes in the other files.


I have attached the compressed file containing the project (obtained with make archive);

It does compile on this end; I hope it will work on your side as well.

Best regards

Elemer

Re: Translation ports vs dual-faced ports part1 [message #1775444 is a reply to message #1769862] Mon, 30 October 2017 09:19 Go to previous messageGo to next message
rashi mittal is currently offline rashi mittalFriend
Messages: 2
Registered: October 2017
Junior Member
Hi ,

I tried to simulate the same thing from my end .I need to create the connection between the SSGN and GGSN for creating he PDP request.

I downloaded the attached code GGSN test but I facing errors related to mapping of port .

Apart from this I used attached code .

I am getting error "Dynamic test case error: Assignment of an unbound octetstring value to a template. (Transport endpoint is not connected),"

Can you please help me know about what will be the values of
charstring m_bind_ip_gtpc := "127.23.42.1";
charstring m_bind_ip_gtpu := "127.23.42.1";
charstring m_ggsn_ip_gtpc := "127.0.0.6";
charstring m_ggsn_ip_gtpu := "127.0.0.6";

ANd what configuration is required to set up the connection between TTCN server ,GGSN and SGSN.

I need to simulate Packet Gateway for 2g/3G n/w.

I am attaching code and TTCN logs .

[Updated on: Tue, 31 October 2017 04:01]

Report message to a moderator

Re: Translation ports vs dual-faced ports part1 [message #1775463 is a reply to message #1775444] Mon, 30 October 2017 13:36 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Rashi,

I see several problems with your attachment:

-first of all, as SourceInfoFormat is set to None, the lines numbers of the executed TTCN-3 code cannot be seen in the log
-the config file is not attached , so initial config parameters are unknown
-the logfile does not seem to tally with the attached code:

for example the log says "Executing test case TC006_GGSN_Test in module TS991_XRASMIT"
but there is no module TS991XRASMIT and no test case TC006_GGSN_Test in the attached code

-finally, whom you expect to know better than yourself your local addresses and stuff?

Please find someone in your surroundings to help you.

BR

Elemer

Re: Translation ports vs dual-faced ports part1 [message #1775554 is a reply to message #1775463] Wed, 01 November 2017 03:48 Go to previous messageGo to next message
rashi mittal is currently offline rashi mittalFriend
Messages: 2
Registered: October 2017
Junior Member
Hi Elemer,

Thanks for the reply .

I just want to know what the significance of these variable

Charstring m_bind_ip_gtpc := "127.23.42.1"; ( IP address of TTCCN server)
charstring m_bind_ip_gtpu := "127.23.42.1"; ( IP address of TTCCN server)
charstring m_ggsn_ip_gtpc := "127.0.0.6"; ( IP address of GGSN server) or any realm of ggsn defined
charstring m_ggsn_ip_gtpu := "127.0.0.6";

As you mentioned in the below comment i need to ask with local team ,for this I need to understand what is main significance of these variable .SO that I can ask with my local IT team to configure in GGSN server/TTCN server.

Re: Translation ports vs dual-faced ports part1 [message #1775802 is a reply to message #1775554] Mon, 06 November 2017 16:07 Go to previous message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Rashi,

All right.

Could you please explain me what are you trying to do here?

Previous Topic:Is it possible to write Bsc/Msc diplomas related to Titan?
Next Topic:Writing test port, incoming_message
Goto Forum:
  


Current Time: Wed Sep 19 20:58:43 GMT 2018

Powered by FUDForum. Page generated in 0.02229 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top