ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005224 | Ext Pack: Config & Deployment Support (ES 202 781) | New Feature | public | 03-06-2009 10:22 | 14-05-2013 15:24

Reporter | Gyorgy Rethy |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v1.2.1 (published 2013-06) | Fixed in Version | v1.2.1 (published 2013-06) |
Clause Reference(s) | new
Source (company - Author) | L.M.Ericsson
TS version |

Summary | 0005224: Introducing dual faced ports

Description

Real testing projects very oftem meats the problem that the same ATS shall be used in different test environments, i.e. the SUT is embedded in a simulated HW/OS environment during functional testing and using the real HW/OS in integration testing. These test environments normally require different adapters and most often even the adapter interface (TTCN-3 ports) does differ. A similar situation arise, when the same message sequence has to be moved from one type of interface to another (e.g. from MTP to SCTP). Today, to prevent re-writing the test cases themselves, so called mapping components are used. Mapping components are receiving messages from the "behaviour" components on their "upper" ports, map the information to the "down" port type and sends them; and vice versa in the opposite direction. This approach has several problems: in complex systems, where the number of "behaviour" TCs is n*10, it boosts the number of test components; this increases development and maintenance cost; complicates debugging and log analysis by producing a lots of extra logs.
The proposal is to introduce "dual faced" TTCN-3 test ports, where the "upper" port definition is the one seen by TTCN-3 connect, map and communication operations, and the "down" port is the one seen by the adaptor. If the two differ, a set of conversion functions shall be defined that makes the mapping between the types in the upper and down ports. These functions are called implicitly by the TE at receving/sending operations.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0005417 | closed | Ina Schieferdecker | Part 01: TTCN-3 Core Language | Support of parametrized map/unmap operation for full dynamic mapping

Attached Files

CR 5224 proposal.txt (6,461) 01-09-2010 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2420&type=bug
CR 5224.txt (7,722) 01-12-2010 16:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2459&type=bug
CR_5224-proposal.doc (1,868,288) 28-09-2011 16:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2569&type=bug
CR_5224-proposal_v2.zip (675,597) 29-11-2011 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2609&type=bug
CR_5224-proposal_v3.zip (662,682) 30-11-2011 17:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2625&type=bug
CR_5224-proposal_v4.docx (950,480) 01-12-2011 09:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2633&type=bug
CR_5224-proposal_v5.docx (878,561) 01-12-2011 09:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2634&type=bug
CR_5224-proposal_v6.docx (976,987) 10-08-2012 14:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2721&type=bug
CR_5224-proposal_v6_BNFmodified.docx (36,809) 10-12-2012 11:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2756&type=bug
CR_5224-proposal_v7.docx (997,629) 10-12-2012 16:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2760&type=bug
CR_5224-proposal_v8_delta.docx (72,080) 12-12-2012 15:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2773&type=bug
CR_5224-proposal_v9_delta.docx (129,295) 13-12-2012 08:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2776&type=bug
CR_5224-proposal_v10.docx (138,537) 13-12-2012 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2777&type=bug
CR_5224-proposal_v11.docx (78,102) 18-12-2012 16:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2788&type=bug

