Transcript Presentation

Progress Report from ET-CTS
(Expert Team on WIS-GTS Communication Techniques and Structure)
Doc. 4.3 (1) Presentation version
Please consider our Earth environment before printing
ICG-WIS-6 (Seoul, 22-26 February 2010)
Hiroyuki ICHIJO (Co-chair of ET-CTS)
ET-CTS Membership and Key Deliverables
Co-chairs
Hiroyuki ICHIJO
Remy GIRAUD
7 Core Members
RA I : 1, RA II : 1, RA III : 1
RA IV : 2, RA V : 1, RA VI : 1
20 Associate Experts
RA I : 4, RA II : 4, RA III : 1
RA IV : 1, RA V : 3, RA VI : 5
RAs II & VI (Russia) : 2
20 Task Groups
Key Deliverables
Confirm arrangements for consolidation of
two IMTN clouds (migration of the current
“cloud 1” to the RMDCN)
[Target : Oct 2009]
Guidance on “push” & “pull” technologies
for use in WIS, including recommendations
on handling of high priority information to
support hazard warning
[Target : May 2010]
Publication for consultation on
recommendations for changes to TCP/IP
practices, including advice on adoption of
IPv6
[Target : Jun 2010]
Guidance on administrative and contractual
aspects of data communication services for
WIS implementation
[Target : Jul 2010]
Tentative Schedule
mid-March 2010 : Distribution of drafts developed by task groups
within ET-CTS
late April 2010
: Physical meeting of ET-CTS and review of the drafts
May 2010
: Pre-coordination with other OPAG-ISS teams
May to July 2010 : Finalize the ET-CTS report including Recommendations
July 2010
: Submission of the report to ICT-ISS and ICG-WIS
after CBS-ext.2010 : Start of another working cycle with refined TORs
Progress of Prioritized Tasks
Consolidation of two IMTN clouds
Network I
Tokyo
Melbourne
IMTN
cloud II
IMTN
cloud I
Washington
Brasilia
Buenos Aires
Beijing
Sofia
Prague
Moscow
New Delhi
Exeter
Jeddah
Offenbach
Network II
Nairobi
Toulouse
IMTN
Dakar
Cairo
Algiers
New Delhi
IMTN
WIS core
network
Moscow
Jeddah
RA II
Beijing
Tokyo
Sofia
RA VI
Prague
Washington
Exeter
IMTN cloud
Offenbach
RA IV
Toulouse
Brasilia
Migration process forming
WIS core network
Buenos Aires
RA III
Cairo
Dakar
Nairobi
RA I
Algiers
Melbourne
RA V
Consolidation was completed in Nov 2009
Study of GISC network requirements
Background #1
 The Improved MTN (IMTN) is currently operating on a single coordinated
Multi-Protocol Label Switching (MPLS) network. MPLS provides any-to-any
connectivity at network level. Since a WIS core network will be established
on the IMTN, it is easy to realize the full-mesh topology for synchronization
among GISCs.
 To minimize duplicated traffic, multicast-oriented architecture on IPv6 is
desirable for synchronization. However it is premature at the moment. The
current IMTN is on unicast based MPLS. Thus it is expected that traffic on
the WIS core network handled by GISCs will considerably increase.
 Network capacity of each GISC will have to be expanded in collaboration
with others.
Multicast-oriented
network
Unicast-oriented
network
Duplicated
transmission
GISC
GISC
GISC
GISC
GISC
GISC
GISC
Multicast group
Responsibility
Area
Responsibility
Area
GISC
Study of GISC network requirements
Background #2

The Appropriate maximum number of GISCs has come up for discussion
repeatedly since the initial stage called as FWIS:
[Extraction from the final report of CBS-ext.02, Annex IV]
Several (perhaps four to 10) centres would serve as GISCs. Each GISC would
have a defined area of responsibility. GISCs would usually be located
within or closely associated with a centre running a global data
assimilation system or having some other global commitment, such as a
WMC.
[Extraction from ET-CTS outcome reported to ICG-WIS-3 in 2006]
Correlation between the number of GISCs and reasonableness of full-mesh
topology of a WIS core network:
From the practical and relative evaluation, the full-mesh can be appropriate
on the assumption that the number of GISCs would be less than 7 inclusive.
In case of more GISCs, the full-mesh should be avoided.

