451-OTP-NCCDS-NCC98

> Flight Projects Directorate

Network Control Center (NCC) Data System (NCCDS) 1998

NCC 98 Operations Transition Plan (OTP)

January 1999

![](media/image1.emf)

![](media/image2.wmf){width="6.6097222222222225in"
height="0.7986111111111112in"}

Network Control Center Data System (NCCDS) 1998

NCC 98 Operations Transition Plan (OTP)

January 1999

Prepared Under Contract NAS 5-31000

Task: GSA D.4 -- NCC Project

By

Computer Sciences Corporation

Prepared By:

*John A. Russell* 1/29/99

J. Russell Date

NCC 98 Release Leader

Quality Assured By:

*Mary Sanchez* 2/2/99

for B. Ferguson Date

NCC Quality Assurance Officer

Approved By:

*J. Praytor* 2/2/99

J. Praytor Date

Technical Manager

NCC System Engineering

Approved By:

*Gail Swick* 2/2/99

for D. DeSantis Date

Project Manager

GSA D.4 - NCC Project

**Goddard Space Flight Center\
**Greenbelt, Maryland

Preface

Network Control Center Data System (NCCDS) 1998 (NCC 98) is the first
step in migrating the NCCDS from the current proprietary system to an
"open system" featuring a client/server architecture, substantial use of
commercial off-the-shelf (COTS) products, and industry standard
communications protocols.

Questions concerning this document or proposed changes shall be
addressed to:

L. Myers\
Code 451\
Goddard Space Flight Center\
Greenbelt, Maryland 20771

Abstract

This document summarizes the overall activities required to transition
from Network Control Center Data System (NCCDS) Release 95.3 to NCC 98.
It provides a general description of the activities along with a
timeline showing relative durations and ordering relationships. This
document provides a basis upon which to coordinate the actual
transition.

The transition to NCC 98 requires extensive coordination. It requires
the migration of the Service Planning Segment (SPS) database from the
current schema on the UNISYS mainframe to a new schema under an Oracle
database on a Hewlett-Packard (HP) server. The transition must also
facilitate the movement away from proprietary communication protocols to
industry-standard protocols. This plan attempts to identify the areas
where coordination is necessary.

Contents

**Preface**

Abstract

Section 1. Introduction

1.1 Purpose 1-1

1.2 Scope 1-1

1.3 Document Overview 1-1

1.4 References 1-2

Section 2. Special Considerations

2.1 General 2-1

2.2 NCC Considerations 2-1

2.2.1 Assumptions 2-1

2.2.2 Special Instructions 2-1

2.3 Network Considerations 2-2

2.3.1 Assumptions 2-2

2.3.2 Special Instructions 2-2

Section 3. Transition Activities

3.1 Establish NCC 98 Operational Environment 3-1

3.1.1 SPSR Preparation 3-1

3.1.2 CCS Preparation 3-4

3.1.3 Workstation Preparation 3-4

3.1.4 Firewall Preparation 3-5

3.1.5 NPG Preparation 3-6

3.1.6 SCD Preparation 3-8

3.1.7 NSM/Cluster Preparation 3-8

3.1.8 WWW Server Preparation 3-9

3.1.9 NCD Preparation 3-10

3.1.10 System (SRIS) Preparation 3-11

3.1.11 SAS Preparation 3-12

3.2 Transition to NCC 98 3-14

3.3 Contingency Plans 3-14

3.4 Preparation and Failover to CCS1/CCS2 3-16

3.4.1 CCS1/CCS2 Preparation 3-16

3.4.2 Failover to CCS1/CCS2 3-16

3.5 Preparation of ANCC 3-16

3.6 Completion of OCR 3-17

3.6.1 ITS Removal 3-17

3.6.2 Workstation Installation 3-17

Section 4. Transition Timelines

4.1 Timeline of Activities for Initial NCC 98 Operational Transition 4-1

4.2 Timeline of Activities to Configure Operational Suite 4-4

Abbreviations and Acronyms

Section 1. Number range head5Number range head4Number range head3Number
range head2Introduction

0.1 Number range head5Number range head4Number range head3Purpose

The purpose of this Operations Transition Plan (OTP) is to provide an
overall script of activities necessary for the successful delivery of
Network Control Center Data System (NCCDS) 1998 (hereafter referred to
as NCC 98) to Operations. This plan will assist in the transition of
NCC 98 from Operational Evaluation Testing (OET) to Operations.

0.2 Number range head5Number range head4Number range head3Scope

The OTP encompasses the activities required to transition NCC 98 to
Operations. This plan discusses:

Number range alfDNumber range alfCNumber range alfBNumber range
alfDNumber range alfCNumber range alfBNumber range alfANumber range
alfDNumber range alfCNumber range alfB• Special Considerations

• Number range alfDNumber range alfCNumber range alfBNumber range
alfATransition Activities

− Establishing the Operational environment in the Operations Control
Room (OCR) facility.

− Removing control from the baseline NCCDS (Release 95.3) and switching
to NCC 98.

• Post-transition activities

− Preparation of the Communications and Control Segment (CCS)1 and CCS2
to support NCC 98.

− Completion of removal of Intelligent Terminal (IT) Segment (ITS) from
the OCR.

The OTP provides an overall approach to moving NCC operations onto the
NCC 98 platform. The OTP also includes detailed transition steps, an
estimated timeline of activities, and the type of support personnel
necessary to transition to NCC 98.

0.3 Number range head5Number range head4Number range head3Document
Overview

This document is divided into four sections. This section, Section 1,
provides a high-level scope and organization of the document. Section 2
provides special points of consideration, including special instructions
that should be addressed prior to the transition of this release to
Operations. Section 3 describes the activities required to prepare for
and complete the transition of NCC 98 to Operations. Section 4 provides
timelines for these activities, indicating relative duration, ordering
relationships, and dependencies.

0.4Number range head3Number range head4Number range head5Number range
head6 References

This plan is provided to augment the *Network Control Center (NCC) 98
Test and Transition Master Plan,* Revision A, dated January, 1998.
Additionally, the following documents are referenced by this plan or
contain related information.

• Network Control Center Data System (NCCDS) System Requirements, 1998,
Revision 2 (Draft), April 1998.

• Interface Control Document Between The Network Control Center Data
System and The Mission Operations Centers, May 1998.

• Interface Control Document (ICD) between the Network Control Center
(NCC)/ Flight Dynamics Facility (FDF) and the White Sands Complex (WSC),
Revision 5, June 1997.

• Network Control Center Data System (NCCDS), System Integration Plan,
1998, January 1997.

Section 1. Number range TableNumber range figsNumber range head5Number
range head4Number range head3Number range head2Special Considerations

1.1 Number range head5Number range head4Number range head3General

This section provides information regarding assumptions and impacts that
must be addressed in order to transition from NCCDS Release 95.3 (also
referred to as the "Baseline NCCDS" or "legacy system") to NCC 98. This
information is provided to facilitate the transition process, both at
the NCC and at the Space Network (SN) level.

1.2 Number range head5Number range head4Number range head3NCC
Considerations

NCC 98 is the first step in migrating the NCCDS from the current
proprietary system to an "open system" featuring a client/server
architecture, substantial use of commercial off-the-shelf (COTS)
products, and industry standard communications protocols. The
significant changes required to transition operations onto this new
platform will impact NCC Operations and the SN. Assumptions and
considerations internal to the NCC related to the transition from
Release 95.3 to NCC 98 are identified in this section.

1.2.1Number range head5Number range head4 Assumptions

This section identifies conditions internal to the NCC that must exist
prior to transitioning to NCC 98. This list includes only those
conditions unique to the transition as compared to those for everyday
operations.

The assumption for the transition to NCC 98 is:

