![Computing Sciences at Berkeley Lab Navigation Banner [Load to Use]](/gifs/CShomebanner.gif)
|
|
|
Support of Prototype Reliable Multicast Development and Deployment in
the Comprehensive Nuclear-Test-Ban Treaty Global Communications Infrastructure
|
|
Background Papers PublishedPresentations
Deb Agarwal (PI) - LBNLMike Bennett - LBNLThe Comprehensive Test Ban Treaty Organization (CTBTO) is putting into place an International Monitoring System (IMS). The IMS is a network of globally-distributed sensors that provide monitoring coverage of the earth, oceans and atmosphere. There are 50 primary seismic stations sending continuous data and 120 auxiliary seismic stations sending waveform segments. There are also 60 infrasound arrays sending continuous data and 6 hydroacoustic arrays sending continuous data. In addition, there are 5 "T-Phase" stations which are seismic stations on steep-cliffed coasts of continents or islands which are used to detect hydroacoustic signals: from a communications point of view the T-phase stations are like auxiliary seismic stations. Finally there are 80 radionuclide stations whose communications requirements are minimal in volume; perhaps two short e-mail messages a day. In total, the International Data Centre (IDC) will collect and archive over 1,500 channels of data from the IMS stations, comprising a daily volume of 5-10 Gbytes. The IDC will serve as the primary central repository of all data from the IMS sensors. In order to communicate with the IMS stations the CTBTO is building a private network composed of frame relay and satellite links called the Global Communications Infrastructure (GCI).
Topologically, the GCI is configured as a two-level tree rooted at the IDC. The major network nodes are the IDC in Vienna and four (or more) satellite hubs in Germany, Italy (2) and the United States. High-speed terrestrial Frame Relay private virtual circuits (PVC) with integrated services digital network (ISDN) backups connect the IDC to each of the hubs. There are five space satellites; each VSAT hub provides communication for a different satellite. Typically, an IMS station is connected by a VSAT (Very Small Aperture Terminal earth station) to one of the satellites and thus one of the five hubs. The NDC's are connected to the GCI via VSAT, frame relay, or the Internet. There are also three methods of connecting IMS stations to the GCI. These methods are called respectively the Basic Topology, Partitioned Subnetwork and Independent Subnetwork. In the Basic Topology, the monitoring data originating at an IMS station uses a GCI VSAT satellite link to a VSAT hub, and from there, it travels a GCI Frame Relay PVC to the IDC. In a Partitioned Subnetwork, the physical connection of the GCI at the IMS stations is the same as in the Basic Topology except that data from the IMS stations is routed through the National Data Centre (NDC) before going to the IDC. In an Independent Subnetwork, the GCI does not have a direct connection to the IMS stations. The network between the IMS stations and the NDC is installed and operated by the Member State. Data from the IMS stations in an Independent Subnetwork is routed through the NDC before going to the IDC. The GCI is expected to meet stringent performance requirements. For example, the one-way delay target is 5 seconds or less for at least 99.5% of the time. The virtual circuit availability is set at 99.5% over one year.
The IMS data will be transmit across the GCI using proprietary IDC application protocols. These application protocols are the CD-x and IMS-x protocols (the x when replaced by a number identifies a particular version of the protocol). The CD-x protocol will provide reliable transmission of continuous data from primary seismic, hydroacoustic, and infrasound sensors. Non-continuous data from the IMS stations and the IDC will likely be sent using the IMS-x protocol. The IMS-x protocol will use a combination of conventional e-mail, ftp, and WWW.
The CD-1 protocol, which is already implemented, uses the TCP protocol to send data. The CD-1.1 protocol has been designed to improve the data transmission reliability and will likely replace the CD-1 protocol. The CD-2 protocol is being designed now and is expected to eventually replace the CD-1 and CD-1.1 protocol. The CD-2 and CD-1.1 protocols provide the mechanisms for determining what the receiver is missing and recovering the missing data. In addition, the CD-2 and CD-1.1 protocols will be responsible for forwarding data at the IDC and the NDC's of Independent Subnetworks and Partitioned Subnetworks. All of the IMS data must be received at the IDC regardless of whether it is via the Basic Topology, a Partitioned Subnetwork, or an Independent Subnetwork. The IDC is also responsible for forwarding this data to Member States that request the data or data product.
Some states parties want access to some or all of the sensor data as it is collected.
The prototype IDC located at the Center for Monitoring Research has been in operation collecting sensor data since January, 1995.
If the IMS data is sent first to the IDC and then disseminated to the states parties there are several potential problems. The first problem is that the IDC becomes a single point of failure for the data. Also, the IDC networks would be handling many copies of the data since there would be one incoming and some number of outgoing streams for each data source. An additional problem is that gating the data through the IDC (perhaps before it is received by the state that generated the data) will make the monitoring of the sensors difficult for the states parties when the IDC is down or unavailable. With this issue in mind several of the states parties are likely to funnel their state's data through a National Data Center (NDC) before sending it to the IDC. Unfortunately, incorporation of an NDC into the data path to the IDC compounds the failure probability since data will be unavailable if either the NDC or the IDC is down or unavailable.
If, alternatively, the IMS sites send the data using reliable multicast, all sites that are part of the multicast would receive the data at the same time. This could be used to simultaneously send data to the IDC and a backup IDC and/or to the NDC's. Use of multicast could reduce the concern regarding the single point of failure and provide an efficient means of disseminating the data to the IDC and to the interested states parties. In addition, it would allow the creation of multiple data repositories; improving the fault-tolerance of the system and the ability of the IDC to recover from failures without loss of data. The IDC personnel are likely to be justifiably concerned about using a new communication protocol. However, the CD-1.1 protocol will be designed to allow the use of either unicast or multicast as the data transport mechanism so multicast can be enabled gradually in the network. This would allow any problems to be addressed without compromising the availability of the data.
There are several tasks before reliable multicast can be a reality within the GCI. The first task was a study of the GCI requirements to determine whether reliable multicast communication is needed. In this phase we worked with the IDC to understand the constraints that the protocol needed to satisfy. Papers describing the results of the study were published at the Seismic Research Symposium and at Working Group B in 1999. The next task was to decide on an appropriate protocol and create a document that describes, in detail, this protocol and how it is implemented. The RMP protocol was selected in this phase as the most likely candidate protocol. The SAIC and Telcordia personnel working on the CD-1 and CD-1.1 protocols began work on a prototype implementation of a reliable multicast enabled CD-1 using RMP. This was demonstrated and is described at the 2000 GCI Workshop. The next phase of the process has been to begin design and implementation of reliable multicast capabilities in the CD-1.1 protocol. This effort is currently underway at SAIC and Telcordia and current progress was reported at the 2002 GCI Workshop.
The intent of this project is to evaluate the appropriateness of using reliable multicasting in the GCI. This project also includes consultation regarding implementation of a reliable multicast protocol.
D. Agarwal, "Discussion of Reliable Multicast Deployment Progress for the Continuous Data Protocol," Proceedings of the 23rd Annual DoD/DOE Seismic Research Review: Worldwide Monitoring of Nuclear Explosions, 2-5 October 2001, Jackson Hole, WY.
"Initial Results of the CD-1 Reliable Multicast Experiment,"
D. Agarwal, R. Stead, B. Coan, J. E. Burns, N. Shah, N. Kyriakopoulos,
Published at the Global Communications Infrastructure (GCI)
Workshop, Vienna, Austria, 2-4 October 2000.
"Multicasting in the GCI - A Preliminary Report," Published at the May meeting of Working Group B, This is a limited distribution paper of the CTBT available on the Expert's Communication System as CTBT/PTS/INF.157, 29 April 1999.
"Multicasting in the GCI - A Report of Study Results," Published at the August meeting of Working Group B, This is a limited distribution paper of the CTBT available on the Expert's Communication System as CTBT/WGB/TL-3/9/Rev.1/Amend.1, 2 September 1999.
D. Agarwal, "Using Multicast in the Global Communications Infrastructure for Group Communication," Proceedings of the 21st Seismic Research Symposium: Technologies for Monitoring the Comprehensive Nuclear-Test-Ban Treaty, 21-24 September 1999, Las Vegas, Nevada.
An article was written by Jon Bashor of LBNL about the project.
"Discussion of Transport Protocol and Network Monitoring Advances," Presented at the Experts Group on GCI Technology Refreshment, Vienna, Austria, May, 2003.
"Next Generation Systems," Presented with M. Harris at the 2003 PMR Review, Cape Canaveral, Florida, May 2003.
"CD-1.1 Reliable Multicast," Presented at the Air Force Technical Applications Center (AFTAC), Cocoa Beach, Florida, May 2003.
"IP Multicast Deployment," Presented by W. Nickless, at the Air Force Technical Applications Center (AFTAC), Cocoa Beach, Florida, May 2003.
"CD-1.1 Reliable Multicasting: Status and Plans," Presented at the Global Communications Infrastructure (GCI) Workshop, Vienna, Austria, 21-25 October 2002 (longer version of same talk).
"Discussion of Reliable Multicast Progress for the Continuous Data Protocol," Presented at the Global Communications Infrastructure (GCI) Workshop, Vienna, Austria, 1-3 October 2001.
"Initial Results of the CD-1 Reliable Multicast Experiment," Presented at the Global Communications Infrastructure (GCI) Workshop, Vienna, Austria, 2-4 October 2000.
"Multicasting in the GCI - A Report of Study Results," Presented at the meeting of Working Group B, September 1999.
"Using Multicast in the Global Communications Infrastructure for Group Communication," Presented at the 21st Seismic Research Symposium: Technologies for Monitoring the Comprehensive Nuclear-Test-Ban Treaty, 23 September 1999, Las Vegas, Nevada.
"The Comprehensive Nuclear Test-Ban Treaty and Multicasting," Presented as part of the LBL Summer Student Series, August 1999.
"Multicasting in the GCI - A Preliminary Report," Presented at the May meeting of Working Group B, May 1999.
 Lawrence Berkeley National Laboratory Home Page. |
 DOE NEMRE Home Page |
 Distributed Systems Department Home Page. |
 Collaboration Technologies Home Page. |
This document was last updated on March 03, 2004, and is located at http://dsd.lbl.gov/~deba/CTBTO/homepage.html.
To report Web page problems, e-mail webmaster@dsd.lbl.gov. To request further information about Distributed Systems Department activities, e-mail DAAgarwal@lbl.gov. For suggestions about content, e-mail DAAgarwal@lbl.gov.
Support Credits identify the funding sources and the organizational context of the work described in this document.
Disclaimers and Legal Notices apply to this document and its uses, and access to and uses of the system on which it resides at LBL. Like all Web pages, it may be linked with pages and systems beyond LBNL jurisdiction. Their contents and uses are the responsibility of their authors and administrators. .
Deb Agarwal is responsible for this document.
