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  |
|
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
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  |
|
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 |
|
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 |
|
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
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 |
 rashi mittal
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 |
|
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 #1830388 is a reply to message #1830356] |
Fri, 24 July 2020 14:19 |
|
Hi , Masayuki,
port variables are , according to the standard, sort of encapsulated , and can be accessed (set ) by globally visible values( such as constants, test suite parameters), or port functions only.
I'll give you a couple of examples. Let's consider the below example, which is a variant of the SNMP translation port:
:
modulepar {
ConnectionParams tsp_connectionParams := {"127.0.0.1", 35000, "127.0.0.1", 0};
charstring tsp_shared_key:= "some_shared_key"
charstring tsp_shared_key1:= "some_other_shared_key"
}
:
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,
charstring to ASP_UDP_message with f_set_shared_key()
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
var charstring vp_shared_key:= tsp_shared_key;
} with {extension "internal"}
Mind that I have :
-marked the port as being internal to avoid using the dummy port skeleton ( see more about this in
Additional info about the usage of the translation ports
https://www.eclipse.org/forums/index.php/t/1091899/
The rest of the info here may also be interesting.
)
-added a port variable of type characterstring vp_shared_key which takes its initial value from tsp_shared_key, a new module parameter
This way the vp_shared _key is initialized.
The initial value can be overwritten with a different value when executing a translation function:
function f_enc_SNMPv1_TranslationPort
( in SNMPv1_Message pl_in,
out ASP_UDP_message pl_out) port SNMP_UDP_PT
{
vp_shared_key:= tsp_shared_key1;
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)" }
Please observe that the qualifier "port" has been added to the function, else the port variable cannot be accessed.
If you want to change the value of a port variable dynamically, you have to access it via the port mechanism. In the above example, the list of "out "
messages has been extended with the type of the variable:
:
charstring to ASP_UDP_message with f_set_shared_key()
:
where f_set_shared_key is:
//---------------------------------------------------------------------
function f_set_shared_key(in charstring p_in, out ASP_UDP_message p_out) port SNMP_UDP_PT
//---------------------------------------------------------------------
{
vp_shared_key:=p_in; //set shared key
port.setstate(4); //no output, discarded
}with {extension "prototype(fast)"}
This function will produce no output but set the value of the variable only with:
UDP_PCO_DF.send("some value that sets the variable");
I hope this answers your question.
Best regards
Elemer
[Updated on: Fri, 24 July 2020 17:04] Report message to a moderator |
|
| |
Goto Forum:
Current Time: Wed Apr 24 22:27:34 GMT 2024
Powered by FUDForum. Page generated in 0.04775 seconds |
] 
Search
Help
Register
Login
Home
