Slide 38 of 56
Notes:
The JCIT SINCGARS discards incoming SINCGARS SA data, JVMF SA is the received and sent to FBCB2.
NRL is not implementing any routing function as part of the IDM capability. Therefore, for TI messaging, the EPLRS and SINCGARS behave like separate links. We can probably run one or the other but not both.
PM FBCB2 has decided to drop Switched Virtual Circuits (SVC) as the routing algorithm for the EPLRS and is instead going to use Dynamically Allocated Permanent Virtual Circuits (DAP).
6. EPLRS Protocol. Andy Feldstein, ICI, briefed on issues with the EPLRS protocol. ITT is developing a change to the EPLRS protocol with a schedule completion and implementation in Feb 99 to support the FBCB2 IOT&E. Porting of the existing X.25 EPLRS protocol to the JCIT is planned to start 9/14/98. The ITT changes will have to be tracked and a working relationship developed with the EPLRS PM to assure that the design changes are passed to NRL. Not only is the protocol changing but also the routing algorithm. Used to be Switched Virtual Circuits (SVC), now is Dynamically Allocated PVCs (DAP).
7. MIL-STD-188-220( ) Protocol. Implementation of MIL-STD-188-220B is not as straightforward as one would think. SINCGARS packet mode (INC) is still pre Task Force XXI. The current IDM software development is using the Task Force XXI INC code adding the SINCGARS SA Agent and 188-220B, Type 2 messages. The type 2 messages are required in order to participate as a member of a Fire Support Net, but Raytheon implementation for Type 2 is a 188-220A+. In Jan - Feb 1999, there is a schedule release of MIL-STD-188-220C. There will have to be much coordination to assure that all the different 188-220 implementations are properly designed into the JCIT.
