Lecture Note No. 6 TRAINING SEMINAR ON INFORMATION AND COMMUNICATION TECHNOLOGY FOR THE GTS (Telecommunication and Data handling systems at NMCs ) (Examples of Implementation and suggestions) T.K.RAY RTH, NEW DELHI, INDIA

Telecommunications and Data Handling Systems at RTHs/NMCs T.K.Ray/RTH New Delhi

New MSS at RTH, New Delhi Facilities Besides usual GTS functions like reception/store and forward, format correction, bulletin compilation, data-base functions-retrieval, real-time and non- real-time monitoring etc., the MSS at RTH, New Delhi has the following more advanced facilities : Dual Sun (Enterprise 250) Servers with Powerful Comm.Gateway Communication Gateway (LINUX/UNIX) Line handling capacity from 50 baud to 128 kbps, upto 128 high speed input/output lines VSAT and Telex interface for data Reporting/Retrieving service X.25, TCP/IP and Telnet facilities WMO/ICAO message handling Met.fax and Retrieval/Reporting of Data/information through dial-up modem Internet connectivity NCDF and T4 fax handling

Communication Gateway at the New RTH, New Delhi System The incoming data are received on communication gateways through modems and telex converters (for converting +/- 60V to RS232 signals) in case of low speed circuits. Each communication gateway can support maximum of 8 ports, each of which can be configured as T/P, X..25, LAPB and ASCII circuits depending on what firmware have been loaded for that port. The data received at the CGs are transmitted to the communication control and executives through 24-port switch. In the CCE there is a separate process for each circuit. Data received are transmitted to Main Data Base Processor (MSDP) through LAN (provided by 100 Mbps switches) and is stored only for a brief period in the CCE. TCP/IP circuits are not handled by the CGs. These circuits are terminated on the WAN router, which is connected to the MSDP through LAN. MSDP directly handles these circuits.

With the advent of Internet and Personal Computers, it is possible today to set up quite a few cost effective yet powerful configurations for exchange of meteorological data between RTH and NMC and between different regions within the NMC as listed below. 1. NMC subscribes to the ISP in its country for a dedicated account. RTH sends on real time all the GTS messages to this account. NMC connects to this account periodically and downloads all the messages for its local use as well as can automatically forward such messages based on predefined message rules to the various regions within the NMC. This arrangement will cost much less as compared to traditional leased T/P circuits. It has the added advantage of the capability to receive binary, fax and graphics files as attachments. It may be noted that in this arrangement there is no custom hardware or software application is required except for some custom facilities at the RTH end. 2.FTP RTH/NMC uses a PC based FTP server to host the GTS messages in predefined message files and authorized centers logs on to this PC to download the files periodically for operational use. The entire procedure can be automated and there is no necessity of any custom application in this set up also. Again this arrangement is also very cost effective. 3.WEBMAIL: Webmail servers such as Microsoft Exchange 2000 based Outlook Web Access ( OWA ) has excellent facility called Public Folder for sharing information between a member who has the write access and others who have the read access. RTH/NMC can publish various processed information such as grid products, analysed charts, satellite and radar imageries for use by the various regional centers. Webmail is a viable solution for RTH/NMC for the following reasons. (i) Users can gain access to their mailboxes from virtually anywhere within the NMC intranet, or even from the Internetwithout needing to reconfigure the client profile or install additional software. For example, one shared client system with a Web browser can service users for an entire regional office of the NMC. (ii)Webmail provides users on UNIX and other operating systems with access to their by using a Web browser.

