Descriptions of Potential Cloud Tenant Applications

lynxfatkidneyedNetworking and Communications

Oct 26, 2013 (3 years and 8 months ago)

141 views









Descriptions of Potential
Cloud Tenant Application
s






Common Support Services Cloud
Request
f
or Information (RFI)
Attachment 2


DRAFT Version
1.
8








V
ersion 1.
8

Date:
9/
11
/2012



i



Change History


Revision

Effective
Date

Sections
Affected

Changes Made

1.
6

9/7
/2012

All

Final

draft

1.7

9/10/2012

All

Updated with comments

1.8

9/11/2012

All

Updated with comments from adjudication
meeting











V
ersion 1.
8

Date:
9/
11
/2012



ii


Table of Contents

SECTION 1:

INTRODUCTION

................................
................................
................................
..........

1

SECTION 2:

CSS CLOUD INFRASTRUC
TURE CONSIDERATIONS

................................
............

1

2.1

P
OTENTIAL
T
ENANTS

................................
................................
................................
...............

1

2.2

S
COPE

................................
................................
................................
................................
....

2

2.3

C
LOUD
D
EPLOYMENT

M
ODEL

................................
................................
................................
...

2

2.4

C
LOUD
C
HARACTERISTICS

................................
................................
................................
.......

3

2.5

I
NTEGRATION
................................
................................
................................
...........................

3

2.6

T
RANSITION
................................
................................
................................
.............................

3

2.7

R
ISKS

................................
................................
................................
................................
.....

3

2.8

S
TANDARDS AND
O
PEN
S
OURCE

................................
................................
..............................

4

SECTION 3:

OPERATIONAL CONSTRAI
NTS

................................
................................
................

4

3.1

FAA

F
ACILITY
................................
................................
................................
..........................

5

3.2

V
ENDOR
P
ROVIDED
L
OCATION

................................
................................
................................
.

5

3.3

D
EVELOPMENT AND
T
ESTING
E
NVIRONMENT

................................
................................
.............

5

3.4

O
PERATIONAL
E
NVIRONMENT

................................
................................
................................
...

5

3.5

M
AINTENANCE

................................
................................
................................
.........................

5

3.6

I
NFORMATION
S
YSTEM
S
ECURITY

................................
................................
.............................

5

3.7

M
ONITORING

................................
................................
................................
...........................

6

3.8

T
RAINING

................................
................................
................................
................................

6

3.9

C
APACITY
P
LANNING

................................
................................
................................
...............

6

3.10

FAA

T
ELECOMMUNICATIONS
I
NFRASTRUCTURE
(FTI)

................................
................................

7

3.11

S
YSTEM
W
IDE
I
NFORMATION
M
ANAGEMENT
(SWIM)

................................
................................

7

SECTION 4:

COMMON SUPPORT SERVI
CES

................................
................................
...............

8

4.1

W
EB
M
APPING
C
OMMON
S
ERVICE

................................
................................
............................

8

4.2

C
OMMON
S
UPPORT
S
ERVICES FOR
W
EATHER

................................
................................
..........

8

4.2.1

Services

................................
................................
................................
............................

9

4.2.2

Software

................................
................................
................................
............................

9

4.2.2.1

Third
Party Software

................................
................................
................................
............

10

4.2.3

Processing

................................
................................
................................
......................

11

4.2.4

Storage

................................
................................
................................
...........................

12

4.2.5

Network
Requirements

................................
................................
................................
...

12

4.2.5.1

LAN
................................
................................
................................
................................
......

12

4.2.5.2

WAN


FTI

................................
................................
................................
...........................

12

4.3

A
ERONA
UTICAL
I
NFORMATION
M
ANAGEMENT

................................
................................
..........

12

4.3.1

Services

................................
................................
................................
..........................

12

4.3.2

Software

................................
................................
................................
..........................

13

4.3.3

Processi
ng

................................
................................
................................
......................

13

4.4

S
CALABILITY

................................
................................
................................
..........................

14

4.5

S
ECURITY

................................
................................
................................
.............................

15

4.6

C
OMMON
M
ANAG
EMENT
P
LATFORM

................................
................................
.......................

15

SECTION 5:

OTHER FAA SYSTEMS

................................
................................
............................

15

5.1

I
NTEGRATED
E
NTERPRISE
S
ERVICES
P
LATFORM
(IESP)

................................
.........................

15

5.2

N
EXT
G
EN
W
EATHER
P
ROCESSOR
(NWP)

................................
................................
..............

16

ACRONYMS

................................
................................
................................
................................
.........

17




V
ersion 1.
8

Date:
9/
11
/2012



iii



List of
Tables

Table 1 Examples of Virtual Machine Estimates for Specific CSS
-
Wx products

................................
.

11

Table 2 CSS
-
Wx Product Count and Total Virtual Machine Estimates for CSS
-
Wx Processing Load

11

Table 3 Summary of CSS
-
Wx File Transactions and Storage

................................
.............................

12

Table 4 AIMMS2 Estimated Infrastructure needs

................................
................................
.................

14

Table 5 Example of modern virtualized data centers w
ithin FAA today

................................
...............

16


List of Figures

Figure 1 Notional CSS Cloud Infrastructure (IaaS) hosting CSS
programs