[Database Freeze Is In Effect]{.underline} - The contents of the
database must be frozen prior to transitioning to NCC 98. The timeline
of activities included in Section 4 of this document provides the
relative time to begin the freeze and its duration. This implies that
the active schedule consists of events for at least 2 weeks and that the
forecast period is free of requests.

1.2.2Number range head5Number range head4 Special Instructions

This section identifies specific activities or steps that must be
performed during the transition to ensure that the operational
environment is stable and normalized for supporting NCC 98. These
activities or steps are unique to the transition to NCC 98 as compared
to those presented in the high-level timeline of activities presented in
Section 4.

The unique considerations for the transition to NCC 98 are:

[Population of Ground Terminal Database]{.underline}: The database
freeze implies that the ground terminal has been supplied with a
sufficient number of vectors and events to provide SN support for 48
hours.

1.3 Number range head5Number range head4Number range head3Network
Considerations

1.3.1Number range head5Number range head4 Assumptions

This section identifies assumptions that apply to the entire network,
including the ground terminals, the NASA Integrated Services Network
(NISN), the Sensor Data Processing Facility (SDPF), and all customers of
the SN. The assumptions identified are necessary for a successful
transition and may be part of normal, everyday operations.

The assumptions for the transition to NCC 98 are:

[Legacy Message Switching System (MSS) is Decommissioned]{.underline} -
NCC 98 is implemented to support Internet Protocol (IP) communications.
This change removes the NCC Front-End (NFE) processors from the NCCDS
architecture. Without this equipment, the NCC can no longer support pure
4800BB protocol. Therefore, the legacy MSS must be decommissioned prior
to the transition to NCC 98.

This assumption has further implications regarding the user interface
channel allocated to scheduled services. NCC 98 will no longer schedule
"secondary" user interface channels (UIFCs). Therefore, these UIFCs must
be deleted from the configuration codes and all scheduled events in the
legacy system prior to performing the NCC 98 database migration.

[New Schedule Result Message Content]{.underline} - NCC 98 implemented
changes to the format of the Schedule Result Messages (SRMs). These
changes were implemented as part of the Flexible Scheduling
requirements, which have subsequently been deferred to a future release.
However, the changes to the format of the SRM are being retained such
that the SRM format was consistent with the format specifications in
530-ICD-NCCDS/MOC. This should not impact customers (i.e., they should
be compliant with the approved ICD), it should be verified through
Engineering Interface (EIF) testing that the customers can support the
new SRM prior to transitioning to NCC 98.

1.3.2Number range head5Number range head4 Special Instructions

This section identifies specific activities or steps that must be
performed to ensure that the transition to NCC 98 does not negatively
impact the activities of the Space Network.

The specific activities for the transition to NCC 98 are:

[Proficient Use of Communications Test Messages (CTMs)]{.underline} -
With NCC  98, the NCCDS transitions from 4800BB protocol to User
Datagram Protocol (UDP)-encapsulated blocks. Because of this change, the
NCC will begin sending CTMs to all legacy sites at a configurable
interval. These CTMs are necessary to ensure reliable communications
when translating between UDP and Transmission Control Protocol (TCP).

[Change the TCP Service Hosts]{.underline} - NCC 98 changes the host
addresses providing services to TCP/IP customers. With NCC 97, a single
server (i.e., the NCC Protocol Gateway (NPG)) provides these services.
With NCC 98, these services are provided by multiple hosts, namely the
Service Planning Segment (SPS) Replacement (SPSR) and the NPG. TCP MOCs
will be impacted during the transition to NCC 98 while network changes
are implemented. TCP MOCs should follow the TCP connection establishment
instructions as documented in the MOC ICD to reestablish lost service
connections.

[Update of External Domain Name Server (DNS)]{.underline} - The External
DNS, that is the advertisement of services provided by the NCCDS, will
be updated at the time of transition. The updated DNS file must be
accessed by the Closed IONET DNS server so that TCP MOCs will be able to
resolve services to IP addresses. Reducing the "time to live" prior to
the transition will force the NISN DNS server to query the External DNS
more frequently. This will in turn facilitate the transition from NCC 97
to NCC 98. The update of the Closed IONET DNS is directly related to the
previous item. This may include NISN redefining which node is the
Authoritative DNS server for the NCC.

[Modification of the NISN Secure Gateway Rule Set]{.underline} - The
Rule Set defining the activity permitted through the Secure Gateway must
be changed as of the NCC 98 transition. The Rule Set must be modified to
allow Open IONET entities to communicate with the NCC TCP Service
providers as well as access new services, such as Tracking and Data
Relay Satellite (TDRS) Unscheduled Time (TUT). This change should be
communicated in advance of the transition such that the change in the
Rule Sets can be phased in.

[Notify Open IONET Customers]{.underline} - Open IONET customers do not
use DNS for service to IP Address resolution. Therefore, Open IONET
customers (and some Closed IONET customers) must be notified of the new
NCC TCP Service providers and a what time they are to become prime. This
communication can take place in advance of the transition with a last
minute "ready or not" notification of the change of control.

[White Sands Complex (WSC) Software Update]{.underline} - NCC 98
requires WSC to send a "new" Schedule Order (SHO) Status message with
status code of "5" when events are successfully deleted (or completed)
from the WSC database. WSC implemented this software change to be
configurable (i.e., either "on" or "off"). "Turning on" this feature
requires WSC to change the value of a logical. This activity must be
coordinated along with the transition to NCC 98.

[Second TDRS Ground Terminal (STGT) Software Update]{.underline} - A
software delivery will have to be made to STGT (only) to make the STGT
software for the SHO header compatible with the changes made in NCC 98
to support the Dual User SHO and Space Network Interoperability Panel
(SNIP) pseudorandom noise (PN) codes. WSC is planning to deliver this
fix under ETN‑295 to STGT prior to the NCC 98 transition.

Section 2Number range TableNumber range figsNumber range head5Number
range head4Number range head3Number range head2. Transition Activities

2.1 Number range head5Number range head4Number range head3Establish
NCC 98 Operational Environment

While NCC operations remain in the operational suite under the current
release, the current OET environment will be prepared for NCC 98
Operations. The following sections detail the appropriate preparation
for each segment.

2.1.1Number range head5Number range head4 SPSR Preparation

The SPSR preparation consists of several activities, including migrating
the SPS database, both static and dynamic data areas, establishing SHO
records for the existing events, and final verification of the SPS
configuration.

2.1.1.1Number range head5 NCC 98 Baseline Verification

Prior to the day of the transition, the SPSR baseline will be audited
and documented. This activity can occur once all changes to the OET
baseline have been delivered. This audit will verify that the
appropriate versions of executables are resident on the system.

2.1.1.2 Number range head5Database Migration

The database migration is done in two phases. The first phase will be
the migration of the SPS database to flat files. The second phase will
be the ingestion of the flat files and additional data into the Oracle
database.

By the time of the transition, the OET group will have been testing with
a migrated database for several months. Their testing activities have
included making the migrated data compatible with NCC 98 Operations for
shadowing, EIF testing, etc. The second phase portion of the final
database migration will attempt to take advantage of the work performed
on the OET database by importing certain tables, such as
dbWindowPrivMap, from their database. The potential application of this
approach is indicated in the following section.

2.1.1.2.1 Database Migration Assumptions

A list of assumptions has been established to control the database
migration from the SPS (legacy NCCDS) to SPSR (NCC 98).

The following assumptions are made for this migration:

-   The TDRS Satellite Identification Codes (SICs) and TDRS identifiers
    (IDs) are as defined in 530-ICD-NCCDS-FDF/WSC (TDRS A/SIC 1300
    through TDRS J/SIC 1309. These will be migrated from their
    definitions in the SPS database.

-   UIFC types are derived from their identifiers as follows: "W"
    channels are local interface (LI) ports; "V" channels are video; "X"
    channels are analog; "Y" channels are recorder; and "Z" channels are
    High Data Rate Multiplexer (HDRM) channels. All other UIFCs are
    assumed to be multiplexer/demultiplexer (MDM) channels.

-   The default customer service parameters will be defined in a
    separate file for ingestion into the SPSR database. This file was
    originally based on the service parameters for SIC 1294.

-   The default TDRS service parameters will be defined in the SPS
    database as those for SIC 1294.

-   The Transmission Rule Sets will be defined by the Database
    Administrator (DBA) and ingested during the migration (or simply
    taken from the OET database).

-   There will be no migration of vectors, maneuver sets, or delta-Ts.

-   There will be limited requests in the forecast period as the desired
    time for migration is immediately following the weekly schedule
    activation and transmission. The database migration will NOT migrate
    forecast requests from the SPS to the SPSR.

-   The Scheduler will ensure that the ground terminal has received the
    maximum number of SHOs possible prior to phase 1 of the migration.

-   The Performance Analyst/Acquisition Tracking (PA/ACQ-TRK) operator
    will ensure that the ground terminal has received the maximum number
    of vectors as possible prior to phase 1 of the migration.

-   After migration, User Schedule Messages (USMs) and Nascom Event
    Schedule (NES) messages will be generated for all migrated events.
    This implies that that MOCs, NISN Event Scheduling Terminal (NEST),
    and SDPF, may receive a schedule message for an event for which they
    were previously notified. It is assumed that this second message can
    be "handled" by the respective systems.

2.1.1.2.2 Database Migration Results

The database migration is ultimately supposed to manipulate the existing
data such that it can be utilized by NCC 98. This manipulation consists
of modifying and deleting existing data, creating new database areas,
and efficiently performing data changes that are required for NCCDS 98.
Data changes include establishing the initial values for new parameters
added with the NCC 98 database. The following list describes the
expected results of specific items of the migration.

-   The TDRS SICs and IDs are as defined in 530-ICD-NCCDS-FDF/WSC (TDRS
    A/SIC 1300 through TDRS J/SIC 1309. These will be migrated from
    their definitions in the SPS database.

-   The Space-to-Ground Link Terminal (SGLT) Resources will be defined
    such that all SGLTs are fully functional. Any adjustment to the
    availability of SGLT resources will be made by the DBA after
    migration.

-   The TDRS Resources will be defined such that all TDRSs are fully
    functional. Any adjustment to the availability of TDRS resources
    will be made by the DBA after migration.

-   The list of valid UIFCs for a customer will be the union of all
    UIFCs included in all configuration codes for that customer resident
    on the SPS at the time of the migration.

-   The UIFCs that require SDPF support will be identified through a
    list provided by the DBA prior to the migration. The migration will
    flag all "D" channels and the ones identified by the DBA as
    requiring SDPF support.

-   All combinations of SIC and User ID will have the same password (as
    migrated from the SPS database). Any definition of new passwords
    will be done by the DBA after transition (or simply taken from the
    OET database).

-   The list of destinations associated with each SIC will originate
    from the SPS Schedule Distribution list. All destinations will be
    defined to be "fixed," vice flexible.

-   The Valid IP addresses for each support identifier (SUPIDEN) will be
    blank. These will be entered by the DBA after transition (or simply
    taken from the OET database).

-   All Multiple Access (MA) Return (MAR) configuration codes will be
    migrated such that they do not specify an MAR Link.

-   The User S-band and K-band PN codes will be migrated to be equal for
    non-shuttle SICs. The value will be the same as the K-Band PN Code
    currently stored for each SIC in the SPS database. For Shuttle SICs,
    the values will be migrated directly from their corresponding values
    in the SPS database.

-   The End Times for MDM and HDRM Overhead records will be set to
    December 31, 1999, during the migration. The DBA should manually
    adjust this end time as necessary through the delivered user
    interface windows.

-   The End Times for TDRS-to-SGLT mappings will be set to December 31,
    1999, during the migration. The DBA should manually adjust this end
    time as necessary through the delivered user interface windows.

• SHO IDs for events that have been transmitted to the ground terminal
(GT) via the legacy system are mapped to their migrated event. This will
be done by executing a transmission without a service connection to the
NPG, overlaying SHO IDs, and then setting the transmission status of
each SHO and of the transmission as a whole to completed.

• The maximum forward and return data rates for MDM Channels will be set
to 7 Mbps in dbGroundTermPort.

2.1.1.3Number range head5 Final Verification

After completing database migration activities, a final verification of
the complete SPSR environment will be performed. This final verification
will be done such that the OET suite will be ready to support Operations
immediately following its completion.

2.1.2Number range head5Number range head4 CCS Preparation

The CCS preparation will be minimal since CCS3 will be used for the
transition. This machine has been undergoing OET testing and should be
ready to support NCC 98.

2.1.2.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the CCS baseline will be audited and
documented. This activity can occur once all changes to the OET baseline
have been delivered. This audit will verify that the appropriate
versions of executables are resident on the system.

2.1.2.2Number range head5Number range head6 CCS Data File Verification

The Site Table on CCS3 should be compared to the Site Table on CCS1 and
CCS2 and updated accordingly. This activity should take place during the
preparation for transition.

The Site Table on CCS3 should then be compared to the NPG Configuration
files. Differences, if any, between these two files should be resolved
at this time.

The DQM_USERS.DAT file on CCS1/CCS2 should be reviewed and compared to
CCS3. Any differences between the two files should be resolved such that
the file on CCS3 is correct for NCC 98.

2.1.2.3Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 CCS environment will be performed. The final
verification will include the execution of a full static data transfer.
This final verification will then be done such that the OET suite will
be ready to support Operations immediately following its completion.

2.1.3Number range head5Number range head4 Workstation Preparation

The workstation preparation will be minimal since these workstations
have been undergoing OET testing and should be ready to support NCC 98.

2.1.3.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the baseline on each workstation
will be audited and documented. This activity can occur once all changes
to the OET baseline have been delivered. This audit will verify that the
appropriate versions of executables and other supporting files are
resident on the system.

2.1.3.2Number range head5Number range head6 Verification of Operator
Accounts

Prior to the transition, each operator account should be exercised to
ensure the correct configuration. The majority of this activity will be
performed in conjunction with operator training provided by OET. For
this plan, the list of accounts, groups, and home directories will be
compared against each other prior to the migration.

This activity will also verify the assignment of the proper toolbar for
each operator. Operators who have been assigned to the DBA, System
Supervisor (SS), or Technical Manager (TM) groups will be provided
toolbars that grant access to a UNIX terminal window.

2.1.3.3Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include the execution of "some" options from the toolbar of "some"
operator. This final verification will then be done such that the OET
suite will be ready to support Operations immediately following its
completion.

2.1.4Number range head5Number range head4 Firewall Preparation

The Firewall preparation consists of verifying the NCC 98 baseline is
installed, verifying the Rule Sets and objects, verifying Mproxy and
High-Availability (HA) configuration files, and performing the final
checkout.

2.1.4.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the Firewall baseline will be
audited and documented. This activity can occur once all changes to the
OET baseline have been delivered. This audit will verify that the
appropriate versions of executables and scripts are resident on the
system.

2.1.4.2Number range head5Number range head6 Verification of Rules and
Objects

The most important step in preparing the Firewall for operational use is
the verification of the Rules and Objects loaded in the active security
policy on the Firewall. The Rules should be reviewed to ensure that all
rules added to facilitate testing are deleted or disabled.

The Objects should be reviewed to ensure that all objects are correctly
identified by name, group, IP address, etc. This activity may require
advanced coordination with NISN to ensure that the correct IP addresses
of multicast small conversion devices (SCDs) are in the Firewall objects
list.

This audit will also verify that each Firewall has the same rules and
objects.

2.1.4.3Number range head5Number range head6 Verification of Mproxy
Configuration Files

This activity should validate that the NCC Multicast address is
correctly entered in the appropriate configuration files. The NCC 98 EIF
testing used a multicast address that was different than the operational
multicast address. The NCC's multicast address in the Mproxy
configuration files should be verified while NCC 97 and NCC 98 run in
parallel just prior to the transition.

This activity should also validate that the correct multicast addresses
for the MOCs are correctly entered in the appropriate configuration
files. The NCC 98 OET testing used a single multicast address for all
external interfaces simulated by the NTS. This address must be replaced
with the correct operational multicast address for each MOC. These
multicast addresses should be verified through EIF testing prior to
transition.

This audit will also verify that each Firewall has identical Mproxy
configuration files.

2.1.4.4Number range head5Number range head6 Verification of HA
Configuration Files

The HA configuration files should be audited for correctness prior to
the transition. This audit should ensure that

• the correct initial role is defined for each machine.

• the correct heartbeat nodes/addresses are listed.

This audit will also verify that the internal/external (i.e., split)
Firewall configuration utilized in testing is normalized. This will
establish Closed IONET connections from both Firewalls with the active
connection being through the primary firewall.

2.1.4.5Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include the flow of data from the NPG through the Firewall (Mproxy)
to the NCC Test System (NTS). This final verification will then be done
such that the OET suite will be ready to support Operations immediately
following its completion.

2.1.5Number range head4Number range head5Number range head6 NPG
Preparation

The NPG preparation consists of verifying the NCC 98 baseline is
installed, verifying the necessary configuration files, and performing
the final checkout.

2.1.5.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the NPG baseline will be audited and
documented. This activity can occur once all changes to the OET baseline
have been delivered. This audit will verify that the appropriate
versions of executables and scripts are resident on the system.

2.1.5.2Number range head5Number range head6 Verification of NPG
Configuration Files

The NPG configuration files should be audited for correctness prior to
the transition. This audit should ensure that

• the vehicle IDs (VIDs) on the NPG match those on the SPSR database for
each SIC;

• the User ID, SUPIDEN, Password combinations for each Schedule Result
Request (SRR) match those in the SPSR database;

• the port numbers in the msscodes file match those in the Mproxy
configuration files;

• the correct CCS hostnames and ports are identified (CCS3 initially);

• the use of polynomial error protection (PEP) is enabled for all legacy
MOCs;

• the site information in consistent with CCS.

This audit will also verify that each NPG has identical configuration
files.

2.1.5.3Number range head5Number range head6 Verification of VT
Configuration Files

The Vector Translator (VT) configuration files should be audited for
correctness prior to the transition. This audit should ensure that

• the correct polling interval is set;

• the correct directory location is specified for the improved
inter-range vector (IIRV) files;

• the correct File Transfer Protocol (FTP) server(s) is/are specified;

• the correct server/service for receiving vectors is identified.

This audit will also verify that each NPG has identical VT configuration
files.

2.1.5.4Number range head5Number range head6 Verification of HA
Configuration Files

The HA configuration files should be audited for correctness prior to
the transition. This audit should ensure that

• the correct initial role is defined for each machine;

• the correct heartbeat nodes/addresses are listed.

2.1.5.5Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include the flow of messages from the SCD through the NPG to the
CCS, Service Accounting Segment (SAS), and the SPSR. This final
verification will then be done such that the OET suite will be ready to
support Operations immediately following its completion.

2.1.6Number range head4Number range head5Number range head6 SCD
Preparation

The SCD preparation consists of verifying the necessary configuration
and performing the final checkout.

2.1.6.1Number range head5Number range head6 SCD Configuration
Verification

The SCD configuration should be audited for correctness prior to the
transition. This audit should ensure that

• the appropriate version of the SCD software is loaded;

• the Nascom Interface Boards (NIBs) of the SCD are configured to route
outbound messages over the appropriate RS-422 connection;

• inbound messages are routed to the prime NPG;

• clock rates of each NIB are set correctly.

This audit will also verify that each SCD has the identical
configuration.

2.1.6.2Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include the flow of messages from the NTS through the SCD to the
NPG. This final verification will then be done such that the OET suite
will be ready to support Operations immediately following its
completion.

2.1.7Number range head4Number range head5Number range head6 NSM/Cluster
Preparation

The Network and System Management (NSM)/Cluster preparation consists of
verifying the NCC 98 baseline is installed, verifying the necessary
configuration of COTS products and customized scripts, and performing
the final checkout.

2.1.7.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the NSM/Cluster baseline will be
audited and documented. This activity can occur once all changes to the
OET baseline have been delivered. This audit will verify that the
appropriate versions of executables and scripts are resident on the
system.

2.1.7.2Number range head5Number range head6 Verification of Omniback
Schedule and Data Lists

The system backup schedule is stored and acted upon as part of the
Omniback product. The audit of the NCC 98 baseline should ensure that
the appropriate files are being archived and that this action is being
performed at the proper time.

2.1.7.3Number range head5Number range head6 Verification of Monitoring
Scripts and Package Configuration

Prior to transition, the configuration of the software "packages" should
be reviewed and documented. Each package should be "pinged" to verify
that it is accessible to the network. The packages should be configured
with package switching enabled and running on their primary node.

The "smart scripts" monitoring the processes of each package should also
be reviewed to ensure that they are running. The logs created by the
smart scripts should be inspected for any occurrences of processes being
regularly restarted. Such log entries could indicate a stability issue
that should be investigated prior to the transition.

2.1.7.4Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include the stopping and restarting of each software package to
ensure functionality and database consistency. This final verification
will then be done such that the OET suite will be ready to support
Operations immediately following its completion.

2.1.8Number range head4Number range head5Number range head6 WWW Server
Preparation

The World-Wide Web (WWW) Server preparation consists of verifying the
NCC 98 baseline is installed, verifying the necessary FTP accounts,
verifying the web server, and performing the final checkout.

2.1.8.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the WWW Server baseline will be
audited and documented. This activity can occur once all changes to the
OET baseline have been delivered. This audit will verify that the
appropriate versions of executables and scripts are resident on the
system.

2.1.8.2Number range head5Number range head6 Verification of FTP Accounts

Prior to the day of the transition, the FTP server configuration will be
audited and documented. This audit should ensure that the FTP accounts
are created to be identical with the existing FTP accounts in NCC 97.
The account for the SPSR to FTP TUT information to the WWW Server is
also required.

This part of the audit should also ensure that the setup of the vector
translator configuration files on the NPG is consistent with these FTP
accounts.

2.1.8.3Number range head5Number range head6 Verification of the Web
Server Configuration

Prior to the day of the transition, the Web Server configuration will be
audited and documented. This audit should ensure that the Web Server
configuration is as expected. This audit will also ensure that the TUT
distribution scripts are configured correctly and that TUT information
will be available to IONET MOCs as of the successful transition to
NCC 98.

This audit will also ensure that the "internal" Web Server configuration
is as expected. This will verify that TUT information and on-line
documentation are available to the NCC operators.

2.1.8.4Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include transfer of TUT data from the SPSR to the WWW Server. This
final verification will then be done such that the OET suite will be
ready to support Operations immediately following its completion.

2.1.9Number range head4Number range head5Number range head6 NCD
Preparation

The NCC Central Delogger (NCD) preparation consists of verifying the NCC
98 baseline is installed, verifying the necessary environmental
variables, and performing the final checkout.

2.1.9.1Number range head5 NCC 98 Baseline Installation and Verification

Prior to the day of the transition, the NCD baseline will be audited and
documented. This activity can occur once all changes to the OET baseline
have been delivered. This audit will verify that the appropriate
versions of executables and scripts are resident on the system.

2.1.9.2Number range head5Number range head6 Verification of Environment
Variables

Prior to the day of the transition, the system configuration will be
audited and documented. Part of this audit should ensure that the NCD
environment variables have been properly defined. This audit should also
include verification that the necessary Network File System (NFS) mount
points have been created and are accessible by the NCD software.

2.1.9.3Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include the execution of a delog to ensure that each set of log
files is accessible. This final verification will then be done such that
the OET suite will be ready to support Operations immediately following
its completion.

2.1.10Number range head4Number range head5Number range head6 SRIS
Preparation

2.1.10.1Number range head5 NCC 98 SRIS Baseline Verification

Prior to the day of the transition, the System Resource Infrastructure
Segment (SRIS) baseline will be audited and documented. This activity
can occur once all changes to the OET baseline have been delivered. This
audit will verify that the appropriate versions of executables and
scripts are resident on the system.

2.1.10.2Number range head5Number range head6 Verification of Internal
DNS Entries

Prior to the day of the transition, the internal DNS files will be
audited and documented. This audit should ensure that

• each node of the operational network is correctly identified in both
forward and reverse look-up tables;

• each virtual address and corresponding node name are correctly mapped
together;

• NCC services are defined with their corresponding virtual address;

• the necessary aliases for the ground terminals and NISN/SDPF are
properly defined.

This audit should also ensure that each node is configured to reference
the primary and secondary DNS tables on the 3-node cluster.

2.1.10.3Number range head5Number range head6 Verification of External
DNS Entries

Prior to the day of the transition, the external DNS files will be
audited and documented. This audit should ensure that

• each virtual address and corresponding node name are correctly mapped
together;

• NCC services are defined with their corresponding virtual address.

This audit should also ensure that the expiration time is set to ensure
that changes to the table are acquired by the MOCs in a timely fashion.

2.1.10.4Number range head5Number range head6 Verification of NTP
Configuration

Prior to the day of the transition, the Network Time Protocol (NTP)
Configuration will be audited and documented. This audit should ensure
that

• the CCS Universal Time Code (UTC) process is running on CCS3;

• the nodes of the 3-node cluster are configured to query the VAX as
their time server;

• the nodes of the 3-node cluster broadcast the time to the other nodes
of the network;

• the WWW Server queries the Firewall as its time server.

2.1.10.5Number range head5Number range head6 Verification of NFS Mount
Points

Immediately prior to the transition to NCC 98, System Administration
personnel will verify that each relevant mount point is established. The
lack of such mount points could also be determined in other verification
steps that rely on mounted files.

2.1.10.6Number range head5 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. The final verification
will include activities that will adequately determine if the DNS tables
and mount points are correct. This final verification will then be done
such that the OET suite will be ready to support Operations immediately
following its completion.

2.1.11Number range head4Number range head5Number range head6 SAS
Preparation

The SAS preparation consists of installing, configuring, and verifying
the SAS software (and network configuration) to support the NCC 98
architecture. The software consists of components on both the SAS server
and SPSR server platforms. Preparations for each platform is described
below.

2.1.11.1Number range head5Number range head6 SAS Server Preparation

2.1.11.1.1Number range head6 NCC 98 Baseline Installation and
Verification

At least one week prior to the transition, the SAS R99.1 release should
be installed and made operational on the SAS1 computer. The release
should be operated in the \"NCC 97 mode\" until the time of the
transition. Refer to the *SAS Release 99.1 Software Release Notes* for
more details concerning the installation and operation of this software.

2.1.11.1.2Number range head6 Verification of Configuration

The \"NCC 97 mode\" functioning of the release will be verified as part
of the initial installation process. Prior to the day of the transition,
additional, \"NCC 98 mode\" verifications will be performed. These
additional verifications will ensure NCC 98 network connectivity and
\"NCC 98 mode\" functions.

• Verify RTnet-TCP/32 network configuration (particularly IP addresses
of the SAS1 server, STGT, and White Sands Ground Terminal (WSGT))

• Verify Knet network configuration.

• Verify network connectivity by pinging both SAS network
implementations from an SPSR server.

• Verify Open Database Connectivity (ODBC) server functions by using
oaisql from an SPSR server to query the SAS database.

2.1.11.1.3Number range head6 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. Verify that any schedule
additions or deletions made in SPSR (e.g., readiness Bilateral Ranging
and Tracking System (BRTS) events) are replicated in the SAS database.
Use the SAS DAC status command to verify connections to the ground
terminal services and that operations data messages (ODMs), operations
messages (OPMs), and Service Level Reports (SLRs) are being received.
Use existing stored queries to verify that the SAS database is being
updated properly with information from the ODMs, OPMs, and SLRs. This
final verification will be done such that the OET suite will be ready to
support Operations immediately following its completion.

2.1.11.2Number range head5Number range head6 SAS Specific SPSR Server
Preparation

2.1.11.2.1Number range head6 NCC 98 Baseline Installation and
Verification

Prior to the day of the transition, the SAS component of the SPSR server
baseline will be audited and documented. This activity can occur once
all changes to the OET baseline have been delivered. This audit will
verify that the appropriate versions of executables and scripts are
resident on the system.

2.1.11.2.2Number range head6 Configuration Verification

Prior to the day of the transition, the SAS configuration will be
audited and documented. This audit will ensure that the ODBC Driver is
properly configured to support the operational environment and that the
Schedule Replication Agent (SRA) application has the proper
configuration.

• Verify the contents of openrda.ini file (particularly logging levels).

> • Use rdaadmin to verify the existence of the operational SAS
> databases and the IP addresses of the operational SAS servers in the
> Database Resource Directory (DRD).

• Verify the contents of the sashpux.cfg file (particularly the database
URLs).

• ping the operational SAS ODBC server to verify network connectivity.

• Use oaisql to verify the functioning of the operational SAS ODBC
server.

2.1.11.2.3Number range head6 Final Verification

After completing preparation activities, a final verification of the
complete NCC 98 environment will be performed. Use MC/ServiceGuard
displays and syslog entries to verify that SRA started successfully.
Verify that any schedule additions or deletions made in SPSR are
replicated in the SAS database. This final verification will be done
such that the OET suite will be ready to support Operations immediately
following its completion.

2.2Number range head3Number range head4Number range head5Number range
head6 Transition to NCC 98

Once the final verification of the NCC 98 system has been completed, the
actual transition of Operations will begin. The basic approach for the
transition is provided below. These items are detailed in the Transition
Timeline contained in Section 4.

• establish NCC 98 connection to Closed IONET. This results in NCC 97
and NCC 98 coexisting on the network.

• startup Firewall and Mproxy applications. Messages from non-TCP MOCs
should now be seen in both the baseline NCCDS and NCC 98.

• startup packages on 3-node cluster.

• startup CCS3 applications. Verify exchange of static data and events.

• Verify updates to external DNS and push them to NISN DNS server.
Notify Open (and Closed) IONET customers to use NCC 98 service IP
addresses as of time X.

• Transfer control from the legacy system to NCC 98:

− Terminate CCS applications on CCS1 and CCS2;

− Terminate Restricted Access Processor (RAP) applications on RAP1 and
RAP2

− Terminate NCC 97 NPG applications;

− Move RS-422 lines from operational NFE to NCC 98 SCD for STGT, WSGT,
and Special Projects and Missions (SP&M);

− Startup NPG application.

With the start of the NPG application software, NCC 98 should begin
processing messages and control of the NCCDS has been switched to NCC
98. TCP MOCs should now begin using the NCC 98 services, which were
advertised in the DNS update.

2.3Number range head3Number range head4Number range head5Number range
head6 Contingency Plans

Once the NCC has transitioned to the NCC 98 system, there will be a
small window of time to return to the Baseline NCCDS in the event that
NCC 98 fails to support operations as necessary. In order to return to
the legacy system, the following steps should be followed:

• Update the external DNS to be accessible to NISN DNS server. Notify
Open IONET customers to return to use NCC 97 IP service addresses as of
time Y.

• Transfer control from the NCC 98 system to the legacy system

− Terminate NCC 98 Firewall applications;

− Terminate NPG 98 application;

− SAS1 must be configured to NCC 97/98 mode during the fallback and to
NCC 97 mode when the fallback is complete;

− Startup SPS applications on SPS1 or SPS2. The message ID counter
should be set to a value greater than the highest SHO ID generated by
SPSR during NCC 98 operations;

− Move RS-422 lines from NCC 98 SCD for STGT, WSGT, SP&M to the desired
NFE;

− Startup RAP applications on RAP1 and RAP2;

− The NCC 98 disks on CCS1 and CCS2 should be powered off and the 95.3
disks powered up. The VAXs should then be rebooted under the NCCDS 95.3
environment; startup CCS applications on CCS1 and CCS2.

• Review any schedule updates enacted on the NCC 98 system and update
the legacy system as needed (e.g., resubmit schedule add requests
(SARs), FDF retransmit vectors, transmit SHOs). Scheduling algorithms
between the two systems are different, so the resulting events on the
legacy system may be different then those on the NCC 98 system.

Obviously, as the effort of this last step increases, the feasibility of
falling back to the legacy system decreases. Therefore, the longer the
database freeze can be maintained, the larger the window of opportunity
for falling back to the legacy system. At some point, the decision to
"fix NCC 98" instead of returning to the legacy system must be made.
This decision will be made by the Space Network Project Manager based on
input from development, test, system administration, and operations
personnel.

The rigorous testing that was performed on NCC 98 reduces the likelihood
that this contingency plan will be utilized. This minimal risk also
resulted in the decision to not pursue a "reverse database migration"
tool. This decision, along with the associated analysis, titled
*Fallback from NCC 98 to NCC 97: Options and Recommendation*, is
captured under NCC 98 Issue #75.

2.4 Number range head5Number range head4Number range head3Preparation
and Failover to CCS1 and CCS2

After Operations has gained a minimal level of confidence in NCC 98
while operational on CCS3, the preparation of CCS1 and CCS2 will be
completed. This preparation consists of all steps necessary to establish
and verify the complete NCC 98 baseline for the CCS-VAX.

2.4.1Number range head5Number range head4 CCS1 and CCS2 Preparation

The complete preparation of the operational suite must include the
reconfiguration of CCS1 and CCS2. In order to preserve the ability for
Operations to fallback to NCCDS Release 95.3 on CCS1 and CCS2, the disk
shadow set will be split approximately one week prior to the transition.
The necessary COTS products and the NCC 98 baseline will then be
installed on the unused disks.

After Operations has gained a minimal level of confidence in NCC 98
while operational on CCS3, preparation of CCS1 and CCS2 will be
completed. This includes the installation of Multinet, ObjectBroker, and
modified applications code will be completed. The preparation of CCS1
and CCS2 will also include deletion of obsolete baselines, including the
Release 95.3 delogger and log files. Therefore, log files should be
backed up to tape prior to the release of CCS1 and CCS2 by Operations.
Therefore, these log files should be backed up to tape prior to the
release of CCS1 and CCS2 by Operations. Before being used operationally,
each CCS should be cold started to ensure that the correct applications
start, log files are created, and operator accounts are setup for NCC
98.

2.4.2Number range head5Number range head4 Failover to CCS1 and CCS2

After the preparation of CCS1 and CCS2 is complete, Operations will
identify a window of opportunity to failover from CCS3 to CCS1 and CCS2
. In order to complete this failover, the NPG configuration files must
be modified (or reloaded) to communicate with the new node names and
addresses. This change requires an NPG restart (or switchover). The
System Context files for the ccs_services package on the HPs (cluster
and workstations) will also have to be redefined for the new nodes. This
requires a restart of the ccs_services package.

Once the point of no return to NCCDS 95.3 has been reached, the disks on
CCS1 and CCS2 can be restored to the shadow set. This action should be
done gradually so as to minimize any performance impact that could
result. The completion of CCS1 and CCS2 will also include deletion of
obsolete baselines, including the Release 95.3 delogger and log files.
Therefore, these log files should be backed up to tape prior to the
release of CCS1 and CCS2 by Operations.

2.5 Number range head5Number range head4Number range head3ANCC
Preparation

The preparation of the Auxiliary NCC (ANCC) is not required for the
transition of Operations to NCC 98.

2.6 Number range head5Number range head4Number range head3OCR Completion

2.6.1Number range head5Number range head4 IT Removal

The removal of the OCR ITs will occur once the transition to NCC 98 is
determined to be successful.

2.6.2Number range head4Number range head5Number range head6 Workstation
Installation

Once the removal of the ITs is complete, the installation of the
remaining OCR Workstations will be completed. This activity includes the
installation, integration, and verification of new workstations as well
as the repositioning of the original OCR Workstations. This activity
will be performed on an aggressive, but non-impacting basis.

Each new workstation will be configured, connected to the network, and
exercised prior to its turnover to Operations.

Section 3Number range TableNumber range figsNumber range head5Number
range head4Number range head3Number range head2. Transition Timelines

3.1 Number range head5Number range head4Number range head3Timeline of
Activities for the Initial NCC 98 Operational Transition

The following timeline (Figure 4-1) shows start time, duration, and the
responsible group for each activity required to configure the NCC 98
environment in the OCR. This timeline also attempts to illustrate any
dependencies between the activities. The timeline also assumes certain
associations between these activities and the OET effort. These
assumptions are suggested as "a plan" and should not be interpreted as
dictating these actions.

*\
Table 3-1*. Initial Transition Timeline

+---------+----------------------------+--------+---------------------+
| Start   | Activity                   | Per    | De                  |
| Time    |                            | sonnel | pendencies/Comments |
+=========+============================+========+=====================+
| T-2     | Ensure that necessary      | OET    |                     |
| weeks   | updates to the NISN Secure |        |                     |
|         | Gateway have been          | GSA    |                     |
|         | requested.                 | D.4    |                     |
+---------+----------------------------+--------+---------------------+
| T-1     | Secondary UIFCs are        | DBM    | IONET is IP-only    |
| week    | removed from config code   |        |                     |
|         | and events.                |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Ensure STGT software       | NCCPO  | Assumed to be on or |
|         | delivery ETN-295 has been  |        | about February 3rd  |
|         | installed                  |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Make image saves of CCS3,  | GSA    |                     |
|         | include Multinet and       | D.4    |                     |
|         | ObjectBroker save sets and |        |                     |
|         | 98_1 baseline.             |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Identify differences in    | GSA    |                     |
|         | CCS command procedures,    | D.4    |                     |
|         | especially startup         |        |                     |
|         | scripts.                   |        |                     |
+---------+----------------------------+--------+---------------------+
| T-1     | Review groups, accounts, & | GSA    |                     |
| week    | home directories           | D.4    |                     |
|         |                            |        |                     |
|         |                            | OET    |                     |
+---------+----------------------------+--------+---------------------+
|         | Compare CCS Site Table,    | OET    | Turn poly "on"      |
|         | NPG Config files, and      |        |                     |
|         | Mproxy config file         | DBM    | Turn CTMs off for   |
|         |                            |        | MPC, BRM, SDPF,     |
|         |                            |        |                     |
|         |                            |        | Remove schStatus    |
|         |                            |        | service for BRM     |
|         |                            |        |                     |
|         |                            |        | Verify Multicast    |
|         |                            |        | addresses           |
|         |                            |        |                     |
|         |                            |        | Establish CCS3 and  |
|         |                            |        | CCS1/CCS 2 copies.  |
+---------+----------------------------+--------+---------------------+
|         | Audit SPSR Baseline        | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Audit CCS Baseline         | GSA    | Verify existence of |
|         |                            | D.4    | correct             |
|         |                            |        | ObjectBroker .col   |
|         |                            |        | files.              |
+---------+----------------------------+--------+---------------------+
|         | Audit NPG Baseline         | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Audit NCD Baseline         | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Audit Workstation Baseline | GSA    | Verify existence of |
|         |                            | D.4    | correct             |
|         |                            |        | ObjectBroker .col   |
|         |                            |        | files.              |
+---------+----------------------------+--------+---------------------+
|         | Audit Firewall Baseline    | GSA    | Ensure correct      |
|         |                            | D.4    | security policy is  |
|         |                            |        | activated.          |
+---------+----------------------------+--------+---------------------+
|         | Audit SPSR Baseline        | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
| T-1     | Audit SAS component of     | SAS    |                     |
| week    | SPSR                       | Dev    |                     |
+---------+----------------------------+--------+---------------------+
|         | Install SAS 99.1 on SAS1   | SAS    |                     |
|         |                            | Dev    |                     |
+---------+----------------------------+--------+---------------------+
|         | Split shadow disks on CCS1 | GSA    |                     |
|         | and CCS2. Begin population | D.4    |                     |
|         | of disks from tape.        |        |                     |
+---------+----------------------------+--------+---------------------+
| T-1 day | Ensure "split Firewall"    | GSA    |                     |
|         | configuration is broken    | D.4    |                     |
|         | and both Firewalls are     |        |                     |
|         | connected to Closed IONET. |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Ensure that ANCC Firewall  | OET    |                     |
|         | has correct Rule Set       |        |                     |
|         | activated                  |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Initialize ITO and         | GSA    |                     |
|         | Omniback databases         | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Delete all log files       | GSA    |                     |
|         | created during OET         | D.4    |                     |
|         | activities                 |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Delete all old TUT files   | GSA    |                     |
|         | generated during OET       | D.4    |                     |
+---------+----------------------------+--------+---------------------+
| T-10    | Activate Schedule          | OPS    | None                |
| hours   |                            |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Dynamic Dump on SPS        | OPS    |                     |
|         | (Database Freeze now in    |        |                     |
|         | effect)                    |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Load Dump onto SPS3        | OPS    |                     |
+---------+----------------------------+--------+---------------------+
| T-9     | Perform phase 1 of         | GSA    | st                  |
| hours   | migration                  | D.4    | ncc\*ncc.tel        |
|         |                            |        | net-start,,,ncc/ncc |
|         |                            |        |                     |
|         |                            |        | \@add               |
|         |                            |        | nc                  |
|         |                            |        | c\*ncc.spsdatadwnld |
+---------+----------------------------+--------+---------------------+
|         | Activate 3-node cluster;   | GSA    | \~dbmig/op          |
|         | start nfshost, sn-oracle,  | D.4    | s_migration/preLoad |
|         | itohost and omniback       |        |                     |
|         | packages                   |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Perform phase 2 of         | GSA    | \~dbmig/ops         |
|         | migration                  | D.4    | _migration/postLoad |
|         |                            |        |                     |
|         |                            |        | make --f            |
|         |                            |        | Makefile_ops all    |
|         |                            |        |                     |
|         |                            |        | make --f            |
|         |                            |        | Makefile_ops load   |
+---------+----------------------------+--------+---------------------+
| T-5     | start spsrhost, ccshost,   | GSA    |                     |
| hours   | rosehost, acrshost, sas    | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Perform manual database    | GSA    | SUPIDEN/IP address  |
|         | updates                    | D.4    | entries             |
|         |                            |        |                     |
|         |                            | NCC    | Destination names   |
|         |                            | DBA    | for future TCP      |
|         |                            |        | entities            |
|         |                            |        |                     |
|         |                            |        | Activate            |
|         |                            |        | transmission rule   |
|         |                            |        | sets and purge jobs |
|         |                            |        |                     |
|         |                            |        | Update passwords    |
|         |                            |        | for VR, SRR         |
|         |                            |        | messages            |
|         |                            |        |                     |
|         |                            |        | Establish relative  |
|         |                            |        | boundary schedule   |
|         |                            |        | and interval.       |
|         |                            |        |                     |
|         |                            |        | Establish Absolute  |
|         |                            |        | and Current         |
|         |                            |        | Boundary times.     |
|         |                            |        |                     |
|         |                            |        | Remove BRM from all |
|         |                            |        | schedule            |
|         |                            |        | distribution lists  |
|         |                            |        | and Rule sets.      |
+---------+----------------------------+--------+---------------------+
|         | Create database reports    | GSA    |                     |
|         | for inspection             | D.4    |                     |
|         |                            |        |                     |
|         |                            | NCC    |                     |
|         |                            | DBA    |                     |
+---------+----------------------------+--------+---------------------+
|         | Perform SHO creation; ID   | GSA    |                     |
|         | migration                  | D.4    |                     |
+---------+----------------------------+--------+---------------------+
| T-2     | Cold start CCS; verify     | OPS    |                     |
| hours   | data transfer              |        |                     |
|         |                            | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Logon to workstation;      | OET    |                     |
|         | verify functionality;      |        |                     |
|         | begin database checkout.   | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Initiate Hot Backup of     | GSA    |                     |
|         | SPSR Database              | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Readdress TUT MAC and move | OPS    |                     |
|         | to NCC 98 network.         |        |                     |
|         |                            | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
|         | Execute scenario to        | OET    |                     |
|         | perform final              |        |                     |
|         | verification.              | GSA    |                     |
|         |                            | D.4    |                     |
+---------+----------------------------+--------+---------------------+
| FINAL   |                            |        |                     |
| VERIF   |                            |        |                     |
| ICATION |                            |        |                     |
| IS      |                            |        |                     |
| C       |                            |        |                     |
| OMPLETE |                            |        |                     |
+---------+----------------------------+--------+---------------------+
| T-1     | Establish Connection to    |        |                     |
| hours   | Closed IONET               |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Startup Firewall and       |        | Verify NCC          |
|         | Mproxy applications.       |        | Multicast Address   |
|         | Verify Firewall Rule set   |        |                     |
|         | is configured correctly    |        |                     |
|         | and activated.             |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Configure SAS1 to          | SAS    |                     |
|         | "NCC97/98" Mode            | DBA    |                     |
+---------+----------------------------+--------+---------------------+
|         | Verify updates to external |        | Affects LS7         |
|         | DNS and availability to    |        |                     |
|         | NISN                       |        | Affects HST, EOS,   |
|         |                            |        | DAS                 |
|         | Inform TCP Customers to    |        |                     |
|         | switch to NCC 98 IP        |        |                     |
|         | Addresses                  |        |                     |
+---------+----------------------------+--------+---------------------+
| T- 15   | Terminate CCS1 and CCS2    |        | NCC is now          |
| minutes | and NCC 97 NPG             |        | off-line!           |
+---------+----------------------------+--------+---------------------+
|         | Move RS-422 connections    |        |                     |
|         | from NFE to NCC 98 SCD     |        |                     |
+---------+----------------------------+--------+---------------------+
| T+0     | Start NPG for NCC 98       |        | NCC is back on-line |
| hours   |                            |        | under NCC 98!       |
+---------+----------------------------+--------+---------------------+
|         | Verify SAS has connections | SAS    |                     |
|         | to NPG and is receiving    | Dev/   |                     |
|         | ODMs, OPMs, SLRs           |        |                     |
|         |                            | SAS    |                     |
|         |                            | DBA    |                     |
+---------+----------------------------+--------+---------------------+
| T+ 0.5  | Schedule and transmit BRTS |        |                     |
| hours   | events to verify NCC 98    |        |                     |
|         | readiness for schedule     |        |                     |
|         | updates.                   |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Verify that the SAS        | SAS    |                     |
|         | database receives BRTS     | DBA    |                     |
|         | event.                     |        |                     |
+---------+----------------------------+--------+---------------------+
| T+1     | Receive full vector        |        |                     |
| hour    | transmission from FDF.     |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Transmit type 8 to ensure  |        |                     |
|         | throughput rule set        |        |                     |
|         | activated ????             |        |                     |
+---------+----------------------------+--------+---------------------+
|         | Remove database freeze for |        |                     |
|         | real-time schedule updates |        |                     |
+---------+----------------------------+--------+---------------------+
| T+3     | Notify MOCs one-by-one to  |        |                     |
| hours   | send in forecast requests  |        |                     |
|         | for next schedule          |        |                     |
|         | generation.                |        |                     |
+---------+----------------------------+--------+---------------------+
| T+6     | Configure SAS1 to "NCC98   | SAS    |                     |
| hours   | Mode"                      | DBA    |                     |
+---------+----------------------------+--------+---------------------+
| T+n     | Inform NISN to redefine    |        |                     |
| hours   | the Authoritative DNS      |        |                     |
|         | server for the NCC.        |        |                     |
+---------+----------------------------+--------+---------------------+

3.2 Timeline of Activities to Configure CCS1 and CCS2

The following timeline (Figure 4-2) shows start time, duration, and
responsible group for each activity required to configure CCS1 and CCS2
into the operational suite of equipment. This timeline also attempts to
illustrate any dependencies between the activities.

*Figure 4-2. CCS1 and CCS2 Transition Timeline*

+--------+-------+------------------------+-------+------------------+
| Start  | Dur   | Activity               | Pers  | Dependencies     |
| Time   | ation |                        | onnel |                  |
+--------+-------+------------------------+-------+------------------+
| T-7    |       | Perform NCC 98 image   | OPS   | None             |
| days   |       | save on CCS3           |       |                  |
|        |       |                        | GSA   |                  |
|        |       |                        | D.4   |                  |
+--------+-------+------------------------+-------+------------------+
| T-4    |       | Split shadow sets;     | OPS   |                  |
| days   |       | populate NCC 98 disks  |       |                  |
|        |       | from CCS3 image save   | GSA   |                  |
|        |       |                        | D.4   |                  |
+--------+-------+------------------------+-------+------------------+
| T+0    |       | NCC 98 is accepted by  | OPS   | None             |
|        |       | Operations on CCS3     |       |                  |
+--------+-------+------------------------+-------+------------------+
| T+2    |       | Power 95.3 set of      | OPS   | None             |
| hours  |       | disks off.             |       |                  |
+--------+-------+------------------------+-------+------------------+
| T+3    |       | Configure redundant    | GSA   | Completion of    |
| hours  |       | disks to be NCC 98     | D.4   | previous step    |
|        |       | compliant (as          |       |                  |
|        |       | described below)       |       |                  |
+--------+-------+------------------------+-------+------------------+
|        |       | -   Upgrade Multinet   | GSA   | None             |
|        |       |                        | D.4   |                  |
|        |       | -   Install            |       |                  |
|        |       |     ObjectBroker       | OPS   |                  |
|        |       |                        |       |                  |
|        |       | -   Create/Update DNS  |       |                  |
|        |       |     on VAX             |       |                  |
|        |       |                        |       |                  |
|        |       | -   Modify IP          |       |                  |
|        |       |     Addresses          |       |                  |
|        |       |                        |       |                  |
|        |       | -   Complete           |       |                  |
|        |       |     installation of    |       |                  |
|        |       |     NCC 98 Custom      |       |                  |
|        |       |     Application        |       |                  |
|        |       |     software           |       |                  |
|        |       |                        |       |                  |
|        |       | -   Patch CCS1 LAN 1   |       |                  |
|        |       |     to Devlan1 in the  |       |                  |
|        |       |     NACC               |       |                  |
|        |       |                        |       |                  |
|        |       | -   Patch CCS 2 LAN 1  |       |                  |
|        |       |     to Devlan2 in the  |       |                  |
|        |       |     NACC               |       |                  |
|        |       |                        |       |                  |
|        |       | -   Configure V-LAN    |       |                  |
|        |       |     once nodes appear  |       |                  |
|        |       |     on Switch Manager  |       |                  |
+--------+-------+------------------------+-------+------------------+
| T+6    |       | Install CM Baseline    | OPS   | None             |
| hours  |       | software onto CCS1 and |       |                  |
|        |       | CCS2                   |       |                  |
+--------+-------+------------------------+-------+------------------+
| T+9    |       | Perform final checkout | GSA   | None             |
| hours  |       | of CCS1/2              | D.4   |                  |
|        |       |                        |       |                  |
|        |       |                        | OET   |                  |
+--------+-------+------------------------+-------+------------------+
| T+10   |       | Make a full image save |       |                  |
| hours  |       | of NCC 98              |       |                  |
+--------+-------+------------------------+-------+------------------+
| T+11   |       | Power up remaining     | OPS   | Installation of  |
| hours  |       | disks and return them  |       | software         |
|        |       | to the Shadow Set      |       |                  |
+--------+-------+------------------------+-------+------------------+
| T+n    |       | Move Operations to the | OPS   | Completion of    |
| hours  |       | CCS1/CCS2              |       | Checkout         |
+--------+-------+------------------------+-------+------------------+

Abbreviations and Acronyms

ABR Abbreviations

ACQ/TRK Acquisition and Tracking

ANCC Auxiliary Network Control Center

ATSC AlliedSignal Technical Services Corporation

BRTS Bilateral Ranging and Tracking System

CCS Communications and Control Segment

CM configuration management

COTS commercial off-the-shelf

CSC Computer Sciences Corporation

CTM communications test message

DAS demand access service

DBA database administrator

DNS domain name server

DRD Database Resource Directory

EIF engineering interface test

EOS earth observing satellite

FDF flight dynamics facility

FTP file transfer protocol

GSA general service agreement

GSFC Goddard Space Flight Center

GT ground terminal

HA high availability

HDRM high data rate multiplexer

HP Hewlett-Packard

HST Hubble Space Telescope

ICD interface control document

ID identification; identifier

IIRV improved interrange vector

IP internet protocol

IT intelligent terminal

ITS intelligent terminal segment

LAN local area network

LI local interface

LS7 Landsat 7

MAR multiple access return

Mbps mega-bits per second

MDM multiplexer/demultiplexer

MOC mission operations center

MSS message switching system

NACC network access control card

NASA National Aeronautics and Space Administration

Nascom NASA communications

NCC Network Control Center

NCCDS Network Control Center Data System

NCCPO NCC Project Office

NCD NCC Central Delogger

NES Nascom Event Schedule message

NEST NISN Event Scheduling Terminal

NFE NCC front-end

NFS network file server

NIB Nascom interface board

NISN NASA Integrated Services Network

NPG NCC Protocol Gateway

NTP network time server

NTS NCC Test System

OCR Operations Control Room

ODBC Open Database Connectivity

ODM operations data message

OET Operational Evaluation Testing

OPM operations message

OPS Operations

OTP Operations Transition Plan

PA performance analyst

PEP polynomial error protection

PN pseudorandom noise

RAP restricted access processor

SAR schedule add request

SAS service accounting segment

SCD small conversion device

SDPF sensor data processing facility

SHO scheduled service order

SIC satellite identification code

SGLT space to ground-link terminal

SLR service-level request

SN space network

SNIP Space Network Interoperability Panel

SP&M special projects and missions

SPS service planning segment

SPSR service planning segment replacement

SRA Schedule Replication Agent

SRIS system resources infrastructure segment

SRM schedule result message

SRR schedule result request message

SS system supervisor

STGT Second TDRSS Ground Terminal

SUPIDEN spacecraft identification

TCP transmission control protocol

TDRS Tracking and Data Relay Satellite

TM technical manager

TUT TDRSS unscheduled time

UDP user datagram protocol

UIFC user interface channel

USM user schedule message

UTC universal time code

VAX virtual address extension

VID vehicle identification

V-LAN virtual LAN

VR vector request message

VT vector translator

WSC White Sands Complex

WSGT White Sands Ground Terminal

WWW World-Wide Web