Issue History
Date Modified | Username | Field | Change
03-06-2009 10:22 | Gyorgy Rethy | New Issue |
03-06-2009 10:22 | Gyorgy Rethy | Status | new => assigned
03-06-2009 10:22 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
03-06-2009 10:22 | Gyorgy Rethy | Clause Reference(s) | => new
03-06-2009 10:22 | Gyorgy Rethy | Source (company - Author) | => L.M.Ericsson
09-12-2009 13:52 | Ina Schieferdecker | Note Added: 0009117 |
09-12-2009 13:53 | Ina Schieferdecker | Target Version | => Edition 5.1.1 (not yet published)
04-01-2010 13:52 | Ina Schieferdecker | Relationship added | related to 0005417
22-03-2010 17:21 | Gyorgy Rethy | Assigned To | Ina Schieferdecker =>
22-03-2010 17:21 | Gyorgy Rethy | Status | assigned => new
23-03-2010 12:55 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
23-03-2010 12:55 | Gyorgy Rethy | Priority | normal => low
23-03-2010 12:55 | Gyorgy Rethy | Status | new => assigned
23-03-2010 16:06 | Jacob Wieland - Spirent | Note Added: 0009266 |
24-03-2010 18:34 | Jacob Wieland - Spirent | File Added: CR 5224 proposal.txt |
24-03-2010 18:37 | Jacob Wieland - Spirent | Note Added: 0009290 |
24-03-2010 18:37 | Jacob Wieland - Spirent | Status | assigned => feedback
24-03-2010 20:16 | Jacob Wieland - Spirent | File Deleted: CR 5224 proposal.txt |
24-03-2010 20:16 | Jacob Wieland - Spirent | Status | feedback => assigned
25-03-2010 00:24 | Jacob Wieland - Spirent | File Added: CR 5224 proposal.txt |
25-03-2010 00:25 | Jacob Wieland - Spirent | Status | assigned => feedback
25-03-2010 08:16 | Jacob Wieland - Spirent | File Deleted: CR 5224 proposal.txt |
25-03-2010 08:27 | Jacob Wieland - Spirent | File Added: CR 5224 proposal.txt |
26-03-2010 09:39 | Gyorgy Rethy | Status | feedback => assigned
26-03-2010 09:40 | Gyorgy Rethy | Note Added: 0009320 |
01-07-2010 09:55 | Gyorgy Rethy | Note Added: 0009442 |
01-07-2010 11:31 | Jacob Wieland - Spirent | Note Added: 0009447 |
01-09-2010 09:54 | Jacob Wieland - Spirent | File Deleted: CR 5224 proposal.txt |
01-09-2010 09:55 | Jacob Wieland - Spirent | File Added: CR 5224 proposal.txt |
01-09-2010 11:05 | Jens Grabowski | Note Added: 0009670 |
02-09-2010 14:13 | Jacob Wieland - Spirent | Note Added: 0009699 |
02-09-2010 18:13 | Jacob Wieland - Spirent | Note Added: 0009703 |
03-09-2010 10:59 | Jacob Wieland - Spirent | Note Added: 0009707 |
03-09-2010 11:03 | Jacob Wieland - Spirent | Note Edited: 0009707 |
03-09-2010 11:10 | Jacob Wieland - Spirent | Note Edited: 0009699 |
29-11-2010 16:22 | Jacob Wieland - Spirent | Note Added: 0009833 |
29-11-2010 16:28 | Jacob Wieland - Spirent | Note Added: 0009834 |
30-11-2010 13:23 | Gyorgy Rethy | Note Added: 0009841 |
01-12-2010 16:30 | Jacob Wieland - Spirent | File Added: CR 5224.txt |
01-12-2010 16:31 | Jacob Wieland - Spirent | Note Added: 0009902 |
01-12-2010 16:31 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
03-12-2010 10:15 | Gyorgy Rethy | Project | Part 01: TTCN-3 Core Language => Ext Pack: Config & Deployment Support (ES 202 781)
03-12-2010 10:17 | Gyorgy Rethy | Target Version | Edition 4.3.1 (not yet published) => v1.2.2
27-09-2011 14:07 | Gyorgy Rethy | Target Version | v1.2.2 (interim) => v1.3.1
28-09-2011 16:06 | Jacob Wieland - Spirent | File Added: CR_5224-proposal.doc |
28-09-2011 16:09 | Jacob Wieland - Spirent | Note Added: 0010283 |
29-11-2011 14:50 | Gyorgy Rethy | File Added: CR_5224-proposal_v2.zip |
29-11-2011 14:55 | Gyorgy Rethy | File Deleted: CR_5224-proposal_v2.zip |
29-11-2011 15:08 | Gyorgy Rethy | Note Added: 0010404 |
29-11-2011 15:22 | Gyorgy Rethy | Note Edited: 0010404 |
29-11-2011 15:23 | Gyorgy Rethy | File Added: CR_5224-proposal_v2.zip |
29-11-2011 15:28 | Gyorgy Rethy | File Deleted: CR_5224-proposal_v2.zip |
29-11-2011 15:28 | Gyorgy Rethy | File Added: CR_5224-proposal_v2.zip |
29-11-2011 15:29 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
29-11-2011 18:16 | Jacob Wieland - Spirent | File Added: CR_5224-proposal_v3.doc |
29-11-2011 18:17 | Jacob Wieland - Spirent | File Deleted: CR_5224-proposal_v3.doc |
29-11-2011 18:17 | Jacob Wieland - Spirent | File Added: CR5347_resolution_v3.zip |
29-11-2011 18:20 | Jacob Wieland - Spirent | Note Added: 0010406 |
29-11-2011 18:20 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 13:47 | Jacob Wieland - Spirent | File Deleted: CR5347_resolution_v3.zip |
30-11-2011 13:47 | Jacob Wieland - Spirent | File Added: CR_5224-proposal_v3.zip |
30-11-2011 14:01 | Jacob Wieland - Spirent | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
30-11-2011 17:05 | Jacob Wieland - Spirent | File Deleted: CR_5224-proposal_v3.zip |
30-11-2011 17:07 | Jacob Wieland - Spirent | File Added: CR_5224-proposal_v3.zip |
30-11-2011 19:06 | Jacob Wieland - Spirent | File Added: CR_5224-proposal_v4.zip |
30-11-2011 19:15 | Jacob Wieland - Spirent | File Deleted: CR_5224-proposal_v4.zip |
30-11-2011 19:17 | Jacob Wieland - Spirent | File Added: CR_5224-proposal_v5.zip |
30-11-2011 19:17 | Jacob Wieland - Spirent | Note Added: 0010453 |
30-11-2011 19:18 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 09:32 | Gyorgy Rethy | File Added: CR_5224-proposal_v4.docx |
01-12-2011 09:32 | Gyorgy Rethy | File Deleted: CR_5224-proposal_v5.zip |
01-12-2011 09:33 | Gyorgy Rethy | Note Added: 0010457 |
01-12-2011 09:53 | Gyorgy Rethy | Note Added: 0010459 |
01-12-2011 09:53 | Gyorgy Rethy | File Added: CR_5224-proposal_v5.docx |
11-07-2012 09:26 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
13-07-2012 09:35 | Gyorgy Rethy | Assigned To | Jens Grabowski => Tomas Urban
13-07-2012 10:33 | Jacob Wieland - Spirent | Note Added: 0010911 |
10-08-2012 14:48 | Tomas Urban | File Added: CR_5224-proposal_v6.docx |
10-08-2012 14:50 | Tomas Urban | Note Added: 0011034 |
10-12-2012 11:03 | Gyorgy Rethy | File Added: CR_5224-proposal_v6_BNFmodified.docx |
10-12-2012 11:06 | Gyorgy Rethy | Note Added: 0011203 |
10-12-2012 16:05 | Tomas Urban | File Added: CR_5224-proposal_v7.docx |
10-12-2012 16:18 | Tomas Urban | Note Added: 0011208 |
10-12-2012 17:14 | Tomas Urban | Note Added: 0011211 |
10-12-2012 17:15 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
11-12-2012 09:17 | Jacob Wieland - Spirent | Note Added: 0011212 |
11-12-2012 11:02 | Gyorgy Rethy | Note Added: 0011217 |
11-12-2012 12:35 | Tomas Urban | Note Added: 0011219 |
11-12-2012 12:35 | Tomas Urban | Note Edited: 0011219 |
12-12-2012 15:24 | Gyorgy Rethy | File Added: CR_5224-proposal_v8_delta.docx |
12-12-2012 15:26 | Gyorgy Rethy | Note Added: 0011246 |
12-12-2012 15:26 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
13-12-2012 08:35 | Tomas Urban | File Added: CR_5224-proposal_v9_delta.docx |
13-12-2012 08:50 | Tomas Urban | Note Added: 0011251 |
13-12-2012 08:51 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
13-12-2012 12:22 | Jacob Wieland - Spirent | Note Added: 0011252 |
13-12-2012 17:53 | Tomas Urban | Note Added: 0011258 |
13-12-2012 17:54 | Tomas Urban | File Added: CR_5224-proposal_v10.docx |
18-12-2012 16:19 | Gyorgy Rethy | Note Added: 0011284 |
18-12-2012 16:20 | Gyorgy Rethy | File Added: CR_5224-proposal_v11.docx |
18-12-2012 16:21 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
18-12-2012 16:21 | Gyorgy Rethy | Priority | low => normal
18-12-2012 16:21 | Gyorgy Rethy | Status | assigned => resolved
18-12-2012 16:21 | Gyorgy Rethy | Fixed in Version | => v1.2.1 (ongoing)
14-05-2013 15:24 | Gyorgy Rethy | Status | resolved => closed
14-05-2013 15:24 | Gyorgy Rethy | Note Added: 0011438 |
14-05-2013 15:24 | Gyorgy Rethy | Resolution | open => fixed