................................
...........

2

Figure 2 Notional Development and Operational Environments

................................
............................

4

Figure 3 Notional CSS Cloud Interfaces for some CSS programs

................................
.........................

8



V
ersion 1.
8

Date:
9/
11
/
2012



1


Section 1:

Introduction

The purpose of this document is to provide
additional details regarding the FAA’s
needs

for
a potential

Common Support Services (CSS) Cloud solution. It contains the following
sections:



Section 2:
CSS Cloud
Infrastructure Considerations



an overview of the scope
and

key constraints
for
a

CSS Cloud;



Section 3: Operational Constraints



description
s

of physi
cal constraints

and
dependencies;



Section 4: Common Support Services



descriptions of
a

CSS Cloud’s
potential
tenant applications, Common Support Services for Weather (CSS
-
Wx) and
Aeronautical Information Management
Modernization
(AIM
M
);



Section 5:
Other FAA Systems



descriptions of other FAA systems that
may

be
considered
as

cloud tenants in the future, Integrated Enterprise Services Platform
(IESP) and
Next Generation Air Transportation System (
NextGen
)

Weather
Processor (NWP).


Section 2:

CSS Cloud Infrastr
ucture Considerations

2.1

Potential Tenants

A

CSS Cloud Infrastructure
may

be
a

new
virtualization platform
or extend an existing one
to facilitate the development, integration, and testing of
some

potential
cloud tenant
applications

such
as
CSS
-
Wx and AIMM
. Deployment of
a

support cloud
may

be followed
by
the
deployment of
a

CSS Cloud in the operational environment.
A

CSS Cloud
may

deliver all desired cloud features (namely broad network access, resource pooling, and
measured services) to enable tenant appl
ications to reach initial operating capability (IOC).

The

CSS Cloud Infrastructure Provider
may also

support the

migration of
the following
legacy weather programs to the CSS Cloud

in the future
:



Weather Message Switching Center Replacement (
WMSCR)



Automat
ed Weather Observing System (AWOS) Data Acquisition System (ADAS)
which includes the
Regional ADAS Support Processor (RASP)

WMSCR and RASP

are
currently hosted on a virtualization platform (IESP).

In the future,
other programs

such as NWP may also be deplo
yed on
a

CSS Cloud.

V
ersion 1.
8

Date:
9/
11
/
2012



2


2.2

Scope


Figure
1

Notional

CSS Cloud Infrastructure (IaaS) hosting CSS programs

T
he scope of
a

CSS Cloud
may

be limited to Infrastructure as a Service (IaaS) only (see
Figure
1

Left panel). The FAA may consider the Platform as a Service (PaaS) model in the
future (
Figure
1

M
iddle panel
). However, the FAA may not
consider the Software as a
S
ervice (SaaS) as a viable model

(
Figure
1

Right panel).

The

CSS Cloud Infrastructure Provider

may
:



Acquire hardware and cloud management software/hypervisors



Administer

hardware and cloud management software/hypervisors



Develop

an integr
ation strategy to deploy
some programs (e.g.,
CSS
-
Wx and
AIM
M
)

software to
CSS Cloud Infrastructure



Develop

a migration strategy to move infrastructure responsibility to

the

future
National Airspace System (
NAS
)

Cloud

Each of the

CSS programs

may
:



Develop and p
rovide
their
own
virtual machine (
VM
)

images/snapshots to be
deploy
ed

to CSS Cloud Infrastructure



Be responsible for

procurement of
licenses

for software installed on the VMs



Be responsible for
content
maintenance of CSS
-
Wx VM images/snapshots



Not procure any hardware

other than that for

lifecycle monitoring & control

The
administration
of the system
may

be accomplished
by
the FAA or a

C
ontractor
.


2.3

Cloud
Deployment Model

The FAA Cloud deployment model choices remain within the Private Cloud model. Public
Cloud is not considered due to the required connectivity to the
FAA
Telecommunications
Infrastructure (
FTI
)
. Some other deployment models that may be considered later are as
follows:

V
ersion 1.
8

Date:
9/
11
/
2012



3




Community
C
loud
-

A Cloud

provisioned for exclusive use by a specific community
of cons
umers from organizations that have shared concerns



H
ybrid
C
loud

-

A Cloud

composition of two or more distinct
C
loud infrastructures
(private, community) that remain unique entities, but are bound together by
standardized or proprietary technology that enables data and application portability


2.4

Cloud Charact
eristics

A

CSS Cloud
may

deliver

the following
C
loud
operating
characteristics:



Broad network access to
available
resources
over dedicated local or metropolitan
area network. Examples would be the FTI Operational IP network, or through
approved secure
communications channels (i.e. N
AS
E
nterprise
S
ecurity
G
ateway
)
.



Resource pooling to serve multiple consumers with resources
which
could

be
dynamically assigned and reassigned on demand
.



Measured service
can

allow for automatic control of
resource use by le
veraging a
metering capability at some level of abstraction
. This metering capability would
have to be
appropriate to the type of service (e.g., storage, processing, bandwidth,
and active user accounts)
.


Resource usage
could

be monitored, controlled, an
d
reported, providing transparency for both the provider and consumer of the utilized
service
.


