GSFC Communications

1
GSFC Communications Forum Code 290
Operations Manager Chuck Duignan Assistant
Operations Manager Vicki Stewart
November 21, 2002
2
Agenda

• TOPIC SPEAKER
• Opening Remarks Craig Hegemann
• Introduction Chuck Duignan
• Operations
• Mission Critical Activities Mike Allen
• Tech Control Section Mike Eder
• Voice Control Section Sandra Marshall
• Electronic Maintenance Section Brian Durkin
• IP Network Operations Center Norman Reese
• Conversion Device Management Joel Peterman

3
Agenda

• TOPIC SPEAKER
• Requirements
• PCEs - Mission CSRs Stan Rubin
• NSMs Mission NSRs Chuck Duignan
• Systems Engineering
• NERD Rita Kemp
• Mission Voice Replacement Rita Kemp
• GSFC Strategic Communications Plan Curt Suprock
• Questions/Answers Chuck Duignan
• Closing Remarks Chuck Duignan

4
Objective

• A forum to improve communications between Code
  290 and key project personnel at GSFC and to
  provide status on mission related issues,
  actions, concerns.

5
GSFC Communications Forum

• Introduction
• Chuck Duignan

6
GSFC Communications Forum

• Format of Presentations
• These presentation will be posted to the Code 290
  web page http//code290.gsfc.nasa.gov/index.html
  
• Miscellaneous Items
• Please sign the Customer List at the back of the
  room
• Questions and Answers
• After each presentation
• Submit in writing for follow-up at a later time
• - Handouts
• Forum Questionnaire
• Voice Requirements Survey
• Code 290 Overview
• VDS Instrument Training Overview

7

• Mission Critical Activities
• Mike Allen

8
Mission Critical Activities

• Nascom MO functional areas are staffed 24 x7 by
  contractor personnel in support of all voice
  and data requirements for manned flight,
  scientific satellite, and deep space projects.
• The support group provides administrative, and
  mission documentation services to personnel
  working in the various functional areas.

9
(No Transcript)
10
Mission Critical Activities

• Functional -
• Technical Control -
• Provides data support for STS ELV
  launches, assists in carrier circuit
  restoration/fault isolation and circuit
  acceptance testing
• Voice Control -
• Provides voice support for STS ELV
  launches, assists EMS in circuit restoration and
  fault isolation of VSS/VDS outages
• Electronic Maintenance
• Provides repair, testing, calibration
  support of Nascom equipment at GSFC
• NNSG
• Schedules network releases, TV support,
  provides metrics for network support
• SWO
• Provides access control of the Nascom areas

11
Mission Critical Activities

• Support -
• - Administrative
• Personnel records, timekeeping, controlled area
  housekeeping
• - Documentation
• Mission specific documentation
• Maintain ISO 9000 certified onsite library

12
Mission Critical Activities

• Staffing
• 4 COMMGRs supporting 24x7, 2 COMMGRs supporting
  12x7 (straight days). On-call status maintained
  via pager support.
• Rotating shifts working 12 hour days alternating
  between days and evening shift every other month.
• 4 Mission COMMGRs supporting 8x5 also on pager
  support. Conducting administrative duties,
  requirement reviews and determination,
  documentation presentations, console support as
  for all STS, ELV launches and other critical
  periods as required.

13
Mission Critical Activities

• Issues and Concerns -
• Maintaining accurate listing of
  Points-of-Contact Projects should report any
  changes in points-of-contact to NNSG/Tom Boggs at
  301-286-5590 or hboggs_at_POP500.GSFC.NASA.GOV

14

• Technical Control Section
• Mike Eder

15
(No Transcript)
16
Technical Control Section

• Technical Control -
• Provides technical management of mission
  critical WAN data services supported by the
  FTS-2000 (CONUS) and NOCS (International
  Partners) networks.
• Establish WAN/LAN circuit configurations to
  support operational and engineering entities in
  their efforts to attain mission specific goals.
• Provides real-time fault isolation and
  restoration of failed services, and coordinates
  restoral activities with commercial carriers.

17
Technical Control Section

• Technical Control -
• The FTS-2000 network is comprised of point to
  point T-1 backbone circuits interconnected by
  programmable time division multiplexers capable
  of supporting analog voice, and digital data,
  both sync and async.
• The NISN Overseas Communications System (NOCS)
  is comprised of point to point 64 kb and T-1
  commercially provided carrier links terminated by
  Ascom Timeplex Link 2 mutliplexers.
• Circuit diagnostic test equipment include
  Firebird 6000 bit error rate test sets, Phillips
  4 channel oscilloscopes, and frequency counters.

18
Technical Control Section

• Staffing -
• 8 Certified Technicians supporting 24x7. Rotating
  shifts working 8 hour days weekly.

