Winlink 2000 Roadmap

[As of 2009, all the items in this plan have been implemented. This document is now obsolete. Ed.]

Victor Poor, W5SMM
Rick Muething, KN6KB
September 28, 2007 Draft
Updated December 6, 2007 - Final

This document spells out how the WL2K developers see WL2K evolving over the near future. It is the intent of the development team to release and deploy new software in stages to provide a seamless transition from the current CMS/PMBO structure to a new CMS/RMS structure.

Primary Components
The future WL2K system will consist of the following primary elements:

1. Common Message Server (CMS). Each CMS site provides a port into the WL2K system for exchanging Internet email with WL2K users, holds all messages to and from all users, interfaces with the RMS channel programs, telnet service, and provides message management services. The details of these services are described in other documents. The CMS Telnet server is compatible with AirMail, Paclink, Outpost, Windows Telpac, Linux Telpac Linux and RMS Clients. There can be up to five CMS sites (three are currently active, one in Australia, one in Canada, and one in the
   U.S.). The sites are synchronized and any one site is capable of handling the traffic for the entire network. All access to a CMS site is via TCP/IP.

2. RMS Packet Program. RMS is short for Radio Message Server. RMS Packet is a stand alone program that connects AX.25 packet links through to the CMS sites. It is intended to replace Windows-based Telpac and PMBO packet ports. RMS Packet will interface a packet TNC supporting multiple simultaneous connections on a VHF channel or two VHF channels if it is a dual port TNC. Alternatively an RMS Packet instance may optionally interface to a single or multi-port AGW Packet Engine installation. There can be any number of RMS Packet program instances in a single computer running at a site limited only by the computer and site s resources. Each instance consists of a single program with a simplified installation compared to the current PMBO sites. The programs will run on a Windows 2000 or later operating system. All RMS programs require a full time Internet connection for normal operation.
3. RMS Pactor Program. RMS Pactor is a stand alone program that connects Pactor links through to the CMS sites. Each instance of RMS Pactor will support a single SCS PTC controller (any model) and an HF radio with optional scanning and antenna switching. There can be any number of RMS Pactor program instances in a single computer running at a site limited only by the computer and site's resources. Each instance consists of a single program with a simplified installation compared to the current PMBO sites. The programs will run on a Windows 2000 or later operating system.
4. RMS Relay Program. This is a supplemental program that can provide temporary storage of messages and local routing in the event TCP/IP access to all of the CMS sites is lost. It will normally only be used with co-located RMS Packet and Paclink MP programs. (Co-located means in the same computer, LAN, or short distance Ethernet links.) The relay program only becomes active when TCP/IP links are lost to all CMS sites. When active it provides temporary local message storage and routing. Optionally it will also exchange messages with a CMS using links to distant RMS Pactor programs over HF. RMS Relay would normally only be installed in sites devoted to emergency services. In normal public sites loss of TCP/IP service to the CMS sites will simply suspend activity until it is restored.

   The RMS Relay program can share the same Pactor controller and radio used by an RMS Pactor program running on the same computer. (RMS Relay just like RMS Pactor could use any of the PTC II models including the II, IIe, IIex, IIpro, and IIusb.) Note that any RMS Pactor inbound portal is deactivated when no TCP/IP connection to a CMS is available, freeing the controller to serve in HF relay service for the local area VHF ports.

5. Paclink MP Program. This provides client access to WL2K for multiple users on a LAN with the individual users accessing the system from their chosen email client programs using POP3/SMTP. Paclink will provide priority weighted access to any number of potential WL2K channels including telnet, packet, or Pactor.
6. AirMail Program. This provides client access to WL2K for a single user via telnet, VHF, or Pactor. It is a stand alone program that provides a number of services to the individual user including peer-to-peer connections between AirMail programs, propagation forecasting, a bulletin catalog, and canned forms for WL2K and MARS services. AirMail is a third-party program written and supported by Jim Corenman, KE6RK (see www.airmail2000.com) and is free of charge for amateur and MARS use.
7. The WEB server includes all of the WL2K WEB applications, the database that holds statistical data about the network, files for automatic update of deployed programs and a registry of all individuals supplying sysop services. (A sysop is defined as any amateur that maintains an RMS channel, a Telpac site, or a Paclink MP site.) The WEB site is not redundant but also is not mission critical. Loss of the WEB site does not prevent the normal traffic flow through the network.
8. WL2K Support Programs. A number of support programs exist or are in development to support the management of the WL2K system in addition to general purpose third party management programs (especially those to support the MySQL database). Programs designed exclusively for use by network managers/administrators include:
   • CMS Prestart

   • CMS Callsign Manager
   • CMS Message Manager
   • CMS Inquiries Manager
   • CMS Whitelist Manager

   Programs for use by network managers/administrators and RMS sysops include:

   • RMS Callsign Manager

   • RMS Message Manager
   • Winlink Network Test
   • WEB-Based Monitoring Programs

Benefits
This new model for WL2K is one of multiple common message servers for redundancy and reliability and individual remote radio channel servers providing direct access to any of the common message servers. This architecture will greatly simplify the installation and maintenance of what is now a PMBO site and will eliminate an extra level of connectivity now required for connections via Telpac. It also eliminates the need for NO-IP registration for a remote site except where a sysop needs remote access to his site for system management (Remote terminal services, PC Anywhere, or similar access program).

This architecture will also have significant benefits to the individual user. Message delivery will be faster since messages will be immediately accessible to the user when they arrive at the CMS sites without waiting for the polling cycle from a PMBO. The chance of a duplicate message is reduced since there is less chance of a PMBO missing a delivery notice and updating a local database. The chance of an outgoing message becoming orphaned at a PMBO site when the PMBO has lost connection to Internet is eliminated.

The CMS sites provide the telnet service that is now provided by the individual PMBO sites. This will provide for continued support of non-RF access for message exchange, existing Telpac sites, and third-party access for services such as ALE networks.

Deployment
Our objective is to provide a seamless deployment of the new architecture replacing PMBOs and Windows-based Telpacs with the new radio servers gradually. Existing services and programs will continue to function as they are. The first objective is to completely convert the triservice MARS network, public Windows-based Telpac sites, public PMBO sites, then key ARES sites, and gradually replace the remaining ARES sites.

Those sites that use the Linux implementation of Telpac may continue to do so indefinitely but will need to redirect the telnet connections to telnet ports at the CMS sites.

Transition from PMBO to RMS
Any site that does not require local routing of messages(and that should include all non-emergency and MARS sites) should be able to seamlessly switch from PMBO operation to RMS.

Sites that currently do require local routing should continue using PMBO code until such time as RMS Relay is available. If those sites are also using co-located (same LAN or same computer) Paclink AGW programs or Paclink AGW programs linked to the PMBO by short distance Ethernet links then they should not switch to Paclink MP until RMS Relay is released and they have converted from PMBO to the new radio servers and RMS Relay.

Possible Future Developments
Paclink MP and RMS Packet support the AGW Packet Engine or direct connections to Kantronics and Timewave TNCs. In the future the team will add additional models of TNCs for direct connection as time permits.

Radio protocols other than packet and Pactor can be supported with additional RMS programs in the future as protocols and controllers become available. This new architecture should make this a relatively easy process.

Another possible future development would be a special option in Paclink MP for local area peer-to-peer message exchange over VHF frequencies when no other means of communications with WL2K or local RMS sites is functioning.

The Winlink Development Team will investigate these options once the current programs under development have been released and successfully deployed.

Winlink 2000 Design Goals
This new architecture does not in any way alter the original design goals of WL2K (See Design Objectives for Winlink 2000, March 22, 2000).