2.5

Integration

The
CSS Cloud Infrastructure Provider
would

support
the software implementation
strategy and timeline for
CSS
software

programs implementation.

Th
e CSS programs
would

be implemented as individual procurements.
The CSS Cloud infrastructure provider
would

address issues identified by the CSS programs’ sof
tware implementation
contractors

relating to

a

CSS Cloud
infrastructure.



2.6

Transition

A

CSS Cloud Infrastructure could

be transitioned to the NAS Cloud in the future to

support
various FAA programs

in addition to the CSS programs and other systems described in
this document. The CSS Cloud Provider
needs to

align its design with the FAA Cloud

Strategy, and
support
the
transition from CSS Cloud to NAS
Cloud
.


2.7

Risks

The CSS Cloud provider
would need to

be prepared to address
at least the

risks listed
below. They
would

also
need to
be prepared to identify and track
additional

risks.
Based
on th
e
National Institute of Standards and Technology (
NIST
)

Special Publication 800
-
146

(
Cloud Computing Synopsis and Recommendations

and the

Recommendations of the
NIST),

some
Cloud

computing risks specific to IaaS
Cloud
s include the following:



V
ersion 1.
8

Date:
9/
11
/
2012



4




Robustness of VM
-
level Isolation

Virtual machines are allocated for different consumers from a common pool.
Consumers must be protected from potential eavesdropping or tampering on the
part of other, possibly malicious, consumers.



Features for Dynamic N
etwork Configuration for Providing Isolation

Network infrastructure (e.g., routers, cables, network bandwidth, etc.) that support
each running virtual machine (VM) is also allocated from a common pool of
networking resources. When a VM is allocated by a C
loud for a consumer, a
network path through the Cloud provider’s infrastructure must be configured to allow
that VM to communicate with the originating consumer. It must also be configured
to possibly communicate with arbitrary external entities on the In
ternet. There is a
risk that the Cloud network
would

allow a consumer to observe any packets sent in
the Cloud by other consumers; thus creating potential interferences between
networks belonging to different consumers


2.8

Standards and

Open Source

A

CSS Cl
oud Infrastructure
would

be built on standards that facilitate interoperability and
portability. The components used should enable an architecture which can be extended
and not replaced to add new functionality. Open standards such as Open Virtualization
F
ormat (OVF) which describes criteria for virtual machine descriptions may be considered.
To reduce vendor lock
-
in, for any custom development or integration, development
languages that are not vendor specific should be used.



Section 3:

Operational Constraints




Figure
2

Notional Development and

Operational Environments

V
ersion 1.
8

Date:
9/
11
/
2012



5



3.1

FAA Facility

An

Infrastructure as a Service (Iaa
S)
Cloud

would

meet all relevant facility requirements if
installed on a Federal Aviation Administration (FAA) property
. Specific Requirements
such
as FAA
-
STD
-
019
Lightning Protection
;

Grounding, Bonding, and Shielding for Facilities;

and FAA
-
G
-
2100H
Electronic Equipment

would apply
.



3.2

Vendor Provided Location

A vendor provided location
may

be acceptable to host
an

IaaS

Cloud
if it meets the

FAA
requirements for security and

performance
,

and can be proven to be affordable in
accessing the private FAA Telecommunications network.
Potential

tenant applications
would

be exchanging large amounts of data with consumers inside
and outside of the FAA.
The cost of bandwidth for the telecommunications services
may

be a consideration for the
location of
an

IaaS

Cloud
.



3.3

Development and Testing Environment

An

IaaS

Cloud

would

support a development and
testing
environment.
T
enant
CSS
programs
software development contractors
would

require a development environment
that can be accessed remotely. Each development area
would

be separate and secure
from others on
an

IaaS

Cloud
. The testing environment
would

be use
d

to
test the

tenant
’s

software once
it has completed
developed
but

prior to making
it
operational.


3.4

Operational Environment

An

IaaS

Cloud

would

consider

at least two geographically diverse locations

for continuity
of operations
.
IaaS

tenants
would

require an operational env
ironment for their respective
virtual machines.


3.5

Maintenance

An

IaaS

Cloud

would

be maintained to ensure the availability requirements of tenant
applications are met. The maintenance of th
is

equipment
would

include everything
needed to ensure
an

IaaS

Cloud

is functioning properly. The maintenance
would

include
replacement of failed parts and
Line Replaceable Units (
LRUs
),

as well as
,

preventive
maintenance. The availability requirements of tenant applications
for the IaaS
infrastructure
would be

at least .999 of availability

at all times
.


3.6

Information System

Security

A

CSS Cloud

would

comply with Information System Security for physical, data, and
network security in accordance with

all applicable FAA security orders which includes, but
not limi
ted to,

the following publications:


V
ersion 1.
8

Date:
9/
11
/
2012



6


1.

FAA Order 1370.95, Wide Area Network Connectivity Security.

2.

FAA Order 1370.82A, Information Systems Security Program.

3.

FAA Order 1370.114, Implementation of Federal Aviation Administration (FAA)
Telecommunications Infrastructure (FTI) Services and Information Security
Requirements in the
NAS
.

4.

FAA Order 1370.116, Boundary Protection Policy.