19
(No Transcript)
20
TCS notified of Circuit problem. Validate ckt
Number in d/b
WAN or LAN
Establish monitor Check performance
Establish monitor Check performance
WAN
LAN
Fault Indicated ?
Fault Indicated ?
Perform Bit Error Rate Test
Advise COMMGR Work with Customer To
resolve problem
Advise COMMGR Work with Customer To
resolve problem
YES
YES
NO
NO
Contact Carrier Open ticket and Logout
circuit Work with carrier To restore
service Determine RFO Put circuit back In service
Contact EMS Logout Circuit Work with EMS to
restore Circuit. Report Fix action and Place ckt
back In service
Test within Performance Specs ?
NO
NO
YES
21

• Voice Control Section
• Sandra Marshall

22
(No Transcript)
23
Voice Control Section

• Voice Control -
• Establish voice conferences to NASA network
  mission control centers and various other NASA,
  DoD and cooperating International Partner
  Agencies.
• Provides fault isolation, restoral, testing and
  monitoring of all WAN/LAN voice resources.

24
Voice Control Section

• Voice Control -
• WAN resources are terminated by the Voice
  Switching System (VSS) which provides the
  capability to switch, conference and monitor 2048
  2 4-wire circuits at 24Kbs and 32Kbs (3 khz bw)
  voice circuits. The VSS employs analog to
  digital conversion with conferencing capability
  supported by digital switching technologies.
• LAN terminations are supported by the Voice
  Distribution System (VDS) which also employs
  digital switching technology in compliance with
  applicable ISDN standards for all on campus
  operational voice switching and distribution
  requirements.

25
Voice Control Section

• Staffing -
• 10 Certified Voice Controllers supporting 24x7.

26
GSFC Voice Conferencing Systems
POCCs

KS
Voice Distribution System LAN
DKS
2-Wire
MSFC
KSC
JSC
MKI
Siemens CBX LAN
2-Wire
MCC 1-2
Voice Switching System WAN
4-Wire Circuits
Network
RTC 1-4
LAN/WAN Demarcation Line
27
Trouble Call

• POCC reports trouble to COMMGR or Voice Control
• On Ext. 6-8737

Voice Controller Completes Trouble ticket
COMMGR is notified
-Works on-line with caller to determine source
of noise, echoes, etc. -If no problem found on
the Line a ticket is issued to EMS
VSS
VDS
Voice Controller works with user to determine if
the trouble is VSS or VDS
Equipment Problem- Ticket issued to EMS
EMS notifies Voice Control when repair is
complete.
Voice Control performs voice checks with user
28
Voice Control Section

• Issues and Concerns
• Request users review their requirements and
  identify any VDS instruments that are no longer
  required.
• When reporting and checking status on trouble
  calls, request that the users work directly with
  Voice Control.

29

• Electronic Maintenance Section
• Brian Durkin

30
(No Transcript)
31
Electronic Maintenance Section

• Voice
• Perform First Replaceable Unit (FRU) and limited
  depot level maintenance for the Voice Switching
  System (VSS) and the Voice Distribution System
  (VDS).
• Manage and administer VDS resources.
• Data
• FFRU level maintenance on the legacy and current
  data systems including TTY systems.
• FRU level maintenance on the Small Conversion
  Devices (SCD)

32
Electronic Maintenance Section

• - Personnel require technical expertise in the
  following disciplines
• Multi-stage digital switching technologies
• Printed circuit board and component level repair
• Analog and Digital circuit theory
• NASA soldering certification

33
EMS VSS Maintenance Flow Cart
VSS Trouble
Open Maintenance Ticket
Request Circuit Release from User thru V/C

• Repair Equipment
• Notify V/C and Users
• Return Circuit to Users
• Start 24 Hour Observation

Any Further Problems?
Yes
Highlighted section relevant to users
No
Close Maintenance Ticket
34
EMS VDS Trouble Flow Chart
Open Maintenance Ticket
VDS Problem
Is this a Problem Central Equipment or Remote
Instrument Problem?
Remote Instrument
Central Equipment
Dispatch Technician to POCC
Request circuit release from users thru V/C
Request circuit release from users thru V/C
Instrument Problem or Infrastructure Cable
Problem ?
Instrument
Cable
Notify Data Comm Group

• Repair Equipment
• Notify V/C and Users
• Start 24 Hour Observation

• Request Circuit Release
• Repair Instrument
• Notify Users and V/C
• Start 24-Hour Observation

• Request Circuit Release
• Data Comm
• Repairs Circuit
• Start 24-Hour Observation

Close Maintenance Ticket
No
Yes
Any Further Problems?
Any further Problems?
No
Yes
35
Electronic Maintenance Section

• Staffing
• 5 Certified Technicians supporting 16x7.
• On-Site mission critical coverage as required.

36
Electronic Maintenance Section

• Issues and Concerns
• - Instrument/Property ownership
• - Customer maintenance

37

• IP Network Operations Center
• Norman Reese

38
What is IPNOC?

