VPN Protocol Testing

Following the standardization of a public ISDN PRI specification, market interest in the open CorNet WAN protocol championed by Siemens plummeted. No "killer application" appeared with the CorNet protocol and most telephone customers were content receiving calling name and number over PRI.

Because both Siemens CorNet and PRI protocols shared the same physical layer and were based on ITU-T Q921 and Q931, some commonality existed. When comparing CorNet versus ATTs 4ESS PRI code, Cornet was more feature rich but basic call control messaging was nearly identical between the two protocols.

Some clever person in Siemens recognized that CorNet messages and information elements that did not map one-for-one into ATT call control messaging could be encapsulated within PRI user to user information (UUI) and be transmitted across the PSTN.

On the receiving end, a CorNet gateway could unpack call control and supplemental service information from the (UUI, and from it, form and send a valid CorNet message to the end user thereby making possible a CorNet virtual private network (VPN to subscribers of ATTs 4ESS PRI

All that would be needed to make possible a Cornet ISDN virtual private network (VPN would be to merge existing Cornet code with existing ATT 4ESS PRI code and add message mapping and unmapping functions. The Network node interfacing with ATTs 4ESS PRI would be configured as the VPN gateway.

The gateway could function as a network of one with anywhere from zero to n subtended nodes. The number of subtended network nodes per gateway were determined based on traditional traffic engineering metrics.

Subtended network nodes would have no knowledge or indications that they were part of a subtended network.

Testing

Both feature and protocol level testing was required. Lessons had been learned from the earlier WAN test directives. That plus the company now being much more focused on product quality made for a good release. Feature testers were not forced to interfere with each other and because the ATT PRI conformance test specification was already published, the existing suite of scripts only needed additions not reflected in ATTs older specification.

Compliance Testing

ATT technical staff had been alerted to capabilities of our VPN product and were eager to see it function, In my opinion, they paid special attention to the way we used their message associated user to user signaling to send information across the d-channel that normally would incur additional charges such as remotely setting a message waiting lamp. In any event, we passed compliance testing without issue.

Field Trials

Customer field trials of our VPN were notable in that ATT had severe technical problems. Either we were their first customer of ISDN PRI supplemental services, or Siemens was the first to so fully exercise it. ATT finally got their system working but it continued having sporadic glitches.

Emotions at Siemens were mixed. On one hand avoiding schadenfreude at the sight of ATTs problems was difficult to do. However, we needed them to have a reliable product in order to help assure the success of our product. In this situation, we needed ATT more than they needed us. Ultimately, ATT did get their problems fixed but not without upsetting our product release schedule. To what extent those early problems affected market acceptance is difficult to know. They sure didn't help.