However 13 GISCs candidates have been identified as of the end of Nov
2009.
Study of GISC network requirements
Main task
 To consider required GISC bandwidth on the core network
considering not only bulk but also peak traffic
 To study smooth evolution process in gradual participation of
operational GISCs
Additional task on a possible basis
 To study further to clarify the appropriate maximum number
of GISCs from the practical view of network bandwidth
requirements
Study of GISC network requirements
Progress

The task group devised an unbalanced model of full-meshed topology
to find out required GISC bandwidth practically. It is to simulate
unbalanced conditions between incoming and outgoing traffic,
considering the pragmatic case of different data volumes from
individual responsible areas.

The group developed a convenient tool for trial calculation for the
bandwidth based on the unbalanced model. It is able to calculate the
required bandwidth corresponding to total daily traffic for global
exchange, adjusting realistic parameters.

Practical required bandwidth will be estimated as long as the daily
volume is accurately estimated. It is expected that ET-OI will
estimate the daily volumes at present and in five years.

Regarding the maximum number of GISCs, the group will challenge
the issue to find an appropriate number from the practical view in the
process of the study on the required bandwidth.
Study of GISC network requirements
Architecture and flows
GISC #4
GISC #3
GISC #5
GISC #2
GISC #6
GISC #1
AMDCN : Area Meteorological Data Communication Networks
GISC #7
Study of GISC network requirements
Balanced model (Example case of 4 GISCs, total volume of 8GB)
2GB
Responsible area #1
2GB
AMDCN #1
GISC #1
2GB
2GB
2GB
Responsible area #2
AMDCN #2
GISC #2
2GB
2GB
Incoming
daily
volume
Outgoing
daily
volume
Necessary
port speed
2GB
GISC
#1
6 GB
6 GB
Bandwidth
appropriate
for 6GB/day
GISC
#2
ditto
ditto
ditto
GISC
#3
ditto
ditto
ditto
GISC
#4
ditto
ditto
ditto
WIS core network
(Full-meshed topology)
GISC #3
GISC #4
AMDCN #3
2GB
Responsible area #3
AMDCN #4
2GB
Responsible area #4
Study of GISC network requirements
Unbalanced model (Example case of 4 GISCs, total volume of 8GB)
5GB
Responsible area #1
1GB Responsible area #2
AMDCN #1
AMDCN #2
GISC #1
GISC #2
1GB
1GB 1GB
5GB
5GB
5GB
1GB
1GB
1GB
1GB
1GB
(Full-meshed topology)
GISC #3
GISC #4
AMDCN #3
AMDCN #4
Responsible area #3
Outgoing
daily
volume
5GB
WIS core network
1GB
Incoming
daily
volume
1GB Responsible area #4
GISC
#1
3 GB
15 GB
Necessary
port speed
Bandwidth
appropriate
for
15GB/day
GISC
#2
7 GB
3 GB
Bandwidth
appropriate
for 7GB/day
GISC
#3
ditto
ditto
ditto
GISC
#4
ditto
ditto
ditto
Investigation of blog technologies
Progress


Japan (JMA) has been investigating usability of blog-based technologies
for notification of priority messages and also GISC synchronization of
global data/products in cooperation with Brazil (INPE) and China (CMA).
The following items have already been tested and the empirical outcome
was reported at the ET-WISC meeting (2-5 Feb 2010).
(1) File synchronization like podcast using a pull-based protocol
for getting web feed of Atom and RSS
(2) Notification of priority messages using a push-based protocol
of the Atom Publishing Protocol (AtomPub) for posting blog
Investigation of blog technologies
Empirical outcome
Blog technologies are not appropriate for “WIS part A” because it would
be difficult to introduce sharply new technologies into the existing GTS.
Also the blog technologies would be not necessarily appropriate for GISC
synchronization.
(2)
On the other hand, they are very useful for “WIS Part B”.
(3)
The following usage are desirable:
(1)
Data providers provide users with data on a near-real-time basis
over the Internet;
 Data providers provide users with data at intervals over the
Internet;
 Data providers receive a priority message from the GTS, and
then post it to their blog server on the Internet;
 Timely delivery service can also be implemented by "pull"
mechanism using the file synchronization of blog technologies.

Development of a list of synchronization protocols among GISCs
ET-CTS will develop a list of protocols for GISC synchronization
considering requirements from ET-WISC.