• Manages IP Operational Networks (IONET)
• 24x7 Staffed Operations Center
• Pro-Actively Monitors Network Devices
• Troubleshoots WAN and Other Network Problems
• Troubleshoots Connectivity and Dataflow Problems
  (end users)
• Support Project and Network Testing
• IONET Sustaining Engineering
• IONET Network Services
• Engineer and Implement Mission Routed Data
  Requirements(via CSRs 290 and/or NSRs CSOC)
• Maintain DNS, IONET Secure Gateway, NTP Servers
• Support Systems Engineering Activities

39
What is IONET?
TDRS-W
TDRS-E
Space Network (SN) - TDRSS
Ground Network (GN)
End Users
WSC
MOCC Data Centers (CDs or self-encapsulated)
CDs
IONET
MDMs
Ground Network Sites MIL, PDL, WGS, SGS, AGS,
MGS,DFRC, OAS, AFSCN, DSN
White Sands Complex (WSC) New Mexico (WSGT STGT)
40
IPNOC-Managed Networks

• Open IONET (IP Operational Network)
• Typically Used to Transport Science Data Between
  Mission Operations Center (MOC) and Principal
  Investigators (PIs)
• Internet Connectivity through NISN SIP
• Closed IONET
• Typically Used for Real-Time Command/Telemetry
  between Mission Operations Center and Spacecraft
• Connectivity to SN, GN, DSN
• IP Transition Network (Closed IONET)
• Mission-Critical Real-Time Multicast/UDP
  Dataflows
• Supports Legacy 4800 Bit-Block Customers
• WAN or Network Errors will result in Lost
  Commands or Telemetry
• High Levels of Redundancy in Order to Ensure
  Mission Availability Requirements

41
IPNOC-Managed Networks

• EOSDIS Backbone Network (EBNET)
• EOS Dedicated Mission Infrastructure
• Closed EBNET for Critical Spacecraft Commanding /
  Telemetry
• Open EBNET for High Bandwidth Science Dataflows
• DOORS GSFC Peering Routers
• Connects IONET EBNET to External Networks (SIP,
  VBNS, etc)
• Goddard Core ATM Network (GCAN)
• ATM Infrastructure to Support Science,
  Administrative, Mission Traffic
• Wallops Core ATM Network (WCAN)
• ATM Infrastructure to Support Science,
  Administrative, Mission Traffic
• IPNOC Manages Multi-Vendor Environment
• Vendors Include Cisco, Nortel, 3Com, Juniper, and
  Marconi

42
IPNOC Staffing

• 24x7 IPNOC Operations
• 9 Network Operators Supporting 24x7
• Operational Engineers On-Call 24x7
• Advanced Troubleshooting Problem Escalation
• On-Console Support for Specific Critical Coverage
  Periods
• 1 2 years to be trained/certified
• Network Engineering Team
• Systems Administrators Network Management
  Systems Developers

43
IONET Troubleshooting
Status, Coordination, and Reporting
COMM Manager
Ongoing Troubleshooting
CD Manager
Tech Control
NMS Alerts
IPNOC
44
IPNOC Troubleshooting Tools

• Network Management System (NMS)
• Proactive Monitoring trying to identify and
  resolve problems before impact to users
• COTS software
• Custom IPNOC apps to enhance supplement COTS
• Trained Staff
• Knowledge of Networks, Hardware,
  Projects/Users, Spaceflight Operations Lingo,
  Critical Urgency
• Network Sniffer/Protocol Decoders
• WAN Circuit Troubleshooting via Tech Control
  Host Center Support
• End User Input and Assistance
• Vendor Support

45
IONET is Unique

• What Makes IONET Different (Than the Average IP
  Network)?
• Heavy Utilization of Multicast/UDP Data Flows for
  Critical Serialized Data (encapsulated in IP)
  Requires Very Consistent Timing in Order for
  Spacecraft and End-Users to Maintain Lock on
  the Data
• High Performance Requirements (Very Low Tolerance
  for Errors)
• High Redundancy and Desire for Immediate
  Fail-Over
• Critical Nature of Operations (Human Spaceflight,
  Billion Dollar Spacecraft)
• Many Diverse and Equally Mission-Critical
  Customers on Shared Network Infrastructure
• High Level of Coordination Required with All
  Users Before Taking Any Actions Which May
  Potentially Impact Users
• No Down Time Full Capability Required 24x7x365
• Little Room for Mistakes

46
IPNOC Issues and Concerns

• IPNOC Issues and Concerns
• Non-Real-Time File Transfer Dataflows (e.g. FTP)
  Can Impact Critical Real-Time Dataflows
• IONET Rate-Limiting Solution Developed to
  Throttle File Transfer Flows (Can be Deployed
  as Required)
• Mysterious and Intermittent Network Connectivity
  and Performance Issues are Often Difficult and
  Resource Intensive to Isolate