5.

FAA Order 1370.98, ATO Informatio
n Technology (IT) Infrastructure
Requirements for Non
-
FAA Connectivity.

6.

FAA Order 1900.69, FAA Facility Security Management Program.


3.7

Monitoring

The Cloud provider
may

provide a
centralized

monitoring capability in order to protect the
infrastructure.
The

cloud provider
may

provide a centralized platform to collect and
correlate all management information for security and network operations.

This
would

ensure established
service level agreements
(
SLAs
)

are met and cloud resources are
being efficiently used.


In addition, the monitoring capability
would

help troubleshoot
application issues faster.

The Cloud provider
may

r
eport on performance parameters such as resource usage (CPU,
Memory) of virtual
and

physical
servers, storage, bandwidth usage
,

etc
.

The Cloud
provider
may

provide
monitoring metrics for the purposes of usage metering. Finally,
the
Cloud provider
may

provide
alerts and information on both scheduled and unscheduled
outages and service int
erruptions.

All collected management information
may

be made
available to other FAA systems through dynamic real time integrated connectivity and/or
through a common view provided through a web enabled interface available through the
FAA’s mission support
network.


3.8

Training

Training and documentation
may
be provided to users of the
IaaS

services

on how to
configure the system for tenant
software

vendors.
T
raining and
documentation
need
s

to

be detailed enough to provide
the necessary information for tenant
application developers
to accomplish their jobs.


3.9

Capacity Planning

The
CSS

Cloud

provider
may

provide
rapid provisioning of new services

based on
demand
for capacity requirements
and
capacity calculations for virtual servers
, the
type of racks,
their
layout, square footage
, and

assignment
. The data center facilities equipment
would

meet
the
maximum allowable power density and typical power consumption per rack
.


V
ersion 1.
8

Date:
9/
11
/
2012



7



3.10

FAA Telecommunications Infrastructure (
FTI
)

The
FTI is a Telecommunications Services cont
ract that is used to satisfy NAS Operational
and Mission Support telecommunications requirements.
The
FTI provides a range of
services including
:



P
oint
-
to
-
point and multipoint Voice Grade (VG) analog services,



P
oint
-
to
-
point digital services,



IP network
services
, and



S
witched circuit services
,

The
FTI also provides a range
of interface types that includes
:



VG,
DDC, DDS, T1, T3, ETHERNET, FDDI, and ISDN.

The
FTI services can be ordered across a range of availability requirements from 0.997 to
0.9999971 a
nd across a range of latency limits from 50 ms to 1000 ms.

For Security,
the
FTI provides a range of
telecommunication
Security Services that
includes Basic security, VPNs, Gateways to non
-
NAS users, and Dedicated Services for
critical NAS operational communications traffic.

The FAA plans to use
FTI
to

provide the telecommunication ser
vices needed for
a

CSS
Cloud
.
An

Ia
aS
Cloud
would

interface with
the
FTI in order for its

tenant programs to
exchange data
internal and external to

the FAA.


3.11

System Wide Information Management (
SWIM
)

The SWIM program is an information management and data sharing system for NextGen.
SWIM p
rovide
s

policies and standards to support data management, secure its integrity,
and control its access and use. SWIM implement
s

enterprise messaging via
the NAS
Enterprise Messaging Service (NEMS) for service providers
.
CSS
programs
depend on
SWIM in a n
umber of areas including messaging services for data delivery
, DNS, and
NTP
.




V
ersion 1.
8

Date:
9/
11
/
2012



8


Section 4:

Common Support Services


Figure
3

Notional
CSS

Cloud Interfaces

for some CSS programs

4.1

Web Mapping Common Service

One

common service
may

be deployed on
an

operational
IaaS

Cloud. The application
may

be a set of virtual machines providing Open Geospatial Consortium (OGC) Web Mapping
Services (WMS). This service
may

be ing
esting:



The CSS
-
Wx and AIM
M

textual and binary products from:

o

The
CSS
-
Wx Web Coverage

Services

(WCS)

o

The
Web Fe
ature Services (WFS) and

o

The
AIM
M

WFS

and

o

The Geospatial Information System (
GIS
)

database
.

The services providing the data
may

be
running in separate virtual machines on the same
IaaS

Cloud.


The OpenGIS
® Web Map Service (WMS)
would provide

a simple HTTP interface for
requesting geo
-
registered map images from a geospatial database. A WMS request
would
define

the geographic layer(s) and area of interest to be processed. The response to the
request
would be

one or more geo
-
registered map images (returned as JPEG, PNG, etc.)
that can be displayed in a browser application. The service
would

receive the weather
information in textual and gridded NetCDF files from the CSS
-
Wx services and
will
convert
these into
map images
. These map images
would

be

stored into the GIS database
. They
would

then be
published via a web server
,

via the
Local Area Network

(
LAN
)

or
Metropolitan Area Network

(
MAN
)

(depending on the physical location of
an

IaaS

Cloud) to
the SWIM NAS) N
EMS node. The service
would

receive aeronautical information in textual
and geo
-
reg
istered map images from the
AI
MM services.


4.2

Common Support Services for Weather

CSS
-
Wx
would

provide

authorized consumers the weather
data

