Wholesale: Products & Services

Archived System CR SCR032202-2 Detail

Implement an Interactive Agent that conforms to TCIF document 98-006 Issue 2 Revision 1.

Additional Information:

The TCIF published the Interactive Agent Functional Specification

for Issue 2. TCIF, ANSI and The ITU-T have all adopted the Issue 3 IA Spec.

An Interactive Agent (IA) is a set of processes that runs on one

(or more) of an ILEC's and a CLEC's computer systems. It serves

as one of the logical interfaces between two companies doing

business together electronically. It should be noted that the IAs

transport data transparently. They don't modify it or interpret

it - they only deliver it.

The IA in one company receives EDI data from one of its own

company's upstream systems. It makes a request across the network

to the other company's IA for a connection. Once the connection

is established (through a "handshake" protocol) the originating

IA then sends the EDI data to the peer IA at the other company.

The peer IA verifies that the data was received without error and

sends it upstream to one of its EDI systems for translation and

processing.

The receiving IA then initiates a disconnect of the session.

(This disconnection process is where all the fuss is.) The

original IA specification (which Quest is still using) left out a

step in the procedure that would assure that the disconnection

process would always occur in the correct order. The later

version of the specification (which WorldCom uses) corrects this

error by inserting one additional step in the procedure for one

IA to disconnect from the other.

If the disconnection procedure is not executed correctly by both

parties, internal problems begin to occur intermittantly in one

or both IAs, causing degraded performance and then finally a need

to stop and restart the IA system(s).

The particular step that was missing in the original spec

guaranteed that the right sequence of steps would occur,

regardless of timing considerations and network delays. In a

large number of transactions, especially in those relationships

that have low volumes, the timing of events work out that the

right series of steps happens. It's only when certain

combinations of events occur (usually in high volume situations)

that the steps get out of sequence and the errors start.

Status History

Project Meetings

With one major exception (see below) the two revisions are compatible.

The exception is noted on the Revision History Page as follows:

1. Section 7.8 - It was determined from reading protocol traces that a "race" condition exists if the current protocol is followed. The IA Server may attempt to close the socket before receiving the Client's SSL Close, causing an incorrect closure of the connection. This can result in either "Close Wait" or "Fin Wait" errors and prevent Session Resumption. To correct this problem, an additional step has been added to the IA Server session closure sequence in Section 7.8, Server Disconnect, between "SSL3 CLOSE" and "Socket CLOSE".

The step necessary to implement this correction to the protocol is quite simple and straight-forward. It typically requires a very small sequence of steps added to the IA Server module to implement. I will be happy to provide further insight on this to you or any one else that is involved at Qwest or any software suppliers.

Regards, John

3/29/02 Clarification meeting held.

In attendance were: LeiLani Hines - WorldCom John Murphy - WorldCom Mary Hunt - WorldCom Mark Routh - Qwest Deb Osborne - Qwest Jerry Mohatt - Qwest J.J. Bradley - Qwest

John started by providing a background on the TCIP standard. He related that the current standard is the TCIF issue 2 R1 document. The TCIF issue 3 R2 document is also a current standard but is not fully implemented across the industry at this time. He confirmed that TCIF issue 1 R0 has been withdrawn as a standard and all ILECs and CLECs should be using Issue 2 R1 at this time. These standars can be referenced on the web at http://www.atis.org/atis/tcif/5tc00a03.htm.

John also mentioned that he is the Vice Chairman of TCIF and would be happy to take any calls from technical staff concerning these standards.

Gerry Mohatt asked if going to the Issue 2 R1 standard would have an impact on CLECs that were not on the standard yet.

John indicated that a CLEC had properly coded their systems for the Issue 2 R0 standard, that they would not be impacted by an ILEC or CLEC going to the Issue 2 R1 standard.

Jerry also asked if this was prioritizable by the CLEC as an IMA change.

It was discussed that even though this change will impact the IMA EDI interface, because it is an industry standard, it may be elligable to be implemented prior to IMA 12.0.

This will be discussed at the April Systems CMP meeting.

CenturyLink Response

Mary,

Attached you will find the description depicting how our IA vendor corrected the problems which were addressed with Section 7.8, Revision 1, Issue 2. Our IA was corrected approximately a year before Revision 1 was published.

Basically, I am asking that we remove the CR from the CMP scope as Qwest does not believe there is an issue with its compatibility regarding Issue 2, Revision 1. In addition, I have recapped a comment from the Clarification Meeting held on March 29th in which John Murphy states Revision 0 and Revision 1 are compatible. Could you please let me know by Noon tomorrow (via e-mail) if WorldCom will be withdrawing CR # SCR032202-2 from the CMP CR Issues list.

John Stated, "If a CLEC has properly coded their systems for Issue 2 Revision 0, that they would not be impacted by an ILEC or CLEC going to the Issue 2 Revision 1 standard."

Please let me know if you have any further questions.

Dawn Beck