• Consume Considerable IPNOC Operations Resources
• Project Often Has Minimal Resources to Assist
  with Troubleshooting
• Problems Often Isolated to Project Issues
• Improved On-Console Dataflow Documentation and
  Diagnostics Tools for Self-Encapsulated Projects
  to Assist With Troubleshooting and Fault
  Resolution of Connectivity Problems

47

• Conversion Device Management
• Joel Peterman

48
Conversion Device Management

• Major Functional Areas
• Configuration of Conversion Devices for nominal
  support based on known requirements or new
  requirements stated in Communication Service
  Requests.
• Generation and implementation of Secure Gateway
  Requests for Open Net users requesting services
  off of IPTX network.
• Configuration of Conversion Devices for Tests
  Data Flows, mission support per briefing messages
  and/or ISIs.
• Implementation/roll-out of NASA approved
  application and security upgrade software.

49
Conversion Device Management

• Major Functional Areas (continued)
• - Troubleshooting Conversion Device problems
  with respect to data receive transmit (IP to
  serial and serial to IP). Reporting of device
  problems using documented Event Report process.
  Reconfiguration of spare devices and replaced
  devices.
• Assignment of Network data routing codes
  (source/destination, logical port addresses
  fixed multicast addresses). Maintain
  Source/Destination Code Handbook.
• Assist self-managed/self-encapsulated projects
  with fault isolation/troubleshooting as
  needed/required/requested.

50
Conversion Device Management

• Technologies Supported
• - Small Conversion Devices
• Native Linux O/S
• SCD 5.2 application
• 142 CDs located throughout network
• - Programmable Telemetry Processors
• IBM Warp O/S 2
• Avtec 4.05.03 application
• KopyKat/Telnet communications software used for
  device connectivity
• 10 PTPs located throughout network

51
Conversion Device Management

• GSFC Locations with Conversion Device support -
• - Building 14-HST, MSAT, GSC/TCS, MUD, etc.
• - Building 3-Wind/Polar
• - Building 13-MSC
• - Building 1-FSDIC
• - Building 23-VISION
• - Building 25-SOCC
• - Building 29-VEST
• - Building 32-EOS, TRMM
• - Lanham-Landsat

52
Conversion Device Management

• Network Locations with Conversion Device support
  -
• - Cambridge-Chandra
• - Toulouse-CNES
• - Dryden Flight Research Center-Shuttle
• - Johnson Space Center-Shuttle, ISS, ESTL
• - Kennedy Space Center-Shuttle, ISS, ELVs
• - Marshall Space Flight Center-Shuttle
• - Poker Flat-Helios, TOMS, etc.
• - Redondo Beach-TRW (Chandra)
• - TOPEX via JPL
• - Schreiver Air Force Base-ELVs
• - Vandenberg Air Force Base-ELVs
• - Wallops Flight Facility-NOAA, Spartan, Helios,
  etc.
• - White Sands Complex-SN support, ISS commanding

53
(No Transcript)
54
(No Transcript)
55
Conversion Device Management

• Shared Responsibilities and Demarcations
• CDM Demarcations
• Ethernet board in conversion device on IONET side
  to serial board in conversion device on user
  side.
• Ethernet board in conversion device on IONET side
  of SCDs performing packet filter capabilities.

56
Conversion Device Management

• Staffing
• - 7 CDM's supporting 24x7. On-call status
  maintained via pager support.
• - Rotating shifts working 12 hour days
  alternating between morning and evening shift
  every other month.
• - 2 CDMs supporting 8x5 also on pager support.
  Conducting administrative duties, requirement
  reviews/determination, documentation
  presentations, console support as required.

57
Conversion Device Management

• Issues and Concerns
• Emphasis on timely reporting of problems to
  Commgr. CDM/IPNOC are hampered in troubleshooting
  when after the fact problems are noted.
• Continue to work on replacement of final residing
  PTPs. Operating system (OS/2) is obsolete. No
  further upgrades to Avtec application software
  forthcoming.

58

• Security
• Bernie Tomardy

59
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Security
• Bernie Tomardy
• Head, Enterprise IT Security Branch
• IONet Security Officer
• Code 297
• 301-286-8089
• Bernard.V.Tomardy_at_nasa.gov

60
IONet Network Security Officer Code
297/Enterprise IT Security Branch
61
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Operational Security Team
• Firewalls
• IONet, CNE, EBNet, TSAN
• Encryption (PKI)
• Network Security Engineering
• Network Security Officer for IONet
• COMSEC

62
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Incident Response Team
• Work with Center OIG CCD
• First responder to Center ITS Incidents
• Intrusion Detection Systems
• ITS Forensic Support
• Recovery

63
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Security Assurance Team
• Network Scanning
• Auditing
• Agency Metrics
• Center Trend Analysis
• GSFC ITSM
• ITS Documentation