generated by various
providers
. T
he weather
data
may include

but not limited to:



Weather radar data,



National Oceanic and Atmospheric Administration (
NOAA
)

numerical
model data,

V
ersion 1.
8

Date:
9/
11
/
2012



9




The
FAA NextGen Weather Processor
(NWP) generated products such as mosaics
and forecasts

Two CSS
-
Wx

services (the WCS and the WFS)
would
provide clients with gridded (raster)
data and vector data, respectively. These services
would
provide clients with an endpoint
from which to obtain data product availability, product descriptions, and raster/vector da
ta
itself. They adhere to standards defined by OGC for representing the data.


4.2.1

Services

The CSS
-
Wx Web Services
would
read and catalog data products for clients to query and
retrieve. Data products
would be

identified by well
-
known, unique identifiers (I
Ds). These
IDs
would be

assumed to be published to clients,
to be used when querying a Web
Service. Reading/cataloging and querying/retrieving
would be

achieved using two
subsystems: a mechanism for receiving data products from weather publishers; and a
mechanism to provide metadata/data to clients.


The Web Services
would
receive data from weather
providers

through either a shared file
system, or through a transaction insert method (OGC standard for WFS) that
would insert

Data Products into a database or

store accessible by the Web Service. Data retrieval
would be

achieved via a publish/subscribe mechanism, such that the Web Services are
notified when new Data Products
would h
ave been placed into a store.


Web Services
would
accept query requests from clients at a well
-
known network address.
There
would be

two data
-
related actions that can be performed by clients:



Describe Data Product and



Get Data Product.


Additionally, clients may subscribe to receive updates about Data

Products.


To enable clients to receive updates when new Entries
would be

available for Data
Products of interest, both Web Service types
have been

extended beyond the OGC
standards to include a subscription capability. A client may subscribe to particul
ar Data
Products, and receive either the actual data of new Entries from the WFS, or metadata and
notification of new Entries from the WCS. Upon receiving metadata about a new Entry
from the WCS, the client
could

use the Get Product mechanism to retrieve
the data itself.


4.2.2

Software

In characterizing the WCS and WFS software
,

the CSS
-
Wx program

performed
benchmark calculations using reques
ts for different size
subset
grids
.
For each test, the
following standar
dized hardware profile was used:



Linux Virtual
Machine



Red Hat 4.1.2
-
52



Linux version 2.6.18
-
308.1.1.el5




1 CPU 2.8 GHz Intel Xeon



4G
B

Memory



2GB JVM Memory


V
ersion 1.
8

Date:
9/
11
/
2012



10


The WCS processing time behaved

linearly with size of the subset grid, as it uses file I/O
to publish the requested data. This service
would

li
kely

require on
-
blade disk access
for
large intermediate file storage to guarantee low latency operations
and may

also

require
bare
-
metal OS machine configuration for speed and reduction in run
-
time variance.

In
contrast, t
he WFS processin
g time
was

virtua
lly independent
of the

requested subset

grid
size
.



4.2.2.1

Third Party Software

An additional characterization of the Weather web services’ demand for memory and
processing power can be
obtained

from

information on the third
-
party software
needed for
each of the reference
implementation
.


The following is a list of critical and important 3rd party dependencies needed at runtime
by the WCS reference implementation (WCSRI)
;





NCAR Unidata Netcdf, Common Data Model (CDM) and Grib are critical to
subsettin
g operations and Netcdf and Grib file handling.



Apache CXF, Mina, Jetty are critical to how the WCSRI provides the soap/kvp
request/reply web services.



Apache Camel is critical to how the server provides notifications, via Camel routes
with file polling a
nd JMS.



Apache ActiveMQ is the message broker, critical to the server.



Apache Commons is important, in that it's used throughout the WCSRI for a
number of 'utility' type functions



OpenJPA is how WCSRI abstracts the persistence layer.



Logback and SLF4J is
how the server does logging.



Spring is important for dependency injection, and a number of other things.



Apache SSHD is used for our SSH handling, and hence is important for security.



The Apache Aries, Felix, Karaf, Servicemix technologies/packages are imp
ortant
for OSGI. Aries Blueprint is how WCSRI does much of its dependency injection
too, and hence, important (though a vendor could use a different mechanism in a
rewrite).


The following is a list of critical and important 3rd party dependencies needed a
t runtime
by the
WFS reference implementation (WFSRI)
:




To support storing information on features to support queries the WFSRI can use
the Apache Derby and PostgreSQL database implementations.



To provide the endpoint and routing messages to the proper ty
pes of requests the
WFSRI uses Apache Camel.

V
ersion 1.
8

Date:
9/
11
/
2012



11




The use of XML based configuration files is supported by the Spring libraries.



When no external JMS broker is provided for the WFSRI an Apache ActiveMQ
broker is used to support publishing and subscriptions.



Transformations of coordinate reference systems are supported by Geotools while
the Java topology suite for spatial filtering of features comes from Vividsolutions.



Aspectj is used to add monitoring code into the base WFSRI at build time.



Log4j and the A
pache Commons Logging libraries are used to support logging.



TestNG provides support for testing the WFSRI source code.


4.2.3

Processing

A
viation weather information
consists of

