Upload
teagan-spittle
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Progress ReportProgress Report from ET-CTS from ET-CTS(Expert Team on WIS-GTS Communication Techniques and (Expert Team on WIS-GTS Communication Techniques and
Structure)Structure)
Doc. 4.3 (1) Presentation versionDoc. 4.3 (1) Presentation version
ICG-WIS-6 (Seoul, 22-26 February 2010) Hiroyuki ICHIJO (Co-chair of ET-CTS)
Please consider our Earth environment before printing
ET-CTS Membership and Key DeliverablesET-CTS Membership and Key Deliverables
Co-chairsHiroyuki ICHIJORemy GIRAUD
7 Core MembersRA I : 1, RA II : 1, RA III : 1
RA IV : 2, RA V : 1, RA VI : 1
20 Associate ExpertsRA I : 4, RA II : 4, RA III : 1
RA IV : 1, RA V : 3, RA VI : 5RAs II & VI (Russia) : 2
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]
20 Task Groups20 Task Groups
Key DeliverablesKey Deliverables
Tentative ScheduleTentative 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
Consolidation of two IMTN Consolidation of two IMTN cloudsclouds
Migration process forming WIS core network
IMTNcloud I
IMTNWIS core
network
IMTNcloud II
IMTN
Exeter
SofiaMelbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Network INetwork I
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New DelhiMoscow
Network IINetwork II
Exeter
SofiaMelbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Network INetwork I
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New DelhiMoscow
Network IINetwork II
Consolidation was completed in Nov 2009
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Exeter
Sofia
Melbourne
Buenos Aires
TokyoBeijing
Nairobi
Washington
Jeddah
Prague
Toulouse
Dakar Algiers
Offenbach
Brasilia
Cairo
New Delhi
IMTN cloud
Moscow
RA I
RA II
RA III
RA IV
RA V
RA VI
Study of GISC network requirementsStudy 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.
GISC
Unicast-oriented network
GISC GISC GISC
Responsibility Area
GISC
Multicast-oriented network
GISC GISC GISC
Responsibility Area
Multicast group
Duplicatedtransmissio
n
Study of GISC network requirementsStudy 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 requirementsStudy 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 requirementsStudy 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 requirementsStudy of GISC network requirements
Architecture and flows
GISC #1
GISC #2
GISC #3GISC #4
GISC #5
GISC #6
GISC #7
AMDCN : Area Meteorological Data Communication Networks
Study of GISC network requirementsStudy of GISC network requirements
Balanced model (Example case of 4 GISCs, total volume of 8GB)
WIS core network
(Full-meshed topology)
Responsible area #1
AMDCN #1
GISC #1
2GB Responsible area #2
AMDCN #2
GISC #2
2GB
Responsible area #3
AMDCN #3
GISC #3
2GB Responsible area #4
AMDCN #4
GISC #4
2GB
2GB2GB2GB
2GB
2GB2GB
Incomingdaily
volume
Outgoingdaily
volume
Necessaryport speed
GISC #1 6 GB 6 GB
Bandwidthappropriatefor 6GB/day
GISC #2 ditto ditto ditto
GISC #3 ditto ditto ditto
GISC #4 ditto ditto ditto
Study of GISC network requirementsStudy of GISC network requirements
Unbalanced model (Example case of 4 GISCs, total volume of 8GB)
Incomingdaily
volume
Outgoingdaily
volume
Necessaryport speed
GISC #1 3 GB 15 GB
Bandwidthappropriatefor 15GB/day
GISC #2 7 GB 3 GB
Bandwidthappropriatefor 7GB/day
GISC #3 ditto ditto ditto
GISC #4 ditto ditto ditto
WIS core network
(Full-meshed topology)
Responsible area #1
AMDCN #1
GISC #1
5GB Responsible area #2
AMDCN #2
GISC #2
1GB
Responsible area #3
AMDCN #3
GISC #3
Responsible area #4
AMDCN #4
GISC #4
1GB1GB
1GB1GB
1GB5GB5GB5GB
1GB1GB1GB5GB
1GB
1GB
Investigation of blog technologiesInvestigation 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 technologiesInvestigation of blog technologies
Empirical outcome(1) 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:
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.