64
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• New Technology Communications Team
• Outreach
• Code 200 DCSO
• Code 100 DCSO
• WEB Development Maintenance
• ITS Training Metrics
• ITS Technical Evaluation
• ITS Lab
• ODIN Security Liaison

65
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Requesting Services from the IT Security Branch
  is easy, Just Screw Up, well be right there. ?
• All types of ITS Services are available
• System and Network Scans
• ITS Engineering Consulting
• System Accreditation
• Audit Assistance

66
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• IONet Network Security Team
• NSO Bernie Tomardy/GSFC
• Deputy NSO Owen Johnson/MSFC
• Alternate NSO Matt Kirichok/GSFC
• Audit Team Members from CSC
• Controlling Authority
• Public Law 100-235 The Computer Security Act of
  1987
• NPG 2810.1
• 290-004 IONet Access Control Policy

67
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Audit Process
• Review and certify security checklist, Security
  Plan, Risk Analysis, Contingency Plan,
  Authorization to process, and network diagrams.
• Verify logon banner on all NASA-owned or
  NASA-funded IT systems
• Perform vulnerability scan of all workstations
  connected to IONet
• Provide incident response isolate, investigate
  compromised workstations, and then assist
  projects in getting them reinstated to the Network

68
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Closed IONet further restricted by the NASA
  Resource Protection Program (NRP)
• NRP requires National Agency Checks for personnel
  with access to systems connected to the Closed
  IONet
• IONet security procedures are binding on all
  customers such as NASA Centers/facilities,
  contractors, universities, and International
  Partners

69
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• It is the responsibility of all projects with
  foreign commercial users to incorporate
  required security safeguards in contracts with
  these users
• Operational Controls for Closed Network
• All closed IONet IP addresses are classified as
  ADMINISTRATIVELY CONTROLLED INFORMATION (ACI)
  and must be protected accordingly
• Project network scanning is prohibited
• Transmission of outbound X-Terminal displays is
  prohibited

70
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Inbound FTP sessions limited, approved by NSO on
  a case-by-case basis
• Inbound telenet sessions are prohibited
• Internet and dial-up modem connections are
  prohibited
• Dual-homed systems, including firewalls, are
  prohibited. (Dual-homed means the IT has two or
  more network interfaces, each connected to
  different networks.)
• IONet personnel must control ALL muxes, switches,
  hubs, and routers connecting projects or centers
  to the Closed Segment.

71
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Restricted physical access to all equipment
  (including workstations or other computers)
  connected to Closed Segment is required. This is
  a NRP requirement.
• Connections to the closed network from the open
  network are via the IONet Secure Gateway ONLY!
• VPNs are not allowed through the Secure Gateway
• The NSO is the final authority on implementation
  and interpretation of the IONet Access Control
  Policy.

72
IONet Network Security Officer Code
297/Enterprise IT Security Branch

• Contact us
• WEB Off-Center Access http//code297.gsfc.nasa
  .gov
• WEB On-Center
• http//forbin2.gsfc.nasa.gov/297
• Phone contact
• NSO 301-286-8089 ITSM 301-286-2486
• PKI 301-286-6579 COMSEC
  301-286-3435
• IRT 301-286-0152 200 DCSO
  301-286-6398

73

• Project Communications Engineers
• Stan Rubin

74
PROJECT COMMUNICATIONS ENGINEERS

• What is a Project Communications Engineer?
• Member of the Information Services and Advanced
  Technology Division, the Customer Interface
  Branch or the Network Engineering Branch.
• Arranger of Communications Interfaces for Goddard
  Space Flight Center Projects.
• - IONET Mission Data
• - Mission Voice
• - Mission Video
• - NISN WAN

75
Requirements Fulfilled by the PCE

• Arranges for Mission data transport, voice and
  Video.
• Interfaces between Customers and NISN.
• Interfaces between Customers and the Security
  Office

76
PROJECT COMMUNICATIONS ENGINEERS

• What Extras Can the PCE Provide to the Projects?
• - Project Planning Assistance
• - Communications Network Development
• - Review of PSLAs and DMRs
• - NISN Interface Analysis
• - Communications Cost Analysis
• - Interface Between the Customer and
  Security
• - Project Testing Assistance

77
CSR FLOW DIAGRAM
Input Phase
No
Evaluation Phase
NISN Path
Solution Phase
CSR Path
No
Yes
Yes
NERD Approved
Submit to Contractor
Output Phase
Yes
Yes
Follow-up Phase
No
No
Requirement Fulfilled?
Yes
78

• NSMs Mission NSRs
• Chuck Duignan