Notes

(0009117)
Ina Schieferdecker
09-12-2009 13:52

Wait for concrete proposal and hence moved to 2010.

(0009266)
Jacob Wieland - Spirent
23-03-2010 16:06

I think to solve this issue at the TTCN-3 language level is the wrong way. The right place to solve this problem is by use of different test adaptations for the different scenarios.
In one scenario, the same mapped port is adapted by an implementation that converts the sent value to a different protocol before sending it to one real-system port, while in another scenario, it is not converted and sent to a different real-system port. In the TTCN-3 code, this is totally transparent and no conversion functions are needed and no intermediate components in TTCN-3, either.

(0009290)
Jacob Wieland - Spirent
24-03-2010 18:37

added a proposal text to be discussed

(0009320)
Gyorgy Rethy
26-03-2010 09:40

status feedback shall only be used when we are waiting for an external feedback.

(0009442)
Gyorgy Rethy
01-07-2010 09:55

Real-life use cases, coming from everyday practice:
1) User tests something above TCP transport and obviously using a TCP adapter. His/her test cases and test data are using the ASPs of the TCP adapter. Then the SUT changes and he/she has to execute the same test cases using e.g. SCTP transport. The SCTP adapter has different ASPs defined than the TCP adapter. In this case the mapping between the two sets of ASPs could be done in a dual-faced port, instead of re-writing the already verified and running test cases.
2) Protocol A carries encoded messages of protocol B, for example a web application carried by SOAP carried by HTTP over TCP. The user is testing the application but from the point of view of the test system, HTTP (or SOAP in case of an HTTP adapter) is the "upper layer protocol", CD will encode/decode only HTTP (or SOAP) messages but not the Application messages. This means that from the point of view of the user no matching is possible by a receive statement (as he/she wants to match the Application messages, which are embedded in an encoded form in the received SOAP or HTTP messages). Dual-faced ports it can handle the whole encoding/decoding chain, i.e. mapping Application ASPs to SOAP/HTTP ASPs and calling external functions for message encoding/decoding, thus the user would be able to send/receive the Application messages directly in his/her test case code.
This means the dual-faced ports shall not only define the two sets of interfaces between the inner and the outer port but also the type mapping (which inner port ASP/message maps to which outer port ASP/message) and also the functions that makes the mapping. The function is needed to allow the user to write them in TTCN-3 (would be a natural choice for a tester using TTCN-3 anyway) and be able to make static and dynamic checking.