large data sizes
. Since weather information is
highly perishable
,

there is a high demand from users for rapid throughput on weather
requests, with low latency.
CSS
-
Wx

services
would

acquire, filter, store and disseminate
large amounts of data efficiently to and from the FAA’s optical IP network.


The CSS
-
Wx program

esti
mated the number of
single core
virtual machines

required to
achieve the filtering operations needed by the various consumers.
The standard hardware
profile VM used for these estimates
(described in

Section
4.2.2
)

is a minimum capability
benchmark.



Examples of t
he VM
requirements

for
three

weather products are
provided in
Table
1

below. In
Table
2
, the estimated total
product count and corresponding total
VM count for
all CSS
-
Wx processing are

presented.
Over 95
% of the product requests
require
20

or
fewer
benchmark
VMs.


Table
1

Examples of Virtual Machine Estimates for Specific CSS
-
Wx products

Example CSS
-
Wx Processing

Input Compressed

File Size

(Megabytes)

Update
Rate
(Seconds)

Allowable

Latency

(Seconds)

Estimated

# of unit VMs

Composite Reflectivity
Radar
Mosaic

1.2

25

5

2

2

h
ou
r Precipitation Forecast

5 min intervals


24 files

62.3

300

60

6

High Resolution
Numerical

Model

12,027

1,600

720

1



Table
2

CSS
-
Wx
Product

Count

and Total Virtual Machine Estimates for
CSS
-
Wx Processing Load

Total Different Products in CSS
-
Wx

Total Estimated VMs for CSS
-
Wx Processing Load

~100

1,204




V
ersion 1.
8

Date:
9/
11
/
2012



12


4.2.4

Storage

An

IaaS Cloud would
provide short term storage for
ingesting
weather data, storage of
filtered / altered weather data
,

as well as
,

system activity logs.
An

IaaS
Cloud would

also
provide storage for a 15
-
day archive of all input and output weather data.


Table
3

summarizes the type of data that
could

be processed by CSS
-
Wx in a single day

and the
file

handling and storage required
. Over 70

different weather data input and
product output types
could

flow through CSS
-
Wx every day.


Table
3

Summary of CSS
-
Wx File Transactions and Storage

CSS
-
Wx Processing

Input

Output

Files per Day

0.39 Million

21.4 Million

Storage per Day

0.7 Terabytes

87.9
Terabytes


4.2.5

Network Requirements

An

IaaS
Cloud would

provide resources for a loca
l

area network for connectiv
ity to FTI
NESG, SWIM and NWP.


4.2.5.1

LAN

The average bi
-
directional data throughput to and from the combined CSS
-
Wx
VM’s via the LAN
could be

approximately 1
55

Megabits/second. The inputs to
the CSS
-
Wx VM’s
would be

from the
NESG, the SWIM NEMS node, and NWP
.
The output
s from the CSS
-
Wx VM’s
would
mainly
go
to the SWIM NEMS node.
The SWIM node distributes this data to the users via
FTI.


4.2.5.2

WAN


FTI

Some of the CSS
-
Wx VM’s
would

implement legacy protocols to existing
systems using FTP and TCP/IP. The average communication throughput for all
CSS
-
Wx VM’s communicating via legacy protocols

to existing systems
could
be

approximately 4 Megabits/second.


4.3

Aeronautical Information Management

4.3.1

Services

Aeronautical Information Management Modernization Segment 2 (AIMMS2)
would

improve
and automate aeronautical data ingest, management, provision, and workflow in order to
increase the
quality and consistency of

the Aeronautical I
nformation (AI). AIMMS2
would

provide the Aeronautical Common Service (ACS) as the single trusted access point of AI.
This segment
would

include Special Activity Airspace (SAA) and airport configuration data.
The scope of AIMMS2
would

include

the following:

V
ersion 1.
8

Date:
9/
11
/
2012



13




Digital Data Ingest
: The development of digital data input capability
would be

essential to AIMM. This
would include

the exchange of data with authoritative
providers using automated tools and systems.
A

CSS Cloud
may

support the
interfaces to these legacy systems which include information associated with
SAA

definitions and schedules, Airports GIS and configuration information, and
Temporary Flight Restrictions (TFR’s).



ACS
: The ACS system
would

manage AI data ingest

from multiple sources. It
would

transform, validate (for integrated products), verify, store, and distribute the
resultant AI to users and systems through AIM enterprise web services via OGC
Web service standards, SWIM compliance standards, using open so
urce COTS
software to provide those services. The ACS
would have

four main functional
capabilities: (1) business rules/services, (2) data capture, (3) data exchange, and
(4) data and information management. Services provided by the ACS
may

be
supported by

a

CSS Cloud.



System Integration and Data Exchange
: The new AIMM2 system
would

establish
functional two
-
way data exchange using Service
-
Oriented Architecture (SOA)
principles. AIMMS2
would

establish and develop a link to provide data to NAS
consumer system
s and users through the SWIM infrastructure.
A

CSS
Cloud

may

support the interfaces between SWIM and NAS consumer systems and users.



External Web Internet Portal
: The new AIMM system
would

establish an interface
for users outside of FAA NAS systems to rel
ay AI via the public Internet. This web
portal
would