79
NSMs
Enterprise/HQ Code NSM E-Mail Earth
Science Code Y/EOS Jerry Zgonc Gerald.R.Zgonc.1_at_n
asa.gov Human Exploration and Development of
Space Code M (Shuttle ISS) Seaton
Norman Seaton.B.Norman.1_at_nasa.gov Code M
(ISS) Kim Wright Kim.Wright_at_nasa.gov Aeronautics
Space Transportation Technology Code R Chuck
Duignan Charles.M.Duignan.1_at_nasa.gov Space
Science Code S Chuck Duignan Charles.M.Duignan.1
_at_nasa.gov
80
CSR FLOW DIAGRAM
Input Phase
No
Evaluation Phase
NISN Path
Solution Phase
CSR Path
No
Yes
Yes
NERD Approved
Submit to Contractor
Output Phase
Yes
Yes
Follow-up Phase
No
No
Requirement Fulfilled?
Yes
81

• Network Engineering Review Design
• Rita Kemp

82
Network Engineering Review Design

• Established in February 2002
• NASA Work Instruction 290-WI-8700.1.1 A ISAT
  Engineering Design Process
• Purpose
• Internal Peer Review Process to validate Code 291
  engineering designs and network modifications
• Provides recommendation for 290 Configuration
  Control Board Approval
• Members
• 291 Engineers
• 291 Operations Managers
• 297 Security Representative

83
290 Engineering Process

• Source of New Requirements
• Program Communication Engineers
• New Initiatives

• Implementation Completed
• CSRs Closed
• Customers Notified

• Project Lead and Team Assigned
• Support Contractors Raytheon,
• CSC, ACS

No
Peer Review Board (NERD) Approval of
Requirements, Design, Schedule, Risks, Impact to
Customers, Security, Documentation Approval
Assigned
Configuration Management Configuration Officer
maintains CCR Records

• Configuration Control Request Package
• Engineering Change (EC) Info
• Instructions
• Drawings
• Testing Required
• NERD Approval
• Distributed to 290 CCB for Signature

No

• Appropriate Design Reviews are
• Scheduled as Required by CCB Chair
• (Customers Invited to Attend)
• Preliminary Design Review
• Critical Design Review
• Operational Readiness Review

Yes
Approved
84
Networks and Projects
85
Mission Voice Replacement

• Scope
• Voice Distribution System (GSFC) and Voice
  Switching System (NASA) located at GSFC
• Goals
• To replace outdated equipment
• To maintain desired functionality and utilize
  latest technology
• To obtain a life expectancy of 15 years

86
Mission Voice Current Status

• - Continuing market survey began early 02
• Identifying potential vendors
• - Distributed user survey to control center
  managers in Fall 02
• lt 10 returned
• Critical need to get user input
• - Met with GSFC Procurement to develop
  procurement strategy

87
Mission Voice Current Status

• - Functional and Performance Requirements
  Document 290-027 approved
• - System Implementation Plan in draft
• - Preliminary Design Review to validate
  requirements and project plan presented to the
  NERD on 11/20/02

88
Mission Voice Next Steps

• - Incorporate additional user requirements into
  290-027
• - Finalize procurement strategy and System
  Implementation Plan December 02
• - Complete Market Research February 02
• - Develop test and transition plans April 02
• - Continue NERD and 290 CCB Reviews - ongoing
• - Provide continuing status to Projects - ongoing
• - Finalize design by Summer 02
• Dependent on procurement strategy

89

• Communications Strategic Plan
• Curt Suprock

An Introduction November 21, 2002
90
Goal, Scope Purpose

• Goal - To develop a plan for providing a highly
  reliable communications service for the Goddard
  Space Flight Center.
• Scope - Communications services include, but are
  not limited to, the following areas phone
  service, video teleconferencing, network
  connectivity, internet services, mission voice,
  mission data, video transmission and the securing
  of these services.
• Purpose To provide an introduction and overview
  to those proposals currently being considered
  part of the Centers Communication Strategic Plan

91
Background Current Situation

• Multiple networks and internet services with
  significant overlap of services
• Multiple organizations and contracts involved in
  providing communication services
• Results in redundant and not fully utilized
  services
• Center is paying for the same type of service
  many times
• No single source responsible and accountable for
  providing communications services
• Little or no coordination among the different
  entities involved in provisioning communications
  services

92
Communications Drivers Opportunities

• - Newer and more capable technology available
  across all areas (data, voice and video)
• Increasing capabilities at same or reduced cost
• - Static or reduced equipment, manpower and
  travel budgets
• - Increased security risk and awareness
• Security threats are increasing in both quantity
  and sophistication
• - Facilities Master Plan
• New buildings require communications
  infrastructure
• Opportunity to improve Center infrastructure
• - New administrative phone system provides
  increased capabilities and expandability
• - OneNASA IT Architecture as defined by Paul
  Strassman
• Secure and redundant local area networks
  engineered and managed by Center CIOs according
  to Level 0 Architecture (Level 3 Local Nets)

93
Communications Challenges

• - Multiple organizations performing same
  function(s) across the Center
• Differing levels of ability and resources per
  organization
• Increased security risk (misconfiguration, patch
  application, etc)
• Non-optimization and waste of resources
• Inhibits ability to integrate services for the
  Center