(iii)Deployment of an client is not required. NMC can support regional offices without needing to deploy the client on their office system. 4. WMO TCP/IP SOCKET and FTP: 4All the above facilities are, in addition to, WMO TCP/IP socket procedures and FTP procedures to be implemented using leased data circuits or through internet which need custom application software for setting up exchange of meteorological data. Message structure for Socket exchange applications The rules for use of TCP/IP socket exchange can be summarised as: 1. All new connections must start from a new message. 2. Each message is preceded by a message length field of eight ASCII characters and a message type field of two ASCII characters. 3. Message length is coun.ted from SOH to ETX inclusive and must contain leading zeroes as necessary. 4.Message type must be encoded as BI for binary, AN for alphanumeric or FX for facsimile. 5.Receiving centres will check synchronisation as follows: Check that the first 8 characters are ASCII numeric Check that the 9th and 10th characters are BI, AN or FX Check that the 11th character is SOH Check that the last character is ETX. 6. If synchronisation is lost the receiver shall break the connection using the following sequence of TCP user primitives: shutdown (to make sure that all data in the TCP send buffer has been transferred) close. 7. It is recommended to use separate sockets for ASCII and binary messages, and separate connections for sending and receiving. The sender should always be responsible for establishing the connection. 8. Once a connection is established, it should be maintained. 9. If there should be a need to close a socket, the procedure should be as follows: shutdown (to make sure that all data in the TCP send buffer has been transferred) close.

10. This procedure should also be used when a MSS is being shutdown. 11. If the receiving side receives a new unexpected connection request on a port for which it has an established socket, the old socket should be closed and the new socket accepted. 12. TCP/IP Service/Port numbers for these connections will be decided by bilateral agreement. The use of reserved ports (1 to 1023) should be avoided. The use of ports above is recommended. 13. To reduce the amount of data lost if an established connection fails, the TCP send and receive buffer sizes can be adjusted. The recommended value for the buffer size is 4KByte, however this value may be agreed on a bilateral basis. 14. To enable detection of message loss, the use of the channel sequence number, (CSN) is mandatory. When using the CSN to check for missing messages, the WMO request/repeat procedures should be used to recover these. It may be useful to automate this mechanism to avoid delays caused by manual interaction. In order to minimise data loss it is strongly recommended that Centres implement a 5 character long CSN in the future. 15. The channel sequence number 000 (or respectively) should indicate an initialisation, and should not cause retransmission requests. 5.VPN: A still costlier but sophisticated option could be the use of VPN ( Virtual Private Network ) such as IPSec for exchange of meteorological data. This is needed when the nature of the information is sensitive enough to warrant out any sniffing by an outsider. Most NMCs are now connected to the Internet. The Internet connection is in most cases : - reliable. The ISP (Internet Service Providers) propose connection to the Internet. They are operated just like others leased lines and are therefore as reliable as the lines. However it must be noted that no end-to-end SLA (Service Level Agreement) could be defined on the Internet. - powerful. The Internet connection is often a high speed connection. - secured. The NMCs should (and even must) be protected by firewalls. Therefore, the Internet is becoming a possible media to complement the current GTS private infrastructure. The only real application and host independent VPN solution is IPSec. Therefore, for WMO use IPSec is recommended as the VPN solution. But in order to guarantee interoperability between NMCs without redefining each time the protocols to use the following implementation solution is suggested: - Tunnel mode : as IPSec will be the most probably configured on routers, firewall or dedicated boxes, and taking into account that neither encryption nor authentication are mandatory on LAN, Tunnel mode is the most appropriate solution - AH ( Authentication Header) should not be used - ESP (Encapsulting Security Paylod) is used for both authentication and encryption o Authentication should be done with HMAC-MD5-96

o Encryption should be done with DES - Pre-Shared secrets : Certificated is probably a more elegant solution, but, in practical, more difficult to implement in WMO situation. In order for two NMCs to establish a VPN link they must : - confirm the protocols to be used (confirm use of tunnel mode, DES, MD5, pre-shared secrets) - define the pres-shared secret. This password must be define and be the same on both sides - confirm the VPN platform to be used - agree on IP addresses to exchange on the link - modify filter rules on the firewall. The following rules o UDP port 500 is used for ISAKMP o IP protocol number 50 (ESP protocol) - implement the define configuration - test Once everything running, the main risk is the potential failure of the virtual link created. References: 1.Recommended Procedures for Internet-based connections between RTHs and NMCs (VPN, IPSec) by Rémy Giraud – Invited Consultant, COMMISSION FOR BASIC SYSTEM OPAG ON INFORMATION SYSTEMS & SERVICES Expert Team on Enhanced Use of Data Communication Systems Montreal, Canada, May Use of TCP/IP on the GTS – ATTACHMENT –II.15