become an Operational Support System (OSS) for external aviation
operations personnel to obtain needed AI. It
would

also work with systems from
within the NAS.

4.3.2

Software

AIMM
S
2
may
rely heavily on open so
urce COTS software to support ACS services.
Software
may

be compliant with OGC standards data for web services and support future
releases of
Aeronautical Information Exchange
(
AIXM
).
The ACS
may

be platform and

operating system independent.


4.3.3

Processing

AIMM
has

estimated the size and number of messages to be processed daily through the
ACS at 22.4 GB per day.


AIMM has constructed a prototype of the ACS. The following summarizes the hardware
profile used in the prototype. The prototype implementation
has not been written t
o utilize
a cloud environment.
It

is designed to be platform and

operating system independent.
Those listed below were considered to be the optimum
for the prototype environment.
It is
expected that any future prototyping effort would

require similar capability in a testing or
R&D environment.


Machine type: Application Server

V
ersion 1.
8

Date:
9/
11
/
2012



14




Usage Summary: Used to host the application for the ACS Prototype during testing
and demonstration phases. Incorporated into the SWIM R&D domain for testing of
connectivity with test SWIM nodes and other program prototypes in development.



Platform/Operating system: Sun Solaris



150 GB Storage



Current location: SWIM R&D Lab, WJHTC


Machine type: Mapping Server



Usage Summary: Used to host the mapping components of t
he ACS prototype
during testing and demonstration phases. Server is incorporated into the SWIM
R&D domain and hosting other applications.



Platform/Operating system: Sun Solaris



150 GB Storage



Current Location: SWIM R&D Lab, WJHTC


Machine type: Database S
erver



Usage Summary: Used to host the copies of AIM
-
DB, test data, etc. for ACS
prototype during testing and demonstration phases.



Platform/Operating system: Sun Solaris



300 GB Storage



Current Location: SWIM R&D Lab, WJHTC


Based on the prototype above,
the estimated processing and storage capacity needed for
AIMMS2 is in
Table
4

below.



Table
4

AIMM
S2 Estimated Infrastructure
needs


Service

Description/Assumptions

Computing (Server/OS)

2 Virtual Machines each with 17.1 GB RAM, 6.5 ECU (2 virtual cores with
3.25 ECUs each)

420 GB Local Instance

Storage, 64
-
bit platform

Relational Database

2 Virtual Machines hosting each a Database Instance

Each virtual Machine has 34 GB of memory, 13 ECUs (4 virtual cores with
3,25 ECUs each), 64
-
bit platform

Database Storage

1 TB per DB instance


4.4

Scalability

An

IaaS
Cloud

would

be scalable to support
future

increase in instances, inclusion
of new
applications,
increases in data suppliers and consumers
, and ingesting additional

information sources
.


V
ersion 1.
8

Date:
9/
11
/
2012



15


4.5

Security

CSS

tenant programs

would have

control over the operating system, storage, applications,
and
use of

the networking components. The under
lying infrastructure
would be

under the
control of the
CSS C
loud
Infrastructure P
rovider.


The IaaS

model would require the operating system, applications, and content be
managed by CSS tenant Programs with a requirement to share and stream all system
logging and system information to a centralized location to better enhance network and
security operati
ons and monitoring.
T
he
CSS Cloud Infrastructure Provider
would secure

the hardware platform and infrastructure components to ensure service security and
availability. The CSS private infrastructure
IaaS

management functions of governance,
operations, secu
rity,
and
compliance
would

be
provided by
CSS programs prime
contractors working closely with
a

CSS Cloud Infrastructure Provider

with a requirement to
share and stream all system logging and system information to a centralized location to
better enhance n
etwork and security operations and monitoring
.

Security
would be

a cross
cutting concern and areas, such as identity management, access control, monitoring, are
shared across the different layers.


FAA’s
Cloud

computing strategy, published May 2012, identifies security challenges
involved with providing cloud computing solutions to the NAS environment. The NAS
systems are all connected to the
FTI

network which has no direct connectivity to the
Internet. All ext
ernal communications to the NAS traverse approved boundary protection
systems.


4.6

Common Management Platform

The CSS cloud may provide a common management platform to centrally collect all
application, system and network infrastructure information. All coll
ected management
information could be made available to other FAA systems through dynamic real
-
time
integrated connectivity. The dynamic interface to the FAA systems could utilize a mutually
agreed upon steaming data format such as syslog, snmp or other c
ommon interface.



Additionally the CSS cloud provider may provide a common view through a web enabled
interface available through the FAA’s mission support network information of the CSS
tenant applications, Iaas and network infrastructure.


Section 5:

Other FAA Sy
stems

5.1

Integrated Enterprise Services Platform

(IESP)

The purpose of the IESP system hardware platform
was

to support initiatives located at the
NEMC in Atlanta and Salt Lake City. This hardware platform consists of
a
server, storage,
networking, monitorin
g, and auxiliary equipment in a scalable enterprise data center
design. The platform
will

host
:



W
eather
M
essage
S
witching
C
enter
R
eplacement,




the National Airspace Data Interchange Network (NADIN) Message Switch Network
(MSN)

V
ersion 1.
8

Date:
9/
11
/
2012