• Results in differing levels of communications
  services for Center personnel
• Divides the Center into haves and have nots
  based upon organization resource availability and
  capability
• - Outsourced contracts limit interaction and
  flexibility
• Both ODIN and CSOC prevent rapid response to
  changing requirements and limit ability to take
  advantage of new technology and changing
  priorities
• Contract costs continue to increase while all
  requirements are not met
• - Requirement to support new and enhanced
  services
• Video Teleconferencing, Collaborative Tools,
  Increased Bandwidth, Storage Area Networks,
  Visualization, Increased Security Requirements

94
Proposal Overview

• - Integrate communications services in the
  infrastructure communications organization, Code
  290
• Provide one-stop shopping for the Center for all
  communications services
• Eliminate redundancy and allows optimization of
  communications services for the Center
• - Migrate toward an IP-based full service network
  infrastructure
• Convergence of voice, video and data
• Initially implement in new buildings and
  buildings still to be transitioned to structured
  cabling system
• Transition existing CAT-5 buildings on a planned
  schedule

95
Organization Proposal Overview

• - Provide communications services to the Center
  in a requirements-based organizational approach
• Focus communications requirements on Code 290
  not in terms of equipment or designs, but
  functionality and performance
• - Code 290 would provide Organization based
  Customer Service Specialists
• Specialists would take ownership of customers
  requirements and insure that they are met
• Similar to todays Telephone Managers or Project
  Communications Engineers (PCEs) who are assigned
  on a per-Project basis
• Establish Code 290 Ombudsman to resolve any
  issues that cannot be handled by organizations
  support specialist
• - Staffing evaluation underway and appropriate
  levels to be defined
• Civil service roles and staffing levels
• Contract model and staffing levels

96
Service Levels Overview

• - Establish service categories and definitions,
  along with published service levels
• Some examples of service categories could include
  Administrative Data, Mission Critical Data,
  Administrative Voice, Mission Critical Voice,
  Video Distribution (TV), Video Teleconferencing
• - Service Level Agreements will be established
  for each service category as a contract with the
  Center
• Separate SLAs could be established, via an
  interactive process, with projects and
  organizations for service levels beyond that
  established in Center SLAs, as needed
• Code 290 would take responsibility for insuring
  that SLAs are met
• Metrics to be available to Center, Organizations
  and Projects to display actual performance

97
Customer Stakeholder Interacion

• - CIO structure would remain and be responsible
  for high-level IT policy
• Code 290 participation, including Ombudsman, to
  provide responsiveness
• - Communications User Group(s) to be formed
• Participate in the establishment and validation
  of communications priorities
• Forum for requirements discussion and status
  reports
• Provide grass-roots input to communications
  service provider
• Representation from all interested organizations
• Multiple groups could be required, focusing on
  different service categories
• - Center Firewall Review Board (CFRB) would have
  responsibility expanded to entire Center
  perimeter

98
Infrastructure Architecture Overview

• - Objective is to have all communications
  requirements met via IP-based network
  implementations
• - All communications equipment and facilities in
  the network would be controlled by Code 290
• Eliminates user purchased equipment being
  deployed in the network
• Prevents security risks, such as backdoors,
  associated with improperly configured equipment
• Prevents equipment being deployed without
  adequate maintenance support
• Users fund requirements not equipment
• - Institutional communications evaluation and
  tech insertion to be conducted by Code 290
• Insures understanding of requirements and current
  network are included in analysis of new
  technology

99
Network Implications

• - Utilize existing network infrastructures to
  provide needed level of IP-service where and when
  appropriate no attempt will be made to shoehorn
  into a particular technology or design
• Network complexity will be hidden from the user.
  Allows users to concentrate on the application
  for their jobs, not on the network.
• - Must continue to maintain separation of
  real-time mission critical traffic from all other
  traffic to insure its priority and security
• Established security guidelines and access
  control plans
• - User connections to be defined in service
  categories
• Reviewed and updated on a regular basis

100
Specific Communications Services

• - Administrative Voice
• Migrate to IP-based solution
• Currently available via Siemens and being
  prototyped by Code 290 at WFF
• Implement in all new buildings and upgraded
  network buildings on a scheduled basis
• Cost savings due to elimination of MAC charges,
  as users would be able to move phones themselves
• Supports teleworking with users able to use their
  phone instruments via ISP connection (with
  adequate security)
• - Mission Voice
• Transition mission voice to a mission-equipped
  and supported phone node or IP-based server
• Majority of requirements could be met
• Requires projects to accept different way of
  meeting requirements
• Precedents - Nascoms 4800BB to IP Transition,
  Nascoms Low Speed Message Switch to
  Administrative Message System/Tracking Data
  System Transition

101
Communications Specific Services (Continued)

• Remote Access
• Support VPN/Secure methods (Web Mail, PKI, SSH)
  for users via ISPs for telework and majority of
  travelers