(0009447)
Jacob Wieland - Spirent
01-07-2010 11:31

The type-mapping is implicitly given by the mapping-functions. Via the restrictions on the set of functions, the mapping is unambiguous.

(0009670)
Jens Grabowski
01-09-2010 11:05

Yes, can be done in the proposed way. I still have the problem that I do not think that this mapping should be done in TTCN-3 itself. Wouldn't it be enough to be able to select different kinds of adapters/coders/decoders?

(0009699)
Jacob Wieland - Spirent
02-09-2010 14:13 (edited on: 03-09-2010 11:10)

To solve the dual-faced port problem with the n-to-m message problem could also be done in the following way by some filtering attribute on port types.
Just the semantics, not an actual syntax proposal:
// Taken a type definition like this:
type record TCPPacket {
...
octetstring content
...
}
// we could declare the following:
type port FilteredHTTPPort message filtered {
in HTTP |> tcpInFilter; // filtered by tcpInFilter
out HTTP |> tcpOutFilter; // filtered by tcpOutFilter
}
function tcpInFilter(in bitstring input, out bitstring output)
return integer // number of bits decoded
{
if (transport == tcp) { // switch tcp transport on or off
var integer inputLen := lengthof(input);
var TCPPacket tcpPacket;
if (decvalue(input, tcpPacket) == 0) {
output := oct2bit(tcpPacket.content);
return inputLen - lengthof(input);
}
else {
return 0; // 0 bits have been decoded because of error or not enough input
}
}
else { // not filtered, just relay
output := input;
return lengthof(input);
}
}
function tcpOutFilter(in bitstring input, out bitstring output)
return integer // number of bits read from the input
{
if (transport == tcp) {
var TCPPacket tcpPacket;
var integer len := packIntoTCPPacket(input, tcpPacket);
if (len > 0) {
output := encvalue(tcpPacket);
return len;
}
else {
return 0;
}
}
else { // not filtered, just relay
output := input;
return lengthof(input);
}
}
function packIntoTCPPacket(in bitstring input, out TCPPacket tcpPacket)
return integer // number of bits put into the packet
{
if (isLongEnoughInput(input) {
tcpPacket := { ... }; // wrap some of the input into a TCP packet
return lengthof(oct2bit(tcpPacket.content));
}
else {
return 0;
}
}
The semantics would be that whenever data arrive from the test system, the in-filter function is invoked on the accumulated bitstring and if it returns a filtered bit number > 0, the output of the function is actually enqueued in the port queue.
The reverse is true for sending, the encoded HTTP message is appended to the accumulated output bitstring and the output-filter function is invoked on that bitstring as many times as the result is > 0. The intermediary results are the messages actually sent to the SUT.

(0009703)
Jacob Wieland - Spirent
02-09-2010 18:13

The extended proposal from Gyorgy in the TCP/HTTP example would look like this:
given the following types:
type record HTTP { ... }
type record TCP { ... }
type port HTTPPort message { inout HTTP; in ASP1; out ASP2 }
type port HTTPToTCPPort map to HTTPPort {
var octetstring inbuffer := ''O;
in HTTP from TCP httpFromTcp; // in-translation function for type HTTP
out HTTP to TCP tcpFromHTTP; // out-translation function for type HTTP
}
// the in types of this port from the component point of view are
// still HTTP and ASP1
// the out types of this port from the component point of view are
// still HTTP and ASP2
// the in types from the outside point of view (used for map/connect
// statements) are TCP and ASP1
// the out types from the outside point of view are TCP and ASP2
// this function will be called whenever an HTTP message should be received
// on port HTTPToTCPPort, it will be called by the test system until at least
// one relay operation has been performed
function httpFromTcp(in TCP tcpMsg)
on port HTTPToTCPPort // this is needed for type-checking of input/output
{
var HTTP httpMsg;
var integer len;
inbuffer := inbuffer & tcpMsg.data; // append data to the buffer
while (true) {
len := lengthof(inbuffer);
if (len > 0 and decvalue(inbuffer, httpMsg) == 0) {
port.relay(httpMsg); // this puts the httpMsg into the port queue
// the type of the relayed message
// the correctness of this type can be inferred
// from the out HTTP to TCP declaration in
// HTTPtoTCPPort
}
else {
break;
}
}
}
// this function is a one-on-one HTTP to TCP mapping without any buffering
// it does not really need a relation to the port type for type checking
function tcpFromHTTP(in HTTP httpMsg) return TCP {
var bitstring encodedHttp := encvalue(httpMsg);
var TCP tcpMsg;
// compute the tcpMsg using the information from httpMsg
// and embed the encodedHttp
...
return tcpMsg; // here, the adapter still needs to encode
// the TTCN-3 value before sending it to the system
}
// the alternative definition would be
function tcpFromHTTP(in HTTP httpMsg) on port HTTPtoTCPPort {
var bitstring encodedHttp := encvalue(httpMsg);
var TCP tcpMsg;
// compute the tcpMsg using the information from httpMsg
// and embed the encodedHttp
...
port.relay (tcpMsg); // the correctness of this type can be
// inferred from the 'out HTTP to TCP' declaration
// in HTTPtoTCPPort
}

(0009707)
Jacob Wieland - Spirent
03-09-2010 10:59 (edited on: 03-09-2010 11:03)

I'm really not that happy with the whole explicit buffering and decoding/encoding and I think this should be hidden as much as possible from the user. So, I would propose to make the approach a bit more declarative and hide these details in the semantics (because this meta-code would look always the same for all such similar problems, as well):
type port HTTPPort message { inout HTTP; in ASP1; out ASP2 }
type port HTTPToTCPPort map to HTTPPort {
in HTTP fromTcp; // the from type can be inferred from fromTcp
out HTTP tcpFromHTTP; // the to type can be inferred from tcpFromHTTP
}
// the in types of this port from the component point of view are HTTP and ASP1
// the out types of this port from the component point of view are HTTP and ASP2
// the in types from the outside point of view are TCP and ASP1
// the out types from the outside point of view are TCP and ASP2
// Each such port has an inner port buffer and an outer port queue.
// Messages arriving from the outside/SUT are enqueued into the outer port queue.
// The results of the translations functions are appended to the inner port buffer.
// For all types that do not have an in-translation function, i.e. ASPs that are not
// transported, the messages are taken directly from the port queue
// if the input buffer is empty.
// Likewise, all types that do not have an out-translation function are
// simply encoded and sent over the port like normal.
// The in-translation function fromTcp will be called whenever an HTTP
// message should be received on port HTTPToTCPPort and the inner buffer of
// that port does not contain a full HTTP message and the outer port queue
// contains at its head the TCP message tcpMsg.
// The result will be appended to the inner buffer so that the port can
// try to decode the HTTP message (if any) from the now longer buffer
// otherwise, the process is repeated until either a HTTP message could
// be decoded or no more TCP messages are in the outer queue.
// If the buffer is non-empty and (even after translation) does not contain
// even the beginning of an HTTP message, the decodiing of HTTP fails and
// the next alternative must be tried. (This allows several different protocols
// to be carried in the TCP).
// As one can see, this function can be reused as in-translation functions
// for all types carried over the TCP.
function fromTcp(in TCP tcpMsg) return bitstring {
{
return oct2bit(tcpMsg.data);
}
// The function tcpFromHTTP is invoked whenever an HTTP messages is to be
// sent over HTTPtoTCPPort. It is called with both the abstract and the
// encoded value of the HTTP message. Its result is the abstract TCP message
// to be sent. This then is encoded by the port and actually sent.
function tcpFromHTTP(in HTTP httpMsg, in bitstring encodedHttp) return TCP {
// assert encodedHttp == encvalue(httpMsg)
var TCP tcpMsg;
// compute the tcpMsg using the information from httpMsg
// and embed the encodedHttp
...
return tcpMsg;
}
As one can see, the code is much shorter and the user can focus on the actual translation from or to tcp and does not need to worry about the whole encoding/decoding stuff.

(0009833)
Jacob Wieland - Spirent
29-11-2010 16:22

After discussing the last proposal the feedback was that a little bit more redundancy in the filter-port declaration would be more readable.
So, I would propose this kind of syntax:
type port HTTPToTCPPort map to HTTPPort {
in HTTP from TCP with fromTcp;
out HTTP to TCP with tcpFromHttp;
}
For the in-types, a list notation for all protocols carried over the TCP
would also be possible:
Example:
type port HTTPOrSIPPort { inout HTTP, SIP }
type port HTTPOrSIPToTCPPort {
in HTTP, SIP from TCP with fromTcp;
out HTTP to TCP with tcpFromHttp;
out SIP to TCP with tcpFromSip;
}
One possible usage scenario would be as follows (this could be added to the example in the standard):
type component SystemType {
HTTPPort http;
HTTPToTCPPort tcpHttp;
}
type component MtcType {
HTTPPort http;
}
modulepar boolean useTCP := false;
testcase TC() runs on MtcType system SystemType {
if (useTCP) {
map(mtc:http, system:tcpHttp);
} else {
map(mtc:http, system:http);
}
...
http.send(HTTP:...);
...
http.receive(HTTP:...);
}

(0009834)
Jacob Wieland - Spirent
29-11-2010 16:28

Maybe a sensible restriction for this feature would be that ports of such mapped port types can only appear in system components, i.e. all component types referenced by runs on (or used in create statements) shall not have port of such mapped port types.

(0009841)
Gyorgy Rethy
30-11-2010 13:23

STF discussion on 30/11/2010: principles agreed, text to be written; shall be added to the configuration package

(0009902)
Jacob Wieland - Spirent
01-12-2010 16:31

added new proposal in plain text form

(0010283)
Jacob Wieland - Spirent
28-09-2011 16:09

uploaded proposal integrated into config&deployment package

(0010404)
Gyorgy Rethy
29-11-2011 15:08 (edited on: 29-11-2011 15:22)

Draft is amended quite significantly, see CR_5224-proposal_v2.zip. Some questions are need be discussed:
(1) Syntactical structure allows:
in InnerInType {"," InnerInType} from OuterInType with InFunction
however, it is unclear how to declare InFunction that would be able to return more than one InnerInType-s
(2) In some cases decoding functions are generated from the TTCN-3 code. In this cases there may be several InFunction-s, with different names and different InnerInType-s but all with an octetstring as OuterInType. In this case, when decoding the TTCN-3 octetstring (the outcome of decoding the bitstring received from TRI by the TE-CD decoding algorithm), these InFunction-s shall be tried sequentially until the decoding successful or no more attempt left. This procedure has been added to the draft.
(3) Currently for a translation port at least 3 port definitions are required: InnerPortType, OuterPortType and the transation port; it should also be allowed to define two ports only: OuterPortType and the transation port, where the in/out/inout lists of the inner port are just the related lists of the translation port
(4) Currently, when 3 port types are used to define the translation port, transparent relaying of messages are not defined in the translation port. It should be considered, for sefaty reasons, to request declaring transparent relaying explicitly â€“ this would be denoted by InnerInType==OuterInType the null in the above draft.

(0010406)
Jacob Wieland - Spirent
29-11-2011 18:20

All issues have been addressed and the proposal changed accordingly. Two notes in the section Port composition have been left because I did not know what to make of them. Please review

(0010453)
Jacob Wieland - Spirent
30-11-2011 19:17

added support for address, map param and unmap param translation, please review

(0010457)
Gyorgy Rethy
01-12-2011 09:33

File CR_5224-proposal_v5.zip contained CR_5224-proposal_v4.docx, so I have deleted the .zip and uploaded the contained .docx instead.

(0010459)
Gyorgy Rethy
01-12-2011 09:53

The whole stuff become so overcomplicated that it is almost impossible to me to follow what should happen in a translational port in the different cases. How can we expect the users to understand it? The whole stuff shall be streamlined and simplified to the really required use cases (see CR_5224-proposal_v5.docx, but the simplifications are not done consistently in the whole document):
- the translational port is part of the test component behaviour, thus there shall be no implicit behaviour there;
- delete InnerInType list in port in message translation lists (only one InnerInType per inFunction) and the whole implicit decoding stuff in the InFunction prototypes; all encoding/decoding shall be explicit (and decvalue shall be called explicitly within inFunction, if needed)
- delete InnerOutType list in out message translation clause (i.e. only one InnerOutType per OutFunction) and the related second prototype with two in parameters (I don't even understand the exact semantics of this second prototype).
All these can be added later if really required, but not at this stage.
The Cr can be added to the standard only if the whole concept is clear and simple enough that users really want to use and tool vendors really implements. I don't have this feeling at the moment. As our last session is ending now, I propose to shift this CR to 2012.

(0010911)
Jacob Wieland - Spirent
13-07-2012 10:33

Using simple solutions to complicated problems is a sure way to get problems in the future. If you introduce a non-composable dual-port construction (which seems to me what you are implying), this might be acceptable for simple use cases, but makes things overcomplicated for more complex situations (where you would have to explicitly gap the bridge between several protocol layers in the same way it should be done implicitly instead of simply composing several dual-ports).
Letting the user deal with the whole encoding/decoding explicitly is also a way of making this feature unacceptable as it overcomplicates things for the user instead of the tool-vendor and makes the whole thing more error prone (the more the user has to do explicitly, the more they can do wrong).

(0011034)
Tomas Urban
10-08-2012 14:50

Temporary draft uploaded. The text contains resolutions to most of the issues that were discussed during the August STF session in GÃ¶ttingen, but some details are still missing. E.g. address translation shall have two branches for in and out directions.

(0011203)
Gyorgy Rethy
10-12-2012 11:06

as agreed this morning, I was working on the BNF, pls. find and check my output in the file CR_5224-proposal_v6_BNFmodified.docx

(0011208)
Tomas Urban
10-12-2012 16:18

Updates in this version:
1. Address translation: two kinds of functions (one for sending, other for receiving)
2. BNF update including (simplified) GyÃ¶rgy's changes
3. TCI-TL update (function for port.setstate)
4. Runs on clause forbidden in translation functions
5. Corrections in examples (5.10.3 - wrong parameter types, syntax highlight missing)
6. Translation functions for addresses don't use translation states (no need for fragmentation support or multiple types)
7. New restriction: in case of fragmented messages, addresses of all fragments shall be equal

(0011211)
Tomas Urban
10-12-2012 17:14

GyÃ¶rgy, please check the latest draft.

(0011212)
Jacob Wieland - Spirent
11-12-2012 09:17

I still think it is wrong or at least confusing/error-prone to have multiple out or in functions for the same type in one port definition (especially since up till now the order of the declarations in a port type definition has no meaning). This can lead to composition problems when mapping a port to an existing translation port. (A -> f1 -> B -> g1 C vs. A -> f2 -> D -> g2 E).
Also, what order takes precedence when trying? The order of the inner port or the order of the outer port?
What happens, if the inner port translates A to B with function f and then the outer port translates B to C with function g but fails?
Also, I think that the multiple-case needs some more attention. What happens with the rest of the partially decoded message? Is the message split into decoded/undecoded part?

(0011217)
Gyorgy Rethy
11-12-2012 11:02

Hi Jacob,
The typical real-life situaton is that the transport layer carries the upper layer's messages as octetstrings (or univ. charstrings); either a transort layer's field and/or the message itself contains a protocol and/or message identifier. The tool is not able to sort this out, because the location, the concrete form and the concrete ID values of this identifier is protocol-specific, but the user can. The typical algoritm of a translation function is: check if my message "manually" -> if not, return with unsuccess -> if yes, decode and return with success. So, the translation process is not ad-hoc at all, just controlled by the user, not by the tool. In rare cases the type of the message cannot be determined manually before decoding, in these cases the-try-and-see algorithm can be used just like the type hypothesis algorithm; but in practice these are the exceptional cases, not the normal ones!
The order is specified in the proposal as the textual order of the from/to_with_function statements in the set of translation functions with the given type as in parameter. The rational behind this is that the user knows which messages are sent most frequently in the given protocol and - if performance matters - translation functons for these can be placed ahead of the list.
"What happens, if the inner port translates A to B with function f and then the outer port translates B to C with function g but fails?" How is it possible? B is a valid value of its type, let me say BType. The same will happen if the coder received an instance of BType it is unable to encode (but I still don't understand how it would be possible, the instance should cause an error earlier than getting to the codec).
You remember, due to the fragmented and multiple cases (streaming protocols) we have introduced the port variable, as we need something to store the undecode-able part of the outer message (e.g. the bits returned in the encoded_value parameter by the decvalue function called from a translation function). In the next translation round the new octets/bits are concatenated to the bits stored in the port variable and message decoding is tryed again.

(0011219)
Tomas Urban
11-12-2012 12:35

Hi Jacob,
The current draft doesn't support protocol stacking, thus the situation you mentioned (multiple translation paths) cannot occur. We have a proposal for protocol stacking via several translation ports in our drawer (including translation path selection which solves the problem you described), but because of overall complexity of the issue, the current draft specifies support for direct translation only. The rationale behind it is very simple: the CR has existed for more than two years without finding its way to the standard, and becuase of that, the STF has decided to resolve the basic problem first and deal with complex issues later (in case it is requested by the community).
Regarding partially decoded messages: There are actually two issues and I am not entirely sure if you meant not finished decoding of a message received in several fragments or an outer (envelope) message that contains several inner messages. Both cases are actually described in the draft. In case of a fragmented message, decoded fragments are removed from the outer queue and the user has to take care of buffering the data (using port variables) if not enough fragments have been received to put together an inner message. In case of multiple payloads in one envelope message, the envelope message stays in the outer queue until all data it contains has been passed to the inner queue. It is again up to the user to store all information about what part of the envelope message has been processed (such as reading positions).

(0011246)
Gyorgy Rethy
12-12-2012 15:26

I have reviewed the draft, see the result in CR_5224-proposal_v8_delta.docx (delta means that only the new and changed parts are left in the file, not the whole ES 202 781). Pls. check my changes and comments.

(0011251)
Tomas Urban
13-12-2012 08:50

I marked most of the changes as accepted and attached some comments. However, I changed several rules in the draft:
1. I added the "Unset" state with description to the list describing all possible states
2. "Multiple" state in case of sending: the in parameter should contain the original sent message of the InnerOutType in all translation calls. In most cases, it won't be of any use for the user, because he/she will encode the message in the first call and then store the unused part, but for consistency reasons it seems better to provide some value in the parameter rather than introducing a rule for uninitialized parameter values.
3. "Multiple" state in case of receiving: as the result of the yesterday's discussion, the outer message is kept in the queue, becuase automatic decoding of all inner messages contained in the outer message is not possible during a single receive call (the type hypothesis is available for the first inner message only). I also added some explanatory text and a rule that the outer message is kept in the decoded form in the outer queue.
4. I extended the BNF rules for OuterPortTypeSpec (adding type list and the connect to part)

(0011252)
Jacob Wieland - Spirent
13-12-2012 12:22

With this clarification, this is fine.
The multi-layer thing is already present, though, because it is not disallowed to define a mapped port that maps to a mapped port (it is only restricted that the port to be mapped to shall not directly or indirectly be the mapped port, as far as I understood it). Thus, all problems presented by the multiple layers need already be addressed or such a restriction be introduced.

(0011258)
Tomas Urban
13-12-2012 17:53

I modified the draft according to results of today's discussion. I also added TCI changes and that were accidentally left out from the shortened version of the document. Please review.

(0011284)
Gyorgy Rethy
18-12-2012 16:19

Final version is in CR_5224-proposal_v11.docx: contains editorial corrections: some missing spaces added, "working" (Word) comments are deleted, names of states are changed to small first character (once they used in small later).
In the notes in 5.10.5 and 5.10.6 (about the non-translated part shall be assigned to port variables), I removed the partially fragmented state: in this case it is enough to store the position, until which the outer message is decoded; In the last iteration, when the superflouos remaining (non-complete message)is processed, the final state will be fragmented.

(0011438)
Gyorgy Rethy
14-05-2013 15:24

Added to V1.2.1 of the standard