16




Regional ADAS Support Proces
sor


The legacy WMSCR, NADIN MSN, and ADAS systems relied on individual networks. A
consolidated network design involving all three systems simplifies the operations. The
high
-
end switches that are part of this consolidated network design increase overall
system performance. CSS
-
Wx
may

subsume the capabilities associated with WMSCR
and ADAS
in the future
. Refer to

Table
5

for further details of the IESP.



Table
5

Example of modern virtualized data centers within FAA today

Category

Description

Computing

HP C7000 blade chassis
containing BL460C G6 blades; capable of supporting up to
80 VMs

Storage

HP EVA 4400 storage array with 3 shelves 36 FC disk 450GB 15K rpm (data) and 1
shelf 12 FATA disk 1TB 7200 rpm (backup); currently 13 TB and capable of
supporting up to 192TB of storage

Network

Redundant Cisco 4503 Gigabit switches for:

-

Combined Servic
es Access Point (CSAP) network

-

Monitor and Control (M&C) network

-

1 GB backplane

Virtualization:
Management

VMWare vCenter Standard and vMotion

Virtualization: Hypervisor

VMWare Vsphere Enterprise 5.0

Virtualization: Cloud

No Cloud functionalit
y currently
(Could support IaaS model in
the
future)


5.2

NextGen Weather Processor

(NWP)

The
NWP
may establish

a weather processing platform and infrastructure to replace the
functions of legacy FAA weather processor systems and host new capabilities. NWP
ma
y
replace the functionality of:



Weather and Radar Processor (WARP)

Radar Acquisition Mosaic Processor
(RAMP)

which has processing components at 25 locations
;



Corridor Integrated Weather System (CIWS)

which has processing components at 1
location
; and



Int
egrated Terminal Weather System (ITWS)

which has processing components at
34 locations
.

NWP
may

further:



P
rovide advanced aviation specific weather information

t
hrough the integration of
real time radar data extrapolation with NWS forecast models up to

8 hours
;



P
erform Weather Translation to produce weather avoidance fields which will enable
the use of weather information by automated
D
ecision
S
upport
T
ools (DSTs)



Perform parallel processing on large amounts of data



Consume and process weather information for
over 200

weather radars,



Consume and process NOAA numerical models and satellite information to
generate products that vary in update rate from 10 seconds to every 5 minutes



Generate products as large

as 500 M
B
uncompressed every 5 minutes.



V
ersion 1.
8

Date:
9/
11
/
2012



17


The NWP system
would have

very little variability in processing or storage requirements
and the individual processes running in independent VM’s on different physical hardware
are timing sensitive and co
-
dependent.
This may
introduce some unique challenges for the
cloud provider and the solution developer to provide an overall solution
. The NWP program
may consider the deployment of an intranet web server display capability on
a

CSS Cloud
.


Acronyms

Acronyms

Description

ACS

Aeronautical Common Service

ADAS

ASOS Data Acquisition System

AI

Aeronautical Information

AIM

Aeronautical Information Management

AIMM

Aeronautical Information Management Modernization

AIMMS2

Aeronautical Information Management Modernization Segment 2

AIXM

Aeronautical Information Exchange

ARTCC

Air Route Traffic Control Center

ASOS

Airport Surface Observing System

CDM

Common Data Model

CDR

Critical Design Review

CIWS

Corridor Integrated Weather System

CPU

Central Processing Unit

CSS

Common
Support Services

CSS
-
Wx

Common Support Services for Weather (formerly known as NextGen
Network Enabled Weather)

DST

Decision Support Tool

FAA

Federal Aviation Administration

FTI

FAA Telecommunications Infrastructure

GIS

Geographic Information System

IaaS

Infrastructure as a Service

IOC

Initial Operating Capability

IESP

Integrated Enterprise Services Platform

IT

Information Technology

ITWS

Integrated Terminal Weather System

LAN

Local Area Network

LRU

Line Replaceable Unit

MAN

Metropolitan Area
Network

MSN

Message Switch Network

NADIN

National Airspace Data Interchange Network

NAS

National Airspace System

NEMC

NAS Enterprise Management Center

NEMS

NAS Enterprise Messaging Service

NESG

NAS Enterprise Security Gateway

NWP

NextGen Weather
Processor

OGC

Open Geospatial Consortium

V
ersion 1.
8

Date:
9/
11
/
2012



18


OSS

Operational Support System

OVF

Open Virtualization Format

PaaS

Platform as a Service

RAMP

Radar Acquisition Mosaic Processor

RASP

Regional Airport Surface Observing System (ASOS) Data Acquisition
System
(ADAS) Support Processor

SAA

Special Activity Airspace

SaaS

Software as a Service

SOA

Service
-
Oriented Architecture

SIR

Screening Information Request

SWIM

System
-
Wide Information Management

TFR

Temporary Flight Restrictions

VG

Voice Grade

WAN

Wide
Area Network

WCS

Web Coverage Service

WCSRI

Web Coverage Service reference implementation

WFS

Web Feature Service

WFSRI

Web Feature Service reference implementation

WJHTC

William J. Hughes FAA Technical Center

WMS

Web Map Service

WMSCR

Weather
Message Switching Center Replacement