• Maintain limited dial-in capability for some
  travelers and occasional at home use
• Electronic Mail
• Single infrastructure to support Center
• Disconnect unauthorized mail (no open mail
  relays)
• Cost savings due to time freed from operating and
  maintaining mail service - as well as reduced
  security exposure
• Wireless Data
• Establish standards for security and protocols
• Deploy in conference rooms (Division up),
  Auditoriums and open areas
• Deploy based on user-funded requirements

102
Specific Communications Services (Continued)

• - Video
• IP-based teleconferencing and streaming video
• Institutionally provided multi-point service
• Support end user (Conference Room and desktop) as
  required
• Support multi-cast throughout network
• Migrate NASA TV to network (web cast) for
  majority of users
• Make desktop video systems available via
  workstation contracts and conference room units
  available via SEWP-type vehicle
• - Web Server Facility
• Web hosting service (both pages and systems)
• Secure, environmentally controlled facility
  (power, air)
• Isolated from backbone (DMZ)
• Support both public and private web pages

103
Security

• - Unauthorized equipment will be disconnected
• - Telecommunications facilities will be limited
  to appropriate personnel
• - Security architecture to support multiple
  layers of security, based on user requirements
• Pre-defined set of security layers available,
  with user able to specify appropriate layer
  required
• Architecture would include firewalls (network and
  local), router access lists, VPNs and encryption
  (as appropriate)

104
Resources

• - Establish Business Plan for communications
  services at the Center utilizing a tier-based
  approach with a budget consisting of two
  components
• An infrastructure element for normal level of
  communications operations, maintenance, tech
  refresh, emergencies and unanticipated
  requirements (new Projects, rehabs, moves, etc)
• An user requirements element based upon
  established SLAs and business model and funded
  via programmatic sources
• - Different organization model may be required
  for Code 290 to proactively support the
  requirements-based provisioning of all
  communications for the Center

105
Benefits

• - Establishes clear source for all communications
  services for the Center
• Organizations would be able to deal with one
  interface for all of their communications needs
  avoids confusion in provisioning of
  communications services
• Definition and display of performance metrics, as
  well as civil service interaction, to win back
  customer confidence
• - Government leadership would allow for more
  flexible reaction to customer needs, priorities
  and problems
• Enhances the ability of the network to respond to
  emergencies and changing requirements
• Not insight or oversight, but true responsibility
  coupled with appropriate authority
• - Enhances capability of Government to secure and
  monitor the network
• Quicker response time to security risks and
  emergencies
• Completed knowledge of the security posture of
  the network

106
Risks

• - Several buildings with inadequate
  infrastructure to support plan
• Old Engineering Directorate Network buildings
  require full structured cabling system
• Earlier CAT-5 Initiative buildings require Tech
  Refresh
• Replace shared equipment and non-router capable
  building switches
• In progress with existing CNE Equipment budget,
  may require acceleration
• Movement of phones to network may require
  additional CAT-5 jacks
• Mitigate by use of workstation integrated phones
• - Adequate funding required to support
  infrastructure
• Maintenance costs for network equipment,
  staffing, security services, communications and
  security tech investigation, communications
  equipment
• - Integration of existing networks and services

107

• Questions and Answers
• Chuck Duignan

108

• Closing Remarks
• Chuck Duignan

109
Contact Listing

• In Presentation Order
• Craig Hegemann Associate Division Chief
  301-286-7337 craig.j.hegemman_at_nasa.gov
• Chuck Duignan Operations Manager
  301-286-6342 charles.m.duignan_at_nasa.gov
• Vicki Stewart Asst. Ops Manager
  301-286-6205 victoria.l.stewart_at_nasa.gov
• Mike Allen LAN Operations Manager
  301-286-2527 mallen_at_pop500.gsfc.nasa.gov
• Mike Eder Tech Control Supervisor
  301-286-3536 michael.j.eder.1_at_gsfc.nas
  a.gov
• Sandra Marshall Voice Control Supervisor
  301-286-9570 mcdoug_at_pop500.gsfc.nasa.gov
• Brian Durkin EMS Supervisor
  301-286-8169 bdurkin_at_pop500.gsfc.nasa.gov
• Norman Reese IP NOC Supervisor
  301-286-6486 nreese_at_sled.gsfc.nasa.gov
• Joel Peterman CDM Manager
  301-286-9587 Joel.w.peterman.1_at_gsfc.nasa.gov
• Bernie Tomardy Security Branch Head
  301-286-8089 bernard..tomardy_at_nasa.gov
• Stan Rubin PCE Team Lead
  301-286-4230 stanley.d.rubin_at_nasa.gov
  
• Rita Kemp Network Eng Team Lead
  301-286-7535 Margarita.t.kemp_at_nasa.gov
• Curt Suprock 291 Asst. Branch Head
  301-286-6196 curt.a.suprock_at_nasa.gov